Animation, tied to diesel's rotation shafts, sheaves, fans, compressors, etc.
#1
Posted 18 January 2025 - 01:30 PM
Would it be interest in having the animation of the rotating fans connected to some physic states of the locomotive? And how is the fan rotation triggered/stopped in real world?
#2
Posted 18 January 2025 - 02:00 PM
Far as the dynamic cooling fans, I would THINK as soon the dynamic's are applied the fan(s) would come on. Maybe they speed up as more is applied and more heat made??
This is all just guessing on my part, and I for one would really like to see this!!
#3
Posted 18 January 2025 - 07:16 PM
https://www.elvastow...post__p__314601
Cheers,
Marek.
#4
Posted 18 January 2025 - 08:46 PM
#6
Posted 19 January 2025 - 06:34 AM
#7
Posted 19 January 2025 - 06:50 AM
They can also be added as freightanims so they spin continuously but can be configured to spin at different speeds.
#8
Posted 19 January 2025 - 07:29 AM
superheatedsteam, on 18 January 2025 - 07:16 PM, said:
https://www.elvastow...post__p__314601
Marek,
I would not try to conflate the two. AFAIK MSTS animations will continue to function and gITF animations are a separate issue. When and where gITF animations are implemented remains to be seen, "hope springs eternal". I would not want to see MSTS animations deleted. As of this writing freight animations have been working in OR for some years now, and work perfectly. Throwing the MSTS freight animations away and even the MSTS shape file away in OR would be a fools errand. Not to mention all the support files which explicitly site ".s" references to the MSTS shape file.
It is clear that legacy MSTS shape/animations have to remain. UNLESS there is a fool proof method of translating MSTS shape/animations to gITF a symbiotic relationship will have to be added to OR to effectively allow BOTH types of shapes/animations. With this in mind the full implementation of gITF has for the mean time stalled. We would all like to see the upgrade to this format, but only if all of the "old" content is NOT trashed in the process. Something that OR can ill afford to do.
With all of the above pre-amble, there is nothing standing in the way of triggered animations with the current MSTS freight animations.
Steve
#9
Posted 19 January 2025 - 08:43 AM
Csantucci, on 18 January 2025 - 01:30 PM, said:
Would it be interest in having the animation of the rotating fans connected to some physic states of the locomotive? And how is the fan rotation triggered/stopped in real world?
The triggering of COOLING fans is based on temperature. Already in OR, as seen in some aspects of the HUD, there is a reference to temperature I assume in the engine compartment. For the electrical/mechanical engineers among us, we are aware of things called upper and lower trigger points. In the case of COOLING, the simple and effective implementation would be that once a certain temperature is reached, the fan(s) is/are triggered ON. Now, how and where the temperature rises in OR, on what curve, is a bit of a mystery as of this writing, especially for the diesel electric setup.
The flip side of this of this is of course when to turn the fans off. Some sort of ersatz rule of thumb would have to be used as I assume or doubt there are any tables out there that indicate how much CFM (cubic feet per minute) a particular fan is capable of on a given locomotive. To be even more precise, you would have to take the ambient temperature into account as cooler OUTSIDE air would effect higher rates of cooling in the engine compartment. I believe we have no implementation real or otherwise of outside air temperature in OR.
So, to makes things as simple as possible and as pleasing visually you would have:
Upper Trigger Point Temp, switches the animation ON
Lower Trigger Point Temp, switches the animation OFF
Temperature Loss While Fan ON, assuming that the engine is at idle, an ersatz factor (curve) to determine how much heat is lost thru the ventilation of air. Of course this can get more complex than needed if we decide to model caloric gains/losses, this is a rail SIM, so maybe keep it SIMple to start with.
The above proposition would reside in the .eng file.
I am sure that the last factor (Temperature Loss While Fan ON,) can be improved on over time, with real data, but I do not think that OR needs that much precision to start with!
Unlike the COOLING fans, the DYNAMIC fan does have rotation speed factors added. As the users will note, when higher and higher values of DYNAMIC braking are used, more heat is generated in the resistive pack/array of the engine and thus the fan rotation speed is increased to cool said pack/array at a greater rate. The easy way out in MSTS/OR, has been to associate the WHEELS parameter with the animation of the DYNAMIC fan. This of course is unrealistic as the DYNAMIC fan is always in rotation as the locomotive moves which is NOT how DYNAMIC fans operate in the real world. Added is that the rotation of the DYNAMIC fan changes direction when the engine is placed in reverse!
As with the COOLING fans, there would be a trigger point to turn the DYNAMIC fan on, but there would have to be some non-linear element added to either the animation (pretty hard to do with MSTS shape file, IMO) or to the animation code in C#, for this specific case based on the position of the DYNAMIC brake lever in the engine. The implementation of this is of course more challenging than that of the COOLING fans. Some might argue, rightfully so, that the visual aspect is a "fools errand" as given how limited the rendering is (capped at 50/60 frames per second) a user would not be able to tell if the rotation speed is 1000 or 10000 RPM, thus why bother! As with cinema, those wagon wheels (in american westerns) seem to be turning backwards or frozen still, because the classic film rate was 24 frames per second. (All those college years acquiring useless information, seems to be useful here in 2025!)
So most likely the DYNAMIC fan rotation could simply be ON/OFF based on the DYNAMIC brake lever position.
Hope this happens. I have posted, EONS ago, a very long animation sequence (thank you spreadsheets) for cooling fans that ended up in shape file based on the WHEELS parameter. I never got any feedback on it, in terms of people actually using it or a subset of it, perhaps too complex to understand. They spin up and down, and stop. But none of this is temperature based. It would be nice to have the spin up and down feature, but that I think is a bit too much complication for the initial implementation.
Other ideas are welcome, but please keep it civil and constructive. https://www.elvastower.com/forums/public/style_emoticons/default/discuss_gathering.gif
Steve
#10
Posted 19 January 2025 - 10:11 AM
Have the effects, but keep it simple as possible.
#11
Posted 19 January 2025 - 04:10 PM
-consume some energy, captured by TM from train
-provide more air flow, when current grows (resistors produce more heat)
Diesel cooling fans
1. ORTSDieselEngine() block has already 3 variants of cooling management's logic (see Manual)
2. If driven hydro-mechanically, thermostat turns transmission on, when temperature exceeds higher threshold, turning off, once temperature turns lower, than lower threshold (hysteresis algorithm). There also can be small additional fan.
If driven hydro-statically, rotation speed follows temperature proportionally: hotter-faster.
If driven electrically - there are numerous fans, so they can be turned on/off one by one, depending on current temperature automatically, or by dedicated switches manually (hint on new cab control).
Also, jalousies are opened or closed manually or automatically - increasing cooling intensity's flexibility, or keeping heat in winter time.
#12
Posted 20 January 2025 - 08:33 AM
Thermal simulation is always a tricky thing as my main takeaway from thermo classes is that there is no single nice equation for moving heat around unless you think at the microscopic level, so the goal is to make the data entry as simple as knowing the details about the cooling system, the min/max temperatures of the safe operating range, and the corresponding min/max ambient temperatures the cooling system can handle while keeping the engine in the safe operating range. This is sufficient information to tune the effectiveness of the cooling system automatically, so the program can guess at heat transfer coefficients instead of the users guessing. Then when you load up the sim, the temperature responds to engine performance, the cooling system responds to the temperature, and if the content is set up well you can get spinny fans and noisy fans.
There are other things to consider here other than just making fans turn on and off. Cooling fans tend to be one of the biggest auxiliary loads on an engine, but we currently don't have a system to keep track of auxiliary loads and increase fuel consumption/reduce tractive power accordingly, so maybe that should be added (then we can also consider other auxiliary loads like the compressor, motor blowers, electric power for passenger coaches). Modern engines tend to set limits on min/max RPM depending on temperature to help the engine warm up and prevent the engine from overheating, but this would require disconnecting engine RPM from tractive effort (I know disconnecting RPM from applied force has come up many times, but maybe we can finally get it done). And there are plenty of other weird behaviors worth supporting that aren't related to the engine cooling system, the current system is just too static.
Dynamic brake fans are way easier to set up though, that just depends on the dynamic brake amperage. However, dynamic brake amperage right now is also faked (dynamic brake amperage is set proportional to force...but anyone who's taken a basic circuits course will know that current across a resistor is actually proportional to the square root of power as V=I*R, P=V*I, P=I^2*R, I=sqrt(P/R). Though it's a bit more complicated as there are other things dissipating power than just the resistor grids.) It wouldn't be too difficult to add some extra parameters to allow for correct calculation of dynamic brake current, and subsequently correct dynamic brake fan animations/sounds.
#13
Posted 22 January 2025 - 07:20 AM
Quote
Good to know that, because I was planning something similar. I already tried to use the SeriesMotor.cs code some time ago but I couldn't make it work. We can discuss it elsewhere.
Quote
This is now partially implemented in the power supply subsystem for diesel-electric locomotives. In particular, PR#961 (which still needs a blueprint approval) introduces two useful parameters: minimum RPM that the Power Supply requests to the diesel engine (revving up the engine), and power that is available for traction at the moment (limiting tractive force). Up to now they remain unused for the default scripting, but they could be extended.
It would be nice if that PR gets merged. I know it's big, so it will require some extra effort from the reviewer. However, it's now blocking any further improvements related to electric/diesel-electric locomotives. In particular, I implemented 4 features that depend on PR#961, which I cannot include until that gets merged:
- Using control cars for electric locomotives
- Ramp up/down times for tractive force and delays between setting the controller and value being updated
- Automatic Speed Control (ATO/ASC) for automatic driving
- New "Electric Motor Controller" subsystem which would be the base for rheostatic motor driving (work in progress)
#14
Posted 22 January 2025 - 07:37 AM
Quote
So, now it can't work?
only for steam&diesel?
#15
Posted 22 January 2025 - 09:14 AM

Log In
Register Now!
Help









