John Dowson
-
Posts
13,281 -
Joined
-
Last visited
-
Days Won
271
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by John Dowson
-
-
That is strange... but I don't know what you mean by 'Could this be the issue?'. You (or the account that you used to install) are the owner. I cannot help with permissions issues on your system - try google.
BUT, you don't need to edit/change that file, and it is not recommended to modify that file anyway as any changes will get overwritten the next time you install. Please read the section WASM module ini file and parameters in the Advanced User guide (page 51) where it says:
It is recommended to leave this file as is, and copy to your persistent storage area and modify as and when needed from there.
-
12 hours ago, Hageneezz said:
FSUIPC3 did install in FS2004. But when installing I got an error message saying 'Problem cannot place FSUIPC.DLL into the FS Modules folder. Windows could not find the
correct path...When I press okay, I get another dialogue which says that the DLL installed into FS9 okay...
Sorry, but this is confusing. Is the dll in the modules folder or not? If not, you can manually install it if someone can supply you a copy of the dll, and you would have to manually update FS2004 to load the dll. This is way before my time I'm afraid and have no access to anything regarding FSUIPC3 (it is free and unsupported).
12 hours ago, Hageneezz said:The problem I`m having is that the registration dialogue never show`s up.
Again, I have no idea, If FSUIPC is installed and loaded by FS2004, and the only issue is that it is unregistered, then you can try manually creating the key file. Create a file in the FS modules folder (where the FSUIPC dll is located) called either FSUIPC3.key (or maybe just FSUIPC.key) with the following contents:
[User] Name=free user Address=fsuipc@free.com FSUIPC=Y8ZGSUWHTIQ2John
-
That is a far better log! But I don't understand why you keep attaching the bat file though - that is installed by the installer and I have that here. It is not needed.
That log file shows that there is an issue with the WASM and that the initial lvars were not received. Please show me / attach your FSUIPC_WASM.log file, and check that the WASM isn't crashing - this seems to be more frequent in MSFS2024 than MSFS2020. Also set Debug level logging in the WASM (via the FSUIPC_WASM.ini file) - see the Advanced User guide if you do not know where these are.
Also see the following FAQ entry on the WASM crash and how to prevent:
John
-
1 hour ago, TimothyPilot said:
The movement is detected in FSUIPC but the ranges appear to be wrong. For instance, the aileron range is from around -12,568 to +8450, with the centre at around -1640.
If that is what FSUIPC sees, that is what windows is reporting.
First, try calibrating under windows (game controllers). That will determine the values that FSUIPC sees.
But if that is the range you see in the assignments panels, you can calibrate those to the full range using FSUIPC's calibration facilities. Better to assign using 'Send direct to FSUIPC calibration', but you may also be able to calibrate when using 'Send to FS as normal axis' (although I am not sure about this when using ProSim).Also, please check in ProSim. I don't use ProSim (although Pete does, the original author of FSUIPC)m but was under the impression that ProSim provides its own assignment and calibration facilities these days, so you may be worth switching to them, or at least checking that they are not interfering.
1 hour ago, TimothyPilot said:In addition, the rudder pedals register but the rudder guage in the lower EICAS doesn't move and doesn't appear to work on the aircraft.
Ask about this on the ProSim forums (or maybe try a different rudder axis control to see if that helps).
John
-
Sorry but it is difficult to understand what your issue is. Is this with software that you have written using Paul's .Net client dll?
If so, when you get the issue, can you still use lvars via FSUIPC or using the WASMClient?
Basically you need to determine if the issue is with your software or if the WASM has crashed. So please do that.If the issue is with your software and you are using Paul's .Net client dll, I cannot help you, and you need to post in Pail's .Net dll client forum: https://forum.simflight.com/forum/167-fsuipc-client-dll-for-net/
15 minutes ago, achilleghilotti said:I also installed the MSFSVariableService example software on the same machine as the simulator but on MSFS2024 it doesn't work either. It connects but doesn't even load the LVAR list.
That is also a question for Paul's forum.
Many of your posts are very difficult to read and it takes a lot of work just to try and understand them. I understand that this may be a language / translation issue, but please take care to post in a format that is at least readable...e.g. at least no scroll bars please....
And this is VERY important:
On 1/31/2025 at 8:21 PM, John Dowson said:Your WASM log does show some issues:
QuoteExpand...
Fri Jan 31 17:18:02 2025 [ERROR]: Ignoring request to update LVARs as updated internally
Fri Jan 31 17:18:02 2025 [ERROR]: Ignoring request to update LVARs as updated internally
Fri Jan 31 17:18:03 2025 [ERROR]: Ignoring request to update LVARs as updated internally
Fri Jan 31 17:18:03 2025 [ERROR]: Ignoring request to update LVARs as updated internally
Fri Jan 31 17:18:03 2025 [ERROR]: Ignoring request to update LVARs as updated internally
Fri Jan 31 17:18:03 2025 [ERROR]: Ignoring request to update LVARs as updated internally
Fri Jan 31 17:18:03 2025 [ERROR]: Ignoring request to update LVARs as updated internally
Fri Jan 31 17:18:04 2025 [ERROR]: Ignoring request to update LVARs as updated internally
Fri Jan 31 17:18:04 2025 [ERROR]: Ignoring request to update LVARs as updated internally
...One of your FSUIPC clients is requesting lvar updates (via WAPI ini parameter LvarUpdateFrequency) - you should remove that/set to 0 and let the WASM control all updates.
You MUST make sure that any/all clients are NOT requesting lvar updates as this should be controlled by the WASM, not the client(s).
John
-
5 hours ago, Mostafa said:
Also trying to build any code using FSUIPC_User64.h results in build error ( The library was created by a different version of the compiler ) is there is something I am missing?
The source is provided so you can recompile it with the latest compiler. However, I did recompile this recently (for FSUIPC7), so I have attached this below.
5 hours ago, Mostafa said:I am trying to change a switch which has LVAR: ASD_SWITCH_EXT_POWER using C++ code, so I am using UIPC_SDK_C_version2.
Sorry, but I just don't have the time to provide an example. I have never used most of the provided SDKs and they are provided as-is, and most donated by other authors.
You need to first write the new value to a user offset (e.g. 0x66C0) using FSUIPC_Write, then write the offset address used + the value format (as described in the offset status document) to offset 0x0D6C (again, using FSUIPC_Write), and then the lvar write request, which would be "::ASD_SWITCH_EXT_POWER", to offset 0x0D70 (using FSUIPC_Write), and then call FSUIPC_Process to apply.
Note that the only supported SDK is the .Net / C# one provided by Paul Henty - there is a sub-forum for this interface: https://forum.simflight.com/forum/167-fsuipc-client-dll-for-net/
-
Your log file show s that FSUIPC wasn't even connected to MSFS and was attached when FSUIPC7 was still running:
Quote516 Auto-started via MSFS.bat with DetectToConnectDelayAuto=30, InitialStallTime=15
3266 Simulator detected
33266 Trying to connect...
48719 Trying to connect...
64156 Trying to connect...
79594 Trying to connect...
95047 Trying to connect...
110531 Trying to connect...
125969 Trying to connect...
141406 Trying to connect...
156859 Trying to connect...
172312 Trying to connect...
Nothing is going to work if FSUIPC7 is not connected to the FS.
And please, ALWAYS exit FSUIPC7 BEFORE attaching files.
How long does it take for MSFS2024 to get to the main menu after starting? You may need to trim the start-up parameters - see the Advanced User guide or the followig FAQ entry:
If FSUIPC7 cannot get a connection, this is usually due to other badly behaved add-ons using up all available connections. What other add-ons are you using?
Also, please at least check your log files if you have issues, and always check them before sending them to me. That one is useless.
-
Rather than using LuaValue and event.param, switch to using flags.
Change the event.param call to use event.flag, and add 1 call for each flag used (the flag replaces the feed_value/ ipcPARAM value):
-- -- function to convert to BCD -- function convertToBCD(freq) local cleanFreq = freq:gsub("%.", "") -- Remove decimal (e.g., "109.2" → "0920") local decimalNumber = tonumber(cleanFreq) -- Convert to number if not decimalNumber then return 0 end -- Return 0 if conversion fails local bcd = 0 local shift = 0 -- Convert each decimal digit to BCD format while decimalNumber > 0 do local digit = decimalNumber % 10 bcd = bcd + (digit * (16 ^ shift)) -- Use base 16 shift instead of bitwise left shift decimalNumber = math.floor(decimalNumber / 10) shift = shift + 1 end return bcd end function updateNav1(flag) currentNav1BCD = ipc.readUW(0x0350) -- read the current NAV1 frequency currentNav1 = string.format("%04X", currentNav1BCD) -- convert BCD to number (as string) if flag==1 then -- if turned right, the left encoder (MHz) sends the value 10 to offset 0x0D6C -- the following lines increase the MHz value by 1 MHz and wrap the frequency around, substracting 900, when 117 MHz is reached if tonumber(currentNav1) >= 1700 then newNav1 = currentNav1 - 900 -- currentNav1 will be converted to a number else newNav1 = currentNav1 + 100 end elseif flag==2 then -- if turned left, the left encoder (MHz) sends the value 20 to offset 0x0D6C -- the following lines decrease the MHz value by 1 MHz and wrap the frequency around, adding 900, when 108.95 MHz is reached if tonumber(currentNav1) <= 895 then newNav1 = currentNav1 + 900 -- currentNav1 will be converted to a number else newNav1 = currentNav1 - 100 end elseif flag==3 then -- if turned right, the right encoder (kHz) sends the value 30 to offset 0x0D6C if string.find(currentNav1, "%d%d95") then -- this line checks whether the frequency ends with 95 and ... newNav1 = currentNav1 - 95 -- ... if so, substractss 95 kHz so as to prevent the frequency from carrying (changing the MHz value) when digit wraps. So you can turn the encoder for the kHz value seperately without increasing the MHz value. else newNav1 = currentNav1 + 5 end else -- if turned left, the right encoder (kHz) sends the value 40 to offset 0x0D6C, which for now is "else" if string.find(currentNav1, "%d%d00") then -- this line checks whether the frequency ends with 00 and ... newNav1 = currentNav1 + 95 -- ... if so, adds 95 kHz so as to prevent the frequency from carrying (changing the MHz value) when digit wraps. So you can turn the encoder for the kHz value seperately without decreasing the MHz value. else newNav1 = currentNav1 - 5 end end newNav1_BCD = convertToBCD(tostring(newNav1)) -- convert to BCD ipc.control(65708, newNav1_BCD) -- sending BCD to FSUIPC end event.flag(1,"updateNav1") event.flag(2,"updateNav1") event.flag(3,"updateNav1") event.flag(4,"updateNav1") ipc.log("Nav1 update lua script now running")Then write the flag value (1,2,3 or 4) to offset 0x0D6C, and use the LuaToggle control when writing to offset 0x0D70.
John
-
I can see the issue - I will do some testing here and get back to you,
John
-
Check your InstallFSUIPC7.log file. You will probably see that the installer detected a steam version as you have a UserCfg.opt file in the location used by a steam installation. If that is the case, uninstall FSUIPC7, delete or rename the steam UserCfg.opt file and then re-install and it should detect the MS Store version.
The FSUIPC7 installer determines the version based on the location of this file, and checks for Steam first.
Also, please give your posts and appropriate title, and nothing generic such as 'please help'. I will update this time.
John
-
No, sorry - I don't have the Fenix. Is it the same aircraft or a different version for MSFS2024? Is this for all assignments? How have you assigned - using presets? Are you using the same or different installations of FSUIPC for MSFS2020 and MSFS2024? Have toy looked at the logs to see what is happening?
It could be due to many things (e.g. is the WASM installed in MSFS2024?) and you should check further and at least provide more information, including logs (with appropriate logging activated) and ini files. It could be the configuration, but it could be that the aircraft uses different controls in MSFS2024.
-
You will need to use one of the C SDKs. To update an lvar, use offsets 0x0D70 and 0x0d6C
-
You can start MSFS via steam or however you like. The default auto-start is via the EXE.xml file, although you can select to auto-start via the bat file.
By default, the desktop icon(s) installed by the installer just show a splash crean and call steam to start MSFS. If you are using the EXE.xml auto-start and dont want to use the installed desktop icon to start MSFS, you can opt not to have this installed by unchecking the checkbox at the end of the installation process.
John
-
1
-
-
The easiest way to control an lvar (in P3d with FSUIPC5/6) is to use a macro - see the documentation.
John
-
This video is interesting, and shows how to get the visuals working using Spad.nect and vJoy:
You can also use that to set-up with FSUIPC and vJoy using vJoyOffsets. which would be mapped to a vJoy axis that is assigned in MSFS.
Its a bit of a fudge, as you have to assign a vJoy axis in MSFS, as well as two buttons. You then assign in Spad.next/FSUIPC to control the vJoy axis and buttons. The throttle axis would write its value to an FSUIPC offset (mapped to the vJoy axis), and the prop-pitch range assignments also trigger the vJoy buttons via offsets.I could set that up here and let you know how that works if interested. That set-up uses a Bravo (which I also use on my flight PC), so it has detent buttons on the throttle & prop axes to move into reverse and cut-off.
The set-up would be different if the axes being used didn't have detent buttons (as my X55 throttle I use on my dev set-up). You would either have to use a separate button or maybe an additional axis range to do that.Also, as that post is also a couple of years old, it is not clear if that set-up would still work, but I suspect so as it basically uses MSFS to control the visuals.
-
Testing further, the FUEL_Manual_Override input event works fine to control the manual override lever.
However, I get very strange results when trying to use the ENGINE_Throttle, input event on an axis. Sending any positive value, however small, seems to set the value of 13% and just switches the throttle to the feather side, with 0 switching it back to the taxi side. Basically it is the same as setting the ENGINE_Throttle_Feathering input event to 1.So looks like the throttle visuals still can't be controlled correctly.
On 3/7/2025 at 5:13 PM, pilotjohn said:Sending 8192, will move it back to taxi. So the only thing I can't quite do consistently is switch between low and high idle.
As well as sending 8192, try setting the unput event ENGINE_Throttle_Feathering to 1 which should move it to high idle.
-
1 minute ago, Paul Henty said:
Maybe @John Dowson could consider adding some offsets so programmers can add 'simvar to offset' mappings via the IPC interface, in addition to the myOffsets.txt file.
e.g. write the simvar name, size, type, destination offset etc. to a series of offsets and this would add that mapping until FSUIPC was closed, just as if they had been included in myOffsets.txt.
Currently all simvars are requested during initialsation, after FSUIPC has obtained a connection to the FS. The problem with such a feature is that the whole way that simvars are requested would need to be change, as this would have to allow for updating the data definitions (plus the internal data structures that map simvars to offsets) dynamically, which would be a huge change. This is probably possible but would require a complete re-design of how this currently works, and I just don't have the time (and probably never will) to consider such a change. You should consider just distributing your myOffsets.txt file with the application, or write or update that file when the app is installed.
Of course, there is always a possible issue if the offset was already being used for another purpose. But this would apply when the simvars are requested via offsets as it applies when requested via the myOffsets.txt file.
There is another method that can be used to get the value of any simvar - write the value to an lvar and read the lvar. This involves an extra step in writing the simvar to an lvar, which can be achieved via executing some calculator code of the form:
(A:someSimvar) (>:L:mySimvarLvar)and then read the value from the lvar L:mySimvarLvar. But doing this, you would need to write the a:var/simvar value to the lvar every time before you read the lvar to make sure that it holds the current value, and there would be a slight delay before the updated lvar value would be available in FSUIPC.
John
-
On 3/7/2025 at 5:13 PM, pilotjohn said:
Prop pitch 1 will also move the throttle between TAXI and FEATHER (hi idle) with 8192/-1 (then sets it to -4096, but sending -4096 will complete do a cutoff), and then to low idle if you send -1 again. Sending 8192, will move it back to taxi. So the only thing I can't quite do consistently is switch between low and high idle. And, obviously get the throttle to actually move visually.
Have you tried the input events:
ENGINE_Throttle : range 0-100
FUEL_Manual_Override : range 0-100
ENGINE_Throttle_Feathering: 0 / 1
?I set-up a few buttons to test these, and these DO control the visual position of the throttle and manual override lever:
Quote0=P174,0,CIENGINE_Throttle,0.000000 -{Input Event}-
1=P174,1,CIENGINE_Throttle,13.000000 -{Input Event}-
2=P174,2,CIENGINE_Throttle,50.000000 -{Input Event}-
3=P174,3,CIENGINE_Throttle,100.000000 -{Input Event}-
4=P174,4,CIENGINE_Throttle_Feathering,1.000000 -{Input Event}-
5=P174,5,CIENGINE_Throttle_Feathering,0.000000 -{Input Event}-
6=P101,8,CIFUEL_Manual_Override,0.000000 -{Input Event}-
7=P101,9,CIFUEL_Manual_Override,50.000000 -{Input Event}-
8=P101,10,CIFUEL_Manual_Override,100.000000 -{Input Event}-
This is just for testing, but shows that the visuals can be controlled.
The TBM930 throttle has always been tricky to set-up using a standard throttle controller, and you probably also need to assign a few buttons, maybe for switching to feather and also to engage reverse and enter cut-off. You can most probably achieve something reasonable using a lua script. and assigning your axis to an FSUIPC offset and then embed the throttle logic in the lua script to send on the appropriate input events and FS controls as needed.
I will take another look at this, but I will need to understand and review how this throttle is supposed to work first.
Could you at least share your current assignments and I can use that as a starting point.
John
-
9 hours ago, Andre92 said:
The first supplied ini was from a session where fsuipc worked fine. Sorry, i had the memory leak initially, restarted without problems and then saved the ini.
I think you mean log file, not ini...
9 hours ago, Andre92 said:I increased "maxnumberofcustomevents" because inibuilds used to create an enormous amount of events when they initially released their A310 and later A300. I'll set it back to default.
This is not a problem - but the current max allowed value is 8192, so if you need the additional higher event numbers then set it to that.
But be aware that this parameter defines the maximum allowed number of custom events which are loaded from event files (*.evt). There is no real need to use these anymore but this is still provided for backwards compatibility. What you may need to increase is the MaxCustomControlNumber ini parameter, which defines the custom control number range allowed by FSUIPC. This does need to be increased for some aircraft.Cheers,
John
-
Maybe also see
-
Yes, there are only 4 standard throttle controls/events. However, if the aircraft has 6 engines, then aircraft should provide a way to control them which FSUIPC can use, such as lvars or input events.
You can try FSUIPC7 before purchasing, to see if it suits your needs. There is a trial license available in a post at the top of this form.
John
-
11 hours ago, ark1320 said:
instead of writing ipc.writeUB(0x1234, 0xF2), write ipc.writeUB(0x1234, 0b11110010) ?
Maybe, I don't know though - why not just try it? I don't know if lua supports "0b" for binary, but should be easy to write a quick script to test / check this.
11 hours ago, ark1320 said:I can't seem to find anything that shows how to indicate the number is binary.
Me neither - it would be in the general Lua documentation, not in FSUIPC's documentation. But I would think that it would be 0b, and if that doesn't work then it isn't supported.
John
-
Could you please add the following to the [General] section of your FSUIPC7.ini file:
TestOptions=x800
LogCustom=x16You also have a very high value set for MaxNumberOfCustomEvents (12288). The maximum value for this parameter is 8192.
Shouldn't be a problem (I will test here), but you should reduce that - or is there a need for it to be so high? -
14 minutes ago, shorthauler said:
Documentation for the Lua control function in MobiFlight seems to be a bit thin, I only found this: https://www.mobiflight.com/forum/message/10232.html
It is lacking the LuaValue function.
Yes, as is the FSUIPC offset documentation for offset 0x0D70 (which is where that comes from). As I said, this is an omission error but it works - as I keep saying, you MUST use LuaValue, and not just Lua. Please read the FSUIPC offset documentation if using FSUIPC offsets (via MobiFlight).
14 minutes ago, shorthauler said:I have found that alternating turns of the encoders for MHz and kHz "unfreezes" the frequencies and they do advance instead of just moving one notch back or one notch forth,
But using what - Lua or LuaValue?
14 minutes ago, shorthauler said:I could not assert it through the error logging (problably, because it is not an error), but the reason might be that if turning to increase the value, the feed value is set to N. And when increasing further, the same feed value is being sent.
It is not error logging (errors are always logged), but debug logging you need. This will show you every line executed in the lua script.
14 minutes ago, shorthauler said:Event.param, if I have understood it correctly, monitors if the value changes. But this is not the case when the same value is being sent.
Event.param does not monitor for value changes, but is called whenever LuaValue is called on the script, using the parameter provided, which when called via 0x0D70 will be the value in 0x0D6C.
14 minutes ago, shorthauler said:I will keep trying.
The ONLY thing you need to try is using LuaValue to call the script.
Joystick Inputs Issue with FSUIPC7 and FS2024 (Fenix A320)
in FSUIPC7 MSFS
Posted
I have no idea - just look at the FSUIPC_WASM.log file, if there is one - this will tell you if the WASM is running and if that ini file is being read. If you have no log file (in the WASM persistent storage area, NOT under your Community folder) then the WASM isn't running and that will be your issue.
Why not? Did you read the documentation? If so, what isn't clear about that? You CAN modify that file, but it is NOT recommended, and you should use the one in the WASM persistent storage area (which is NOT there by default - you have to copy the one from the Community folder location to the persistent storage area and then modify it from there). This is all explained in the documentation.
There is no file attached, and there is no point attaching it either. Attach the FSUIPC_WASM.log - that is the file I need to see, preferably with Debug logging activated, but any existing one would to do start with....
Also, why are you using the bat method of auto-start rather than the default (and preferred) EXE.xml method? Why are you starting other programs from the MSFS2024.bat file? It is better to use the facilities provided by FSUIPC to start other programs (and use either the CONNECTED or READY keywords, depending in the program). See the section Programs: facilities to load and run additional programs in the Advanced User guide.