Pete Dowson

Ah, that must be a link to the Schiratti site I mentioned. It is there as a convenience. But that product page is where you BUY the registration key. That's the whole point of that page! No, because that is just about installing, and registering if you already have a key. The user guide is installed for you by the Installer, and if you (please!) read the Installation Guide it does clearly tell you this, right near the beginning, on page 1! No, a mouse is quite different from a keyboard. Key presses are from the keys on keyboards. Pete

Sorry, but you have to go to Elite support. I know nothing whatsoever about their quadrant. It is probably specific to their simulator. Regards Pete

Er ... you cannot download FSUIPC from SimMarket! They don't have it! The download site is www.schiratti.com/dowson. SimMarket only sell the registrations. You pay for it at SimMarket, purchasing it just like any other product there. There's a page for it with all the usual purchase options. I really don't know. Sorry. If you can operate those things with keypresses, then, yes, you can assign keypresses in FSUIPC. You found nothing about where to pay, even though the User Guide has a whole chapter entitled "Paying for FSUIPC4" starting on about page 3 and clearly listed in the Contents list? How could you possibly miss it? Pete

Okay. Done. told you it was easy! ;-) Download 4.644 from the Download Links subforum. The change is this: So, you only need to have events set for offsets 0E88 and 0E98. Okay? Pete

Do all the buttons and switches show as different buttons in FS or FSUIPC for each mode? If so: yes, just by simple assignment as you would in FS. If the answer is no, then it depends on whether the mode switch itself is seen, because then there are ways of setting flags or conditions for each mode. If it is, you can program by INI file editing, using the conditional actions as documented in the Advanced Users document. There's no such thing, that's why. FS's "F2" button is assigned to "Throttle Decr". So the FS command to use is "Throttle Decr" (or, for different engines, ThrottleN Decr where N is the engine number). I'm pretty sure you can assign these in FS as well. And if you look at the FS assignment for the F2 key you would have found the correct command. Sorry, I don't know what you mean by this. Using F2, or using the mouse on the throttle quadrant reversing levers, you can't engage reverse? Pete

Yes, it would scare me to try and do it well in a Lua script. Good. In that case it is quite easy for me to provide just a couple of offsets for you to check -- one for wind turbulence, the other for cloud turbulence (with the provisos I mentioned about the latter inaccuracy). I'll get back to you when it is done, maybe later today else over the weekend. Regards Pete

That's actually much more difficult. It involves searching the cloud and wind layers to find which one the aircraft is within. The offsets you are currently using really only cover a few of the layers possible. Active Sky, among others, sets up to 12 layers. So the correct offsets to read are those of the "New Weather Interface", documented separately in the FSUIPC SDK. The offsets relating to weather at the aircraft position are 0xC000 to 0xC3FF, with: Number of Wind Layers at 0xC0F8, full sets of data for each of up to 24 layers following at 0xC0FC Number of Cloud Layers at 0xC27C, full sets of data for each of up to 24 layers following at 0xC280 You would need to read the aircraft altitude at 0x570 (just the whole number of metres at 0x0574 "SD" would do), then scan the tables of winds and clouds to see which layer you are in, before finally checking that layer's turbulence setting. You would most certainly not want that sort of procedure to be executed every time the aircraft altitude changed a little, nor would monitoring that number of offsets make sense. Additionally if you doing this for FSX then I'm afraid the cloud turbulence will be a bit of a guess, as FSX doesn't supply the actual cloud height (i.e. we get the base altitude, but not the tops). So FSUIPC fills in a nominal value, different for each cloud type. Also, no matter whether it is FS9 orr FSX, you can't really detect if you are actually IN the cloud with turbulence: a cloud layer may only be 2 oktas with lots of blue sky between. I don't know of any way of detecting this without looking out of the window. Quite honestly I wouldn't really attempt any of this for a fully programmed solution outside FS, let alone a Lua script. How important is it? What aircraft has this facility you are trying to make work? Is this for FSX? If it is really important to get this working, the only thing I can think of is for me to add some more offsets which will provide more data on the conditions at the aircraft, without having to scan everything. This isn't too difficult to do for FSX and ESP, but I would be very reluctant to do it for FS9 or before. Regards Pete

But I assume for reverse thrust all you are doing is assigning the button to F2 or "Throttle Dec" and letting it repeat? I don't see how that action has any influence on the axis read-outs. Have you tried Saitek support? Maybe its a problem with the device itself, or their software? Pete

Sorry, but I don't know what Matlab is. If you do I'm sure you should be able to determine this for yourself. Providing you have access to the required Windows API calls and can program reasonably flexibly in Matlab (is it a language?), then I don't see why not. Where have you seen that? It is my preferred language (well, at least C, not C++), but most folks seem to use Visual Basic or one of those new-fangled managed languages in .Net, like C#. The FSUIPC interface is provided, in the SDK, in C source form so could be implemented in any other language by someone who knows both. See the examples in different languages in the SDK, and also the popular .Net interface provided by Paul Henty (Download Links subforum, FSUIPC Client DLL for .NET). Regards Pete

Where did you find the Key Code? They are both together. The Key Code list is in the section on Button Programming ("Format of Button Definitions") with the shift codes explained immediately afterwards. FSUIPC control 1070 is merely using the button programming action internally. Pete

Try refreshing the drop-down list by clicking on the "reload" button. If they are new macro files it will need to re-scan. They don't just "go2. If there are .mcro files in the modules folder, FSUIPC will scan them. Show me the FSUIPC.INI file. That should contain a list of all the .MCRO files in your modules folder. Regards Pete

That is because you are not stopping it. your line: sound.stop("c:\\mysound\\turb.wav") is not doing anything. The stop and query functions need the reference number for the sound which is returned by the play and playloop functions. Please do have another look at the documentation. Each time you play a sound it constitutes a "job" -- something being done. It is the JOB that has to stop. Re-addressing the Wave file doesn't help. It is quite possible to have the same wave being played several times, maybe on different speakers or at slightly different times (eg to simulate echo). The 'ref' number is the reference to the sound job, as documented. The word "ref" used in the documentation is short for "reference". Sorry, but I thought that to be a quite commonly understood abbreviation? Pete

Okay. The fixed versions are now uploaded: 4.643 for FSX and ESP 3.989s for FS9 and before The change is described like this: Regards Pete

Maybe it is because of something EZDOK did to the default assignments? The 1, 2, 3 and 4 keys are normally assigned to "SELECT 1, SELECT 2 ... etc. It is those assignments which the FS facility needs. If they keys are now unassigned, or assigned differently, it would explain the problem. But I don't understand your concern. Surely it doesn't matter because you have the solution, the one you explained? Pete

I don't feel a bright one at present. The fix for this bug reveals another. A lot of the button numbers assigned to the M-Panel overlap with those assigned to the MCP Combi! This might be okay if no one owns both, but the trouble is that to make the fix for the CDU2 work correctly I've had to fix the bug which caused the overlap. This means that most all of the M-Panel buttons change! :-( As far as I can see now all I can do is fix it so it is correct, but provide a fidddle INI-file only option to "retainoldMpanel buttons". i.e. OldMpanelButtons=Yes but defaulting to No, so things are okay for new users. What do you think? Pete

No, sorry, you misunderstand. The names are not mine. They are the strings the firmware in the CDU2 is sending to represent the key-press. You've forgotten all the logging you and others did so I could identify all the names of all the buttons and switches on each device? ;-) I have solved it by assigning 4 button numbers luckily still unused from the previous device in the tables. So SP DEL / and CLR will all have nice shiny new button numbers, but the others all stay the same! I had to include / as it's part of that little sequence. I'll post updated version for both FS9 and FSX later today. Regards Pete

Yes. A stupid error. The problem is in the name matching. The three keys which have the wrong button assignments are supplying the following names: KEYSP KEYDEL KETCLR but FSUIPC's name matching algorithm is matching them to earlier names in the list: KEYS KEYD KEYC I should have put all the longer names at the beginning. The matching is done like this, in general, because often there are other parts following the name, like numbers or + or - which have to be processed separately. The problem I have now is that, to do it properly, I should re-order the list. But that will mean all of the letter keys having their buttons numbers changing, which might upset folks who've already done a lot of work on assignments. So, I'll have to think of another way, maybe an exception in the code somehow. Ugh! Pete

3 seconds is rather a long time. That's a far better solution normally. I don't know. That isn't an FSUIPC function, but an FS one. Possibly Shift+E or the numbers 1-4 have been reassigned, either in FS or FSUIPC? I can't think of any other reason. Regards Pete

Okay ... and how are you detecting that they no longer trigger a "key command"? From everything you say it sounds like FSUIPC is still sending things but the aircraft is then not responding to them. You could tell one way otr the other by using the FSUIPC logging facilities. Log buttons and keys, and Events (though the latter only applies to FS events). Regards Pete

But give 70% FORWARD thrust at the idle position? That makes no sense. Have you checked Saitek support? Pete

Sounds like you have the throttle reversed, or totally un-calibrated. What happens when you push them forward? Pete

So, are you confirming there was no run-time log, and that you don't know where to find the DLL.XML and EXE.XML files? According to this part of the Install log: there was something installed in the DLL.XML before you installed FSUIPC, so the course of action I suggested looks promising. You'll find the DLL.XML file in C:\Users\Ed\AppData\Roaming\Microsoft\FSX and there may or may not be an EXE.XML file there too, depending on what you've installed. I only asked for the Install log if you didn't know where to look for the XML files I mentioned. But now you know so you can proceed ... Regards Pete

To investigate the possibilities just use the Log Lvars lua supplied as one of the examples and installed in your Lua plugins package. That will log (and display on screen) changes to Lvars and you can see if the altitude is one of those you can use. The Lua file itself contains an assortment of Lvar related Lua library functions, so studying that as an example will help. But please also see the Lua library documentation also included in your install of FSUIPC. Me too, but Lua is easy enough, especially for simple scripting of library functions to interact with FS and FSUIPC. Regards Pete

The warninmg about ALT is simply there because effectively, as soon as ALT is seen, the Sim goes into Menu modes after which the keystrokes won't be seen, or even sent if FSUIPC gets stopped because the menu selection goes modal. But ALT+ENTER as a combination is one action so stands a reasonable chance. Regards Pete

You can try sending the ALT+ENTER combination. I've never tried myself, but I don't see why it shouldn't work. It depends on what level FS is decoding it at. You can send keypresses via the 3110 offset. Just use the added FSUIPC control number 1070 with the encoded keypress and shifts, as documented in the Advanced User's guide. But won't that tend to lose the positions for the undocked windows? Especially when used on a multi-screen system. Also, panels are easily undocked when in Windowed mode, but it usually is not possible in full screen mode -- there's no concept of docking in full screen mode. Panel windows are loaded with the aircraft when that is reloaded, and a flight load re-loads aircraft, so whatever way the panels were set when the flight was saved should be the same on the flight load, so whatever you do I can't see how it could make any difference? Regards Pete