[Csantucci]

Chris,
thanks for the appraisal.
Here a picture of the crane grabbing a 20ft container


and here a picture with the same crane, having lengthened its arms, grabbing a stacked 40ft container

[steamer_ctn]

Csantucci, on 28 April 2022 - 09:02 AM, said:

In addition to that, a new file format is needed to define the containers that are present at game start in the various container stations. I'd prefer to keep it in "MSTS" format, because that would be coherent with the other files, but I see that for new file formats the .json format is mandatory...
This new file could then be recalled from .act files, and also from timetable files, provided someone would implement this second link.

cjakeman, on 28 April 2022 - 11:51 AM, said:

Yes, it is indeed mandatory.

What is the current OR policy for implementation of JSON format files? When will all old formats be converted over?

How will legacy files be handled, will OR always have to handle both file formats? Will there be some sort of incentive provided to encourage users to transition to JSON files?

My personal preference would be to see this new file as a "MSTS" format, as most users already are familiar with the layout, style and text format. It could then be converted over when all the other "MSTS" files are converted to JSON.

Whilst I agree that it maybe reasonable to be working towards a JSON format, I think that we need to consider all the implications of a JSON conversion, and develop an appropriate transition plan, rather the encouraging an ad-hoc mixture of MSTS Legacy files and JSON.

Csantucci, on 28 April 2022 - 09:02 AM, said:

Replying to Peter after some days of coding and testing: I'm open to discussion about file formats and so on, but I think that the best place is here, for two reasons: first, we are speaking about files that will be managed by content creators and by players, so here there is a wider audience. Second, I prefer not to duplicate the discussion.

Ok, thanks for that.

To provide a base for the attaching of physics to this new loading/unloading concept lets think in terms of the following two physics scenarios (this is not all the physics that need to be considered, but acts as an example).

i) The first obvious one is the wagon weight (mass) that will need to vary as loads or added or subtracted. Naturally this will impact the tonnage capacity.

ii) Train Resistance - All Davis values will be impacted as the weight changes. In particular the Davis C value will be the most challenging (due to the change in air resistance), as it will vary from an empty wagon, to one or two containers single stacked, and containers double stacked. So how could we differentiate if the same container is added as a single stack or double stack?

So, I assume that you have already thought about the handling of wagons in MSTSWagon.cs and to ensure that we are on the same page, I believe we have two scenarios as follows:

i) In Game Addition / Subtraction of Load - Containers (or other loads) are loaded at a terminal and the physics is added or subtracted from the base wagon in MSTSWagon.cs as appropriate. One aspect that will need to be considered is how is the load linked to an articulated wagon consist, eg 5 pack container cars? Hence the need to consider a "bigger" picture view of loading and articulated wagons.

ii) Game Initialisation - Train consist is built, and loads are added to MSTSWagon.cs

Are these the options that you have considered?

Hence, on the above basis I agree with your concept of creating a LOA file for every discrete load. Some thought will need to be given to the parameters defined in this file, so that only the required parameters are required.

I also think that using a ACT file or Timetable file as a means for providing a pool of containers (or loads) at a site seems a reasonable approach. For the ACT file I would suggest that they should either be able to be included directly into the ACT file, or alternatively via an INC file (my preferred solution). When the activity initially starts how will it physically locate the containers at the loading site. Will the user need to put in a location reference point similar to the loose consist concept?

Csantucci, on 28 April 2022 - 09:02 AM, said:

At the moment for the containers I am using an intermediate solution: container data are stored in .inc files (one for every container type) within a directory, with a mnemonic name indicating the dimensions of the container and the brand. This way it is not needed to write specific code, and the data are centralized, easily accessible and don't require duplication. As this is a solution that didn't require writing code, another solution, if better, wouldn't mean that I have wasted time.

As a prove of concept this seems a reasonable approach, but I would suggest that a "permanent" solution needs to be developed before final deployment, as we don't want to create a legacy situation that needs to be maintained into the future.

Csantucci, on 28 April 2022 - 09:02 AM, said:

I am thinking at two ways to link container data to wagon data: the first way is - let's say so - an embedded way, where the .wag file contains the data of the containers carried by referencing the above .inc files. I think that wagon+container developers would like to have also this possibility. The second way is to insert the link in the .con file.
I am thinking at the following one:

                ...
		Wagon (
			WagonData ( DTTX_62142_3D ATW.DTTX_62142 )
			UiD ( 6 )
                        ContainerData (
                            Container (
                                Include ( "..//..//common.containerdata//20hamburgsud.inc")
                                Alignment (CenterRear)
                                )
                            Container (
                                Include ( "..//..//common.containerdata//20cmacgm.inc")
                                Alignment (CenterFront)
                                )
                            ...
		)
                ...
 

For a start I would prefer to see Container renamed to Load, as this will allow future extension of this work beyond containers without needing to change input file formats.

Again I think that it should be possible to either add the statements directly to the CON file, or as a preferred solution via an INC file.

Is it possible to use a more abbreviated coding input? Perhaps something like the following:

LoadData ( UiD   Load File   Load Directory  Load Alignment )

Which using your example might look something like this:

LoadData ( 6  20cmacgm  common.containerdata  CenterFront )

Thus reducing a number of lines into one line, and also allowing it to be placed anywhere in the file or in an INC file. It also maintains a similar format to WagonData, etc.

Csantucci, on 28 April 2022 - 09:02 AM, said:

Allowed alignments are Rear, CenterRear, CenterFront, Front, Center and Above. I believe I can manage all significant container layouts this way.
Center alignment is default.

Can you describe each of these positions, for example my main question is what is the difference between Rear and CentreRear, etc?

[Csantucci]

Peter,
thank you for your contribution.
I start answering your last question.
Rear means that the container is aligned with the rear end of the wagon's loading area;
CenterRear means that the container has one side aligned with the center of the wagon's loading area, and extends towards the rear of the wagon;
Centerfront means that the container has one side aligned with the center of the wagon's loading area, and extends towards the front of the wagon;
Front means that the container is aligned with the front end of the wagon's loading area;
Center means the the container has middle point of the Z axis coinciding with the center of the wagon's loading area;
Above means that it is a container laying on the "second floor". It is intended that on the "second floor" there is only one container, and that it is aligned to the center of the wagon's loading area.

This should cover practically all combinations that can be seen. If a 2% doesn't enter in this classification, I won't care about that.

About file formats, I too would prefer to keep an MSTS format here to avoid mixtures (container data are needed in .con files, in .wag files and in the file related to the loading areas). In general however I prefer a co-existence of the two file formats and not a complete switchover.
Re the identification of the loading areas (which are always related to a pickup point), this would occur as it is with the turntable file now, that is world file name and UiD within such world file of the related pickup.

[Laci1959]

Quote

Whilst I agree that it maybe reasonable to be working towards a JSON format, I think that we need to consider all the implications of a JSON conversion, and develop an appropriate transition plan, rather the encouraging an ad-hoc mixture of MSTS Legacy files and JSON.

Hello.

I would like to add to this and above that the average content creator and user has not even heard of the JSon format.
What's next? Will they go away forever or get stuck on a current version, giving up on future changes?
Maybe you are making some simple easy to use graphical converter?

Peter's points (i) and (ii) only to the extent that this has already been partially resolved or not? I am thinking of the FreightAnimContinuous block that was introduced earlier.
There is so much truth in it that the 20hamburgsud.inc file in the path path Include ("..//..//common.containerdata//20hamburgsud.inc") must somehow include the weight of the container. It had been raised in me before, I just didn’t want to lead it out yet.

Sincerely, Laci 1959

[Laci1959]

LoadData ( UiD Load File Load Directory Load Alignment )  

Hello.

The UID () line above the ContainerData line was introduced by MSTS, as was the line above it. I don't know if OR is using it now. If you don’t use it, I think Carlo typed it out of habit, the way I still use it out of habit.

Sincerely, Laci 1959

[Csantucci]

The UiD line of MSTS in .con files is used by OR.

[steamer_ctn]

Hi Carlo,

Thanks for the additional feedback.

Csantucci, on 29 April 2022 - 12:01 AM, said:

Rear means that the container is aligned with the rear end of the wagon's loading area;
CenterRear means that the container has one side aligned with the center of the wagon's loading area, and extends towards the rear of the wagon;
Centerfront means that the container has one side aligned with the center of the wagon's loading area, and extends towards the front of the wagon;
Front means that the container is aligned with the front end of the wagon's loading area;
Center means the the container has middle point of the Z axis coinciding with the center of the wagon's loading area;
Above means that it is a container laying on the "second floor". It is intended that on the "second floor" there is only one container, and that it is aligned to the center of the wagon's loading area.

How do you detect the reference point for the loading point?

Is the loading point reference included in the wagon WAG file as a reference point, much the same as the "water" or "coal" intake point? This type of approach would provide a more accurate reference point then trying to calculate a reference point off the wagon Size parameter which is never accurate enough. This approach would also allow some configurations to not be used on this type of wagon. For example if CentreRear is not reference then a load could not be assigned to this position on the car.

So would a user insert a statement something like the following into the WAG file?

LoadPoint ( 1.759 10 Rear )

Csantucci, on 29 April 2022 - 12:01 AM, said:

About file formats, I too would prefer to keep an MSTS format here to avoid mixtures (container data are needed in .con files, in .wag files and in the file related to the loading areas). In general however I prefer a co-existence of the two file formats and not a complete switchover.

Thanks for your feedback on this. I am also hoping that the ORMT will provide some input on this discussion as well.

In regards to the different files co-existing, I suspect that they may co-exist forever, unless we have a transition plan defined. My point was more about ensuring that we don't have different formats for different files. My thinking is that if MSTS format is going to be retained, then it should be available for all files, similarly if JSON is used then all files should be in JSON. I would be disappointed to see a mix where one file type is in JSON, and another file type is in MSTS. To me it is all about consistency and ease of user (within reasonable bounds) for the content provider.

Csantucci, on 29 April 2022 - 12:01 AM, said:

Re the identification of the loading areas (which are always related to a pickup point), this would occur as it is with the turntable file now, that is world file name and UiD within such world file of the related pickup.

Can you expand on this a bit for me?

So say that we want to have 60 containers in a dump ready to be loaded, then how would we specify how they are to be placed in game? All on top of each other? In neat rows, etc?

[steamer_ctn]

Thinking about adding the physics, would it be possible to add two new methods as follows?

LoadPhysicsInitialisation () - This would perhaps be located in TrainCar.cs(?) and would be called whenever a wagon is initialised with a load module. Relevant physics would be added to the base wagons physics as appropriate.

UpdateLoadPhysics () - This would be called every time a load was added or removed from the base car. It would adjust the wagon physics as appropriate for changes to the load.

WDYT?

[Csantucci]

Peter, I agree about the two physics methods you suggest, and have the intention to add the calls in the code at suitable time.

Chris, I wanted to start with Json, but I've seen that there isn't the possibility to directly read a Vector3 (X, Y, Z), which is instead available for the StfReader, and which is quite useful for this function.
Also an item.AsBoolean(parameter) seems to be missing.
I am a zero in writing/expanding parsers, so I'd need help here if I have to use Json.

[cjakeman]

steamer_ctn, on 28 April 2022 - 11:20 PM, said:

What is the current OR policy for implementation of JSON format files? When will all old formats be converted over?

How will legacy files be handled, will OR always have to handle both file formats? Will there be some sort of incentive provided to encourage users to transition to JSON files?

My personal preference would be to see this new file as a "MSTS" format, as most users already are familiar with the layout, style and text format. It could then be converted over when all the other "MSTS" files are converted to JSON.

A new thread has been started for this discussion in the private forum Open Rails Development > Features > All other features

[cjakeman]

Csantucci, on 01 May 2022 - 07:08 AM, said:

Chris, I wanted to start with Json, but I've seen that there isn't the possibility to directly read a Vector3 (X, Y, Z), which is instead available for the StfReader, and which is quite useful for this function.
Also an item.AsBoolean(parameter) seems to be missing.
I am a zero in writing/expanding parsers, so I'd need help here if I have to use Json.

Sure. I'll take a look tomorrow and get back to you.

[gpz]

Csantucci, on 01 May 2022 - 07:08 AM, said:

Chris, I wanted to start with Json, but I've seen that there isn't the possibility to directly read a Vector3 (X, Y, Z), which is instead available for the StfReader, and which is quite useful for this function.

See an example here, how a vector3 can be defined in json:
https://github.com/K...TF/Box.gltf#L77
(This is a 3-element array.)

[Csantucci]

Thanks Peter,
it's clear how to define it. The problem (only for me) is how to parse it.

[gpz]

The Vector3 struct is defined in the MonoGame package, while the json parser in the NewtonSoft.Json package, so they don't know about each other. Json can be parsed into float[], and that can be written into Vector3, I think.

[Csantucci]

Yes, that is a possible, indirect, solution. But in my ignorance I don't know how to read an array using Json parser calls...