[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...

[gpz]

You may define the whole json structure as classes, like here:
https://github.com/p....cs#L1599-L1630

Then you can deserialize the string like this:
https://github.com/p...tfShape.cs#L338

It can be done in one pass for the whole complex object.

[Csantucci]

Thanks Peter,
I'll study that.

[cjakeman]

Hi Carlo,

cjakeman, on 02 May 2022 - 01:03 PM, said:

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

Still working on this.

I'm preparing a PR which extends Source\Orts.Parsers.OR\JsonReader.cs, but I was hoping to provide some parsing for you too.

Here is the test data I am using. Basically contains a list of objects each with Boolean, Vector3, free text, enum text and ints. Hope that will be a good starting point.

[Csantucci]

Hi Chris and Peter,
in the meantime I could solve my problems. By analogy I could add an AsBoolean and for the vectors I used this simple syntax

		"IntrinsicShapeOffset": [0,1.17,-6.118],

which I was able to parse.

Thank you for your time.

[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.

If a JSON file is known to be valid then, using the JSON library, it can be read in a single statement (as it is currently in Updater, ActivityEditor and TrackViewer).

If it might be edited as a text file, then we can use OR's JsonReader class to parse data and report any issues in the log with the appropriate line number.
Aspects to consider include:

• ensuring required properties are present
• allowing optional properties to be present or absent
• ignoring unexpected properties (if desired)

An example which reads valid data and invalid data, including Boolean and a Vector3, is now available at https://github.com/c...-container-file It also shows working with required, optional and unexpected properties.

I know Carlo already has a working solution, but this example shows how OR's JsonReader class is meant be used.


I've now submitted a PR which adds AsBoolean() and AsVector3() to OR's JsonReader class as used in this example. Credit to James for improving my attempt.

[James Ross]

cjakeman, on 07 May 2022 - 10:49 AM, said:

If a JSON file is known to be valid then, using the JSON library, it can be read in a single statement (as it is currently in Updater, ActivityEditor and TrackViewer).

If it might be edited as a text file, then we can use OR's JsonReader class to parse data and report any issues in the log with the appropriate line number.
Aspects to consider include:

All code should use "JsonReader" unless granted an exception. It provides a more familiar, more performant way to load JSON than the other options in all but exceptional cases.

cjakeman, on 07 May 2022 - 10:49 AM, said:

I know Carlo already has a working solution, but this example shows how OR's JsonReader class is meant be used.

I've now submitted a PR which adds AsBoolean() and AsVector3() to OR's JsonReader class as used in this example. Credit to James for improving my attempt.

There are still some small outstanding issues with the code, so please bear that in mind when taking code out of the example to use.

[Laci1959]

James Ross, on 07 May 2022 - 12:34 PM, said:

All code should use "JsonReader" unless granted an exception. It provides a more familiar, more performant way to load JSON than the other options in all but exceptional cases.


There are still some small outstanding issues with the code, so please bear that in mind when taking code out of the example to use.

Who will be better off using JSON?

For programmers who write the OR program?
For the average user because the program will load faster to run?
For the average user who has weaker hardware and is running win 7 for some outside reason?
Or for the user who is trying to build a track as a driver, a traffic person, or an absolute outsider? Since it is not supported by any graphical track editor, it will not be an easy thing with the animated container anyway, but at least it is / was in a familiar environment.

[superheatedsteam]

Laci1959, on 07 May 2022 - 10:48 PM, said:

Who will be better off using JSON?

I'm not a programmer, but from the examples of JSON I have just seen from a google search, it is not some cryptic format and to me is human readable. If it makes programming and data exchange easier for the programmers, then I'm all for it.

Average 'user' will not care or know about JSON.

Average 'content creator' has demonstrated ability to learn new skills, adding JSON to their skill set should be insignificant in comparison.

Cheers,

Marek.

[Csantucci]

Thanks for the JsonReader additions!

[Csantucci]

There weren't progress reports since some time, because I decided to allow for more flexibility in use of 20 and 40ft containers. So, where a 40ft container was present and then unloaded, one can load two 20ft containers. This seems quite a trivial issued, but required a rethinking and rewriting of the FreightAnimDiscrete design.
Now FreightAnimDiscretes are no more defined by the player at game startup, remaining immutable in number, position, length; instead, they are generated dynamically depending from the load that is present. To be more clear, suppose to have a single-stack wagon able to get up to 80ft of containers. It could e.g. be loaded (from rear to front) with a 20ft, then with a 40ft, the with a 20 ft container. The 40ft container could be unloaded, generating a "hole" of 40ft, that eventually can be filled with two 20ft containers. And so on.
Another feature now is that, as announced, the container list present in a wagon can be defined in the .con file. This way the same .wag file can be used to carry different container combinations.
The possibility to define in the .wag file the containers present is still available in a simplified way, because wagon developers could prefer it. The two load definition methods can co-exist in the same consist.
Here an example of an entry in the .con file(I have used Peter's suggestion):

		Wagon (
			WagonData ( DTTX_620040_A ATW.DTTX_620040 )
			LoadData ( 20cmacgm common.containerdata CenterFront)
			LoadData ( 20hamburgsud common.containerdata CenterRear)
			LoadData ( 40msc common.containerdata Above)			
			UiD ( 11 )
		)

So this doublestacker has two 20ft containers below and a 40ft container above. The three parameters for each LoadData entry are the name of the load (container) description file, its folder within Trainset, and the position of the container in the wagon. Possible positions are Rear, CenterRear, Center, CenterFront, Front, Above.
The load description file has a .loa extension and is a simple Json file. Here an example of file 20cmacgm.loa:

{
	"Container": 
	{
		"Name" : "cmacgm",
		"Shape" : "COMMON.FREIGHT_Sgns/Sgns_0-20-0-001.s",
		"ContainerType" : "C20ft",
		"IntrinsicShapeOffset": [0, 1.17, 0],
	}
}

The IntrinsicShapeOffset X, Y and Z are the coordinates (within the container's shape file) of the center of the bottom face of the container (the one that lays on the wagon). Unfortunately in many existing container shapes the coordinates of this point are not 0, 0, 0.

To the .wag file following lines must be added

		ORTSFreightAnims (
		MSTSFreightAnimEnabled ( 0 )
		WagonEmptyWeight( 12.575t )
		EmptyMaxBrakeForce ( 47kN )
		EmptyMaxHandbrakeForce ( 15kN )
		EmptyORTSDavis_A ( 465.8 )
		EmptyORTSDavis_B ( 3.2 )
		EmptyORTSDavis_C ( 0.9942 )
		EmptyCentreOfGravity_Y ( 2.02 )
		IsGondola ( 0 )
		UnloadingStartDelay ( 2 )
		LoadingEndDelay ( 2 )
		LoadingAreaLength ( 14.6 )
		AboveLoadingAreaLength ( 16.15 )
		DoubleStacker ()
		Offset( 0 0.34 0 )
		IntakePoint ( 0 6.0 Container)
		)

which are the general FreightAnimation parameters, independent from the specific container load present.
(The physical parameters up to EmptyCentreOfGravity_Y ( 2.02 ) might be fully wrong for this type of wagon).
LoadingAreaLength and AboveLoadingAreaLength are the length in meters of the area available for the container load.
DoubleStacker means that the wagon can carry stacked containers.
The Offset is the offset within the .s file of the center point of the loading area.
Offset.Z is always equal to the first parameter of IntakePoint.

Here instead an example of the part needed in a .wag file with "pre-loaded" containers:

	ORTSFreightAnims (
		MSTSFreightAnimEnabled ( 0 )
		WagonEmptyWeight( 21.5t )
		EmptyMaxBrakeForce ( 47kN )
		EmptyMaxHandbrakeForce ( 15kN )
		EmptyORTSDavis_A ( 465.8 )
		EmptyORTSDavis_B ( 3.2 )
		EmptyORTSDavis_C ( 0.9942 )
		EmptyCentreOfGravity_Y ( 2.02 )
		IsGondola ( 0 )
		UnloadingStartDelay ( 2 )
		LoadingEndDelay ( 2 )
		IntakePoint ( -0.15 6.0 Container)
		LoadingAreaLength ( 12.19 )
		Offset (0 1.215, -0.15)

		FreightAnimStatic (
            			SubType( Default )
			FreightWeight( 0.01t )
			Shape( "..\\COMMON_Container_3d\\FA-Sggrss_576\\CZ-MT-Sggrss_579_40FA-A.s" )
			Offset( 0.0, 0.0, 0.0 )
            			Flip ( 0 )
        			)
		LoadData ( 40HCmaersk common.containerdata Center)
		)

As can be seen, the general part has the same data as the first example, then there is a static freightanim (nothing has changed for them), and then there may be one or more LoadData entries, that have the same format as the ones in the .con file.

All this now seems to work here, and I'll provide to the small developer group of this feature a new Test environment.
By the way Laci's container gantry was integrated in the test route and is working too with this feature.

There is another design and coding area now that requires significant upgrading, which is the allocation logic within the Container handling areas (and which hasn't changed up to now). Now there is no check on container length, which is not an issue if only 40ft containers are managed (which is indeed the most common case), but if there is a mixture of lengths, one should avoid that a 40ft container is stacked over a 20ft container. Also movements between wagons and stacking areas should be at least partially optimized. Furthermore it should be possible to "pre-load" container stations with containers.

When this task will be finished (no idea about the time needed) the feature can go public.