[Aldarion]

Both are interesting for my project in the national railway museum in Portugal in wich I have a full cab sim working. But if I had to choose I'd go with the capacity to control the sim through a smartphone or any other device so I could alter rain, fog, and even simulate faults by altering readings on brake pipes ( or any other OR variable loaded into memory)...

[Weter]

Yes. A student uses drive-stand with its controls and gauges, while an instructor have full control on whole program, including options and debugging functionality via, say tablet.

[cesarbl]

Well, that's beyond what I had in mind.

The idea is to control cabview controls with external hardware, not just limiting to RailDriver (say potentiometers, buttons, etc.)

[Weter]

so, only train controls, analog - looking (e.g. Levers with continues range)
Custom-built, or factory-serial?

[Laci1959]

Helló.

https://kephost.net/p/2022/44/4337_f4dccf21987d.jpg

Version for raildriver. Made from disassembled V43 parts. It was originally created for the EU 07 Maszyna program, but can now also be used for OR.
Since then, the owner has also used 3D printing for the TAURUS locomotive.

Sincerely, Laci 1959

[Aldarion]

Weter, on 31 October 2022 - 08:07 AM, said:

Yes. A student uses drive-stand with its controls and gauges, while an instructor have full control on whole program, including options and debugging functionality via, say tablet.

Yes something like that only in my case, visitors would use the drive-stand and me, with a side control on my smartphone, to play some tricks on them :rotfl:

[cjakeman]

Hi Cesar,

cesarbl, on 31 October 2022 - 05:17 AM, said:

Technical details: I'm re-using HandleUserInput() function of CabViewDiscreteRenderer, substituting ChangedValue() by the value given by the API. Therefore, minimal code changes are needed to support all existing cab controls.

Any ideas or suggestions?

This is going to be a significant extra functionality for Open Rails. Very happy to see it going ahead.

I am hoping that we can re-factor the code just a bit and pull some common code out of CabViewDiscreteRenderer.HandleUserInput() which can then be called by both the new API and HandleUserInput().

I'm hoping to take a look and see what's possible. Send me a PR if you want to discuss this in detail.

[cesarbl]

Hi Chris,
I'm waiting before uploading the changes because I'm basing them on the cruise control branch, as CC creates a variety of new controls that would otherwise conflict with my changes.

Quote

I am hoping that we can re-factor the code just a bit and pull some common code out of CabViewDiscreteRenderer.HandleUserInput() which can then be called by both the new API and HandleUserInput().

Yes, my idea was to reuse it as much as possible to avoid duplications. Almost all the controls work with the HandleUserInput(), except precisely some of the cruise control levers. I also reused parts of the RailDriver code.

Another thing that might need discussion is the protocol. I'm currently using HTTP POST requests, and sending data in JSON format, which is not really fast. From my tests speed seems OK, but somewhere in the forum it was suggested to use WebSockets instead. Maybe both protocols can be implemented in the future, but I think that if speed is an issue then serializing and deserializing JSON every 50ms is not the best idea, so for WebSockets another protocol would be needed. I think we can stick to HTTP POST at the moment, which can be easily implemented using Python scripts.

[cjakeman]

cesarbl, on 07 November 2022 - 12:44 PM, said:

I think we can stick to HTTP POST at the moment, which can be easily implemented using Python scripts.

I'm starting to look at this now. I've no objection to using WebSockets if speed becomes an issue, but I'm using HTTP POST and JSON for now, as you are.

[Genma Saotome]

I've always thought this was a great idea with huge potential. I don't now recall if the output will just be text or whether there will be some structure (f4 and f9 come to mind)? Is .css plausible?