[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".

[darwins]

Sorry you have got the wrong "Centre"

OR does read CentreofGravity ( x y z ) - this is for physics as the name implies, it governs when a vehicle may become unstable and fall over! (weight distribution)

The line you need to adjust for either loco or tender of both is "Centre"

I have used this to adjust the position of a Royal Scot loco in OR - as then I can use the same motion as a Patriot or Jubilee without having to redo the animation for something like a 3 inch difference in position because of a difference in length. (Also for 5500 and 5501 which had different wheel centres to later Patriots and Jubilees).

The line in my Royal Scot is

Centre ( 0 0 -0.056 )

You should try adjusting the Centre of both loco and tender till you find the correct measurement.

[copperpen]

darwins, on 29 March 2018 - 10:27 PM, said:

Sorry you have got the wrong "Centre"

OR does read CentreofGravity ( x y z ) - this is for physics as the name implies, it governs when a vehicle may become unstable and fall over! (weight distribution)

The line you need to adjust for either loco or tender of both is "Centre"

I have used this to adjust the position of a Royal Scot loco in OR - as then I can use the same motion as a Patriot or Jubilee without having to redo the animation for something like a 3 inch difference in position because of a difference in length. (Also for 5500 and 5501 which had different wheel centres to later Patriots and Jubilees).

The line in my Royal Scot is

Centre ( 0 0 -0.056 )

You should try adjusting the Centre of both loco and tender till you find the correct measurement.

If I adjust the Centre line Z axis of a King, nothing changes relative to the tender. If I change the Centre of Gravity line Z axis the space between loco and tender changes by that amount. The Centre of Gravity is also used in the steam4me tutorial on adjusting coupling spaces between wagons.

[darwins]

Just have a quick try I can not move the model using either of these lines today. Now totally confused. Needs in depth investigation.

[steamer_ctn]

darwins, on 29 March 2018 - 10:27 PM, said:

Centre ( 0 0 -0.056 )

There doesn't appear to be any provision in the current OR code for the reading of the Centre parameter in the WAG or ENG file.

copperpen, on 29 March 2018 - 12:50 PM, said:

In MSTS the CofG determined the relationship of a model to the next model front or rear.

Sadly another example of MSTS creating problems by using the incorrect parameters for particular functions.

I have had a quick look at the OR code, and it appears as though the Y value (height) is used only for the physics to determine the "toppling" effect of the wagon, whilst the Z value is only used for positioning a wagon shape (horizontal distance along the track).

As a possible way forward it is suggested that two new parameters be created as follows:
i) ORTSMassCentreOfGravity - used to allow entry of CoG information for relevant physics functions
ii) ORTSShapeCentre - used to offset the shape in the Z direction as discussed. As a potential new feature, it may also be useful to allow the Y value (height) to be used to raise or lower a wagon slightly if it is not sitting on the track correctly.

It would be strongly recommended that all new ENG or WAG files going forward would use both of the above parameters and cease to use the CentreOfGravity parameter.

To handle "legacy" issues where the CoG parameter has been used in older files, the Z value would be assigned to offset the shape file, whilst the Y value would be used for the CoG physics.

The code would be setup that either of the two new parameters would be used as the first preference, and the old CoG parameter only used if neither of the two new parameters were present in the ENG or WAG file.

[James Ross]

copperpen, on 29 March 2018 - 12:50 PM, said:

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".

I agree that it is problematic to limit the about of CoG.Z movement that we allow in OR, but I spent multiple hours testing changes to CoG.Z, Size, and bounding boxes in MSTS and could only get reliable behaviour in small CoG.Z values. See my earlier message:

James Ross, on 28 December 2016 - 08:50 AM, said:

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.

I don't think I recorded my results, though, so perhaps we can re-run the experiments to see if there is a pattern? Basically, we should only use values that we can be reasonable confident that we're doing the same thing as MSTS, otherwise we'll break more than we fix. Remember that the limit is in place precisely because, without it, we broke some content.

I agree with Peter that adding new ORTS parameters to explicitly set visual position, physics CoG, etc., would be useful, even if it would not help the existing content.