Jump to content
The simFlight Network Forums

jaxx

Members
  • Posts

    62
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by jaxx

  1. 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.
  2. 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.
  3. 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.
  4. 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?
  5. 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.
  6. 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
  7. 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.
  8. 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.
  9. 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")
  10. 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 jaxx EDIT: 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. :)
  11. 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.
  12. 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?
  13. 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
  14. 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 } }
  15. 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
  16. 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.
  17. jaxx

    Starting FS2020

    No 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".
  18. 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.
  19. 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 }-
  20. That'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:
  21. 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).
  22. 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\"
  23. 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. FSUIPC7.ini (partial) AlphaToggles.lua
  24. 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... 🤪
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.