Jump to content
The simFlight Network Forums

jaxx

Members
  • Content Count

    23
  • Joined

  • Last visited

Everything posted by jaxx

  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
  2. 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.
  3. 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".
  4. 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.
  5. 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 }-
  6. 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:
  7. Here are some more error logs. DisconnectLogs.zip
  8. 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).
  9. 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\"
  10. 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
  11. jaxx

    Massive FPS Drop

    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... 🤪
  12. Is there even a standard location for flight saves? When saving/loading I get a standard file selection dialog and I can save to/load from anywhere.
  13. jaxx

    Massive FPS Drop

    Yes, there's something really wrong with the SimConnect connection (e.g. vPilot has the same issues). More than the reduced FPS it's basically unusable due to stutter, as you can see in the attached screenshot (please ignore the fact that I'm lying upside down in the streets of New York 😁). You can see on the graphs on the left side the moment FSUIPC connected. Average FPS drop from 40 to 20, but it's much worse than stable 20 FPS. On the right side the "Manipulators" graph was a steady, green block before the connection. Other than that FSUIPC is working really well for what I tested so far. The one special hardware I have that uses FSUIPC for its displays and buttons seems to work just like in P3D. I really hope Asobo fixes the SimConnect issue fast.
  14. I'm not sure what you mean by this, as far as I know Windows only allows one window/application from having the active focus?
  15. Hi, what's the best practice to spoof reads of an offset variable? Some fixed gear planes report always "gear down" and I don't want the gear down indicator on my panel lit when using those planes, so at the moment I have the following in the profiles' lua of the affected planes: function spoof_gear(t) ipc.writeStruct(0x0024, "1UW", 0x0BEC, "1UW", 2, "1UW", 0) ipc.writeStruct(0x0024, "1UW", 0x0BF0, "1UW", 2, "1UW", 0) ipc.writeStruct(0x0024, "1UW", 0x0BF4, "1UW", 2, "1UW", 0) end function cleanup() ipc.writeStruct(0x0024, "1UW", 0x0BEC, "1UW", 0) ipc.writeStruct(0x0024, "1UW", 0x0BF0, "1UW", 0) ipc.writeStruct(0x0024, "1UW", 0x0BF4, "1UW", 0) end event.timer(1000, "spoof_gear") event.terminate("cleanup") I found offset 0x0024 and its usage in the offset list and I'm not sure if using a timer there is the best way, but the spoofed values always reset after a few seconds. I know there is event.offset that fires when an offset changes, is there also an event that fires on an offset read where you could spoof the read result? In the documentation I didn't see something like that... jaxx
  16. No, it is still using SerialFP, but something has changed since I first used it years ago. I remember it needed some manual tinkering with the COM port configurations and it was not easy to set everything up (I can't really remember what I had to do exactly to get it running). But soon after that when I used a newer software version it worked out of the box without needing any manual configuration. I also don't have to do this VRi-device configuration from the FSUIPC advanced users guide, it just works. That's why I thought those were for that old manual configuration (of course I can't speak for other device models).
  17. Maybe I should clarify what the device does. It is an VRinsight M-Panel. From what I can see from the FSUIPC logs it writes offsets (the values from the "FSUIPC5 Offsets Status.pdf" documentation) to FSUIPC when I press a button, dial in a number etc. But they (the natively supported offsets) are hardcoded and I cannot change them. In the configuration utility I can choose either a standard keybind (like ALT+X) or a "FSUIPC Control": All custom IDs/Values set in that way will be written to FSUIPC using the "3110" offset ("Operates a facility to send any ‘controls’ to Flight simulator."). The GUI also prevents entering any ID below 65535 and the configuration file generated by the GUI is a binary file, so not easy to edit without the GUI. Sidenote: Even in the default/hardcoded state it does not use dedicated FSUIPC offsets for every action, some are just send via offset "3110", just like the custom changed ones. PS: I've also seen the VRinsight specific documentations for lua but I don't know if they are applicable (at least for the M-Panel) as they seem to be based on the deprecated method of directly configuring VRi devices with COM ports etc. in FSUIPC. The drivers (at least for the M-Panel) work out of the box with FSUIPC for many years now. Jaxx
  18. Thanks for your answer, but I'm not sure how to do this with the restrictions of the configuration drivers of the hardware (from VRinsight) I use. For 1: How would I link it to the buttons of the device, it will only let me set a 5-digit decimal greater than 65535 plus a single value that is send as FS Control to FSUIPC. (Only other options would be normal keyboard shortcuts and there I see a greater risk of some key-bind conflicts with the flightsim or anything else). For 2: Basically the same problem as with 1, as far as I understand the offsets are not the same as FS controls, and even if they were the range you provided would be less than 65535 in decimal and the VRInsight software would not accept that value. EDIT: Do you mean intercepting the default Offset codes the device sends to FSUIPC when there is no custom config? The software sends the control codes through offset 3110 (not only the custom ones I made, it also uses it this by default for some actions and for some actions it uses "native" offsets. When I now listen to those offsets manually, like with event.offset, will it suppress the default action for this?
  19. Hello, is it a problem when I use undocumented FS Control IDs as trigger events for Lua scripts? I have hardware that I can configure to send any 5 digit decimal >65535 on button presses, dials etc. But some planes I have only really work well when using L:Vars (e.g. the A2A Comanche with its 3-position gear switch does not really work with the FS control gear up/down events from the 2-postion switch on my hardware. When I use the standard FS Controls those don't seem to get suppressed when processing in lua. Is it ok to use undocumented FS control codes for this (e.g. 78001), or are those used for internal stuff and will cause problems? Like doing this: function gear_up(controlnum, param) ipc.writeLvar("L:LandingGearLeverPos", 0) end function gear_down(controlnum, param) ipc.writeLvar("L:LandingGearLeverPos", 2) end event.control(78001, "gear_up") event.control(78002, "gear_down") Is that ok? I mean it seems to work fine, but I don't know if there are any side effects. Thanks Jaxx
  20. I think I have the problem described in this thread as well wit my VRInsight M-Panel, or at least a very similar one. The autopilot buttons (only the on/off buttons) stop working after a while (not really reproducible for me), everything else continues to work just fine. I get the same "DATA_ERROR" messages in the log. After reading this thread I've noticed in the log that by default it sends the controls with 4 byte writes, whereas if I manually map e.g. <FSUIPC_CTL:66103/0> & <FSUIPC_CTL:66104/0> for AP ALT ON & OFF in the VRI Keymapper to the buttons it sends 8 byte writes: Error: 1373344 WRITE repeated 1 times 1373344 WRITE0[848] 07D0, 4 bytes: 01 00 00 00 .... 1373344 Exception 20 "DATA_ERROR", Ref 4079, Index param 1 on write SetData for "AUTOPILOT ALTITUDE LOCK" 1373844 Exception 20 "DATA_ERROR", Ref 4081, Index param 1 on write SetData for "AUTOPILOT ALTITUDE LOCK" Default write: 767000 WRITE0[3332] 07D0, 4 bytes: 01 00 00 00 .... 767000 *** EVENT: Cntrl= 66103 (0x00010237), Param= 0 (0x00000000) AP_PANEL_ALTITUDE_ON 767516 WRITE0[3332] 07D0, 4 bytes: 00 00 00 00 .... 767516 *** EVENT: Cntrl= 66104 (0x00010238), Param= 0 (0x00000000) AP_PANEL_ALTITUDE_OFF Manually mapped write: 948203 WRITE0[4480] 3110, 8 bytes: 37 02 01 00 00 00 00 00 7....... 948203 *** EVENT: Cntrl= 66103 (0x00010237), Param= 0 (0x00000000) AP_PANEL_ALTITUDE_ON 951750 WRITE0[4480] 3110, 8 bytes: 38 02 01 00 00 00 00 00 8....... 951750 *** EVENT: Cntrl= 66104 (0x00010238), Param= 0 (0x00000000) AP_PANEL_ALTITUDE_OFF If I understand this thread correctly the problem should be solved if I don't use the default but map every button manually so they are using 8 byte writes? Or is the new version you are working on supposed to fix this exact issue?
  21. 24€ before tax. Which, depending on your country, including ~20% tax is around 29€.
×
×
  • 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.