John Dowson

WideServer.log? No screenshots earlier that i can see, but not needed anyway. John

Files? However, I won't get a chance to look at this in detail for at least a few days (too many problems with the latest MSFS release...), but if you can attach all your files (i.e. all logs and inis) then I will take a look when time permits, to see if I can determine what is causing this issue - although it may have resolved itself again by then...! John

The Axis Left/Right Brake set controls are no longer working in SU10, and as that is what the offsets use, that will be the issue. There is nothing I can do about this at the moment ecept report to Asobo/MSFS. Sorry about that. John

The ipc function is working correctly - as I said, try listing the lvars to see if those are available: S_OH_EXT_LT_LANDING_L and S_OH_EXT_LT_LANDING_R Reading lvars should have been ok with SU10, it was the writing/updating that was broken - and fixed in the latest beta 7.3.9f. That offset still uses the lvars read from the WASM, so I can't see how switching to using the offset would make a difference... the lvar has to be available to FSUIPC via the WASM however it is read. Ok, thanks. I don't have the Fenix, so cannot check the available lvars here. Thanks @Fragtality

@Agniparvata Do you have ini parameter AxisCalibration set to Yes, or DirectAxesCalibs set to Yes or All? Those offset use the Axis Left/Right Brake Set controls, so I will check them here (both with and without calibration, and via the offsets). However, please note that those controls (and therefore offsets) no longer provide a linear brake axis (if it was working!). From the documentation: There are new linear brake axis control, but unfortunately these are not currently accessible/useable via 3rd party apps (SimConnect). I will raise a bug report for this, and once added I will switch to using these linear controls, or maybe add a new ini option so the user can decide which should be used (via the offsets). John

This folder is created by P3D and is the location of the add-on.xml file. It should be used for that only, and you should not install the application into this folder. Its ok to leave it there if its working ok.... Cheers, John

This is a known issue since the SU10 update that I am looking into. For now, you should only calibrate if assigned with 'Direct to FSUIPC calibration'. If assigned as 'Send to FS as normal axis', you need to delete the calibration for the axis. See the following thread for further details and where I will post any updates / new information on this issue: John

There was a known issue swapping COM2 and NAV1 and NAV2 frequencies in that version. Can you please update to the latest beta (7.3.9f) and try again - if you still have issues I will need to see your FSUIPC7.ini and FSUIPC7.log files. See John

That is strange...there is a FAQ entry on MSFS auto-start issues, but if this is an occasional issue I don't think it will help... That is even stranger...do you get any errors, or anything in the event log when this happens?

For many tears the Modules folder was the default (and only) installation location. This was a hangover from the FSX days / FSUIPC4, which still uses that folder. No - I recommend that you don't install under the FS/P3D folder any more. This can also cause issues, depending on where the FS is installed. These days, it is better to have all your add-ons installed in a separate non-windows protected folder , such as C:\FSUIPC6 or C:\P3Dv5 Add-ons\FSUIPC6. The former is actually now the default installation location, but initially it defaulted to the location of the add-on.xml file, under your Documents folder, and when you re-install it always defaults to the existing installation location. John

Ok - I will take a look at those... Ok, thanks for the update. Thanks.

Can you set axes logging, open the console window, turn the elevator trim and tell me whet controls/events you see? Also check the elevator trim calibration, but I can't think how that could do this.... And maybe double check your assignments (or show me your FSUIPC7.in) to make sure its not assigned to both axes... John

For this issue, can you also check and remove any calibration (that may still apply if using scripts), as well as using the latest beta. If its still an issue, I will need to see a log and the script you are using.

I've tested in the Asobo A320 and get similar errors if I assign using 'Send to FS as normal axis' and then calibrate. If I assign and don't calibrate, the axis work fine (just tried throttle at the moment, will check others tomorrow). If you remove the calibration, it still doesn't work until you restart FSUIPC7, which is also very strange. Assigning 'Direct to FSUIPC calibration' and calibrating also seems to work. So can those who have assigned an axis to 'Send to FS as normal axis' check the calibration tabs for those axes and remove any if set. If using profiles, check the profile specific checkbox first (if not already checked and inactive). Then exit FSUIPC7 and restart to see if that helps. I will continue looking into this (and the other strange issues mentioned) tomorrow.

Good to here its working for someone....! John

I am working on the issue. This is a problem that many people are having - I do not have the time to respond to everyone on an individual topic - I would have no time for anything else! Your/this issue isn't closed, it is just that this is the thread where I will be communicating on this issue. Only that it was working in SU9, and not in SU10. As I said, I am working on it.... No its not - it is just here, not in the post that you raised, as that is already covered by this topic/post. You are obviously a new forum user. Please look for other posts the same or very similar to your issue (hence use an appropriate title when creating) and contribute to that rather than starting a new post. and I am still working (past midnight here) to try and fix this issue - although spending most of my time responding to posts at the moment....

Oh - an please at least provide a title more relevant to your specific issue - using the forum name is pointless as it is so general and could apply to every post in this forum!

This is a known issue that has been reported several times. Please check/search the forum for similar issues before creating a new topic. I am looking into this issue. Please see the following thread for updates: John

There is another thread for this issue - please switch to this thread for future updates on this: John

Ok - this error was also reported when using 7.3.8 with SU10, so it certainly something that has changed in MSFS or the SDK. Strange I haven't seen it here yet, and I have tried several aircraft both sending to FS and direct to calibration. I will test further - and check I have packaged and uploaded the correct version... But this will be tomorrow now... John

I'll check in the A320 tomorrow (and please use that for any future logs ). The log file is strange though as there should be no events sent until everything has been started...

Well, there is no point me looking if there is no longer an issue....! From the first error, sounds like a file somewhere was left hanging around (probably a system file for the socket) that prevented the connection, that was eventually cleaned-up. Cheers, John

There is a beta release available here:

The log shows a couple of issues: That should be self explanatory - take a look at line 1 of that lua. That one is probably due to an lvar not being available, but look at line 24 and that should tell you. Writing to an lvar is working ok here, but it won't work if the lvar has not been loaded, which is what I suspect is your issue. Reloading should work now (was broken before) - do you see the lvar count increase when you reload? Did you adjust the LvarScanDelay WASM ini parameter, and if so to what value? You can try listing the lvars - do you see the ones you use? Then reload & list, and see if you see it then, and repeat until no further ones are found. Note that if the lvar is not available when the lua starts, it may not function correctly if later found on a rescan - that would depend in how the lua is written. That is why it is a good idea to set the LvarScanDelay to a reasonable level for the aircraft that you are using. I have plans to implement a feature to provide all lvars as available/created by implementing an auto-scan (for new lvars) functionality in the WASM, but that will be after the next release for SU10 compatibility. Try the above, and if you still have issues, please activate Debug level logging in the WASM/WAPI by adding the following to the [WAPI] section of your FSUIPC7.ini file and to the [General] section of your FSUIPC_WASM.ini file: LogLevel=Debug and then generate another FSUIPC7.log file and show me that, together with your FSUIPC_WASM.log file. You can also attach the luas if you want me to take a look at them.

But what behavior are you referring to? Why are you not showing me the information I need - your FSUIPC7.ini and FSUIPC7.log files? Have you updated to the latest beta (including the WASM update), 7.3.9f?