I've been looking at ways in which the RailDriver device might be supported and it seems to me that an expansion of the ats plugin proxy might be the least disruptive.

I have this idea of developing a raildriver dll which is called by the ats proxy plugin. The changes to the proxy code would be relatively small, basically adding a call to initialise the new dll and hence the raildriver and then calling a "control position" function everytime elapse is called. This function would return the required states of the various controls on the raildriver hardware.

Where this scheme falls down is the limited scope for feeding the required control states back into the core program. The ATS_HANDLES structure (returned by Elapse) provides a way to feed back desired throttle, brake and reverser control states to the core program which is a start but it doesn't support any other controls such as the horn or the various ats controls.

Therefore I was wondering if there was any possibility of providing an expanded ATS_HANDLES structure containing additional controls for use between the core program and the ats proxy. This would obviously require changes in the core code to act upon the additional control requests. This wouldn't affect existing plugins as they would continue to be called with the existing structure but it would start to open up the proxy as the starting point of a more general purpose control interface.

Now I could do this myself but everytime there was a new release it would have to be done again. I don't see this as a problem for the proxy as I expect that to be relatively stable and thus less likely to change whereas the core program is going to be evolving all the time.

Perhaps you could give this idea some consideration.

I think that the most useful approach would be to write a device driver that exposes the device as an ordinary joystick, which in my opinion, it is. Changing the (legacy) plugin API to accomodate support for one particular proprietary device is not something that I will do.

The most striking issue though is that your idea wouldn't work in the way you think, anyway. If you implement support for the device via a safety system plugin - and given the fact that there can only be one safety system plugin in use at a time - there wouldn't be any safety system such as ATS/TPWS/etc. to which you could send commands (except for the built-in). If anything, you would also have to write the corresponding safety system, and then, you don't need further interaction with openBVE as the safety system would also be simulated in your plugin (so you can simply evaluate and incorporate the data of the device directly). Of course this basically means one plugin per safety system as they usually aren't combined in DLLs (as they are not standardized and often incompatible). Given this approach, there isn't any further expansion of the API necessary - just do everything inside the plugin and use the keys that are available to plugins.

If you have the technical knowledge to implement support for the device, then I think writing a device driver should be within your scope - or at least you could write a program that sends keystrokes to the openBVE application from an externally running process.

EDIT:
For openBVE 2.0, I have already decided to allow for multiple plugins, while allowing any plugin to communicate with any other, so it should be fairly easy to achieve the desired functionality at that point in time.

You may classify Raildriver as just another joystick but I don't. It is the only device specifically aimed at train driving sims and I would have thought that any train driving sim worth talking about would aspire to provide support for it. You clearly think otherwise.

I also don't agree with a lot of the rest of what you say but i'm not going to argue about it. I've done a keyboard emulation implementation for BVE4 but I was looking to do something more integrated. Whether support for multiple plugins makes this easier remains to be seen.

Let me clarify why I think adding direct support for the device (or abstraction layers) is not a good idea. The whole current plugin architecture is an entire dead end, because openBVE targets multiple platforms, but the plugins are Windows-only. Furthermore, openBVE is soon undergoing a major architectural transition, and all future plugins will be entirely .NET-based, not making use of native code. I consider the current plugin API final and am unlikely going to make future additions to it. The new architecture will prove to be much more flexible and versatile for applications like yours.

As I am unlikely going to make additions to the current API, there is another alternative that might be easier for both you and me: Take the source code of AtsPluginProxy.dll, integrate support for the device directly, and then offer the modified AtsPluginProxy.dll as a replacement for those who have the device. This approach would also allow you to directly inject keystrokes to the underlying safety system by simply raising KeyDown and KeyUp events, to modify panels and sounds, to display the speed of the train in the device's LED (if that is actually functional and not just decorative), and of course to modify the handles. You would also get absolutely all other information the plugins receive. What you would not be able to do is to raise the horn as this is simulated inside openBVE, and you would not be able to use the device for trains that don't have a custom safety system plugin - but using your approach, you wouldn't be able to do that either, because AtsPluginProxy.dll is not used in that case.

Consider it a compromise - which should allow you to do most of the intended things.

The Raildriver comes with sample source code in VB.Net, should be fairly simple to port to C#, just a matter of hooking it into OpenBVE, I might look into it when I've got my coursework handed in!