Although the tutorials in this series are designed to help new developers start creating BVE routes, I thought it might also be an idea to show how existing routes can be modified to easily create new scenarios.

For this tutorial, we will be modifying the Clarendon 158 day fine route which may be downloaded from http://www.trainsimcentral.co.uk/clarendon.htm. The route file is best edited in ?notepad? and saved in .CSV format (file name xxx.CSV, save as type all files, encoding ANSI). It is useful to include in the filename the traction and basic scenario details. TAKE CARE WITH THE SYNTAX AND SPELLING.

The timetable bitmaps required for the examples given are here; example timetables.zip

Save these to ..\\railway\object\Clarendon for BVE 4\Timetables

Throughout this series of tutorials, pre-existing code will be coloured blue and changes being made to the code will be shown in red. New code to be added will be coloured green.

Although the class 158 DMU is certainly a good train, we can modify the route file so that a 153 is used in place of the class 158 (providing you have the class 153 installed!). To change the traction, open the route file in notepad and change

Train.Folder cl158,

to

Train.Folder cl153,

The code that is being changed is identical to the directory name of the trains used and any train you like may be used on the route (although correct operation of AWS and TPWS is not always guaranteed).

BVE2 trains may also be used although AWS and TPWS will not function. This is not a problem on the Clarendon 1988 scenario as TPWS was not in use and trains were permitted to run with AWS isolated).

You may also wish to change the notes in the header to reflect any changes being made;

,;this is the 12_28 all stations service on a fine late summer day running with a class 153 railcar,

This header is for information only and has no function in the operation of the route.

The timetables displayed in the cab are for information only, serving no actual function. They are made up from bitmap images - on the Clarendon route, these are contained in the directory ..\\railway\object\Clarendon for BVE 4\Timetables.

To change the displayed timetable, the bitmap image must first be indexed by changing

To

.timetable(0).day.load ..\..\Railway\Object\Clarendon for BVE 4\timetables\day_fine_my 153 timetable.bmp,

To display different timetables at other stations, additional timetable bitmaps may be indexed and the station commands modified to suit.

To index an additional timetable image, add to the route file

And change the timetable index in the station command so that it displays the bitmap previously indexed as timetable 1.

to

.freeobj 0;192;20;0;90,.railstart 10;0;0;20,.dike 10;1;5,.railtype 0;11,.Sta Barford Green 12.31; 12.3030;12.3100;;1;0;;;25;80;;1,

Being an all station stops route, the only modfication which can be made to the stopping pattern is the removal of station stops. There are two options for this, either completely delete the .sta command and associated .stop command or reconfigure the station so that it becomes a timed passing point.

Choosing the second option, to alter the stop at Barford Green to a timed passing point, change

To

.freeobj 0;192;20;0;90,.railstart 10;0;0;20,.dike 10;1;5,.railtype 0;11,.Sta Barford Green 12.31; P;12.3100;;1;0;;;25;80;;1,

And also change

to

.railend 10,.Stop 0,

By doing this rather than simply deleting the station and stop commands, the timings on which delays associated with signalling are maintained. It also goes without saying that the timetable bitmap indexed as timetable (0) needs to be updated to reflect the removal of the Barford Green stop.

It is also possible to introduce stations as timed passing points just before signals; using this technique, approach controlled signals can be simulated providing the sixth parameter in the .sta command is set to 1, eg

.Sta app_controlled_signal; 12.3030;12.3100;;0;1;;;5;80;;1,

Station arrival and departure times form the second and third parameters of the .sta command and are highlighted in the example below;

.Sta Barford Green 12.31; 12.3030;12.3100;;1;0;;;25;80;;1,

If traction is changed or station stops added or removed then adjustment of the times at other stations may be required. This is easily performed by modifying the highlighted times; these are given in hours.minssecs. Note that in this instance the time is also included as part of the station name so that it is displayed in the ?jump to station? list - it serves no functional role and is included for information only.

Obviously, if station timings are changed, the timetable bitmap object should be modified to reflect these changes.

This scenario, when originally developed, used very high passenger loading factors to simulate a down on power unit which had very poor acceleration. BVE trains may be loaded to between 1 - 250% capacity although at high loading factors problems may be encountered with the doors being unable to close (as in real life!) and the loading factor adjusted to overcome these problems. Nevertheless, the loading factor of 80% now used throughout is quite high and does have an impact on train performance.

If we wanted the train performance to be a bit ?nippier?, the loading factor can be minimised (and which would in any case be more realistic for this scenario). The passenger loading factor is included in the .sta command (for full details of this command, see tutorial 1.2). To alter the loading factor to maximise train performance between Hampsford Park and Barford Green, change

To

.Sta Hampsford Park 12.28; 12.2720;12.2805;1;1;0;;;7;1;;0,

Similar changes may be made throughout the route if desired or the loadings varied to suit the observed passenger numbers.

Another way of changing train performance is to alter the adhesion (amount of grip). In real life, loss of adhesion would occur, for example during wet or icy weather or when seasonal events such as leaf fall occurs.

The adhesion available is controlled using the adhesion command,

.Adhesion x,

Where x is between 1-250.

When conditions of normal adhesion prevail, the adhesion value should be around 100-150. During conditions of poor adhesion, this may be significantly reduced, making both braking and acceleration more difficult.

Ideally, the values of adhesion used in a route will reflect the weather conditions, season and location.

On the route being modified in this tutorial, adhesion is generally good throughout with the very best adhesion being found towards the end of the route. For a bit of variation, adhesion in braking zones can be changed. For example, on the approach to Clarendon station, we can impair braking performance by adding

13250,.height 3.5,.accuracy 1,.rail 3;7.0,.rail 4;10.5,.adhesion 30,

But to ensure we can accelerate away from the station, raise the adhesion after the stop point;

13875,.form 0;l;0;1,.form 4;r;0;1,.dikeend 5,.railend 5,.rail 6;33;-0.7,.freeobj 0;199;0;0;180,.adhesion 150,

It is also possible to randomise the adhesion. If we want the adhesion to be between 30-150, use .adhesion $rnd(30;150),

Random numbers can be used for almost all commands providing the number being generated is within the range needed for the command. A further example of the use of random numbers is the dwell time in stations, for example

Could be changed to

.Sta Berkely 12.55; 12.5400;12.5430;;1;0;;;$rnd(10;30);80;;0,

Rain is controlled using the command

Where n is the intensity of the rain and has a value between 0 (not raining) and 99 (raining hard).

This command may be used at any point in the route but don?t forget to make it stop raining in tunnels and other ?dry? locations by using .beacon 21;0;0;0,

If it is raining, the appearance of a blue sky is unrealistic and the background image may need to be edited or, more easily, the fog command may be used;

Where x is the start distance of the fog and y the end distance. The r,g and b values represent the colour of the fog and require values in the range 0-255.

For the effect of very dull, damp weather, something like .fog -100;500;102;102;102, can be used.

The signalling on Clarendon relies on the use of a route run interval to define the time to the train in front;

Where x is the time to the train in front (in seconds) at the start of the route.

This is not as sophisticated as the use of pretrain commands where the time interval can be re-specified at any point on the route. Nevertheless, some variations in signalling response can be obtained by altering the run interval with shorter times leading to longer delays (as waiting for the train in front to clear the signalling blocks is more likely). A random number may be used for the route run interval.

Where x controls the position of the default BVE stop marker, -1 for displaying it on the left hand side, 0 to hide it and 1 to display it on the right hand side.

y is the distance before the stop point after which you will not be prompted to move ahead

z is the distance after the stop point before which you will not be prompted to move back.

Values of y or z greater than 25m may cause door closing problems.

The position of the .stop command indicates where the nominal stopping position is located and it is where the train stops when jumping to stations. If the train length is being altered, it may be necessary to move the .stop command (although it must remain located after the .sta command).

The Clarendon route (unlike most others) does not feature ?car stop? signs to indicate stopping points - these could be added as free objects if desired to clarify the exact stopping position, or (as I have in the original route), make use of the ?rubbish? free objects to mark stopping points.

By minimising the values if y and z in the .stop command, more precise stopping is required, making for a more challenging drive.

Although there is no DOO equipment on the platforms of the Clarendon route, it is still possible to simulate it by removing stations stops (not the first or last stations) or converting them to timed passing points. Manual door operation will be necessary as BVE will not recognise the station as a stop if configured in this way.

If all the waiting passenger free objects are replaced with random objects containing both passenger and other suitable non-passenger objects, stopping at the station will be required only when passengers are visible.

Barford Green may be used as an example DOO stop. Firstly, convert to a timed passing point as discussed previously and remove freeobj 270 (the passengers currently waiting) from 2750metres.

Then add ?random? passengers to the platform using free objects 250-258 by adding

2700,.form 0;r;0;0,.pitch 2,.rail 14;-10,.dikeend 14,.freeobj 0;245;5;1,.freeobj 0;$rnd(250;258),

Where free objects 250 - 258 are a mixture of passengers and rubbish on the track.

Now, only stop at the station when passengers are visible!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hopefully, the ideas presented here will enable you to modify existing scenarios of any route. Many other modifications are possible, options probably limited not by your imagination but coding ability. Modification of existing routes (and objects) is how I started developing for BVE so perhaps after trying some of the ideas presented here, you might wish to build a whole route!

As developer of the Clarendon route, I have no objection with modified scenarios entering the public domain although the permission should be sought from other developers before redistributing their routes.