Probably not important for sidestick, rudder, or toe brakes, but everything else which is directly related to the simulated state of a physic control (parking brake, gear handle, engine master, in future flaps, and so on) should exhibit clear mastery and attempt to reset the game state where they are out of sync.
Do a PoC with, say, the parking brake, where GameController.cs properly scans the hardware at startup (at present it only really notices changes, so can start in the wrong state). That class already has a convenient place to store the current position, so they we just need a better way to detect when both it and the sim are in the correct state (the GC itself is easy because the raw might be missing, though we need to detect a controller being removed and unset it). (We might first wish to refactor to only store the old as current, with the new values being transient when scanning for changes.
But for this to work reliably, we really need a clearer division of responsibilities:
- Master: the code directly facing the hardware and communicating the desired state
- Slave: the thing which listens for the state of that(those) control(s) in the simulator (and perhaps also understands the sim state, so that we aren't trying to sync when its paused or not even running, or if an inappropriate aircraft is loaded)
- Controller: the thing which compares the outputs/states of all the above and decides when to actually attempt to perform a sync (which in normal circumstances, i.e. control just changed and sim running with appropriate aircraft); this thing may also need to understand that the sync may not be instant, and decide whether/when to attempt to retry a sync
- Syncer: actually does the syncing, i.e. knows what things to send where to attempt to realign everyone
That will make more sense that the current mess for physical controls, and also potentially allow the web UI to assume mastery of some things. The complication there is that we sometimes have multiple browsers looking at the same thing, so ideally we understand that only one of them can actually be a master, and that for stuff mastered by the sim itself we ideally don't need to request it from the sim to just repopulate a single instance of the web UI. So in the usual case, the Master is actually the sim-facing listener, the Slave is potentially one per SignalR client, and the state of the sim (running or not) is probably not important.
Probably not important for sidestick, rudder, or toe brakes, but everything else which is directly related to the simulated state of a physic control (parking brake, gear handle, engine master, in future flaps, and so on) should exhibit clear mastery and attempt to reset the game state where they are out of sync.
Do a PoC with, say, the parking brake, where
GameController.csproperly scans the hardware at startup (at present it only really notices changes, so can start in the wrong state). That class already has a convenient place to store the current position, so they we just need a better way to detect when both it and the sim are in the correct state (the GC itself is easy because therawmight be missing, though we need to detect a controller being removed and unset it). (We might first wish to refactor to only store theoldascurrent, with thenewvalues being transient when scanning for changes.But for this to work reliably, we really need a clearer division of responsibilities:
That will make more sense that the current mess for physical controls, and also potentially allow the web UI to assume mastery of some things. The complication there is that we sometimes have multiple browsers looking at the same thing, so ideally we understand that only one of them can actually be a master, and that for stuff mastered by the sim itself we ideally don't need to request it from the sim to just repopulate a single instance of the web UI. So in the usual case, the Master is actually the sim-facing listener, the Slave is potentially one per SignalR client, and the state of the sim (running or not) is probably not important.