John Dowson

That file is deleted when you uninstall, and will be created (in-the-fly) the next time you run MSFS. It is automatically generated once connected to MSFS. John

Yes, sorry - TrafficStallTime cannot be set to a negative value, my mistake. Set this to 2 or 3 seconds (or higher) if using traffic data. If not, it doesn't matter. Hmm. Maybe that is the case - I will check. However, I think that profile specific luas should be started/auto-run when you start FSUIPC with an aircraft already loaded. However, they won't start until the lvars/hvars have been received. I will check this - but next week now, I'm off tomorrow and back next Thursday, so I will check then. Ok, thats good to know, thanks. John

What has FSUIPC got to do with any of this? And what does C1, Vr and V2 actually do? FSUIPC is aircraft agnostic - it just sends controls as you have assigned for that aircraft. The controls for many MSFS aircraft, especially add-ons, can be aircraft specific, and in the case of the FBW A320, version specific. Take a look at the MobiFlight HubHob resource (https://hubhop.mobiflight.com/presets/) and you can see what is available for the different version of the FBW A320, and also the Fenix A320 and the Asobo 787. You will see that the controls you need to send are quite different for each aircraft. In FSUIPC, you need to assign the correct control for each aircraft (using profiles). I know nothing about FDC Live Cockpit - you will have to consult the documentation or support forum for that program to see how (and if) it needs separate configuration for different aircraft or versions. John

I know why you say this - FDUIPC can be used with any HID joystick type devices, as well as other devices like GoFlight and PFC devices using specific drivers that we provide. You don't need to use lua if yoy don't want to, although it may be necessary for non joystick type HID devices. FSUIPC does not have any facilities for talking to IOS devices. If its only GPS data that you require, then it may be possible then you may be able to configure FSUIPC's GPSout facilities (see User Guide) to provide the correct data for that program from a USB acting as a standard serial device on the FS PC. Otherwise, there may be additional programs to help with this (e.g. WingX). Alternatively, there is a websocket server/interface also available, and any web pages written using these dacilities should be accessible from a web browser on any device. There have been several questions on using ipad with FSUIPC before, maybe check some previous posts - here are a couple (version of FSUIPC and the FS dont matter here as the FSUIPC facilities are the same): There is also a utility (FSXFollow) that allows connection but using WideServer: By the way, you posted in the User Contributions sub-forum where it states NOT for support requests. I have moved your post to the correct forum. John

I will update tomorrow.

That is very strange...that version has been released now as 7.3.6. There was only one change and I can't see how that could effect that... Please download and try the latest release. If you get the same issue, activate logging for Lua Plugins and set Trace logging for the WAPI (in your FSUIPC7.ini)) and show me the log file as well as the lua script.

Do you have AutoAssignLetters=No in the [JoyNames] section?

Got me sad because I´ve spend €60+ and now own a plane that I can´t fly. That is unfortunate...they should make it clear that the aircraft cannot be controlled externally from MSFS. Many home-cockpit builders will have the same issue. Maybe try asking for a refund... Thanks for the update. John

I have also updated the dll - please find attached.FSUIPC_WAPID.dll I will release this version shortly. Thanks got your help with this. John

Ok - so this also indicates the issue is/was with the WASM/WAPI. That would be good, thanks, After you have done this, you can disable the WASM and uninstall it again if you like. Not an issue keeping it installed/running, but may as well remove to save resources if not using. John

Hi @aurel42 I found an issue in the WAPI (WASM interface) code that can cause FSUIPC7 to crash in certain circumstances. This is fixed in the attached version if you would like to try it (with the WASM enabled). John FSUIPC7.exe

@Fragtality Could you try the attached version please. I've also attached the updated WAPI library (and header - not sure if you need this) for you to use to rebuild your client (zipped). Let me know how it goes - attach the trace logs again if any issues. Thanks, John FSUIPC7.exe FSUIPC_WAPI.zip

It is the specific PMDG offsets for the PMDG 7XX aircraft that were available in FSUIPC4/5/6 that aren't currently available in FSUIPC7 (see documents Offset Mapping for PMDG...pdf available in those versions of FSUIPC). This data was provided by the aircraft via SimConnect using specific Client Data Areas. It is not clear if this data is provided by the MSFS version, nor the structure of such data if provided. I am still waiting clarification from PMDG on this issue. John

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.