Pete Dowson

Many add-on aircraft use their own autopilot values. It is probably simply writing back to the FS value because it uses a standard bit of gauge for its display. Check whether it is using the standard FS controls -- enable FSUIPC's event logging and see what controls it uses when changing the heading bug on screen. Do the standard FS keystrokes work? Do the standard FS controls work if you assign them in FSUIPC? It may be using local gauge variables (L:vars) to hold values like this. Try logging L:Vars and see if one of those holds the heading bug value. Sorry, I don't understand this part. It may not be solvable, depending how that add-on aircraft was designed. But have you checked the User Contributions subforum here? I just had a quick look, searching for "Duke" and there are two threads with lots of examples. Seems the aircraft uses L:Vars quite extensively. The solution probably lies in that direction. Regards Pete

Sorry, but I don't think this is really anything to do with FSUIPC specifically. It looks like some sort of memory corruption, and different results with different versions of things like FSUIPC just moves the memory data around enough to give different results. I think this confirms what I surmised above. Something in the scenery is causing memory corruption. Almost all G3D errors are due to such -- and usually when FSX's process memory is close to being filled. See if it is still a problem when you reduce memory demands somewhat -- i.e sliders to the left more. I had a big problem simnilar to this with UK2000's EGLL once when I originally also installed UK2000's EGLC -- with one order in the Scenery.CFG file I got FSX crashing at EGLL and the other way at EGLC. It did eventually go away after I fiddled about with all sorts of things, including re-installs of both sceneries, but i never really isolated the cause. Not really relevant except that the PMDG aircraft will be using a lot of FSX process memory too. Incidentally, the FSUIPC4 log file, from the Modules folder, is always useful to see in any reports like this. Regards Pete

Yes of course, because by providing the settings for all of the lights there is no dependency on whatever is read from the device. Nevertheless, as i said, i can treat this erroneous version of the RP48 like the erroneous LGT2 if that would help -- even if you don't need it, others might. I await the HidScanner results. Sorry, I don't understand what more you think you can do or show? There's only the HidScanner data I want to see, please. Regards Pete

;-). Nice name for it! If you mean the instrusion of the message Error, no table returned[/CODE] then it doesn't interest me. it isn't from FSUIPC, but from some other add-in DLL or Gauge you have installed. The Console Window is owned by the EXE process that is FS, and anything sending messages to it will have them appearing there even if they haven't actually opened it themselves. I see this quite a lot. One process can only have one console window. Regards Pete

Well, you ARE assigning "direct to fSUIPC calibration". If you don't want to use FSUIPC calibration you should simply assign to the FS controls instead. Can you please explain to me why it is confusing? There are 4 slots to assign up to 4 actions for each axis. You have evidently used up to 3 of them for several of your axes in order to assign completely separate functions. It isn't as if they wouldn't all be shown on screen together, as assigned to the axis. What is confusing about it clearly displaying what you've done? And why would you do it? It seems to me you may have dived in head first, done some things without thinking then through, and probably without referring to the user guide. FSUIPC is a big box of tools, and can do all sorts of coplicated and useful things, but most find it simple enough to use for simple things, like assignment and calibration. I'm also astounded and rather disturbed that you appear to be using a really ancient version of FSUIPC. I cannot support such old versions., and the one you are using appears to predate the very facility which would have been of most benefit to you -- Profiles. Well I think you'll dig yourself into deeper and deeper trouble. Please do not come back for more support if you do this, as I will only repeat what I said above. And also do not come back until you update to a supported version, please. :sad: Pete

Ah, maybe. Not one to GSX specifically then, at least not one mentioned on the GSX forum. I've been away over the weekend, not fired up my cockpit since Thursday. Regards Pete

By "normal" do you mean "correct"? If so, of course it is correct. 42.7416406 (the nearest I can get in my calculator) = 42*44.498436 which would certainly be 42*44.50' to the nearest 1/100th of a minute! What is your problem? Check it yourself on a calculator (just multiply the fractional degrees by 60 to get minutes of course)! Pete

Hmm. Never heard of the "RP48 mouse" version. There's bound to be different firmware. I'm afraid GF sometimes don't seem to test their firmware functions very fully -- their own software doesn't read the lights so they never worry about that function, it seems. I can program around it, but I'd rather do it only for that specific version if I can distinguish it. Could you run HidScanner and show me the entry for the RP48 in its log? (HidScanner can be found in the Lua thread in the Download Links subforum). The work-around assumes that the lights status reading function always returns zero. I keep a record of what I've already written and if I get zero back and i know I've set some I use my remembered settings instead of the read settings. It's messy and should be unnecessary, and it means it isn't cooperative with other programs (Lua or otherwise), but i had to do it like that for the LGT2 because of its firmware fault. Best also report it to GF as well please. They should know about it even if they find it, er, uneconomic, to fix it. [LATER] I folllowed the link and read about it, but it looks no different and it says nothing about the mouse function other than it has one, so how does that work? Why would it involve different hardware which looks identical? Regards Pete

Sorry, I've no idea. I use GSX as well, but I've not seen an update recently. I'll have to check that out. Regards Pete

There is no separate code for SetLight / ClearLight for any of the devices, just the one function each (Set and Clear) executed for all. And the code in the SetLights function, which uses the masks, is identical for almost all devices -- exceptions for the LGT2 for the firmware fault I mentioned, and weirder devices like the WP6 and DIO. I have run this here: and I get the same as you on the T8 but also like the T8 on the RP48, no difference at all. I am using FSUIPC 4.834 and GFDev version 2.1.0.1. You didn't tell me the versions you are using, but assuming they are both up to date then the problem nust be in the firmware within the RP48 itself. Running HidScanner all i can tell you is that my RP48's say 'version 1.1.'. I've had them many years. Regards Pete

Complete INI file to start with. FSUIPC4.Log file. Some idea of whether it always occurs no matter what you do -- e.g. just loading FSX, getting to flight mode, then closing don ... does that do it? If not it'll be something you do subsequently, so I'd need to determine what. If it isn't a hardware memory problem it could only be some corruption occurring from some add-in, so i need a list of all the add-ins. And then it might be a process of eliminatin. i.e. stopping one of those at a time. The parameter "ShortAircraftnameOk" is written backto the INI from a 32-bit word in the midst of a lot of other data. If it is 0 it is "No", if it is >0 it is "Yes" and if it is <0 it is "Substring". something is zeroing it if itis changing to "No". FSUIPC never writes to it after reading it from the INI, and it only reads it the once, during initialisation. If you can determine exactly when it changes it would be useful. Pete

There is no difference in the code, it is identical. And the "SetLight" and "ClearLight" functions are merely wrappers for the "SetLights" function, preparing the two masks for you, that's all. It sounds as if you are using the GoFlight software too. It is not cooperative like FSUIPC -- it doesn't read the lights before changing them like FSUIPC does. The other possibility is a bug in the firmware in the unit which stops the reading of indicators working. I know that happened on the LGT2, but I don't think it happened on the RP48. GF never discovered it because as i said, they never use it. I don't know if that ever got fixed, but if not it only matters if you have separate programs accessing the same device. Regards Pete

The INI, LOG and KEY files FSUIPC uses are all named in accordance with the EXE name. Have you tried simply renaming those files accordingly? Pete

Do NOT revert to an older version! The problem is that the programmer has used an FSUIPC offset which was not working as documented and never bothered to report this problem. The error was then fixed and so broke the programming which was incorrect in the application. You can use the current supported version of FSUIPC (3.999) by changing "AxesWrongRange=No" to "Yes" in the INI file. I had to put this in to make FSUIPC provide the incorrect offset value because the application programmers couldn't be bothered to fix their programs. Pete

As far as I can tell from that (difficult to read unformatted) rendition of the DLL.XML file, it is okay, so FSUIPC should be loading. Are you sure it's the same problem? You have no FSUIPC log file produced at all? Pete

FSUIPC is still working, but your Simconnect installation is getting bogged down so much that FSUIPC is not getting information quickly enough. This can happen, rarely, on a very overloaded FSX -- but then you would notice stupidly low frame rates (unflyable) too. So I don't know what else is going on with your system. By default FSUIPC assumes SimConnect has stalled it it gets no update information within one second. This is set by the INI file parameter: SimConnectStallTime=1 You could try increasing that, but if information is arriving so slowly over a consistent period, as it seems from the log (not the reconnections needed even other second), then any FSUIPC client programs are going to suffer from that jerky supply of data. More likely, one of the SimConnect client programs you have running is somehow causing SimConnect to stall and not service any other programs. You could try getting a SimConnect log to see if you can identify it (SimConnect logging is described in a thread in the FAQ subforum), or, probably more productively, try a process of elimination to find the culprit. Regards Pete

You need to go to Saitek support. FSUIPC4 has nothing to do with what Saitek do. Oh, and update your FSUIPC4 please -- 4.80 is out of date and not supported. Pete

The INI file most certainly isn't one from any recent version of FSUIPC. All recent versions produce these parameter lines (with appropriate data of course) in the INI, which are missing from yours: UpdatedByVersion=4834 FSVersionUsed="Microsoft Flight Simulator X",10.0.61637.0 SimConnectUsed=10.0.61259.0 In fact without that first line your INI hasn't been touched by a version of FSUIPC released for quite a long time. I think you'd better show me your FSUIPC4 log file so I can check the actual version. The other strange thing is that almost all the calibrations you have set are default. You don't appear to have followed any of the calibration steps at all, making it a bit of a waste of time using FSUIPC I should think: All of those are default values except, oddly, that 10000 for the max airlen value. Your mixture lever problem is no doubt because you have a generic all-engine mixture calibrated ("Mixture =", but no sign of any calibration for Mixture1 to match up to your other three! There are some extremely strange assignments amongst your myriad of separate aircraft settings (why so many different ones in any case?) Look: 0=0U,256,D,9,17,13,0 1=0V,256,D,0,17,13,0 That's one axis assigned to operate Throttle1, PropPitch1 and Mixture1 all at the same time, and another simultanerously operating PropPitch1 and Mixture1 at the same time! What are you trying to do? The only saving grace is that you've not bothered to enable calibration for PorpPitch1 or Mixture1 so those have no effect. As for Mixture, the "generic" all engine mixture control is only assigned for your multitude of C130's and such. That's another thing about your INI file. It hasn't even got the "UseProfiles" parameter in it. This means the FSUIPC you are using pre-dates Profiles, making it many years out of date! So: I recommend: 1. Delete the INI file altogether. It's a mess and trying to fix it will take longer that starting again. I honestly don't know how you got it into such a state. 2. Install an up to date version of FSUIPC. I most certainly cannot support the one you are using! 3. Use Profiles. Do your assignments (properly, not multiple assignments to each axis as you've done so far), AND proper calibrations for named profiles, and merely assign the aircraft to a profile. If you edit the name in the profile section, ensuring you have "ShortAircraftNameOk=substring" in the INI, to a short part of the name but one which identifies it, it should pick up all variants. Please reveiw the User guide sections of Calibration andf on Profiles. Regards Pete

NEVER EVER post registration information openly as you did. I will probably now have to disable that WideFS registration because it will be plastered all over the Pirate sites for folks to get free use of my software. And then you will have to purchase another! It was extremely unfortunate you posted it on a day i departed from a weekend away, as it has now been open to al for several days and read by over 60 people. Hopefully they are all good honest folks, but if not I will have to take steps! ASE and Squawkbox do not use WideFS. Only FSCommander does of those three. The INI file is in the same folder as the EXE file. If you don't have one, the default settings will be generated for you. There will also be a Log file. Show me the Wideclient.Log. Pete

Sorry, I've never heard of SkyDemon. I take it that it is a moving map driven by GPS data? So it connects to a serial port (COMn), to receive GPS data? For that to work on a WideFS client you must configure FSUIPC to send it to WideFS and you need to add the GPS port details to the WideClient.INI file. What actually "opens" your application isn't relevant. Regards Pete

No, can't see that. And I use SSD's, they are fine. The FSUIPC documentation includes a User Guide which has step-by-step calibration instructions. Look in the FSUIPC documents folder, inside the Modules folder. Pete

Actually the log you sent explained it. It is my error. I forgot: the events are triggered by a change. The "event.param" will only occur if the value of the parameter is different. Sorry, it was me being blind! Of course, repeated turns in the same direction won't change the parameter! The answer is to program the "Press" for a LuaValue with parameter 1 or 2, and the "Release" with a LuaValue with parameter 0. The 0 will be ignored in the Lua but it will make the next value trigger the event again. It just means a definite "click click" to do a selection. An alternative would be to trigger on a flag being toggled instead, if you'd like to try that. Use, say, flag 1 in place of parameter = 1 and flag 2 instead of parameter = 2. Assign to "LuaToggle <name>" with parameters 1 or 2. Then instead of the Select function and the event.param line you'd have: function Select1() if switch > 0 then -- limits encoder switch from going below 0 switch = switch - 1 ipc.writeLvar("L:DME_Switch", switch) -- DME Selector Rotate Left end end function Select2() if switch < 3 then -- limits encoder switch from going above 3 switch = switch + 1 ipc.writeLvar("L:DME_Switch", switch) -- DME Selector Rotate Right end end event.flag(1, "Select1") event.flag(2, "Select2") [/CODE] Regards Pete

Hmm. That's good, but I still don't understand what was happening. I have tested the Installer on a system without FSX installed. It shouldn't make any difference. Pete

So the "switch" value only ever gets to 0 and 1, never increases to 2 or 3. That makes no sense to me. If it can increment to 1 it can surely increment to 2 and so on. Try setting the Lua debug logging option in the FSUIPC logging tab, and alo the "button" logging. No other selections. You'll then need to close FS and restart after since the Lua program will already be running. Then do a systematic test. Turn the dial slowly three times in each direction. Note what you see each time. then close down. ZIP up the FSUIPC4.LOG and send it to me at petedowson@btconnect.com. I'll work out what is going on from that. Unfortunately I am away from tomorrow (Friday) lunchtime till sometime monday morning, so this may all get delayed. But at least your original is still usable, right? I'd like to understand why this isn't working right though. Regards Pete