[ebnertra000]

 charland, on 22 December 2018 - 06:43 PM, said:

Just noticed the crossing flashers ( ci_xing1.zip, ci_xcan.zip ) that have worked fine in MSTS and OR (1.3.4310) stopped working recently.
I just made a business sign in TS Modeler that rotated and works just fine on OR about 200 feet from a crossing that isn't working on the same tile.

Paul :-)

I assume you fixed Bruce Bridges' crossing flashers to animate in OR (removing the decimal in the animation speed). I did notice that the signal on a wayside horn I just built doesn't animate in TSRE, but it works fine in OR, as do the beacon-equipped traffic signs I've installed in a route

[vince]

Quote

a wayside horn I just built doesn't animate in TSRE, but it works fine in OR,

I also have objects, aircraft that animate okay in OR but not TSRE, smoke plumes okay in both though. Some subtle difference in the shape files maybe?

regards
vince

[charland]

"I assume you fixed Bruce Bridges' crossing flashers to animate in OR" Thanks, I'll go look that that.
Paul :-)
Thanks, that did the trick. :-)

[jonas]

I've had similar experiences with animations as they've been mentioned here. In fact, it seems very important to me that in an animated shape only child-nodes should be animated. If the parent node is animated or if the shape consists of only one animated node, even in MSTS there will be strange behavings of that shape.
For example, in PTRR there is a combine harvester that moves for the first lap as it is given by the animation, but already in the second lap it doesn't move on the same path as the animation describes, which after a few more laps goes so far that it even crosses the tracks.

Animated JP2FishBoat.s in JAPAN2 after 2 hours simulation
Also the here mentioned boat "JP2FishBoat.s" in the original MSTS JAPAN2-Route is subject to this phenomenon in the w-file "w-00370+013909.w". It has only an animated parent-node and drifts in MSTS from lap to lap further north until it even leaves the water and moves its laps ashore :-).

I think rounding errors play a role here, which add up from lap to lap. So it seems right to me, according to what Carlo writes, that OR doesn't animate such shapes in the first place, because they are also faulty in MSTS.

For me there are therefore 2 important principles when creating animated shapes:

1. In an animated shape, the parent node should never be animated, which inevitably means that at least 1 animated child-node must exist. The non-animated parent node represents the fixed reference value (position) for the animated shape for the simulator. The rounding errors are thus excluded.

2. The parent node must include the maximum spatial extent of the animated child node so that the MSTS RE in the w-file correctly dimensions the corresponding "ViewDbSphere" and so that the user can see the animated shape at any viewing angle.

If, for example, a tram is to travel back and forth at 1000m, I use a non-animated parent node which has a polygon at 0m along the moving path of the child node and a bit below the street surface. Also under the street surface and at the ends of the moving path (turning points of the child node) two more polygones of the parent node are placed one at -500m and one at 500m. So the non-animated parent node has 3 polygons, one in the middle and two at its ends. So the animated shape can always be catched well with the mouse by the parent-0m-polygon, even if the shape is already set as animated and one would have problems to catch the moving tram with the mouse :-)



I'm afraid the description here won't help to re-animate the stucking air planes but maybe an explanation why them not moving in OR and doing strange movings in MSTS.

[ebnertra000]

I found a UFO shape in the default Marias Pass shapes folder (apparently an Easter Egg that never was) and each time it flew around it got lower. It has flown into the ground on many occasions. Based on that, I'm guessing that it, too is an animated parent nodeshape, and won't work in OR. I may have to make a replacement...

[paulytechnic]

 ebnertra000, on 21 December 2018 - 03:59 PM, said:

I'm willing to bet that if a node were inserted with the boat as a child (not sure if that's actually possible), it would then work

I can confirm that the issues I was having were indeed caused by the animations being on a parent node, rather than a child. Thanks everyone for helping to identify the issue!

I was able to successfully convert the boat's parent node into an animated child node, inserting a minimal (static) parent. However, that required A LOT of involved manual editing in the shape file's code. In some cases, it may almost be easier to just construct an all-new replacement model than to manually recode an existing shape (particularly since many of the ones having the issue are fairly outdated by this point).

Either way, it's good to now know that any animations MUST be on child nodes. Thank you all!

[ebnertra000]

I've thought about making a replacement sine this thread came up. Not sure when I'd get round to it, though

[Csantucci]

I've restudied the issue and here I propose replacement Runactivity files for OR 1.3.1 that should enable animation of the shape root.
 Runactivities_rootanimation.zip (1.11MB)
Number of downloads: 496

[Goku]

I think that there was a long discussion about root shape rotation and there were some issues with it and that's why it was never enabled. But maybe I remember it wrong.

[jonas]

Carlos patch seems to be working for me. Now the boat in the JAPAN2 route moves in OR with the patch-runactivities and holts the animation path position at least for 3 test-hours (That I've catch the same second "47" is a real coincidence :-)



So only the "ViewDbSphere" problem remains. If I go closer to the boat with the camera, the boat disappears completely, the same as in MSTS.