John Dowson

Yes, just checked and its the same for me. No idea why, but I cannot do anything about this, sorry. This application was provided a long time ago by a user and is provided as-is and unsupported. What do you actually want to do? You can log up to 4 distinct offsets using FSUIPCs offset logging mechanism, in hex or otherwise. Alternatively, use the Interrogate panel of FS-Interrogate. John

Plenty of resources on boundary data alignment on the web, e.g. https://learn.microsoft.com/en-us/cpp/cpp/alignment-cpp-declarations?view=msvc-170 But I wouldn't worry about this two much. Just remember that the last digit of the offset address must be wholly divisible by the size of the data you are adding, as this will mean that the address is aligned to that data size.

I cannot explain it any other way. A 4-byyte value MUST start on a 4-byte boundary. So the hex address must end in 0, 4, 8 or C. Those are the 4-byte boundaries. If you add an int to an address ending with 0, e.g. xxx0, then the next address available is xxx4, and an int to that, and the next address available is xxx8, add an int to that, and the next address available is xxxC. 4-byte boundary addresses end in 0, 4, 8 or C. 8-byte boundary addresses end in 0 or 8.

What do you mean? You do not place data - the hex viewer just reads the data and displays the offset values in hex

As it says - the offset address needs to be bound to its size. So, for example if you add a 1 byte simvar to, say, offset A000, the next free offset in that area will be A001. But if you now want to add an int, which is 4-bytes, you cannot add to A001 as that is not on a 4-byte offset boundary. The next position it can be added in will be A004 (the last offset digit needs to be 0, 4, 8 or C, i.e. on a 4-byte boundary).

Check everything is working ok first and send me your files if any issues. I am not sure if the JoyScan file is re-written io joystick re-connection, so the last one you showed me might be out-of-date, and there could be another registry issue.

You should not do this when FSUIPC is running. It looks like this has caused some strange issues....can you delete this from the [JoyNames] section of your FSUIPC6.ini: The quadrant was recognised with the same GUID as your rudder pedals for some reason. Can you check that the power saving/allow sleep setting is disabled on all of your USB hub devices (in windows Device Manager). The most common cause of this issue is that windows has put the devices to sleep. Otherwise, I am not sure what could cause this. The next time it happens, pause the sim and open FSUIPC and see if your throttle assignments are recognised in the Axis assignment tab. Also, set logging for Axes Controls, Events (non-axes controls) and Buttons & Keys. Then un-pause the sim and move the throttles and rudder, and press a few buttons on each device. Then exit and show me the files. Do not unplug and re-connect your controllers. Thanks, John

Thanks, but I think you mean me and my father, Pete, who has now retired. Cheers, John

Looks a lot better... Only one throttle quadrant is recognised, but I think one is attached to the yoke and so the axis/buttons look like they are coming from the yoke. Can you replace your ini with the attached (I have just removed some unnecessary JoyName entries and assigned different letters) and then start P3D/FSUIPC and see if everything is recognised, and if your assignments are still valid. Any issues let me know and re-attach those 3 updated files. Thanks, John FSUIPC6.ini

Please see the documentation - the README.txt and the Installation and Registration guide. If you have re-installed windows, you will need to update to the latest VC++ redistibutables. John

Found this issue and should be fixed in the attached update. This is a long standing problem, I am surprised it hasn't been raised before... Note also that the interval is the minimum interval, and you should generally expect to see the data at a slightly slower frequency than that specified. This is strange and I cannot reproduce this here. If you still get this with this latest update, can you please add FSUIPC offset logging for offset 0x0580 as SA32 - this is the offset that the heading is calculated from. Also please keep the custom logging for the GPS out data that I showed you before. Ok - I took these values directly from the RPY sentence. I have reversed these values for PASHR in the attached update. Did you check on the comma before the checksum? As no other sentences have this, I would rather not include this. However, if you need this, you can add PashrComma=Yes to the [GPSout] and/or [GPSout2] section So can you please try the attached. Any issues, please attach your FSUIPC6.log file, with the GPSOut data logged, and also with offset 0x0580 logged if the heading is still an issue. Thanks, John FSUIPC6.dll

It won't be "recognized" by FSUIPC as a device, as it is a keyboard device. FSUIPC just receives the keyboard input from such devices from windows, and if it is sending keys then they should be picked-up in FSUIPC's keyboard assignment panel. Is this device actually sending any keys? Is there some configuration software that you use to determine what keys this is sending? If you open another app (e.g. notepad or notepad++) does that receive input/key strokes from this devices? Did you check the other button assignment (as I mentioned) on this device? If that has the same problem, it will be a problem with the device. If not, it will be an issue only with that button,

You did - it was the log file that was missing.

Yes - LINDA is a lua interface built on top of FSUIPC's lua facilities. Not necessarily - only if LINDA has a module/lua script that supports that hardware, otherwise you would have to write your own. You should ask about this on the LINDA support forum. The VRInsight MCP works with FSUIPC as we provide support for this device within FSUIPC (see appendix 3 in the Advanced User guide). Why do you want to send me that - it is of no use to me. I will not be adding any special support for this device. No. It is really up to the hardware provider to provide the software for this device. If this is not available, then you would have to see if it can be controlled using the lua com interface, and write your own lua script to handle this. Or maybe check if MobiFlight support this device. No, sorry. John

I will take a look and get back to you. John

Could you please also attach your FSUIPC6.ini file the next time you show me your files. Have you installed any saitek drivers? If so, please remove them and let windows install the default windows drivers. There is certainly something strange going on.... first, the joyscan file shows only 3 HID devices, and all showing the same GUID: And in your registry, there are multiple entries for the yoke with one using the same id as one of your throttle quadrants: And your ini file shows only one throttle quadrant and the yoke detected, missing your pedals and 2nd throttle quadrant: The first thing to do is to switch to using JoyLetters - this helps prevent issues and aids recovery when ids and guids change in the registry. To do this, change the AutoAssignLetters ini parameter in your [JoyNames] section (shown above) from No to Yes. Then run P3D/FSUIPC and exit. This will update your ini to use JoyLetters. After that, you need to clean the registry entries. To do this, first run regedit and take a back-up of your registry, then exit regedit. Disconnect your yoke and throttles, and download and run (i.e. double-click it in windows explorer) the attached regedit script: removeDevices.reg Then reboot your PC, and then reconnect your yoke and throttle. Run P3D with FSUIPC6 - just load an aircraft and then exit. Then show me/attach your updated 3 files - FSUIPC6.log, FSUIPC6.ini and FSUIPC6.JoyScan.csv, John

I don't think the version is the problem, and updating to v6 probably won't fix this, whatever the issue is. I could provide you with a trial/time-limited license if you would like to try it. No - you just need to rename your FSUIPC5.ini to FSUIPC6.ini and your settings will be preserved. John

I've also just tried the GFLeds-G58.lua with the Cessna 172 and it also works for this aircraft, so no need to resort to using lvars. The latest script should work for most aircraft, and for the ones it doesn't you will need to adjust and provide a separate script for that aircraft. For now, I suggest that you just install the script and add it to your general [Auto] section, i.e. [Auto] 1=Lua GFLeds-G58 It will than be started for all aircraft. If it doesn't work for a specific aircraft, you can then look at that on a case-by-case basis. Probably also better to change the name of that script to just GFLeds.lua, as it is not G58 specific (and change the name to match in your [Auto] section). John

As I said, that script uses offsets, so should be valid with all aircraft that use the simvars associated to those offsets. You should just try it. For the aircraft that don't use the simvars associated to those offsets, you will need to look at the lvars instead and adjust the script accordingly, and as I showed in the first lua script I posted (for the Cessna 172). For the yaw damper, try offset 0x0808. Then find the appropriate offset or lvar that holds the state/position of the fuel pumps/alternator, and add the appropriate code to the lua script. I have shown you how to do this now for both when offsets (bits or otherwise) and lvars hold the state of the function that is needed to control the light state, so you should be able to use and adapt those for your needs. I cannot write everything for you - just take a look at the scripts I have provided, as well as the FSUIPC documentation, and you should be able to use and adapt those scripts for any use case / aircraft. John

Please see the attached script. This works for the G58 for all your switches in the order you specified (Landing lights, taxi lights, nav, panel, beacon, strobe, yaw, pitot) except yaw, as I am not sure what that is. Note that this script used the general lights offset at 0x0D0C, and the pitot heat offset at 0x029C. As it uses the general offsets, it should work with all aircraft that use these offsets. For those that don't, you need to find what holds the state to control the light, such as an lvar. The script for the Cessna 172 I posted earlier uses lvars instead of offsets. John GFLeds-G58.lua I have also noticed a difference in the way GF device are detected (I think!). I have two each of the GFP8, GFT8 & GFRP48. These used to be detected as separate devices, i.e. each with a unique joy#. However, now only the GFRP48s are recognised as two separate devices with unique joy ids (or device numbers). Only 1 device number is given to both of the GFP8s and GFT8s, with the button/switch numbers on one going from 0-7, and from 8-15 on the other. Not sure when or how this happened...

Then rename it to be a .lya file... Which "other"? What do you mean by "yaw"? Just create a text document then rename it to a lua file. Then you will most probably have to write a script for each aircraft, although some may be compatible with each other, Alternatively, you could just write a simpler script that switches the leds on when in the up position and off in the down position, but I think that is a lor less useful. I can look at the G58 and give you an updated script for that, or maybe a general script if you prefer that. John

But doing it that way means you need two macro files. Better to leave the parameter out of the macro file, and add it to the button assignment to the macro, and this will then be passed-in, As the Advanced User guide says: John

These were the references I was using - no comma before the checksum: http://receiverhelp.trimble.com/oem-gnss/NMEA-0183messages_PASHR.html https://docs.novatel.com/OEM7/Content/SPAN_Logs/PASHR.htm Are you sure you want this added?

Yes, that seems strange - no other sentences have this additional comma. I have added in the attached: FSUIPC6.dll John

Parameter d is the GPS Quality flag, and e the IMU state flag. You said: Which is why they are always 1 and 4. Do you want me to just change e ( IMU state flag) from 4 to 1? As I previously said, I do not know how to calculate these values so have just hard-coded the values that you asked for.