Input events get lost in FSUIPC if debug is not enabled

Issue #136 resolved
Sebastian Möbius created an issue


  • Input offsets when used once are read continously which may lead to a race condition.
  • Input offsets should only read when used by a button
  • FS Event Inputs are having this problem extremely
  • Maybe it helps to not continously read input-only events

Comments (20)

  1. Akis Papapantelis

    Hi Sebastian,

    Congrats for Mobi!

    Issue #136 still exists. I have the latest mobiflight version (7.3.2) and firmware (1.7.3)

    I just spent 2 hours testing all possible failing points and concluded that when not in debug mode mobiflight ignores inputs on a random but regular interval. This never happens with debug mode enabled. I would just leave debug mode on but it causes my rotary encoders to be very slow.

    I am also a fellow programmer/project manager. It would be a life saver if you could investigate this further.

    Thank you, Akis

  2. Tom De Cooman

    I also noticed similar behavior, where from time to time a push on a button or a flip of a switch is not seen in the sim. I added 2 actions to 1 button, the left and right F/D. During a test , after flipping the real switch only 1 of the virtual F/D switches moved. Will try the debug mode.

  3. Tom De Cooman

    Hey Akis,

    I did, but noticed the same thing: slow encoders, which will be normal with this high level of logging. But, while it looked ok during some tests on the ground, in flight I still noticed missed events. I am turning off logging again for the time being.

  4. Akis Papapantelis

    Yes encoders are not usabe with debug mode on. I never checked flying with debug mode to see if events still get missed.

    I hope Sebastian can get this fixed soon because it is, in my opinion, the biggest issue with mobiflight.

    Sebastian are you working on it? I could also try to debug but it will take some time for me to understand the code.

  5. Tom De Cooman

    Just some extra info which might help figuring out what the culprit is. Something else I noticed, experienced while using the PMDG 747 where when you use a middle click on any of the 4 landing switches all of them move. The middle mouse action is assigned to the rightmost landing switch. When moving the hardware switch, sometimes just that one landing switch moves instead off all of them.

    As a test, I'm going to split the needed actions using custom fsuipc offsets and a lua script. Mobiflight to set a custom offset and the lua script to read the value and set the event id.

  6. pizman82

    In case i not be able to "edit" this issue i will comment it.... Maby Sebastian can copy paste this to the topic if needed !

    Summary of our Meeting last week:

    • Problem:
      The Missing Input Events happen if a Offset is written and the SAME Offset is Read by the "Loop" permanent multiple time per second.

    • Problem History: In Old Version (Pre 7.3.x ) A Config that include ONLY Inputs have no problems. Here The Read was just executed single one time when push the Button. If you also include a Output Config then at beginning only the Output Offset was read by the Loop ! After pushing the button first time then the Input Offset would be include to the Loop, too.... In Logging we can see that "now" both offests got read permanent.... And From this point the "missing event" Problem start. In New Versions (Post 7.3.x also 7.4 and 7.5) There was a change.... Now a Input config occure in a permanent Read Loop at all time (after first use) Whatever a Output Config is existing or not. So finaly this "hotfix" not solve the problem.... It increase the problem after all.

    • Recommend Solving procedure.... and Ideas

    1. Rework of Read/Write function and priority. To solve the Problem complete we must get sure a Write will be executed correct in FSUIPC (Maby stop reading for this periode) BUT Sebastian said this is problematic, cause the Read/Write is not done by Mobiflight. Thats a Tool (Library/Plugin/Compiler etc) that is hardcoded by FSUIPC. Benefit: This will solve 100% of Problem if we find a Way.

    2. Splitting the Input Configs (Single Read) and Output Configs (Loop Read) indipendent . If you be able to make 2 Systems here..... so a Input Offset will not get into the "Loop" then problem is much better. BUT Here Sebastian also means this is a "external" Problem and he can not make 2 different Read procedures in the Programm Benefit: Here maby 90% of Problems are solved.... Only Offsets we need to Write and also need to Read (For a display e.g.) are already involved.

    3. QUICK Help by simply exclude EVENT ID from the Read Logic ( I think this is the best Solution and should be done in next release ! ) Input Typ "EventID" basicly need no Read ! A Event ( Offest 3110/3114) have no "indicator Value $". So a Read is NEVER needed. If possible simply delete the Read Request here.... If my theory is correct then ALL Inputs via EventID will work 100%. Benefit: This will solve maby 95% of Situations.... Just some AddOn specific things like Jeehell will occure in Problems ( If there are no events to use) Here we can then work with Keycommand, Vjoy or Virtual Joystick Range of FSUIPC to create this maby 5% of Inputs direct in FSUIPC.

    @ Sebastian. If Possible please just tell us.... Is it technical possible (and easy) to exclude the Read in EventID Configs ?

  7. Log in to comment