John Dowson

No they were not - you pasted images. Please attach the following files (not paste images or contents): From your server PC: FSUIPC7.log, FSUIPC7.ini, WideServer.log From your client PC: WidweClient.log, WideClient.ini Did anything change? Please check the following: - firewalls: maybe temoprarily disable all firewalls (client and server PCs, routers) to see if its a firewall issue - check your WorkGroup names, both PCs must be in the same WorkGroup You can also try adding the ServerName and Protocol ini parameters to your WideClient.ini file. Please see the Configure your Network section of the WideFS User Guide. And see the trouble-shooting notes in the WideFS Technical guide. Also a good idea to reboot both PCs if you haven't done that already. John

Unfortunately the logs don't reveal much. I have now had MSFS running (and attached to a debugger for the WASM) for around 24hours, switching between the FBW A320 and the PMDG 777 and 737 and have not been able to get the WASM to crash/fail. I had to stop this session as I ended up getting exceptions/a CTD in MSFS. Looks like there is definitely a problem somewhere in the WASM causing this but it is going to be difficult to track down. I will keep investigating, and I do have some performance improvements I would like to implement in the WASM so maybe I will take a look at these to see if this improves things. There are some minor adjustments you can make which will hopefully make this crash less likely. Change the following in your FSUIPC_WASM.ini file (the one in your WASM persistance area, not the one under your Community folder. Set the following ini parameters: LvarScanFrequency=-5 LvarScanDelay=8 LvarScanPeriod=5 Are you sure this is the same problem, i.e. a WASM crash? To verify this, you can either try sending another preset or lvar update - if that works, the WASM hasn't crashed. Otherwise, you need to check in the devmode debug console - search for fsuipc and see if there is an exception message. If it is a WASM crash, also please try those updated settings mentioned above. If not, then I will need to see your files (FSUIPC7.log, FSUIPC7.ini and FSUIPC_WASM.log). John

Sorry, but it is confusing when you talk about 'not showing in task bar'. I think you mean that FSUIPC7 is crashing on start-up. The log files you attached are also very strange, and just show that FSUIPC stopped at different stages during start-up. Can you please download the installer again and re-install from a fresh download. If you get the same issue can you temporarily rename your FSUIPC7.ini file and try again to see if that makes a difference. Also please check the Windows Event Viewer application and see if there are any events related to FSUIPC there, and if so show that to me (they are under Windows Logs -> Application).

And the event information pease. All I can tell you is that WideClient/WideFS has been stable for around 10 years now, with no updates. If it does crash, this normally indicates an issue in your system - maybe a corrupt windows library somewhere. Such issues are notoriously difficult to track down... John

I need to see the FSUIPC_WASM.log from when it crashed. Restarting FSUIPC won't help. This is an FSUIPC WASM crash and you need to restart MSFS. Which version of the FBW A320 were you using?

I don't have the 738 and am not familiar with 'squad' - what is it? Is there a control in the Virtual Cockpit for this? If so, do you see any events in the FSUIPC7.log file when this is used? Try logging events (Log -> Events) and open the logging console (Log -> Open console) and see if anything is logged when you activate this in the VC. If nothing is logged, try listing lvars to see if any look appropriate. I can't see anything related to squad the PMDG custom controls or offsets.

Sounds good, but I wonder why it is still off by 1000 feet - it would be useful to know where/how it is deriving this altitude. This sounds strange as offsets CC00-CFFF are documented as the area to READ the weather at the requested location. The writable area is C800-CBFF. To be honest I am not sure how these offsets work - I will take a look in more detail next week, Maybe worth checking these in FSUIPC6 with P3D, or maybe with FSUIPC4 in FSX. The Active Sky files may contain some useful data, especially the current_wx_snapshot.txt file: Maybe worth taking a look at that file. I will see if I can look into this in more detail next week sometime.

Offset area 6700 - 6BFF (1632 bytes) are ok to use if not using Jean-Michael Biston ("Michael") for Airbus gauges or FS-Communicator, which is what they are reserved for. Note that your lua WILL NOT turn on the LED - it will update the offset with the status of the LED/lvar when the lvar changes. Those offsets should certainly work - I will double check them next week, but if having issues try debugging the lua script using the facilities provided (i.e. Debug/Trace Lua plugins in the Logging tab). This will tell you if the script is running and what it is doing. Also try logging the offset you are using on the right hand side of the logging tab, and make sure to check Normal log file.

How long into the flight did this happen? Those files are all from today and show no issues.

No. Can you please show me your WideClient.log file, and also any event information from the windows Event Viewer. If WideClient crashed, there should be a crash event reported with further details. Yes. Instructions are provided in Appendix 4 of the Advanced User guide (page 67). John

Are you using 7.4.15? Was it just the presets that stopped working? You can compress/zip them. If still too big, you can use one of the free file transfer services (e.g. https://filetransfer.io/). It must be there - are you sure you are looking in the correct place? It is in the WASM persistent storage area: John

There are only 4. But you can also log an offset range, although I am not sure where or if that is documented. I have never had a need to use this facility so I would need to check.

Sorry, but what do you mean? What is 'Squad'? What aircraft are you using? That would help....

FSUIPC just reports what events are seen. And this is completely dependent on how the aircraft is implemented. Usually, when an input event is triggered, this can then send various other events - lvar updates, k-evenrs (standard FS controls), h-var updates, etc. BUT, the input event may not trigger everything. So there may be some aircraft when you can send an input event and nothing else, and that is sufficient. For other aircraft, maybe the input event (or b-var) only triggers some actions, and you may also need to add a k-var trgger, or an lvar update, or something else. But this is completely dependent on how the aircraft model is implemented. Some developers/aircraft respect the norms (i.e. an imput event should be sufficient, and the input event code will do everything, including sending necessary k-events, updating lvars, triggering hvars, etc). If badly implemented, you may need to send the Input Event and also perform other actions. But this is nothing to do with FSUIPC. With FSUIPC, you can log what is happening and then try and replicate that with assignments. I cannot control how an aircraft is implemented, only provide the facilities for users to investigate and determine what to use. But generally, if an Input Event is available, use that. If that is not sufficient, then investigate. Or look to see if a preset is available. Presets cover all other control mechanisms (i.e. K-events, lvar updates, hvar updates) apart from input events (or b-vars). So, most things should work with either input events, presets, or a combination of both. And please understand that FSUIPC only provides access to such things. How they are implemented and used in various aircraft is defined by the aircraft developers, over which I have no control.

Sorry, but I do not understand this. If I search for free offsets in the offset document, I find these: This is for FSUIPC6 v6.1.5 and later. The official release is now 6.2.0. If you are using an older version, please update. Is that not enough space to use? If not, then you van use offsets assigned to other things (i.e. 3rd party software such as the PMDG offsets). But please at least first use the offsets available. If then you run out of space, I van let you know which other offsets to use (documented in FSUIPC7, but not yet in FSUIPC6). John

Control numbers must be preceded by C, so its: [Macros] 1=MBAutoT 1.1=C68836,x20000000 1.2=C69837,x20000000 2=FSUIPC. //this is just copied from the manual to check the macro is available in FSUIPC 2.1=K68,12; Tab D 2.2=K70,8; F John

Sent

@VENOMous Still waiting to see your FSUIPC7.JoyScan.csv file so that I can correct your assignments...please also attach your latest FSUIPC7.ini and FSUIPC7.log files.

You can use the FSUIPC SDK to create such a file. Using the SDK, you can write to FSUIPC offsets to trigger events/controls, presets, etc. There are also quite a few wrappers to the SDK for various languages, the most popular and advanced being Paul Henty's .Net client dll. There is a sub-forum for this here: https://forum.simflight.com/forum/167-fsuipc-client-dll-for-net/ Otherwise, take a look in the SDK folder of your FSUIPC installation. John

I do not know of any such control - as far as I understand, there is only the throttle... Do you have an aircraft where it is possible to control this (in the virtual cockpit)? If so, then it may be possible in that aircraft, but there is no generic FS control/event for this.

You can read the name of the current aircraft in offset 0x3D00.

You have NOT installed the MF events.txt file - from you installation log: and from you FSUIPC7.log file: Please re-run the installer and select to install the MF events.txt file, or download it from the MF HubHop site (https://hubhop.mobiflight.com/presets/) and copy it to your FSUIPC7 installation folder.

I don't know as you do not provide enough information. Did you install the FSUIPC WASM module? Did you install the MobiFlight events.txt file (which holds the MF presets)? Please show me/attach your FSUIPC7.log file and also your InstallFSUIPC7.log file and I will take a look.

No! Why do you think that? For example, 0x0D70 is the area for Macro and Lua requests, as it states in the FSUIPC6 Offset Status document: Please see that document, and you can use offsets in areas designated as Free for general use. Thats fine and will store the value of the lvar in the offset (for reading ONLY), except that offset 0x8804 is NOT free for general use. Please DO NOT use offsets that are not documented as free for use as this may cause issues. What is a 'raid folder'? All lua scripts should go in your FSUIPC6 installation folder, or the folder specified by LuaPath if using that. Entries with indices 1m11,12,13 & 14 are ALL incorrect. Lua scripts in this section MUST be preceded by Lua, as are the entries with indices 2,3,4,5,6,7,8,9. You can interrogate (i.e. read) the offset to get the status of the LED, but you cannot control it as the offset will be read-only, as you have not added any lua code to handle a write/update. Please do not attach images, especially of MobiFlight which I do not support. I will remove that.

No yet - I am rather busy in support issues at the moment, and my time is rather limited at the moment due to health issues. Don't worry, I haven't forgotten, and will hopefully find time to look into this next week.