New: Allow uncoupling of cars

[leezer3]

This PR allows us to uncouple cars from a train.
No method of coupling two trains at the minute, will be part of a separate PR.

Uncoupling must be done in train exterior view, with the camera set to the car you wish to uncouple.

Another strand of #329
Realistically, that wants merging reasonably close to this, as otherwise we've got no way of actually doing anything interesting with this.

TODO:

• Animated functions which use car indicies are now broken.
• Add uncoupling sound with appropriate trigger.
• Assign default controls- Probably going to be CTRL + U to uncouple front and ALT + U to uncouple rear (??)
• Test......
• Check signalling effects.

Further Development:

We need a method of finding preceeding / next trains, which takes into account those on other rails, and where the points are set, although this is probably part of #329

It also occurs to me that uncoupled couplers require a different state to that of the coupled / default ones.
The number of people using coupler objects is likely to be lower (as a later addition), but that's someting interesting to think about.

A nicer GUI for this might be useful.
MSTS / TrainSim have a consist window, which could also be useful for other things, such as showing car loadings / weights etc.

Click on couplers to decouple?
Presumably this could be bodged in using something along the lines of the clickable 3D cabs.

RELATED:

The main website should have a default keymap template on it somewhere.

Essentially, something like this random template found on Google.
This would help to increase accessibility for new players, although legacy plugins may confuse the issue slightly, as these often use the ATS keys to operate wipers etc.

[leezer3]

Finding an unused default key was actually more difficult than I thought, U is actually in use for cutoff. (Probably not used by many if any items, as this is only currently passed to custom plugins)

For the minute, I've set it to semicolon.
Undecided as to whether it should stay here, but let's see for the minute.

[leezer3]

https://www.youtube.com/watch?v=ayou3XdY4BE

Tested and seems to be working reasonably OK, but no doubt once it goes public someone will completely break it.
If testing, please remember that if the uncoupled front portion has no motor cars in it and you attempt to drive it, this will go nowhere- Not a bug :)
(Already found that one with a train where the front car is not a motor car)

I'll probably merge this tomorrow or Sunday and post a thread with this video in on BVEWorldwide for the wider community.

[ginga81]

If this is a train with two trains, is it possible to drive the train behind after separating and moving the front train with TFO?
For example, in this video, I want the silver train to go first, and the white train to drive to the next station.
before sepalate, we are driving at silver shinkansen car, arriving and sepalated, white shinkansen driviing.
https://www.youtube.com/watch?v=vs0_YMvNPIs

[leezer3]

At the minute, I'm afraid this is incredibly simplistic. You can uncouple a portion (front / rear) of the train and drive it away, but anything left behind will not move at the minute.

What you want should be possible in the much longer-term, but it'll need careful thinking about as to how it works, as obviously we wouldn't want a set of goods trucks to drive themselves off without a locomotive attached.

I think whatever happens, something like that will require a whole set of configuration XML somewhere to denote the fact that this portion may automonously drive away.
It's also another reason XML really wants more work doing to it- The BVE train folder concept is OK, but we need the ability to have consists with specific instructions attached :)

Essentially, I'm working on the principle of many small steps.

[Kenny-Hui]

I've compiled this branch, and it crashed when I jump to the second car and decoupling the front car (Shift+Ctrl+Semicolon)
OpenBVE Crash- 2023.8.20[00.56].log

Another crash would occur if I jump to the last 2 car and decouples the front car:
OpenBVE Crash- 2023.8.20[01.04].log

(Train used: MTR SIL C-train EMU-FAO)

[leezer3]

Thanks, must have broken something in the logic for the front uncouple.
Sure that was working when I tried it.....

[leezer3]

Done a little redesign, and hopefully that should now work.

@Kenny-Hui
Incidentally, should that train have a working 3D cab?
That was linked on BVEWorldwide earlier ( https://bveworldwide.forumotion.com/t2375-confused-about-throttle-in-a-route#21667 ), and the download refers to a 3D cab, but all the files all seem to be missing.
Couldn't see anything on the BVEHK page about it either.

[Kenny-Hui]

Very unlikely, I've checked the panel.animated it is the same file as another train HKRSC has produced (MTR URL C-Train EMU).
Because the SIL C-Train does not have an actual cab (It's still a part of the train cabin), it would not make sense to put a completely wrong cab into the train.

It's probably still in development, or there was never one developed in the first place.

[Kenny-Hui]

Also, just wondering is there any plan for animated or train plugin to be able to tell if the train has been divided? (I assume for animated you can check if the cars variable has changed? Not sure how reliable that is though)

[leezer3]

Plugins should I think be able to check the runtime data.
That's built dynamically each frame, and IIRC it should reflect the new state.
We may get the issue that some plugins never expect the train length to change, but the game should handle that & gracefully unload them.

Realistically though, I'd much rather move all code from plugins into the sim itself.
Whilst that's unlikely to happen soon if ever, pretty much everything a plugin does logically should be handled by the main physics etc. engines- Things like the plugin virtual handles are nothing more than a horrible kludge.

[Kenny-Hui]

I think for .NET Plugin, it will call SetVehicleSpecs and this is the only chance you can store the amount of train cars?
I've checked ElapsedData and I couldn't find any car informations there

[leezer3]

I'll have to check, not off the top of my head on the phone :/
Sure we were passing around vehicle specific data though.

Either way, the whole plugin interface is a teetering tower :)

[leezer3]

Yuck, you're right.
I was thinking of the VehicleState class. This has the BC, MR etc. pressures in, but for the whole train.

Looking at the VehicleSpecs, it contains the basic specs of the train, but even this would seem to need some major revision now you've brought this point up.
Assume for example we couple two cars with differing brake types together (Or add them to a single train via XML- This can be done at present, and I think at least doesn't crash)- This isn't handled, and I can think of plenty more cases. It only gets worse as we start to add / remove random cars.

---

Doing some quick digging through the vast quantity of stuff I've got, I can see various methods of car / train information handling including beacons to pass this data, and it being hardcoded into some plugins. Overwhelmingly though, it's route-specific trains.

I do wonder at this point whether it'd be better to introduce a V2 runtime API, specifically designed to take into account coupling, and allowing plugins to do things like set the deceleration / acceleration on a per-car basis.
Whilst that (probably) would be feasible, I also question the value of this (after all, the current API was a originally a direct .Net port of the existing BVE API), and as stated in a lot of ways, I'd much rather just implement everything directly into the main code.
Overall, I'm not sure how much effort to put into this. The total number of plugins is vanishingly small (IIRC there are about 5 total .Net plugins and about 10 - 15 legacy plugins)

Another (easy-ish) possibility would probably be to call the SetVehicleSpecs function on a couple / uncouple event. What I don't know however is how existing code would react, especially some of the legacy plugins. Whilst obviously this could be tested, it's the sort of thing that could cause subtle issues.

---

Other thoughts:
With my musings about merging the safety system code into the main tree, I've also considered relatively strongly merging a lot of the code from BVEC_ATS into the default safety system plugin (not the traction stuff, but the AWS / TPWS)
With a little hackery from the compatability database, that would actually allow a majority of UK stuff to work much better on non-windows platforms, and it'd also give us another safety system variant available by default. With my thoughts above on quite how much stuff doesn't use anything other than default, that's again important :)
I did look at something like that a few years ago ( #137 ) but got some quite bad pushback from someone concerned that 'all' features of his stuff wouldn't work, so I didn't go further......

---

Essentially, we need a design and steering committe almost.

[Kenny-Hui]

I do agree the current Plugin API is kinda a mess, and calling SetVehicleSpecs again could very potentially break things. (I think I have a plugin that does specific stuff with SetVehicleSpecs under the assumption they will only be called once)

I think a V2 API would be inevitable one day, probably just far away from now. (Unless there's a new scripting language that can control the train. I probably can abuse some animated CSScript for this but that sounds like a terrible idea)

Essentially I am looking to see if there's a way to apply Full Service Brake when a train is decoupled midway while the train is running, although that was probably never the intent for this PR, either way it's just a very minor thing and it's not a very high priority thing.

[leezer3]

Interesting.
My initial thought would be that doesn't belong in the plugin or anything at all- In real life, that would be a property of the braking system. Could probably add that to the XML somewhere- Will think about a bit.

Another bit of design that needs looking at before going down this hole too far is where the handles are stored. If we're considering coupling etc. then the handles really need to be a property of the driver car, not the train- That's also important if we split off a portion so that it has more than the simple dummy handles in this PR.
It ought to be possible to hack it so the train handles pass back a reference to the cab handles, but you can see how a vey simple change starts spiralling out of control. Everything is interlinked......

[trainkidkris]

Depending on what information you need there's a lot of ideas and suggestion for the uncoupling features that you can incorporate in the future such as:

Sounds played when coupled or uncoupled from the train car
Trains air system depleted when uncoupled/handbrakes need to be activated or the train can roll freely due to gravity
Or incorporate a feature in the xml sheet that allow the developer to mark off which cars can be uncoupled from the unit and operated or will be trailer cars and must be operated from the headunit

[leezer3]

Completely agree.

Have added CanUncouple to the coupler XML. (Add in the same way as a distance)
A sound played when uncoupling may be added in sound.xml via the following:

<Coupler>
<Uncouple>filename.wav</Uncouple>
</Coupler>

Train air system is on the list of things to look at, but is complicated by the fact that the pressure distribution is actually only dummy averages, rather than proper simulation.