John Dowson

Sure - license sent. John

License sent. John

I tried using a pre-compiled lua and get the following error: *** LUA Error: D:\FSUIPC7\Lua\soundTest2.lua: bad header in precompiled chunk This error is normally due to mismatched compiler versions, but I compiled with 5.1.4 and this is also the version that is built-in to FSUIPC7, so I am not sure what the issue is here. I will update the documentation (for the next release) to state that this is no longer possible. Regards, John

That was pitch-down - I went to the extremes to test! The maximum pitch-up I tested was around 50 degrees: Hmm, strange - I am not sure why, but the code I showed you should always restrict this to 1dp. John

I do not understand the following: 1. why do you have FLAPS_DET, FLAPS_DETENT_SET and FLAPS_UP assigned to ranges on your flaps axis? I would have though just assigning your your flaps axis to FLAPS_SET would be sufficient. 2. why are you also assigning to FLAPS_SET & FLAPS_UP in your wing sweep axis? I thought the wing sweep would be independent of the flaps 3. the ranges on your sweep controls look very strange, as well as the entering/leaving assignments, especially this one on the minimum axis value: 5=2S,B,-16384,-16384,65595,0,M3:1,0 -{ Entering=FLAPS_UP, Leaving=Macro F3_Sweep_Decr: F3_Wing_Decr }- Ok, that's interesting - could I see this explanation please? What type of variables? Can you not use these variables rather than mouse macros? Could you possibly attach a screenshot of the wing sweep and flap controls so I can see how these operate? Thanks, John

Hi Ray, I just tested this with a simple lua: function PitchDisplay(offset, pit) -- Ray's code local mypit = pit*360/(65536*65536) if mypit <= 20 then --descending mypit = math.floor(-mypit *10) / 10 else --ascending mypit = pit*360/(65536*65536) mypit = 360 - math.floor(mypit *10) / 10 end local mypit1 = tonumber(string.format("%.1f", mypit)) -- My Code local jdPit = -pit*360/(65536*65536) -- convert to degrees, also reverse sign so -ve descending/pitch down, +ve ascending/pitch up if jdPit < -180 then jdPit = 360 + jdPit end jdPit = tonumber(string.format("%.1f", math.floor(jdPit *10) / 10)) -- ensure value is to 1 decimal place displayString = "Ray's original pitch =" .. mypit .. ", Ray's 1dp pitch = " .. mypit1 .. ", my Pitch = " .. jdPit ipc.log(displayString) ipc.display(displayString) end event.offset(0x0578, "SD", "PitchDisplay") When running this I got mostly the same number printed each time, the only difference being when the pitch falls below -20: So it seems your original code displays to 1dp anyway! Cheers, John

Great - thanks for the update. John

Yes - I removed the 7.4.13 beta version when I released it officially, so now downloadable from the usual places. There seemed to be 2 issues with the 7.4.12 version: - WASM crashing after long flight. Not 100% sure on this but it seems that some add-ons are continually creating lvars which, due to the way lvars are pushed out from the FSUIPC WASM to its clients (including FSUIPC) caused some resource issue and the WASM to crash. - start-up and connection issues due to a combination of switching the auto-start method to using the MSFS.bat file and the auto-tuning functionality running when MSFS is updating, causing long start-up times and too many re-connection attempts/. Both issues have been addressed in the new version. You don't have to add that to the ini for the time being, but if you get any connection/start-up issues, then please add this TestOptions to your ini. That option provides extra logging as to why things are started or not during initial connection to MSFS. John

Ah, looks like your lua add-on is using the HotKey offsets starting at 0x3210. So your issue may be that keys are not being received from MSFS, which a few people have reported with version 7.4.12. Update to 7.4.13 and try with that version. If you still get an issue, it is most probably due to start-up issues. Please activate logging for Buttons & Keys, and show me your FSUIPC7.log and FSUIPC7.ini files from a session when you got the issue. John

Why are you posting those files? I am not going to look at them. If you want them debugged, contact the provider. I will only check if FSUIPC7 is working correctly, if you provide the files I need.

Ok, good. And sorry - I had done most of the work for you but looks like I forgot to attach your FSUIPC7.ini in my last post. Sorry about that. There are other profile sections that need cleaning. I have also just released 7.4.13, so please download and use this. Correct the remaining profile sections to use substrings, then add the following parameters in the [General] section to force an auto-tune: StartUpTuningActive=Yes John

I never said that this would fix your issue - you just need to be on the latest version for me to investigate. And, as I said, I need to see your logs if you want me to look into this. And I have just released 7.4.13 - please update to this version, the only supported version., and try again. If it doesn't work. show me your FSUIPC7.log file. The log file will be in your FSUIPC7 installation folder. If you do not know where that is, use the FSUIPC7 File -> Open Installation Folder option. If you still cannot see the file, you will have the Windows Explorer options set to Hide extensions of known file types. Remove that option.

I have just released 7.4.13 - can you please install this version and see if that solves your issue. If not, I need to see your files: FSUIPC7.log, FSUIPC7.ini, FSUIPC_WASM.log. Please exit FSUIPC7 before attaching the FSUIPC7 logs, and only attach the FSUIPC_WASM.log after exiting MSFS. John

Sure, I will PM you one. Sorry, but I will not send you one as it looks like you have been using the trial license since November 1st 2022: If you want to continue using FSUIPC7's licensed functionality. please purchase a license. John

I have also just released 7.4.13 - please update before requesting any more support.

If you just remove that, it will brake. You have to correct it. But, you say this is working. If your original code WAS working (which I doubt), then just converting mypit to have 1 decimal place should not change anything, except to display the value with 1 d.p. But you saiy this didn't work. Ok.

No. LINDA is no longer supported by the developer. I have never used LINDA and just haven't got the time to look into it and support it, sorry. Especially for VRI devices, which I also know very little about. How do you know when it controls COM and when it controls NAV? If you want a button/switch (including rotary buttons) to send different controls, then you need something else that this depends on, e.g. another button or maybe an offset. Lets assume you are using another button or switch, so when this switch is down/off, the rotary controls NAV, and when up/on, it controls COM. So, on the rotary, you would assign the left/righ buttons to decr/incr both NAV and COM. Then you would add a compound button condition to those assignments, so that the assignment triggered would depend on the state of your other button/switch. See the section on Compound Button Conditions in the Advanced User guide, page 22.

I have replied there and locked that post. Read my reply there, correct those issues, and tell me what your problem is here...DO NOT START YET ANOTHER THREAD ON THIS SAME ISSUE.

That is strange...maybe I should have checked this in P3d (I checked in MSFS as that is what I had running). I can't see how your code can work because of this: if mypit <= 20 then --descending Why is 19 descending, -19 descending, but 21 ascending? Maybe try something like this: -Display Pitch Angle... pit=ipc.readUD(0x0578) -- 0=level, –ve=pitchup, +ve=pitch down mypit = -pit*360/(65536*65536) -- convert to degrees, also reverse sign so -ve descending/pitch down, +ve ascending/pitch up if mypit < -180 then mypit = 360 + mypit end mypit = tonumber(string.format("%.1f", math.floor(mypit *10) / 10)) -- ensure value is to 1 decimal place I can fire-up P3D to check there but not today... John

@DaveSCUSA Please explain what issues you are having with assignments to this aircraft here, but at least please try what I have already advised you to use, i.e. input events. And as I have said, the last time I looked at this aircraft I could not find anything to control the fuel cut-off triggers (bottom of throttle). I can take another look, when time permits, but I doubt I will find anything unless there has been an aircraft update. Apart from these, which you have to trigger manually in the VC, there should not be an issue starting this aircraft. John

Just checked these and the Pan controls still don't work from an external app. Either assign directly in MSFS, or assign in FSUIPC to the default key controls for the camera/view in MSFS, e.g. lctl+Left, lctl+Right, lctl+Down, lctl+Up for quick look lshift+Right, lshift+Left, lshift+Down, lshift+Up to move camera, Right, Left, Down, Up for eyepoint movement, etc. Check the default key assignments in MSFS to control the camera, try them out and then assign the ones you want to use to your hat switches. John

Your FSUIPC7.ini file you attached has no profile information at all and no assignments. Your log showed a profile being loaded, so this CANNOT be the FSUIPC7.ini file that was used. I cannot help if you are not showing me the correct files. Your log also shows errors which you should correct: Not sure why you are even trying to add these - FUEL TANK SELECTOR:1 is already available in offset 0x0AF8, and FUEL TANK SELECTOR:2 in offset 0c0B22. You also have issues with assignments to missing devices that you should correct: You will have assignments to devices F and N in one or more of your profile files. You will need to update these to the correct letter for the device or remove them. Then delete those two missing joystick entries. Your Joystick Buttons FSUIPC7.log file also shows that it was attached while FSUIPC7 was still running. Please ALWAYS exit FSUIPC7 before attaching log files. Your C510 ini also shows that you are assigning to the standard FS events/controls: As I told you two months ago, for the C510 the battery, avionics and starter all work easily via Input Events - why do you not use these? See I don't understand why you are having so many difficulties, and why you are creating so many different posts for the same issue.... Can you PLEASE just use ONE topic for your C510 issues, and not keep creating new topics. I am closing/locking this one now. Please use the other topic (Cockspur C510 assignments too complicated) for all your issues with this aircraft going forward. And please re-read that post again... John

I have not looked at the PAN controls for a long time, as these were never working correctly in MSFS (especially Pan View). As it says in the README.txt: I will look again at the Pan controls when time permits. I am rather busy at the moment with various issues raised since the SU15 release, so it may take a while before I get time to look into this (probably next week). John

I showed you how to restrict to 1 decimal place. Thats all the code I showed you does - it does not change the values. So, if the values are wrong, they have always been this way. What pitch value? The value in offset 0x0578 will be positive on pitch down, With your code, it will depend on the pitch angle, as you have a conditional on the is being less than 20 for some reason, as I said... ? When you take-off (pitch-up) so you expect to see a positive or negative pitch? Offset 0x0578 will show negative. When landing (pitch-down), do you expect to see a positive or negative pitch? Offset 0x0578 will show positive. Why don't you just try this: --Display Pitch Angle... pit=ipc.readUD(0x0578) -- 0=level, –ve=pitchup, +ve=pitch down mypit = -pit*360/(65536*65536) -- convert to degrees, also reverse sign so -ve descending/pitch down, +ve ascending/pitch up mypit = tonumber(string.format("%.1f", math.floor(mypit *10) / 10))) -- ensure value is to 1 decimal place if mypit < 0 then --descending cond="c1" else --ascending cond="c2" end I have just adjusted as per the comments I have previously made... Try adjusting yourself if that is not what you want... John

Your issue is not he same as the topic you posted in - I have moved your posts to a new topic. Your ini file is in a bit of a mess with its profiles, so lets sort that out first. You should try to understand how FSUIPC matches the aircraft name to profiles, and ALWAYS look at your aircraft name when you add it to a profile (in the ini file under the [Prodfile.xxx] section, and edit the name to use a substring to match all variants. So, for exa,ple, you can replace this: with this: I have changed one I can for you in the attached in (please use this going forward), but there are some conflicts that you need to resolve. First, your 787 profiles, for which you have 2 One problem here is the boing entry in bold. If you load, say, the 'Boeing 787-8 British Airways' then entry 2 in your KURO 787-8 profile will match, as well as entry 1 in your 787 profile. Which profile do you want to use with this aircraft? Also, entry 3 in your KURO 787-8 profile and entry 6 in your 787 profile look suspicious, as these are the same aircraft, different livery, and so really should be using the same profile. Should this be: ? You have a similar issue with two A310 profiles: If you load the 'Airbus A310-300', then this will match the entry for the A310 profile (A310) and so either profile may be used (i.e. it is not possible to determine which one will be used). Can you please clean-up these issues, as I cannot look into your issue until I know which profile is being used. The log file you attached is also pretty useless, and has far too much logging activated. Can you download and use the attached FSUIPC7.ini file please. Then correct your profile issues, as explained above. Once that is done, please generate a log file showing your issue, and attach your updated FSUIPC7.log and FSUIPC7.ini files and explain what you did and what the issue was. Don't do this - re-installing achieves nothing, and should only be done to update to a new version, changed installed components (i.e. to switch auto-start methods), or to change the installation folder. This should only happen with XInput devices, such as the XBox One controller. This has always been an issue with FSUIPC7 - see the readme.txt where there is a solution to this. Key presses should be recognised when MSFS has the focus. This sounds very strange... Anyway, please use the attached ini, correct thos profiles I mentione. Then run MSFS and FSUIPC7, load an aircraft (which has a profile), test a button assignment and a key assignment (when MSFS has the focus), and if not working, exit FSUIPC7 and show me the FSUIPC7.log file together with your FSUIPC7.ini file. Then restart FSUIPC7 and test again. Do you still get the same issue? If so, exit FSUIPC7 and show me the new FSUIPC7.log file (or, if you do both tests, attach the FSUIPC7_prev.log and also the FSUIPC7.log, as well as the FSUIPC7.ini file). John P.S. You also have some assignment errors in your A300 keys section - either correct or remove these: