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

[Aldarion]

superb! This really adds to realisme and contributes to having a living railway system.

[Csantucci]

The package is now complete and will be provided to the small development group, and after few days it is foreseen to integrate it into ORNYMG and OR Unstable.

First of all here, by courtesy of QJ-6811, I attach a picture that explains the meaning of the various positions where a container can be laid down in a wagon

http://www.elvastower.com/forums/uploads/monthly_05_2022/msg-9011-0-10727000-1653154134_thumb.jpg

The calls to the load physics methods have been inserted.

And now to the further specs for the container stations.
Here
 w-005354+014849.zip (640bytes)
Number of downloads: 244
a sample extension file for the container stations (which are a subclass of the standard pickup items) is available.
UiD must correspond to the base UiD of the pickup in the base .w file;
ORTSMaxStackedContainers ( 2 ) is the maximum permitted number of stacked containers;
ORTSStackLocationsLength ( 12.19 ) is the length of the stack locations.
The various stack locations may have following parameters:
StackLocation (
Position ( -10 0 26 )
Length ( 15.0 )
MaxStackedContainers ( 1 )
Flipped ( 1 )
)
Position is mandatory, and, in case Flipped ( 1 ) is not present, is the position of the center of the area side with the lower Z coordinate (that is it extends towards growing Z). If the Flipped ( 1 ) line is present, it is the position of the center of the area side with the higher Z coordinate (that is it extends towards reducing Z).
Length is optional and can override the general ORTSStackLocationsLength.
MaxStackedContainers is optional and can override the general ORTSMaxStackedContainers.
If ORTSStackLocationsLength is higher or equal to 12.19 m (which is the length of a 40ft container), OR can dynamically split it in two parts, to allocate two 20ft containers at each "floor" instead of one 40ft container. If the couple of 20ft containers are later loaded on the train, the two parts are again merged together for a 40ft container (but can also be split again).
ORTSPickingSurfaceYOffset is the offset of the face of the "grabber" that enters in contact with the container when loading and unloading. The offset is relative to the 0 of the container station (crane) shape.
ORTSPickingSurfaceRelativeTopStartPosition is the offset (with relative to the 0 of the container station shape) where the crane stays at startup.
ORTSGrabberArmsParts ( 2 or a multiple of it) indicates the total number of animation entries for the grabber.
ORTSCraneSound contains the name of the crane sound, which must stay in the route's SOUND folder.

It is now possible to pre-load the container stations with containers.
This is done with a Json file. Here an example

 ContainerStationPopulation.zip (472bytes)
Number of downloads: 254
The file has a .lso (LoadStationOccupancy) .lsp (LoadStationPopulation) extension.
The format of the file is self-explaining.
The file must reside within an Openrails subfolder of the Activities folder of the route.
It must be recalled by activities by adding at end of the activity header following line

		ORTSLoadStationsOccupancy ( ContainerStationOccupancy )

		ORTSLoadStationsPopulation ( ContainerStationPopulation )

The selection of the sequence of the wagons to load/unload and of the related stack locations has now been improved. The train is now orderly loaded/unloaded starting from the first wagon and proceeding down the train. The related stack location selected is the one which is nearest to the wagon, in order to avoid crane runs back and forth along the Z axis.

The code should also have solved some fine-positioning issues that were noticed by QJ-6811, which also optimized some offset parameters.


And now some pictures to clarify the above specs.
Here some containers are present from game start in Aldarion's container station. As can be seen, the 20ft containers are stacked in couples.


Such containers can obviously loaded on the train.


The container station can be emptied, by loading the remaining empty wagons.


The loaded train can now proceed and reaches a second, bigger container station, which is also pre-loaded with some containers.


This great container station, which is also pre-loaded with some containers through the above .lso file, has been developed by Laci1959.



The train can be fully unloaded in this container station

[vapor3D]

:shock6: :shock6: :shock6: :shock6: :shock6: :shock6:

Superb work!!!

[Laci1959]

VAPOR3D, on 28 May 2022 - 10:09 AM, said:

:shock6: :shock6: :shock6: :shock6: :shock6: :shock6:

Superb work!!!

I have winterized since then, the rainy texts failed unfortunately.
I need to compile another installation "manual".

[Csantucci]

Thanks to the test containers that David Rowe kindly sent me, I could now also run 45ft, 48ft and 53ft containers, completing the palette of the most used countainers. Laci's crane adapts now from 53 to 20ft containers, see pictures.



Various stacking combinations were tested too, see picture.


Laci's container station now begins to be well occupied when the train is fully unloaded, see picture...