[jared2982]

steamer_ctn, on 30 March 2018 - 03:48 AM, said:

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.

I think this is a wonderful idea. Many steam engines use the CoG entry to get the position of the tender adjusted correctly. In addition to the Z and Y values I would like to suggest also allowing the use of the X value to offset the shape left and right. My current route has dual gauge trackage and the only way to allow the interaction between standard gauge and narrow gauge is to offset a models origin, if you have access to the source files. Trying it any other way sometimes has undesired consequences. Currently we have to build separate models with offset center points to accomplish this. Allowing the use of the X value would allow us to offset any model for use in this manner, or to adjust any model that might not be quite centered on the rail like it should be.

[steamer_ctn]

Hi James,

James Ross, on 30 March 2018 - 09:17 AM, said:

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.

If of assistance I could add the two new parameters and remove the Z value restriction, but I wouldn't have a clue how to implement the X and Y value changes.

Do you want to take ownership of this potential change, including the possibility of offsetting the X and Y values (as suggested in post #31)?

Thanks

[James Ross]

steamer_ctn, on 30 March 2018 - 05:07 PM, said:

If of assistance I could add the two new parameters and remove the Z value restriction, but I wouldn't have a clue how to implement the X and Y value changes.

Hmm, yeah, it's fun. I guess we'd need to shift the bogies in X and Y as well as Z, but the Z change seems to be done dynamically at runtime and not during loading - and I don't know why. :(

steamer_ctn, on 30 March 2018 - 05:07 PM, said:

Do you want to take ownership of this potential change, including the possibility of offsetting the X and Y values (as suggested in post #31)?

It looks like adding an ORTS parameter for the centre of gravity for physics should be easier to do, and we leave the model adjustment as-is using only the old MSTS parameter (and keeping the limit). That should be achievable by switching the code in TrainCar.cs to use "InitialCentreOfGravityM" instead of "CentreOfGravityM", leaving the latter free for the physics.

You're welcome to work on the new physics parameter, and I'm happy to check over the changes if you have any concerns/questions. We'll keep the model shifting on hold for now.

[steamer_ctn]

Hi James,

James Ross, on 31 March 2018 - 05:58 AM, said:

You're welcome to work on the new physics parameter, and I'm happy to check over the changes if you have any concerns/questions. We'll keep the model shifting on hold for now.

Attached is a potential patch to add the extra parameters discussed.

I will leave it up to you to incorporate model shifting into it as and when you see fit to do it. Please commit it when you are ready.

Attached File(s)

•  CoG_patch.zip (1.89K)
  Number of downloads: 550

[ErickC]

It will probably be a useful feature, but it's pretty sad that MSTS model builders are so bad, on average, at getting the basics of good model building right that a crutch needs to be devised for them.

[slipperman]

Hi,

ErickC, on 01 April 2018 - 12:07 PM, said:

It will probably be a useful feature, but it's pretty sad that MSTS model builders are so bad, on average, at getting the basics of good model building right that a crutch needs to be devised for them.

Sorry, Erick, but I think that is an uncalled for slur on many contributors to the MSTS Community. It is, after all, mentioned in the MSTS TechDocs, dated 9 May 2001 :

Quote

The centre point of the vehicle is defined in CentreOfGravity (x, y, z ) “z” value.

Cheers,
Ged

[ErickC]

It's the truth. You might not like it, but it is. Many models with these issues looked that way in MSTS, regardless of what parts of the physics OR chooses to ignore. People exploited that parameter to correct problems with models that were released in a state of floating above or sliding below the rails. It wasn't used by model builders to position their models, because they didn't care. They just released them that way and left the user to "fix" the problem. Fixing it for real is as simple as moving a pivot and re-exporting. In other words, fixing a model that does not sit right literally takes five seconds of actual effort for the model builder.

It's a good thing that OR is getting a parameter to deal with the problem, but the fact remains that a long-standing problem with MSTS models, that goes all the way back to 2001, is that developers put all that effort into detail parts and textures without spending a few seconds ensuring that the model was actually going to sit on the rails correctly, or that the ends of the couplers were equidistant from the pivot. This isn't to say that the models were bad or the builders did an otherwise poor job, indeed many of my favourite models suffer from misplaced pivots. But MSTS model builders, on average, were very bad at setting top node pivots properly. Most of them just didn't care. I think most contemporary model builders are a bit more aware. This is a good thing. I've never run a Tyler Bundy model that didn't sit exactly where it was supposed to, for example.

[darwins]

Need to say here Erick, that it can take a lot more than a few seconds to re-centre a steam loco model with complex valve gear (well at least if making in TSM).

So variations of a class or group of locos might use the same driving wheels and valve gear but have different frames or bogies, making them say four inches longer.

So moving the model centre back takes a few seconds - then all the valve gear will animate in the wrong place.

To move all the animations can take several hours - 10, 20 or 30 moving parts with 8, 16 or even 32 frames animation to edit for each. Then recheck for mistakes.

Having a small adjustment that can be used in OR will make life much easier.

(That is without thinking about the y direction - I build models to sit nicely on UKFS track... which results in their wheels being buried in the default track - life would be easier if the datum chosen was the top of the rail rather than the ground.)

[ErickC]

Nope. I just ran some tests in TSM and literally all you have to do is move the top node's pivot. Transform|Translate, select "axis only," enter whatever number will place the pivot in the right spot, and the child animations work just fine.

Wait - you were aware that the origin of the project in TSM and the exported model's center have nothing to do with each other, right? Does the TSM documentation not make this clear? Because that would explain a lot of the miscommunication between me and TSM users on the subject elsewhere. If you were trying to fix the problem by moving the model, then you would indeed have major issues, as FSDS/TSM does not move the pivots with the parts (which is out of the ordinary, but there must be some reason I guess).

[darwins]

Good news and bad when I finally tried this with a more complex model.

Exactly as you say - move the top node (in this case closing up an engine tender gap that would otherwise be too large) and the animation still works perfectly.

Unfortunately some of the other parts of the model shifted for no apparent reason.

http://www.atomic-album.com/showPic.php/121473/gaps1.jpg

Having all parts centred to the new model centre brought some parts into line. Changing the hierarchy (parents and children) got some other parts into line. Some parts want to stay in the wrong place whatever...

So the easy solution again becomes adjust the model centre in the eng file using the "CentreofGravity" line z value. :wacko: :wtf01: :(