Pete Dowson

Er, slow down a bit. Why is this "driver" for the throtle trying to set flaps 0? Please expplain why that should be so. Axes are intercepted in any case unless they are assigned directly in FSUIPC's axis assignments for "direct to FSUIPC calibration". then the axis intercepts from FS are generally not wanted, and can cause problems for some add-ons (like the Level D 767). There's no point because FSUIPC3 always intercepts all axes. It was different on FSX because of the way intercepts have to work through SimConnect. It's a very technical difference, not a difference in user facility. I think you are seeking the wrong solution to a problem which isn't fully explained. If you can go into some more detail, p[erhaps I can see a better solution. Having a driver enforcing flaps 0 does not make any sense to me at all. Regards Pete

You have something wrong there, then. WideFS 6.7 is for FSUIPC3 and FS9 or before, not FSX. You have not enabled the WideServer facility in FSUIPC4. Maybe you've not even registered it via the installer? There is no WideServer.DLL nor WideServer.INI file for FSX. You are failing to read the simple instructions! Not with WideServer.DLL and FSX, they would NEVER have worked together. For FSX WideServer is built into FSUIPC4. Please read the instructions. Regards Pete

Download 6.773, now available via the Downloads announcements. I've added a facility for a page title, with its own colour number (8) and facilities to set two more colours (8 and 9). I've not managed to change the font, though. That involves a *lot* more code which I'm really not willing to get involved in. I'd be very interested in looking at your eventual results. Perhaps I could use than as an example, if you are using all these facilities constructively? What do you think? Regards Pete

Just assign to the Flaps Inc and Flaps Dec controls, instead of Flaps Down and Flaps Up. Then the same rocker can handle any number of steps (like the 4 in the Cessna, the 7 in the 747 and the 9 in the 737). Pete

It sounds like you are using an integer variable. Obviously the end value is going to be small, with many fractional parts, which your integer cannot hold. It would be okay (without the overflow) if you divided by the 65536*65536 before multiplying by 360, but then you'd always get zero (of course)! For anything like this ALWAYS copy the value you are reading into a floating point variable first. Only with floating point will you retain all the accuracy of the original in a useful form. Do the conversion after you have it safe in floating point. Pete

The former -- the "Unused" status is identical to the black reserved spot for the default PREV button on the first page, and the NEXT button on the last (though obviously there wouldn't be any further button numbers to displace in the latter case. The only uses intended for "Unused" were (a) for the old default layout to work the same WITHOUT displacing button numbers, as I now do not have 2 reserved positions on each screen for PREV / NEXT, and (b) possibly to act as layout fillers where you didn't want to waste real buttons but also didn't want to mix functions on the one screen. Don't use them to 'reserve' buttons for later allocation. Best to simply assign those blank labels (a space only -- omittted labels with give you the default, the button number). You can colour them black if you want, as long as you are clear that when clicked they will send the button number to FSUIPC.

Since I don't really know how to do it (and I am loathe to try these things out on a perfectly working system for fear of messing it up), I really don't see myself knowledgeable enough to include anything about it. The current write-up probably needs a warning "not for Vista" if it doesn't already say so! Perhaps if what you are doing does eventually work you could kindly write up the process for us (with references to other websites if really necessary -- though you have to be careful with those as they come and go)? What do you think? By the way, I'm not sure why you deleted all three SimConnect folders. Did you suspect they were all corrupted? The one needed to get FSUIPC (and many other SimConnect client modules) loaded is just the base version, the original from the DVD. Regards Pete

Yes, they are FS Controls. Correct. 1055 is an FSUIPC conttrol, not an FS control, so it doesn't appear in the list of FS controls. The list of FS controls only lists FS controls. And the FSUIPC event logging doesn't include the names for its own controls. Maybe it should. I'll think about that. All FS controls are above 65536. The added FS controls are generally much lower -- excepting offset, macro and Lua controls which use a complex encoding involving all 32 bits. All of the added FSUIPC controls are listed in the Advanced User's guide, under the heading obscurely entitled "Additional 'FS' controls added by FSUIPC". There are 4 added controls to handle the transponder in digit pairs (the FS controls for the transponder handle each digit separately). They are added FSUIPC controls and they are in the list of added FSUIPC controls. That is where you must look! Then you presumably don't have the Advanced users guide. I suggest you re-download the FSUIPC.ZIP from the Schiratti site so you have the complete documentation. Oh, and apologies for not reading your original message carefully enough. I should have spotted that you were referring to the dual digit controls. I think the confusion between "offsets" and "controls" took precedence! ;-) Regards Pete

Your request is rather mixed up. You want offsets for FS controls? FS controls are one thing, FSUIPC offsets are another. You can directly set the transponder value via an offset in FSUIPC -- not increment it or decrement it, but set it, all four digits at once. And this "latest list of FS controls" dated FS2003 MUST have the transponder increment and decrement controls in it because they've been standard in FS since about FS95. On the Schiratti site, where all my programs and FS documents are, there are lists for FS98 and FS2000, both dated 1999, and they are in there, a list for FS2002 dated 2001 and they are in there, and the list for FS2004 dated 2003 and, amzingly, they are still in there. The dates of such documents are from when they were published which, with the exception of FS98, coincide more of less with FS release dates. I don't know why you can't find them -- try using search on "XPNDR". Incidentally, with FSUIPC installed, just enable Event logging then use the keystroke or mouse on the thing you want to find the control for, then look in the Log. That's one of its main uses. Regards Pete

I've never heard of FSX not loading because of SimConnect.dll, because, in fact, FSX itself doesn't use SimConnect.dll -- the programs which use it are add-on applications and plug-ins like FSUIPC. What exactly does FSX say when it won't run? Not "new" folders, just the standard ones in WinSxS. If the base SimConnect one is not there, just run repair or install from the main FSX DVD. "New"? Oh dear. Are you a Vista user? I have no idea how you managed to change the ownership -- I'd love to know how to do that! As a consequence of not knowing I don't know how to change it back either. Sorry. i strongly suspect that it is the change of ownership which prevents FSX from working. The WinSxS folder contains all of the side-by-side library setups used by many many programs, not just FSX and even for FSX not just for SimConnect. I think the C run-time libraries are there too, and many other essential subsystems. I also suspect that by them not being in the correct ownership clobbers the way the Side-by-Side system works. and that's whay FSX (and maybe other things) won't load. I did do a bit of searching on this for you. Take a look at http://www.vistax64.com/tutorials/15936owner.html. It may help. Vista frightens me. It is far far too complicated. Regards Pete

Try turning off the firewall altogether, just as a test. I've never had to "open" Port 8002 -- if Windows tells me Wideclient wants to use the network and should I allow it, I say "yes" with the "don't ask me again" option checked. I wouldn't even know how to enable specific "ports", nor what most programs use for their ports. By the way, you are specifying both the Server IP address AND the name (and protocol) explicitly. Don't provide name AND IPaddress, that's a waste of time. Just use the name. Or better, please note that this message: 16156 Broadcasting service every 1000 mSecs indicates that WideServer is actually sending that information out regularly (on port 9002 by default). If both of your systems are in the same WorkGroup, and both running at least XP, why not let WideFS sort itself out automatically, as intended? Otherwise, sorry, but there's nothing in the logs to indicate anything other than either an incorrect IP address or a firewall blockage. Regards Pete

As Jim says, 3.48 is almost unbelievably old. The current user release is 3.82, and none before that are supported. There's a later increment even than that available in the "Other Downloads" Announcement above. (Version 3.845 at present). Please keep up to date if you want support. Why not read the User Guide for FSUIPC? It tells you all about this stuff. And yes, there is in fact a "graduated visibility" function in FSUIPC which allows you to control the visibility from the top of the normal FS visibility layer up to any set altitude, with the visibility realistically extending from one value to another as you ascend. It is one of the features which, alas, I couldn't continue in FSX. No user facilities in FSUIPC are available to you unless you purchase it and register. Regards Pete

If you've not installed WideFS how do you expect it to see it? No, none at all, because any answers will be in the FSUIPC or WideFS logs. I cannot answer questions on Project Magenta! Sorry. If you want to use PM checking programs and seek answers just from those you have to ask PM support, not FSUIPC support. Show me the FSUIPC Log file -- from a complete attempt, after you've closed FS. If you've not installed WideFS do not try to run PM modules on Networked PCs, only the FS PC. Oh, one other thing. If you are trying to run FS in elevated Administrator mode (i.e. "run as administrator"), don't -- only do this to Register. If you really have to run it that way (ugh!) then EVERY other add-on you run which needs access to FS via FSUIPC needs also the same privilege levels, because Vista will otherwise prevent them sharing any data. Pete

This is exactly what I've done in version 4.328, now available in the FSX Downloads announcement. I've tested it with most FSX default aircraft, and I even managed to find and install a copy of the PMDG 747X which Lefteris sent me a while back when we were testing the effects of turbulence on the LNAV function. It seems to work fine with that too now! (I forgot i had it -- I searched my archives and there it was! ). Regards Pete

Okay. Found it, thanks. It was quite complex. I'd extended the internal arrays to allow not only the 288 buttons but now also the entries for the Goto, Previous, Back and unused entries. Because this can run to many more than 288 I extended it quite a lot, but even so I was overrunning it because my algorithm failed to check the correct conditions to stop filling in the tables. i.e when a page is full AND we've already got or passed button 287. Oddly it didn't go wrong with any off my examples. Yours was far more elaborate than anything i have and failed easily! ;-) The computation of the dimensions (16 x 7 instead of 12x4) occurred because the first thing getting overwritten was the 12 x 4 values. These became 0 x 0 which is the same as omitting the Size parameter. When the size parameter is omitted it computes using a default cell size. The other odd effects are also explained, I think (and hope) by the overwriting of other values sometimes. Please try 6.772: http://fsuipc.simflight.com/beta/WideClient6772.zip Regards Pete

Not so easy in FS9 of course. In FSX SimConnect provides it via the "INIT POSITION" facility, which is also driveable via the FSUIPC IPC offsets interface. In fact there is a demonstration of this in one of the Lua plug-ins provided in the Lua package (see announcements). I'm not surprised! They are just two halves of a double (64-bit) floating point value. Working out what they mean is no easy task -- do you even know the Intel 64-bit floating point representation standard? I don't offhand. And even then it isn't easy. Why not use the actual number you want, in floating point, and write that? I don't know why you are messing with weird hexadecimal strings instead of proper easy-to-compute numbers (nor do I understand why timsc posted such an example). Well that's obviously because you are writing some integer (why?) into the lowest (i.e. LEAST SIGNIFICANT) 32 bits of a 64-bit floating point number. So you will certainly be influencing it, but by a very very small fraction of a knot! You are evidently not checking the result accurately enough to see the difference! ;-) Change your pIAS integer into a double floating point value (however that might be declared in Delphi) and write 8 bytes not 4. Then you can work on the knots to ft/sec conversion. Pete

Got back early so before I have to go out again I'm catching up a bit. Aha! At least it sohws clearly how it gets to full flaps: 213237 LUA: Param = 15872 gives Handle = 13653 and Flap Index 5 214236 LUA: Param = 16384 gives Handle = 16383 and Flap Index 6 So even values as high as 15872 still only give Flaps 25, despite the proper spacing which should be allowed being, what was it? 5460. I would have expected and hoped for at least half of that be allowed for Flaps 30! Well, that's one good thing, anyway. At least that means the PMDG modelling hasn't destroyed the relationship between its flap positions and the SimConnect indices. Hmm. Could be a side effect of some corrections to make flaps work properly on some of the default aircraft. Maybe my adjustment by 128 -- the one now giving the uneven increments. I can't keep changing things back and forth, fixing one and breaking another. I need to look for a solution that works for everything. I'll examine your figures more closely, see what I can come up with. [LATER] After a cursory glance through those last results, and comparing it with the values FSUIPC sends out, I see that each of my selections are right on the lowest edge of the ranges PMDG computes! Very dodgy. Maybe it worked before, but it must have been a close shave! It appears as if, rather than selecting ranges where the central value is the one with the correct 5461 increment, they've used that increment to determine the CHANGEOVER point! Seems to deliberately be made critical! I would guess that they never even bothered to look at how FS itself interpreted the values! Very sloppy programming in my opinion -- surprising for PMDG! I'll experiment with making my choices, instead of near central to me computed ranges, something like 75% of the way though. That should put them safely within the lower half the PMDG ranges without upsetting any other aircraft. At the same time I'll force 0 flaps to be minimum value and full flaps to be maximum - they obviously allow no leeway at all in the latter case! Regards Pete

What ideas have you tried so far? For example, have you contacted IOCARD or SIOC support? Have you checked the Logs for FSUIPC and WideServer and WideClient? If you want help here you have to provide more information, else we have no idea. For example: Version of FS Version of FSUIPC Version of WideFS Version of Windows Where you are running this "IOCARD" or "SIOC" Contents of the relevant Logs -- FSUIPC for local FS running of IOCARD or SIOC, WideClient and WideServer for network use. Pete

For what purpose, exactly? You cannot change the True Air Speed (TAS) directly in FS in any case, and the TAS value provided in only a normal 32-bit integer in any case. What's all this about "Hi" and "Lo" numbers? If you really mean the Z (longitudinal) GS velocity relative to the body axes, in offset 3090, then, as documented this is a standard 64-bit (8 byte) double floating point value. Don't deal in "Hi" and "Lo" or anything like that. Just use standard floating point, supported by all languages. This velocity is in feet/sec so you obviously need to convert knots to feet/sec, that's all. 1 knot = 1 nautical mile per hour. There are 3600 seconds in an hour and an easily-look-uppable number of feet in a Nautical Mile (try Wikipedia), so the arithmetic is easy enough. Regards Pete

I'm not really understanding that. To start with I've made no changes whatsoever to any of the code conncerning the Window or the button sizes or demarcations. All of the changes are concentrated in one small area, that of what is drawn in the buttons already existing. I cannot make it go wrong here, so I need your help in identifying what is going on. To start with can we clarify, please, what it is you are saying above? First, by "size" parameter do you mean the numbers of buttons across and down, or do you mean the saved Window size? Second, are you saying that even with a specification of "12 x ?" for the matrix, it is giving you "16 x ?" ...? If so that is truly weird. The number is used, as it always has been as a divisor into the wideth of the available window space. >> If I try to resize the window by "grabbing" the corner then one of 2 things happen; either the screen will go completely white (with no previous/next buttons) or completely black except for the next/previous buttons in the corner. In this latter case the buttons revert to the original, larger size. << Again, that is truly strange. It is working fine here. When the window is re-sized it re-reads all the parameters, a feature I used extensively in testing it. Thanks. But I only need your ButtonScreen parameters, to see what the &£$%!@# is going on, and you've omitted it all except the "size=12,4" line! Surely there's more? If it is "secret" maybe you could email it to me at petedowson@btconnect.com. I really cannot do anything without the parameters which are causing the problem! I'm surprised you can't see that! Regards Pete

This is even more puzzling. The maximum for the reported position of the Flap Lever by SimConnect was 13653, which, on the default 747, equates to Flaps 25. Maybe you need to move that Sleep and increase it substantially. Maybe the Flaps readings I'm getting back are more delayed with the PMDG. Try and increment of 512 instead of 256 and increase the Sleep to 1000 (1 second between each) -- and move the Sleep line to just after the Control line, so it now looks like this: n = -16384 while n &lt; 16384 do n = n + 512 ipc.control(66534, n) ipc.sleep(1000) flapctrl = ipc.readUW(0x0BDC) flapindex = ipc.readUB(0x0BFC) ipc.log(string.format("Param = %d gives Handle = %d and Flap Index %d", n, flapctrl, flapindex)) end Oh, one other idea. If you go to the Logging tab and disable the Lua logging but select the Log console display, then run FSX in Windowed mode with the console log display visible as well as the Throttle Quadrant, you will see the log entries from the Lua program at the same time as the lever moves and you can make a note of which line (by time, very left on each line) equates to which visible position. I've really currently got no idea how to solve this. I hope we get some useful, non-conflicting, information. Anyway, you just caught me before bed. It's nearly 3 am here. I'll be out tomorrow. Regards Pete

I just realised that the "ipc.Sleep(250)" line needs to immediately follow the "ipc.control" line to give time for the flaps to operate before reading the flap index (the control position should be okay, as that's immediate). Maybe also the delay needs to be more. But all that it would only affect the fringes of each range. We want to aim for near the centres if at all possible. Regards Pete

But I've only changed the top value, nothing else. That makes no sense at all! :-( What are the numbers you are seeing now? I really don't know how to solve something with a shifting interpretation. Something is weird with that aircraft. [LATER] It just occurred to me that perhaps the interpretation of the values by the PMDG aircraft is much worse than we thought. The only feasible explanation for the change you have seen is that one of the others is actually being ignored. Something like this: -16383 which should be UP os okay -11052 which should be Flaps 1 is okay but which may in fact be also giving flaps UP? -5592 which should be Flaps 5 is okay but which maybe giving 1 -132 which should be Flaps 10 but which may be giving 5 5328 which should be Flaps 20 but which may be giving 10 10788 which should be Flaps 25 but may be giving 20 16254 which should be Flaps 30 but is actually giving 25 That's only one possibility. In fact any one of them apart from the first and last may be being ignored (or rather not differentiated). I'm sorry, but I really cannot do anything without more information. I'm going to have to ask you to run some tests. We can do this best with a little Lua program. So, save the following in the Modules folder as "TestFlaps.lua": n = -16384 while n &lt; 16384 do n = n + 256 ipc.control(66534, n) flapctrl = ipc.readUW(0x0BDC) flapindex = ipc.readUB(0x0BFC) ipc.log(string.format("Param = %d gives Handle = %d and Flap Index %d", n, flapctrl, flapindex)) ipc.sleep(250) end Then go to FSUIPC options, enable Lua logging in the logging page (so it gets its own Log file -- else it'll share the FSUIPC4 one), the in the Keys or Buttons page, Reload Keys or Buttons (ro get the Lua file seen), then assign a key or button to "Lua TestFlaps". Also "Reset" the Flaps calibration in FSUIPC4's calibration page -- otherwise it will work on these controls and we won't get the real picture. Back in FSX, use the button or key to run the test. Watch the flaps lever. I put the Sleep in there to slow things down a little -- the test should take 128 x 250 mSecs, or 32 seconds (roughly). The reason for the sleep is so you can watch it if you want, and of course to give time for the lever to move. After, check the Modules folder for "TestFlaps.log". Show it to me. Here's the result for the default 747. The lines I then marked <<<<< are those closest to the values FSUIPC4 is computing using increments. As you can see, with the exception of the two extremes (full down and full up), these are reasonably near the centre of each range. I could afford a slight shift, probably upwards. 2377281 LUA: Param = -16128 gives Handle = 0 and Flap Index 0 &lt;&lt;&lt;&lt;&lt; 2377625 LUA: Param = -15872 gives Handle = 0 and Flap Index 0 2377969 LUA: Param = -15616 gives Handle = 0 and Flap Index 0 2378266 LUA: Param = -15360 gives Handle = 0 and Flap Index 0 2378531 LUA: Param = -15104 gives Handle = 0 and Flap Index 0 2378797 LUA: Param = -14848 gives Handle = 0 and Flap Index 0 2379125 LUA: Param = -14592 gives Handle = 0 and Flap Index 0 2379406 LUA: Param = -14336 gives Handle = 0 and Flap Index 0 2379734 LUA: Param = -14080 gives Handle = 0 and Flap Index 0 2380078 LUA: Param = -13824 gives Handle = 0 and Flap Index 0 2380328 LUA: Param = -13568 gives Handle = 0 and Flap Index 0 2380688 LUA: Param = -13312 gives Handle = 2731 and Flap Index 1 2380938 LUA: Param = -13056 gives Handle = 2731 and Flap Index 1 2381188 LUA: Param = -12800 gives Handle = 2731 and Flap Index 1 2381563 LUA: Param = -12544 gives Handle = 2731 and Flap Index 1 2381828 LUA: Param = -12288 gives Handle = 2731 and Flap Index 1 2382078 LUA: Param = -12032 gives Handle = 2731 and Flap Index 1 2382438 LUA: Param = -11776 gives Handle = 2731 and Flap Index 1 2382688 LUA: Param = -11520 gives Handle = 2731 and Flap Index 1 2382938 LUA: Param = -11264 gives Handle = 2731 and Flap Index 1 2383234 LUA: Param = -11008 gives Handle = 2731 and Flap Index 1 &lt;&lt;&lt;&lt;&lt; 2383484 LUA: Param = -10752 gives Handle = 2731 and Flap Index 1 2383734 LUA: Param = -10496 gives Handle = 2731 and Flap Index 1 2384094 LUA: Param = -10240 gives Handle = 2731 and Flap Index 1 2384406 LUA: Param = -9984 gives Handle = 2731 and Flap Index 1 2384656 LUA: Param = -9728 gives Handle = 2731 and Flap Index 1 2384906 LUA: Param = -9472 gives Handle = 2731 and Flap Index 1 2385156 LUA: Param = -9216 gives Handle = 2731 and Flap Index 1 2385516 LUA: Param = -8960 gives Handle = 2731 and Flap Index 1 2385797 LUA: Param = -8704 gives Handle = 2731 and Flap Index 1 2386109 LUA: Param = -8448 gives Handle = 2731 and Flap Index 1 2386391 LUA: Param = -8192 gives Handle = 2731 and Flap Index 1 2386719 LUA: Param = -7936 gives Handle = 2731 and Flap Index 1 2386984 LUA: Param = -7680 gives Handle = 5461 and Flap Index 2 2387250 LUA: Param = -7424 gives Handle = 5461 and Flap Index 2 2387500 LUA: Param = -7168 gives Handle = 5461 and Flap Index 2 2387813 LUA: Param = -6912 gives Handle = 5461 and Flap Index 2 2388078 LUA: Param = -6656 gives Handle = 5461 and Flap Index 2 2388438 LUA: Param = -6400 gives Handle = 5461 and Flap Index 2 2388703 LUA: Param = -6144 gives Handle = 5461 and Flap Index 2 2388953 LUA: Param = -5888 gives Handle = 5461 and Flap Index 2 2389219 LUA: Param = -5632 gives Handle = 5461 and Flap Index 2 &lt;&lt;&lt;&lt;&lt;&lt; 2389563 LUA: Param = -5376 gives Handle = 5461 and Flap Index 2 2389828 LUA: Param = -5120 gives Handle = 5461 and Flap Index 2 2390094 LUA: Param = -4864 gives Handle = 5461 and Flap Index 2 2390344 LUA: Param = -4608 gives Handle = 5461 and Flap Index 2 2390594 LUA: Param = -4352 gives Handle = 5461 and Flap Index 2 2390844 LUA: Param = -4096 gives Handle = 5461 and Flap Index 2 2391188 LUA: Param = -3840 gives Handle = 5461 and Flap Index 2 2391438 LUA: Param = -3584 gives Handle = 5461 and Flap Index 2 2391797 LUA: Param = -3328 gives Handle = 5461 and Flap Index 2 2392047 LUA: Param = -3072 gives Handle = 5461 and Flap Index 2 2392391 LUA: Param = -2816 gives Handle = 5461 and Flap Index 2 2392641 LUA: Param = -2560 gives Handle = 5461 and Flap Index 2 2392891 LUA: Param = -2304 gives Handle = 8192 and Flap Index 3 2393219 LUA: Param = -2048 gives Handle = 8192 and Flap Index 3 2393469 LUA: Param = -1792 gives Handle = 8192 and Flap Index 3 2393734 LUA: Param = -1536 gives Handle = 8192 and Flap Index 3 2393984 LUA: Param = -1280 gives Handle = 8192 and Flap Index 3 2394391 LUA: Param = -1024 gives Handle = 8192 and Flap Index 3 2394703 LUA: Param = -768 gives Handle = 8192 and Flap Index 3 2394969 LUA: Param = -512 gives Handle = 8192 and Flap Index 3 2395234 LUA: Param = -256 gives Handle = 8192 and Flap Index 3 &lt;&lt;&lt;&lt;&lt;&lt; 2395578 LUA: Param = 0 gives Handle = 8192 and Flap Index 3 2395844 LUA: Param = 256 gives Handle = 8192 and Flap Index 3 2396094 LUA: Param = 512 gives Handle = 8192 and Flap Index 3 2396500 LUA: Param = 768 gives Handle = 8192 and Flap Index 3 2396797 LUA: Param = 1024 gives Handle = 8192 and Flap Index 3 2397047 LUA: Param = 1280 gives Handle = 8192 and Flap Index 3 2397391 LUA: Param = 1536 gives Handle = 8192 and Flap Index 3 2397641 LUA: Param = 1792 gives Handle = 8192 and Flap Index 3 2397891 LUA: Param = 2048 gives Handle = 8192 and Flap Index 3 2398156 LUA: Param = 2304 gives Handle = 8192 and Flap Index 3 2398406 LUA: Param = 2560 gives Handle = 8192 and Flap Index 3 2398750 LUA: Param = 2816 gives Handle = 8192 and Flap Index 3 2399000 LUA: Param = 3072 gives Handle = 10922 and Flap Index 4 2399250 LUA: Param = 3328 gives Handle = 10922 and Flap Index 4 2399516 LUA: Param = 3584 gives Handle = 10922 and Flap Index 4 2399766 LUA: Param = 3840 gives Handle = 10922 and Flap Index 4 2400016 LUA: Param = 4096 gives Handle = 10922 and Flap Index 4 2400266 LUA: Param = 4352 gives Handle = 10922 and Flap Index 4 2400516 LUA: Param = 4608 gives Handle = 10922 and Flap Index 4 2400766 LUA: Param = 4864 gives Handle = 10922 and Flap Index 4 2401109 LUA: Param = 5120 gives Handle = 10922 and Flap Index 4 2401359 LUA: Param = 5376 gives Handle = 10922 and Flap Index 4 &lt;&lt;&lt;&lt;&lt;&lt;&lt; 2401625 LUA: Param = 5632 gives Handle = 10922 and Flap Index 4 2401891 LUA: Param = 5888 gives Handle = 10922 and Flap Index 4 2402141 LUA: Param = 6144 gives Handle = 10922 and Flap Index 4 2402391 LUA: Param = 6400 gives Handle = 10922 and Flap Index 4 2402656 LUA: Param = 6656 gives Handle = 10922 and Flap Index 4 2402906 LUA: Param = 6912 gives Handle = 10922 and Flap Index 4 2403188 LUA: Param = 7168 gives Handle = 10922 and Flap Index 4 2403438 LUA: Param = 7424 gives Handle = 10922 and Flap Index 4 2403688 LUA: Param = 7680 gives Handle = 10922 and Flap Index 4 2403938 LUA: Param = 7936 gives Handle = 10922 and Flap Index 4 2404297 LUA: Param = 8192 gives Handle = 10922 and Flap Index 4 2404547 LUA: Param = 8448 gives Handle = 10922 and Flap Index 4 2404797 LUA: Param = 8704 gives Handle = 13653 and Flap Index 5 2405047 LUA: Param = 8960 gives Handle = 13653 and Flap Index 5 2405297 LUA: Param = 9216 gives Handle = 13653 and Flap Index 5 2405563 LUA: Param = 9472 gives Handle = 13653 and Flap Index 5 2405813 LUA: Param = 9728 gives Handle = 13653 and Flap Index 5 2406063 LUA: Param = 9984 gives Handle = 13653 and Flap Index 5 2406313 LUA: Param = 10240 gives Handle = 13653 and Flap Index 5 2406672 LUA: Param = 10496 gives Handle = 13653 and Flap Index 5 2406922 LUA: Param = 10752 gives Handle = 13653 and Flap Index 5 &lt;&lt;&lt;&lt;&lt;&lt; 2407266 LUA: Param = 11008 gives Handle = 13653 and Flap Index 5 2407516 LUA: Param = 11264 gives Handle = 13653 and Flap Index 5 2407781 LUA: Param = 11520 gives Handle = 13653 and Flap Index 5 2408125 LUA: Param = 11776 gives Handle = 13653 and Flap Index 5 2408375 LUA: Param = 12032 gives Handle = 13653 and Flap Index 5 2408750 LUA: Param = 12288 gives Handle = 13653 and Flap Index 5 2409094 LUA: Param = 12544 gives Handle = 13653 and Flap Index 5 2409344 LUA: Param = 12800 gives Handle = 13653 and Flap Index 5 2409625 LUA: Param = 13056 gives Handle = 13653 and Flap Index 5 2409906 LUA: Param = 13312 gives Handle = 13653 and Flap Index 5 2410250 LUA: Param = 13568 gives Handle = 13653 and Flap Index 5 2410500 LUA: Param = 13824 gives Handle = 13653 and Flap Index 5 2410750 LUA: Param = 14080 gives Handle = 16383 and Flap Index 6 2411016 LUA: Param = 14336 gives Handle = 16383 and Flap Index 6 2411359 LUA: Param = 14592 gives Handle = 16383 and Flap Index 6 2411625 LUA: Param = 14848 gives Handle = 16383 and Flap Index 6 2411906 LUA: Param = 15104 gives Handle = 16383 and Flap Index 6 2412156 LUA: Param = 15360 gives Handle = 16383 and Flap Index 6 2412406 LUA: Param = 15616 gives Handle = 16383 and Flap Index 6 2412672 LUA: Param = 15872 gives Handle = 16383 and Flap Index 6 2412938 LUA: Param = 16128 gives Handle = 16383 and Flap Index 6 2413188 LUA: Param = 16384 gives Handle = 16383 and Flap Index 6 &lt;&lt;&lt;&lt;&lt; At this stage, I'm not even sure there will be values which work for "normal" aircraft and the PMDG 747. There may be a need for the notch calibration not only to define the places on the lever for detentes, but also the values to be associated with each. Ugh. I do hope not. Things are complicated enough as they are. Let's see your results. Unfortunately I'm out all tomorrow, so it won't be till Saturday (maybe very late Friday) I'll be able to taker a look. Regards Pete

Good. Something must have been a bit strange in 4.30. Sorry. I've been doing a lot of work on FSUIPC since then, so it is always best to re-check with the very latest. Regards, Pete

Yes, of course. Please work out the maximum you are likely to need (looking to the future as well). Keep to a multiple of 16 -- so, 16, 32, or 48. Then please send me an email (to petedowson@btconnect.com) with the project/product name, for my records, and i will send you the offset range details. Regards Pete