John Dowson

Done.

Strange issue...no idea if it is related to FSUIPC. Can you please activate logging for Events and Buttons & Keys, and produce an FSUIPC7.log file showing your issue, than attach that as well as your FSUIPC7.ini file and I will take a look - the log file may be large and need zipping. You can do this with the logging console window open, and see what events/timestamps you see when this occurs, which may help identify the cause. John

Yes, I would have thought you would get the discount price. However, don't have any control over SimMarket's discount pricing policy, but I will see if I can add a discount if you have previously purchased FSUIPC4/5/6 in a bundle, if possible... John

Just checked and it looks like I removed this ini option ion FSUIPC7 but have forgotten to remove it from the documentation. Too many people were having issues with Joy id changes as they weren't using the JoyLetters facility, so I originally just change the default from No to Yes. However, as many users transferred there ini files from other FSUIPC versions, this was still not being set so I decided to remove this option altogether but forgot to update the documentation. This option really isn't necessary. If you want to change the original letter assigned, just do this before you make any assignments and then reload/restart. I will update the documentation to make this clear. John

Why don't you just try the trial license, available in a thread at the top of this forum. It has currently expired, but I will be generating a new one a bit later today. If your VRInsight devices are serial devices, see appendix 3 of the Advanced User guide 'Handling VRInsight serial devices in FSUIPC', together with the separate document Lua Plugins for VRInsight Devices. John

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...!