[VicenteIR]

Automatic door open/close at station stops for AI trains in Timetable Mode. I hope, it would be some way to implement it.

Regards
Oleg

[ErickC]

I would like to see correct diesel loading and unloading behaviour with a functional wheelslip control system (you can't actually have one without the other, they're mutually dependent):

• Eliminate tractive effort curves and use the real-world TE equation for output ((HP x EFFICIENCY x 375 / SPEED))
  
• Make field excitation a controllable variable (necessary for wheelslip system and realistic engine loading/unloading)
  
• Make changes in electrical load separate from engine RPM set with its own rate parameter
  
• Governor simulation with two variables: a reaction time parameter and a max deviation parameter. Literally all you need - real-world governors are complex solely because they need to be able to detect things that OR already knows.
  
• Wheelslip control system with three parameters: detection speed, response speed, and maximum slip. You can simulate literally any system from IDAC to modern radar-controlled wheel creep systems with those three parameters
  
• Sound variables for field excitation percent and engine acceleration rate (controls exhaust stream volume)
  
• Power delay parameter (sets the time between moving the throttle and the locomotive responding)
  
• Add a sound variable for wheelslip percent
  
• Supplement the RPM-dependent fuel flow chart with a parameter that sets the percent of total fuel flow when the engine is unloaded
  
• Add a NORMAL (constant RPM) / STANDBY (RPM determined by throttle position) function for locomotives equipped with HEP (this would need an associated cabview control)
  
• Add low idle section with three parameters: RPM, time delay, and an on/off flag.

How this works:

• The player advances the throttle out of idle to a given setting
  
• The throttle delay parameter waits a set time before either the electrical system or engine begins to load
  
• The engine RPM increases at the set rate, controlled by the acceleration and other parameters in the ORTS engine block
  
• The traction output increases at its own rate*
  
• The exhaust volume is controlled by two volume curves: one tied to field excitation and the other tied to engine acceleration, which means the exhaust volume should increase as power increases, but it should also increase as engine RPM increases, settling back down as the engine RPM settles at a particular speed
  
• The governor reaction time parameter controls how fast the simulated "governor" can respond to load changes. The way a real governor works is it senses changes in RPM and adjusts the fuel flow accordingly, but the system has inertia, so the governor doesn't instantly respond to a tendency for the engine speed to change. The reaction time parameter sets this time. Small load changes aren't noticeable because the system responds before the RPM changes much. Large load changes cause large RPM changes before the governor can respond. The total RPM deviation ought to be a function of the difference between electrical load percent and engine load percent, with the maximum commanded deviation set by the governor maximum deviation parameter. This makes the commanded RPM directional - increases in load tend to cause a momentary decrease in RPM, decreases in load tend to cause a momentary increase in RPM. The reaction time parameter sets the time it takes for the governor to arrest these changes and bring the RPM back to the commanded value, so that the maximum deviation is probably never actually reached. So large RPM increases, such as going from notch to notch, ought to cause the RPM to overshoot slightly and settle down, while sudden power reductions should cause the RPM to spike slightly.
  
• The traction equation will result in very large power levels at low speeds beyond the limits of adhesion. This will cause the wheels to slip. The wheelslip control system reduces electrical output (but not engine RPM) to maintain wheelslip at the maximum set percent. But because we can set the detection speed and response speed, we can then finesse the parameters to simulate different systems. For example, IDAC or WS10 should have a slow detection speed (detection by resistance) and a slow response speed (analog processing), meaning there will be large oscillations in field excitation as the system hunts for the balance. MOD3 or other contemporary radar-controlled wheel systems should have a fast detection speed (ground radar) and a fast response speed (digital processing), allowing for a near-perfect maintenance of the optimum wheel creep. Basically, you would set the detection time and response time to zero.
  
• For an older system like IDAC, the constant field excitation changes create a constant state of engine load oscillation. The delay time and maximum deviation on the "governor" cause the engine RPM to spike at power reduction and drop back down when the power comes back on. Concurrently, the exhaust streams have their volume curves governed by the field excitation (increase as excitation increases, decrease as it decreases) and engine acceleration (increase with positive acceleration, decrease with negative acceleration, somewhere in the middle with constant speed). This causes the exhaust volume to dynamically respond to the engine oscillations. The wheelslip stream increases in volume as wheelslip percent increases, just like we use curve resistance to dynamically control flange audio
  
• The adhesion curves set the limits of adhesion which determines how much of the engine's weight can be translated into usable force before wheel slippage begins to occur - just like it does presently.
  
• Because the fuel flow chart has been supplemented with a parameter that determines the percent of the fuel flow with an unloaded engine, there will be an increase in fuel flow as the throttle is moved from idle to Run 1 despite the engine RPM staying the same, or even decreasing (generally the latter in the real world). Because the field excitation parameters control both the total percent of engine power sent to the engine, and the rate at which the system responds to throttle input, then there will no longer be sudden spikes in output when going from idle to Run 1. In fact, locomotives with constant RPM at multiple power settings, like an F40 in NORMAL mode or a GE in the mid throttle notches will now have correct fuel flow and traction response. A NORMAL / STANDBY function and control would mean that HEP locomotives would no longer require separate SMS files or ENG files. You'd just take the locomotive out of STANDBY and put it in NORMAL and the RPM would increase to the set value for HEP delivery, the total available traction output would decrease by a percentage set with another parameter, and the fuel flow, exhaust volume, and loading would be controlled as outlined above.
  
• Similarly, if a simulation of transition were ever implemented, then the engine would respond accordingly because the sudden drop in load would command a spike in engine RPM and a reduction in exhaust volume. In fact, I could add a frequency curve controlled by load percent to the turbocharge stream which would cause the turbocharger pitch to decrease as the engine unloads. When the load comes back on, the changes would reverse.

With this system, it would finally be possible to simulate a GE locomotive (the present inability to do them justice is one reason why I haven't made any) because the electrical parameters would be separate from the RPM parameters entirely, and you'd get a dynamic representation of the exhaust chug that changes with the actual load.

*On EMD locomotives this is slower than the engine RPM changes - this was an intentional sleight-of-hand designed to make crews feel like the locomotive was loading faster. If you watch an F7 and a GP7 load, you'll notice the ammeters increase at the same rate, but the F7's engine powers up at about the same rate as the load increase, while the GP7 powers up instantly

[pschlik]

Completely agreed with Erick on that one. From my view, my absolute biggest pet peeve with OpenRails at the moment is the total lack of reasonable slip and slide control simulation (it's my belief that the fancy adhesion system we have is worthless, sometimes even detrimental, without also having fancy wheel slip protection systems), and just considering the necessary changes to implement non-jank WSP brings ya down that whole rabbit hole of ways to improve the DE simulation. Steam's gotten a pretty nice treatment, and it would be nice for the diesels to get that kind of love.

Now, I would also like to further emphasize the point of transition. That's a really big thing that is completely missing from OpenRails and should not be treated as a side point to a better electrical simulation. A tremendous number of diesel-electric locomotives have some combination of motor field shunting, motor group transition, and generator transition; without these Open Rails is effectively preventing the realistic simulation of a majority of all diesel-electric locomotives ever made. Transition systems are a vital part of electronics and leaving them out makes everything take power as if it were an AC.
After all, I want to be able to suffer through the nightmarish sequence of transitions the GP35 features...but right now the best I can do is a GP35ACe.

[ErickC]

I totally agree. I mentioned it there as a sidenote simply to demonstrate that getting an accurate load/unload simulation now would automatically result in correct engine behaviour if transition was ever implemented.

The wheelslip system has been really getting on my nerves lately, especially because you can't up the simulation rate much before the wheels start slipping like crazy (I end up upping the rate a lot when taking screen caps of new releases - getting from photogenic location to photogenic location takes time, y0). You get a touch past the maximum slippage and the wheels start spinning at mach 3. No biggie, drop a notch and add a little independent brake - nope, still going mach 3. Reduce power to idle. Okay, the slip stops. We started slipping in run 5, so let's advance to run 1 - mach 3 again. You have to reset the adhesion model or stop the train to stop the slipping even in power ranges where the wheels shouldn't slip at all. And when you're starting a heavy train, adding independent brake doesn't help at all. So I end up doing basically what IDAC would do - I hit F5, watch the adhesion percent, and jockey the throttle back and forth so the train gains momentum in short spurts, being careful not to let the wheels hit the max threshold for even a millisecond, because then you've got to stop the train and start all over from the beginning.

Cooling, that's another big one. You start the engine and the temperature just keeps climbing and climbing no matter what parameters you set. We eventually will need a simulation of the radiator fans and the sound triggers to go with them.

Mind you, I really do appreciate that our basic physics system is vastly superior to the alternative simulations. A lot of stuff that we take for granted requires scripting in TS20XX. There are just a few things that could be improved.

[pschlik]

Agreed on all points there...I know the pain of the supersonic wheels, which I think is an unintended side effect of the way traction was coded (it looks like the simulation is using the "true" speed of the locomotive to set the amount of tractive force output when the wheel speed should be used instead) but that's a topic for another post where hopefully someone more informed about the inner workings of the physics could comment. I hope to talk about that more this week, assuming I actually have time.

But in general, Open Rails definitely has the best train dynamics simulation and that's why I'm bothering with OR in the first place. It's just the old MSTS leftovers that work to spoil the rest of the pleasing stuff. Still, anything is better than TS1's wheel slip 'simulation.' And that stupid points system that penalizes you for wheel slipping...so much nonsense in that sim.

[conductorchris]

I would like to see explore route and timetables be able to load the static consists that are in an another activity activity. Perhaps explore route could also load traffic from another activity.

It seems like this wouldn't be hard to program but would make a huge jump in the fun of running open rails.

Christopher

[bobwdude]

That idea reminds me a bit of Train Simulator 20XX's 'Quick Drive' functionality - you don't necessarily have a timetable or work order and you can muck around as you wish, but you'll still encounter AI and static trains in the world.

I'd also love to see improvements to diesel simulation. Open Rails already does physics over the entire train rather well, but building further on the existing simulation would help immensely.

On a content creation side, I would love to see more 3d cab models being done for rolling stock as well as work to remove the continued dependencies on MSTS for content. In some other communities, people get quite excited to try out Open Rails, only to find that the route that they want to run requires assets from those default 6 routes from MSTS. Having a new open source asset library built to 2021 standards would help us finally move away from the past, as well as open up doors for new community members to join.

[ckawahara]

Programmers to implement all the wanna-haves".

[ErickC]

That, too. I'd totally implement some of these things if I knew the first thing about programming, but with all the Freud and Erikson they're shoveling into my brain, I don't think that's a skill I can really put the time into at the moment.

I will say that one more thing that would solve some problems would be to set the external SMS volume of the player's loco to zero when in the cab instead of deactivating it. The same would apply for the internal SMS in external views. That would solve the problem of cued looped streams suddenly cutting in/out without playing the intro every time you change views. It also opens up the door to bringing the external SMS volume up in cab views when the doors are opened. Just fade it up to 100% when the door opens and back to 0% when the door closes.

[mopacfan]

P.S. I would like to see this year the start of TSRE becoming fully integrated into the OR software as a step that TSRE will serve as the official RE for OR.