John Dowson

By "extras" do you mean the components under Extras in the installer? If so, these don't actually do anything, unless you actually use them, so I can't see how they could have any affect om performance at all...

Thanks, but you don't need to do that - the license is per user and you can install on as many PCs as you like, for your own use. No - it will be either because you have not entered the key details correctly, or your VC++ redistributables are out-of-date. Please see the provided Installing and Registering FSUIPC7 document, section Invalid Key Problems. John

Could you please try with the following setting in the [General] section of your FSUIPC7.ini file: ComReadLoopTime=10 If you get the same issue, can you also try with a value of 5 and then maybe 2 and then 0... Let me know if any of those values make any difference. Thanks, John

Sorry, this one had moved off my radar...I will take another look and report back, although it will be difficult for me to investigate properly as I don't have any VRInsight devices.

Yes, but not at the same time!

FSUIPC7 only connects to MSFS. It is self-loading cargo that connects to FSUIPC7. And you (probably) don't need to use a registered version of FSUIPC7 to run 3rd-party clients, the free/unregistered version should be sufficient. As it says in the first comment on this topic where you downloaded the FSUIPC7.key file: What do you mean by this? If you got to the license registration page, where you pressed Skip. then FSUIC7 is already installed. If your issue is with self loading cargo, you need their support - I cannot and do not support 3rd-part programs, Otherwise, please clarify as to what your actual issue is - and please do not post again in this topic, as this is for requesting a trial license only. Please check/search the forum for the same issue and use that (if the answer isn't given!) or create a new appropriately titled topic. John John

To determine how to operate a switch, do the following: - first, see if there is a standard event/control that you can use. To do this, activate logging for Events (non-axis controls) and open the logging console window. Then flip the switch in the UI and see if any event is logged - if so, you can use that. - if there is no standard event/control,. list the lvars and see if anything looks appropriate. Then flip the switch and list the lvars again to see if the lvar you have identified changes value. If so, you can use that. I can't really help you any further as I don't have the 390 Premier IA. Well, if that assignment doesn't work when assigned to a switch, it won't work when sent when using an axis range. Note also that the range for the action you assigned is 0-0, You should really set a wider range for this (using the From and To buttons). Also please note that these questions have nothing to do with the title of this topic - 'PFChid64 Addon doesn't open in P3Dv4'. Please don't continually use the same topic for different issues. Create a new appropriately titled topic (also with the aircraft you are using) - you may then get assistance from others who own this aircraft. John

FSUIPC only does what you ask it to do.... If the speed is limited, this could be because the flaps or spoilers are deployed. Try activating logging for Events and Axes Controls, to see if you see anything logged that could be limiting the speed (i.e. do this with the logging console window open and see what is logged in real-time). You can also attach your FSUIPC6.log file here and I will take a look. Please exit FSUIPC/P3D before attaching you log, and it will probably be quite large and so need zipping/compressing. Also, attach your FSUIPC6.ini file. Not sure what this means...for many/most switches in the PMDG 737, you need to use custom controls - see Additional offsets (read-only) are also provided for the PMDG 737 (once activated) - see the provided documentation (Offset Mapping for PMDG 737NGX and 737NGXu). John

I have released this now - the beta release (available in the Announcements page) has been updated to include this change. I plan to make this the official release at the weekend. John

I have looked at his now as well and have updated so that the lvars-loaded callback will be called after the initial values have been received. The downside of this is that you wont get an lvar-update callback for the initial value. I haven't released this update yet though - I will do some further testing first.

I have checked this now and it seems to be working as expected. I added these lvars to an FSUIPC offset, which will flag them for a callback: Then in the log, I can see these being flagged for a callback: where And if I log offsets 0xA002 and 0xA004 I can see these values change when I release and then apply the parking brake: Note that the [Debug] messages are from the WAPI and show the lvars being flagged for callback when a value change is detected. This callback is then used by FSUIPC to update the values held in the offsets. This therefore seems to be working as expected and the error must be in your code somewhere. John

I suspect that it this is happening then it is the lvar that is not changing value. but I will take a look. Is this in the Asobo or FBW A320. and if the latter which version (stable, development, experimental)? Btw, please also update to the latest beta, if not using this already: John

Yes. Use the messaging functionality provided - click my name/avatar and then use the message function. Please explain your use (in the PM/DM) and we can take it from there. Regards, John

First. make sure that you are using the "JoyLetters" facility in FSUIPC7 on your old PC - this should be active by default. Install the latest version of FSUIPC7 on your new PC. You can skip registration, and then copy across the following files from your old PC FSUIPC7 installation folder to the one on the new PC: FSUIPC7.ini, FSUIPC7.key, *.dll, *.lua, *.mcro. Also copy across the Profiles folder, if using profiles in separate files. It is quite possible that the GUIDs of your controllers are different on the new PC. To check and correct for this, run FSUIPC7 once and then exit. Then open the updated FSUIPC7.ini file in an editor and find the [JoyNames] section. If your GUIDs have changed, you will see some entries marked as "<< MISSING JOYSTICK >>". For these entries, you need to change the GUID entry for that matching entry (i.e. with the same letter as the missing device), which will be listed later with a new device letter (the names will match). So, change the GUID entry of the missing device entry to the new one, and remove the new device entry. Do this for each missing device. Then if you run FSUIPC7 again, everything should be ok. If you have any difficulties or issues, please post/attach your FSUIPC7.ini once it has been updated by FSUIPC7 on your new PC, together with your FSUIPC7.log file. John

It should be ok to run MakeRunways while MSFS is still open/running. However, please note (from the provided README.pdf): John

Is this the same error as reported here (Pegasus): If running MSFS as admin, make sue you have set the FSUIPC7.exe to be ran as admin (in Properties->Compatibility) as it may not run automatically as admin. otherwise./

Thanks for the update. Are you tunning Pegasus on a client PC then? Using WideClient or FSUIPC7 on the client PC?

When you list the lvars, they are also logged to the FSUIPC7.log file in id order, with the id given. The list in the main FSUIPC7 window is in alphabetical order, and the ids are not shown (as not normally needed for most users). Try listing the lvars with the logging console window open (Log -> Open Console...). Just FYI.

B vars are "input events" - see https://docs.flightsimulator.com/html/Additional_Information/Reverse_Polish_Notation.htm (section Variable Types). We can only provide access to the variable types permitted in the SDK - A type (simvars) and k type (events) via simconnect, and L type (lvars) and h type (hvars) via the gauges API using the WASM. You may be able to use other variable types via calculator code, but you cannot read/know their value - if they have one. As a b-type variable is an input event, I doubt it has a value - it is what you input.... Then again, I know nothing about b type variables - maybe ask about those on the Asobo forums.... As I said, they are input events, whatever that means, and there is no provision in the SDK to access or know about such variable types. I think the b var is for control. as it is an input event. Try listing the available lvars to see if the state is held in one of those. As I don't have this aircraft, and it isn't listed in the MF presets, I can't really help with this. Ask Asobo / MSFS - it has been very difficult for us 3rd party developers to try and provide what we can with the APIs that they provide.... John

The lvars-ready callback is performed once all lvars have been loaded (i.e. the names known), not when they have received an initialisation value. All lvars are initialised to 0.0, If you need the values initialised, you should set a timer in this callback (200ms or so should be ok)and perform your actions in the timer callback. I guess I could delay the callback until the first set of values have been received - I will look into this. I really can't see how this can happen...the code doesn't know anything about any particular lvar, they are all treated the same. Try setting Debug level logging in the WAPI - this should tell you when am lvar is flagged for callback when values are received. If you can generate a log showing your issue (it will be large so will need to be compressed/zipped) I will take a look. Only the lvars that you register to receive a callback when changed will be monitored. There is currently no way to deregister an lvar for a callback - this could be added if needed. But you can use whatever method works best for what you are trying to achieve. Cheers, John

You can't - but if you need to know this, then as it is on before you start to toggle it on/off, you can keep track of this yourself if needed. You just need to initialise a free FSUIPC offset to 1 (on) and then also toggle this offset value each time you toggle auto-save (i.e. overload the button you gave assigned to auto-save to also toggle this offset va;ue). There is also a flight-save counter that is incremented each time a flight is saved, at offset 0x3BD2. You could monitor that if you want to know when a flight is saved. John

Ok, thanks for the update. John

No - that control should be the one you need. Can you please activate logging for Buttons & Keys as well as Events (non-axis controls), and generate a short log file showing your issue - i.e. load an aircraft and press the assigned key to switch com1 active/standby, then click the button in the VC that does this, then exit the FS and show me/attach your FSUIPC ini and log files.

You should try listing the lvars when this occurs, to check if those lvars are available or not. Then reload and check again. Do those ;vars have high ids? The log file you posted is useless - it is from a running FSUIPC7 and ends after 41 seconds. By the way, you posted in the main support forum. There is a specific sub-forum for FSUI{C7 / MSFS issues - I will move this topic to that sub-forum. John

Yes! John