
John Dowson
Members-
Posts
13,332 -
Joined
-
Last visited
-
Days Won
273
Content Type
Profiles
Forums
Events
Gallery
Downloads
Everything posted by John Dowson
-
How do I fully uninstall FSUIPC6 from P3D?
John Dowson replied to Kalnon's topic in FSUIPC Support Pete Dowson Modules
It is installed in the folder you chose when you installed - this may be under your Documents folder... To uninstall FSUIPC6, run the uninstaller, either via the windows app management panel or by running the uninstaller directly from the installation folder. -
I am not familiar with the G1000 and am not sure what that key/symbol is...these are the control pad presets available for the G1000: There are also many presets available for the MFD, PFD and MID: Could one of those be what you are looking for?
-
This really shouldn't happen... I have realized that I made a mistake with the 7.4.18 release...I have been testing the SDK for MSFS2024 and accidentally built the final release of 7.4.18 with the SDK from this version, instead of the version for MSFS2020. Sorry about that - I have corrected this now and have updated the installers with this correct build. Could you therefore please re-download and try again. if you get the same issue, please show me / attach your FSUIPC7.log file. Note that I have kept the version number the same, at 7.4.18, but the build date has been updated to 3rd November, so please check thar you are using this version (you may need to clear your browser cache to download this version. I have also attached this version below, but you should really re-install as the WASM has also been rebuilt. You can prevent this by setting the following ini parameter under the [General] section of your FSUIPC7.ini file: OpenOnStart=Never John
-
New Fuel System - How To Read Tanks
John Dowson replied to CougarFool's topic in FSUIPC Client DLL for .NET
The new fuel system simvars have not been added to any FSUIPC offsets as if these are added, they flood the MSFS console with error messages when using an aircraft that does not use the new fuel system. I did add the new fuelsystem pump simvars to FSUIPC a while ago which produced this error, which can cause stuttering due to the number of messages logged, I therefore removed these by default. and added a new ini parameter NumberOfPumps which can be set to re-enable these offsets. For the new fuelsystem tank variables, you can add these to spare/free FSUIPC offsets yourself via the myOffsets.txt file (see Advanced User guide for details). If you do this, make sure this file is only loaded/used when you use an aircraft that uses the new fuelsystem. John -
Thanks for your kind words. Pete has retired now and doesn't check the forums often, but I will pass on your message. Regards, John
-
Your upload limit will increase the more you post. The files also zip/compress pretty well, as they are just text, so you can also try that next time. Your log files don't show any issues, other than your device not being detected on COM1. You need to determine what COM port your device is using, and I can't really help with this. Your device is or has previously been detected as a HID joystick type device though: Although there are no entries for that device with a joyId number, which makes me suspect it was added earlier when you were using a different COM port number. Maybe try removing that entry, and go through the COM port numbers again and see for which COM port number that entry gets added Other than that, I am not sure what I can advise... maybe some other PFC Cirrus !I users can help - both @Logan Greenlee and @Jeff Enlow are PFC Cirrus II users I have helped in the past, maybe they could help with this?
-
Did you install the driver that comes with the cable? Then I guess the drivers are installed... Does the test app tell you which COM port is being used? Did you try COM1? Most modern PC's don't have COM ports, so the cable may be on COM1, so at least try that. If that doesn't work, show me / attach your FSUIPC7.log, FSUIPC7.ini and PFCcom64.log files and I can take a look, although I'm not sure I can help much if its not detected...
-
No - that ini parameter just specifies the just delay between aircraft load and the first scan for lvars. It seems to be repeated scanning for lvars that is causing this issue, and that will still occur. That is very interesting...that does indicate to me that there maybe is a memory issue somewhere un the WASM - I will look into this (again).... Thanks for your files/input on this. I will update if/when I find amything. Regards, John
-
Glad its now working. Yes, using event.com is much more efficient. That is probably a better long-term solution, as you are already writing your own code to drive the LCD. Via the SDK, you can either write the COM1 standby frequency (in Hz) to offset 0x05CC (as a 4-byte int), or you can use offset 0x3110 which operates a facility to send any control to the FS. Cheers, John
-
Your log files are very interesting... They show the lvar names correctly in the initial scan, when 134 lvars are detected, but (97 seconds) later 137 lvars are detected and two of the lvar names have been corrupted. This corruption looks to be in the WASM, so I am surprised when you say that 'MSFS Disconnect / MSFS Reconnect from FSUIPC menu often solves the issue'. However, to confirm this, I would need to see an FSUIPC_WASM.log with Trace logging activated. It is strange that the following 3 lvars are created such a long time after aircraft load: 77391 [TRACE]: LVAR Data: name='FSDT_VAR_Frozen' 77391 [TRACE]: LVAR Data: name='B738_EmergencyDoors' 77391 [TRACE]: LVAR Data: name='Prosim738_Steering' There is a known issue with scanning for lvars that can cause the FSUIPC WASM module to crash. See It looks like you are getting a similar issue, but rather than a WASM crash you are getting a memory corruption somewhere. To prevent this, try tuning your WASM ini parameters. You currently have these set: Try with: LvarScanFrequency=-30 LvarScanDelay=10 LvarScanPeriod=-4 If you still get issues, and if not using those 3 additional lvars (mentioned above) directly (you can still use them via presets/calculator code), you could disable continual lvar scanning by setting: LvarScanFrequency=0 There seems to be something un MSFS that is corrupting the lvar name space, which I reported to MSFS a while ago but have yet to receive a response. I have ran the FSUIPC WASM in a debugger for days at a time and have not seen any corruption in the WASM itself, so this seems to be an MSFS issue... John
-
Also, from the User Manual: So throttle should stay at full, and you need to send a throttle cut to release the idle stop ring to come out of idle. What type/style of axis is your z-axis? Is it a twist-style axis, fixed or spring-loaded, or a lever style axis? How you would assign for this depends on this - if it is a spring-loaded twist axis (which for airplanes you would normally assign to rudder and maybe steering tiller) then you would not want to assign this to an axis control (left-hand side of axis assignment) as this would mean you would have to hold it in maximum position. But re-reading this thread, you did say that assigning to Helicopter Throttle Set didn't work (did you try Helicopter Throttle1 Set ?), and you have now assigned this in MSFS. Is this still the case? If assigned in MSFS, you should remove the axis assignment in FSUIPC. I am confused now as to what you have working, and what you still want to assign. Can you let me know what is assigned in MSFS, what you are trying to achieve, and attach your current FSUIPC7.ini file.
-
And if you go back to using the renamed ini, do you get the issue again? Also, delete this entry, as it doesn't make much sense: This entry is also strange: (due to the large range specified): And why are you assigning to the Throttle control if this doesn't work: ? Are you sure that this is your axis range? According to your calibration, it is -16197 to 15378. That dies NOT show the value range if the input event - it shows that he throttle is using the standard control Helicopter Throttle1 Set. Why don't you just assign your axis to this control? What do you mean by this? And why would you want to do this? What is the range of that input event? Do you see it change when logging Input Events (Log -> Input Events) and if so what is the range? Also, when you make any changes, please attach your updated FSUIPC7.ini. Sorry, but the more you post the more confused I am on what you are actually trying to achieve. According to the Cowansim documentation, you just need to map the throttle axis (on left-hand side of axis assignment panel) to Helicopter Throttle1 Set (or maybe Helicopter Throttle Set, Axis Helicopter Throttle Set or Axis Helicopter1 Throttle Set ) and the Idle Stop Ring to Throttle Cut. I am not sure what an 'Idle Stop Ring' is, but if you want to send this to cut the throttle on the same axis, map this to be sent when entering a range in the right-hand side of the axis assignment panel.
-
But previously you said that MSFS crashed... Does this happen with any axis now? What about buttons? Can you also try with a default aircraft? That won't do anything... Try rebooting your PC, and first check in a default / Asobo aircraft. If you get the same issue, exit/kill FSUIPC, then rename your FSUIPC7.ini file and try again - you will lose all your assignments/settings, but we can add them back later, If that fixes your issue, show me / attach your renamed FSUIPC7.ini file and try with the cowansim. Not sure what is happening - I have never heard of an issue like this before....
-
This is not correct - the documentation states: str, n = com.read(handle,max,min) so your call will always return a null string until at least 100 characters are read, Please see the documentation on com.read (see below) - you need something like (with no minimum): function processInput() local datastring, length = com.read(dev, 256) -- Read up to 256 bytes from the serial port if length then ipc.display("Data received: " .. datastring, 2) -- Display the received data for debugging ipc.log("Data received: '" .. datastring .. "' [" .. length .. "]") -- log to file -- Example of parsing the received string to set COM1 standby frequency if datastring:match("^COM1SB") then local frequency = tonumber(datastring:sub(8)) * 1000 -- Extract frequency and convert to Hz ipc.control(67363, frequency) -- COM1_STBY_RADIO_HZ_SET ipc.display("COM1 standby frequency set to: " .. frequency, 3) ipc.log("COM1 standby frequency set to: " .. frequency) -- log to file end end end John str, n = com.read(handle,max) str, n = com.read(handle,max,min) str, n = com.read(handle,max,min, term) Reads up to 'max' bytes from the port, returning them as a string in 'str' with the number actually read returned in 'n'. If the 'min' parameter is also given, this returns a null string and n=0 until at least that minimum number of bytes are available. It does not block waiting for them. If you specify -1 as the minimum then the terminating character ('term') must be seen before the function returns a non-zero result, unless of course the 'max' size is reached first. The 'term' parameter specifies an ASCII value (0 to 255) which is to be treated as a terminator for each block. This character is included in the returned count and string. Note that you can use the event library function, event.com to perform reads and call your Lua back when there is data to process. This can be more efficient and tidier than a program which uses continuous loops to scan the input.
-
That is very strange! Did anything change to cause this? It does look like a memory corruption issue, which is very strange, and also seems to occur when FSUIPC is started, Ok, then that would seem to indicate that this is on the client side (WAPI) rather than in the WASM, Not sure at the moment. Could you set Debug level logging in the WAPI (Log->WAPI->Debug) and show me/attach another log file. As it seems to happen straight away, you could even set Trace level logging in the WAPI. Can you also set Debug level logging in the WASM (via the FSUIPC_WASM.ini - see Advanced User manual for details on where this is) and also include/attach your FSUIPC_WASM.log file. John
-
I also am not sure that you can specify the units for an lvar like this: (L:var_cabinPressurizationAltitude, FT) That syntax is for simvars, which have units specified (and documented). I have never seen this used before with lvars.... John
-
That doesn't sound like a small issue! Is this a new issue? You haven't mentioned this before.... Are you sure FSUIPC is crashing? If MSFS CTDs, then FSUIPC detects that MSFS is no longer available and will exit. Check your FSUIPC7.log file - it should show FSUIPC exiting normally.
-
The same device connected to a different computer will almost certainly be assigned a different GUID. GUIDs are allocated by windows. You cannot change this by editing the registry. You should use letters. Using numbers/JoyIds has further issues as joyIds can easily change and is more cumbersome to compensate for. If you use letters and the GUID of a device changes, the fix is simple: - copy the GUID from the new letter assigned to the old letter - delete the new letter assigned entry Thats it. No, this is not possible (as far as I am aware) as the GUIDs are created dynamically. You could possibly do this (by editing the registry and your FSUIPC ini file)) but I would not recommend this, And, as I said, use joyletters. John
-
But that can't possibly work, for two reasons: 1. You are instructing to write 8 bytes to offset address 0x2748. This will therefore use addresses 0x2748 - 0x274F inclusive. The second entry is using 0x2749, which then overwrites the area specified for the first lvar. 2. You cannot write an 8-byte value to 0x2749 as this is not on an 8-byte boundary. As I mentioned earlier (and as documented), values MUST be boundary aligned. What this means is that the offset address used for 8-byte values must end with a 0 or 8, offset addresses for 4-byte values must end in 0, 4, 8, or C, and offset addresses for 2-byte values must end in 0,2,4,6,8,A,C or E. Your ini file shows this: which is incorrect for the reasons given above. You are also adding many lvars as unsigned bytes (UB), and many of those are not unsigned bytes. An unsigned byte can only hold a value in the range 0-255. No point looking at your log as - you have WAPI TRACE logging activated., Turn this off. - you are NOT monitoring/logging the offsets you are using, as advised Why do you noy just follow the advise I previously gave: . Please use something like: and also log offsets (Log -> Offsets...) 0x2750 and 0x2578 both as FLT64. This will then log the values in those offsets to the FSUIPC7.log file. You can show me / attach your FSUIPC7.log and FSUIPC7.ini files ? John
-
If you list the lvars (Add-ons -> WASM -> List Lvars) do you see the lvars with the correct values? I don't know why you would try that... Please use something like: and also log offsets (Log -> Offsets...) 0x2750 and 0x2578 both as FLT64. This will then log the values in those offsets to the FSUIPC7.log file. You can show me / attach your FSUIPC7.log and FSUIPC7.ini files I have added new functionality to log specified lvars (to the log or a separate window) which I will release in a day or two - this may help you see the lvar values, but will basically show the same as adding the lvars to offsets and logging the offsets. I will let you know when available.
-
Is the script receiving any data? Try debugging the script, by either starting it with LuaDebug or by setting Debug / Trace Lua plugins in the FSUIPC logging tab. But it would be better to update your C code and use the FSUIPC SDK to update the offset with the COM! stndby frequency. Take a look in the SDK subfolder, at the UIPC64_SDK_C_version2 toolkit. You can use this to update FSUIPC offsets, which will trigger the controls to set the values in the FS, John