Why this Issue with Steam Locomotives

[davidpravin1970]

I have been using the YP class Steam locomotives which i have designed for MSTS using train sim modeller and it has been successfully running in MSTS.

It also runs well in OR but with certain issues which I wuld like to highlight

1. When 2 locos are attached back to back or front to front the non player (AI loco) and tender bunch up together
2. Similarly when the player locomotive is flipped in the consist editor the player loco itself bunches up with the coal tender once the activity starts.
3. After the player loco has been turned around in a turn table and saved thereon, the saved activity when opened again in OR displays a similar issue with the player loco bunching up.

I am attaching the coupler parameters and the screenshots just for reference :

Wagon ( YP_2323
Type ( Engine )
WagonShape (YP_2323.s )
Size ( 2.621m 3.991m 12.37m )
CentreOfGravity ( 0.0m 0.0m 0.0m )
Centre ( 0m 2.04785m -0.000584848m )
Mass ( 99.0t )
InertiaTensor ( Box(2.621m 3.991m 12.5m) )

Coupling (
Type ( Bar )
Spring (
Stiffness ( 1e1N/m 1e6N/m )
Damping ( 1e12N/m/s 1e7N/m/s )
Break ( 5.2e6N 5.2e6N )
r0 ( 2.3m 0.04m)
)
CouplingHasRigidConnection ( 1 )
Velocity ( 0.1m/s )
CouplingUniqueType (YP_2323 )
)

Coupling (
Type ( Chain )
Spring (
Stiffness ( 3e6N/m 3e6N/m )
Damping ( 1e6N/m 1e6N/m )
Break ( 5.2e6N 5.2e6N )
r0 ( 10cm -25cm )
)
CouplingHasRigidConnection (1)
Velocity (- 0.1m/s )
)



I never had any such issues with these locos in MSTS....can any one help which would be highly appreciated

thank you

Pravin David

[baldwin]

I suspect the problems are being caused by this unusual r0 parameter r0 ( 2.3m 0.04m), 2.3 meters is 7.5 feet. This is a large distance for a coupler to stretch, even for MSTS.
MSTS uses the size line and the bounding box to position stock relative to each other, whereas ORTS seems to use the coupler r0 setting to determine spacing, it ignores the bounding box. ORTS by the way, only uses one coupler per unit and the style is automatic, regardless of what you have in the eng or wag file.

[slipperman]

Hi Pravin,
As I can't find YP 2323, I tried using your YP 2358 from the file library.
This is NOT an Open Rails problem as it also occurs in MSTS; I don't have a solution at present!

Another problem, which WILL manifest itself in Open Rails is that the tender has : Type ( Freight ) which means it will have no coal and water!
Yet another error, which, based on Baldwin's comment, might not affect OR, is that the second coupling's Damping values should have /s added to them.

Cheers,
Ged

EDIT : I'm assuming that YP 2323 is basically the same loco as YP 2358, in which case, although it shows up in the stable v1.2 of OR, it is rejected in the current (X4096) version. The log is attached, but believe it's because the loco has vacuum brakes and the tender has air brakes.

[davidpravin1970]

Yes YP 2323 and 2358 are all the same except that 2323 has a headlight in the Tender

[davidpravin1970]

Thanks guys for the thread. i have done the adjustments which you suggested but everything is still the same. is that that i cant use the loco to flip it around or couple it back to back or front to front with the same type of locos ever in ORTS? So is there a way around for this?

thanks

Pravin David

[Vince]

One thing I see is your coupler break force is set at 5.2e6N!
That works out to 1,169,007 pounds force!
Setting them to a bit less than1 million pounds I'd think would be prototypical. 1.26e6N will give you 283,259.3 lbf which is pre 1970 FRA class C coupler specs.

You can probably figure a proper break force setting for this fine engine as it probably a lot lower than the Class C

regards,

[slipperman]

Hi Pravin,
After further investigation, it seems that the problem using the flipped loco may be because the loco shape isn't centred. Note the large difference between the 3rd and last values in the bounding box entry :

ESD_Bounding_Box ( -1.448971 0.005444 -9.550806 1.458436 4.294968 6.240266 )

I'm a relative novice at this, but using Shape File Manager to shift the shape so that both values are approximately equal makes it easier to get the tender to appear in the correct position, but, as a result, the rear pony truck, the wheels of the front bogie and the smoke all now appear out of position in both normal and flipped locos!! As you're the author, I would think you'd be able to fix this As the problem applies to MSTS as well as OR, I've been using the former for my tests. I don't know if Open Rails can offer a different solution, but if not, the answer to your first question is : No!

Cheers,
Ged

[baldwin]

Looking at those figures, they are for the bounding box, used in MSTS for collision detection, but not in OR. It does however clearly show that the model is not centred which will not help in OR either. The model it seems does need a rebuild because of all the animations for rods, wheels and valve gear. I feel that just moving the axis to centre the model will put all of those out as well.

[davidpravin1970]

Hi all thanks every one for the inputs again. well i guess there is a tough job ahead if there is no solution than rebuilding the loco again from the scratch though i am not sure i wud want to do that. My only other choice is to operate the loco in the reverse for any return trip which means after dark i wud b loosing out on the head lights since i cant flip the loco, or turn it around in the turn table.

[baldwin]

You can try adjusting the centre of gravity line, z axis is currently 0.0. Try a positive number first, if that makes the gap bigger, put a negative sing in front and see how that looks. The problem arises because the point of origin of the model when building was not in the centre.

[slipperman]

Hi Baldwin,
Thanks, mate, the phrase I was looking for - "point of origin"

Setting the z value of the CentreOfGravity to -1.2m cured the problem for MSTS, but not Open Rails, which, I understand, doesn't use the CoG values. Tested with stable v1.2 only as the tender and loco brakes require matching.

Cheers,
Ged

[baldwin]

Ged, CoG does not work in the stable 1.2, but does work in the later experimentals, but cannot remember which version introduced it. Definitely works in the latest.

[scottb613]

Hi Folks,

Yeah - one issue with steam locomotives for me - is that I always start with the "pivot point" - possibly the same as "point of origin" - centered between the main drivers - this was always an issue as steam locomotive's ends are not always equidistant from this point... So - adjusting the "Pivot Point" to a position where it still works well and allows for proper coupling of both the tender and front coupler always took some work... To the best of my knowledge SFM will not work - as all the locomotive's rod animations have to be shifted at the same time - I always had to do it within the modeling software... Fortunately in 3DC - Paul Gausden wrote a script to perform this very function... Sorry - no help with TSM on this...

Regards,
Scott

[slipperman]

Hi Baldwin & Pravin,
I got YP 2358 and YP 2357 to work in Open Rails by omitting all the Engine Brake parameters, except for :

EngineBrakesControllerHasProportionalBrake( 1 )
EngineBrakesProportionalBrakeLag( 0.9 )

but I still don't know what the problem is.

I'm sorry to say that the CoG does not work in X4096. Using the value of -1.2m for the z parameter works OK in MSTS, but there's no difference between that and 0.0m in OR.

Cheers,
Ged

[baldwin]

Try using 1 meter. I know when it was first activated I needed something like 2.5 m for an Alleghenie to get the two engine parts to fit, but I seem to recall that a limit was decided on for some reason. Because of that limit, I no longer use those locos in OR.