John Dowson

I have just re-read this thread and it seems the issue has changed since the initial report. Can you confirm that the issue now is that FSUIPC7 seems to hang, and that there is no response from the UI? If you kill and restart, does it then work? Do you only get this issue when GSX is running? How frequent is this issue, both when GSX running and when not? Do you see any events (warning or error) related to this issue in the windows event viewer? I am going to run some extended tests in the debugger to see if I can catch anything with this... John

Well, that last log has thrown a spanner in the works... What was the issue - did FSUIPC hang? Could you access the UI? In all your previous logs, the last line logged has always been: However, this time this is the last line logged, out of the blue: And I can't see how that can be logged with no other log message indicating why it was closed.... This is all very strange and I am at a loss as to what could cause this.... It would be useful if I could see a SimConnect log file. Could you configure to generate one - see Also please switch back to WAPI Trace level logging, and show me the files again, including the simconnec.log (it will be quite large and will need zipping/compressing, and still may be too large to attach....). I have also noticed an issue in the WASM from your WASM log. However, this does not cause any actual problems, but I will correct this in the next release. John

The MF HubHop website is very useful resource - it contains the calculator code/presets found by the community and is very useful for a repository of calculator code for various aircraft. You should certainly use this for calc. code examples. The MF discord server (MSFS2020 channel) is also the place to ask questions on calc code syntax and how to determine the calc code to be used for specific functions. Calc code is pretty new to me as well, and I am by no means an expert in this area. I help out if I can, and if I can't I will try and point you in the right direction. I am extremely busy at the moment and don't have time to look into such things (that are really out-of-scope of the support I provide for FSUIPC) in detail.

It isn't - this is the support forum for FSUIPC7.

This doesn't make any sense - uninstalling from windows app management will call the same uninstaller anyway, so it is exactly the same as running the uninstaller manually. And you should not uninstall if/when re-installing anyway - the installer will detect if currently installed and run the uninstaller anyway, And all of this has nothing to do with your original problem, which I guess was because you didn't register your license, hence the need to re-run the installer. John

?

Can you show me a log when you get a hang using the following version, where more logging has been added: FSUIPC7.exe Just use WAPI Debug level logging, not Trace. I will consider adding the extra option to run programs, but I do not know when I will have time to look into this - it will go in the backlog/to-investigate list. John

Can you please ALWAYS attach your FSUIPC6.log and FSUIPC6.ini files - there is no point in reporting issues with assignments if you do not provide these files, and every time please as they are changed/updated each time you run FSUIPC. You also have controllers active in P3D. If assigning in FSUIPC, it is better to disable controllers in P3D. As a minimum, you need to check that any axis assigned in FSUIPC is NOT assigned in P3D. And be aware that P3D can sometimes automatically re-assign an axis if controllers are not disabled. You have no assignments to your throttle in FSUIPC, so this MUST be assigned elsewhere, probably in P3D You say you have been flying a long time and this is a new issue. What has changed? Why do you only have two axis (aileron and elevator) assigned in FSUIPC? Are the rest assigned in P3D? If so, why are you even using FSUIPC - if everything else is assigned in P3D, why not just assign the aileron and elevator there, as you do not seem to be using anything else in FSUIPC? I suggest you try assigning in FSUIPC with controllers disabled in P3D. For PMDG aircraft, you should not calibrate if the axis is assigned in P3D or elsewhere, and should only be calibrated if assigned in FSUIPC with 'Direct to FSUIPC Calibration'. Sometimes even this can give issues, and if so you should assign using 'send to FS as normal axis; and not calibrate.

Haven't you already asked this question? The only way to send an event with more than one parameter is via calculator code. As to the exact RPN format if the calculator code for such an update, I am not sure. Check the Asobo documentation or ask on the Asobo forums. Does that work? If not. try: ipc.execCalcCode(“4 (>K:3:ELECTRICAL_BUS_TO_BUS_CONNECTION_TOGGLE)”) Maybe also check out some of the MF presets that are already using this - just search for ELECTRICAL_BUS_TO_BUS_CONNECTION_TOGGLE at https://hubhop.mobiflight.com/presets/

Ok, I will look into this next week...I will provide you another exe with additional logging to try and track this down,.,, John

If you get this issue again. post again, and try and catch it with appropriate logging... If there is no problem, why add another option? Everything is already very complicated as FSYUPC can be started in carious sim states, I would rather not add additional functionality for no perceived benefit... And this functionality has been around for many years and this hasn't been requested before, so I doubt it is that useful... Would this be to delay the starting further (until simconnect is ready)? If so, why not just add a delay?

From the Advanced User guide: You said: So READY obviously wasn't working as it should, and is why it has been corrected. If you want the programs to be started earlier, remove the READY. No - remove the READY, you don't seem to want to use this, so just remove it. John

Yes - the READY parameter wasn't working correctly, and this has been corrected in the latest beta. It does list the other changes in the beta release note: If you want it to start earlier, remove the READY. The beta version you are using (7.3.26e) has some issues - please update to the latest beta, 7.3.26g, and test with that. John

Are you using Project Magenta? These offsets are in the reserved area for PM. A cannot help with this, sorry. This offset is in an area free for general use. It is therefore not controlled directly by FSUIPC, and myst be written/read by some other tools you are using. As these offsets are controlled by other software, I cannot really help you any further with this. Try PM support. You should also mention that you are using PM in your description and in the title, as that may then attract other PM users whi may be able to help. I have no knowledge or experience with PM (and very little with FSX!), so am unable to help any further with this, sorry. John

Ok. Looking at the script you posted (always better to attach than paste!), why are you doing this: ? You should use the event.timer function.. Using that, you shouldn't need to sleep, but if you do want to add a random delay, use ipc.sleep and not os.execute.

First, using a prop. aircraft, you should use offsets 0x3B70 and 0x3AB0, as the comments in the FSUIPC offset document states: Those offsets are two-byte ints - I am not sure if they are signed or not (i.e. can they be negative?). If signed, you would use the function ipc.writeSW(offset, value), and if unsigned, you would use ipc.writeUW(offset, value). I suspect they are signed, so try that first. Note that a value of 16384 - 860 C, so you would need to scale your values of -9 to + 9 to the range temperatures that you want (e.g. -16384 to + 16384). If using offsets 0x3B70 and 0x3AB0, these hold 64bit/8-byte floating point numbers, so you would use ipc.writeDBL(offset, value). These offsets are in degrees Rankine, so you should also convert your -9 to +9 value to the variation range toy want to see in these units. John

That log file was attached when FSUIPC7 was running and ends after 31 seconds. Always exit FSUIPC7 before attaching log or ini files. It does however show that all your controllers are recognised and matches your ini. What do you mean by 'FSUIPC 7 does not recognize any of my controllers'? What do you see, for example, when you open the button assignments panel and press a button on one of your controllers - is that not registered?

Why? That does nothing at all....the ini file (containing your assignments) will still be the same - or did you delete this? If you delete this, you will have to re-assign and re-calibrate. Try the attached ini - just save it to your FSUIPC installation folder: FSUIPC6 ini Any issues, please re-attach both your .log and .ini files.

What do you mean by 'no longer recognises my numbers'? Id you have already validated yout license once and generated your FSUIPC7.key file, there is no need to validate again, although doing this should do no harm. Yes - read the section on Invalid Key Problems in the Installation and Registration guide. If that doesn't solve your issue, please explain why you need to re-register and let me know your FSUIPC7 order number and I can check the details here. But if has previously worked, it should still work. You are either entering the details incorrectly or you need to install/update your VC++ combined redistibutable package (if this is a new PC), John

Dvar isn't defined anywhere, so when you declare it in a function I suspect it will be local to that function - try defining DVar at the top of your script, e.g. local DVar = "no value" the variable val used in function UpdateWnd() is also never declared and will always be nil.

No it has not...I don't understand why you would think that. Please post ALL issues/comments/requests relating to the beta in the beta announcement thread. Yes, the DA62 is continually firing this input event for some reason. FSUIPC7 just logs what it sees. This is similar to the way many aircraft continually emit standard events/controls. For standard events, you can use the DontLogThese ini parameter to stop such events being logged. I will add something similar for Input Events at some point. but not sure when I will have time for this - it mat be after the initial release. John

Yes, sorry "not equals" in lua is '~=' not '!=' - that is C/C++, getting my languages confused... using '>0' is just as good. No problem - glad its now working and help with your issue. Regards, John

Please try the attach script. I have not tested this but its pretty simple. Make sure its running - best to add to the [Auto] (or a profile-specific [Auto.xxx]) section of your FSUIPC7.ini file, e.g. Any issues, please activate logging for Lua Plugins (only!) and show me your FSUIPC7.log and FSUIPC7.ini files. centerTankFuel.lua

Ok, thanks. I will provide you with a lua script to try - it is pretty straightforward and I may get a chance later today, but I will post again when ready. John

Which offsets? Offsets only hold data, they do not send anything. I have no idea as I do not fully understand your issue. Can you try logging some offsets (up to 4) using FSUIPC's offset logging facilities. ones which you think are holding invalid data. Try in both situations to see what the difference is. There are no 'offset processes', except the main simconnect thread that requests the data from the FS and then receives this and uses it to populate the offsets. Offsets that hold simvars are only updated from values received from the FS - they will be cleared/updated when any new value is received. I don't understand this and don't have the FSLabs A320 so I am not sure I can help that much, but if you can identify what offsets are holding incorrect data, we can go from there... Also, can you attach your FSUIPC4,ini file. John