John Dowson

This is certainly not an issue with FSUIPC or the installer, and so there is nothing I can do. It is either something you are doing or system settings (permissions). You are not even running the FSUIPC7 installer! As I said before, make sure you unzip the downloaded file before running the installer, and I recommend just unzipping from your Downloads folder (not in your desktop). And check any anti-virus software which may be blocking or removing the installer. Have you actually checked it is there? Did you try what I suggested in my previous response? I am closing this thread now as thee i really nothing more I can say or do on this issue. Try google (as this is nothing to do with FSUIPC). John

It is for technical reasons in how the lvar names and values are passed from the WASM to FSUIPC (via the WAPI). I could increase this (would involve an update of the WASM and WAPI), and have already done this once (from 2044 to 3066) quite recently, in version 7.3.5 released 29th May. I may consider increasing the maximum limit again, but not at the moment. I don't want to be increasing this every 6 months if the number of available lvars keeps increasing like this. MSFS should only provide the lvars for the aircraft currently loaded - the rest are just noise. John

Extensive documentation for FSUIPC7 is installed in your Documents folder when you install FSUIPC7. Also available from the Documents section of this forum, although that will be slightly out-of-date. There is no such file. FSUIPC7 stores is user-settings in a file called FSUIPC7.ini, located in the FSUIPC7 installation folder. This file is created when you first run FSUIPC7, if not already present. John

Sorry for the delay - I will look into this further in the next few days... John

No problem - and me too!

Can you please turn off logging for both Lua Plugins and Log Lua Separately. If you want to show me a log file, I just want to see your FSUIPC7.log file, and also your FSUIPC7.ini file if you have issues. And, as I said, you should open the logging console (Log->Open Console) and monitor the output in real-time. I also suggest you re-read my previous posts to make sure that you have set everything up correctly. You are also using an extremely old and unsupported version of FSUIPC7 - 7.0.0-Beta from 19/8/2020. This is a very early version - please update to the latest (and ONLY supported) version which is 7.3.15. John

There are many posts from users saying the FSUIPC is causing MSFS to CTD (with different MSFS versions) and my answer is always the same. I am not going to repeat myself on this topic again - please search for the similar posts where I have replied to this accusation at length. I will also create a FAQ entry on this issue in the next few days and will post a link in this topic when done. No. FSUIPC7 is a separate application and in no way should cause MSFS to CTD. If MSFS CTDs, it is a problem for Asobo, even if this only occurs with FSUIPC, as it will be a SimConnect issue on the server side if MSFS is crashing. However, I doubt very much if this is the issue. Many many users are using FSUIPC7 with SU11 without suffering CTDs. I suggest you check the Asobo forums and report to Asobo if MSFS is crashing. Check your windows event log and submit the crash report to Asobo. The only possible way that FSUIPC7 could cause MSFS to CTD was if this was caused by the FSUIPC WASM module. If this did cause such issues, it would certainly have been reported by many other users, so I really don't think this is the cause - but you can always test with the WASM removed from your Community folder. John

👍

Don't do this! Just let the luas be logged to the standard log file (FSUIPC7.log) - you can then see the messages in real-time if you open the console window. Yes, of course you do, as I previously said: Please see the section Automatic running of Macros and Lua plugins on page 39 of the Advanced User guide for further details. John

Why are you installing the WASM manually? Are you a developer? The WASM module for users is included in the FSUIPC7 installer, you only need to download/use the WASM/WAPI package if you are not using FSUIPC7, or if you are a developer and want to use the WAPI (the WASM Application Programming Interface). Please attach your full InstallFSUIPC7.log file, not paste extracts. The folder $LOCALAPPDATA\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache is the first one checked for the UserCfg.opt file for an MS Store installation. If the installer could not fund that file, then either your LOCALAPPDATA environment variable is not set correctly, or you have permissions issues somewhere that are preventing the installer from seeing this file. Please check that environment variable first. Anyway, there is no problem manually installing the WASM into your Community folder. You may also have issues with auto-start installation if your MSFS EXE.xml file cannot be found, but you can also set this up manually (see the FAQ entry on auto-start for details). I will correct the spelling mistake, thanks. None of this is of any importance. The WAPI is NOT installed by the installer - as I said, you only need this for developing WASM clients. The WASM is also not installed by the installer, but you do not need this either - everything that that provides is also provided by FSUIPC. The WASMClient is provided as an example client using the WAPI, and standard FSUIPC users don't need this, or need to know anything about this really... Yes it is correct. It is for developers. The WASM is installed by the FSUIPC7 installer (which I know you are having issues with - we can sort that out). Please see the provided document Installing and Registering FSUIPC7. That should tell you all you need to know about installation. It doesn't seem to matter what documentation I provide, as many users don't seem to use or refer to it anyway.... You should read the Installing and Registering FSUIPC7 document, as well as the User Guide. You should take a look at the Advanced User guide to be familiar with what's available, and read the WASM section there. The FAQ questions are available here. and this forum is the knowledge base. Please use it to search for any issues BEFORE posting (and after having checked the provided documentation). John

Sure, no problem, Once you have tested this, and maybe tuned the script, I can also create a post un the User Contributions sub-forum and make the script available there. Cheers, John

Auto-start is working fine here (Steam install)- always has. I don't know why so many people are having issues with this, but id you have checked everything mentioned in the FAQ entry on this topic and it still doesn't work, you should raise a bug report with Asobo, as it is MSFS that should do the auto-start via the EXE.xml. If that file is correctly formatted, and all your permissions and privileges are correct, then it is an MSFS issue.

Ok, thanks for the update. John

That is probably because you asked about an FSUIPC offset - you should just ask about the SDK variable. As I said, FSUIPC just populates the offset with the value received. That is also an option! Cheers, John

The PMDG offsets are just populated directly from the data received from the PMDG SDK. If there are any questions or issues with this data, you need to ask about this (i.e. SDK variable AIR_CabinVSNeedle) on the PMDG support forums. Sorry I can't be of more help, John

But even with that the formulae still don't make sense - if rudder < 50 then: Left Brake Control = 2*((100-Rudder)-50)*(Rudder<50)*Brake/100 === 2*((100-Rudder)-50)*1*Brake/100 Right Brake Control = (2*(Rudder-50)*(Rudder>50))*Brake/100 === (2*(Rudder-50)*0)*Brake/100 === 0 and if rudder > 50: Left Brake Control = 2*((100-Rudder)-50)*(Rudder<50)*Brake/100 === 2*((100-Rudder)-50)*0*Brake/100 === 0 Right Brake Control = (2*(Rudder-50)*(Rudder>50))*Brake/100 === (2*(Rudder-50)*1)*Brake/100 i.e. one of the brakes is always zero! Anyway, you can try different formulae by adjusting the calculations in the script (should be straightforward)- I would be interested to know what you finally use. Note also a slight correction to the script - the lastBrakeValue should be initialised to off, i.e. change line 8 to local lastBrakeValue = -16383 -- initial value, no brakes Regards, John

Those formulas don't make sense - how can you multiply by (Rudder<50) or (Rudder>50) - they are conditional tests... But I understand toughly what you are trying to achieve - alter the %ages sent to the toe brakes depending on the rudder position.... I have attached a script that you can use as a starting point to tune. To use this, you need to first copy the lua file to your FSUIPC7 installation folder and then have it auto-started by adding it either to your [Auto] section or your profile-specific [Auto.xxx] section (where xxx is the name of the spitfire profile). You then need to assign both your rudder and brake lever axis in FSUIPC7 using Send to FSUIPC Offset with Offset Dword Set. The script uses offset 0xA000 for the rudder axis and 0xA004 for the brake lever axis - use these or update the script to the ones that you use. I suggest that you try this with the console window open so that you can see what is happening and tune the formulae for your needs. Some notes: - once you are happy with the script, you can turn off the logging by setting enableLog to false - the brake axes used (AXIS_LEFT_BRAKE_SET and AXIS_RIGHT_BRAKE_SET) are not actually linear: from the documentation: There are linear axis controls (AXIS_LEFT/RIGHT_BRAKE_LINEAR_SET) but these have not yet been exposed to the SDK (I have raised this with Asobo). - the script assumes both the axis value ranges are from -16383 to +16383 - if your axes are not in this range, including reversing, then you will need to calibrate to this range in the script - I have commented where you need to do this - the brake lever is used just for the maximum brake value - it is not 100% clear to me how the actual brake axis values should be calibrated...the script is always using the full brake lever axis value for one of the axis, and then decreasing the other axis based upon the value of the rudder axis. I implemented this way as you have 100% of both axis values when rudder is at 50%, so I didn't want to decrease this maximum value when using differential braking. - I am not sure if this will actually work (or make much of a difference)in the Flying Iron Spitfire due to the MSFS SDK and this note in the documentation: Anyway, this should at least give you a starting point. Let me know how it goes or if you have any questions. Please also return the script if you update/change this (so others can use). John spitfireBrake.lua

No. Are you tunning SIOC with admin privileges? If so, you must also run FSUIPC7 with admin privileges (as well as MSFS). FSUIPC7 and all clients must be ran at the same privilege level. Also check that you have not installed FSUIPC7 under a windows protected folder, such as under Documents or Program Files - if so, try re-installing in a non-windows protected folder. If neither of those solve your issue, you should ask about this on opencockpits.com. John

Thanks @ark1320

Ok - maybe you or @ark1320could share the script (either here or in User Contributions), or post a link to where available. Maybe useful for others who come across this. Thanks, John

Ok, I understand what you are trying to achieve a lot better now. Maybe if you could expand on this, and how you expect to achieve this either with two axis (handbrake axis and rudder axis) or an axis (rudder) and a button/switch/trigger (handbrake), then I could provide you with a basic lua script to emulate this behavior which you could then tune. Maybe some simple use-cases would be helpful: e,g, to turn left I would move...and then/also push, , to turn right I would..., etc

BTW, I just noticed this in the MSFS SDK documentation: You can still interpret the data as an 8-byte string in FSUIPC (as I showed). John

Did you get anywhere with this? By 'single brake lever', do you mean the parking brake? There is no other lever I can see on the control column... According to the spitfire documentation, the aircraft already has differential braking via the toe brakes, although it also says that currently only rudder-linked steering is implemented due to SDK limitations: With this limitation (i.e. steering only via rudder), I don't think it will be possible to achieve proper differential braking... John

Yes, this is correct - the title is ignored in P3D (as the manual states, although it references P3Dv4 when it should just reference P3D - I will update). The same simconnect connection is used by FSUIPC for all operations (apart for monitoring of AI traffic where a separate connection is usually used) and FSUIPC knows nothing about your displays - that is all controlled by the FS. I am not sure why you see this flickering - is it the same regardless of the monitor where you position the window? If you post/attach your lua script here, I can try it and see if I see the same begavior. No problem. Maybe consider creating a post in the User Contributions sub-forum and attach your script there, with an appropriate description, for others to use. John

No, this will not work as defined here in P3D - there is no such thing as a preset or a way to execute calculator code in P3D. However, if the same (or similar) lvars exist when using GSX in P3D, you could write a lua script to set the lvars (including a short delay) instead of using a preset/calculator code. First, try listing the lvars to see if the following are available: L:FSDT_GSX_PILOTS_NOT_DEBOARDING, L:FSDT_GSX_CREW_NOT_DEBOARDING, L:FSDT_GSX_PILOTS_NOT_BOARDING & L:FSDT_GSX_CREW_NOT_BOARDING If they exist, you can write a short lua script that performs the same actions as the calculator code (i.e. set the value of each of those lvars to 1, with a 100ms delay in between each call) and assign to that. John