Pete Dowson

The DLL.XML file, you mean? It should be all text. If it is large it seems then that you have quite a few modules added to your installation? This is why the installer cannot complete the job. Hmm. Strange you would need to do that, as FSX generates a new FSX.CFG file when it is run if it cannot find one already there. Sounds like something else must have been broken in the earlier FSX installation if that wasn't happening. Good. Happy flying then! ;-) Regards Pete

Good. Thanks for confirming. Pete

Well FSUIPC does absolutely nothing unless it is asked to. You've either got things assigned in FSUIPC which are being activated by buttons, axes or keys, or something else is telling FSUIPC to send those controls. For the former try deleting your FSUIPC settings -- the FSUIPC INI file. For the latter, well, you'll need to remove each add-on in turn until you find the culprit. Or, first, just do as I already suggested. that should tell you pretty quickly what is going on. Pete

Offset 3367 is bit-oriented. Bit 0 (value 1) for door 1, bit 1 (value 2) for door 2 and so on. At least that's the case for FSX -- with FS9 I there's only support for the one door. To open a door, assign a button to "Offset byte setbits" with offset 3367 and parameter 1, for door 1 (2 for door 2, 4 for door 3 and 8 for door 4) To close a door, assign a button to "Offset byte clrbits" with offset 3367 and parameter 1, for door 1, etc. To open and close all doors in FSX together, as I do, use parameter 15 instead of 1. 15 is 0x0F in hex which is 1111 in binary (1+2+4+8), so operating all 4 doors together. Regards Pete

So where is the FSX.CFG file? If you know where it is, then you can edit the DLL.XML file so that FSUIPC4 will be loaded okay. According to the partial log file you showed me, it isn't to be found in any of the correct places. That is the problem. What "old version"? Any version for FSX would have the same installation problem if your FSX.CFG file is missing! What error message? You've not mentioned any error message? Install what? FSUIPC4? Yes, after installing FSX you need to run it at least once before adding to it. Regards Pete

What are these "modes"? what do you have F10 and F9 set to do? Have you buttons assigned to do these "mode" changes? Sorry, I don't know what they are or what you mean, but if these are some normal FSX functions, activated by FS controls, then the only way they can be changing is if some keypress, button or other control is assigned to those controls and is sending them. Try going to the FSUIPC options, select the Logging tab, and enable "Buttons and Keys" and "Event" logging, two of the selections on the left. Then, when one of these "mode" changes occurs, look in the FSUIPC4.LOG file (it is a text file and will be in the FSX Modules folder) and see what FS control was responsible, and how it was instigated. Regards Pete

Yes. The keypress facility is merely emulating the user pressing keys. It isn't sending KEYDOWN and KEYUP messages to a specific Window. If you wanted to do that you could do it direct from your application, if it is running locally. In the normal use of your program, wouldn't FS have the focus in any case? You lose sound if it doesn't have the focus. Incidentally, you don't need to explicitly exit at the end of the Lua program -- it exits automatically at the end in any case. The exit facility is provided for conditional premature exits, earlier in a Lua program. Regards Pete

I still couldn't reproduce this, but I suspect it may be a similar bug to one i did just find and fix in FSUIPC 3.935. So could you try version 4.541, which has a similar timing issue fixed? It is now in the Updates folder, please. If you still get a problem, I'll need more details. Thanks, Pete

I couldn't find SB3 so i installed SB4, and I've managed to reproduce the error. It is a timing problem -- one of the SB components is calling FSUIPC very early, before it has initialised a critical path semaphore. It is easy to fix, so look out for 3.936 later today. Thanks for the detailed information. It was very useful. Regards Pete

What is the relevance of Microsoft updates? Sorry, you seem to have added to a different thread and there's nothing explaining what you are talking about. Do you mean SP1 and SP2 updates for FSX? Why get rid of them? Looking at the install log: All that shows that FSUIPC4 is installed. However: That part and the following searching shows that there's not yet any FSX.CFG file, and so FSUIPC4 is unable to update your DLL.XML file so that SimConnect will load it. You've either deleted your FSX.CFG and not run FSX again since, or you've never run FSX. You must always run it before trying to add anything to it. Regards Pete

Hmm. Not much help, that's in Windows. Is there an FSUIPC.LOG file produced (albeit pretty short I should think)? If so, could you please add LogReads=Yes LogWrites=Yes to the [General] section of the INI file and try again. I cannot see how anything in FSUIPC can crash FS so early, but it is worth a try. As I said, the changes between 3.934 and 3.935 are not only small, but only come into play when you run a Lua plug0in in any case. Ah, that does raise another question. Do you have an Ipcinit.lua in your modules folder? If so can I see what is in it, please? Hmm. Not sure which of those use FSUIPC. Definitely the PMDG and the SB3 modules, maybe the LegacyHUD one. If you have time do you think you could try without them, then add them back one at a time? Sorry to ask all this -- it is difficult when I cannot reproduce the error, though i will try adding the PMDGoptions one and the SB3 ones later today. Thanks, Pete

Oh, did I say that? Let me checkAh, yes! Do you know, I clean forgot I'd added that control. I just checked. It is certainly there, in its correct alphabetical order, named "List local panel vars". I don't understand why you couldn't find it -- I just dropped the list, hit "L I S" keys reasonably quickly, and there it was! It sits between "Letterbox" and "Lod zoom in". There's no need whatsoever to enable any other logging options for it to work. There's certainly no need to enable Extras logging, and as I already told you, the LuaSet and LuaKill controls do NOT run the Lua plugin. Only the "Lua" and "LuaDebug" controls run a plug-in. Please do read what I write even if you cannot find the Lua documentation. I did even list the different Lua controls for you! Sorry, but i think you must be missing the obvious somehow. There's never a need to bounce any PDF manuals anywhere anyhow. Well, I don't understand how. If you couldn't find the control for it which is most definitely there, and you couldn't work out how to run a Lua plug-in, which you certainly cannot with the controls you've been using, then I've no idea at present how you did it. Maybe you found some debugging tool I'd left in? That's what the Extras option is normally about -- I advise folks on how to use it when I need to get additional information in order to debug or develop something or other. :-) Pete

It works fine here. I need more information please. The change between 3.934 and 3.935 is only an additional Lua plug-in facility, and even that isn't active until FS is fully loaded and ready to fly. When Windows comes up with the error message, please select the option for more details. I need the Module name and the address provided -- it'll be a 4 or 8 digit hexadecimal number, like 0x...... What add-ons are installed which will be active during FS9's loading sequence? What aircraft is loaded by the default flight you've set? Is it an FSUIPC client aircraft? Any other add-in modules installed in the Modules folder? Pete

Just open it with Notepad or any ordinary text editor, and delete that section. Yes. Regards Pete

These are latching toggles, i presume? You mean you want Green to mean "ON" and Red to mean "OFF" -- whereas, of course, I use toggles for things like Dorrs and Pause, so I want them Red when On. What? You changed colours 2 and 3 -- those are the Toggle colours, as documented. That should certainly work. All colours 0-9 can be changed. Where does it say it is read only? I use offset 3367. On FSX there's a separate bit for each of up to 4 doors. FS9 only has the one there. Regards Pete

What's that? You seem to have continued something but in a new thread, so I've lost any continuity. Sorry, you had to enable Extras logging for what purpose, exactly? What should be made clear in what various PDF files? There is no such drop--down menu item. Where did you get that idea? Are you perhaps getting mixed up with the Lua plug-in I provided to log L:vars? You need to have the example Lua program in the FS modules folder, and then start it by assigning a keypress or button to it and activate it with that button or keypress. Sorry, you'll need to explain why you think there was or ever will be such an option. Oh dear. You really do need to read a little more. There are a number of Lua-related controls, all clearly described in the Lua document: Lua to RUN a plug-in LuaKill to Kill a running Lua plug-in LuaSet with a parameter, to Set one of 32 flags for a running plug-in LuaClear .... similarly to clear the flag LuaToggle .... similarly to toggle the flag LuaDebugto run the plug-in with debug tracing, line by line in the Lua program. (This needs the debug lua plug-in present too). It seems, by lack of reference to what the facilities are, you tried everything EXCEPT running the plug-in which does what you want. :-( Pete

By "previous beta" do you mean 4.538? Because the change between 4.538 and 4.539 is simply a new Lua plug-in facility. nothing else. I'm pretty sure the GoFlight module for FSX doesn't use FSUIPC, so I'm really not convinced FSUIPC can have anything to do with it, other than, of course, memory arrangements might be slightly different. Not only that but the log seems to show that the GoFlight module is crashing before FSUIPC is even doing anything -- it doesn't get to do anything until that request to SimConnect returns with version details. Those affect which SimConnect functions FSUIPC can link to. I don't appear to have any FSX GoFlight software here, so perhaps you could enable FSUIPC's IPC read/write logging and just re-check that the GoFlight module is not attempting to use FSUIPC. [LATER] Three more comments. First, you say FSX crashes with a windows erorr message. Have you got the module name and address for that crash? The details you appended were for the GoFlight driver which appears to be a separate crash: It is an EXE, a separate process altogether to FSX. Where did FSX itself crash? Second, I found my GFDEVFSX.EXE but I'm not sure it is doing anything. Is it supposed to allow units like the GF-T8 and GF-P8 operate, or do I need to assign things to them somewhere in the GF software? It doesn't seem to have a menu or anything. The EXE certainly runs here without crashing itself or FSX, but perhaps that's because it is doing nothing? Third, it might help to get a SimConnect log, please. The "FSX Help" Announcement explains how to do that. Regards Pete

The details provided in those error reports not only include the module name, but also the error tyoe (an 8-digit hexadecimal number) and also the actual address within the module at which the error occurred. This latter information is actually often extremely useful as it can pinpoint the exact place in the code experiencing the problem. But of course you have to have the source. But if it can be reproduced so successfully, as you are saying, there should be no problem for the vendor to also reproduce it and therefore diagnose and fix it. The problems which are really difficult are those which simply don't occur except in very specific, though unidentifiable, circumstances. This doesn't appear to be the case from what you are saying. For an unregistered installation of FSUIPC, none of those settings would have any affect on anything not using FSUIPC (which I must assume applied to this aircraft, else you wouldn't be able to use it without FSUIPC). There really isn't anything you can experiment with -- further information on the problem is needed first in any case. Regards Pete

I briefly looked at the AVSIM thread on this subject, and I think the term "CTD" is incorrect in a strict sense. By "CTD" we mean "crash to desktop" -- i.e. nothing to see, just the desktop. No error message, nothing, no helpful information at all. It used to be one of the most frequent crash types in FS9 before the 9.1 update came out, which seemed to fix most of them. According to reports on the AVSIM thread, and I quote one: it appears that this isn't a real CTD but a more understandable crash which Windows has detected and provided details for -- in this case actually identifying the villain as "maam_tbm.gau". Since the crash is actually occurring inside that Gauge, not in any code of mine, there is really no way I am likely to be able to fix it. Just because it seems to only occur when FSUIPC is also loaded is not any indication that FSUIPC is contributing in any way other that by occupying some memory (hence making the memory patterns different) and possibly changing the timing of events slightly. It is pointing to a bug inside that gauge, such as using an uninitialised variable value, which will crash when the memory supposedly containing the variable has some sort of data left in it but not when other data is there. This is the most common types of intermittent bug, but if it is as reproducible as you say it should be easy to find with the normal Microsoft debugger and a debug copy of the gauge and its source. I therefore recommend that you strongly appeal to the support section of the folks who make and sell this aircraft to get them to debug the code and fix the error. I would certainly try to help in this further if the aircraft were freeware, or if the makers decided to send me a copy to test for them, but I am not prepared to purchase an aircraft I don't want in order to find a bug in their code. Sorry. Regards Pete

And does the Gauge still work fully without FSUIPC? Because the only way I can think of there being a problem is if the gauge is using FSUIPC and has maybe requested something which doesn't have an instantaneous response, and when the response arrives the Gauge has been removed from the system by an aircraft change. No. Yours is the first report. I assume this MAAM_TBM.Gau file is new? What does it do? No idea without any more information. Is there any problem noted in the FSUIPC.LOG file at all? Is the CTD a crash with no error message at all, nothing from Windows saying FS has crashed? Is this Gauge freeware? If it can be added to any aircraft, and is freely available, I could test it here to see what is going on. Regards Pete

Seems so. This is only the second time it's been a problem in the 6 years of FSUIPC registration. You purchased the key when it was "tomorrow" in Germany but still "today" in America, and tried to use it before "tomorrow" arrived. The date check is part of the essential anti-piracy checks on the registration keys. Now that the time zone thing has caused a problem more than once I might take a look to see if I can adjust the check for time zone differences, or possibly just allow one day's "grace". ;-) Regards Pete

Okay, that looks fine. But: is a bit of a worry. Having two programs sending what presumably is the same stuff to FSX doesn't seem correct, and may well be the cause of your double button actions. Make a safe copy of your EXE.XML file and remove this part: so that only one driver loads. If that fixes it then tell Saitek they've got an installer problem which needs fixing. Regards Pete

So, there must be a driver being pre-loaded, one which sends these commands to FS. Maybe it uses SimConnect direct? Does it get loaded by the DLL.XML or EXE.XML files? Maybe you could get a Simconnect log (see the FSX Help announcement for instructions for that). Of course it could simply be sending keystrokes. You could log Buttons and Keys in FSUIPC logging to find out. If it is basically a keyboard emulator it may be getting repeats activated. Not odd -- FSUIPC can log events being received by FSX no matter where they come from. Phew, that's quite a list. Are they all actively connected? Could any of those be interfering? Er, hang on. I thought you'd removed the INI file in any case? If you are using the default INI file there shouldn't be any "joystick commands" in there in the first place. Maybe you'd better show me the entire INI file -- I am now suspecting you have things assigned you've forgotten about? Regards Pete

No, they are irrelevant. The problem is that FSUIPC thinks you are using illegal keys. Looking at the date and time of the session, from the log: System time = 27/09/2009 23:09:17 and the date and time of your registration -- 28 September 2009 01:32 it appears to FSUIPC that your keys weren't valid on the day you used them. I bet if you tried again now everything would work fine. In fact just an hour later would have been okay. Regards Pete

Er .. which buttons? Are they the correct events? Sorry, you evidently misunderstood me. It seems likely that the Saitek device is sending spurious button presses. You need to know which button you pressed and link it to the events FSUIPC is logging so yuou can tell which ones should be occurring and which ones not. It's not hard. In a line like this: 105893 *** EVENT: Cntrl= 65580 (0x0001002c), Param= 0 (0x00000000) AP_MASTER the number on the left is the time since FSUIPC started, in milliseconds, -- so 105.893 in this example. EVENT is a lable meaning this line is logging an Event. The Ctrl=65580 is telling you the internal control number (used also by external programs) The (0x0001002c) part is simply the control number in hexadecimal The Param part gives the parameter sent with the event -- not relevant in this case. For Axis events the parameter would be the axis value, eg throttle setting. The name "AP_MASTER" is the internal name for the Event -- in this case the autopilot master toggle. On the contrary, you seem to has so many AP_MASTER events occurring that you are probably switching the autopilot on and off a lot. The problem looks like your button is repeating so it always sets it on and off. Can you try pressing one button once and looking then to see what you get? Just playing with the buttons won't really help. Not really. FSUIPC doesn't change. So they are all duplicated. It sounds like you either have the same buttons assigned to do the same things in two places, or the same device is being see twice in FS and it is assigning them automatically, twice. Check the FS assignments. See how many devices it thinks there are. You said in your first report here that "the multipanel doesn't actually show up as a joystick in FSX; buttons can't be assigned." That seems quite hard to understand or believe. If it isn't a device as far as FSX is concerned, what is actually sending those events to FS? Are you sure that part is not duplicated, whatever it is? Doesn't FSUIPC see it as a device either? Isn't it listed in FSUIPC's [JoyNames] section, in the FSUIPC4.INI file? Regards Pete