Interlocks
- Before starting the engine:
- the Master Switch must be ON
- the train must be stationary
- the
reverser must be in NEUTRAL
- the power handle must be OFF
- Power cannot be applied if the engine is not running!
Starting
Two models of engine starting are available:
Simple start model
A single sound file is required,
covering the entire startup
procedure. It must be aliased to ats10
in sound.cfg
.
On pressing the engine start button:
- the engine start (
ats10
) sound is played
once;
- the engine start button is illuminated;
- after
startDelay
milliseconds:
- the engine idle loop is played;
- illumination of the start button ceases;
- the power interlock is released.
Complex start model
Five sound files are required, as
listed above. To start the
engine, the start button must be pressed and held until
the engine fires
after a random number of BVE frames. To add even more excitement,
the engine randomly stalls after firing. The ease of starting and
likelihood of stalling can both be configured.
On pressing the starting button:
If interlocks prevent starting
(see above):
- the engine start button is animated, but does not illuminate;
- the engine does not start.
If starting is allowed:
- the starter motor switching on sound (
ats7
)
is played once;
- the engine start button is illuminated;
- after
motorStartDelay
milliseconds:
- the starter motor loop (
ats8
) is played;
- the engine start loop
begins.
During the engine start loop
<>the probability of the engine firing in any one BVE frame is as
configured by the attribute fireProbability
(a
value between 0 and 1000) - if the start button is released
during this period
- the starter motor loop ends
- illumination of the start button ceases
- the starter motor running down sound (
ats9
)
is played
- the engine returns to the stopped
state.
On engine firing:
- the probability of the engine stalling is as configured by the
attribute
stallProbability
(a
value between 0 and 1000);
- if the engine stalls:
- the engine stalled sound (
ats11
) is
played once;
- after stallDelay milliseconds:
- illumination of the start button ceases
- the engine returns to the stopped
state.
- Note that the start button must
be released before another starting attempt can be made.
- if the engine does not stall
- the engine start (
ats10
) sound is
played once
- after
startDelay
milliseconds:
- the engine idle loop is played
- illumination of the start button ceases
- the power interlock is released
Randomising Start Performance
With the complex start model,
performance can be further randomised by
specifying:
fireProbability |
= 0
|
stallProbability |
= 1000
|
In this case random values are assigned as follows:
fireProbability |
a value between minFireProbability
and 1000
|
stallProbability |
a value between 0 and maxStallProbability
|
Revving up/down sounds
These sounds are played whenever the power handle is moved away from/to
the OFF position. In addition, the revving down sound is
correctly played if the power is tripped by an interlock.
Notes
- There is a slight but noticeable delay on shutting off power
before the revving down sound is played, due to the way BVE handles
plugin sound variables. If this is unacceptable, increase
the power down delay in the
train.dat
file.
- Because it is not possible with BVE 4.1 to fade plugin sounds
out, stopping the idle loop when the power handle is opened produces an
unrealistic sudden change in the engine sound. To avoid this, the idle
loop is played continuously, regardless of power setting.
Engine shutdown
On pressing the engine shutdown button:
- the engine stopping sound (
ats15
) is
played once
- the power interlock is reapplied
Note that there are
no interlocks preventing the engine
stop button being active while the train is in motion.
This is a stub which controls door
interlocks and allows for more detailed models of specific door types
in future. It is, however, able to drive door release
indicators on routes correctly equipped with .beacon 23. The keys
allow the correct indication to be selected manually on startup or
after a restart.
Wiper speeds and hold times
Wiper speed is configurable up to a maximum of
four settings, plus OFF.
Speeds are entered in the configuration file under the attribute
sweepTimes
as a list of values, each representing the time in
milliseconds for a single sweep of the wiper across the screen. The
default is a single setting with a sweep time of 1000ms.
For each speed, a hold time is configurable using the attribute
holdTimes
to create intermittent wiper modes. Note that even in continuous
modes, the minimum hold time is 250ms (see
Wiper Animation below). If
more hold times are entered than sweep times, superfluous hold times
are ignored; if there are fewer hold times than sweep times, the
default hold time of 250ms is used.
Wiper Animation
For better visual effect a minimum pause of 250ms at each end of the
wiper's sweep has been introduced: this ensures that the wiper appears
to reach the end of its travel on every sweep. Previously, the
wiper could sometimes reverse direction within a BVE frame and appear
to miss out the end of its sweep.
Wiper Sounds
Two wiper sounds are supported, one representing the wiper on a wet
windscreen, the other the scrape of a wiper on a dry windscreen.
Changeover is controlled by rain simulation variables (see below).
Raindrops
From 0 to 50 (the default) raindrops can be configured using the
attribute
nDrops
: the same drop placement
algorithm is used as in OS_ATS_1.3.
Up to
five (the default) drop
sound channels can be configured using the attribute
nDropSounds
-
they can be aliased to the same or different sound files in the
sound.cfg
file. It is
strongly recommended
that the full five channels be
used, otherwise sound may not play correctly at higher rain intensities.
New Rain Simulation Features
A number of the variables used in simulating rain are configurable in
this release, to allow us to find the most effective values for
them. It is likely that they will be fixed in future releases.
Speed Dependence
Rain intensity
i
now increases with speed as:
i = i0
× (1 + vFactor × speed)
where
vFactor
is a configurable
attribute The default value is 0.05
Raindrop 'lockout'
At high rain intensities, the rain algorithm could reuse a raindrop
almost immediately after it had been removed by the wiper, with two
undesirable results:
- It looked as though the wiper had missed the drop;
- The difference in effectiveness between different wiper speeds
did not show up well.
To avoid this phenomenon, drops are now locked out of use for a
configurable time after being wiped. The time can be entered in
milliseconds under the attribute
lockout
(default
value 1000).
Wiper Sounds
To decide which wiper sound to use, the 'wetness' of the windscreen is
modelled, increasing by 1.0 for each drop that falls and being reduced
for every sweep of the wiper as
wetnessn+1
= wetnessn × 1/wipeFactor
where
wipeFactor
is a configurable attribute
(default value 2.5).
The value of wetness at which the sound changes from 'wet' to 'dry' is
configurable using the attribute
dryLimit
(default
value 2.0).
The intention is that at low rates of rain, the driver will be forced
to switch between wiper modes in order to avoid annoying wiper-scrape,
introducing an extra level of distraction into the simulation :-)
To help with configuring this feature, an Excel spreadsheet Rain.xls is
supplied. Given a starting value of wetness and the number of
drops falling on each sweep of the wipers (a measure of rain intensity
and approximately 1 at an intensity of 5), this calculates and
displays on a graph:
- How the wetness varies for each sweep of the wipers
- The minimum value it will eventually reach (the asymptote)
It can also show the value of
dryLimit
for easy comparison.
The horn lever moves when either of the
BVE horn keys is pressed and returns to its off position automatically
after a time which can be separately configured to suit the horn sounds
used with the train.