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.