Container management
#32
Posted 28 April 2022 - 11:20 PM
Csantucci, on 28 April 2022 - 09:02 AM, said:
This new file could then be recalled from .act files, and also from timetable files, provided someone would implement this second link.
cjakeman, on 28 April 2022 - 11:51 AM, said:
What is the current OR policy for implementation of JSON format files? When will all old formats be converted over?
How will legacy files be handled, will OR always have to handle both file formats? Will there be some sort of incentive provided to encourage users to transition to JSON files?
My personal preference would be to see this new file as a "MSTS" format, as most users already are familiar with the layout, style and text format. It could then be converted over when all the other "MSTS" files are converted to JSON.
Whilst I agree that it maybe reasonable to be working towards a JSON format, I think that we need to consider all the implications of a JSON conversion, and develop an appropriate transition plan, rather the encouraging an ad-hoc mixture of MSTS Legacy files and JSON.
Csantucci, on 28 April 2022 - 09:02 AM, said:
To provide a base for the attaching of physics to this new loading/unloading concept lets think in terms of the following two physics scenarios (this is not all the physics that need to be considered, but acts as an example).
i) The first obvious one is the wagon weight (mass) that will need to vary as loads or added or subtracted. Naturally this will impact the tonnage capacity.
ii) Train Resistance - All Davis values will be impacted as the weight changes. In particular the Davis C value will be the most challenging (due to the change in air resistance), as it will vary from an empty wagon, to one or two containers single stacked, and containers double stacked. So how could we differentiate if the same container is added as a single stack or double stack?
So, I assume that you have already thought about the handling of wagons in MSTSWagon.cs and to ensure that we are on the same page, I believe we have two scenarios as follows:
i) In Game Addition / Subtraction of Load - Containers (or other loads) are loaded at a terminal and the physics is added or subtracted from the base wagon in MSTSWagon.cs as appropriate. One aspect that will need to be considered is how is the load linked to an articulated wagon consist, eg 5 pack container cars? Hence the need to consider a "bigger" picture view of loading and articulated wagons.
ii) Game Initialisation - Train consist is built, and loads are added to MSTSWagon.cs
Are these the options that you have considered?
Hence, on the above basis I agree with your concept of creating a LOA file for every discrete load. Some thought will need to be given to the parameters defined in this file, so that only the required parameters are required.
I also think that using a ACT file or Timetable file as a means for providing a pool of containers (or loads) at a site seems a reasonable approach. For the ACT file I would suggest that they should either be able to be included directly into the ACT file, or alternatively via an INC file (my preferred solution). When the activity initially starts how will it physically locate the containers at the loading site. Will the user need to put in a location reference point similar to the loose consist concept?
Csantucci, on 28 April 2022 - 09:02 AM, said:
Csantucci, on 28 April 2022 - 09:02 AM, said:
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) ) ... ) ...
For a start I would prefer to see Container renamed to Load, as this will allow future extension of this work beyond containers without needing to change input file formats.
Again I think that it should be possible to either add the statements directly to the CON file, or as a preferred solution via an INC file.
Is it possible to use a more abbreviated coding input? Perhaps something like the following:
LoadData ( UiD Load File Load Directory Load Alignment )
Which using your example might look something like this:
LoadData ( 6 20cmacgm common.containerdata CenterFront )
Thus reducing a number of lines into one line, and also allowing it to be placed anywhere in the file or in an INC file. It also maintains a similar format to WagonData, etc.
Csantucci, on 28 April 2022 - 09:02 AM, said:
Center alignment is default.
#33
Posted 29 April 2022 - 12:01 AM
thank you for your contribution.
I start answering your last question.
Rear means that the container is aligned with the rear end of the wagon's loading area;
CenterRear means that the container has one side aligned with the center of the wagon's loading area, and extends towards the rear of the wagon;
Centerfront means that the container has one side aligned with the center of the wagon's loading area, and extends towards the front of the wagon;
Front means that the container is aligned with the front end of the wagon's loading area;
Center means the the container has middle point of the Z axis coinciding with the center of the wagon's loading area;
Above means that it is a container laying on the "second floor". It is intended that on the "second floor" there is only one container, and that it is aligned to the center of the wagon's loading area.
This should cover practically all combinations that can be seen. If a 2% doesn't enter in this classification, I won't care about that.
About file formats, I too would prefer to keep an MSTS format here to avoid mixtures (container data are needed in .con files, in .wag files and in the file related to the loading areas). In general however I prefer a co-existence of the two file formats and not a complete switchover.
Re the identification of the loading areas (which are always related to a pickup point), this would occur as it is with the turntable file now, that is world file name and UiD within such world file of the related pickup.
#34
Posted 29 April 2022 - 01:00 AM
Quote
Hello.
I would like to add to this and above that the average content creator and user has not even heard of the JSon format.
What's next? Will they go away forever or get stuck on a current version, giving up on future changes?
Maybe you are making some simple easy to use graphical converter?
Peter's points (i) and (ii) only to the extent that this has already been partially resolved or not? I am thinking of the FreightAnimContinuous block that was introduced earlier.
There is so much truth in it that the 20hamburgsud.inc file in the path path Include ("..//..//common.containerdata//20hamburgsud.inc") must somehow include the weight of the container. It had been raised in me before, I just didn’t want to lead it out yet.
Sincerely, Laci 1959
#35
Posted 29 April 2022 - 01:06 AM
LoadData ( UiD Load File Load Directory Load Alignment )
Hello.
The UID () line above the ContainerData line was introduced by MSTS, as was the line above it. I don't know if OR is using it now. If you don’t use it, I think Carlo typed it out of habit, the way I still use it out of habit.
Sincerely, Laci 1959
#37
Posted 29 April 2022 - 11:42 PM
Thanks for the additional feedback.
Csantucci, on 29 April 2022 - 12:01 AM, said:
CenterRear means that the container has one side aligned with the center of the wagon's loading area, and extends towards the rear of the wagon;
Centerfront means that the container has one side aligned with the center of the wagon's loading area, and extends towards the front of the wagon;
Front means that the container is aligned with the front end of the wagon's loading area;
Center means the the container has middle point of the Z axis coinciding with the center of the wagon's loading area;
Above means that it is a container laying on the "second floor". It is intended that on the "second floor" there is only one container, and that it is aligned to the center of the wagon's loading area.
Is the loading point reference included in the wagon WAG file as a reference point, much the same as the "water" or "coal" intake point? This type of approach would provide a more accurate reference point then trying to calculate a reference point off the wagon Size parameter which is never accurate enough. This approach would also allow some configurations to not be used on this type of wagon. For example if CentreRear is not reference then a load could not be assigned to this position on the car.
So would a user insert a statement something like the following into the WAG file?
LoadPoint ( 1.759 10 Rear )
Csantucci, on 29 April 2022 - 12:01 AM, said:
Thanks for your feedback on this. I am also hoping that the ORMT will provide some input on this discussion as well.
In regards to the different files co-existing, I suspect that they may co-exist forever, unless we have a transition plan defined. My point was more about ensuring that we don't have different formats for different files. My thinking is that if MSTS format is going to be retained, then it should be available for all files, similarly if JSON is used then all files should be in JSON. I would be disappointed to see a mix where one file type is in JSON, and another file type is in MSTS. To me it is all about consistency and ease of user (within reasonable bounds) for the content provider.
Csantucci, on 29 April 2022 - 12:01 AM, said:
So say that we want to have 60 containers in a dump ready to be loaded, then how would we specify how they are to be placed in game? All on top of each other? In neat rows, etc?
#38
Posted 30 April 2022 - 08:29 PM
LoadPhysicsInitialisation () - This would perhaps be located in TrainCar.cs(?) and would be called whenever a wagon is initialised with a load module. Relevant physics would be added to the base wagons physics as appropriate.
UpdateLoadPhysics () - This would be called every time a load was added or removed from the base car. It would adjust the wagon physics as appropriate for changes to the load.
WDYT?
#39
Posted 01 May 2022 - 07:08 AM
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.
#40
Posted 02 May 2022 - 11:34 AM
steamer_ctn, on 28 April 2022 - 11:20 PM, said:
How will legacy files be handled, will OR always have to handle both file formats? Will there be some sort of incentive provided to encourage users to transition to JSON files?
My personal preference would be to see this new file as a "MSTS" format, as most users already are familiar with the layout, style and text format. It could then be converted over when all the other "MSTS" files are converted to JSON.
A new thread has been started for this discussion in the private forum Open Rails Development > Features > All other features