Container management
#12
Posted 16 April 2022 - 09:48 PM
Firstly this sounds like a terrific new innovation for OR.
Is it possible to set up other types of loads, say such as unloading/loading a series of logs, special loads, such as boilers, transformers, etc using the same approach?
Csantucci, on 16 April 2022 - 07:51 AM, said:
Container shapes must obviously be standalone shapes.
I am assuming that you are creating a WAG file for each container?
Thus you are then loading two wagons in the "same" location in OR, ie piggy backing one WAG file over the top of another. Have I understood this correctly?
If so I would suggest that we may need to create a "new" wagon type, as discussed in this thread. This will enable correct handling of the wagon physics, rather then users trying to set up "dodgy" WAG files as a work around to get the two WAG files to "work" as a single wagon.
Whilst the structure described in this thread has not been implemented yet, it would be good that any changes that you make lend themselves to be incorporated with minimal effort when done.
#13
Posted 16 April 2022 - 10:24 PM
These are containers with special parts on their corners for being processed by spreaders automatically, iron things, or packets, which can be handled with magnets and, maybe, packs of logs, as Peter mentioned, which can be handled with a kind of calipers.
Other freight is need to be properly tied, hung, unhung, untied and fixed on platform.
Hence, given approach, looking very good with containers, will be very simplified and unprototipical with wide variety of other freight.
Especially, ones with asymmetrical center of gravity.
#14
Posted 17 April 2022 - 12:14 AM
at the moment I will stick with containers.
Re your other point, containers are not .wag files, but at the moment are inserted as part of a freight animation within a wagon. So I don't see issues related to articulated wagons or their new strictures.
I am rather thinking to create a new type of file (e.g. a .loa file) that contains the data for a container. Initial associations between wagons and containers could be inserted in the .con file. This way it is not necessary to create a separate .wag file for each wagon-container couple.
I think this is something that has been sketched in Amtrak115 post.
#15
Posted 17 April 2022 - 04:17 PM
Richard
#16
Posted 17 April 2022 - 11:26 PM
sorry for the question but once released will it be inserted in the "MG" or in the "unstable" version?
Edoardo
#17
Posted 18 April 2022 - 12:04 AM
Csantucci, on 17 April 2022 - 12:14 AM, said:
at the moment I will stick with containers.
Re your other point, containers are not .wag files, but at the moment are inserted as part of a freight animation within a wagon. So I don't see issues related to articulated wagons or their new strictures.
I am rather thinking to create a new type of file (e.g. a .loa file) that contains the data for a container. Initial associations between wagons and containers could be inserted in the .con file. This way it is not necessary to create a separate .wag file for each wagon-container couple.
I think this is something that has been sketched in Amtrak115 post.
Hello.
Using multiple FreightAnimDiscrete blocks is not a viable option? Would you really complicate the code or the wag file, i.e. the ORTSFreightAnims block?
Sincerely, Laci 1959
#18
Posted 18 April 2022 - 11:55 AM
this will first appear in ORNYMG and then, when both the Blueprint is approved and the code is sufficiently stable, also in the Unstable release.
Laci,
sorry but I dont' understand well your question. What do you do with multiple FreightAnimDiscrete blocks? Why should the ORTSFreightAnims block be complicated in my solution?
#19
Posted 18 April 2022 - 01:18 PM
ORTSFreightAnims ( MSTSFreightAnimEnabled ( 0 ) WagonEmptyWeight( 12.575t ) comment ( az üres kocsi tömege, továbbiakban minden bejegyzés az üres kocsira vonatkozik ) EmptyMaxBrakeForce ( 47kN ) comment ( fékerő ) EmptyMaxHandbrakeForce ( 15kN ) comment ( kézifék ereje ) EmptyORTSDavis_A ( 465.8 ) comment ( gördülési ellenállás ) EmptyORTSDavis_B ( 3.2 ) comment ( gördülési ellenállás ) EmptyORTSDavis_C ( 0.9942 ) comment ( gördülési ellenállás ) EmptyCentreOfGravity_Y ( 2.02 ) comment ( súlypont ) IsGondola ( 0 ) comment ( nem buktatással ürít ) UnloadingStartDelay ( 2 ) comment ( kirakodás megkezdésének a késleltetése ) LoadingEndDelay ( 2 ) comment ( berakodás megkezdésének a késleltetése ) FreightAnimDiscrete ( comment ( a rakodás típusa ) IntakePoint ( 3.07937 6.0 Container ) comment ( alul külön részletezve ) FreightWeightWhenFull ( 26.7t ) comment ( a rakomány tömege, továbbiakban minden bejegyzés a rakott kocsira vonatkozik ) LoadedAtStart ( 1 ) comment ( a játék indulásakor rakott, az üres kocsinál ez 0 ) FullMaxBrakeForce ( 112kN ) comment ( fékerő, továbbiakban minden bejegyzés az rakott kocsira vonatkozik ) FullMaxHandbrakeForce ( 35kN ) comment ( kézifék ereje ) FullORTSDavis_A ( 793.1 ) comment ( gördülési ellenállás ) FullORTSDavis_B ( 10.52 ) comment ( gördülési ellenállás ) FullORTSDavis_C ( 0.9942 ) comment ( gördülési ellenállás ) FullCentreOfGravity_Y ( 1.72 ) comment ( súlypont ) Offset( 0.0, 0.0, 0.0 ) comment ( elvileg a rakomány pozíciója, szerintem ide nem kell ) Container ( Shape( "../COMMON.FREIGHT/Container/Hapag-Loyd_40ft.s" ) comment ( a felvehető konténer shape neve ) ContainerType ( C40ftHC ) comment ( a felrakható konténer típusa, alul külön részletezve ) IntrinsicShapeOffset ( 0 1.17 3.07937 ) comment ( a konténer pivotpontjának az eltolása, alul külön részletezve ) Flip ( 0 ) comment ( a kontérer megfordítása 180 fokkal ) ) ) FreightAnimDiscrete ( comment ( a rakodás típusa ) IntakePoint ( 3.07937 6.0 Container ) comment ( alul külön részletezve ) FreightWeightWhenFull ( 26.7t ) comment ( a rakomány tömege, továbbiakban minden bejegyzés a rakott kocsira vonatkozik ) LoadedAtStart ( 1 ) comment ( a játék indulásakor rakott, az üres kocsinál ez 0 ) FullMaxBrakeForce ( 112kN ) comment ( fékerő, továbbiakban minden bejegyzés az rakott kocsira vonatkozik ) FullMaxHandbrakeForce ( 35kN ) comment ( kézifék ereje ) FullORTSDavis_A ( 793.1 ) comment ( gördülési ellenállás ) FullORTSDavis_B ( 10.52 ) comment ( gördülési ellenállás ) FullORTSDavis_C ( 0.9942 ) comment ( gördülési ellenállás ) FullCentreOfGravity_Y ( 1.72 ) comment ( súlypont ) Offset( 0.0, 0.0, 0.0 ) comment ( elvileg a rakomány pozíciója, szerintem ide nem kell ) Container ( Shape( "../COMMON.FREIGHT/Container/Maersk_40ft.s" ) comment ( a felvehető konténer shape neve ) ContainerType ( C40ftHC ) comment ( a felrakható konténer típusa, alul külön részletezve ) IntrinsicShapeOffset ( 0 1.17 3.07937 ) comment ( a konténer pivotpontjának az eltolása, alul külön részletezve ) Flip ( 0 ) comment ( a kontérer megfordítása 180 fokkal ) ) ) )
Hello.
I apologize for the comments in Hungarian, but I will provide detailed explanations for other users.
There are two FreightAnimDiscrete blocks, one with a Hapag-Loyd 40ft and the other with a Maersk 40ft container.
I think he puts it on the car he finds first in the loading area. Of course, he takes it down and places it in the loading area for what he finds on the car.
Now that I’m writing this, comes the realization of what happens if you can’t find any of them.
Maybe it was a bad idea?
Sincerely, Laci 1959
#20
Posted 18 April 2022 - 10:00 PM
Thanks for the feedback.
Csantucci, on 17 April 2022 - 12:14 AM, said:
I am rather thinking to create a new type of file (e.g. a .loa file) that contains the data for a container. Initial associations between wagons and containers could be inserted in the .con file. This way it is not necessary to create a separate .wag file for each wagon-container couple.
I think this is something that has been sketched in Amtrak115 post.
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.