[R H Steele]

Of course, that would be the best case to be hoped for. However, most all the MSTS eng files have an inexhaustible supply of sand.
comment( infinite sanding time )
MaxSandingTime( -1 )
I wonder if OR parses this line...if so would be good to have OR ignore this and provide a prototypical amount of sand available for use. More coding?

So I suppose for now substituting a definite speed limit after which sanding ceases because in reality it is ineffective is the best solution we presently have.

[Weter]

Hello.
Sorry, I likely misunderstood, but I see two different things, mentioned in last post by Gerry, having nothing common with each other.
1. Is sanding efficiency's fading with speed growth: now it looks like sanding "cutoff" in greater speeds, than specified.
2. Is defining sand deposits on given unit (including possibility to infinite them)
So, why should them be tied in game? Why forgive player's carelessness, if he just turns sanding on and wastes it all?
On real locomotives driving practice it's proven much time back: impulse sanding is overall more efficient, than continious.
(And there can be automatized function for impulse sanding application on more modern locomotives) I don't know, have US locomotives automatic sanding cutoff with speeds, higher, than predefined, though.
Also, railroad instructions order to stop sanding, while passing switches, as it will damage switch gear with thin sand, being spread around.
And one more: modern stock do have EP sanding definitely, so it can be activated (deactivated, I think, too) by some safety systems in addition to driver's control.
More frequent case - emergency stop knob, which cuts power, opens brake pipe and applies sand, plus sounds horn. In some models, crew member can pull-out emergency system triggering ring and jump off locomotive, or run away to diesel room with it on finger - as a proof, that all measures were used to stop the train.

[pschlik]

If you want sand to reduce in effectiveness as speed increases, use ORTS ( ORTSSanderSpeedEffectUpTo ( x mph ) ) I have no clue why this isn't mentioned in the manual, but using that causes a linear decrease in the friction sand provides, starting at a factor of 1 at 0 speed, and dropping to halving adhesion when speed is 'x' mph. (This means that sand will become completely ineffective around a speed of x/2.)

[Weter]

ORTS() within engine section?

[R H Steele]

pschlik, on 08 June 2023 - 05:27 AM, said:

If you want sand to reduce in effectiveness as speed increases, use ORTS ( ORTSSanderSpeedEffectUpTo ( x mph ) ) I have no clue why this isn't mentioned in the manual, but using that causes a linear decrease in the friction sand provides, starting at a factor of 1 at 0 speed, and dropping to halving adhesion when speed is 'x' mph. (This means that sand will become completely ineffective around a speed of x/2.)

So you can confirm that the ORTS parameter is currently coded --- applies directly to the condition that Darwin brought up, that's a nice surprise! I have never seen that mentioned anywhere in the threads. To Weter's question I would assume it is used in the eng section of the engine file...would be good to know for sure.

Edit: Did a quick search of the threads and found two other times the parameter is mention ( although not specifcally in connection to sanding )
Post #36 and Post #18
These two posts ( if I'm reading them correctly ) show the parameter to be used in the eng section of the engine file.

[Weter]

Thank You for this little, but important investigation, Gerry.
Now we know.
Although, I confused with exta brackets: engine(orts(ortssanderspeedeffectupto))
Is'nt it ommitted?
http://www.elvastowe...post__p__201949

[pschlik]

Nope, you need the extra ORTS ( ) brackets. Per the source code, it looks for an Engine ( section, then for an ORTS ( section, and finally interprets the token. There are only a few tokens which need to be contained within ORTS ( ), it seems to be a style that was tried out and shortly abandoned as it's (evidently, per this discussion) a bit confusing.

case "engine(orts(ortssanderspeedeffectupto": SanderSpeedEffectUpToMpS = stf.ReadFloatBlock(STFReader.UNITS.Speed, null); break;

The other tokens which need to be inside an ORTS ( ) block are ORTSEmergencyCausesPowerDown, ORTSEmergencyCausesThrottleDown, ORTSEmergencyEngagesHorn, and ORTSWheelSlipCausesThrottleDown.

Feasibly, it would be possible to add a second case for each of these tokens which would not require the ORTS ( ) block but editing the existing case would be a bad idea as existing content assumes the ORTS ( ) block needs to be there, and would break if that was removed from the interpretor.

[Weter]

As I've read in next post (#39, see the link above), after one, which Gerry have brought up, that was already... Offered or done???

[pschlik]

That strategy would work well, but is not part of the code as it stands.

This also reminds me of the whole ORTSAirBrakeMainResVolume thing I noticed a couple of weeks ago-that's another example of a token not working the way people expect. Considering it seems nothing has been done so far about that and I have the dangerous power of the ability to compile OR, I can definitely have a try at rectifying confusing tokens by adding alternates. Though I have no idea if there's any precedent for having multiple tokens apply to a single variable, so we'll see if that's an acceptable solution.

[R H Steele]

Regarding whether or not to use ORTS parameters inside of an ORTS ( ) block --- ( and which parameters must be contained within a block ) --- my experience is that include files are an exception. OR parses all the ORTS parameters in the Standard Engine files whether or not they are contained within a block.

	IdleTemperature ( 55degc )
    )
)
    ORTSEmergencyCausesThrottleDown ( 1 )
    ORTSWheelSlipCausesThrottleDown ( 1 )
    ORTSMainResChargingRate ( 0.4psi/s )
    ORTSBrakePipeChargingRate ( 200psi/s )
    ORTSEngineBrakeReleaseRate ( 38psi/s )
    ORTSEngineBrakeApplicationRate ( 34psi/s )
    ORTSBrakePipeTimeFactor ( 0.003 )
    ORTSBrakeEmergencyTimeFactor ( 0.1 )
    ORTSBrakeServiceTimeFactor ( 1.009 )
    ORTSAirBrakeMainresvolume ( 28.35ft^3 )
    TrainPipeLeakRate ( 0.0833psi/s )
    TrainBrakesControllerMaxReleaseRate ( 10psi/s )

MaxForce ( 630113N )