jaxx
-
Posts
62 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by jaxx
-
-
How I understood it that would only work when each physical axis would be always mapped to the same axis control or if I give every profile its profile specific JoystickCalibration entries.
Maybe I didn't explain it right.
Let's say I have Axis 1-6 and they need their raw values for the 0-Position calibrated to 10, 20, 50, 20, 30, 30.A twin-engine GA aircraft will use Axis 1 and 2 for Throttle 1 and 2, so I calibrate in FSUIPC those Throttle 1 and 2 axis controls to the 10, 20 min-position.
But now I change to a twin-engine airliner, this now uses Axis 3 and 4 for Throttle 1 and 2. FSUIPC will use the same calibration values for Throttle 1 and 2, even though they are now different physical axis and would require a different calibration (50, 20).
Only chance I see to do this with FSUIPC would be to have a profile specific calibration section for every aircraft profile, even if many of those would be 1:1 duplicates (e.g. every Twin-Engine-GA aircraft profile would have the same duplicate profile specific axis calibration, as I don't think you can reference an existing profile specific axis calibration in multiple profiles).
For me that just gets a bit to confusing to maintain. -
I thought as much.
I have now found a tool called DXTweak2, with this I can at least line up a calibration points around the ends and a center point so all axes have the same physical deadzone. That already helps keeping it within an error of around 1% ingame.
-
Is there a way to calibrate raw joystick axes like it is already possible with assigned axes like e.g. throttle with min/max and "Sync Pos"?
I'm asking because the axes on my Honeycomb Bravo are a few millimeters off so throttle is not the same value at the same position, sometimes 2-3% difference.But due to different configurations the axes for Throttle 1 and 2 are different physical axes between different planes. I would need a profile specific JoystickCalibration for every single plane.
It would be nice if there would be a way to pre-calibrate/sync all 6 axes before they are assigned to FS-axes.I tried some calibration tools for DirectX, but they seem to be quite old and not really working with Windows 10.
FSUIPC probably doesn't have this option, but maybe someone knows a tool or Windows option to calibrate the axes of a DX device on a lower level?
-
Sure, no problems.
At the moment it's just an annoyance having to check if FSUIPC has crashed after a plane change or while shutting down and then having to kill and restart it.
I'll post again if I see it crashing during "normal" operation and not just on script termination. -
Hi,
I had random crashes of FSUIPC when using button polling on my Honeycomb Bravo.
When FSUIPC is killing the LUA script (on exit or on a "reload" when switching between airplanes) sometimes FSUIPC crashes with this message:188765 Lua threads being terminated: 188765 9 = "G:\MSFS\FSUIPC7\lua\test.lua" 188953 LUA: "G:\MSFS\FSUIPC7\lua\test.lua": killed 189515 LUA.0: Crash C0000005 at 7FFB15A75C57: ""
As you can see at the "9 =" this was the 9th aircraft switch, it usually happens between 1 and 15 tries. The same can happen when closing FSUIPC. When it happens FSUIPC then has to be killed via the task manager.
I simplified my LUA to this small code, and it still happens:
VendorIdHC = 0x294B -- Honeycomb vendor id ProductIdBravo = 0x1901 -- Honeycomb Bravo product id Pollrate = 25 -- Polling rate in number of polls per second devB, rdB = com.openhid(VendorIdHC, ProductIdBravo, 0, 0) function Poll(time) -- if devB ~= 0 then --PollBravo() -- end end event.timer(1000/Pollrate, "Poll")
This is the only script I used for testing, no other script running. Script startet using the [Auto] block in FSUIPC ini.
As you can see I removed the complete polling logic and it still happens, the Poll function is basically just there to keep the script running.It only happens with the Honeycomb Bravo, not the Alpha, where everything works fine with basically the same code.
I also removed the MSFS addon that controls the LEDs on the Bravo, thinking it might interfere, but no, same behavior with or without.In the log of the LUA script itself everything looks like it was terminated fine:
********* LUA: "test" Log [from FSUIPC version 7.0.3] ********* 28203 System time = 24/12/2020 11:13:52, Simulator time = 10:13:37 (09:13Z) 28203 LUA: beginning "G:\MSFS\FSUIPC7\lua\test.lua" 39766 >>> Thread forced exit (ipc.exit or os.exit) <<< 39766 System time = 24/12/2020 11:14:03, Simulator time = 10:13:48 (09:13Z) ********* LUA execution terminated: Log Closed *********I tried closing the com-handle manually with
function on_exit() com.close(devB) end event.terminate("on_exit")
But this only made it worse, with this it crashed consistently on the first try every time, even without logging the LUA.0: Crash line in the log.
I tried with FSUIPC 7.0.2 and 7.0.3, same result with both.
Also with Lua debug logging there is no more information logged regarding the crash.
Maybe you could provide a version with more debug logging enabled so I can support you better finding the cause for the crash?
Thanks,
Jan -
24 minutes ago, John Dowson said:
Btw, are you now using MSFS 1.12.13.0? I've had some reports of FSUIPC7 crashing with this version when using those Honeycomb devices and lua (HidDemo.lua), but am still awaiting details.
Since the latest version released I just worked on setting up the throttle, no long flights or anything.
But I noticed with the new Version the ingame profile for the HC Alpha was filled again with the default actions, which is not good for the always-on-toggles.
E.g. when the magneto is set ingame, it will fire constantly. In the FSUIPC event log you can then see the Magneto-Off event being fired all the time. Same with e.g. the Alternator-On toggIe don't now if this can cause problems, I removed the assignments again from ingame as I only use FSUIPC for any always-on toggle.
I'm also using HID polling for the Magneto on the Alpha, so in general it works, haven't looked at the HidDemo though. -
55 minutes ago, John Dowson said:
I should be getting a Honeycomb Bravo soon (according to Honeycomb....), so I may use your lua once it arrives.
I'm still in the progress of setting it up, just got it yesterday. Like with the Alpha Yoke I think I'll need quite some special handling in LUA as there are again buttons outside the 32-button range and to get it working with automatic profiles for the different commercial/GA lever setups.
But all in all it's great, much better than the simple Saitek Throttles I had before. -
1 hour ago, John Dowson said:
Have you looked at using the Throttle Reverse Thrust Toggle control? If that is supported in the aircraft you are using, this allows you to use the full range of your throttle axis for reverse thrust when set.
If I see that behavior correctly it would just use my forward throttle as reverse throttle while toggled? That is not exactly what I wanted.
I have the Honeycomb Bravo which has dedicated reverse throttle levers like in a Boeing, but they are not axis but basically a toggle button.Setting for this button "full reverse on press and throttle 0 on release" was working from the beginning, but I got those slight problems when I wanted to prevent engaging reverse throttle when I'm not near the bottom with my throttle lever and prevent setting throttle to idle on releasing the button when I'm already in positive throttle.
I'm using this now which works great:function reverseThrottle(readOffset, writeOffset, downup) pos = ipc.readSW(readOffset) if downup == 1 and pos <= 100 then ipc.writeSW(writeOffset, -4096) elseif downup == 0 and pos < 0 then ipc.writeSW(writeOffset, 0) end end function reverseThrottle1(joynum, button, downup) reverseThrottle(0x088C, 0x089A, downup) end function reverseThrottle2(joynum, button, downup) reverseThrottle(0x0924, 0x0932, downup) end function reverseThrottle3(joynum, button, downup) reverseThrottle(0x09BC, 0x09CA, downup) end function reverseThrottle4(joynum, button, downup) reverseThrottle(0x0A54, 0x0A62, downup) end event.button(HCB, 8, 3, "reverseThrottle1") event.button(HCB, 9, 3, "reverseThrottle2") event.button(HCB, 10, 3, "reverseThrottle3") event.button(HCB, 11, 3, "reverseThrottle4")
-
Hi,
I'm trying to create an offset condition so that is only true while I'm in reverse throttle.
The obvious 1=W088C<0 UB,8,C65820,0 -{THROTTLE1_SET}- does not work, and the manual also says All values are treated as unsigned..
But I also tried W088C&F000=x1 or W088C>F000 or even W088C>16384 which I thought should work if the value is treated as unsigned.Any idea if this is possible?
Thanks
jaxxEDIT:
Ok, the problem might be somewhere else. I get it working in some conditions, but it seems the release action is not getting executed when the button is releases.
With this setup:
0=PB,8,C65820,-4096 -{THROTTLE1_SET}-
1=UB,8,C65820,0 -{THROTTLE1_SET}-
When the button is pressed (and held down) reverse throttle is set.
When I do nothing else and release the button throttle goes back to idle.
BUT: When I press/hold the button and set reverse throttle and then increase the throttle manually (via axis or in the VC) and then bring it back to idle and then (via the VC) bring it into reverse throttle, all while the button is still held down, when I then release the button I would expect the throttle to go to idle from reverse, but it doesn't do anything.EDIT 2:
Seems setting the throttle to 0 is not working reliably when the throttle is somewhere in reverse. Same behavior from Lua. I'm now writing to the offsets with Lua Events and everything is working fine. :) -
For writing I'm using
offset.WriteOnly = true; offset.ActionAtNextProcess = OffsetAction.Write;
If I remember correctly WriteOnly alone was not enough when the value I set to the offset object was 0. Probably that was not registered as a change from the default value and to force it being sent to FSUIPC I set the ActionAtNextProcess.
-
I configured my hardware buttons with MSFS to control pushback and then when I tried the setup also with P3D it didn't work there. It seems the offsets for read and write pushback states are a bit switched on MSFS.
E.g. when I'm reading 31F0 I get '1' for tail left and '2' for tail right.
But to actually trigger the pushback I have to set 31F4 to '2' for tail left and '1' for tail right, so '1' and '2' seem to be swapped on 31F0 and 31F4.
And when I set it up this way it did work in MSFS, but not in P3D, where it looks like it is not switched.This is with FSUIPC 7.0.2.
In the offset list it says the status should be the same between those offsets, so It looks like its wrong for MSFS.
Is this something that can be swapped in FSUIPC? -
Thanks,
I tried it without a cache, but due to the SDK of the hardware I'm using that was not really feasible. Basically every item that is currently shown on the display is represented by an object that is only created while it's visible and then destroyed again, due to this lifecycle it would create thousands or more offsets if I would create them when needed. Also the Offsets are dynamic and can change on the fly if the user changes the settings.
So now I'm using a cache where other instances can subscribe/unsubscribe to when they want to listen on an offset and this also takes care of the polling, only having offsets connected that have a listener and notifying its subscribers only if one of the offsets they want to listen to has changed.
That is for monitoring offset, for offsets that I need to read or write directly on a user interaction I'm now just using a dedicated group that I use for a single read or write Process and then delete again.
jaxx
-
1
-
-
The Hz/int offsets are already working for reading, for writing a 8.33 frequency I'm using a workaround by setting the frequency to the nearest lower 25kHz frequency via the standard radio offsets and then calling the control for radio increase until it matches the correct 8.33 frequency. This works quite well.
Simplified example based on C#, but should be easily adaptable to LUA or any other language:
double freq = 122.385; // example freq int freqKhz = (int)(freq * 1000); // 122385 int nextSmaller25 = (freqKhz / 25) * 25; // 122375 int remainder25 = freqKhz % 25; // 10 int steps = remainder25 / 5; // 2 if (nextSmaller25 >= 118000 && nextSmaller25 < 137000 && steps <= 3 && remainder25 % 5 == 0) // is valid 8.33 freq? { string legacy4digit = nextSmaller25.ToString().Substring(1, 4); // 2237 => write legacy4digit as BCD to COM offset (e.g. to 0x311A for COM1 standby) for (int i = 0; i < steps; i++) // 2 times { => call control for radio fract increase, e.g. 65639 (COM_RADIO_FRACT_INC) for COM1 } }
-
1
-
-
Hi
When I have to create offsets dynamically (from user input) and I have multiple offset with the same address and size, will this result in duplicate calls to FSUIPC and should I manage the offsets in a cache?
Thanks
jaxx -
On 9/11/2020 at 11:49 PM, Pete Dowson said:
Understood. But no matter what the aircraft it always seemed wrong to have control axes which cannot reach the full range of the surfaces they control. I realise you seldom need those extremes, but there may come a day ...
I've always thought that the method of flattening (making less sensitive) the main areas of normal use (centre and middle ground) at the expense of very steep and sudden changes at the extremes was the best compromise.
If you draw a graph of what you achieve by chopping off the extremes, as you will be doing using Thomas's method, you'll probably find it very similar to the rather flattened centre/mid zones you get using my method, just with more movement needed.
Of course, i suppose on some joysticks the amount of movement you have in the first place isn't really that great, so i'd concede the point there. On the other hand with a decent yoke with full fore/back, left/right movement capability such measures are definitely less needed, and probably not needed at all.
Pete
I think the problem is that the effect of the control surfaces is way higher than realistic. The axis<->control surface mapping seems to be completely ok and linear if you look at the ingame movement in relation to the axis. But the aircraft reacts too sensitive when the control surface is just slightly moved.
-
2 hours ago, Torkermax123 said:
start L:\FSUIPC7\FSUIPC7.exe
start C:\Windows\System32\cmd.exe /C start shell:AppsFolder\Microsoft.FlightSimulator_8wekyb3d8bbwe!App -FastLaunchNo need for calling cmd.exe, calling start shell:AppsFolder\Microsoft.FlightSimulator_8wekyb3d8bbwe!App -FastLaunch is sufficient.
Also when you have spaces you need to quote and then the start command needs an extra quoted parameter, like start "" "G:\Flight Simulator\FSUIPC7\FSUIPC7.exe".-
1
-
-
2 minutes ago, John Dowson said:
I'm not sure, which is why I am asking for you to check. is that the config you have when you experience this issue? If so, then no. But if your assignments were previously different, then please check again with those assignments (presuming each of those axes is also calibrated in FSUIPC7 - if not, do that first).
I was using that config the whole time and also do not have any axis mapped in MSFS directly. But I also only had the disconnects very rarely.
-
1 hour ago, John Dowson said:
Could those who experience the disconnect due to the SimConnect issue (with TransmitClientEvent failures) please check their ini/assignments. It seems that there is an issue when assigning to the FS control (i.e. not direct to FSUIPC calibration) but then calibrating in FSUIPC7. If you do this, can you either update to 'direct to FSUIPC calibration' and calibrate, or if you sent to the FS directly, then delete the calibration in FSUIPC7. Thanks.
So it's fine when it's configured like this?
[Axes] PollInterval=10 RangeRepeatRate=10 0=AX,256,D,7,0,0,0 -{ DIRECT: LeftBrake }- 1=AY,256,D,8,0,0,0 -{ DIRECT: RightBrake }- 2=AR,256,D,3,0,0,0 -{ DIRECT: Rudder }- 3=BX,256,D,1,0,0,0 -{ DIRECT: Aileron }- 4=BY,256,D,2,0,0,0 -{ DIRECT: Elevator }- 5=CZ,256,D,4,0,0,0 -{ DIRECT: Throttle }- 6=CU,256,D,5,0,0,0 -{ DIRECT: PropPitch }- 7=CV,256,D,6,0,0,0 -{ DIRECT: Mixture }- -
16 hours ago, ptimale said:
my problem is that the left, both, start position is not recognized in fsuipc7
I'm not from Joy # XXX Btne # XXX
for these three positionsThat's because Magneto left, both and start are outside of the 32-button range supported by the default assignment options.
You can have a look at my solution on how to handle all always-on toggle buttons (including all magneto positions) of the Alpha in FSUIPC:
-
1
-
-
Here are some more error logs.
-
I put the SimConnect.ini directly in C:\Users\<username>\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalState\ (MS Store installation) and it's creating SimConnect log files in the path I defined.
Though since I'm logging I didn't get any disconnects (only had 2 in total before that).
-
What is the FLT UNC Path?
In the FSUIPC7.log I only see a FLT path = and a FS path =
172 System time = 05/09/2020 14:05:09 172 FLT path = "C:\Users\<username>\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalState\" 187 ------------------------------------------------------------------- 234 Registered HotKey 'InvokeFSUIPCOptionsKey' (key=0x46, modifier=0x1) 281 FS path = "G:\MSFS\Microsoft Flight Simulator\" -
Here is my solution to map all toggle switches on the Honeycomb Alpha via FSUIPC to prevent the bugs that happen when always-on switches are bound in the game itself.
Landing lights and strobes can be mapped directly to on/off, all other toggles require special handling in the lua script.
Some notes on the special handling:
- State of a single battery can not be read. Only the master state which is 1 when at least one battery is on. This means if the switch is in the off position and at least one battery is on, switching the switch on will not switch the remaining batteries on. But after one on/off cycle the switches should be synced.
- Alternator should work correctly, toggling only those which are not already in the new state.
- For avionics 1+2 there are no separate controls, so 4 keyboard keys must be mapped in the sim itself for 1&2 and on&off and then the lua script will send those buttons when the switch is pressed.
- The lights beside landing & strobes need to be set via offset. Setting them via the FS controls leads to a race condition between reading the offsets and executing the controls when switching the toggle switch very fast.
-
As half of the magneto states are out of the standard 32-button range the remaining states have to be polled via the lua script.
But putting those and virtual buttons and then just mapping those and the real buttons to the controls does not work correctly. There will be a race condition where, when quickly switching from the virtual button part to the real button part the virtual button will be registered later putting it in the wrong position (e.g. quickly turn from "BOTH" to "R", the dial will in some cases jump back to "L", because the virtual button of "L" is registered or handled after the real button of "R"), even when polling every 1ms.
Because of that instead of mapping directly to the pressed button I only register a magneto change and then determine which button is currently in the pressed state, starting with the real buttons to avoid the race condition.
-
1
-
12 hours ago, Dave March said:
What it actually says about the simconnect issue is 'Significant FPS drop when using Simconnect should no longer affect the experience'
So they are not saying they'll fix the FPS drop, just that it no longer affects the experience 🤔
Maybe they'll add something even worse so you'll no longer notice the Simconnect issue... 🤪
Transponder Offset 0x0354 No Longer Working?
in FSUIPC7 MSFS
Posted · Edited by jaxx
I can confirm that I can no longer write the transponder code via 0x0354. But reading still works for me. (Using FSUIPC 7.06)
Edit:
Just for clarification on reading. When writing a value to 0x0354 it is written to the offset (and consecutive reads will return the value written), but it is not propagated to the sim. When reading from 0x0354 the value is only updated again from the sim when I change it from within the sim.