[edwardk]

OR is using CentreOfGravity(), but unfortunately not in the way it should be used.


Edward K.

[steamer_ctn]

edwardk, on 12 August 2016 - 01:04 PM, said:

OR is using CentreOfGravity(), but unfortunately not in the way it should be used.

How should CentreOfGravity be used in OR?

[edwardk]

Evidently, MSTS use of CentreOfGravity() should be replicated in OR. It was probably determined at one point that it was not too important to work on, but this post is indicating the opposite.

Edward K.

[QJ-6811]

Hobo, on 11 August 2016 - 01:08 PM, said:

You said a " Sister " locomotive . Is the model the same with only different FA and color or a different model altogether ?

Please check your mailbox

ianmacmillan, on 12 August 2016 - 01:38 AM, said:

Easiest solution is to set the size of the tender to be correct for the rear coupling and insert an invisible wagon between the loco and tender.

Thanks. An unexpected solution. Placing an "invisible car" between the locomotive and tender I think is not a good idea. I expect a tender as a second car does not function properly. The gap is at the front, but then you turn out the light problems ( incl. headlight on track). So it will have to be placed on the tender side. I will try it once soon .

slipperman, on 12 August 2016 - 11:06 AM, said:

It appears that Open Rails doesn't read the CentreOfGravity entry from the eng file. This loco's entry is : CentreOfGravity ( 0m 2m -1.3m ). If that line is replaced with : CentreOfGravity ( 0m 0m 0m ) and run with MSTS, EXACTLY the same problem occurs with the front-coupled wagon.

Thank you for testing. Now I understand why I had no problems in MSTS...

I'm not sure, but I see in the default file the following lines:
CentreOfGravity ( 0m 2m -1.3m )
Centre ( 0m 0m -1.3m)
Is it just CentreOfGravity or maybe a combination with Centre? (Difference in MSTS or ORTS)

.

[copperpen]

steamer_ctn, on 12 August 2016 - 04:29 PM, said:

How should CentreOfGravity be used in OR?

Check the last part of the coupling tutorial at Steam4me.

[James Ross]

I'm working on a fix in https://bugs.launchp...or/+bug/1649285

[James Ross]

slipperman, on 12 August 2016 - 11:06 AM, said:

It appears that Open Rails doesn't read the CentreOfGravity entry from the eng file. This loco's entry is : CentreOfGravity ( 0m 2m -1.3m ). If that line is replaced with : CentreOfGravity ( 0m 0m 0m ) and run with MSTS, EXACTLY the same problem occurs with the front-coupled wagon.

As has been mentioned previously, it seems that the only way to correct it for the current version of OR is to modify the shape file. That doesn't seem to be the right way to go, because who knows how many other locos will have the same problem? Wouldn't it be better if OR read that entry and acted on it as MSTS does?

This should be fixed in X3693.

[Lindsayts]

There is a similair problem in Australia with a payware model of Victorian Railways H220, for some unknown reason the developers made the tender to long at the front for its bounding box and they then put an invisible wagon containing just the locomotives crew to space it back . In this case though it was possible to solve the issue and go without this invisible wagon by changing the tenders bounding box. Surely though if the bounding box does not match the shape file there's an error with the model as there is in this case

Lindsay

[copperpen]

James Ross, on 12 December 2016 - 07:22 AM, said:

This should be fixed in X3693.

Just been dealing with an articulated locomotive that uses centreofgravity to position the lead section. This works fine in MSTS, but with the OR version of CofG, I have to subtract 2 meters to get it in the same place. Seems like the OR CofG is working in reverse when compared to MSTS because OR offsets the lead unit to the rear by those 2 meters'

[James Ross]

copperpen, on 28 December 2016 - 01:56 AM, said:

Just been dealing with an articulated locomotive that uses centreofgravity to position the lead section. This works fine in MSTS, but with the OR version of CofG, I have to subtract 2 meters to get it in the same place. Seems like the OR CofG is working in reverse when compared to MSTS because OR offsets the lead unit to the rear by those 2 meters'

Hmm, strange. The CoG calculation in Open Rails is very simple: shift wagon by amount. The problem I found was that MSTS has a lot of interaction between Wagon>Size, Wagon>CentreOfGravity, and the bounding box of the shape. Lots of things I tried to experiment with just did garbage in MSTS or it ignored some settings, or even positioned everything visually where I expected but broke the couplings! I am pretty sure I got the direction right but if you have an example I can look at where it's deviating from MSTS, we can check.

[copperpen]

slalleg.zip in the trainsim.com library is the one I have been fiddling with. In MSTS the front engine displays in the correct position under the boiler. In Open Rails v1.1 the model displays the same as in MSTS, but at that point OR was not using the CentreofGravity in the same way as MSTS. Now that OR is using the CofG the data in the eng file must be altered in the z axis to get the front engine section in the correct place. It has to be changed from 2.25m to 0m.

[James Ross]

copperpen, on 28 December 2016 - 11:21 AM, said:

slalleg.zip in the trainsim.com library is the one I have been fiddling with. In MSTS the front engine displays in the correct position under the boiler. In Open Rails v1.1 the model displays the same as in MSTS, but at that point OR was not using the CentreofGravity in the same way as MSTS. Now that OR is using the CofG the data in the eng file must be altered in the z axis to get the front engine section in the correct place. It has to be changed from 2.25m to 0m.

Interesting; given that, in my MSTS testing, large CoG.Z values would often result in weird or unexpected behaviour, I've decided that we will only shift things in OR for small CoG values and ignore larger ones - at least until we have a better understanding of how Size, CoG and bounding boxes all fit together in MSTS.

Fix is in X3727.

[James Ross]

copperpen, on 28 December 2016 - 11:21 AM, said:

slalleg.zip in the trainsim.com library is the one I have been fiddling with. In MSTS the front engine displays in the correct position under the boiler. In Open Rails v1.1 the model displays the same as in MSTS, but at that point OR was not using the CentreofGravity in the same way as MSTS. Now that OR is using the CofG the data in the eng file must be altered in the z axis to get the front engine section in the correct place. It has to be changed from 2.25m to 0m.

Interesting; given that, in my MSTS testing, large CoG.Z values would often result in weird or unexpected behaviour, I've decided that we will only shift things in OR for small CoG values and ignore larger ones - at least until we have a better understanding of how Size, CoG and bounding boxes all fit together in MSTS.

Fix is in X3727.

[QJ-6811]

Now I downloaded v1.2, I wanted my "gap problem" also correct again.
As described, would be fixed from X3693. However, still the same problem as before..........


Now I read something about fix X3727 and "small values"?

this means that it was fixed, but not anymore in release 3766? (Hummm)

[copperpen]

James Ross, on 31 December 2016 - 05:13 AM, said:

Interesting; given that, in my MSTS testing, large CoG.Z values would often result in weird or unexpected behaviour, I've decided that we will only shift things in OR for small CoG values and ignore larger ones - at least until we have a better understanding of how Size, CoG and bounding boxes all fit together in MSTS.

Fix is in X3727.

James,
Any chance of relaxing this restriction. I would like to run the Alleghenies in OR again, and we now have a couple of Indian engine that would benefit from the ability to use larger figures. In MSTS the CofG determined the relationship of a model to the next model front or rear. The C of G is always set at the models point of origin as a default. If this point of origin is incorrect so then is the C of G, hence the need to move it 2.25 meters forward for the front section of the Alleghenies in MSTS and to move it back by the same amount in OR because OR is reading the C of G as the point of origin. Only having a limited amount of movement does not "cut the mustard".