[engmod]

omsriguru, on 23 May 2022 - 07:07 PM, said:

What is "automatic tuning turned on" ? I did not get U.

Check your options, you have set it.

[omsriguru]

Weter, on 23 May 2022 - 07:55 PM, said:

On experimental options tab, there is an option for automatically tune settings, to maintain TARGET FRAME RATE. I guess, Derek have meant that.
I ran ORTS with 2GB RAM, but XNA version 1.3.1 - not monogame 1.4
the MANUAL says, LAA is needed for windows to use memory addresses, higher, than 2GB, so for 4 it might be suitable (trying one and other setting on game sessions, you can compare graphs of memory usage on diagnostics HUD page for seeing, what will fit to Your machine better), but it not believed to affect adhesion performance... However, adhesion must be computed very frequent...

What about sanding - I have the same observations: it makes adhesion even worse for mysterious reasons, so I turn it off as soon, as train gains some adhesion and don't use it further. Maybe it's a bug...

3MB log seems cool!

Thanks for ur prompt resp. Sanding is certainly a big bug and they need to rectify this. Sanding must improve adhesion...and not kill it. Hope the makers of ORTS will address this in their updates.

[omsriguru]

Weter, on 23 May 2022 - 08:26 PM, said:

If so, would You please arise the question about this issue on "Maybe, it's a bug?.." branche's thread: your log-files and descriptions of problem will be useful proofs.

If I guess right, steamer_ctn is believed to be the head developer of physics model, including wheel-to-rail interactions.

I just did that... Thanks

[engmod]

omsriguru, on 23 May 2022 - 08:20 PM, said:

Sanding is certainly a big bug and they need to rectify this.

Your testing is in no way good enough.

Sanding does increase tractive effort in the area below the continuous tractive effort value.

It can be checked and verified with the extended HUD.

Unless there is a new bug that I have not seen, I run Carlo's latest all of the time.

[Weter]

Test is far from being complete, that's fact, but, what's more important:
In real life, SANDING IS EXPECTED TO INCREASE AN ADHESION, and raising of tractive effort (which obviously can't exceed maximal value, counted in ideal-dry and perfectly surfaced wheel-to rail pairs(contact spots), but actually always will be lower), is a consequence, but not a direct result of sand presence.

If our simulator increases effort, during same poor adhesion's presence, wheelslip will certainly become even havyly, isn't it?

[R H Steele]

I have to go along with Derek, one of my physics mentors.

In my experience, with engine parameters and proper OR physics set up correctly, sanding in wet rail conditions works as expected. A good test activity, apart from the preferred method of using the test track under controlled conditions --- to make the test repeatable and verifiable --- is the activity "What goes up" on the BNSF Scenic Route.

There may be room for some wheelslip improvement if you take into account nuances in different wet rail conditions --- rain, snow or ice...and how long it takes the rail to heat up. But, a big bug...no, I don't think so.

[Weter]

Addition:
First, to Gerry.
I find Your note right.
As an advance, there is CTN test route with various grades, laid-down in compact area, what saves time and makes tests more predictable and effective;
there is test rolling stock there (I mean boxcars with preset load for forming test consists to given locomotive, for the case, being discussed here).
Also, there are plenty of MSTS-stock with inaccurate physics, as it treated badly by MSTS, so either haven't been taken in account, or incorrectly interpreted, hence authors intentionally distorted some values for life-like MSTS performance with a model.
I remember a comment, roaming from *.eng-file to *.eng-file:

Comment (
Don't try to set real values: it will ruin MSTS physics!
With given values, this locomotive will be able
to pull train with X ton mass up on Y% grade at Z mph speed
)

So, I admit, current engine characteristics shall be verified.
If Derek, or other experts would agree to see the file, You may show it, by attaching to Your post.
ET software allows not to zip *.eng-files for being directly accessible for forum users.

[Weter]

Addition 2, by myself:
Unfortunately, I don't remember the formula (but it's in the book, that is available), so let me say in more common words:
Tractive effort is borning at contact wheel-to rail spots of pulling locomotive, as a sum of vectors:
- the momentum on wheel's rim (rolling-surface) - what is given locomotive's ability to produce torque and...
- the adhesion-depending force, which also depends on weight, pushing down every driving wheel and some conditions (material, temperature, weather, surface, etc.)
Hence, if negative value of the given adhesion force exceeds the locomotive's momentum - the sum will become negative too (subtracting greater from lower), so all momentum will be eliminated by adhesion and no positive tractive effort will be produced.

The rest is about formulae, used inside ORTS core. If traction will be artificially increased by program's mistaking logic, wheel slip will increase.
Right approach, this way, would be adhesion improvement, at the same tractive effort, until throttle setting stays the same.

[Weter]

Third:
There are two variants of friction, (actually, the friction force does produce traction, while adhesion is one of it's factors):
Stationary(maybe static?) — (not sure, whether this is right English term),
and slipping friction.
Second is much more less, than the first. In our case, that means, that once wheels begin slipping, there is no way to recover them to attitude with static friction, without temporary decreasing momentum (throttle setting), so tractive ability will be lost, and this is implemented in ORTS now. The question is - how accurate?

Same if for die-cast iron brake pads: once pressure will exceed some value, the friction (and brake force), will immediately drop-down very significant.

So, static friction is useful for traction producing, slipping friction is undesirable. And third kind - the rolling friction is useless, but it's low values give a great benefits for railroading, as it "works" on coasting car's wheel-to-rail pairs and roller bearings, so it's very low value in case of steel-to-steel rolling, allows to pull very heavy trains by relative small power.

[PerryPlatypus]

I don't think I've seen anyone mention it specifically in this way, so here goes:

You are most likely experiencing severe slippage issues due to low frame rates on your machine. In the vast majority of cases where people struggle with adhesion on Mullan, that's the reason. If you're getting less than about 20 to 25 FPS, it becomes almost unavoidable. This is because, for reasons beyond my comprehension, the coding of the Advanced Adhesion model has been heavily linked to frame rates. Until some physics guru in the OR development team can reinvent the adhesion model to no longer be so dependent on frame rates, this is going to keep happening to users on low end machines and/or on resource-heavy routes unfortunately...

And as has been mentioned before, what we *really* need is someone who is capable of programming proper AC traction physics, controlled "wheel creep" technology, realistic automatic sanding and re-adhesion, etc. (OR's current "Antislip" variable that physically moves the throttle position down when slippage occurs, but does not gradually throttle back up afterward is a far cry from anything I've ever seen used on modern real world locomotives)