Pete Dowson

There's nothing to "learn"! It's far easier that creating macro files and assigning them as you've already done. You only need to put the Display Vals.lua file into your FS Modules folder, go to the Keys or Button assignments tab in FS, press the "reload" button if your FS was running when you copied the file over (so it recognises it), then assign a key or button to "Lua display vals" in the drop down as you have for the macros. Then when you use that key or button the logging will start and it will display changes to LVars on screen too. If you want to stop it you'd need another key or button assigned to LuaKill display Vals, and use that. I now have a version of FSUIPC which can optionally log the L:Var aactions when you use those macros so we can see what happens. As I said, email me and I'll send it. Pete .

I can't do much with the others, but the last, the FSUIPC4 Log is useful. Your program or driver is evidently in error and trying to write to somewhere it shouldn't. Enable ipc Write logging in FSUIPC's Logging tab, which will show what you/it is trying to do. Pete

Sounds like SimConnect is overloaded. But I need to see the FSUIPC4.log file from such a session. Pete

Those offsets cause direct writes into P3D. To calibrate values sent to offsets you should use those in the range 3BA8-3BC4. What about the Windows crash data? That's more relevant! Please show me that. Only that if it is on you'll probably get conflicts in any case. Always use one or the otther. But you should never be able to cause a crash. Pete

If it occurs with P3D (then it is NOT the same thing. There will have been a crash and I'd need to see the Windows crash details and the FSUIPC4.LOG file, if one is produced. If it is the trust bug, there's no log made because FSUIPC never runs. If it is a crash then there will be crash details in Windows event viewer and maybe a log from FSUIPC4. Note there can be other, registry or FSX.CFG [Trust] section reasons for the trust bug window appearing. There are threads about the registry fix in the FAQ subforum, and you can delete any FSUIPC entries in the FSX.CFG [Trust section. Pete

It's a SimConnect trust bug, which was fixed in P3D but not FSX. It only happens on some systems, and sometimes fixes itself after one try (say "yes" for it to continue and run), but sometimes takes several attempts. Once is runs okay once it stays okay -- until, at least, the next update. Then it may or may not happen again. Microsoft knew about this but couldn't fix it -- but it was a lot worse before the SP2/Accel update. They said it was a Windows problem, and the Windows folks said it was an FSX problem. So, stalemate. Pete

Yes That makes no sense at all. Two more things to try: 1. Remove both T lines, and change AutoAssignLetters back to "Yes". Runthe sim, and it will probably assign letter A and that should show as A in the assignments tab. If so, change both A's to T's and see if that fixes it. If not: 2. Go to the Windows Device Manager, in the Control Panel, and sselecting the throttle and fully uninstalling it there. Both of them if it lists two. Then re-boot the system. Failing that I think it'll be a matter of searching the registry for any mention of "Rhino Throttle" and deleting the entries for it. Pete

That sounds exactly like the occasional SimConnect "trust" bug as covered by the FAQ subforum thread. It does seem to take a few retries sometimes (according to reports. I've never reproduced it on any on many PC systems). Luckily all that nonsense was removed in P3D. So, what is changing after those few revolutions? Certainly nothing in FSUIPC. I assume this, for COM1 for instance, is the total of what is being done in the Log above? If those L:Vars get written then presumably you should see an immediate effect? It might be a good idea to have the L:Vars displayed on screen in real time as they chhange, so we can see. You can do that by running the Lua plug-in "display vals" -- it's in the example plug-ins Zip file in your FSUIPC Documents folder. It may be that it is they aircraft which is responding incorrectly or late. Though I don't uinderstand why it would be different between different versions of FSUIPC as none of the code in any area to do with button interpretation has been changed, not for many many years. And the log certainly shows it responding to buttons okay. The L:Var requests are just that, requests via the FS PANELS.DLL interface. I'd add more logging if there was anywhere to add it, but all it does is call "get_named_variable" followed by "set_named_variable" -- and it does the same sequence no matter whether it's a Set, Toggle, Setbits, ClrBits, Inc, Dec, or Cyclic Inc. I could put a log message at the very point of sending those two commands to FS, but I'm not convinced that would help. Let me know what you think. If you want to try that send me an email on petedowson@btconnect.com. Pete

And what happens if you tell Windows to go ahead and let FSUIPC load? That message box is often only a warning because of a previous crash, not one in this session. Off to bed now. Pete

Not really. I'm only moving things around to see what changes. And I don't think the changes are relevant to your problems. And anyway, I'm up to 4.961b now. Pete

The crash on Exit you get may be the same as those crashes on exit which seem to somehow give rise to the crash on a subsequent startup, which is what we are primarily trying to solve, being the much more major problem. I would hope that one of the interim test versions I have now produced would get rid of your problem on exit, but I have no way of knowing. If you want to tr, see the pinned thread at the top of the Forum and send me an email. I'm having to try to get some sleep now, so there will be a delay I'm afraid. Pete

I can understand a corrupt DLL.XML file causing FSUIPC not to be loaded -- it would have no menu entry then -- but I still don't understand how a loaded FSUIPC doesn't respond when its menu entry is selected. In the log earlier where there was no menu, this sequence: 77000 ### MENU: EV_MENU [15] received: dwMenuEvent=0, fInScanJoy=0, fInOptions=0 80656 ### MENU: EV_MENU [15] received: dwMenuEvent=15, fInScanJoy=0, fInOptions=0 80922 ### MENU: Error: failed to receive DLGMODE notification! Aborting menu! shows that you clicked on the selection twice, presumably because it was slow to respond. the "=15 in the second is the 'memory' of the first, showing my code that it was already trying to get into dialog mode. the notification of the menu selection worked, but then SimConnect wouldn't go into dialog mode. The correct sequence is: 778305 ### MENU: EV_MENU [15] received: dwMenuEvent=0, fInScanJoy=0, fInOptions=0 778305 ### MENU: ST_DLGMODE received, stt->dwInteger=1, dwMenuEvent=15 778305 ### MENU: ST_DLGMODE: fInScanJoy=0, fInOptions=0 Then, on exit from the options screen: 784857 ### MENU: PropertySheet call returned 1 784981 ### MENU: ST_DLGMODE: ending dialog mode I also get this 'error', later: 785668 ### MENU: Error: failed to receive DLGMODE notification! Aborting menu! That's just a safety measure, to stop the "MenuEvent" memory I mentioned preventing further attempts to enter dialog mode. The last time I saw anything like this it was down to another add-on somehow preventing dialog mode from being used. I'm afraifd I don't remember which add-on. This must be about 6 or 7 years ago, at least! Pete

No, sorry, they were there. It was me. There's so many crash problems with P3D at present that I'm overloaded and rushing. Sorry. I also haven't slept properly for several days. So your problem isn't the GUID matching. I had assumed that because it was the mst recent change and I'm not aware of any other which could affect assignments. So, going back to the original problem reported, I need to get to the bottom of it. Is this the entire assignment list for device A or had you abbreviated it for me? [Buttons] PollInterval=25 ButtonRepeat=20,10 1=RA,0,C65588,0 -{BRAKES}- 2=RA,11,CM1:16,0 -{Macro 01 A2A 180: L:Com1FreqInnerKnob inc}- 3=RA,10,CM1:17,0 -{Macro 01 A2A 180: L:Com1FreqInnerKnob dec}- Does the brake assignment work? Does FSUIPC see joystick A properly -- does it respond to it in the Assignment tabs? Can you enable Button and Key logging in the FSUIPC Logging tab, please and use the above assigments and show me the results? Thanks, Pete

They are the standard flight control inputs, yes. They result in direct writes to SimConnect variables unless "WrIteAxesDirect=No" is set in the INI file. In the latter case they invoke controls ("events"). With rudder trim I assume you mean the rudder trim control. There is a rudder trim input offset, 0C04 which is direct and not affected by the INI file setting. Why such a mix? Why use offsets for control in any case? They are separate, no conflicts. A stackhash error where, in your program? Pete

Sorry, what have other addons got to do with it. Your report makes no mention of any problem other that the fact that the FSUIPC options screen won't appear. FSUIPC cannot affect any other add-on, except those which interface to it, of course. If that's happening you have a serious corrupted installation. Pete

Yes, and it showed no problems. Can you tell me EXACTLY what other add-ons or add-ins are running? Have you tried eliminating any? As a first step I need some more logging. Something seems to be stopping the message from SimConnect telling FSUIPC that the menu option has been clicked. Add Debug=Yes LogExtras=x8000 This just adds some logging to the menu process. Do that and then try to get the FSUIPC options showing. Do it just twice, with a minute or two between, then show me the log. I'll be back in a few hours. Pete

Well, there's nothing I can change in FSUIPC which will fix anything if it isn't even running. But see my previous message and drop me an email if you want to try some changed versions, which I'm making to try to solve the P3D problems. Pete

And is the crash data always the same, as above? Pete

The problem you have is nothing to do with any video drivers. Usually it is a SimConnect trust bug. There is a thread about this. in the FAQ subforum. The report occurs before FSUIPC is even loaded. The log you supply shows a perfectly good FSX session. I assume that was a previous one. Both Event Viewer logs show: Faulting application name: fsx.exe, version: 10.0.61472.0, time stamp: 0x475e17d3 Faulting module name: FSUIPC4.dll, version: 4.9.6.1, time stamp: 0x58933f1b Exception code: 0xc0000005 Fault offset: 0x0001f145 Now 1F145 is the ENTRY point into FSUIPC from SimConnect (the exported function called DLLStart), so it really isn't getting to run at all. There's a similar investigation into this going on for P3D users -- see the pinned thread at the top of the Forum. Please read that, and though you are using FSX, i think parallel investigation into the same startup problem is warranted. If you email me, as it says, I can supply another FSUIPC version which should give us more information. Pete

Apart from recording the version of FSUIPC, the files are identical. I don't know why you are supplying them. You haven't even made the change I suggested. I do not need the whole file. That change is all you should need. It doesn't get added by itself UNLESS you are starting from scratch with no letters allocated, in which case both lines will be added for each device with different letters for each one. You need to add the line yourself now. Pete

On disk? Are they all fragmented and spread all over? If you are using SSDs, leave well along. If not, run a good defragmenter. 10 minute freezes!!! You definitely have something really wrong there then. Nothing can take 10 minutes to load without there being a serious problem! Is is streaming over a very slow internet connection each time? Rather than just remove things willy-nilly you should have tried to do a process of elimination to see where the one culprit file was, one which is probably corrupt. Or, probably quicker, use Process Monitor (ProcMon) to log all the file accesses and see where the 10 minutes comes in. Pete

The PMDG aircraft don't suite cockpit builders at all for all these reasons. I think the iFly models have a slightly more cockpit-oriented attitude, but I like many others use external aircraft systems like Prosim, SimAvionics and Project Magenta. The flight model in the sim is then cockpit-less and relatively simple, with only the flight characteristics (and outside views of the aircraft) then being important. In the past the manufacturers of the MCP units have often supplied their own drivers, and I think they probably could do (and may already have done it) it with PMDG's assistance, but I bet they pay for this. Pete

And you'd prefer not to be able to see scenery below you? And not have the traffic from / to that airport, except that little the default would allow? The VAS usage would decrease again once past. At least it does in FSX-SE and the latter editions of P3D. Pete

Yes, I realise this in any case. It is simply their routine functioning as if it had been called by a mouse click. I was thinking that the wheel codes, supplied the same way, would do it too. Have you tried? i.e. these: #define MOUSE_FLAG_WHEEL_UP 0x00004000 #define MOUSE_FLAG_WHEEL_DOWN 0x00002000 The thing with those though, is what increment or decrement (wheel clicks) their function assumes. With the real mouse they can be accumulated and arrive in a separate parameter. Still, it may accept them faster, if necessary. Er, Lua without FSUIPC? How? Unless they accept L:Vars (Local panel variables) then I think there's no way. Have you tried using the L:var logging facilities in FSUIPC, or the supplied Lua plug-in to check?. Modern gauges written in XML tend to use L:Vars a lot, but I think the PMDG ones may be the older style C/C++ ones, which don't so much. Pete

As I've said before, and explained in my pinned post at the top of the Forum (why are folks not reading these?), I have already started a closed test session with updates by email only. Please see the pinned thread and drop me an email. It works better that way because it all goes into a separate folder on my system and I can contain it. I'm afraid I don't really like the PM system as I cannot organise it. I used to be able to disable it, but the later Forum software won't let me do that. But I only tend to check PMs once or twice a week. Sorry. Pete