Jump to content
The simFlight Network Forums

Luke Kolin

  • Content Count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About Luke Kolin

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  • Location
    Atlanta, GA

Recent Profile Visitors

2,386 profile views
  1. I have the Honeycomb Bravo throttle quadrant, and I use the software for configuring the lights and some of the buttons (specifically, the PMDG autopilot integration). However, there's nothing stopping you from using it as a regular joystick with FSUIPC. Cheers! Luke
  2. There are four areas I recognize I am ignorant in and leave it to the experts - thread synchronization, dates/times, encryption and character encoding. 😄 From what little I know, UTF-8 and UTF-16 should be a superset of ASCII, so regular ASCII characters should be encoded the same way in all three. It should a simple modification to change the signature for that function and any comparisons it does, then see what happens. I'd be slightly surprised if that's all it took to make it work, but even more surprised if that broke the ASCII case. YMMV, of course. Cheers Luke
  3. If I can load it into VS2019, I'd be willing to look at it. My point is that your challenge is upstream, when you load the strings out of the BGL. I suspect (being optimistic) it might be enough to either load the strings as wchar_t* instead of char* (or cast) and then have your encoding function that you shared here operate on *wchar_t instead of *char. The challenge is going to be how you read from the BGLs, but I suspect it's all bytes and the cast should be OK. If you want a low-effort experiment, change the function signature of your encoding function to take wchar_t* instead of char
  4. Stop mucking about with char*. Seriously.... these aren't ASCII strings and probably everything is a wchar_t or LPWSTR/LPWCSTR (which is a pointer to a wchar_t). What is the character encoding in the BGLs? Given how P3D has moved to Unicode I suspect that they are UTF-8 but you'll need to ensure that you are reading them as Unicode strings and then doing your translations on wchar_t variables, not chars. Cheers Luke
  5. Pete doesn't realize it yet, but he's going to go insane - or in a few years, John will. 😄 These are WCHAR or wchar_t typedefs, not byte arrays or char pointers. I'd work with them as such if possible. Cheers Luke
  6. To paraphrase Dorothy, "Toto, I don't think we're in ASCII any more." You're likely to see that 1:1 byte/character mapping for most ASCII characters, but once you get out of that world all bets are off. I'd check the SDK to see what character encoding they are using in the BGLs - I suspect it is UTF-8 but you really need to be sure. If it is, you can probably just do the standard copy of bytes but I expect there are a number of Visual C constructs that treat them as Unicode strings rather than ASCII byte arrays. From there, instead of a BOM I would just add the encoding to the XML header.
  7. The previous message has my INI/LOG files from the first run, here is the second. FSUIPC6.ini FSUIPC6.log
  8. Sorry to bump, but there is definitely something wrong here, or at least non-intuitive. I am used to not having the yoke plugged in during pre-flight, so I forgot to attach it. After the sim was running for a few minutes, I plugged it in. It was detected, and matched my Joystick letters. Except none of my axis or button assignments were recognized by FSUIPC! They appeared to be visible in the INI file - neither my general button assignments (trim up/down) or aircraft-specific ones (LUA) were visible in FSUIPC assignment, nor were the elevator/aileron axes. I then restarted the sim, w
  9. I am certainly missing something. I want to assure both of you that I am not trying to be difficult (my wife says that's because it comes naturally!), rather as I am assigning more and more controller functions through FSUIPC and things aren't behaving as I expect I want to understand the system better to debug it without coming cap in hand here every time. I assume that the GUID will change depending on the port, which makes sense because it's likely a combination of device properties and the port which one would need to support multiple instances of the same type of device, connected to
  10. Now I'm a little more confused. I tried again, starting with the yoke disconnected. When I attached it, all worked. I then as an experiment disconnected it, then reconnected it to a USB3 port on the front panel. The axis assignments didn't appear to work - after I shut down P3D I get the following in my FSUIPC6.INI: [JoyNames] AutoAssignLetters=No T=Bravo Throttle Quadrant T.GUID={E2A82AF0-4F72-11EB-8001-444553540000} P=CH PRO PEDALS USB P.GUID={8AE67BE0-FD72-11E8-8002-444553540000} Y=Saitek Pro Flight Yoke Y.GUID={D2E11750-88B0-11EA-8001-444553540000} 1=Saitek Pro Flight Yoke 1.GUID={8AE6
  11. To give you some context, I almost always start the sim with the throttle and pedals connected (they are out of the way and stay connected 100% of the time), then once preflight is done I connect the yoke since it sits in front of my keyboard. When things didn't work, I disconnected and reconnected the yoke to see if that made a difference. It didn't. I believe the log I sent you should be consistent with that action. I did a slightly different test (for an unrelated reason, I started working on some in-progress code) with all devices connected. Apologies - it uses a different aircraft bu
  12. To add, I noticed this because my axis assignments for the throttle quadrant and pedals appeared OK, but the yoke did not. When I opened up the FSUIPC axis assignment dialog and moved the yoke, it said the axis was unassigned. Cheers! Luke
  13. I have a setup with a Saitek Yoke, CH Pedals and a Honeycomb throttle. I have switched to using JoyLetters (Y, P and T) instead of numbers because FSUIPC seems to forget about my yoke, or renumber. Today I noticed the same thing, when I plugged in the yoke after starting up p3Dv4. I am enclosing the relevant files. Why are the devices being listed twice? Cheers Luke FSUIPC6.ini FSUIPC6.JoyScan.csv FSUIPC6.log
  14. Ah, that sounds like what I need. Shouldn't be too difficult to retrofit. Thanks! Cheers Luke
  15. I have a LUA function that listens for parameter changes using event.param(functionName). My understanding is that if I send the same parameter over and over again the function will not trigger, since the param value hasn't changed. Right now I'm setting the parameter to zero in my button release and treating a zero as a NOOP, but I'm curious whether the function itself can modify the parameter value. The documentation doesn't seem clear, or my brain is too small. 😄 Cheers!
  • 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.