Pete Dowson

It probably isn't FSUIPC which is doing that. It sounds more like a time discrepancy and you have some program trying to keep the time synchronised? It might even be the option in FSUIPC to synchronise the time -- turn that off and see. It isn't enabled by default in any case. There are other programs which also change the traffic quantity which would cause a reload too.. Why do you think this is any way something to do with a G3D.DLL error? You were very specific about that. With it occurring withing 5 seconds of starting the flight it really sounds more like an initialisation bug in the PMDG NGX, something which doesn't like changes being made at a crucial time. I've really no idea. And i can't help with FSX.CFG settings. I always refer to the very useful guide available on AVSIM -- see the FSX Forum there. Your problem sounds much more specific to the PMDG aircraft. Have you looked to the NGCX support forum? I'm afraid I don't use any clever add-on aircraft. If there is any sort of FSUIPC problem it will be in the FSUIPC4.LOG file, in your FS Modules folder. Next time it happens get that and paste it here and I'll tell you if there's anytrhing helpful there. Meanwhile maybe you can explain why you referred to a G3D error? Pete

Do you think you could use a larger font next time. yours is too small for me to read easily! I will change it for the rest of my reply: Hold on. FSUIPC simply logs one specific G3D error and prevents it crashing the Sim. Even if that actually occurs you would never know it until AFTER you finish the flight and examined the FSUIPC log file. There is no "keeping the sim alive" because there is no need -- the crash is stopped before it can happen -- and in any case FSUIPC most certainly never reloads anything. I think you must be completely misinterpreting some other problem you are having which is not related to FSUIPC at all. Regards Pete

Hold on a moment. As I said, I think you have the logic of this all wrong in any case. The AVAIL light is nothing to do with 0B52, except insofar as when 0B52 is non-zero, the AVAIL light should be off. The AVAIL light is surely based on the state of the APU, not the generator. It is on when the generator is off but the APU is running. It tells you when to press the Generator switch. At least this is most certainly the case with a 737. I've no idea with other aircraft, but if you are turning the LED on when the Generator is on, I can't see why you'd want to turn it off when the generator is still on. What do YOU think the AVAIL light is telling you? Again you are asking questions which are 100% related to how you are dirving the LED, which you never explained and cannot be done by FSUIPC which has no LED output drving facilities. I get a very strong feeling you don't read all of my replies, otherwise you'd have surely seen the logic i think you should be using. Pete

Sorry, you've lost me. Is this not about PMDG doors any more? Have you by any chance posted in the wrong thread? Please try starting a new thread if its a new subject, and give some context. You seem to imply, by "so you mean", that this is something already discussed somewhere. If so please stick to that thread so I know what you are talking about. Regards Pete Pete

Great! Thnks for getting back with this. Good idea. I don't know what it does either, but it doesn't sound very performance friendly! Regards Pete

I think, then, you either need to link your LEDs to your use of those controls -- in other words keep track of the doors you have opened and closed, or ask PMDG to supply such indications. One way of implementing it yourself would be to use a free user offset, say 66C0, and when you send the door open/ close controls, also change bits in that offset (i.e. dual assignment to the buttons or switches). Then you can relate the LED states to bits in that offset. The only problem then is to make sure you are synchronised to start with. eg ideally always start cold and dark with all doors closed. Pete

You asked me how to turn an LED off, NOT about any offsets!. I don't know how your LEDs are connected nor how you are turning them on or off, so why ask me how to turn one off? If you are asking about an offset then you really need to say so, not ask how to turn an LED on or off! By "cancelling" 0B52, what do you mean? That offset shows the state of the APU Generator -- whether it is ACTIVE or not (i.e. on). I think you have it all mixed up. Surely your "AVAIL" light is not related to the status of the Generator, but the status of the APU -- when the APU is fully running but the generator is Off, the AVAIL light should be on. When you turn the generators on, or the APU off, then the AVAIL light should go off. The APU is fully running when offset 0B54 (a 32-bit float) is 100% (actually, best use >=99% as it never quite gets to 100% -- 99.999 is the highest I've seen it). Both 0B51 and 0B52 are set when you operate the Generator switch if the APU is running. One shows the switch position, the other whether the generator runs. (This is with the default 738). BTW the APU generator switch turns the APU generator on or off, not the APU itself as you state. Please do ask the question you actually want answered next time. I would save a couple of days I'm sure! I'm not good at reading between the lines ;-) Pete

The mapping list is from the data listing in the PMDG NGX SDK file "PMDG_NGX_SDK.h". Did you check there? I'm pretty sure I've not missed labelling any, and the data indexed by the offsets is a straight copy of the data provided by PMDG. Note that PMDG may use the FSX inbuilt door facilities in any case, in which case the door indications in FSUIPC normal FSX offsets would be the correct place to look. The NGX support forum would be the better place to ask, really. I don't even use the PMDG aircraft! Pete

Okay. I don't really understand how the PANEL.CFG comes into it -- is it installing a gauge or something? Are the buttons seen in FSUIPC? If so, of course you can assign them. Pete

Sorry, I don't know how you are achieving the first part. There is no LED controlling interface in FSUIPC, so i assume you are talking about some other software. How am I supposed to know what it is and how it works? And in any case if you can light an LED surely you can extinguish one too? Else things will stay lit forever after. regards Pete

Sorry, I don't know LINDA. Pete

Good. Andy knows a lot more about VRI stuff than I, and certainly about their software which I never used -- I added facilities into my Lua plug-in libraries to help get away from their software so that the original serial port devices could be used with add-on aircraft. Well, most add-on hardware makers, VRI and Saitek included, do not really aim their software at all the various wonderfully different ways add-on aircraft makers find to implement things, so I'm not surprised. But it also makes me wonder why you use the VRI software when you said "Else the fcu work fine for AXE". Well, having neither this "FCU Combo" nor the AXE aircraft, I wouldn't have done that, would I? ;-). I tend to find out about problems or questions about FSUIPC and WideFS, not about things away from my area. Good luck! Pete

You can of course use the "zone" programming feature in FSUIPC's axis assignments tab to create a reverse zone on your throttle axis which sends the equivalent of the F2 keystroke (actually the "throttle decr" control). Regards Pete

One of the first things to check for when there are conflicts. Pete

Sorry, I don't know "FCU Combo"? Is it? Why not describe it again, then, because I don't know what it is. So you are using some software from VrInsight which doesn't work with your add-on aircraft? Why are you asking here, then, instead of at VRInsight or Aerosoft? And if everything works fine otherwise, why are you using something you don't need which doesn't work? Fast update to what, the Airbus? Or VRInsight? I'm sorry, but all of the FSUIPC facilities are oriented around standard default aircraft. If you have specific problems with specific add-on aircraft I can't often help. I just do not use any add-on aircraft. You need to go to the correct support forum for that aircraft, or maybe for your hardware device. You've not even said anything about any of my software, whether you even use FSUIPC or not, for instance. If you do, please test on default aircraft. Then maybe i can assist. And if this is a "known problem" who else knows? Why do you say this in any case? Rgards Pete

Reverse thrust on an axis is only possible using the older FS98-compatible throttle controls. Some aircraft implementations just do not support these. You probably have no option really but to program your reverse thrust by button. Regards Pete

Did you test on a default aircraft? It may be to do with the way they've implemented it. Does the prop pitch axis work? Why a mouse macro on something with axes? What's wrong with the normal axis assignment for prop pitch? It would surely be more appropriate. And what control, if any, is is using when you do that? Use the FSUIPC logging facilities to find out. That's what they are for. Does the mouse macro work when you use the Test facility first? Not many modern cockpits are susceptible to mouse macros. Many are not written using the standard Microsoft Gauge SDK for C/C++. but often in XML instead. Again, the FSUIPC log will show you whether there is a problem. You don't even mention what flight simulator this is with, FS9, FSX, P3D? Is there a Support Forum run by DreamWings for this aircraft? You might find help there. Pete

That's the "memory is running low" warning in FSUIPC. If you don't like it you can switch it off. the Log will also show the warnings. But it is much appreciated by most users. It is nothing whatsoever to do with FSUIPC. FSUIPC is trying to help you AVOID the OOM crash, there is no way it can possibly cause one. So you are looking at a coincidence relating to some other change. FSX runs out of Process Memory, nothing to do with real memory or hard disk space. Its process memory is limited to 3Gb, or 4Gb if you have enabled the large address space modification or are using SP2 or Acceleration. If you only have 4Gb of real memory you are running a severe risk in any case. Up to 1Gb of that wil be taken up by systems processes and services. Regards Pete

If things are okay they are okay. The real rudder position is available is another offset, and some EICAS programs (like the purpose-written one I use in my cockpit) read and display that correctly. If you are using a standard or add-on aircraft EICAS gauge then there is no way unless you disuse the FSUIPC steering tiller and use the FSX steering tiller instead. Then you will have steering on both rudder and tiller so won't be able to check the rudder whilst taxiing without veering from side to side. Your choice. Pete

You don't need to, but you may need to do a run of FSX without it at least once in order to set up your options and get eveything correctly recognised. Yes, of course, as it does when you first install and run FSX. FSUIPC4 does the same with its INI file. Pete

What do you want to do? FSUIPC4 is a toolkit to use as you want. In any case, there is no difference between P3D and FSX as far as FSUIPC4 is concerned. Use the same INI file from your FSX Modules folder in P3D. Pete

There's NEVER any reason to uninstall fSUIPC just to install an update! You are not looking in the right place then! Or maybe you have Windows Explorer hiding filetypes from you! Show me the Install log. Nothing to do with FSUIPC is in the Registry. The only things to do with FSUIPC are in the Modules folder -- FSUIPC.DLL, FSUIPC.INI, FSUIPC.LOG and the registrations in FSUIPC.KEY. Then all the documentation and ancillary files (eg Lua plugins) in the FSUIPC Documents subfolder. Pete

FSUIPC obviously cannot be responsible for FSX losing its settings. I've no idea what would cause that, except possibly FSX not actually closing down properly -- I think it only saves things on closedown (at least that's certainly true for the FSX.CFG file). Next time you close FSX, use the Task Manager to see if it is really still running. If so you have some rogue thread still running, possibly from an add-on DLL or Gauge file. That's because they aren't fully releasing. If you assigning in FSX make sure the null zone slider is fully left. If calibrating in FSUIPC, recalibrate and leave some free movement before setting the 'minimum' position. And of course you normally have to REVerse toe brakes -- do that BEFORE calibrating. That is definitely a problem of the FSX.CFG file not being updated on disk. Are you running something like FSPS booster or extreme FSX? If so I think that may keep the FSX.CFG protected whilst it's running. I can't see how that can occur -- if so it isn't FSX or FSUIPC doing that. Sounds like another add-on. Pete

FSUIPC does not touch and has nothing whatsoever to do with FS9's assigned keyboard commands. It does allow you to assign keys overriding the FS assignments, but it doesn't do anything like that by itself, you'd have to assign each key you want changed individually. It sounds like you've corupted your FS9.CFG file, which contains all of the keyboard assignments in its [KEYBOARD_MAIN] and [KEYBOARD_SLEW] sections. If you delete the remaining mutilated CFG file FS9 will generate a new one with all the defaults next time to run it. But of course you'll then need to go through and set up your FS options again. Pete

No, it doesn't. I don't think you completed your research. The only one which is "fixable" is a relatively common one which just happens to be in an easy place to patch, a routine which returns an easy "true" or "false" result -- and not one where aborting the code sequence can yield non-crash results. The offset in G3D of your crash is not that one I'm afraid. There are a lot of crashes reported in modules like G3D, and most are simply not avoidable or recoverable without eliminating the cause -- in the case of G3D it is almost always something not quite right in the scenery somewhere. Pete