Jump to content
The simFlight Network Forums

pilotjohn

Members
  • Posts

    377
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by pilotjohn

  1. So I used the client library's FSUIPCExampleCode_CS project to test this out by modifying the BC004_WritingOffsets example. 0x3340 triggers and logs, 0x7f00 does not. This removes StreamDeck and my original setup/code from the equation at least.
  2. Hi@John Dowson @Paul Henty, So I used the FSUIPCExampleCode_CS project to test this out by modifying the BC004_WritingOffsets example. I changed altimeterPressure to point to 0x3340 offset, and used a bool to toggle whether I was setting it to 1 or 0. This works and FSUIPC receives it. private Offset<ushort> altimeterPressure = new Offset<ushort>(0x3340); // 2-byte offset - Unsigned Short private bool b = false; ... private void btnSetStandardPressure_Click(object sender, EventArgs e) { b = !b; this.altimeterPressure.Value = (ushort)(b ? 1 : 0); It showed up in Buttons & Switch Assignments, and in the log for the offset: 643313 Monitor IPC:7F00 (U8) = 0 643313 Monitor IPC:3340 (U8) = 1 705719 Monitor IPC:3340 (U8) = 0 706032 Monitor IPC:3340 (U8) = 1 706219 Monitor IPC:3340 (U8) = 0 706719 Monitor IPC:3340 (U8) = 1 715594 Monitor IPC:3340 (U8) = 0 715782 Monitor IPC:3340 (U8) = 1 715969 Monitor IPC:3340 (U8) = 0 I then changed altimeterPressure to point to 0x7f00 offset, but nothing happens. It doesn't trigger in the Buttons & Switch Assignments and shows nothing in the log. private Offset<ushort> altimeterPressure = new Offset<ushort>(0x7f00); // 2-byte offset - Unsigned Short Thoughts? Thanks, John
  3. @John Dowson Thanks... I tried to use 7F00 with the client libraries, but FSUIPC doesn't seem to be reacting to them. Any thoughts on whether this is a client library or FSUIPC issue? Or me? I posted a thread here:
  4. Hi @Paul Henty, I'm using your client libraries in a small plugin for StreamDeck to trigger virtual joystick buttons at offset 3340. This works fine. I'm updating my plugin to use offset 7F00, which provides more joysticks and buttons. I updated my usage, but this doesn't seem to trigger FSUIPC. I simply changed my offset declaration from: private readonly Offset<BitArray> Buttons = new Offset<BitArray>("Buttons", 0x3340, 36); to: private readonly Offset<BitArray> Buttons = new Offset<BitArray>("Buttons", 0x7f00, 256); and my bit calculation (example for clearing) from: Buttons.Value.Set((vj - 64) * 32 + bn, false); to: Buttons.Value.Set((vj - 64) * 128 + bn, false); All other logging I put in (which button being pressed etc.) work as expected, and there seem to be no other errors in any of the StreamDeck logs. I also put a watch on offset 7F00 as U32 in FSUIPC, but it seems to not be receiving anything. Any thoughts? What am I missing? Thanks, John
  5. I've tried in the past, but the number of fuels selectors available doesn't seem to have been reliable. I'll have to try to again to see if there have been any improvements.
  6. I'm specifically asking about the FSUPIC specific range that starts at joystick #64 (via offset 0x3340)? Based on the 36 bytes, it seems to be 9. Is there a way to use more somehow?
  7. Hello, One of the things I'd like to be able to do is cycle through available fuel selector positions, except OFF (e.g. LEFT, RIGHT, BOTH, LEFT, RIGHT, BOTH) with a single button, ideally usable for all aircraft. Has anyone done something like this yet? I tried this in the past with an FSUIPC Lua, but there were challenges (e.g. setting a non-existing selector index would report it set even though the model wouldn't do anything with it). Does anyone have any suggestions? Thanks, J
  8. Is it 16 (64-79)? I'm trying to space my panels out. Thanks!
  9. Hello, Many times FSUIPC won't provide input when MSFS is first started and a flight is loaded. I have to quit and restart FSUIPC and then it starts working. The log in the former shows connected but never becomes ready (log attached). Have you seen this before? Thanks, John FSUIPC7 - No Input.zip
  10. @Perk Did you find a solution for this? I tried a few things and none of them worked. Using Axis Mixture N Set Using Axis Condition Lever N Set Using Mixture N Set Using Condition Lever N Set CONDITION_LEVER_1_CUT_OFF and CONDITION_LEVER_1_HIGH_IDLE using range Toggle Fuel Valve using range
  11. @nantelpDid you find a solution for this? I tried a few things and none of them worked. Using Axis Mixture N Set Using Axis Condition Lever N Set Using Mixture N Set Using Condition Lever N Set CONDITION_LEVER_1_CUT_OFF and CONDITION_LEVER_1_HIGH_IDLE using range Toggle Fuel Valve using range
  12. No I didn't have the assignment window open. The reinstall of 7.0.9 from April 14th seems to have "fixed" it.
  13. I'll try with the latest. No, the logs are before I quit FSUIPC to restart it, but was sitting on the ramp in the plane. I'll attach the full chain of events next time (if it still occurs).
  14. Yes, I'm using the "old" release (where you added offsets for engine master). The log is complete, as in, that's all FSUIPC would show despite loading up a flight and being ready to go. Is there an official source for the latest greatest version (I'll search for these for now)?
  15. I launch FSUPIC before the sim starts. With the latest update ipcReady never fires after loading into a flight and FSUIPC doesn't actually work (e.g. controls/events). I have to relaunch FSUIPC in order to regain functionality. Is this a known new bug? FSUIPC7.zip
  16. It's the WASM module that was CTD on loading screen for me.
  17. Thanks, it works using the new offsets as bytes.
  18. I'll try this. I was testing on the TBM930 which does have off/on/auto and setting them to 0/1/2 does correctly set the switch and function.
  19. Yes, the individual ignition switch state for each engine would be ideal as multiple offsets.
  20. Ok, so it looks like this "should" work as expected (e.g. there's no update between the two sequences), but it doesn't because 208C only shows a value of 1 regardless of whether the control sends 1 or 2 as the param. The aircraft switch behaves correctly (Auto vs On) but 208C always reads 1, never 2, and 0 when off. I'm not sure if this is a sim/aircraft issue or whether the value is reflected incorrectly in this offset. Any thoughts? Resetting the flag is a great idea, I should have thought of it, thanks.
  21. I tested with lower sequence numbers: 360=P65,9,C65930,0 -{MAGNETO1_BOTH}- 361=P65,9,C67059,1 -{ENGINE_MASTER_1_SET}- 362=D208C<2 P65,9,C67017,2 -{TURBINE_IGNITION_SWITCH_SET1}- 363=D208C=2 P65,9,C67017,1 -{TURBINE_IGNITION_SWITCH_SET1}- And the result is the same. It appears offset values are modified immediately after #362, so pressing this button always just result in the ignition set to "1". The flag idea works (thanks for the pointer), but it's less deterministic from a user standpoint (not predictable where the toggle state will land when switched off). So is the only other option then a Lua?
  22. What would the pause help with in this case (assuming both actions are actually being executed).
  23. They are in the INI (placed next to #42, #1042 etc.), but there is 2043 (for example). I'm basically trying to group button actions using this method. I have >200 "base" assignments (made in the UI), and to pick the right sequence when adding additional controls I would have to find the next highest one. So I'm using this schema, where additional actions for a given base are +1000 +2000 etc. In this case #41 is MAGNETO1_BOTH, #1041 is ENGINE_MASTER_1_SET. I'll verify that #3042 is being used. This works across many planes/types that achieve same functional result (e.g. some sort of ignition on). I'll look at this, thanks.
  24. I have the following to try to toggle between auto/on for ignition (off is separate). 2041=D208C<2 P65,9,C67017,2 -{TURBINE_IGNITION_SWITCH_SET1}- 3041=D208C=2 P65,9,C67017,1 -{TURBINE_IGNITION_SWITCH_SET1}- The above doesn't work because offset 208C is updated immediately with the state (2) after sequence 2041, so 3041 will always trigger. Any chance you could add a "break" option to this syntax that would stop process or ignore sequences after the break? The other option would be to treat the "state" as atomic across all sequences (or at least per button), but I imagine that would likely break lots of legacy stuff. Or, do I have to use a Lua for this?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.