[Bill]

After developing my own interface using the Raildriver interface as a starting point, the less data transmitted, the better. I sent my data in the Raildriver format with the embedded control data, using the Windows Messaging process between programs. But a Web Socket would be best.

The only behavioral change I made with my interface in OpenRails was to remove the automatic reset of the Alerter when a packet comes in. Not every control change resets the alerter. For example, moving the Camera should not reset the Alerter. What I did instead was to set the Alerter bit in the packet if I wanted the Alerter reset with the control change. Since we are talking about people developing external code, I don't see this as a problem for them to include the Alerter reset with the control change packet.

Attached thumbnail(s)

• 

[joe_star]

Am currently using webserver read to get the state of regulator, cutoff and brake, and matching that to a 3-axis saitek flight throttle quadrant. An autohotkey script takes the quadrant axis values, and by sending keystrokes attempts to match the throttle, regulator and brake values in OR. It works quite well, although a direct input method would be much more responsive and accurate

[cjakeman]

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

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.

I've been playing with your new PR Web interface to control cab controls with external hardware and it seems to be working very well.

I've added some slider controls to a copy of the webpage Content/Web/CabControls/index.html so it can post changes to your new API and I was able to drive a train using the sliders, which greatly pleases me.

I shall submit a PR for this in a few days when I've polished it.

[cjakeman]

cjakeman, on 27 November 2022 - 02:10 PM, said:

I shall submit a PR for this in a few days when I've polished it.

The new PR is at "Extends CabControls for user input" and requires Cesar's PR 751 to be in place first, otherwise the sliders do nothing.

[cesarbl]

It seems cab controls are a critical part of the code regarding merge conflicts. I tagged my PR 'not for unstable' because it depends on 'Unlimited TCS Controls' which itself conflicts with 'Extended door functionality'. The conflicts are easy to solve by hand, but they are too much for the Code Bot.

[Aldarion]

Hi cesarbl

I'm takng a look at the API sample to learn how to add more introduction for commands.
for instance, If I want to add the deadmans's switch, should I introduce into the Cabcontrols/index.hmtl the following:

        <div class="control"> <input id="deadman" step="1" value="0" min="0"
            max="1" onchange="sendValue(this.value, 'DEADMAN')" type="range">
          <label for="deadman">Deadman (0 - 1)</label> </div>

Were can i get a list of the commands and values?

[cesarbl]

It uses the same names and ranges as cab view controls. The deadman switch corresponds to "RESET" cab control.

[Aldarion]

Ok. great. Thanks cesar.

[Aldarion]

BTW cesar.

is it possible, at this time, to create controls to change conditions such has fog, precipitation, hour of the day and light? Or is it limited to cab controls for now?