Pete Dowson

So the actual devices you have are: 1 x Alpha Flight Controls 2 x UnoJoy_Throttle 1 x B737 1 x MFG Crosswind V2 Right? And in the last set of files you submitted these were recognised and assigned: 2 x Alpha Flight Controls 2 x UnoJoy Throttle which means on that occasion you lost both the B737 and the Crosswind and gained a "ghost" Alpha Flight Control! All because of Windows apparently repetitively assigning new GUIDs which copy existing ones. I think there must be a load of entries in the Registry for each of those devices and which entry gets assigned is almost pot luck. Not sure what the "more details" were intended to be in the Log, but there's nothing useful there. For some reason you are running a plugin called "comtest.lua" and have Lua log/trace enabled. Next step would be to get the log with that extra logging i mentioned so I can give you instructions on cleaning this stuff in the Registry. Pete

Well, it might be easier to eliminate each of them, one at a time -- or maybe by halves. after all, in the end i have to get the logging operating for those offsets to see which causes the crash (assuming it is due to one of the values being written). Another way of tackling it would be to log them all in any case and see if there's any consistency over the last thing written before the crash. It's just that the log could get very large. To make this happen please set Log=Yes (replacing Log=Errors+ probably) in the [User] section of WideClient.INI. There are much more detailed logging options which we'd use if that proves futile -- Log=All, and Log=DebugAll. One of these methods should show us what is causing the problem. Pete

We didn't need the FSUIPC log. If anything the WideServer log would be the one relating to WideFS. You give only one client log. Please confirm that there are no lua files in the WideClient folder. I see there are quite a few applications being loaded: 5016 New Client Application: "FsATG" (Id=1720)5422 New Client Application: "FD_Sounds" (Id=10480)21922 New Client Application: "FlightDeck320" (Id=7212)282110 New Client Application: "FSATG" (Id=5492)287516 New Client Application: "FD_PUSHBACKEDITOR" (Id=1444) Is it possible for you to run with less of these? Or even one at a time? I'm trying to see which might be causing WideClient to crash. I know it shouldn't happen, but perhaps one of them is writing some values to an FSUIPC offset which Wideclient chokes on. Once we can narrow it down I can tell you how to enable logging so we can find out exactly which. To do this logging without first narrowing it down a bit would produce far to much to wade through i fear. Pete

There is an update to 7.157 which fixes a problem which could conceivably cause a crash if ipc.Get's and ipc.set's are used a lot to transfer data between clients. The problem with a crash in NTDLL is that it could be almost anything. That Windows module is a collection of many of the little functions used by most programs. Before we go further, assuming it still occurs with 7.157, we need to see your WideClient.INI and WideClient.Log for each PC (after each crashes). Also, if you have any Lua plug-ins on the Clients, list those, and finally, whether you have joystick devices on the client with buttons/switches assigned in FSUIPC. Pete

I use several Bodnar BU0836 cards without problem, but not as many on one PC. I have read of problems with more than a few (can't remember number -- something like 50 such cards connected to ProSim. I don't recall if those problems were ever solved. If neither FSUIPC nor P3D can read the buttons on this card I can only think its a problem with Windows itself. Not sure how you can work around that -- unless you have a Networked PC and can connect it there and use WideFS to connect buttons to FSUIPC. Pete

It would be interesting to see the files before the re-boot so we can see exactly which one changed its GUID. In the new files you provided things are slightly different -- the second pair with identical GUIDs is with "B737" instead of the Crosswind: MFG Crosswind V2 ID=4 {9EEBEF20-B521-11E7-8001-444553540000} Alpha Flight Controls ID=4 {9EEBEF20-B521-11E7-8001-444553540000}, B737 ID=0 {7BFCBC30-96D6-11EA-8001-444553540000} Alpha Flight Controls ID=0 {7BFCBC30-96D6-11EA-8001-444553540000} The common factor in this is, then, "Alpha Flight Controls". Very odd that Windows keep re-assigning it AND gives it the same GUID as something else. I can provide detailed instructions, or even a little .REG file to remove them automatically, if you get me a log with more details. To do this add these lines to the [General] section of the INI file: Debug=Please LogExtras=x200000 The log will then give me the full pathnames in the registry. Pete

Thank you. And please also try those alternative assignments I provided earlier for the PMDG 777. Pete

Which one? Or it is a different one each time you re-boot Windows? I can see one really BIG problem. Two pairs of devices have EXACTLY the same GUID: UnoJoy_Throttle ID=3 {3F0557C0-20F2-11E9-8001-444553540000} Alpha Flight Controls ID=3 {3F0557C0-20F2-11E9-8001-444553540000} and UnoJoy_Throttle ID=0 {7BFCBC30-96D6-11EA-8001-444553540000} Alpha Flight Controls ID=0 {7BFCBC30-96D6-11EA-8001-444553540000} They have the same ID because they have identical GUIDs! According to Microsoft, this cannot possibly happen! The GUIDs are assigned by Windows, FSUIPC can't do anything about them, but they are the one essential link which enableds FSUIPC to open the channel to receive input. When you followed those steps, are you sure you did step 2 thoroughly, until there was no trace of these devices left at all? I suggest doing that again, perhaps just for one of them, and see if Windows assigned new GUIDs. If not it will come down to Registry Editing, not a pleasant task. Incidentally, it appears as if you didn't use Step 1 at all -- your INI shows devices A, B, C, and D "missing" and the devices which got added start from letter E. That cannot happen if there were no entries in that section beforehand, as the program always starts from 'A' when assigning automatically. With Step 1 not followed, and step 2 being suspect because of the GUIDs, I think you need to re-check what you actually did and maybe do it all again. Do NOT do any of it with the Sim running!! Pete

I assume that by "FSU" you mean FSUIPC. Anyway, I am sorry but there is no way I can confirm that it will work of not. The last update for my EPICLink was done in 2003 (it is still on www.FSUIPC.com), three years before FSX. FSX came out long after I had stopped any EPIC development and by that time I had no EPIC equipment left to even test it on. So all I can advise it to try it and see before you change everything over. Please bear in mind that EPICLink is really obsolete software and cannot be supported, so it either works for you or it doesn't. Pete

Yes -- one of the forms of conditional assignments as described in the Advanced User's guide (page 24 I think). And my idea was to try to narrow it down -- determining whether it was related to the Lua plug-in method, or somehow related to those custom controls. Well, we need to be able to reproduce your findings to work out what is going on. Nothing in what you've said you are doing involves any sort of focus change being made by FSUIPC or its Lua interpreter. They are just simple sending of controls to SimConnect for passign on to the add-on aircraft. So if you can make it happen, without going overboard with scripting, for one or other of the default aircraft, that would make some basic debugging possible. Else we'd need to ascribe it to something the PMDG coding is doing. But the first thing to help would be trying with more direct means than the Lua scripting. Pete

The only change I found which is in any way related is that the default value of the parameter LuaTrapKeyEvent was changed from FALSE to TRUE. That should only affect key combinations explicitly requested via event.key functions. Could this explain the change you see? Please try adding LuaTrapKeyEvent=No to the [General] section of your FSUIPC6.INI file. Have you a list of all the Key Combinations you use in event.key calls? I'd be interested to see it. Pete

In that thread you reference you reported the problem as: When using 6.0.9 the GSX Menu opens (which is triggered by LUA and a STRG+SHIFT+W "ipc.keypressplus" operation). So it looks like sending keypress with lua is working in general. But when the GSX menu opens I cannot press an option (0-9) nothing happens. Not with my script and not by keyboard - strange. when I uncomment my script to .lua.off (to avoid loading it) I CAN press the GSX options (0-9) with keyboard again So something with my script and the change from 6.0.8 to 6.0.9. We thought we fixed this, and you verified that the fix worked. What is different now? are you saying the same bug is back? You say it was fixed with 6.0.1.0b, but also that rolling back to 6.0.1.0b fixes your newly discovered bug, whatever that is (it isn't explicit above). Your log states: FSUIPC6, Version 6.0.10 (19th July 2020) I think this indicates that it is the official 6.0.10 release not an interim update sent for testing. I wouldn't have thought this would hve incorporated any other changes in the same area, but i will check ... Pete

Are you using custom controls on those other aircraft too? I cannot see any way FSUIPC can cause mouse/keyboard focus to be lost using a script which merely sends controls to the Sim. It would act exactly as if the button were assigned to those controls. Instead of the Lua script you show above you could have done exactly the same with direct assignments, so: 39=B644C=1 PD,16,69640,1 40=B644B=1 PD,16,69639,1 41=B644A=1 PD,17,69640,1 42=B6449=1 PD,17,69639,1 Can you see if the same happens with such assignments instead of using your Lua? The action as far as the sim is concerned is identical. One other question: you say you have those EVT names declared in a file called "pmdg_777_offsets.lua", with the action carried out in "PMDG 777.lua". If this is correct then those event values must have been set in the Global lua, using ipc.set and retrieved using ipc.get. Are those lines in the Lua but simply missing in your post? Finally, I don't have any fancy aircraft to test with. Can you make these problems happen with any default aircraft? Pete

All of the files show all your devices correctly recognised and assigned unique IDs 0-7, with the Service Panel as ID 5. Its details show: Btns=32, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R0,U4095,V4095,X4095,Y4095,Z4095 the same as the other PoKeys panels. So it certainly looks as if it all should work. Currently, according to the log, you have controllers enabled in P3D, in RAW mode. Are you saying P3D doesn't even see the buttons in RAW mode? FSUIPC uses the higher level DirectInput mode. If Raw mode gives nothing then DirectInput has no chance! I see you don't have any buttons or axes assigned in FSUIPC, but there are Lua files relating to each of the named Pokeys cards, plus: 9=pokeys131 10=pokeys132 11=pokeys133 12=pokeys134 Odd that there are only 4 of these. I don't know what function they perform, but something's a bit asymmetric about it. Shouldn't there be 5? Sorry, but i really know nothing about "PoKeys". Pete

But none of those are assigned in FSUIPC, according to your settings. It is not recommended to mix assignments in FSUIPC and FSX. You should do everything in one place, so if all those assignments you mention are in the Sim, then make your new assignments there too. Yes, this is the problem you stated at the start. And it seems to be due to there appearing to be more than 16 joystick devices connected (the maximum FSUIPC can cope with), and an apparent corruption in the Registry, which FSUIPC depends upon for its information on devices. However, since you are obviously happy with all the assignments and connections you made in FSX, not in FSUIPC, why are you now wanting to assign things for your new added control in FSUIPC instead? You either need to take the drastic steps to fix the registry issues, as I suggested, or simply continue to make all your assignments in FSX instead of FSUIPC. The only thing that would do is start you off with default settings, which yo could do by simply deleting the FSUIPC4.INI file instead. Pete

Yes, but according to your INI file you only have 14 button assignments (most of those for COM Radio), and two axis assignments (oddly both to the rudder), neither calibrated. So there's really very little to re-do, especially considering how many Joystick devices you appear to have -- hundreds of buttons and dozens of axes! Pete

Well, none the FS range of simulators actually have facilities to specify those things. I doubt if MSFS has either, but I wouldn't be able to say either way in any case because of the NDA. In the P3D world I know a number of third party programs (including TopCat for example) provide the means to set the numbers of passengers in each class, maybe in each seat, but what then goes into the Sim is the weight in each payload section. I don't know of any program which breaks down cargo into more than just passenger and freight cargo, totalled in fore and aft holds. Pete

Maybe some of those OVH11 devices have two USB identities? The Registry has GUIDs for 15 Simple Solutions devices, but it seems mixed up about the name: ECAM 2, OVH11, New, and wcamgr are all the different names which appear to be recorded, though they all have the same Vendor and Product IDs. Oddly, 13 of them are listed as having 32 buttons each but R, X, Y and Z axes with a range of only 0-3! The other 2 have a more reasonable range of 0-127 on all axes R U V X Y and Z.Can all this be true? I just cannot imagine what your cockpit is like with so many button, switches and axes? The Arduino's are serial port devices, so don't come into this. There must be errors in the Registry then, because you have two sets recorded. And their assigned IDs in the Registry clash with IDs assigned to two of your "OVH 11" devices Oddly, that one is about the only one which doesn't appear to have a weird entry. It should be usable easily as Joy 15. I think the Registry for your devices has got into a mess. Here are the steps I would recommend: 1. Replace the complete [JoyNames] section in your FSUIPC4.INI file with just this: [JoyNames] AutoAssignLetters=Yes So far you haven't made many assignments to any devices, but be prepared to make them again as the numbers may change (probably will), and now you'll see letters instead. 2. Now use the Windows Device Manager or Settings and remove all those devices. If the option to remove their drivers too, agree and let it happen. You may need to repeat this several times for the multiple entries looking the same. 3. Unplug all those USB devices. 4. Reboot the PC. 5. Start the sim, then when it is all ready, plug the devices back in, one at a time, leaving the Simple Solutions ones till last, and checking access each time in FSUIPC. If there's still a problem, please supply those three files again. The more drastic solution is Registry Editing, which it may come to. But let's see. Pete

Instead of payload weights and distribution? What would you use counts of passengers or bags/parcels for? The crucial thing for performance and balance is the weight and distribution. Pete

Which of the 16 devices registered in FSUIPC is your A320 sidestick? You may have more than 16 USB joysticks connected, which is more than FSUIPC is designed to deal with! Here are the ID assignments, with 2 rudders, 13 devices called "OVH 11", and one "T.A320 Pilot". The rudders and "pilot" are by Thrustmster and the OVH 11 devices all by "Simple Solutions". [JoyNames] AutoAssignLetters=No 0=T-Rudder 0.GUID={B3C82B00-B7CD-11EA-8001-444553540000} 1=T-Rudder 1.GUID={B75EFDB0-8646-11EA-8003-444553540000} 2=OVH 11 2.GUID={B75EFDB0-8646-11EA-8004-444553540000} 3=OVH 11 3.GUID={B75EFDB0-8646-11EA-8005-444553540000} 4=OVH 11 4.GUID={B75EFDB0-8646-11EA-8006-444553540000} 5=OVH 11 5.GUID={B75EFDB0-8646-11EA-8007-444553540000} 6=OVH 11 6.GUID={B76147A0-8646-11EA-8008-444553540000} 7=OVH 11 7.GUID={B76147A0-8646-11EA-8009-444553540000} 8=OVH 11 8.GUID={B76147A0-8646-11EA-800A-444553540000} 9=OVH 11 9.GUID={B76147A0-8646-11EA-800B-444553540000} 10=OVH 11 10.GUID={B76147A0-8646-11EA-800C-444553540000} 11=OVH 11 11.GUID={B76147A0-8646-11EA-800D-444553540000} 12=OVH 11 12.GUID={B7623200-8646-11EA-8011-444553540000} 13=OVH 11 13.GUID={B7623200-8646-11EA-8012-444553540000} 14=OVH 11 14.GUID={B7623200-8646-11EA-8013-444553540000} 15=T.A320 Pilot 15.GUID={B7623200-8646-11EA-8014-444553540000}

ZIP files before posting. they are basic text only and compress very small. Pete

Yes, for whatever values we can get and act upon. Maybe not all, and maybe, later on, some new ones. We are still checking what works and what doesn't, and it'll probably be all different again in the released version of MSFS, which means FSUIPC7 will still be in Beta.We will be relying a lot on feedback from users acting as beta testers. Pete

So far as far as I am aware there seems to be no such thing as "L:vars". But even if there are they would only be accessible to internal modules in the sim, and there's no way currently we can make an FSUIPC internal module because, I think mainly for things like Xbox compatibility, internal modules have no access whatsoever to the outside world, basically killing almost all of the reasons folks use FSUIPC. Pete

The first step is to supply some actual information! From the Modules folder the FSUIPC INI, LOG and Joyscan files to start with. Pete

I've updated the text and the link for the list of controls now. Pete