[marcuskiwi]

Hi
I have been using OR for some time now on various routes and find it's great. Just recently I installed the english route "Black Country 1 (BC1)" and I note that in activity "BCIM_45308_Birmingham_Lichfield_City" using steam engine CCW_BR_B5_45308 that when the activity starts the crew are riding on the front of the engine and not in the cab!!. When I run this activity through MSTS the crew are where they are supposed to be, in the cab. Has anyone else come across this particular problem. By the way I have yet to check all the steamers on this route, this was the first one I have tried.
Mike

I should have said I am running OR experimental version X2299.
I have checked other steam engines and some have crew in cab and there are others where crew is outside !

[copperpen]

I did report it as a bug some time ago. Where the crew is modelled as part of the engine there is no problem. Where they are a freightanim they ride the front of the engine, even if the freightanim line is commented out. This freightanim problem also affects some tender animations.

[marcuskiwi]

Thanks for that prompt reply. If you have already reported this problem I will just leave it for now and just enjoy the activities. The crew only show when in view 2 so and only at a certain distance, if you zoom in to the engine they disappear.
Mike

I note that if I go back to OR V8 then the crew are IN the cab and not riding on the outside!

[copperpen]

I have been looking at the various crew freightanims in use by loading the shape file a crew is associated with, then loading the crew as the second shape. This has led me to the conclusion that OR is displaying these in the correct world space which is dependent on where the point of origin of the model is. Add to this a vertical component and what you see is what OR is programmed to do. Looking at the various shapes it is very clear that they all have different points of origin shown by where they appear in Shape File Viewer.

In the Freightanim line within the eng or wag file there are three sets of data corresponding to the X,Y,Z of the position the shape should be displayed at in relation to the original point of origin. However, since the code was modified for the tender shape animation the crew shape animation only responds to vertical positioning where this is part of the tender wag file.

This therefore clearly identifies the need for OR to accommodate more than one FA on a base shape which can probably be easily added by using the ORTS prefix in the same way that other items are added to the MSTS file for OR to process. This would then allow for the crew animation to be placed with the engine, not the tender which is the underlying cause of the current bug.

[atsf37l]

I have found that FA's in MSTS don't always end up in the right place for OR. When this occurs I will adjust the freightanim using Shape Viewer to position the 'second shape' then take the shape file to Shape File Manager, uncompress it then shift it (and scale it if necessary) using the offset figures from the Shape Viewer positioning bar. Once satisfied I re-compress the file and I'm good to go.

A case in point are Bill Pratt's RGS T-19's. The FA for the crew puts them in just the right place in the locomotive but the FA for the tender coal ends up high and up forward in the engine cab. So I have a locomotive and two separate tenders for each of these three engines, one for MSTS and one for OR.* I think this has to do with the actual animation involved with a coal pile in a "tender" wagon shape, which never worked right. I zeroed out the FA statement so the coal doesn't move because even though it stayed in place horizontally and laterally you never knew where it would start out vertically.

*This arrangement will be short lived 'cuz I'm running OR almost exclusively now! :sign_welcome:

[railguy]

 copperpen, on 26 October 2014 - 04:51 AM, said:

This therefore clearly identifies the need for OR to accommodate more than one FA on a base shape which can probably be easily added by using the ORTS prefix in the same way that other items are added to the MSTS file for OR to process. This would then allow for the crew animation to be placed with the engine, not the tender which is the underlying cause of the current bug.

Please do this. There are other reasons for doing this. For example, a locomotive that uses a FreightAnim for many of its parts (now very common) could have a second FreightAnim, for example, to add a crew for lead diesel units. Indeed, a whole "secondary market" could be created in the sim community for producing modifying FreightAnim's for models that already have one FreigtAnim that should be left in place.

[James Ross]

 copperpen, on 26 October 2014 - 04:51 AM, said:

This therefore clearly identifies the need for OR to accommodate more than one FA on a base shape which can probably be easily added by using the ORTS prefix in the same way that other items are added to the MSTS file for OR to process. This would then allow for the crew animation to be placed with the engine, not the tender which is the underlying cause of the current bug.

Do you think the bug can be fixed? Extending things is cool and all, but if we can fix the bug as well that would be the best.

[copperpen]

I am not sure if it can be fixed. The problem arose when a fix was applied to make the normal tender FA behave. Unfortunately this only reads the highest and lowest points of the animated coal, the Y axis. Ideally the engine is where the crew should be, but as an FA is impossible on engines that carry one for all the details, it became the norm to use the tender where an FA was not already used. To use the tender for crew positioning it needs the Z axis active as well, and again, cannot be used on a tender that already carries an FA for the coal.

[James Ross]

 copperpen, on 28 October 2014 - 09:52 AM, said:

I am not sure if it can be fixed. The problem arose when a fix was applied to make the normal tender FA behave. Unfortunately this only reads the highest and lowest points of the animated coal, the Y axis. Ideally the engine is where the crew should be, but as an FA is impossible on engines that carry one for all the details, it became the norm to use the tender where an FA was not already used. To use the tender for crew positioning it needs the Z axis active as well, and again, cannot be used on a tender that already carries an FA for the coal.

Okay, so how does it work in MSTS? I assume these models all work in MSTS. Are we ignoring something MSTS doesn't (or visa versa)?

[copperpen]

I think we have done something that MSTS does not do which is to fix an FA specifically on a tender restricting it to the Y axis only. I don't know why this was done, but the answer is in these forums or the bug tracker. In my experimenting I edited the positional info of the FA in all three axes, and found that in two of them the height was affected, and in the third nothing was affected, the model appeared at the base level with no elevation.