John Dowson

You may have a registry issue. Please show me / attach your FSUIPC7.JoyScan.csv file and I will take a look. It finds the name in the device scan but not when matching to the registry: Your JoyScan file will tell me why. No. The matching on GUID and name is there for a reason, and has been like this for 10+ years. I am not going to revise the code for this now. Windows does occasionally create new entries for devices sometimes, maybe when disconnecting and re-connecting to a different hub, or on windows updates. It can also change the GUID of devices. Any such changes in the registry usually require a simple update of the ini to get it working again, or a cleaning of the registry entries. I can help with both, but there is nothing I can or am prepared to do about this in the way that devices are scanned and acquired by FSUIPC. John

1. You attached your FSUIPC7.log file when FSUIPC7 was still running. Please exit FSUIPC before attaching files (log and ini). 2. You trim is NOT assigned in FSUIPC. Your ini file shows no button or key assignments, and you only have axis assignments to set the Flaps: FSUIPC can only disable the trim if/when assigned in FSUIPC. John

It did not. D was created to match device 0, which has GUID DA65E8F0-62FA-11EB-8001-444553540000 A has GUID 90950270-68C6-11EB-8001-444553540000 What has happened is that your Alpha Flight Controls name now seems to be missing: Even though the GUIDs match, the names dont and so a new letter entry is created: I don't know why the name (in the registry) for your Alpha is now missing. You can either correct that, or go with the blank name by changing that section to: John P.S. This is not a bug, but something that changed in your system. I will remove [Bug Report] from the title of this post.

Add-ons -> WASM -> List Lvars If you do not have that menu entry, then the WASM has not been installed.

I just fired up SPAD with the C172 loaded. It connected, I selected the default profile for the aircraft, and both my Saitek Switch Panel and Multi panel seem to work, although the display seems to be not working on the Multi Panel at the moment - its blank, but the buttons are working. Not sure why - I haven't used this for many years. This is using version 0.5.1. I don't want to install and test with 0.5.0 as this would remove my current (working) installation. Sorry, but I have no idea why it isn't working for you - are you using 0.5.1?

Yes - its wrong. You are checking the value against 2 bytes (word), but offset 0D0C is a bit-oriented offset with the nav lights in bit 0 (so use a mask of 0001 for bit 0, or 2^0), so should be: If checking bit 1, use 0002, bit 2 is 0004, bit 3 is 0008, etc (generally, use 2^bitno, so 2nd bit is 2^2=4). Also better to use !0 for the condition, or omit (as I have done), as that is the default, as the actual value would depend on the bit position, but you are just checking if the bit is set (!0) or not (=0). John P.S. But as you are using Nav Lights Set and NOT a toggle control, you don't really need an offset condition. Without the offset condition, the control will be sent but have no effect

If a key (combination) press is assigned both in MSFS and FSUIPC7, then both assignments will be triggered. i.e. assigning in FSUIPC7 will not prevent assignments being triggered in MSFS (or in any other software). So, if/when assigning in FSUIPC7, you should check and delete the key assignment in MSFS. John

Control numbers are given in decimal, not hex, so the to send the auto-save on/off toggle control you would need to use ipc.control(1151) No. As it says in the documentation (Advanced User manual, page 30): So auto-save must be active, and then the toggle allows you to enable/disable it. No, not directly. But as it should always be on when you start a flight (*), you should be able to determine the current state of auto-save by the number of times it has been toggled. * auto-save should always be on when a flight is started, regardless of the state of the auto-save after the previous flight, but I am not sure if this is the case...if not, I would need to correct this. John

You are assigning to a toggle control and only on the press. So when you activate the switch (press) it toggles, but when you switch off (release) it is doing nothing. So, when you next activate the switch, it toggles again and will switch on. You need to assign to the toggle on release as well. However, when assigning both a button/switch press and release to toggles, you can easily get out-of-sync with the state of the switch in the VC. Better to assigning the press to on (e.g. Master Battery On or Master Battery Set with a parameter of 1) and the release to off (e.g. Master Battery Off or Master Battery Set with a parameter of 0). Alternatively, you can add an offset condition so that the control is only sent if needed (i.e. if already on and you switch on, no toggle control is sent). See the Advanced User guide on how to use offset conditions, and you need to find an offset that holds the state of whatever you are trying to change (see the Offset Status document for this). Thanks...but I have found my SPAD installation from 6 years ago, so will try/test this later. John

There was a 10 euro discount for FSUIPC7 if you have already purchased FSUIPC6, but not the other way around. I have corrected this now, so you should see the discount. John

Btw, what aircraft are you using? If I have it, I can check this here. Or does this apply to all aircraft? Can you check this in a default/Asobo aircraft or two (if not done already)? It should have no affect if disconnected, but it could be an aircraft-specific issue. I need to know how your trim is assigned, as well as the aircraft. Is any trim actually being applied (even briefly), or is this just a visual thing? Maybe also see this user contribution:

There is NOTHING "techy" about anything I am saying.... What are you talking about? PLEASE read what I have said. i..e. Find the FSUIPC4.ini file, which will be in your installation folder, the same folder as the log files you are attaching. Open that in an editor (e.g. Notepad++), find the section that starts [General]. and then add that line. Then test to see if this prevents the CTD. If so, it is due to a corrupt weather file. I have already answered this and provided a link with further information as well as a link to a very useful program that helps you locate ANY file on your system. Try reading my posts before responding with the exact same questions that I have already answered...

It does say this on the SimMarket page for FSUIPC7: It is recommended to download and read the documentation and try the unregistered version before purchase. You can also try the registered facilities using a trial license, available here: https://forum.simflight.com/topic/92702-fsuipc7-trial-license-available-here/ The log and ini files are always in the FSUIPC7 installation folder, and C:\FSUIPC7 is the default location where it is installed, so you just installed in this location by default. Not sure why your logs haven't completed/closed correctly. Maybe FSUIPC7 was still running when you attached the FSUIPC7.log file (please always exit FSUIPC7 before attaching files), but the FSUIPC7_prev.log should have closed properly, which it hasn't. Not sure why this is. And it looks like FSUIPC7 isn't actually doing much, except sending out GPS data. You don't seem to even have any devices/controllers.... You can try logging the GPS data to see what is being sent - go to Log -> Custom, and enter x4. After doing that, the GPS strings being sent out will also be logged in the FSUIPC7.log file. Strange... I am not expecting them to support FSUIPC7 (I do that!), but they should support SkyDemon on all platforms that they support. I cannot support SkyDemon. You do need a key/license to use the GPS-out facilities, but you can also trial this first by requesting a trial license. FSUIPC7 doesn't do online license validation, so once a licensed is given it cannot be rescinded, hence the no refund policy. Sorry about that (but you should be able to get this working...). Did you install Flight Sim GPS? Did you check out that link I posted? Try following this:

The assignment index numbers in the ini have always started at 0 and have always been incremented by 1. Why would you want to increment by more than 1? Seems a strange thing to want to do. And if you are manually editing the ini, you can change the index numbers to any unique number within range.

Maybe also worth trying these lua scripts instead of SPAD: John

Well, as FSUIPC doesn't do anything with SPAD, it won't be an FSUIPC issue (although SPAD may talk to FSUIPC). But you should certainly be able to use the free SPAD version with FSUIPC, and I have done in the past (but over 5 years ago!). I have no recollection of how I set this up though... Do you have a link to download SPAD? Seems that it is no longer available at the link we provide(at http://fstools.weebly.com), and can't find it with google. Maybe also see https://www.prepar3d.com/forum/viewtopic.php?t=8356. John

That is 12 years old - way before my time! As I said, I will prevent FSUIPC from writing an entry with all 0's, but I do not know why this is being written occasionally, It should only write that entry if the console window is open, and the position/size is retrieved from windows. John

First, you posted in the wrong forum for FSUIPC support - you posted in the support forum for the .Net client dll. I have moved your post, but please take care post in the correct forum for support. What version of FSX are you using? i.e. what is 'Flight Simulator X-BR'? If that is the beta version (build 63003), please see: Although I would recommend not using that version.... Otherwise, please show me/attach your FSUIPC4 Install.log file.

License sent - sorry for the delay, I was on holiday. John

Also see:

I have not heard of this happening before, and this functionality has been around for many years. The ConsoleWindow entry should only ever be written if/when the console window is actually open, and not when any logging is activated. I don't know why it is adding that entry for you, but I guess I can not write the entry if the values are 0. John

Possibly - I will look into it. Maybe, I am not sure - FSUIPC just calls a windows API function to select/position the menu entry. I don't think its possible to force it to the top, but I will take a look when I can. Sorry, what do you mean by this - what 'increment' are you talking about here? You can use a simple lua script (using event.lvar, and just log the value in the handling function). I have been meaning to add specific support for lvar logging for quite a while, but have just not had time to do this yet. It will be added at some point, but I do not know when. John

The documentation is always a good place to start...from the README.txt: John

What do you mean? You do realize that I am on holiday: If this CTD is due to a bad weather file, then this is a known issue, has been known for 10+ years, and there is nothing that can be done about this in FSUIPC. It is the FSX API that FSUIPC uses to get the weather that is causing this issue. There are already hundreds of support requests in this issue, and the response from me (and Pete, before he retired) is always the same. Did you even try what I suggested: ? i.e. Did adding NoWeatherAtAll=Yes prevent the CTD? Your *.WX files will be in your Documents\Flight Simulator X Files folder (where your flights are stored), and the file "wxstationlist.bin" in your <user>\AppData\Roaming folder for FSX. You can always try searching for them, using something like Everything. John

I do not have this aircraft so cannot advise. You need to use the standard techniques for determining what control the aircraft is using - logging. First try logging for Axes Controls, open the logging console window (Log-> Open Console) and see if any axes control is logged when you move the throttle in the VC. If anything is logged, try using that. If nothing is logged, try logging Input Events. Again, with the logging console open, move the throttle in the VC and see if any Input Events are registered, and if so you can use those. But be aware that you cannot assign an axis to an Input Event directly, you have to assign to an FSUIPC offset and have a lua script that monitors the offset and sends the Input Event - I can help with this if needed. If no Input Events are logged, then the next step would be look into seeing if possible to control using lvars. John