Test: Send/Receive Data between openBVE and external application

As everyone knows, the BVE/openBVE provide only 16 ATS buttons for train plugin.
With train having some systems, or even computers (or TIMS, TIS, etc.), there are far away more buttons for driver to press.
In this case, those 16 "internal" buttons can/should only used for very essential work on train driving.
How about when I want the driver to do lot more with for example the Train Information (or something else) System, like playing a PA?

And finally I did this (prototype).


Player would start the external application, whenever the openBVE has completed loading the route and train.
When Train Plugin has completed Load(LoadProperties properties) call, the Named Pipe Server should start and the external application should be able to connect to it.
Named Pipe can be just in In or Out mode, but duplex should be used in this scenario.
Currently I'm just testing the possibilities of this trick, so only ElapseData would be sent (by serialising as JSON).

This idea might be used in another future projects, possibly a tube, and a "display card-burning" stuff.

(Edit@20140219: If you'd like to see how it actually works, check out this HKHR-ATP source at my GitHub, starting from commit 7e2de35d4a5a87eed9f3854ab537bd4eec824eb4.)

Very interesting! And really promising. Would maybe even allow for real multiplayer; plugins may be unable to control signals, but they are able to simulate and thus control an in-cab signalisation like LZB, TVM or ETCS...

Quork wrote:Very interesting! And really promising. Would maybe even allow for real multiplayer; plugins may be unable to control signals, but they are able to simulate and thus control an in-cab signalisation like LZB, TVM or ETCS...

If me then I'll probably fork the openBVE's code instead...
It'd be even better if I can be a co-developer of openBVE, but I don't see any ways to contribute (new codes) to the openBVE

Post-Scriptum @20140209 UTC0 1917:
The Named Pipe is a kind of Inter-Process Communication which does only provide communications locally. Socket, or TCP which BVEStation tried, can do IPC remotely.

I have a better idea. How about someone just opens up the ability of a plugin being able to influence and affect the main bve code.
Plugins can do a lot for a train but so long as the core bve code won't allow itself to be configured by a plugin, you are limited to cab only.

Wow. This sounds very interesting. So basically, with this external program, it would increase the features on trains and this could make openBVE more realistic by simulating more in-cab systems?

Exactly. It allows for far more sophisticated simulation of modern, busbased (I'm speaking of IT-busses, not of omnibusses ;-) ) vehicles, which is really, really great news.