Pete Dowson

That's really weird. It certainly doesn't happen here. I'll try to reproduce it. Are you saying that happens even before any of your Lua stuff is run? If not, when does it first appear? I might need the Lua sequence which does it. Apart from that odd Window, do the Lua display things all work correctly now. You forgot to say. [LATER] Messing about with "setdisplay", I too can now get that extra Window called "UIPCMAIN". So i should be able to fix it forthwith ... Regards Pete

Very strange. Can you show me the FSUIPC log file please? BTW when it is solved you can make it apply to all liveries by simply changing this line: 1=AirSimmer A320 CFM Lufthansa D-AIPK to 1=AirSimmer A320 Maybe, as proof it is related to FSUIPC's assignment, perhaps you could please simply change that line to, eg 1=AirSimmer A320 CFM Lufthansa Dummy so it won't match, then see if it loads okay? If it still doesn't then it's a problem of the livery. Regards Pete

Looks fine. Wht were you doing with WeatherSet2 during this time? What are the symptoms of it "not connecting" -- in other words, how can you tell? What does it say? If WeatherSet doesn't connect, nothing else will. Are you sure you aren't doing something like running FS "as administrator" and WeatherSet not? Programs at different privilege levels cannot talk to each other ia shared memory, which is the access method used in FSUIPC and WideFS. Regards Pete

If you have no existing aircraft-sepcific settings it is quicker or at least just as quick and easy to do your assignments and make them a profile. You can name the profile specifically according to the aircraft if you wish. In fact you can have a different profile for every aircraft of every livery, if you wish. A bit pointless, but you can. But it doesn't take any more effort to built a profile for your aircraft than making an arcraft-specific setting set for it. I really don't understand what you are afraid of. Just check the Profile option, name your profile, and your settings for the current aircraft are made part of that profile. Please tell me what the problem is you are trying to avoid so strenuously -- so much so that you've taken days over it and many messages. I just don't understand!? Pete

Show me the FSUIPC log, after closing FS. Pete

Doesn't it? I didn't know that. If that's what you've found, I expect so. I really don't know the innards of FS in this area, sorry. Well, 2EA8 is only a read-out, not a control. And it is actually the angular deflection, in radians. In order to get that value matched up to the control inot, which is just a control value, -16k to +16k, you'll need to convert from the angle to the control value. It is probably not even linear, and will almost certainly vary from aircraft to aircraft. If you are only flying one aircraft you might need to use a look-up table with enough positions to make linear interpolation work. If you want to do it for many aircraft you've problably got a lot of work to do. Sorry, I've no idea. Try it and see. You might want to discuss this with more knowledgable folks on FS aircraft modelling -- I think there's a forum dedicated to such things over in AVSIM? Regards Pete

These are the only relevant parts of the INI file: There are two questions about this: 1. Why, specifically, are you assigning "Direct to fSUIPC calibration"? I see you are using the throttles with no reverse zone. There are several add-on aircraft which don't like direct assignment. these may not include yours, but it is a consideration. 2. Why are you setting the Filter option on the throttles in the calibration section? Surely your Saiteks are smooth enough. The filter mechanism is very drastic -- I'd recommend you turn that off. It is also odd that you only have throttles assigned and calibrated in FSUIPC. How are you using the other controls? If you are assigning the others in FSX, it would probaby be best to assign the throttles there too. FSX has a habit of reassigning things in any case unless you disable its controllers, in which case you'd need to assign everything in FSUIPC. Apart from these observations I can't see anything actually wrong with the settings. Something is eveidently wrong in fSX, or in the aircraft you wish to fly. the symptoms you mention are normal with the settings you have for some add-on aircraft -- you should probably try changing this parameter to Yes: UseAxisControlsForNRZ=Yes because that makes FSUIPC use the same controls as it would had you assigned in FSX. In your later message: Hmm. Certainly sounds like something is corrupt in the normal flight you are loading, then. Perhaps you could ZIP up the one that works and the one which doesn't and send to petedowson@btconnect.com so I can compare them. I'm intrigued. But it certainly points to something screwed up in fSX rather than anything specifically within FSUIPC's control. Why not replace the faulty flights with ones based on the one which works? (After you've sent the the faulty one of course, as i'd still like to understand why). Regards Pete

Actually that is Enrico Schiratti's website. I don't have one, and I don't manage to get that one updated as often as I'd like. you'll almost always find later versions here in the Dowsnload Links subforum, as I said. Either way, I think you'll find the version 4.8xx on the Schiratti site is later than 4.80 -- his wording has not been updated. You need to always quote the actual version number when coming here. It is easy enoguh to find. it is displayed in the options on the About tab, it is shown in the first line of the Log file, in the Modules folder, and it can be found by right-clicking on the DLL itself and selecting Properties. The user guide shows several methods of assigning them, depending on your needs. I'm assuming by "pitch and roll" you are talking abour elevator and airlerons, not the ailerons trim and elevator trim? You reeally need to be specific about the controls, not the resulting movement of the aircraft. No, you never mentioned where you were seeing these values -- most would be referring to the axis assignments tab, which is where the actual values from the controls are normally first seen. Also, you need to be more specific, as I asked before. On the calibrations tab, what does the top left button read in each of the four sections, "Set" or "Reset"? And are these "-16000" to "+16000" values seen in both "IN" and "OUT" slots or only "IN"? If you mean "IN", what values correspond to those in the "OUT". As you see, I need information. There's no way to help unless you can be more excplicit. Regards Pete

Certainly you do not for those aircraft which are written to use the axes normally, or the FSUIPC offsets as documented. The only aircraft which need the faulty axis read-outs from the offsets affected by this parameter are those written by programmers who found a bug in an old version of FSUIPC and didn't even bother to tell me about it, but simply worked around it. That's why when the bug is corrected they don't work properly. All the parameter does is bring back the bug. it will make anything programmed to use the correct documented value go wrong. Regards Pete

What "site" is this? I don't have a "site". And saying "latest version" tells me nothing I'm afraid -- I always need the VERSION number. The latest version certainly works fine with P3D version 1.3 and does not need FSX installed. Please see the Download Links subforum above. Sounds like you've not even bothered to calibrate? Is that right? Follow the steps in the user guide. And yu don't say how you are assigning the controls nor where you are seeing this "-16000" to "+16000". I cannot help without information, so please always be more explicit. Please update to a supported version first, though. Pete

Sounds like your USB Cirrus has not been modified correctly to make the yoke axes fixed. They are presumably left open circuit and therefore floating and so feeding random signals to the driver. Try adding these lines to the [Config] section of the PFDHid.ini file: Ailerons=off Elevator=off I don't use PFCHid myself and have barely been involved with it, leaving things really to PFC, so if this doesn't work you may need to contact them -- or check your modified Cirrus. Regards Pete

Sorry, I've no idea. Have you looked in the SDK? There is a JAVA contribution in there. not sure whether that means "eclipse" too, whatever that is, but it'll be a start. If you need to change it to make it work, send me the updated package and I'll inlcude it in future updates. Regards Pete

If you have no aircraft-specific assignments or calibrations set yet, then it will default to using profiles, because that is far preferable, easier for you, and less support for me. If you really want to go back to aircraft-specific you'll need to add at least one dummy aircraft-specific section. e.g. [JoystickCalibration.Dummy] Dummy=rubbish Do this and change UseProfiles=No again. This will fool FSUIPC into thinking you are already using aircraft-specific and won't force the change on you. The change this way was never intended to happen, and I don't understand why you'd want to do it. Can you please explain why, so I can understand? No one else has wanted to go backwards like this. it makes no sense to me. Regards Pete

No. The numbers are the IDs assigned by Windows and used internally. FSUIPC cannot address the devices by letters. It uses the [Joynames] section to relate the letters to the numbers. Well, it will re-locate the numbers it needs in the Windows registry, relating them by comparing names and GUIDs, and restore the lines you deleted. It's just less efficient that one time. With the lines already there it knows exactly where to check, else there's a small search involved which it would otherwise only need to if there was no match found at that numerical ID. Well, as i just said, it won't matter either way -- FSUIPC will correct the section when it is run. Regards Pete

You must have not saved your previous INI file. FSUIPC now defaults to using Profiles, as they are much easier to handle and make more sense. Until you actually create a profile all you need to do is change the UseProfiles=Yes line to UseProfiles=No. But if you are setting up everything afresh I would strongly recommend using profiles. If I'd thought of that system originally I would never have implemented the clumsy aircraft-specific system. It's really only justified when you've already put a lot of work into it, but if you've lost or discarded all your settings anyway, as it sounds like, then you should really do it the better way. Regards Pete

Can you try this test version please (4.839). Seems okay here, but I've got nowhere near your complexity of Lua usage, and it would take be a while otherwise to test thoroughly. FSUIPC4839 test.zip This should fix both your concerns. Let me know please. I will then have to do similar changes to 3.999 as well. Thanks, Pete

I have no idea because I don't have enough information, but I cannot and will not support an unsupportable version. What IS your problem with getting up to date? It makes no sense at all!!! I won't answer any more till you are using the current version (4.827 or later). Sorry. Pete

The "Lua KillAll" you have in many is (or should be) always closing any display window. Also the closing of any Lua which was using the generic Lua Display will and should be closing that Window. In one recent release (it may have been 4.829) I did find a fix a few holes in the logic which may have left the generic Lua Display window open still when it shouldn't. Perhaps the change was this fix, not specifically the addition of the completely separately coded "setowndisplay" function. In your example function: function dispP51_CS(offs, val) conset=val+1 ipc.setdisplay(650, 200, 500, 100) if val == 0 then ipc.display("MAG INC _ BATTERY _ RECOG _ NAV LIGHTS _ LAND LIGHTS\nMAG DEC _ AV MASTER _ GEN _ APU _ PANEL LIGHTS\nControl Set = "..conset, 10) end if val == 1 then ipc.display("FUSELAGE _ LEFT MAIN _ RIGHT MAIN _ REL L DT _ REL R DT\nFUEL OFF _ LEFT AUX _ RIGHT AUX _ SPARE _ SPARE\nControl Set = "..conset, 10) end if val == 2 then ipc.display("PRIME _ FUEL PUMP _ SPARE _ GUN SIGHT _ GUNS \nSTART _ PITOT HEAT _ SIGHT GYRO _ SIGHT MODE _ SMOKE OFF\nControl Set = "..conset, 10) end if val == 3 then ipc.display("GPS _ AP CHART _ TAGS _ WING LEVEL _ CANOPY\nRADAR _ MAP _ HEADPHONES _ OXYGEN _ CABIN VENT\nControl Set = "..conset, 10) end end[/CODE] Really the "setdisplay" call should be at the end. I realise this isn't very logical, but it is the way it works at present, unless you have initialisation code outside all the functions which creates the window for you, mybe even displaying one space, just to create a blank window (a null string won't do). Anyway, having slept on it I have woken with a few ideas as to how to get around the problem I have in implementing it the way you would have logically expected. The original problem is simply that the generic display has to be written to in the main FS thread, whilst of course the functions are in the Lua threads. The "setdispay" function was implemented simply as a "SetWindowPos" API call to Windows, executed in the Lua thread -- easy, but not working if the Wndow is not yet created. I'm now looking at saving the size and position parameters in the case where the window didn't exist and applying them when the Window is next written to, in the main thread. It's not a pretty solution, but doable I think. To be honest, if I had known how popular the Lua display mechanism was to become I'd have implemented it the way the "setowndisplay" works now in the first place and would never have invented the original setdisplay facilities that way. The way the own display system works is thoroughly logical and tidy throughout, with each thread having its own controlable Window., and everything properly organised internally. I'll let you know later today how I get on. BTW, in this: [CODE]function dispFUEL_TANK(offs, dummy)[/CODE] there is no need to include the "dummy" parameter. I didn't know this when I first started with Lua, but, unlike many languages, especially C/C++, Lua's function declarations can include more or less parameters than those used in the calls to them (and vice versa). Where you supply parameters not declared they are simply discarded, and where you declare them and they are not supplied they would be read as 'nil'. Regards Pete

Okay, I've found that problem and fixed it here -- it was a typo in that change you entioned, so thanks again for that. However, this:

Okay, thanks for your diagnosis. I shall take a look -- but tomorrow now, England vs Italy on at present. I'll get to this in the morning.

FSUIPC has no idea when or why or how often you use your contorls, it just does the same thing every time based on the inputs it receives. It sounds very much like your controls are going to sleep. Windows power management on the USB hubs in your PC needs disabling. Sorry, that is not supported. Please update before you return. Regards Pete

No you don't have filtering, which makes the hangs more of a puzzle for me. I'll publish 4.838 as it is obviously solving something, but I'd like to know what it is, so I'll keep hunting. Thanks for the info in any case. Pete

When you are running a supported version of FSUIPC I will help if you have a problem, but I cannot support old versions! What on Earth is your problem with keeping software up to date? Things are improved and fixed and get better and get support, and all at no cost to you!!! :-( Pete

Looks a lot better, and with properly calibrated axes by the look of it! ;-) Either will work, but I always recommend toing it manually so you can choose letters which bear some relation to the function. For example, in your case, just add these lines to the [JoyNames] section: S=CH FIGHTERSTICK USB S.GUID={B9DCFE80-8400-11E1-8004-444553540000} W=Logitech WingMan Force USB W.GUID={B9DB77E0-8400-11E1-8002-444553540000} P=CH PRO PEDALS USB P.GUID={B9DCFE80-8400-11E1-8003-444553540000} R=Saitek Pro Flight Rudder Pedals R.GUID={B9DCFE80-8400-11E1-8005-444553540000} Regards Pete

If FSUIPC is used for throttle calibration then it depends how the throttles are assigned. If they are assigned in FSX, or in FSUIPC but to the FS controls (the default), then it intercepts the throttle controls by asking SimConnect for them, at a higher level, modifies the parameters according to the calibration, then sends them on, via SimConnect, at a lower level. Naturally it cannot send them back at the same high level as that would result in a never ending loop. If the throttles are assigned "direct to FS calibration" then the higher level intercept is not needed, so only the calibration and lower level transmission to SimConnect occurs. This is more efficient, naturally, but this method does not suit several more advanced add-on aircraft because they then do not see the FS controls. The PMDG add-ons are prime examples. So, as you can see there are several alternatives and I'm sure one will suit your aircraft. If the aircraft is well behaved with normal uncalibrated throttle inputs there is no reason why the FSUIPC Profile for your aircraft, constructed by the users, cannot simply not have the throttles calibrated in FSUIPC. Assignment should then by either in FSX or in FSUIPC4, but in the latter case to the "axis throttle set" controls, which are the same as those used in FSX assignment. Don't forget FSUIPC allows different settings for different ircraft, selected automatically, so this should present no problems. If FSUIPC is not being used for calibration then it causes no interference with axes. Regards Pete