John Dowson

Any errors setting client data calculator code are NOT due to the calculator code itself, it means that the calculator code could not be sent to the sim/WASM for some reason. Any errors in the calculator code itself will be logged in the FSUIPC_WASM.log file (or possibly the MSFS console) and not in the FSUIPC7.log file. Looking at your log file. the errors are reported as the WAPI hasn't yet connected to the FSUIC7 WASM module and so the calculator code could not be sent to the sim, i.e. they are logged before this message is logged" Basically you are trying to do things too early - just be more patient. Once you have loaded an aircraft and are ready-to-fly, wait for a short while before trying to do anything. Usually it is best to wait until the lvars have been loaded, i.e. when this is logged: The reception of lvars is also logged in the FSUIPC7 main window. And if using InputEvents, you need to wait until all these are loaded and initial values received, which in your log is here: i.e. approximately 2 minutes after FSUIPC7 is started. The number of Input Events is also logged in the FSUIPC7 main window. I will look into your other questions, as well as taking another look at the C510, at the weekend. I believe SU15 should be released tomorrow, and I will release FSUIPC 7.4.12 shortly afterwards, which has improved handling for Input Events - this may be useful for the C510 so please update once released. John Later: could you just give me a list of the buttons/switches that you are having issues with, and I will take a look at each and let you know how to assign to them in FSUIPC7. This will be quicker and easier for me than going through your files or lua code.

👍😎

First, run MSFS and FSUIPC7 and load the PMDG aircraft to the ready-to-fly state. Then, open the FSUIPC7 axis assignments panel and create your profile lets say you call the profile PMDG-737. You will be asked if you want to import your axes - agree to this. Then click Ok, and then exit FSUIPC7. Next, open your FSUIPC7 in an editor. Find the profile section and edit the aircraft name to use a substring, e.g. Next, rename all the following sections to make them profile specific: [JoystickCalibration] -> [JoystickCalibration.PMDG-737] [Buttons] -> [Buttons.PMDG-737] [Keys] -> [Keys.PMDG-737] and also the following, but only if using them: [Auto] -> [Auto.PMDG-737] [LvarOffsets] -> [LvarOffsets.PMDG-737] [InputEventOffsets] -> [InputEventOffsets.PMDG-737] Then re-start FSUIPC7 and you should be good-to-go. Cheers, John

The latter, i.e. you have created that and forgotten about it. FSUIPC does create a file called FSUIPC5.JoyNames.csv, but you do not need to copy that - it is created on-the-fly. John

Seems like you are using some different controllers now as well: 1. There is no longer a HOTAS Warthog Joystick, but a Right VPC Stick WarBRD 2. The rudder pedals have changed from Mad Catz Pro Flight Combat Rudder Pedals to Saitek Pro Flight Combat Rudder Pedals I have also switched the assignments for these, i.e. what was assigned to the HOTAS Warthog Joystick are now assigned to the Right VPC Stick WarBRD, and what was assigned to the Mad Catz Pro Flight Combat Rudder Pedals are now assigned to the Saitek Pro Flight Combat Rudder Pedals. The pedal assignments should be ok, but you should revise your assignments to the Right VPC Stick WarBRD. So, please try the attached ini file. Any issues, let me know and please re-attach your updated .log and .ini files. I have also update your profile aircraft names to use substrings. However, you seem to have two profiles for the 777 so I have left these: This is the same aircraft so you should use just one profile. I am not sure which one you want to use, but choose one profile, delete the other profile (all profile sections), and then set the aircraft name to be a useful substring, e.g. John FSUIPC5.ini

You can edit the MSFS.bat file to remove the display of if you like, but why not just not install the desktop icon installed by the FSUIPC installer. To do this, you need to select the auto-start via the EXE.xml method (and de-select the MSFS.bat method) during installation (if you want FSUIPC7 auto-started) and also uncheck the installation of the desktop icon on the last installer page. If you want to use the MSFS.bat but just not show the splash screen, change this line: start mshta "%splash%" to this ::start mshta "%splash%" i.e. comment it out John

You also need to copy across the FSUIPC5.key file or re-register, as well as any lua files (*.lua), macro files (*.mcro) and additional drivers (*.dll) that you are using, if any. Just copying across your ini file is also not enough, as the GUIDs of your devices will also have changed, and so some manual editing of the ini is needed. This is far easier if you are using the JoyLetters facility on your old PC, but please attach both your FSUIPC5.ini and FSUIPC5.lg files from your new PC and I will take a look. John

That seems to be the same as the documentatin link I always give when people ask about this: https://docs.flightsimulator.com/flighting/html/Additional_Information/Reverse_Polish_Notation.htm Looks like this has recently been updated - until recently this was very sparse and only gave the basics! Looks a lot better now... Not sure now - I usually only use the stacks/registers if the value is needed in multiple places... Looking at the calc code now, it doesn't look correct...it is not possible to set a B:var via calc code...that is why an lvar is introduced, to control the b:var via using that xml update.

After the latest AS update, the API documentation is now available in the AS documentation folder (Active_Sky_API.pdf) - could you take a look at this? I am not sure what information I should request. I would have thought to use the GetCurrentConditions call. However I am not sure how useful this is - it seems to return the first string only from the Conditions tab of the AS UI - i.e. the Metar data. This is what this returns when on the runway at LEVX (Vigo, Spain): @POS 201348Z 28012KT 250V320 9999 FEW019 SCT024 FEW028 16/10 Q1015 RMK ADVANCED INTERPOLATION For comparison, this is what the AS UI shows under the Conditions tab: The GetMetarInfoAt call using the ICAO LEVX gives the following string: LEVX 201400Z 28012KT 250V320 9999 FEW019 SCT024 FEW028TCU 16/10 Q1015 NOSIG I guess I could extract the wind direction/speed, temperature, etc from the Metar string.... Or would the basic weather data (WindDirection, WindSpeed, Temperature, Pressure) at the aircraft position, using the GetAtmoshere call, be sufficient?

That is why I needed to see the log file! I don't think you should change this even if possible - if it is running with elevated privileges then I', pretty sure its doing this for a reason... Sorry but if AS is being ran with elevated privileges and FSUIPC not, then I don't think it will be possible to have AS auto-started by FSUIPC7. I do have AS for MSFS so will take a look when I get time (after the SU15 release). You could maybe try adding an entry to the MSFS EXE.xml file instead to see if that can start AS.

Can you please show me/attach your FSUIPC7.log and FSUIPC7.ini files. John

Your ini file shows that you have assigned to the Lua control and not the LuaValue control: This is also confirmed by your log file, which shows the lua script continually being restarted (which is what using the Lua control will do): Not sure why as the image you attached shows LuaValue - can you please check again. Your assignment should look like this: It is only running as it is being started/re-started each time the axis valuer changes. As well as changing the assignment from using Lua to LuaValue, you also need to have the lua auto-started. To do this, you need to add an [Auto] section, i.e. John

So FSUIPC7 on the client PC cannot connect to MSFS? Did you configure your SimConnect.xml file correctly? Can you please attach your FSUIPC7.log and FSUIPC7.ini files as well as your SimConnect.xml file please and I will take a look. What log file? What cfg file?

Are you using MSFS2020 / FSUIPC7? If so, please use the specific sub-forum for FSUIPC7. I will move your post. I don't have the LVFR so cannot look into how the elevator trim works for this aircraft. You can try using FSUIPC's logging facilities to see what is being used - activate logging for Events and Input Events and open the logging console (Log -> Open Console), increment and decrement the elevator trim in the VC and see if anything is logged. If so, try using those evens (or input events). If nothing is logged, try listing the available lvars to see if any of those look applicable. As a final resort, you can inspect the model behavior of the VC trim controls using the development facilities provided by MSFS to see how they work, and then try and duplicate that (usually using calculator code via a preset) - see https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/ on how to do this. John

You are using a very old and unsupported version - please update to the latest and only supported version, 7.4.11. John

No, sorry. Probably a good thing to log though - I will look into this. For now, you will have to use the Windows Task manager which will tell you if a process is running with elevated privileges or not. Ok. Then if when running FSUIPC without elevated privileges your client does not connect, but running with elevated privileges it does, then the reason must be that FSUIPC is running with elevated privileges, no? I can think of no other reason for this behavior. John

What has changed? Has anything been updated? If this only affects vPilot, gave you asked on their support? You need to determine what has changed. Try logging to see what events/controls are being sent - use Event logging in FSUIPC and see what events are logged when you alter the com1/2 frequencies. Maybe also look into the PFC driver logging as well (see the PFC User guide for the driver you are using). John

This implies that FSUIPC7 is being ran with elevated privileges. All FSUIPC clients must be ran at the same privilege level as FSUIPC otherwise they will not connect.

Maybe I should look into seeing if it can handle support for me.....would save me a lot of time!

This is not actually correct anymore, but was correct on initial release, and should really have been 'when MSFS starts FSUIPC7 via the EXE.xml file'. However, now that the default auto-start has been switched from using the EXE.xml file to the MSFS.bat file, it should be: “Please note that this feature is only activated when using the auto-start facility, either via the MSFS' EXE.xml file or the FSUIPC' MSFS.bat file (via the Desktop icon)” This is all explained in the latest FSUIPC7 Advanced User guide (for 7.4.12) which I have attached below. If you remove the DetectToConnectDelayAuto ini parameter, auto-tuning will run automatically, no need to add the StartUpTuningActive ini parameter. Otherwise, you can leave the DetectToConnectDelayAuto ini parameter and add StartUpTuningActive=Yes to force auto-tuning. Only if it is needed. If you are using auto-start via the MSFS.bat file / FSUIPC 'MSFS' Desktop icon, then you must use this to start MSFS (and FSUIPC7) as this is where the auto-start component is. If you are using the EXE.xml auto-start method, then it doesn't matter how you start MSFS. Basically it is active if auto-started and not manually started via using the FSUIPC7.exe. Why don't you take a look at your log file as this will log auto-start activity. Looking at the log you attached, this shows that FSUIPC7 was auto-started and auto-tuning was active: Note your log file ends after 70.89 seconds and was attached while FSUIPC7 was still running. Auto-tuning terminates and updates your FSUIPC7.ini when MSFS gets to the main menu (and FSUIPC7 is connected at this stage). What is happening in your case is that you are getting to the main menu, selecting a flight and starting the flight before FSUIPC7 is connected. Therefore FSUIPC7 is not detecting MSFS in the main-menu state and so not updating the auto-start parameters. However, it WILL do this once you terminate your flight and go back to the main menu. If you exit before doing this, auto-start will just activate the next time that you run MSFS. If you want auto-start to do its job, you can always wait for a short while (until FSUIPC7 connects) when you get to the main menu to allow this state to be detected by FSUIPC7. 30-40 seconds should suffice. Anyway, I really wouldn't worry about this to much. Your system loads pretty fast, and the auto-tuning process will do its job and probably reduce the DetectToConnectDelayAuto parameter to either its minimum or until it detects an error, and then increases it again. Note that I will release 7.4.12 when SU15 is released. It is already available from the Announcements sub-forum if using the SU15 beta. John FSUIPC7 for Advanced Users.pdf

But you don't! As your log file that you attached states, you are running from C:\Users\dhsim\Desktop\MSFS\FSUIPC7\ as this is where the FSUIPC7.ini file is read from. I am taking this from the files you attached. This is why it is still loading the C510.ini as you are editing the wrong FSUIPC7.ini file. I'm sorry but this is all very confusing for me. As I suggested, please use File -> Open Installation folder which will tell you where FSUIPC7 is running from, and from where it is reading the options. ALWAYS show me files form that location (i.e. where it is actually running from, not where you think it is running from). You need to sort out your locations and provide me the correct files if you want support. You should only have one FSUIPC7 installation folder - remove all others. Please do not attach any more files or ask for support until you have done this as it is confusing and time-wasting doe both of us. Sorry, but I have no idea what this means. What is stacking, and what variables? If you are referring to why the UI is grayed-out when you have overloaded assignments (i.e. more than one assignment to a button or key) then this is just the way the UI was designed many years ago. It is just not possible to use the current UI to add overloaded/multiple assignments to a button or key, and you have to edit the ini to achieve this. Once this has been done, it is not possible to show this in the UI, hence it is grayed-out. This also applies when you add compound or offset conditions. Again, you cannot do this via the UI and hence you cannot edit such an assignment via the UI for such assignments and so they will also be shown as grayed-out. In a perfect world I would modernize and update the UI to allow such things to be achieved via the UI rather than having to edit the ini. But that would be several months development work, and I just do not have the time for this. It is what it is and has always been this way.

These are assignments for the End key to switch between cockpit and external: I have checked the insert key and it should work fine. To use this to switch between cockpit camera and drone camera, you can use the following: Try those and adjust as needed. Let me know if you have any issues. If you want to use other camera views or states, try logging those offsets I mentioned and see what values are used for the views you want to be able to switch between. See the offset status document for what the values held in those offsets mean. Also, maybe check-out these similar requests: John

I have checked this here now and it is working as expected. Did you solve your issue? I expect it is/was due to the lua script not running... John

There is currently no radar or associated functions provided by AS - basically there is no dll and so no dll functions to communicate with AS. This is currently being worked on by AS. I believe there is a HTTP interface but I cannot find any documentation on this. I have asked AS about this and will take a look and see what is available / possible once I see the documentation and will then get back to you.

Thats very strange, but interesting...I have no idea why that works...!