Replacing the 'Security Keys'

https://bveworldwide.forumotion.com/t1288-western-engine-instructions-error-split-by-quork-split-from-openbve-packages#14273

Something I implemented a few months ago (And forgot about......) , was the initial draft of a set of 'new' plugin keys.
At present, openBVE plugins use a limited set of keys (A1, A2, B1, B2 etc.) which are not applied in a consistant manner.

First, the new keys and their descriptions:

Code:

;;Common
WIPER_SPEED_UP = Increases the speed of the windscreen wipers
WIPER_SPEED_DOWN = Decreases the speed of the windscreen wipers
FILL_FUEL = Fills fuel
HEADLIGHTS = Toggles the train headlights
;;Steam engine
LIVE_STEAM_INJECTOR = Activates or deactivates the live steam injector
EXHAUST_STEAM_INJECTOR = Activates or deactivates the exhaust steam injector
INCREASE_CUTOFF = Increases the cutoff
DECREASE_CUTOFF = Decreases the cutoff
BLOWERS = Activates or deactivates the blowers
;;Diesel engine
ENGINE_START = Starts the engine
ENGINE_STOP = Stops the engine
GEAR_UP = Shifts up a gear in a train fitted with a gearbox
GEAR_DOWN = Shifts down a gear in a train fitted with a gearbox
;;Electric engine
RAISE_PANTOGRAPH = Raises the pantograph
LOWER_PANTOGRAPH = Lowers the pantograph
MAIN_BREAKER = Toggles the main breaker

The proposed assignments for these keys are as follows:

Code:

WIPER_SPEED_UP - W
WIPER_SPEED_DOWN - CTRL + W
HEADLIGHTS - H
LIVE_STEAM_INJECTOR - I
EXHAUST_STEAM_INJECTOR - O
BLOWERS - K
GEAR_UP - G
GEAR_DOWN - CTRL + G
RAISE_PANTOGRAPH - P
LOWER_PANTOGRAPH - CTRL + P
MAIN_BREAKER - B
ENGINE_START - E
ENGINE_STOP - CRTL + E

In order to do this, I've removed the DEBUG keys (Normals, wireframe and brake information) from being assigned by default, which I consider to be relatively reasonable.

Feedback?
Obviously, this wouldn't affect existing trains (I can probably effect a hack for UKDT / UKMU based trains, but it will be 100% a hack.....) , but that's the only downside I can see at the minute.

Any more keys we need adding?

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Today's build sets these keys as per above.

Users:
You should see no changes, unless you download a train which refers to these 'new' keys.
Developers:
The original SECURITY_A1 etc. keys have been marked as obsolete.
Please use one of the 'new' keys for anything that might be used in multiple trains. Additions are welcome- The aim is to allow the same key to be used across all trains with the same function.


Couple more thoughts:

• Headlights- These really ought to be handled by the sim, rather than a plugin, as they're totally generic. The only thing that gives me slight pause, is the implementation of slightly more complex power logic (Anthony was trying to give stuff power draws in UKTrainsys), but I think this could probably still be overcome. They'd want something like a brand new subject for panel2.cfg / animated files (Headlights?)
  
• Wipers- Much the same thing as headlights. I could without too much trouble implement the current raindrop generation code into the main source, but it's a tad crude for my tastes.
  

Cheers

Chris Lees

http://www.bvecornwall.co.uk

The headlights aren't as trivial as they might seem though. UK has different settings of head lights I still don't understand, mainland Europe usually has three white lights forming an "A", shunting engines usually have one white light near the buffers at least in Germany and Poland, etc.

Wipers: My suggestion would be to draw droplets all over the whole screen with a visibility layer of 1 below anything else in the panel, so they accumulate outside the wiper's reach. For 3D cabs it would be nice if this behaviour could be applied to transparent faces.

Quork wrote:The headlights aren't as trivial as they might seem though. UK has different settings of head lights I still don't understand, mainland Europe usually has three white lights forming an "A", shunting engines usually have one white light near the buffers at least in Germany and Poland, etc.

Wipers: My suggestion would be to draw droplets all over the whole screen with a visibility layer of 1 below anything else in the panel, so they accumulate outside the wiper's reach. For 3D cabs it would be nice if this behaviour could be applied to transparent faces.

UK headlights:
I suspect you're thinking of headcodes, rather than headlights?
These were a sequence of lamps placed around the bufferbeam/ front of engine in order to deliminate which class of train it was.


Other than that, all I can think of, is that *some* trains have a day/ night setting. The night setting basically just uses a narrower beam in order not to dazzle other drivers.
Oddly enough though, they aren't really designed as headlights in the true sense, they're more as I understand it for *you to be seen with* rather than to allow the driver to see.

Marker lights are another kettle of fish mind......

Need someone with actual experience to clarify really.

Could easily enough change it to headlights up/ down keys, although I'm by no means certain that's not going OTT....
Sooner or later, a little realism has to be sacrificed, as we're running on a PC

As a further note:
At the present time, these keys do nothing, unless they're handled by a train plugin.
Most of the common stuff really should be built into the sim itself though, which is why I'm trying to figure out the best way to do this....

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Up/down would probably really be the best option. The "be seen" thing is common to many railways, including Germany. Others, like Austria, have actual lights for seeing. Modern vehicles in Germany usually have five settings: Off, dim normal beam, normal beam, dim full beam, full beam. While some collegues drive with the full beam lights (and are being cursed for this by every one driving in the other direction...), you're only supposed to use them when driving "on sight".

Will change that then, unless anyone else has any strong thoughts?

I think that headlight states will largely have to wait for the train.xml parser though.
In order to have an infinite number of light states available (Essentially what you're asking for), we need somewhere to store the number of light states that this train has.

Whilst I could shoehorn this into one of the existing configuration files, the implementation of bogies was absolutely as far as I'm really prepared to go on that front.

Need to get out a 'stable' release with packages before getting too deep into this.......
Famous last words

Cheers

Chris Lees

http://www.bvecornwall.co.uk

What about keys for AWS and vigilance but of course not all railways use it? Also what about the key for the buzzer? The up/down for the headlight would be good but not essential. Trains over here have different settings for headlights with the newer trains also having flashing headlights when approaching crossings and the like.

I'd leave TPS to plugins. Too much diversity there. Give them a set of keys A, B, C (or just stay with the current model - after all, those "old" keys must stay anyway for compatibility reasons*) and have the plugin dev assign their functions at will.

* This could be circumvented though if we'd introduce a version line into panel files, just like HTML does. No version declaration = legacy mode, version declaration triggers corresponding compatibility mode. This way we'd also keep an open door for future modifications of the system.

Quork wrote:I'd leave TPS to plugins. Too much diversity there. Give them a set of keys A, B, C (or just stay with the current model - after all, those "old" keys must stay anyway for compatibility reasons*) and have the plugin dev assign their functions at will.

* This could be circumvented though if we'd introduce a version line into panel files, just like HTML does. No version declaration = legacy mode, version declaration triggers corresponding compatibility mode. This way we'd also keep an open door for future modifications of the system.

The essential plan is to replace the whole lot eventually, with a much more logical XML based format.
This is the current draft format I'm working on:
train.xml - Defines a single train.

Code:

<?xml version="1.0" encoding="utf-8"?>
<openBVE>
    <Train>
        <DriverCar>1</DriverCar>
        <MotorCars>1,5</MotorCars>
        <DriverPosition>-1,2,-1</DriverPosition>
        <Consist>
            <Vehicle>123456789</Vehicle>
            <Vehicle>123456789</Vehicle>
            <Vehicle>123456789</Vehicle>
            <Vehicle>123456789</Vehicle>
            <Vehicle>123456789</Vehicle>
        </Consist>
    </Train>
</openBVE>

Each car is assigned a GUID, from which it may be loaded. Metadata for the cars is stored in a per-car XML file:

Code:

<?xml version="1.0" encoding="utf-8"?>
<openBVE>
    <Car>
        <GUID>123456789</GUID>
        <Description>XML Test Car</Description>
        <Body>
            <Object>Object.b3d</Object>
            <Length>25</Length>
            <Axles>-10,10</Axles>
            <Weight>25</Weight>
        </Body>
        <FrontBogie>
            <Object>Bogie.b3d</Object>
            <Axles>-2,2</Axles>
        </FrontBogie>
        <RearBogie>
            <Object>Bogie.b3d</Object>
            <Axles>-2,2</Axles>
        </RearBogie>
    </Car>
</openBVE>

Whilst it's relatively easy to shoehorn new stuff into the old formats, they were never designed to be extended; Michelle always intended to replace them, but obviously things never got that far.
Once this becomes stable, adding a version attribute will be a good idea, but at the present state of things, all of these are subject to change without notice.

If you look at the XML files used in packages, this is a real-life working example of the kind of structure I'm working towards.
The really good thing about XML, is that attributes can be added at will, and it allows deep, yet readable structures.

Small amount of discussion at the tail of here:
https://github.com/leezer3/OpenBVE/issues/50#issuecomment-198580195

Cheers

Chris Lees

http://www.bvecornwall.co.uk