[roeter]

As is well known, trains in timetable mode can be detailed to exist (long) before becoming active, (long) after completing their service, or in between duties.
Such units can be stabled in pools, sidings or just in yards or platforms where they sit in between duties.
At present, all units stabled in this manner will always have power on, with all the related sounds which reflect this state.

I am now working on new commands which allow power to be switched off when units are stabled, and this also includes proper sound management for switching off power which at present does not exist. Note that power switching only applies to electric and diesel engines, steam trains are not affected.

To keep this post from getting far too long, I will split the information in three posts:

• General information (this post)
  
• Timetable commands for switching power
  
• Sound processing

General setup

Power switch off:
With specific timetable commands, it will be possible to switch off power (and sound) for units for the following situations :

• When created, either as actual train or as static (but not in pools, see below)
  
• When terminated, either with $forms, $trigger or $static (but not in pools, see below)
  
• When detached
  
• When attached, but only when $attach is defined in #dispose row, and only when the train to which is attached is not active.

The actual time that power is switched off will vary, and is random delayed between 30 to 60 seconds after the action which sets the power off command takes place.

Automatic Power switch on:
For units which have power switched off, power will be switched on automatically at the starttime as defined in the #start column.
When units are attached, and the train which attaches is not terminated as part of the attach action, and the train to which is attached has power off, all units will have the power switched on after attaching has taken place.

Forced Power switch on:
Power can be forced to be switched on before the defined start time, at a specific given time. It is also possible for an attach action that power for the static units to which a running train will be attached, to have the power switched on before the attach action, at a specific given time.
Power switching on is at the time as defined, there is no delay.

Pools:
A general pools command will be introduced as part of the pools definition which defines that power must be switched off for engines stabled in this pool. This setting will apply to all units in the pool, it is not possible to set commands for power switching for individual engines stored in a pool. When the option is set, a unit will switch off power when it is created in that pool, and also when it is stabled in the pool. Power will be switched on when an engine is requested from that pool.

Note that there are no commands linked with the $transfer command. This command is mainly used for non-powered units. Power state of any engines transferred between trains using the $transfer command will not be changed.

Player train
For the player train, power will never be switched on or off by the system. It is up to the player to decide if and when power will be switched on or off.
The state of the power of the player train at the start of a player session will depend on how the train is created.
If the player train is created using the $create command, or if it is formed out of an AI train using $forms, $trigger or $detach, the power state will depend on the power command set with the command through which the train is created. If that command defines that the power must be switched off, the player train will start with power switched off. If the player train is created in a pool, the power state will depend on the pools setting. In all other situations the player train will start with power switched on. Note that the setting of the general option in the menu "start player without power" no longer will affect player trains in timetable mode.

Program logic
This new function to switch power for AI trains required substantial program changes. The power logic simply was not set up to handle power switching for AI trains, in fact there were safeguards at multiple locations in the code to ensure power for AI trains was always switched on. Another problem was that calculations for power switching, in particular for diesel engines, is based on certain calculations and these calculations are such that these only work correct for limited delta values. During prerun, with low frequency update, these delta values were too large so special logic was required to handle power switching during prerun.

Progress
Presently I am testing the implemented changes, and first tests look very promising, with units properly switching on and off as required. Further tests are still needed, in particular for player train actions.

Outstanding issues

• Electric engines - pantographs: presently, power off for electric engines is linked with all panto's down. In real life, this is often not so, electric units are often stabled with power off but panto's up, in particular in between duties. I am looking into possible additional options to make this possible.
  
• Dead in tow. I am looking into possible additional commands to allow units with power switched off, to be attached to or by other trains, while power will remain switched off and the engines are taken along dead in tow.

Functions not implemented and not planned
Separate power switching for different MU sets in a single train is not implemented and will not be implemented as this is just too complicated.

As stated, testing is still taking place so it will be some time, probably two or three weeks, before this function will be pushed to the testing version.

Regards,
Rob Roeterdink

[roeter]

• General information
  
• Timetable commands for switching power
  
• Sound processing

Power off:

• #start field : additional qualifier /poweroff for $create and $static commands.
  
• #dispose field : additional qualifier /poweroff for $forms, $trigger, $detach and $static commands.
  Also for $attach command but it is valid only if the train to which the attach takes place is not active.

Automatic power on:
For this no commands are required.

Forced power on:

• #start field : additional qualifier /poweron=<time>, set as qualifier to the starttime value.
  
• #dispose field or any station row : additional qualifier /poweron=<time> for the $attach command.
  Note that this power on command does not apply to the train for which it is defined, but for the train which is being attached to.

Pools:
field #setting, value /poweroff.


Regards,
Rob Roeterdink

[roeter]

• General information
  
• Timetable commands for switching power
  
• Sound processing

The sound definition in the .sms files as inherited from MSTS simply is not set up to play proper sounds when engines are switched off as this was not possible in MSTS.
Note that the functionality described here is a very 'rough and ready' method to have proper sounds playing (or, more precise, not playing) when engines are switched off.
A more extensive and sophisticated proposal is described by ErikC in this post; this is also still under development. It is at present not yet known if special action or commands or whatever will be required to be able to use these two methods side by side.

In most .sms files for engine sounds (either for inside -cab- or outside -eng- of the unit), engine sound volume and frequency is defined using either variable2_control or speed_control settings. Switching sounds on or off is also usually based on variable_triggers using either variable2 or speed.
There are some exceptions to this using other parameters, but these are only few and have not been taken into consideration.

Variable2 control
Variable2 is linked to the RPM of the engine. The range of variable2 is 0 for RPM=RPM_idle, and 1 for RPM=RPM_max.
This means that it is not possible to set any values for frequency or volume for RPM below RPM_idle, which of course is required when the engine is switched off.
This means that for any state where RPM < RPM_idle, which includes engine off (RPM=0), the sound for RPM_idle will always be played.
To overcome this problem, without the need to make extensive changes to all existing .sms files, the internal value of Variable2 is extended for RPM<RPM_idle, thus :

                        -0.9999f * RPM
Variable2 = -0.0001f - -----------------
                           RPM_idle

So, for RPM_idle, Variable2 = -1, and for RPM=0, the value = -0.0001f. This small value is used to avoid Variable becoming zero as that would conflict with the 'normal' range for Variable 2.

When Variable2 < 0, the volume or frequency is calculated as:

Value = -Variable2 * Value_Variable2=0

So, for RPM_idle, Value = 1 * Value_Variable2=0 which is indeed the value for Variable2 = 0 as required.
For RMP=0, Value = 0.0001 * Value_Variable2=0 which is just about volume and frequence at level 0.

Switching engines on and off using this behaviour sounds a bit rough, but it is better than nothing. Also, on save and restore the values are properly calculated again so engines sounds will be correct after restoring.

Speed control
For speed control, the value of 0 corresponds with speed = 0.
The above method cannot, of course, be used for speed control as there is no speed below 0. Also, speed control is also used for other streams which should not be affected by switching power on or off.
Also note that the special triggers for switching power cannot be used to stop or start repeating streams, but only for one-off streams (see details below).

So, in order to be able to stop streams controlled by SpeedControl, and also start or restart these streams as required when power is switched on again, two new variable triggers are introduced :

variable_trigger (Power_On 0 etc...
variable_trigger (Power_Off 0 etc...

Note that these triggers do not actually require a value, but a value must be included in the command to match the syntax requirements for these definitions.

Variable trigger Power_On will be valid when power is on, and, rather obviously, Power_Off is valid when power is off. Note that the streams controlled in this way start and stop abruptly, there are no intermediate sounds during the switching phase. This is rather crude, but this is only noticeable when the player is near a train switching power. The main point of this method is that the proper sound (or absence of sound) is heard when passing a stationary train, and that works fine.

Example :
Original definition:

				Triggers ( 7
					Skip ( Engine Sounds )
					Initial_Trigger ( StartLoop ( 1 File ( "DMU_idle_ext.wav" -1 ) SelectionMethod ( SequentialSelection ) ) )
					Variable_Trigger ( Speed_Inc_Past 0.001   ReleaseLoopRelease () )
					Variable_Trigger ( Speed_Dec_Past 1.5   PlayOneShot ( 1 File ( "DMU_revrise_ext.wav" -1 ) SelectionMethod ( SequentialSelection ) ) )
					Variable_Trigger ( Speed_Dec_Past 1.5   StartLoop ( 1 File ( "DMU_idle_ext.wav" -1 ) SelectionMethod ( SequentialSelection ) ) )

					Variable_Trigger ( Speed_Inc_Past 0.001	PlayOneShot ( 1 File ( "DMU_revdrop_ext.wav" -1 ) SelectionMethod ( SequentialSelection ) ) )
					Variable_Trigger ( Speed_Inc_Past 0.001   StartLoop ( 1 File ( "DMU_ingear_ext.wav" -1 ) SelectionMethod ( SequentialSelection ) ) )
					Variable_Trigger ( Speed_Dec_Past 1.5   ReleaseLoopRelease () )
				)

Allthough this definition would stop the "idle" stream as the train starts moving, it restarts the idle stream when speed drops again and that will then be played continuously, also when power is switched off.

Using the new variable_trigger commands for power, the stream looks like this :

				Triggers ( 7
					Skip ( Engine Sounds )
					Variable_Trigger ( Power_On 0 StartLoopRelease ( 1 File ( "DMU_idle_ext.wav" -1 ) SelectionMethod ( SequentialSelection ) ) )
					Variable_Trigger ( Speed_Inc_Past 0.001   ReleaseLoopRelease () )
					Variable_Trigger ( Speed_Dec_Past 1.5   PlayOneShot ( 1 File ( "DMU_revrise_ext.wav" -1 ) SelectionMethod ( SequentialSelection ) ) )
					Variable_Trigger ( Speed_Dec_Past 1.5   StartLoop ( 1 File ( "DMU_idle_ext.wav" -1 ) SelectionMethod ( SequentialSelection ) ) )
					Variable_Trigger ( Power_Off 0 ReleaseLoopRelease () )

					Variable_Trigger ( Speed_Inc_Past 0.001	PlayOneShot ( 1 File ( "DMU_revdrop_ext.wav" -1 ) SelectionMethod ( SequentialSelection ) ) )
					Variable_Trigger ( Speed_Inc_Past 0.001   StartLoop ( 1 File ( "DMU_ingear_ext.wav" -1 ) SelectionMethod ( SequentialSelection ) ) )
					Variable_Trigger ( Speed_Dec_Past 1.5   ReleaseLoopRelease () )
				)

The 'idle' stream now only starts when power is on, and will switch off when power is off, so it will not play when power is switched off.

Discrete triggers
The discrete triggers for power switching cannot be used to switch continouos streams on or off. This is because these triggers are only send once, as the event takes place, but are not stored to represent a specific state. The state is therefor lost, and cannot be used to restore the proper stream state after save and restore.
Also, these discrete triggers are only send if the train is within range of the player train, that is if the train is actually created as existing in the world. For trains which do not exist in the world, e.g. when they are outside the range of the player train or during prerun, the discrete triggers are not send and therefor the change of power state would be lost.

Regards,
Rob Roeterdink

[scottb613]

Hi Rob,

Man - you weren't kidding about an ambitious scope of work - thanks for all your efforts.

:sign_thanks:

Regards,
Scott

[Aldarion]

WOW Rob. Those are some nice festures.

I'll have my timetable for PT79 route at the ready for some testing if you would like.
Let me ask you a question: this feature about power on/off will cover just sound or is it capable of infuencing lights?

[roeter]

Aldarion, on 16 February 2023 - 05:43 AM, said:

Let me ask you a question: this feature about power on/off will cover just sound or is it capable of infuencing lights?

Lights is next on the list - watch these pages.

Regards,
Rob Roeterdink