[NickonWheels]

I´ll share my extended code on starting friction. This is only a test version based on the downloadable code fromthe official website, so it´s 2 GB memory only. Please choose some route which is has few objects like Peter Newell´s CTN route. The accompanying locomotive (based on the old dash-9) is fitted with all friction lines and also has diesel engine tab and traction+dynamic brake curves.

Feel free to make some experiments with those new lines and share your experience.

[attachment=103671:ORTS_extended_friction.zip]

[NickonWheels]

README for new starting friction equation - by NickonWheels

First and foremost, the three Davis lines

ORTSDavis_A
ORTSDavis_B
ORTSDavis_C

work as before. However now it is POSSIBLE to replace ORTSBearingType with

ORTSStandstillFriction - the amount of static friction / defaults to newton but can use pounds, just like ORTSDavis_A
ORTSMergeSpeed - the speed at which low speed calculations and Davis equations meet (while accelerating and decelerating) / uses meters per second, other units are untested

The older code section uses 5mph as merge speed throughout.

If you don´t want to bother with this new section ORTSBearingType (or lack thereof in regards to plain bearings) still works as before.
Of course it´s hard to know what values seem to fit as FCalc won´t tell that.

[NickonWheels]

Ideas? Suggestions? Comments? Someone...

[pschlik]

As someone incredibly inactive on these forums, I definitely can't speak for everyone, but I really like this idea. In my recent return to Open Rails, I've been modding the heck out of every last piece of rolling stock I have, including adding the whole Davis setup to everything. I definitely found starting friction to be more extreme than I expected, to the point that I've set the bearing type on everything to low just to reduce the starting friction. Even then, starting friction can still be really extreme, so I've been wanting the ability to manually set the starting friction myself. Even just having more than three choices of starting friction would work so much better on my end.

Your solution is nice and simple, does just what I want, and for those who still want to have the old friction setup, it doesn't change anything. I think that can keep everyone happy, so long as we don't start complaining about the starting friction anyone else uses! Hoping we can see this feature mainlined soon. I'll spend some time implementing this in my existing .inc files.

[R H Steele]

Just to give perspective and context to this thread...for those not familiar with other discussions.
Quoting from this thread >>> http://www.elvastowe...friction-value/

wacampbell, on 29 April 2020 - 09:16 AM, said:

On north american trains ( and others I am sure ), coupler slack is the key factor on starting trains. Static friction of the wheel bearing is negligible since only one car starts rolling at a time. There's no point in fine tuning starting resistance until coupler slack effects are in place.

and...

MatarazzoT, on 29 April 2020 - 03:20 PM, said:

Most of them yes, but here for example we got twin wagons connected by a rigid connection, x68 150t Railcars, making x136 150t iron ore cars loaded 20400 metric tons with 2 engines, sometimes 1 engine working, it makes difference. But this is a Heavy Haul operation, just one of them, coupler sure is a big factor too, but resistance on railcars are more than that.

Cheers,
Thiago

and lastly...

steamer_ctn, on 29 April 2020 - 09:13 PM, said:

Given the fact that the rigid connection is between each pair of twin cars, one could assume that some coupler slack is still present between each pair of cars, and hence advantage can be taken of it in starting the train.

Starting resistance is not a well documented area of railway operation, and hence putting huge amount of effort into trying to find, or make up some values for it seems like a lot of effort, potentially without a great deal of return.

So in order to determine whether it is worth the time and effort to make adjustments, etc, a test scenario should be designed using real world data and see whether OR performs the same as the real world situation. If it doesn't, then this will support the case for changes to OR to be considered.

I will be able to take some of these test results into the work that I am doing on Advanced couplers.

So...it appears work is moving along, in an orderly manner.

[NickonWheels]

Thanks folks.

Unfortunately there is just little enthusiasm to include this code extension into the official code for unknown reasons. Sure it fixes everything and sure we should not complain about the values of others as many of us have to fix wag/eng files anyway before any serious railroading. It´s no great deal for the official code, just copy and paste/replace and a little bit updating the manual; feels a bit odd this being too much 'effort' compared to what it actually took to make this code extension so far.

BTW this version only adresses definable starting friction for static weights which most vehicles use; always planned to extend it to ORTS weight-dependent friction as well, i.e. tenders.

[pschlik]

Oh I do like that idea as well. Needing to open up Fcalc2 and get new Davis A and B coefficients just for a mass change is something I'd rather not have to do, and even then, that doesn't work for anything with variable mass. Having the sim come up with those numbers based on the mass real-time is a much better solution.

[copperpen]

NickonWheels, on 06 May 2020 - 10:02 PM, said:

Thanks folks.

Unfortunately there is just little enthusiasm to include this code extension into the official code for unknown reasons. Sure it fixes everything and sure we should not complain about the values of others as many of us have to fix wag/eng files anyway before any serious railroading. It´s no great deal for the official code, just copy and paste/replace and a little bit updating the manual; feels a bit odd this being too much 'effort' compared to what it actually took to make this code extension so far.

BTW this version only adresses definable starting friction for static weights which most vehicles use; always planned to extend it to ORTS weight-dependent friction as well, i.e. tenders.

I don't think that is quite fair on the developers. It has been stated that this is a grey area with not much information to work on. Right now the OR train acts as one solid block, no coupler slack to use when getting a train on the move. First we need proper working slack action, then some testing to see where we are at with current starting friction, and where possible compare results with what happens in the real world.

[NickonWheels]

copperpen, on 08 May 2020 - 11:36 AM, said:

I don't think that is quite fair on the developers. It has been stated that this is a grey area with not much information to work on. Right now the OR train acts as one solid block, no coupler slack to use when getting a train on the move. First we need proper working slack action, then some testing to see where we are at with current starting friction, and where possible compare results with what happens in the real world.

Slack action works reasonable right now, but this is not the point. Real world data are only useful when someone can put them in, which is principally only possible with the extended code. The thing not fair on us ORTS users is to be forced on ORTSBearingType and the calculations behind it. As said, the code extension is readily available, if you ask me I would upload it here.

I just reworked MLT´s old Bridge Line which mostly works on a self-compiled 2GB version; now I was finally able to actually accelerate cars with plain bearings..... and to overcome most of the remaining starting friction by bunching up the couplers as you told. Both this is more or less impossible with the current system but from evaluating real life switching moves (watching YouTube videos) it´s indeed possible in reality.

[NickonWheels]

[attachment=104335:MSTSWagon.zip]

Here it is, who ever wants do deal with it.

[cjakeman]

NickonWheels, on 15 May 2020 - 08:05 AM, said:

Here it is, who ever wants to deal with it.

Thanks for making this contribution.

I've downloaded it and will check it out. If it fits in with the other ORTS parameters, then I'll package it up and add it to the Unstable version of Open Rails so that it can get wider exposure.

If you have more good ideas, then it would be worthwhile using GitHub to submit your contributions in the same way as other coders.

[NickonWheels]

Thanks, Chris

According to numerous test runs with the private version it works perfectly and in conjunction with the Davis lines already established, also positive feedback.

Maybe I should figure out GitHub for more trials.

[YoRyan]

Hi NickOnWheels,

I have some interest in this feature, so I've pulled it into my GitHub repository and will submit a pull request for mainline inclusion after I've completed some refactoring and cleanup.

In the future, to make your contributions easier to merge into the master branch, please use Git for version control instead of sharing customized versions of files. Your MSTSWagon.cs file was dated from February, so I had to manually merge in changes that have been made to that file since then.

[NickonWheels]

Thanks, Ryan

I´m running back and forth about joining GitHub myself, have currently no experience with this and not wanting to mess the main code up by accident. I also sill have the fear of someone else removing such code changes because they think it´s unnecessary. If you know the formula to main code changes I´m very thankful.

[YoRyan]

Just keep in mind that if you want your features to be included into the core, it's in your interest to make the developers' jobs as easy as possible. Merging changes from concurrent efforts and adding manual documentation takes precious time and manpower. Conservatively speaking, writing the actual code is only a quarter of the battle.

The good news is that there's a well-defined process: You submit a pull request, or a set of proposed changes, that you have the ability to revise, and that the core team can approve or reject. So, mistakes are easily caught and aren't permanent. And nobody else will break or revoke a feature without going through peer review first.

(By the way, I am not a core developer either, but I will try my best to integrate and advocate for this feature. :) )