John Dowson

7.5.2e is a beta version, and you should not have received any notification for this as only official releases will prompt a message to download, When you re-install, it is far easier to just install into the same folder. This will then just replace the installed files and leave all other files (e.g. settings, key, lua sctipts, macros, dlls, etc). 7.5.2 is the latest official release, and it should say that 7.5.2 is available, and not 7.5.2e. If you are using 7.5.2e, then you are using the last beta of 7.5.2. You should ypdate to the latest official release (hence the message), although there will be no actual difference in the versions (7.5.2e was the last beta and was released as 7.5.2). Please also use the FSUIPC7 support sub-forum for all issues/questions with FSUIPC7, and not the main support forum. I have moved your post. John

Again, all information on offsets is in the FSUIPC7 Offset Status document - why don't you look at that? I provide extensive documentation so that I do not have to spen all day responding to such questions. Please ALWAYS consult the documentation (as well as checking these forums) before posting questions.

No hay ningún problema con su licencia: Consulte la documentación - Installation and Regisuration guide. Los problemas de validación siempre se deben a: - introducir los datos incorrectos - no tener instalados los redistribuibles de VC++ correctos - problemas con el antivirus Todo esto se explica en la documentación, aunque solo está disponible en inglés.

Does that even work? Should be: i.e. presets names should be preceded by 'P:'. Macros are ran in the main thread, and will block that thread until it has finished. If a macro is going to take more than a few hundred ms to complete (and you have an 8 second delay there!), you should use a lua script instead. Lua scripts are ram om separate threads. John

👍

Ah - maybe these are 'scoped' local variables? See https://devsupport.flightsimulator.com/t/how-to-access-scoped-lvars-l-with-simconnect/12540/20

This issue is continually getting reported, and my answer is always the same. Please see one of the other many posts on exactly the same issue: ...etc Basically read the documentation and follow the advise there, and also check out the many posts on exactly the same issue.

So it looks like the GUIDs have changed, not only for that device but also for your Saitek Pro Flight X-55 Rhino Stick, which now has two device letters D and E. If the GUID if your MIAP STD is now that in the C entry, but your assignments are referencing B, then switch the GUIDs and remove the C entry, ie. You should also do similar for your Saitek Pro Flight X-55 Rhino Stick. Also, please attach the full ini file next time rather than posting extracts, and also attach your FSUIPC7.log file for any further issues. John

From the FSUIPC7 Offset status document - 3584 bytes starting at offset 0x5200: i.e. Offset 0x5428 is in an offset area that has been allocated to Project Magenta, and you need to look at the PM documentation or ask them what that offset is used for. John

It is not actually hanging is it, its just waiting for a connection, no? Does it connect automatically when you restart FSUIPC, or do you have to also restart the WideClient? Can you please show me / attach your FSUIPC7.log and WideServer.log files, both from when it initially fails to connect (and after you have exited FSUIPC7) and also from after when you restart it and it connects.

You should sort out the disconnection issues shown on your log. There are no changes from any version that cause performance issues - your problem lies elsewhere. You can try an older version if you like (not that this will help!) - current/latest version is: https://fsuipc.com/download/Install_FSUIPC7.5.2.zip previous version: https://fsuipc.com/download/Install_FSUIPC7.5.1.zip older versions: https://fsuipc.com/download/Install_FSUIPC7.5.0.zip https://fsuipc.com/download/Install_FSUIPC7.4.17.zip https://fsuipc.com/download/Install_FSUIPC7.4.15.zip etc.

It doesn't make sense to allow this in FSUIPC due to the way calibration works in FSUIPC. FSUIPC calibrates to an FS control, and as there is no specific control/event when assigning to a preset, it does not know the range to calibrate to. Max/min/scaling etc can easily be handled, either in the RPN itself. or you can just write the axis value to an offset and do whatever you want with it before using it in a preset.

All I can see in those images is that one has an FPS of 127 and the other of 110. Isn't an FPS of 110 enough? The log file you attached is very strange, as it just shows FSUIPC connecting and disconnecting, It makes no sense to me, and you have not provided any context. What actually happened? What/why is FSUIPC closing shortly after being started: ?

The log file you attached was attached when FSUIPC was still running and also stops after 30 seconds. You are also using an old an unsupported version of FSUIPC. Only the latest version is supported - please update. And your ini file shows that you are not actually using FSUIPC for anything. You only have one (strange) button assignment, you have profiles but they are empty, and you [MacroFiles] section is very weird... Are you assigning in MobiFlight? i cannot support mobiflight - please use their support channels (discord) for issues with MF.

How have you assigned? There can be toggle controls, set controls that take a parameter (on/off) and separate on/off controls. So it depends on how you have assigned. You can also use offset conditions to check the state of a button before changing it, if require. Please show me / attach your ini file so that I can see your assignments.

You cannot calibrate when assigning to presets - this just doesn't make sense to allow this. No - it doesn't make any sense to allow this. There is no way that FSUIPC can calibrate values needed for a preset. No. Just use scaling.

Is there a simvar or lvar that holds the current state of this button? If so, log that... And also please at least activate logging for Events, and attach your log file here (as well as your ini) and I can take a look. Just defining a macro cannot affect the aircraft state on start-up. Something must be triggering this.

So its NOT an lvar. And it is not 'doing anything' as it doesn't exist. Juat because an lvar exists for the rudder trim and aileron trim, doesn't necessarily mean that one will exist for elevator trim. And if you list the lvars and its not there, it doesn't exist. If you are thinking that it should exists as there are similar ones for rudder and aileron trim, then you are mistaken and are wasting both your and my time on this. Use the facilities provided to determine what is available, don't guess.

Please: - turn off WAPI trace logging. Debug level logging is sufficient - also activate logging for Axes Controls and Extras - please also attach both your FSUIPC7.ini and myevents.txt files as well as a new FSUIPC7.log - please don't attach images unless requested. It is the files I need to see.

Almost all lvars are defined by the aircraft... Well, there are no lvars added to offsets by default. And as I have said many times now, listing the lvars in FSUIPC will list ALL lvars available fromthe last scan. You can even reload and list lvars, which will list ALL lvars defined and available. If that lvar isn't there' it is NOT an lvar, 'custom' (which means nothing) or otherwise. I don't understand why you think that is an lvar - why do you think that? How can you see it? How can you read/set/change it then?

But the macro does nothing unless you run it. So, if something is running the macro when you start FSUIPC or MobiFlight, then stop/disable that. A macro file does nothing by itself - something needs to trigger it to be ran. You can use FSUIPC's logging facilities to determine what,

Almost all lvars are defined by the aircraf... I still have no idea what you mean when you say 'custom'. As I said, if FSUIPC does not list it, it is NOT an lvar

I don't see how this can be the case. There is no such scaling. If assigning an axis to a preset, the axis value Out value should be used as the parameter, which should also match the In value. WAPI Debug level logging should show the values being used.

We seem to be going in circles here....I know that it isn't closing, and I need to see your file if you want my help looking into why... John

I am sorry but I don't understand this - how can running FSUIPC7 force spad.next to lose a connection? Yes - by not connecting FSUIPC7 to MSFS. Once it is connected, it is interacting... FSUIPC does not do anything with any devices/controllers unless you tell it to. Unregistered versions do not even scan for devices.