Dynamic Brakes and Shuswap route

[crstagg]

Post the player and Trail ENG files so we can possibly identify the problem.

[R. Steele]

There's a thread at Elvas concerning the same circumstance. I have read both threads and no logs or what version of OR people are using when the ?problem occurs.

I was running OR version X3700 and using the standard consist provided with the activities (full player in lead, two TRAIL eng as supplied by SLI ) and encountered no problems with dynamics (post#13).

That said I have modified many AI and Trail engs in the trainset to full engine files, however, I may have neglected or missed renaming the files. So after reading Baldwins post I'll take a look and see what's in the files.

So, in agreement with Charles, but with the addition that some logs and what version of OR is used may be helpful in finding the problem.

[geepster775]

X3741

If I replace the two TRAIL locos with AI, the stalling still happens. If I replace only one TRAIL with a player and leave the other, I end up with two pulling being offset by the third functioning as a brake sled. Under those conditions, I can only exceed 40 mph on the downgrades. Only when the player version is used in all 3 loco positions, does the problem go away. It would appear both AI and TRAIL are considered 'incomplete' by OR standards.

By contrast, the windmill train pack was released with player-only ENG files for all the UP SD70M's. No problems there.

I also eliminated the moving start on the DRGW train to see if that had any impact, since the successful windmill train starts at 0 mph. But no impact discovered.

Then again, its not like handicapped AI and TRAIL eng files are essential to OR. I purged my AI and TRAIL from my main installation long ago and never noticed the problem creep in. I ran these experiments from a duplicate test installation that has all 'OEM' files.

[crstagg]

X3741

If I replace the two TRAIL locos with AI, the stalling still happens. If I replace only one TRAIL with a player and leave the other, I end up with two pulling being offset by the third functioning as a brake sled. Under those conditions, I can only exceed 40 mph on the downgrades. Only when the player version is used in all 3 loco positions, does the problem go away. It would appear both AI and TRAIL are considered 'incomplete' by OR standards.

By contrast, the windmill train pack was released with player-only ENG files for all the UP SD70M's. No problems there.

I also eliminated the moving start on the DRGW train to see if that had any impact, since the successful windmill train starts at 0 mph. But no impact discovered.

Then again, its not like handicapped AI and TRAIL eng files are essential to OR. I purged my AI and TRAIL from my main installation long ago and never noticed the problem creep in. I ran these experiments from a duplicate test installation that has all 'OEM' files.

Again. Please post the ENG files use that cause the problem along with the Player ENG.

[geepster775]

It's not the ENG files themselves that are the problem. Its more the case that the different types of ENG files represent a difference in input that changes how OR responds and produces it's physics output.

If I go with original consists on the Ford Fast (2 TRAIL trailing), and don't touch the dynamics all the way to between Mack and Ruby where speed decreases from 70 to 50, dynamics slow the train properly, but then I coast to stop with 100% throttle about halfway between the switches at Ruby siding.

When stalled, if I uncouple the lead unit from the rest of the train, the lead unit will accelerate away. When I re-couple, the consist remains glued to the spot at 100% throttle.

If I change it to 3 player ENG files in the consist, acceleration up to 70 mph is a bit snappier, dynamics work as intended, and I can always come out of dynamics and get right back up to 70 mph track speed.

[Claude350]

Replacing the AI and trail units has fixed the issue for me. I believe it has something to do with the units not having throttle or dynamic brake sections in the file like the driveable units.

[baldwin]

Been experimenting. I put the throttle and brake data into the two Trail engines of the fast ford consist. That made no difference. Then I renamed the trail eng files, did a copy/paste of the player eng and renamed the copy to TRAIL and edited the internal calls to match. Then the problem went away. Then I edited the controls section out, leaving the cabview. Still worked normally so it seems that somewhere we have a bug.

[crstagg]

Replacing the AI and trail units has fixed the issue for me. I believe it has something to do with the units not having throttle or dynamic brake sections in the file like the driveable units.

BUT according to Geepster (who would not upload his ENG file so that those of us who do not have the route could help) ENG files have nothing to do with the problem.

[R. Steele]

Just read a post over at ET from copperpen

excerpt: "...so it seems that somewhere we have a bug that does not disconnect the dynamic brakes of units without a cabview, linking that to the throttle instead so opening the throttle puts the trail engines into dynamic braking, but the HUD shows increasing power on all engines in the consist . Running with TRAIL units in V1.1 does not cause the problem."

[geepster775]

BUT according to Geepster (who would not upload his ENG file so that those of us who do not have the route could help) ENG files have nothing to do with the problem.

Instead of waiting on others to supply you widely available files that you simply haven't paid for yet, you could contribute to the problem solving by running an activity in some other payware route from some other vendor that you do have and report your findings using that vendor's ENG files. Already we have this happening with MLT Shuswap and SLI Green River.

[geepster775]

so it seems that somewhere we have a bug.

A bug in the 'backwards compatibility' section of the house. If you are someone who dumped their AI and TRAIL as totally unnecessary for ORTS, and which only exist today to accommodate dual use with MSTS, then you never saw the problem. Low priority fix to me, and maybe a proper trebuchet to catapult others into the MSTS-less future.

[baldwin]

A bug in the 'backwards compatibility' section of the house. If you are someone who dumped their AI and TRAIL as totally unnecessary for ORTS, and which only exist today to accommodate dual use with MSTS, then you never saw the problem. Low priority fix to me, and maybe a proper trebuchet to catapult others into the MSTS-less future.

I dumped AI and trail units years ago, long before ORTS, could never see a use for them. The problem with this bug is that it will apply to ANY unit that does not have a cabview whether freeware or payware, and I suspect that quite a few people will not want to be fiddling in an eng file or con file to get something to work.

[tbundy1982]

I agree, Baldwin. Since the AI/Trail .eng files are a large part of our history in MSTS, IMHO it would behoove the OR Team to find a solution. Streamlines made some very popular payware routes that work 'out of the box', and this bug pretty much spears everything I've ever owned by them. Being somewhat of an MSTS power user now, I have the ability to alter files to fix it on my end. I don't think that is a practical solution for everyone, though.

I've been upgrading the most needy rolling stock for the past couple of years and I don't feel like I've upgraded more than 1/10th of my rolling stock in that time. Better OR compatibility = better use of hobby time in that respect.

I commend you all for working to figure this out. I only had time to run a few activities and understand that it wasn't a global problem.

Tyler

[R. Steele]

I'm reading in the threads that this problem is being looked at, however, the problem is not being duplicated.
Someone that is encountering the problem with some consistency should post what engines are being used.
Perhaps, zip up the .eng files so they can be examined.

[geepster775]

Streamlines made some very popular payware routes that work 'out of the box', and this bug pretty much spears everything I've ever owned by them.

Spears? Nonsense. Are we saying that the requirements to correct Maxpower and other physics tweaks are not a burden upon the users, but editing consists (something we do everyday) to eliminate MSTS handicapped ENG file variants that were never needed by ORTS to work around this bug is such a huge burden?

I don't care about respecting the history of limitations that MSTS threw in our faces that produced a 67% bloat in engine file headcount, and which has a direct contribution to this problem. Going forward, I want to see ORTS code written around the needed player ENG file definition and that efficiently ignores the 67% bloat. Even if it means forcing users to whip out their Conbuilder once in a blue moon.

My gawd, if we can't handle minor consist substitutions such as this to shed some of the stupid bloat, then how can we ever handle a replacement for the .S file and the planned obsolescence of TSM when that day comes?