Pete Dowson

You've set a slope in FSUIPC calibration. If you want it linear, select the linear slope (number 0) -- as shown in one of your pictures, in fact. The reason it starts at "50%" is that is where IDLE is. The lower part, for reverse thrust, is not subject to any slope -- it really isn't needed as the amount of reverse adjustment is normally quite limited. Your "50%" point is calibrated as the "central" idle, which for a throttle incorporating reverse would be calibrated quite low down, towards the pilot, not at the 50% mark of the movement available. With NRZ selected, as you have, the lower part of the response curve is irrelevant -- it isn't used. Only values 0-16383 are sent to FS and you don't get a reverse section at all. In the Calibration page picture you posted I see you have set NRZ, but it must have been recent, and you haven't since then waggled the lever in order to get new IN / OUT readings posted. The OUT value of -4096 is the normal max reverse thrust when NRZ is not selected, and that is showing as left over from before you selected NRZ. If you don't need reverse, and you are only assigning one throttle lever, you should really be using the generic throttle, not the separate Throttle 1. You'd find it easier I'm sure -- less options to consider. I don't understand why you are "going nuts" over this because you don't say. What is actually wrong with your throttle control? You post lots of pictures which i could just as easily have created myself, but don't bother to explain what is actually troubling you about using your throttles. Regards Pete

Received, thank you. It fails here too. However, I can't see how your test module can work in FSUIPC as it stands. It contains Lua C calls, presumably intended to call directly back into the.Lua interpreter bolted into FSUIPC. But it links (imports) from Lua5.1.dll which of course is not being used or supplied, and presumably wouldn't relate to the interpreter in FSUIPC in any case. FSUIPC doesn't export any of the Lua procedures for external C modules to call. By an external DLL module I was of course assuming this was something completely non-Lua, a routine for accessing external hardware or some such. I've obviously been a little naive in this regard, because I now assume you need at least some such callbacks in order to provide the tables of functions or variables provided by the module in the Lua caller. I'm afraid I don't know enough about this side of "normal" (freestanding) Lua to do much very quickly. Can you explain what you think ought to be provided? Do you expect all of the Lua 5.1 lib functions to be exported? And how would the standard Lib file you are linking hook into the resulting FSUIPC exports. You'd presumably need a specific FSUIPC.lib to link against? At present I'm not sure I want to proceed down such a route. I'd need to understand it all first, then try to design something which will work easily without forcing folks to recompile modules for each new update of FSUIPC. It looks like it could be a large project -- as large as my original undertaking to incorporate Lua in fact. I also noticed that the current code searches some weird and wonderful pathnames if you don't get the module correctly identified. I'll probably need to sort that too. Regards Pete

Glad you solved it! Good flying! Regards Pete

Good. Thanks for letting me know. I'll make the release the current one in the Download Links subforum over the wekend. Regards Pete

I did an example Lua for the VRInsight MCP, for handling Mach settings as well as Knots and the changeover. Can you look at that and adapt it to deal with the altitude setting? It should be easy enough. Currently I'm not really in a good position to help. Can you try asking for help with this over in the VRInsight forum? Rhere's some clever chaps doing things like that there. If you haven't got anywhere by the first week in June, when I get back from holiday, get back to me and I'll see what I can do then. I should be able to set up an MCP here then so I can try things (but I don't have QW757). Regards Pete

Good. But I must admit I am now puzzled. You must be using the calibrations for the 4 separate controls, after assigning to Engine 1 only. Why? In your first message you said this: so if you only have the one lever for each, and don't want the reverse area assigned, why not just assign to the generic controls, the ones which cover all engines in any case? Well it's rather a technical point, and quite new, but 99% of users never use the pages you are using. As I said, with one lever for each axis it makes no sense UNLESS you want the reverse functions, and even then single axis users assign to the Generic control then map to the others. Well, that may be so (though I think GoFlight did something similar in any case), but there are many users who still prefer to have the range on those levers and not program the buttons. They are just levers after all, and the real aircraft have levers for those reverse type functions with some degree of adjustability. Not really. I do not really wish to support any Saitek products at all and if I was not thinking of my users I'd have put stops in the program to actively prevent FSUIPC being used for Saitek goods altogether, as Saitek have refused to honour their agreement for FSUIPC licensing, knowing i can't afford legal processes. By all means, if you wish to write things up and post in the User Contributions subforum, feel free. But I truly think you would have been fine if you had used the simple route in the first place. I don't understand how you ended up in the 4-controls sections at all. Regards Pete

Yes. I still don't know what's happening on your system that somehow causes it to lose the KEYUP's, but there was too long a gap before they arrived here, too. So the fix was beneficial to all. There's now a version 3.994, with another small change for a problem in a thread near here where the FSUIPC options dialogue was hanging. It seems that was to do with some rogue joystick driver, but we've not identified it exactly. I'll give it a few days to be sure and upload 3.994 (or whatever) to the Download Links subforum. I'll need to do that before I disappear on holiday later next week. Good flying! Pete

Okay. If that remains so, then there is definitely a driver installed on your system which has no Registry entries defining its device but which responds to a "joyGetPosEx" call with its number by hanging! It might be some old device you no longer have or use, or something you installed by mistake or to try out. Yes, you don't want those. That was just for testing. Yes, but simply copying the new one in would be exactly the same. It would replace it. No, it cannot run if corrupted. It is signed and checked. Regards Pete

From your INI file posting, all those with H. Here, I'll highlight them for you: In the encoding, P=Press (no hold or repeat) H=Hold R=Repeat U=Up, or release Pete

I think this is because some add-on aircraft do their own thing and don't go by FS controls into which FSUIPC can intervene. Since unmoved axes should give no inputs this isn't surprising. The scarce jumps you do get will be jitter, caused usually by dirt or power fluctuations. Sorry, by without any specific knowledge about how the add-on programmer has done things I couldn't really say. Maybe they can help? Wouldn't you be better off sticking to aircraft you know you can work with? The PMDG ones have always seemed very amenable. Regards Pete

There isn't one for FSUIPC3. One was added for FSX as I mentioned. The point is that it is dependent on your altitude and where the wind and cloud layers start and end. With winds you'd need to work out which wind layer you are in then read its turbulence. With clouds you can never really tell. If you have "few clouds" with turbulence you might actually be well outside the nearest cloud, but you can only tell that by looking out of the window. You can find if you are in a cloud layer by its lower and upper altitudes, as with winds, but that doesn't mean you are actually in a cloud. Even the FSX value provided can't distinguish those two conditions, and, worse, it has to guess the cloud upper altitude as FSX doesn't supply that value. That covers two out of the possible n cloud layers -- but one of those should apply to the aircraft altitude, as I think i made one change accordingly. you'd need to check. Sorry, I've not used FS9 for 6 years now. Regards Pete

What? sorry, I don't understand that. Certainly FSUIPC is pressing the Shift if you asked it do. Csan you explain further? Logs? Not knowing what you want to do I can't tell, but you have a lot (and I do mean a lot) of "Holding" buttons, keeping keys pressed for a long time. I don't know why. I could understand if you wanted them to repeat whilst you held a button down, for altering settings continuously and so on, but just holding a press without repeating seems, er, rather odd. You may have reasons for this, but it is unusual. Regards Pete

Okay. First new thing to try. I had a look at the code for joystick scanning on FSUIPC3 and see that it still scans all possible "joy" interface devices, 0 to 15, even though it also now retrieves the DirectInput-assigned names and GUIDs for the "joyNames" list and device lettering. Before the joy lettering option was added, FSUIPC never touched DirectInput, using only the more efficient but more restrictive "joy" API which started way back in Windows 3.1 days or maybe even before. In version 3.994, which you can download here: FSUIPC 3.994 I only scan those joysticks I find listed in the Registry, in the DirectInput data. Maybe this will avoid addressing whatever it is in your system which is hanging the process. Note that the joynames list is rebuilt when FSUIPC loads and each and every time you enter the FSUIPC options. However, it isn't until you enter the Axis or Buttons tabs that all 16 device possibilities were scanned. Regards Pete

Where do you understand that from? That offset is part of a complete structure with multiple levels. You'd need to find the correct layer. The NWI cannot be used without some programming to work out where it is you want data. Please use the "WeatherSet2" program to view data read via the NWI protocol, to check whatever it is you are doing. No, that's not correct either. It's the precipitation at the lowest level. 04CB is one of the old FS98 offsets where there was only one level for precipitation. I think you are getting yourself confused by all the weather data provided. There are several sets (all maintained, as best as can be, for backwards compatibility): The FS98-compatible weather offsets in the 0E9A-0F8C area of offsets. That sufficed for FS98 and FS2000. The Advanced Weather Interface, a protocol based around encoded offsets, designed for fS2002 ff, with localised weather readout and setting for the first time (i.e. weather stations) The NWI, New Weather Interface, introduced with FS2004 and enhanced for FSX, to take advantages of the hugely expanded weather capabilities introduced in FS2004. The latter two involve protocol exchanges for reading and writing, though some structures are also filled in by default, such as weather at the current aircraft position. However, those are still complete structures, with the layered data and so on. C288 seems to be part of the first cloud structure, for the lowest layer. Please just check your readings and decide what it is you need. As I said, WeatherSet2 wil display the data for you, and of course FSUIPC weather logging will show you just about everything. BTW you don't mention version of FS or version of FSUIPC. Please do so next time. If you are using FSX you might be more interested in the new offsets at 0E84-0E88 and 0E94-0E98. Regards Pete

That really sounds so weird. Okay, but i'm not going till Wednesday evening, and will certainly get back to you with something to try before I go. Watch this space please. Regards Pete

You obviously have an FSUIPC axis assignment for the trim as well, and that is sending its own trim settings as you can see (the highlighted lines). Just find it and delete/clear it. Pete

Ah, I remember that. I couldn't reply there (it is locked like all those 'pinned' topics), but i did write to "ronzie" about it asking him to revise it. he said he would, but I don't think he can change it either. Probably got lost in JDs work list. :-( It talks about old unsupported versions of FSUIPC4 and WideClient, too! Regards Pete

Thank you! Pete

Why? Not so. The parameter really should be omitted altogether -- just delete the whole line. As documented, and explained for the umpteenth time it seems, "Yes" forces the use of ASE Weather for FS Metars, the "No" forces it not to use ASE weather, whilst simply omitting it, as per default and as recommended, makes it use ASE weather when it needs to -- i.e. in DWC mode -- but not when it doesn't. The automatic action is best unless you have a jolly good reason to override it. I don't understand why folks are overriding it, and presumably without even reading the documentation about it! Someone has started this nonsense somewhere! :-( Regards Pete

Very strange. I've no idea what could cause that. It still sounds like a rogue joystick driver. I'll look at adding more logging, but without narrowing it down at all so far it isn't going to be easy. I'll have to put a little logging in to narrow it down first, then get more info as we go. I'm away on holiday after next Wednesday, until June 2nd, so if nothing's resolved before Wednesday I'm afraid it's going to be a wait. If it's only the axis assignments tab which gives you problems, why not, for the time being, just use FS assignments for axes? You can still calibrate in FSUIPC. Anyway, I'll try to tackle this later today. Regards Pete

Have you tried any of my suggestions? Certainly, even if all the others fail, the one using the FSUIPC offset should work okay. Pete

Er .. there are no elevators on a throttle quadrant. Do you mean the yoke? If you are getting two different axes reports for one being moved, then one is jittering (interference), probably caused by poor power. Try to park everything else in a clean dead zone. The ignore axes facility works fine, but only until you finish in the assignments tab. FSUIPC only ever assigns one axis at a time. You'd only have to delete anything if you personally assigned to both. The axis being assigned is the one declared at the top, no other. It seems to me, from what you say, that you are still misunderstanding something here. Shame. Profiles are the ideal way of supporting different aircraft types. I think, instead, you simply need to think about what you are doing. Just do one thing at at time. FSUIPC will NOT replace one axis with another once it's recognised one and it most certainly cannot possibly automatically program two at the same time! Pete

I said I'd debug it for you if you sent me something to test. I'll do it on FSX since I'm not set up for FS9 at present. Hmmm. Why not launch FS first then attach to the process from the debugger? I'm using that for FSUIPC4, but I'm still on VS 2003 for FSUIPC3 so that it's libraries etc are the same as those FS9 is using.. Saved a lot of trouble having folks loading more run-times. From your subsequent message: I told you already I'd not tested any of that. I state in the documentation that I've not taken possible incompatible parts out, but may have to do so when and if they are found to crash FS. I've made very few changes at all to the Lua interpreter itself (only things like routing 'print' to the log and making exit terminate only the thread not the EXE), and the module loading stuff is untouched just like most of the rest. It probably needs massaging to fit into the FS environment. I will either remove it completely to avoid further folks complaining, OR I'll try to make it work, as I offered to do if you look back. I am not familiar enough with that part of Lua to construct a test, which is why I asked you to send me whatever it takes and I'll debug it for you here and see if I can fix it. I even gave you my email address so you could send me stuff. Regards Pete

There's really no way it can lose such a setting. But it does have to re-read the INI file on a change of aircraft to see if assignments etc need changing. no. As you can see: That's the only aircraft listed for the Jet profile. FSUIPC shows the profile at the top of the assignments dialogue when one is in operation. You appear to have axes assigned for "Jet" and generic, so the Embraer would use the generic assignments. there are strange anomalies in your assignments in any case. Look at the generic ones first: [Axes] 0=0X,256,D,1,0,0,0 1=0Y,256,D,2,0,0,0 2=0Z,256,D,2,0,0,0 3=0U,256,D,1,0,0,0 4=1X,256,D,4,0,0,0 5=1Z,256,D,6,0,0,0 6=2X,256,D,7,0,0,0 7=2Y,256,D,8,0,0,0 8=2Z,256,D,3,0,0,0 You have two assignments for both Ailerons (0X, 0U) and Elevators (0Y, 0Z), both on the same joystick device! They'll conflict. the Jet profile assignments are also odd: [Axes.Jet] 0=0X,256,D,1,0,0,0 1=0Y,256,D,2,0,0,0 2=0Z,256,D,1,0,0,0 3=0U,256,D,1,0,0,0 4=1X,256,D,4,0,0,0 5=1Y,256,D,22,0,0,0 6=1Z,256,D,6,0,0,0 7=2X,256,D,7,0,0,0 8=2Y,256,D,8,0,0,0 9=2Z,256,D,3,0,0,0 Here you have 3 (THREE!) assignments to ailerons (0X, 0Z and 0U), and one to elevator (0Y). I would guess at the very least you'd get some odd things happening, including axes apparently not doing what you thought! Regards Pete

After calibration, yes. It is FSUIPC which maps whatever range it receives, during your calibration and setting of the end points. to the range required by FS. That's the "OUT" value. In IN values, those from the device, could be any old ything. Where in FSUIPC are you calibrating? The default single Throttle will map any range of inputs to -16k to +16k. On the 4 throttles page it depends how you have set the options. If you don't want reverse and so have set the "No Reverse Zone" (NRZ) options, then the output will run from 0 to 16k. It sounds like you are muddling up INPUT values and OUTPUT values. FSUIPC's calibration will map ANY input range to the correct output range. That is precisely what it is for! If the VC throttle shows at idle, it is at idle -- or maybe you've brought it slightly back and are engaging reverse. Can't you tell? Use the FS 2D throttle quadrant (Shift+4 usually). It's easier to see. No, if you are talking about either IN or OUT values. I think you are a bit confused? Sounds about right if you don't set the NRZ option. I think the 8k position (50%) is a special idle position on some aircraft. Below that it's called something different. Sorry, but it really does sound like you ARE confused. if 0 sets 50%, -16383 must set less! Please please please just follow the numbered steps in the FSUIPC User guide. As far as FSUIPC is concerned ALL axis inputs are the same -- just a run of numbers from x (any x) to y (any y). The process of calibration is really simply to tell FSUIPC how to convert these into values that FS likes. That's all. There's no magic, it is extremely straightforward. IN = the joystick input, OUT = what goes to FS. On the pages with 4 controls each you can have 0 - 16k sent to FS for all forward or positive values, with 0 down to -16k (or more usually something different, like -4k for throttle), or you can use the whole input range for forward (the NRZ option). with those FS treats 0 as 0. This doesn't apply to the single axis-per-control settings (the earlier page), which are only forward: with those FS treats -16383 as 0, 0 would be 50%. But you don't need to worry about it because FSUIPC is dealing with it. All you need to do is set the end points (and centre if you want a central idle, for reverse). Either use the single controls, which are identical to the FS ones, or, if you use the 4 separate controls, set the No Reverse Zone option. Have you tried just assigning in FS first and checking them there, first? If you want to use FSUIPC, please please read the calibration instructions and follow them. Regards Pete