[Traindude]

I would also like to add that my proposal also facilitates alternate naming of wheels and axles (so we aren't bound by the current constraints). In the 1910s in the United States, there were some very...interesting to say the least...articulated locomotives with 10 or more driving axles...

Example # 1: Santa Fe 3000-class 2-10-10-2:
https://loco.skyrocket.de/img/atsf__3000__3000__1.jpg



Example # 2: Erie Triplex 2-8-8-8-2:
https://loco.skyrocket.de/img/erie_p1.jpg


You'll notice in both examples, I treated the 10th, 11th and 12th driving axles in a hexadecimal manner. So we could potentially have up to 16 drive axles if we wanted.

[cjakeman]

Traindude, on 10 July 2024 - 01:03 PM, said:

Hi everybody. In an attempt to overcome the limitations of the MSTS-era models, I began thinking of an alternative method of defining wheels, axles and bogies/trucks for locomotives and rolling stock. Some of the goals I am trying to achieve include:

Are there any objections to TrainDude's proposal?

Does it cover all cases we know of?

[Eldorado.Railroad]

cjakeman, on 20 July 2024 - 02:40 AM, said:

Are there any objections to TrainDude's proposal?

Does it cover all cases we know of?

From what I can see in the O/P, we are going to "wheels within wheels", as far as animation parlance is concerned!!

Whereas, in a cursory way I can see what this change is trying to accomplish, I can also see a huge mess of work for the modeller to get things to animate properly.

So three points here:

1) I have models that do use the builtin pre-animated names to animate things like fans. Are those animations going to be broken with these changes and why?

2) Given 1) I hope, really hope, that this new way of doing things is SEVERELY tested before we decide to put it in production, where bugs will break, what was already working..for well over a decade. It is tiresome to have new features added to OR that breaks what was working well after it has been decided that it was going to be included in the mainline code. I am sure I am not the only one holding back on using newer releases as it severely disrupts users workflows.

3) Also connected to 1), as an example cooling fans, if you are willing to put in all that work to simulate animations of bogies and wheels in the .eng file, why not add animations for cooling fans, dynamic brake fans, that are triggered ON/OFF etc by parameters in the .eng file?

I have a lot of model work that used the old ways of doing things, which I would not like to end up in the garbage with these changes. Some payware vendors are still having trouble with the old ways of doing things with the Blender exporter, so I have seen/noted! Getting them to do stuff in the new ways will be a bit of a stretch. A utility to streamline the entry of the NEW parameters in the .eng file will make life easier for the few payware modellers we have left. Hobbyists will struggle with these new parameters for a great deal of time.

thanks,
Steve

[Laci1959]

Hello.

I read the description once again (it has to be translated, and it goes slowly), and I add two Hungarian locomotives. What I can already see is that the definition of the pivot point of the bogies is missing. ORTSLengthBogieCentre is only acceptable if the vehicle has a perfectly symmetrical structure. I think that in some cases it is necessary to define the center of the bogies individually in the Bogie ( ) block. Let's not fall into OR's current mistake.
In Hungary, unfortunately, the minutes of the factory weighing are not available in all cases. In this case, if ORTSWheelWeight is missing, it uses the value of the currently used ORTSDriveWheelWeight ( ) and ORTSNumberDriveAxles ( ) line, if specified.

Sincerely, Laci 1959

[pschlik]

Eldorado.Railroad, on 20 July 2024 - 06:02 AM, said:

3) Also connected to 1), as an example cooling fans, if you are willing to put in all that work to simulate animations of bogies and wheels in the .eng file, why not add animations for cooling fans, dynamic brake fans, that are triggered ON/OFF etc by parameters in the .eng file?

I have some general improvements to the diesel engine model that are required before we start to consider things like electric motor simulation, and a rework of engine cooling would be part of that so there is sufficient information to trigger animated fans. This would come along with naming changes that would allow these to not be confused with wheels.

In terms of supporting older models which did define fans as wheels, we'd benefit from some .eng parameters to allow manipulating the shape file from the .eng file so users don't need to uncompress and manually edit shapes as much. Something like "ORTSReplaceHierarchy( "ROD01, RADIATORFAN1" )" to tell the shape file (in code, not in real life) to rename the relevant object, and the rest of the program will be none the wiser that the radiator fan was originally implemented as a connecting rod. (Similar could be done for shape textures to make reskins easier, I'm sure many people out there would much rather not do shape file editing for a pack of 20 reskins!)

[Traindude]

Eldorado.Railroad, on 20 July 2024 - 06:02 AM, said:

From what I can see in the O/P, we are going to "wheels within wheels", as far as animation parlance is concerned!!

Whereas, in a cursory way I can see what this change is trying to accomplish, I can also see a huge mess of work for the modeller to get things to animate properly.

So three points here:

1) I have models that do use the builtin pre-animated names to animate things like fans. Are those animations going to be broken with these changes and why?

2) Given 1) I hope, really hope, that this new way of doing things is SEVERELY tested before we decide to put it in production, where bugs will break, what was already working..for well over a decade. It is tiresome to have new features added to OR that breaks what was working well after it has been decided that it was going to be included in the mainline code. I am sure I am not the only one holding back on using newer releases as it severely disrupts users workflows.

3) Also connected to 1), as an example cooling fans, if you are willing to put in all that work to simulate animations of bogies and wheels in the .eng file, why not add animations for cooling fans, dynamic brake fans, that are triggered ON/OFF etc by parameters in the .eng file?

I have a lot of model work that used the old ways of doing things, which I would not like to end up in the garbage with these changes. Some payware vendors are still having trouble with the old ways of doing things with the Blender exporter, so I have seen/noted! Getting them to do stuff in the new ways will be a bit of a stretch. A utility to streamline the entry of the NEW parameters in the .eng file will make life easier for the few payware modellers we have left. Hobbyists will struggle with these new parameters for a great deal of time.

thanks,
Steve

In the case of the fans, my intention was to prevent ORTS from being misled into thinking that the fans contribute to the vehicle's wheelbase, and consequently thinking that the vehicle has more axles than it actually does.

Take for example, an SD40-2:

https://www.rr-fallenflags.org/manual/e20773.jpg

It has three radiator fans and two dynamic brake fans. In order to make them animate in sync with the movement of the train, you'd name them WHEELSx. Now, the "real" wheel arrangement of the locomotive is a C-C (or Co-Co for anyone outside North America). Theoretically, the Consist Info section of the extended HUD should show 6-6 as the wheel count. However, when ORTS looks at the shape file hierarchy and "sees" the "fans" as additional "wheels", it may be misled into thinking the wheel arrangement is actually 6-10-6 instead of the correct 6-6.

To prevent this, my proposal was to define only the "real" wheels in the axle count, so it's properly displayed as 6-6, and excludes the animated "fans" from being misinterpreted as being part of the locomotive's wheelbase, and thus prevents the game from thinking the locomotive has more axles than it actually does.

IOW, the fans would still animate in sync with the locomotive speed, but would be excluded from the wheelbase definition in the *.eng file, so ORTS treats the locomotive as having its true C-C wheel arrangement.

[James Ross]

Traindude, on 10 July 2024 - 01:03 PM, said:

Hi everybody. In an attempt to overcome the limitations of the MSTS-era models, I began thinking of an alternative method of defining wheels, axles and bogies/trucks for locomotives and rolling stock. Some of the goals I am trying to achieve include:
...
What do you guys think? Let me know!

Thanks for taking the time to improve the axle situation!

I have no comments on the functional design (seems fine to me but I am not a modeller or knowledgeable about locomotive axles), but one small detail stood out to me: which items have "ORTS" prefixes to their name.

IIRC, we typically only prefix the top-level new blocks, "WheelBase" in this proposal AIUI, and not any sub-blocks inside the new block. Alternatively, we could prefix everything.

I don't believe there is any good code reason to keep the prefixes on the sub-blocks, even if they are used elsewhere, because the code looks at the whole block-path (e.g. "engine(enginecontrollers(ortssmallejector"), but do let me know if there are specific reasons for this naming.

[Traindude]

James Ross, on 07 August 2024 - 10:04 AM, said:

Thanks for taking the time to improve the axle situation!

I have no comments on the functional design (seems fine to me but I am not a modeller or knowledgeable about locomotive axles), but one small detail stood out to me: which items have "ORTS" prefixes to their name.

IIRC, we typically only prefix the top-level new blocks, "WheelBase" in this proposal AIUI, and not any sub-blocks inside the new block. Alternatively, we could prefix everything.

I don't believe there is any good code reason to keep the prefixes on the sub-blocks, even if they are used elsewhere, because the code looks at the whole block-path (e.g. "engine(enginecontrollers(ortssmallejector"), but do let me know if there are specific reasons for this naming.

The inconsistencies in the prefixing the parameters with ORTS were by no means intentional. I agree that there needs to be a way to differentiate ORTS-exclusive parameters from "traditional" MSTS parameters, but I was just illustrating how my "newly proposed" parameters would be integrated with pre-existing ORTS parameters.