Pantograph problems: OR does not recognize extended pantograph animations

[GoGoran]

I am currently trying to get an electric locomotive with extended pantograph animations to work within OR, but it looks like OR does not know these codes as of yet.

For better understanding, I post an excerpt from the uncompressed shape file, listing the matrices - the relevant ones which I am referring to are boldened:

matrices ( 27
matrix MAIN ( 1 0 0 0 1 0 0 0 1 0 0 0 )
matrix PANTOGRAPHBOTTOM1A ( 1 0 0 0 1 0 0 0 1 0 4.11 3.86608 )
matrix PANTOGRAPHMIDDLE1A ( 1 0 0 0 1 0 0 0 1 0 0.0790277 -1.18253 )
matrix PANTOGRAPHTOP1A ( 1 0 0 0 1 0 0 0 1 0 0.17645 1.63478 )
matrix P1_ANI_11 ( 1 0 0 0 1 0 0 0 1 0 0.0849996 -0.0427501 )
matrix P1_ANI_21 ( 1 0 0 0 1 0 0 0 1 -0.109965 0.0780935 -0.0777683 )
matrix PANTOGRAPHBOTTOM1A_1 ( 1 0 0 0 1 0 0 0 1 0 4.11 -4.76435 )
matrix PANTOGRAPHMIDDLE1A_1 ( 1 0 0 0 1 0 0 0 1 0 0.07903 -1.18506 )
matrix PANTOGRAPHTOP1A_1 ( 1 0 0 0 1 0 0 0 1 0 0.17645 1.63108 )
matrix P2_ANI_11 ( 1 0 0 0 1 0 0 0 1 0 0.0849996 -0.0427499 )
matrix P2_ANI_21 ( 1 0 0 0 1 0 0 0 1 -0.109965 0.0700297 -0.0777702 )
matrix PANTOGRAPHBOTTOM1B ( 1 0 0 0 1 0 0 0 1 0 4.11 4.76435 )
matrix PANTOGRAPHMIDDLE1B ( 1 0 0 0 1 0 0 0 1 0 0.079 1.18506 )
matrix P1_ANI_12 ( 1 0 0 0 1 0 0 0 1 0 0.0849996 0.0443201 )
matrix P1_ANI_22 ( 1 0 0 0 1 0 0 0 1 0.109968 0.0780954 0.07724 )
matrix PANTOGRAPHBOTTOM1B_1 ( 1 0 0 0 1 0 0 0 1 0 4.11 -3.86608 )
matrix PANTOGRAPHMIDDLE1B_1 ( 1 0 0 0 1 0 0 0 1 0 0.079 1.18253 )
matrix P2_ANI_12 ( 1 0 0 0 1 0 0 0 1 0 0.0849996 0.0443201 )
matrix P2_ANI_22 ( 1 0 0 0 1 0 0 0 1 0.109968 0.0699997 0.07724 )
matrix BOGIE1 ( 1 0 0 0 1 0 0 0 1 0 -0.06 4.91 )
matrix WHEELS13 ( 1 0 0 0 1 0 0 0 1 0 -0.01 -4.91 )
matrix WHEELS12 ( 1 0 0 0 1 0 0 0 1 0 -0.01 -4.91 )
matrix WHEELS11 ( 1 0 0 0 1 0 0 0 1 0 -0.01 -4.91 )
matrix BOGIE2 ( 1 0 0 0 1 0 0 0 1 0 -0.06 -4.91 )
matrix WHEELS21 ( 1 0 0 0 1 0 0 0 1 0 -0.01 4.91 )
matrix WHEELS22 ( 1 0 0 0 1 0 0 0 1 0 -0.01 4.91 )
matrix WHEELS23 ( 1 0 0 0 1 0 0 0 1 0 -0.01 4.91 )

The boldened parts do animate, but in a repetitive, non-stop and super-fast way.

In MSTS, they work as they should, as MSTS recognizes them as parts of the pantographs, and thus only animates them once, when the panto moves up, and a second time in the other direction, when the respective panto moves down again (when the player hits the P / Shift+P key).

So please, dear OR developpers, mark the P1_ANI_11 thru P2_ANI_22 codes for incorporation into a future release of OR.

Thank you.

PS: You may think about possible extensions of this system in OR, since some multi-current locomotives in Europe feature up to four different pantographs on a single locomotive, such as the new Austrian Taurus model 1216 of the OeBB (Austrian national railways). For a correct animation of such a model, four controllable pantographs would be needed, and correspondingly P1_ANI_11 thru P4_ANI_22.

PPS: While this model only features two extra animations tied to each main pantograph animations, you can easily imagine models with more than two such animations per pantograph, i.e. while you're at it, you could code e.g. P1_ANI_13, 14, 15, ... 23, 24, 25, ... 31, 32, 33, 34, ... etc. into the OR engine.

PPPS: Write me via PM to obtain the sample locomotive for testing and evaluating purposes with OR. A download link to the base model would be useless, since the base model got other issues which keep it from running in OR - see my other thread on this board explaining the problem and its solution: https://www.trainsim.com/vbts/showth...electric-locos
Of course you can make the explained adaptations by yourself in gmax, but why bother if you can get it ready-made from me ...

PPPPS: The animations in question are speed-sensitive in OR, i.e. in standstill, nothing animates, whereas the faster the loco runs, the quicker the animations work !

[longiron]

We will need to make coding changes to properly animate those parts labeled "P1_ANI_ .... P4_ANI" as they are animated like running gear. We are approaching a slipperly slope here. I'm not a fan of chasing every model builder's naming convention to properly animate parts within shape files. When we move to OR new shape/ENG files, there will be specific standards to which model builders will have to adhere for them to properly animate.

The following matrix names are explicitly used by the OR animation code. The first level of this list is the prefix which is checked, then any specifics are checked in the second level. n and m are 1-digit numbers. ... means a name can have any suffix.


WHEELS...
WHEELSn A fixed wheel on the car.
WHEELSmn A wheel on a bogie. m identifies which bogie it is attached to.


BOGIE...
BOGIEm A bogie. m identifies which bogie it is.


WIPER...
WIPERARMLEFT1 Wiper component.
WIPERBLADELEFT1 Wiper component.
WIPERARMRIGHT1 Wiper component.
WIPERBLADERIGHT1 Wiper component.


DOOR... or DEUR...
DOOR_A... Left-side door.
DOOR_B... Left-side door.
DOOR_C... Left-side door.
DOOR_D... Right-side door.
DOOR_E... Right-side door.
DOOR_F... Right-side door.
Otherwise, left-side door.


PANTOGRAPH...
PANTOGRAPHBOTTOM1 Front pantograph.
PANTOGRAPHBOTTOM1A Front pantograph.
PANTOGRAPHBOTTOM1B Front pantograph.
PANTOGRAPHMIDDLE1 Front pantograph.
PANTOGRAPHMIDDLE1A Front pantograph.
PANTOGRAPHMIDDLE1B Front pantograph.
PANTOGRAPHTOP1 Front pantograph.
PANTOGRAPHTOP1A Front pantograph.
PANTOGRAPHTOP1B Front pantograph.
PANTOGRAPHBOTTOM2 Rear pantograph.
PANTOGRAPHBOTTOM2A Rear pantograph.
PANTOGRAPHBOTTOM2B Rear pantograph.
PANTOGRAPHMIDDLE2 Rear pantograph.
PANTOGRAPHMIDDLE2A Rear pantograph.
PANTOGRAPHMIDDLE2B Rear pantograph.
PANTOGRAPHTOP2 Rear pantograph.
PANTOGRAPHTOP2A Rear pantograph.
PANTOGRAPHTOP2B Rear pantograph.


PANTO...
If it contains "1", front pantograph.
If it contains "2", rear pantograph.
Otherwise, ignored.


MIRROR...
MIRROR... Mirror component.


Anything else is animated as part of the running gear (rods, etc.).

[GoGoran]

I am under the impression that the above codes (P1_ANI_11 etc.) must be part of the default MSTS set of codes, and thus should be incorporated into OR, too. If they were not part of MSTS' codes set, they would not animate properly in MSTS, either. But they are clearly tied to the pantographs in MSTS.

[twpol]

I am under the impression that the above codes (P1_ANI_11 etc.) must be part of the default MSTS set of codes, and thus should be incorporated into OR, too. If they were not part of MSTS' codes set, they would not animate properly in MSTS, either. But they are clearly tied to the pantographs in MSTS.

Could they be MSTSBin extensions? I'm just curious, I see no reason not to support them in OR either way.

[GoGoran]

Could they be MSTSBin extensions? I'm just curious, I see no reason not to support them in OR either way.

Maybe, maybe not. At any rate, OR is meant to be fully backwards compatible and therefore it would just be plain wrong not to incorporate all MSTS and MSTS-Bin features, if it's technologically possible. The work involved in this particular case is not an issue, either, since it's not an overly complicated task, either - the codes just have to be properly registered as pantograph parts, and that's it.

[csantucci]

Longiron, thank you for the info about how OR interprets animation blocks. I point out a problem with door animation.
Practically all Bernina passenger rolling stock has animated doors. If I however try to open and close them with OR, then with key Q both left and right doors are opened/closed, while Shift+Q has no effect, while they work correctly on MSTS.
I have uncompressed and opened as a sample case the .s file of one EMU, that is ABe44III-53 (in folder RhB_ABe44III), and seen that maybe the naming of the doors is a bit different than you state.

Carlo

[csantucci]

We are approaching a slipperly slope here. I'm not a fan of chasing every model builder's naming convention to properly animate parts within shape files. When we move to OR new shape/ENG files, there will be specific standards to which model builders will have to adhere for them to properly animate.

After having checked with the author of the Bernina's rolling stock I believe the question is a bit different, and applies to both GoGoran's case as well as to the doors of Bernina's rolling stock. MSTS recognizes the "groups" of animations, and provided that the group root has a correct name (e.g. DOOR_A) it animates all elements of the group as the root, independently of their name. ORTS instead does not seem to do that. MSTS approach allows for more freedom in animations, and so it would be nice if ORTS would behave the same.
The attached Gmax screenshot shows what I mean by a group ( DOOR_A in this case) and its naming.
Group.jpg

Carlo

[OTTODAD]

MSTSBin George has added the opening/closing left and right doors capability to MSTS rolling stock which looks like this below in shape files.

O t t o

[GoGoran]

After having checked with the author of the Bernina's rolling stock I believe the question is a bit different, and applies to both GoGoran's case as well as to the doors of Bernina's rolling stock. MSTS recognizes the "groups" of animations, and provided that the group root has a correct name (e.g. DOOR_A) it animates all elements of the group as the root, independently of their name. ORTS instead does not seem to do that. MSTS approach allows for more freedom in animations, and so it would be nice if ORTS would behave the same.
The attached Gmax screenshot shows what I mean by a group ( DOOR_A in this case) and its naming.
[ATTACH=CONFIG]49301[/ATTACH]

Carlo

Hi Carlo,

thank you so much for your invaluable research !

Actually it looks like I was wrong - the parts I described above probably do not have standardized names, and you are right on the money with your explanation: MSTS recognizes whole groups of animations, as long as they are attached to a standardized parent part such as PANTOGRAPH........., WHEELS.. or DOOR_A, and then animates them in the same way as the parent part: Continuous and speed-related animation for animations attached to a WHEELS.. parent, such as ventilators e.g., or one-time, one-direction animation for parts attached to a PANTOGRAPH....... parent part.

Here's the corresponding gmax hierarchy tree/subtree view of the model I mentioned above -- don't wonder about the shortened names, I abbreviated the standard MSTS codes to comply with the 8+ character truncation behaviour of the gmax converter plugin, and rename them manually after exporting to *.s format, such as PNTB1A to PANTOGRAPHBOTTOM1A etc.:



As you can easily see, the P1_ANI_11 etc. parts are all attached to registered pantograph parent parts with standardized names. And therefore they animate all correctly in MSTS.




The more the development of OR continues, the more apparent it becomes that MS/Kuju put A LOT OF THOUGHT AND EFFORT into MSTS, and it will take lots of time and effort from the OR developpers and the supporting community to duplicate all the finer points of MSTS into OR. But the OR developpers should not stick their collective heads into the sand over this revelation, but continue step by step, unabashed.

PS: I know how it feels like to work on a very much progressed project like OR, which lets you think every day "Tomorrow I will finish it!", only to find out about the next major flaw in it the very next day, and keep working on it like that forever ...

[longiron]

Guys,
Thanks for the investigation into the animation question. I will add the ability to animate subobjects of a correctly named master object ... to the TO DO list.