John Dowson

I understand what is happening now - the fix is relatively simple. I will post you a version to try later today.

Checking the logs further, it seems that the config update request from the 2nd client is being picked-up by the first client and is being re-mapped, causing issues: I have enough information to look into this now, and will report back when I find the cause. Thanks for those logs! John

Note also that the WAPI is open source (see https://github.com/jldowson/FSUIPC_WAPI) and a debug version of the library is available. It may be easier if you can try and track this down in your plug-un/client (unless I can reproduce). Try with the debug enabled lib to se if you get any more information... John

👍

Not sure what you mean by 'second [WAPI] Section' - there should only be one....! But thank you - I can finally see the messages from the WAPI that I was looking for... This narrows it down to around 10 lines of code, which look ok...I will investigate further tomorrow, but I think I will need to provide you with a special build to track this down further...it is crashing somewhere between the LOG_DEBUG and the LOG_TRACE statements in this section of the code: sprintf_s(szLogBuffer, sizeof(szLogBuffer), "EVENT_LVARS_RECEIVED: dwObjectID=%d, dwDefineID=%d, dwDefineCount=%d, dwentrynumber=%d, dwoutof=%d", pObjData->dwObjectID, pObjData->dwDefineID, pObjData->dwDefineCount, pObjData->dwentrynumber, pObjData->dwoutof); LOG_DEBUG(szLogBuffer); noLvarCDAsReceived++; CDAName* lvars = (CDAName*)&(pObjData->dwData); // Find id of CDA int cdaId = 0; for (cdaId = 0; cdaId < MAX_NO_LVAR_CDAS; cdaId++) { if (lvar_cdas[cdaId]->getDefinitionId() == pObjData->dwDefineID) break; } if (cdaId < noLvarCDAs) { for (int i = 0; i < lvar_cdas[cdaId]->getNoItems(); i++) { sprintf_s(szLogBuffer, sizeof(szLogBuffer), "LVAR Data: name='%s'", lvars[i].name); LOG_TRACE(szLogBuffer); Its also strange that this only occurs when you have a 2nd WAPI client running. I will test with multiple WAPI clients tomorrow and see if I can reproduce...although that section of code should be independent on clients used.... Uhm ... I don't know what you mean, I'm not aware that I enabled something like that in the first place 😮 I'm just starting it (IPCManager.cs#L73) and checking the IsRunning State (IPCManager.cs#L29). Only after WASM is ready (that is after VariableListChanged Event received) the Lvars are read (IPCManager.cs#L267 --> IPCValueWASM.cs#L18 - for every unique Lvar the User has configured and currently visible on the Deck) Update frequency of lvars CAN be set by the client, using the LvarUpdateFrequency ini parameter, I'm not sure how thus is used/set using Paul's dll, but it should certainly be possible to set this to 0 (i.e. no update - let the WASM control this), which should be the default. As your plugin is requesting updates, this has been changed to a non-zero value. Find out where that is, and change or remove it. Ask on Paul's dll forum if not sure.

I really don't know - the MF discord channel is probably a better place to ask this...with the Fenix A320 being so new, there is still a lot of discovery doing on on how to control this aircraft. The hubhob community-driven preset list is the site to follow for this - you can add any presets discovered, and I always include the latest preset list (events.txt file) with each FSUIPC7 release. John

That is the definitive source for the MSFS variables, so use that... it gives the original variable type.. Which is why I don't in the documentation...!

Have you checked the Linda forum? https://www.avsim.com/forums/forum/424-linda/ Lots of documentation and tutorials there, and you are probably better off posting your question there... John

Then your issue has nothing to do with the issue of this thread - this thread is about key press assignments not repeating - the xbox controller has no keys, but you can send key presses on buttons, which is completely different (i.e. it is a button assignment issue, not a key assignment issue). For your issue, I suggest you read the README.txt file that comes in the zip file: John

The FSUIPC7.log doesn't show anything...can you change the log-level to Trace and repeat please. Maybe also activate Event logging in FSUIPC7. The WASM log shows that something, probably your plugin, is configured to send lvar update requests to the WASM: This won't be the cause of the crash, but you should disable this and leave the lvar update period to the WASM (you can change this period if you like). Show me the updated logs. Finishing now - I may take a look tomorrow morning if I get time, but most probably be Monday.

You can use the lua com library to read the state of buttons of a HID joystick type device - see the FSUIPC Lua Library documentation, function: com.gethidbuttons(handle, str)

But those logs show that FSUIPC7 ran as expected and exited as MSFS was no longer running. Also no WAPI Debug level logging is present in the FSUIPC7.log (although it is in your PilotDeck.log) - are you sure you enabled it? Maybe have your plugin running, so that FSUIPC7 crashes and I can see the log from that. I cannot help debug a crash in your application.

Try the offset status document, installed with the rest of the FSUIPC documentation under your documents folder. John

You have to determine if there is a simvar (a simulator A type variable, most held in FSUIPC offsets), or an lvar that holds the current which position. Its most probably the latter - try listing lvars to see if there is anything appropriate. If there is, you can read that in lua. John

First, can you download and try with the latest FSUIPC7 release, v7.3.5, released earlier today. The WASM & WAPI have also both been updated to 0.5.9 in this release, so you will also have to recompile your plugin with the latest version. Once that is done, if you still experience the same issue, can you activate Debug level logging in both the WAPI and the WASM and show me both your FSUIPC7.log and FSUIPC_WASM.log files. A WAPI log file from your StreamDeck plugin would also be useful, if you could also generate that with Debug level logging. I think your issue may be to do with having multiple WASM clients... John

Of course - I used 82 (R) so that I could test with Win+R that opens the windows 'run' command window - I did tell you this earlier on: Anyway, glad you finally figured it out.

Really? You should show me what you tried...I need to see your FSUIPC7.ini and an FSUIPC7.log file with Buttons & Keys logging activated. It should be sending the assigned key press if done properly, as in the screenshot I posted (but using 89+512, as indicated. If that is not working I would like to understand why... But there may be no change...you should test this now, before I release, if you want this working... No idea what this is supposed to mean...

I will look to see if I can add anything to help with this in a couple of weeks or so...I will let you know. I'm not too familiar with the windows API for mouse control so I need to investigate...I will report back if/when I find anything. John

Thinking about this a bit more, it may be possible to allow this to be sent as a key press assignment...I will implement and check before I release to see if I can enable, but in the version I posted you will have to use the key press controls. John

What is this? As I said, you have to assign to the Key Press & Release control, right hand side of the assignments dialog, not send as a keypress on the left. That cannot be used as windows hijacks the key press and it won't register.

Can you explain what you are doing...this is the assignment I tested with, Win+R (win+Y doesn't trigger anything I can test...):

I think your problem is almost certainly related to the Fenix A320. A lot of people are having issues using FSUiPC to control the main flight axes (check this forum!), and they currently only seem to be able to assign via MSFS assignments. As MSFS doesn't support PFC hardware (as far as I am aware) then this is not an option for you. Maybe also check the Fenix support forum (I assume there is one...!) for this... John

I can't see how that can be related to the auto-start issue - those installation components only install files (the MF events.txt file and the MF events file) into your FSUIPC7 installation folder. The pop-up dialog doesn't appear when you don't install the MF events.txt file. Strange!

The general method of determining what controls/events to use is to activate the appropriate logging (Events or axis controls) and then operate the function in the cockpit UI and see what events are logged. Otherwise, ask in the support forum for the aircraft you are using, if available. What pdfs are you referring to? Those for FSUIPC3 or for your aircraft? If the latter, then I still suggest that you need support from the aircraft provider. If the former, tell me what pdfs you are referring to and I will see if I can find them and take a look so I know what you are talking about... John

There is no control/offset to do this directly. However, you could possibly write a lua script to achieve this - in the lua you need to determine the current local or zulu time (I am guessing there should be a way to do this in lua but don't know off-hand - try google) and then set the time via the local and/or zulu time offsets (see the Offset status document). Probably better to do this in zulu time, as the local time for your PC is most probably a different time-zone to the local time in the FS. John