Pete Dowson

Nearly my bedtime here. At my age, 76, I don't wait tll midnight. In my younger days i used to work on programming till 3 or 4 am. My most productive hours! Can't do that any more! Weird but winderful, eh! Now try not to change anything! As if! everyone likes changing things. Hopefully though not so disatrously next time! Oddly enough it's precisely those aircraft which don't much like how FSUIPC handles throttles. The other controls are okay, but most folks say you need to assign throttles to the normal Sim controls (Axis ThrottleN Set) and avoid calibration in FSUIPC. That's basically the same as assigning them in the Sim in any case. So the only advantage of doing so in FSUIPC is for the Profiles. The theory is that these aircraft do their own interception of the throtle inputs and that the feeding of controls in from FSUIPC conflicts with those values, making them behave erratically. this doesn't seem to happen with the other flight controls though. Pete

John referred this to me, since it is for FSUIPC4 not FSUIPC5. I've sent you an email. Pete

Sorry, i'm not fully understanding. What "string"? Can you give me an example? Macros don't trigger themselves. You assign them to buttons or key presses. There are event functions in Lua which can trap those. But surely if you want an offset changed instead of the mouse click to be emulated, why bother with the mouse macro in the first place? event.offset will trigger when an offset is changed. You can write to offsets using the ipc library functions. Please refer to the Lua library document. Controls are not Offsets and vice versa. Offsets provide values and can, like controls, trigger actions when changed. Some of those actions may actually use controls, internally to FSUIPC, but many don't. There are many offsets which provide or change values which have nothing to do with controls -- eg, all the Weather stuff. The EVENT logging is just that. It sees the event being triggered in the Sim, no matter whaere it came from (that isn't discernible in any case), and since it is only an event, a transient thing, what offset gets changed as a result is also unknown. One event might cause many offsets to change (eg throtle changes, flight control operation, etc). Even something seemingly simple like AP_MASTER will likely change many things . To determine the state of the aircraft, indeed the entire sim, you look at offsets, and the offset list is the reference for this. To operate the sim you use controls or events, or in some cases, writes to offsets. Pete

What Wideclient issues? Did you put the ServerIPAddr and Protocol parameters into the INI as suggested originally? Pete

Just delete the INI file. All its settings are there. But really, as you haven't done any assignments yet, this won't really change much. Joystick devices are re-scanned every time it starts up, and also whenever you go into the assignments tabs, and when it detects a new USB device connecting. That implies that P3D doesn't see your controls either, nor presumably Windows. FSUIPC is not necessary to use controls with P3D. It never has been. It provides additional options. You can even calibrate controls in FSUIPC without making assignments through it. So can you explain why your Sim is not playable? On your first post in the thread you said "After replacing a faulty USB Hub (to which all my FS devices were plugged into)". I assume that new hub is powered? If not devices like the Warthogs won't work properly. Furthermore, devices like that which I've had (brief) experiences with need a lot of power, often not supplied by the cheaper powered hubs. Also, is the Hub plugged into a USB2 (black) socket on the PC, or USB3 (blue). It seems many USB devices do not play well in USB3 ports. Have you tried plugging them into the PC's USB ports directly. Again, USB2 not USB3? Pete

Buttons and Keypresses can be profile specific or general. Both apply. For assignments to the same buton / keypress profile overrides the general setting. The idea is that all your common button/key actions can be assigned to all aircraft, reserving profile assignments for the differences specific to this aircraft type. This doesn't apply to axis assignments or calibrations because, unlike buttons and keys, axes are really always active and you don't want unintended inputs from axes affecting the wrong aircraft. I'm sure the documentation does explain this. With buttons and keys the General assignments will be shown initially by default. You switch between them using the Profile specific checkbox. Pete

Looking through the new Log and the Scan CSV, it looks like there's some clash between one of the 6 Registered Razer devices and the Thrustmasters. Windows, or something, appears to be getting them confused and assigning the same GUIDs to both! I thought that was impossible! You could try uninstalling the Razer devices in the same way as for the Thrustmasters, but i am gradually coming to the conclusion that the Registry, at least, is well and truly mucked up. We could try uninstalling all joystick devices AND removing all the related Registry entries 9poring though the Log will reveal them all to you -- see the ones in the REG file suggested earlier0, but in the end, depending how much you have installed, it might be cleaner to reinstall windows. Or maybe you have a recent backup you can use? Presumably you take regular backups (I make one at least once a month, and more before big updates, and keep previous, father and grandfather copies -- being a very old DOS user I've never really trusted anything Windows-wise!). Pete

We don't really need or want their drivers. I'm pretty sure that they are standard UDB HID joystick type devices and standard Windows drivers should work fine and without problems. But, see: 3=Joystick - HOTAS Warthog 3.GUID={50E9F090-52E4-11E8-8001-444553540000} The Joystick is still detected and listed okay, so its disappearance makes no sense. Though previously it was actually listed twice 9I never noticed that before as I was only really looking at Throttle): 0=Joystick - HOTAS Warthog 0.GUID={6F3BE990-5696-11E7-8001-444553540000} 4=Joystick - HOTAS Warthog 4.GUID={50F980F0-52E4-11E8-8005-444553540000} So that was wrong then. The first of those two was bad in any case: 187 ****** Registry scanning: VID=044F, PID=0402 ****** 203 Trying: "HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_044F&PID_0402\Calibration\0" 203 ... and a "GUID" value 203 GUID= {6F3BE990-5696-11E7-8001-444553540000} 203 NB: not valid for this device according to GetConfig! Anyway, on the Throttle problem, if you followed the instructions you've actually made no changes which would delete anything to do with the Joystick device, only the Throttle unit. So the only change which could affect the joystick is that "driver". If re-installing Thrustmaster devices doesn't get them working correctly, if their own driver updates (which could happen any time anyway and, in fact, is designed to happen, else why do they bother?) stops other of their devices working properly, i can only suggest using Thrustmaster support. FSUIPC uss standard DirectInput, nothing more nothing less. I am sure there must be many Thrustmaster users who don't have these problems. I'm afraid i have no more ideas about how to fix your problems. there's something very very odd going on. You cannot assign there either? Then it is truly unmistakebly a Thrustmaster problem. 😞. Could their new "driver" be inompatible with your version of Windows? something to ask them, though if that were the case it shouldn't have installed. Pete

FSUIPC has always had its buttons numbered from 0-31, never 1-32. This is because that's how DirectInput actually numbers them. Button 1 in P3D is button 0 in FSUIPC. I'm sure this is explained somewhere in the documentation. But it doesn't matter. There is never a need to reassign buttons in FSUIPC. They are recorded in its INI file and reloaded for you. Pete

Okay, but no need to remove everythiing. Please accept a delay now, maybe for a few hours. I have to flake out at my age. evening rest time ... Pete

Yuck! Thrustmaster entries don't show as such? That's very bad. I see that the others declare themselves okay: Loogitech, Mad Catz and Razer. The screw up is worse that I thought. If the entries are there, and it looks not, you'd need to open each and see what it says. Or just assume that Windows hasn't recognised either Throttle or joystick ...? but that doesn't seem right. If you can't locate it there, just carry on. But it's worrying. Do you have any Thrustmaster software installed? If so you should probably uninstall that (windows Control Panel Programs and Features. BTW please read my instructions again -- I changed the REG file. I realised i was removing the Throttle too. Be away from PC for a while -- dinner time! Pete

The deletions in the Registry (see edited copy) should only affect the Throttle. Pete

I'm quoting this from John's reply in the thread just below this one, but I've edited the REG file for your Warhog entries, both sets: 1. Find the device in the Control Panel – System – Device Manager, right click and uninstall, including driver if option presented. 2. Unplug the device. 3. Create and Execute a .reg file containing the text highlighted below, then run this “as administrator”: Windows Registry Editor Version 5.00 [-HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_044F&PID_0404] [-HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_044F&PID_0404] 4. Power off. 5. Re-connect the device 6. Re-boot and test again. Pete

Okay. I think that FSUIPC is choosing the later entry in the Registry over the first. Not sure why -- it theoretically should actually choose both. However, the Scan CSV record you posted orinially is very confusing. For the Warthog nothing makes sense. So I now do think something has screwed up its registry entries. I'll work out what to edit and get back to you. Pete

Can you paste the new JoyNames section here please? Let me see the resulting Joynames first -- or is it completely identical? Pete

Ah, so you ARE trying to assign in FSUIPC, but FSUIPC doesn't see the Throttles? Right ... Is the throttle the "HOTAS Warthog"? If so ... A check in the logging shows the Hotas Warthog showing up in two places, with two different GUIDs one of which is the one FSUIPC has used Here's the being used, but note these lines: 203 NB: not valid for this device according to GetConfig! 203 1st registry entry has Joystick ID=0 203 WARNING: Joystick ID 0 is duplicated in Registry Maybe that's a clue to some sort of Registry corruption. 203 ****** Registry scanning: VID=044F, PID=0402 ****** 203 Trying: "HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_044F&PID_0402\Calibration\0" 203 ... and a "GUID" value 203 GUID= {6F3BE990-5696-11E7-8001-444553540000} 203 NB: not valid for this device according to GetConfig! 203 1st registry entry has Joystick ID=0 203 WARNING: Joystick ID 0 is duplicated in Registry 203 Attempting to acquire this device for checking ... 203 Acquired device, GetDeviceState to check values 203 ... Okay so far 203 Finding name in "HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_044F&PID_0402" 203 Joy Name = "Joystick - HOTAS Warthog" the other entry for the same device is: 203 ****** Registry scanning: VID=044F, PID=0404 ****** 203 Trying: "HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput\VID_044F&PID_0404\Calibration\0" 203 ... and a "GUID" value 203 GUID= {7C5DBA90-5696-11E7-8002-444553540000} 203 1st registry entry has Joystick ID=1 203 Attempting to acquire this device for checking ... 203 Acquired device, GetDeviceState to check values 203 ... Okay so far 203 Finding name in "HKCU\SYSTEM\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_044F&PID_0404" 203 Joy Name = "Throttle - HOTAS Warthog" and that gives no errors and is probably the correct device. How this can happen I don't know. The PID (Product ID) is one case is 0404 whilst in the second it is 0402. Two different devices .. ??? Anyway, take a simple step first before I consider something more drastic. Delete the entire contents of the [JoyNames] section in the INI file -- excepting the AutoAssignLetters=Yes line, as with so many devices it is best to have that enabled unless you want to choose letters manually (before making assignments). If you had assignments already which you didn't wish to lose I'd instead suggest manually editing the GUID in the INI, but the safest way for you is to just delete them all. If that works, well and good. If not please show the newly generated JoyNames section (just paste that section into your message). Pete

John asked me to look, but he also pointed out that you are not assigning anything in FSUIPC. So, my question is, where and how are you assigning? Also if you are not assigning in FSUIPC how are you detecting that FSUIPC is not seeing your throttles? where are you looking to decide this? Pete

You'd need instead to assign to Throttle 1, not the Generic (all engine) Throttle, and calibrate on the multiple throttle page. The basic throttle in the simulator doesn't have reverse zone nor therefore a "centre" zone. FSUIPC gets around this by using an old FS control, but one still supported internally (luckily). Pete

You have left it to the system to let WideClient find the Server using Windows interrogation. This normally works fine, but sometimes Windows updates might mess things up, or it can happen if you aren't using a fixed IP address on the Server. Check if the server IP address is still 192.168.1.111. Generally, if you always use the same Server from this client then it is more reliable to fix the server's IP address, and explicity provide the ServerIPAddr and the Protocol parameters in the Wideclient.INI file. It does remain active unless you change aircraft. Even the same aircraft but a different livery. You can edit the name of the Aircraft in the INI file [Profile ...] section so that it applies to them all (eg using A330). It is more likely that the button device has gone to sleep. Re-entering the assignments tab makes FSUIPC re-scan devices, which would wake it up. Make sure all USB devices listed in the Windows Device Manager have power management disabled, where that option is offered. By default Windows turns power off to dormant devices. Pete

I wouldn't know how to fix it, that's the problem. The set and get functions are really simple, using basic calls into the Lua code which is not mine, but the free lua.org package, and for which the source is complex, convoluted and too complex for my aged and gradually failing brain. Maybe there is some bug in the version of Lua we used -- there are later versions. However, on this: The details of the crash might be useful to check where this is occurring as that might then be fixable. You can get these details, even historically, from the Windows Event Viewer (Application Logs). But I'd only be interested if it was for the latest FSUIPC5 release, or the latest WideClient. Pete

This is probably some clash between threads. You should have something to slow down those loops -- an ipc.sleep perhaps. There's no way threads can be switched fast enough to meet your demands. The globals are, of necessity, stored and retrieved in a different (invisible to you) thread, so that all threads can access them. I'm not sure there's anything FSUIPC can do unless we deliberately assume a sleep before each get and after each set request. That might actually be necessary now that I think of it -- for FSUIPC5 and the future in any case (you don't say what you are using) -- but as it has never been a problem before I think your solution is to put them in yourself. You might need to expriment with different sizes of sleep, from (0) which usually allows a thread change (but maybe not to the desired one) upwards. Oh, two questions 1. In your test.lua, why are you getting the 1000 variables before they are set. Wouldn't you expect errors? What is setting them beforehand? 2. Why the complication of creating a lua file in a lua file instead of just creating it yourself? Is there something I've not understood? Pete

Changes in Windows, no matter what the update, don't affect the low level device access which FSUIPC uses for GPSout. What are your current GPSout settings (in FSUIPC4.INI)? Maybe the coms port number or name has changed? That's be the first thing I'd check. Also, FSUIPC will log what it is attempting to send if you add these lines to the [General] section of the FSUIPC4.INI file: Debug=Please LogExtras=4 Check the logging -- make sure it is showing what you'd expect to be sent. if it is, and it isn't arriving, it will most likely be a problem with the port number or name. If it isn't right, then it's your settings. Pete

Further to what John says, I should point out that IVAP does not use FSUIPC and is certainly not dependent upon it for its connection. So, you really need to seek IVAP assistance. They must have a Support Forum? Pete

Well, assuming the P3D SDK is correct, that is indeed the case. The pairs of offsets you refer to are obtained directly from the relevant SimConnect variables. Only the format is changed, nothing else. The lower offsets (0C48 and 0C49) were originally derived in FS98 by hacking, and the range discovered by experiment. Nothing like the P3D SDK was available until SimConnect was invented in FSX. Documnetation inconsistencies may indeed therefore occur. These are corrected as discovered, but this can't occur retrospectively -- it will be in the next full release. So, thank you for pointing it out. Pete

Yes, and very easy to miss! Pete