[Laci1959]

Quote

It could within reason fit in with the "articulated" wagons structures as it is potentially a load spanning two sets of axles.

Hello Mr steamer_ctn.

I know it's Off, so I'm sorry. Where is the sample for that car. I’ve been trying to put it together for a long time and I can’t. It does not move in the curves as it should. It is true that it rests on the three bogie. Could this be a mistake?

Sincerely, Laci 1959

[Csantucci]

steamer_ctn, on 18 April 2022 - 10:00 PM, said:

Hi Carlo,

Thanks for the feedback.


Will different scenarios, such as single and double stacked containers be done with the "freight animation" approach that you are using? Can the physics vary depending upon how many containers are added?

It could within reason fit in with the "articulated" wagons structures as it is potentially a load spanning two sets of axles.

We should also need to consider the impact on the CON file, as at the moment they are set up to accept WAG and ENG files.

Also, as you are proposing a new potential file, it might be worthwhile to start a thread in the developers forum to seek further architectural input, and hence reduce any rework that future architectural changes could impose on your work.

Hi Petee,
yes, double stacked containers in trains are foreseen. The physics should vary, but I won't work on this. Once the function is consolidated, I'd prefer that someone else (You know whom I'm thinking about...) inserts the needed code additions.

[steamer_ctn]

Laci1959, on 18 April 2022 - 10:55 PM, said:

I know it's Off, so I'm sorry. Where is the sample for that car. I’ve been trying to put it together for a long time and I can’t. It does not move in the curves as it should. It is true that it rests on the three bogie. Could this be a mistake?

I was merely pointing out an architectural discussion that have been taking place to facillitate multiple cars to be "combined" into an articulated (combined) car from a physics perspective. At the moment this feature does not currently exist in OR.

Csantucci, on 19 April 2022 - 07:49 AM, said:

yes, double stacked containers in trains are foreseen. The physics should vary, but I won't work on this. Once the function is consolidated, I'd prefer that someone else (You know whom I'm thinking about...) inserts the needed code additions.

Thanks for the feedback on the double stacked containers.

I am happy to have a look at the physics for you.

However I would still like to see a discussion thread in the developers forum to get broader input on architectural structures, especially as these changes may impact on the CON files, and also in creating a new LOA file. Ideally it should be part of a bigger picture view.

From a physics perspective, this change is similar to the "articulated" wagon whereby they are both creating a "consolidated" wagon from multiple WAG (or LOA) files, and therefore managing the consolidated wagon from a physics perspective may even use some of the same code.

[Laci1959]

Hello.

I have two questions.
1. Do I think the Z axis of the container crane is the same as the Z axis of the railway vehicle? At least parallel to av.
2. The animation consists of only 3 frames as in the example. This is compulsory? True, an animation of 3 cubes is simpler than an animation of 30 cubes. The cranes of the Budapest Intermodal Logistics Center are moving on a nearly 700-meter-long track. There are some restrictions on this.

I'm sorry to ask for nonsense, but I'm in an unfamiliar area.

https://kephost.net/p/2022/16/1684_7225e40d649c.png
I did it based on the characteristics of a Chinese container crane. It’s not exactly like BILK cranes, but I don’t think it will bother anyone.

Sincerely, Laci 1959

[Csantucci]

Hi,
great that you are developing that! The Z axis of the crane should coincide with the Z axis of the train, and the Z zero should be in the middle of the extension of the Z axis (not at one end!). Please have a long extension of the Z axis (at least 100 m)! This is more realistic. X should be at one of the two internal sides of the crane. To accommodate for the longer extension of the Z axis you can do something like this:

				anim_node ZAXIS (
					controllers ( 1
						linear_pos ( 3
							linear_key ( 0 0 0 -50 )
							linear_key ( 5 0 0 50 )
							linear_key ( 10 0 0 -50 )
						)
					)
				)

This way the Z movement is five times slower than the other two. (In reality the third linear_key line can be omitted).
If you want to add the cables to raise and lower the YAxis part that enters in contact with the wagon, they must be hierarchically dependent from YAxis.

[Laci1959]

Hello.

Thank you very much for your reply.
Helped a lot. I was thinking about parallelism. This is obviously the solution.

Quote

If you want to add the cables to raise and lower the YAxis part that enters in contact with the wagon, they must be hierarchically dependent from YAxis.

I'll cross this bridge when I get there. There is still a lot of work to be done.

Sincerely, Laci 1959

[Weter]

God to help You!

[Laci1959]

Thanks. And my two left hands.

[Csantucci]

First release of double stacking containers on wagons works, and if I have time I'll provide a short video. Aldarion provided a container crane with cables and with a grabber which varies its extension depending from the length of the container, and the controls for such animations have been introduced in the code and work. Moreover now it is no more needed to move the train for every container. It is now possible to perform load/unload operations for all wagons that are within the Z-movement range of the crane.

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.

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.

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

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.
Inserting the code to manage these insertions should not be a problem, and I think that this format is easily manageable by both activity creators and players.

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]

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

Yes, it is indeed mandatory.

Anyway, this is a terrific piece of work. Well done to everyone involved.