ORTS/MSTS physics compatibility? (Official resource for ORTS developers)

[NW 2156]

Good Evening, On behalf of the ORTS development team I have been asked to collect information pertaining to the issues of incompatibilities surrounding out of the box MSTS commerical products not working correctly in ORTS.

The goal of this thread is for everyone to report problems found with MSTS commercial content that does not work correctly in ORTS because of issues like physics, braking, couplers, eng/wag file perimeters, route problems, activity problems, etc.

If any problems are found please report them here so the information can be forwarded to the ORTS development team for evaluation and possible corrections in ORTS V1.3 and V1.4.

Helpful information would be any and all issues or errors and any corrective actions taken? The name and source of all routes, trains, activities and their sources would also be helpful.

Also please post any ORTS error log messages in a .txt attactment for evaluation.

Thankyou.

Robert
ORTS Research Dept.

[cjakeman]

The goal of this thread is for everyone to report problems found with MSTS commercial content that does not work correctly in ORTS because of issues like physics, braking, couplers, eng/wag file perimeters, route problems, activity problems, etc.

Yes, we will continue to fix problems where it is practical to do so.

However, the intention here is to identify SOLUTIONS to problems found with MSTS commercial content that does not work correctly in ORTS which cannot be fixed through coding.

Many solutions have been found and lie scattered throughout the forums. Several helpful people have attempted to document some of these solutions. We would like to pull this advice together and then provide a Conversion Guide for problems that cannot be overcome through coding.

Which nuggets of good advice do you recommend?

[geepster775]

A couple of thoughts, if I can wedge a few comments in between ftldave's flurry of helpful replies -

------------ ---------- -------

Lighting definitions in ENG files are often inadequate for all the possible operational situations. Given the new flexibility in Open Rails, this creates a need for player mountable engines in lots of places within an activity now, and we should be able to reach the point of dropping the need for AI and TRAIL versions and using Player ENG files exclusively, with all the other lighting situations properly coded, either by vendors in the ENG file or by the development team (should rear DPU lights be auto OR driven like AI lead units?, or user controlled with more user headlight control options?)

Air Flow Physics seems a bit odd. When I break the trainline to do some switching and rejoin my train sitting there in emergency, and reconnect the hoses and start pumping air, I notice that the compressor seldom runs (shouldn't it be on constantly in that situation?). While the brake line is filling the compressor runs for like 3 seconds, and goes off for 12-15 seconds, and then kicks on again. The train line is charging, yes, but the compressor doesn't seem to be in sync with the rate of airflow going on. The "handshaking" between various ENG values are just are not right there. Both SLI and DW engines do this.

When developers add features, what I see is they often whip out their default Dash9 on Marias Pass to test. Not good enough. These commercial developers are looking at selling activities that run from one end of the route to the other, activities emboldened by Open Rails features. I don't think many on the development side actually are developing the same complex level activities to test Open Rails features. Sorta flying blind there.

Signals - We need to do something quickly with the Lionel-ish CTC system we have - and do it BEFORE these commercial developers get to building their complex activities. It is SO UNREAL when Stop signals at an interlocking clear before the opposing movement vacates the interlocking. We are SO DONE with using invisible cars on the opposing train to add the realism that should be in the code. Three months ago I added a Trello card for that one, putting the "cog" into the "machine", but that one needs to be accelerated so we don't end up creating new activities that end up broken again at a later date. Let us all admit that MSTS activities are probably broken now with all the new OR features, and I'm okay with that, content with building new Open Rails activities - But only once. Get those things which impact timing like prototypical signal code line delay in there now, before those Open Rails activities are built by commercial developers or users.
Proper example in this thread

https://www.trainsim.com/vbts/showthread.php?325818-EB-Priority-Z&p=1904393#post1904393

Player is stopped, AI approaches at 60 MPH and passes. In order to get a minute and a half code line delay (the real deal), at that high AI speed I needed to add an invisible car consist nearly as long as the original AI consist.

Helpers - I don't think Open Rails is "there yet" when it comes to inserting multiple helper consists into a train as part of an activity. Its 90% there, but that 10% gap is highly tricky if not fatal to activities. You wont discover that running Dash 9's on Marias Pass.

https://www.trainsim.com/vbts/showthread.php?324930-Tennessee-Pass-coal-train-run&p=1895632#post1895632

Here is another activity climbing DRGW Tennessee pass, inserting a mid train and rear end helper at the base, and cutting them out at the top of the hill. The proper way is for the player to take control of the the helper and insert itself into a train. Unfortunately, the fragility of the life of player path makes that impossible. The work around is embarrassingly non-prototypical. The upcoming Mullan Pass route is going to be ripe for these types of helper insertion/cutout activities. How are these commercial developers going to pull this off?

Maxpower (naturally) since OR is underpowered using MSTS values, which mucks up activities where trains are running underpowered and need all the horsepower they can produce. Minor tweaks to ENG files fixes it, tho.

Exhaust smoke is usually too strong in OR, okay in MSTS. Minor tweaks to ENG files fixes it, tho.

On the good news front, new releases from Diesels West come with proper OR maxpower values now. Finally one vendor has fully turned the corner. DW just hasn't hit the advanced activity wall head first yet.

[Vince]

With regard to:

Air Flow Physics seems a bit odd. When I break the trainline to do some switching and rejoin my train sitting there in emergency, and reconnect the hoses and start pumping air, I notice that the compressor seldom runs (shouldn't it be on constantly in that situation?). While the brake line is filling the compressor runs for like 3 seconds, and goes off for 12-15 seconds, and then kicks on again. The train line is charging, yes, but the compressor doesn't seem to be in sync with the rate of airflow going on. The "handshaking" between various ENG values are just are not right there. Both SLI and DW engines do this.

I had this on the gp38 I distributed with the lirr_install.zip in the f/l. I tinkered with the NECX102.eng file (as I had to do with the default stock when MSTS first came out!) I remember the compressor flow rate too high and cutout too low (or visa versa)
You could look at the LIRR gp38 necx102 and have a look at it's eng file and how I set it up. Free to copy!

It's like Déjà Vu all over again!
You remember . . . those early MSTS physics wern't so hot at all and needed MUCH 'tinkering'.

regards,

[ftldave]

A couple of thoughts, if I can wedge a few comments in between ftldave's flurry of helpful replies -

I have no flurries to report about payware and OR, sorry, because I have not tried to run that much commercial stuff in OR, except Valleypass locomotives and rolling stock. Other than tweaking exhaust smoke, BLW/ZT stuff has been good in OR, for me.

[cjakeman]

Other than tweaking exhaust smoke, BLW/ZT stuff has been good in OR, for me.

Can you point to any advice on how a novice should approach "tweaking exhaust smoke", I wonder?

[ftldave]

Can you point to any advice on how a novice should approach "tweaking exhaust smoke", I wonder?

I still use Markus Gelbmann's MSTS Diesel Power Updater (DPU) VX3.0 (dpu_vx3_0.zip in the trainsim.com file library), probably the easiest utility for a novice. But it usually fails to back up .eng files before making changes like it's supposed to, so best practice is, of course, to back up files manually before testing exhaust smoke or any other tweaks.

[wwhall]

geepster775 brings up some good points. I haven't tinkered with the air settings for OR locos because I know that the OR handling of air brakes, though hugely more prototypical than MSTS, is still a work in progress.

OR does correctly emulate coupling to cut of cars and opening the angle cock causing the train to go into emergency. That is prototypical. Why? Because the air valves on the cars sense the quick reduction in air pressure in the train line as the air from the coupling train flows into the empty train line of the cars being coupled to, causing the brakes to into emergency. Now, in prototype, particularly with short cuts of cars, old heads try to prevent this by opening the angle cock very slowly. This would cause a more gradual reduction in train line air pressure while, at the same time, air flow from the locomotive would start to increase train line air pressure. It can be a tricky maneuver to pull off, but I see it done all the time.

Now, what OR does NOT do prototypical, as of now, is to correctly emulate air compressor behavior on MU'ed locomotives. In prototype, the air tanks and compressors of all the MU'ed locomotives contribute air to charge the brake system--currently in OR, only the player locomotive contributes air, even though the compressors of the MU locomotives are running. That is a deficiency that needs to be corrected. Distributed power locomotives cut into the train or at the rear in prototype operation also contribute air, but, in OR, the compressors on those locos do not even run. In prototype, manned helpers behave the same way--contributing air, but not controlling brake sets and releases, unless the helper engineer cuts his control valve into the system.

When it comes to coupling in helpers, here's a look at how it was/is done in prototype. I watched it being done many times on Tennessee Pass, with both mid-train (swing) and rear helpers. There were variations, but here is an example: the eastbound train would pull into the yard at Minturn, stopping with the point at which the train would be broken in two several locomotive lengths west of the crossovers. The brakeman would close the angle cocks on the cars at the point where the train would be broken in two. While this was happening, quite often the rear helpers would be coupling up at the rear. The brakeman would pull the pin to uncouple the front part of the train and the engineer would pull the front part of the train clear of the crossover. Then the swing helper would come from the adjacent track, with the brakeman lining it through the crossover to a coupling with the rear part of the train. A note here--on TP operations, the swing and rear helper engineers would often be running from the rear unit of their lashup, thus they would be "backing" eastward up the pass. This was done so that, when they cut off at the summit, they could proceed westward to Minturn without having to change cabs in their lashup. Once the swing helpers were coupled up and the air line on the rear half of the train pumped up and crossover relined for the main, the the swing helpers would pull the rear half of the train up to a coupling with the front half. At this point, control of the air would be "handed off" to the road engine, brake tests made, and the train would head up the hill. Cutting off of the helpers at the summit was done more in less in reverse order, though it become a more common practice in later years to leave the mid-train helpers on the train all the way to Kobe or Malta (sometimes all the way to Pueblo) for additional dynamic braking.

In OR, I have tried to build a simpler, but still prototypical activity, where an eastbound train (the player train) picks up a mid-train helper at Castilla on the Soldier Summit route. I've tried this using extended AI shunting functions to have the player split his train at the crossovers, allow the helpers to come through the crossovers, couple up to the rear half of the train, then pull it up to a coupling with the front half. At that point, the engineer of the player train takes over and the train proceeds east. As geepster775 notes with his attempt on TP, I haven't figured out to make the switches and signals in OR behave correctly to make it all happen. If I was trying to do this in yard tracks where signals aren't an issue, I think that I could make it work. I may to do the same thing in the yard at Helper to see if it would work there.

Yes, OR does need a realistic code line delay in all of its signaling.

As for diesel smoke, OR handles it much more realistically, but it still needs work. As it stands now, using OR's "include" .eng file, there is still some strange mathematical relationship between the MSTS exhaust parameters and those in the OR file. No one on the OR team has explained what that relationship is. Also, OR does something that MSTS never did--simulate smoke from turbo lag. The only issue that I have with that is that the smoke becomes more intense on throttle up as one moves up the notch scale. In a prototype 4-cycle prime mover (GE and Alco, for example), the heaviest turbo lag smoke is coming off of idle before the turbocharger can spool up, with less turbo lag smoke in the higher notches. I've tried umpteen smoke settings in OR, but I can't totally overcome the heavier turbo lag smoke at higher RPM issue. Part of the problem, I think, is that unknown relationship between MSTS and OR smoke settings. I think that it's time for a "pure" OR .eng file that has no dependence on the MSTS .eng file.

Just my thoughts on some of this. The good news is that OR has come so far beyond MSTS that this kind of stuff can even be a topic of discussion--MSTS did almost none of it.

[NW 2156]

Yes, we will continue to fix problems where it is practical to do so.

However, the intention here is to identify SOLUTIONS to problems found with MSTS commercial content that does not work correctly in ORTS which cannot be fixed through coding.

Many solutions have been found and lie scattered throughout the forums. Several helpful people have attempted to document some of these solutions. We would like to pull this advice together and then provide a Conversion Guide for problems that cannot be overcome through coding.

Which nuggets of good advice do you recommend?

Chris, Thanks for adding this information. I have asked Nels about a new seperate area for this discussion in the ORTS section. Still waiting on a response.

Robert

[OrangeBlossom]

I tend to think that payware vendors who only produce rolling stock face a much easier transition from MSTS to ORTS than payware vendors who sell a complete experience. I define a complete experience as routes, locomotives, rolling stock, and activities all bundled in one product. Vendors who sell the more complete experience are behaving like they are stuck in the mud, unsure on how to proceed given the new features and user options beyond the vendor's control within the new product. For them, planning for deployment has to be a much greater burden. I would hate for the lack of dialog between vendors and programmers to result in more vendors being driven towards a simpler approach and away from building and delivering the complete experience.

Other than tweaking exhaust smoke, BLW/ZT stuff has been good in OR, for me.

BLW content has always been slightly overpowered in ORTS, and greatly overpowered in MSTS. Supercharged trains generally can be good for everyone.

We should realize that your experience is not the result of a conscious choice by this vendor to build ORTS-ready content, but merely an alignment fluke where ORTS suddenly matches their past practices which were not accurate for MSTS. More like when a broken clock ends up being accurate twice a day.

[OrangeBlossom]

I think that it's time for a "pure" OR .eng file that has no dependence on the MSTS .eng file.

Although I agree with this, I don't believe our vendors are willing to produce dual files specific for both environments. So little return on that time investment. They really should produce one version in support of wherever the majority of users are.