Pete Dowson

The mystery is solved. I received all your details by email. You purchased keys for FSUIPC3 and WideFS6 but you are trying to register in FSUIPC4's installer. They are separate products with separate keys. The purchase sites are actually clearly labelled. I should have spotted this earlier when you said you were using 4.742 after I said the latest was 3.998h (scan back and see). Sorry, my error there -- comes of dealing with so many posts in different forums all the time. when I see a new reply I don't always remember the full context. It would have been at the time you downloaded it. It is 4.745 now. But that's for FSX, ESP and Prepar3D. For FS9 and before you need to download FSUIPC3, the latest installer being 3.998g. Regards Pete

Sorry, I don't understand. What is PL? And how do you get a "full stop" while airborne? Are you simply saying you don't want the throttle value to go below a certain positive value whilst in the air, no matter what you do with the throttle lever? Assuming I understand correct;y, 1b would be the easiest in any case. Have the Lua loaded and run automatically using the [Auto.<name>] section in the FSUIPC INI file -- aircraft or profile specific so it only applies to the one aircraft. Make it event driven, on changes to whichever of offsets 332E to 3336 are applicable (generic throttle, and throttles1 to 4). You need to set the relevant bit(s) in offset 310A-310B, to disconnect the relevant throttles, and you also need a timer event at, say, 5 seconds (5000 mSecs) to refresh that.. Then, on intercepting the throttle offset changes, check you are airborne (offset 0366 == 0), and if so check the throttle value provided, and if it is lower than your flight idle, change it to flight idle, then, either way, write it to the correct throttle offsets (088C or as appropriate). If writing to the throttles directly doesn't work for the particular aircraft (and this is possible if it is doing its own throttle control based of FS Control inputs), you'd need to send it by FS control instead. For that you'd probably need to scale the result back to the -16k to +16k range (i.e. x2 then -16k). Please do make sure you use the latest FSUIPC version (see Download Links subforum) for this, as the 332E-3336 offsets have had a few problems of late which I've only just sorted properly. Regards Pete

It isn't a control, but a value. Variables are not controls! (In the SDK controls are called 'events'). it is available through FSUIPC offset 0B00, as it always has been in fact, and is usually either 0 (idle), or for those aircraft with reverse thrust on the throttle control, something like -4096, but varying depending on the value provided by the Aircraft.CFG file. (for example -0.25 there is -4096, as the possible throttle range is -16384 to +16383). This value is automatically used as the minimum value (max reverse thrust if you like) applied by FSUIPC's reversers and reverse zone throttle calibrations. And it isn't new in ESP, it's been available in FS and FSUIPC for many FS versions, at least as far back as FS98 I think. Regards Pete

That should be okay, though there is a later version of the Installer (4.745) it would make no difference as far as registration is concerned. Did you check the date on your PC? If the is incorrect it may prove a problem, though usually that doesn't make the registration appear invalid, but simply causes FSUIPC to malfunction as it does if a pirated key is used. I used your details, exactly, copied and pasted from the same details you should be using, and had no trouble registering. The response "invalid code" to your registration attempts just has to be a mis-entry of some sort. It is such a simple algorithm really, and hasn't been changed for years because it simply works. Maybe when you copy and paste you are including extra characters, like a space or something? If you want to go private so you can show other details, my email address is petedowson@btconnect.com. Regards Pete

Versions 4.70 and later connect to Simconnect in a different way, avoiding many of the problems folks get with the Windows Side-by-side library system (WinSxS). It sounds like you have some sort of such problem with your FSX installation -- something which happens very easily if you ever try to uninstall and reinstall FSX (the uninstaller makes a hash of it). Regards Pete

Can you tell me what version of FSUIPC you are attempting to register? If it isn't a recent one it may simply be that you are using one with the signature expired. The earliest supported version at present is 3.99 and there's a 3.998g installer and 3.998h update available now (see the Download Links subforum). Also please check that the date set in your PC is correct. Found it. I'll check it here too. Regards Pete

0BB2, 0BB6 and 0BBA are working fine here. They are used by my own controls. I really cannot support such an old version. The current version is 4.745 (with an update to 4.746 in the Download Links subforum), and the earliest version which is supported is 4.70. A rather uninformative part too. Look nearer the beginning. Are there any problems with SimConnect logged? Why on Earth are you reading 2048 bytes? First, update your FSUIPC installation. You can get the 4.745 installer here, in the Download Links subforum, or you can go to the Schiratti site. Second, if there is still a problem, show me the Install log and the FSUIPC log -- but not with all IPC Reads and Writes logged., please. That will cloud the issue too much. Better to use the Monitor facilities on the right-hand side of the Logging tab. Put 0BB2 and 0BB4 there, both as S16 type. I've just done that and written first 5000 (your hex 1388) and then -5000 to 0BB2, via FSInterrogate. I can see the effect on the elevator, and the results are confirmed, in the Log, by the SimConnect readouts logged. See here: 642156 Monitor IPC:0BB2 (S16) = 5000 642172 SimRead: 0BB2="ELEVATOR POSITION" FLT64: 0.30517583956 642172 Monitor IPC:0BB4 (S16) = 2726 642172 SimRead: 0BB4="ELEVATOR DEFLECTION PCT" FLT64: 16.638187499 671375 Monitor IPC:0BB2 (S16) = -5000 671375 SimRead: 0BB2="ELEVATOR POSITION" FLT64: -0.305236993926 671375 Monitor IPC:0BB4 (S16) = -2726 671375 SimRead: 0BB4="ELEVATOR DEFLECTION PCT" FLT64: -16.6427727652 Regards Pete

Iron cokpit's problem was using an invalid key or other details. If your registration is rejected outright as invalid, the same applies to you. You are mis-entering something. Did you also paste the name and email address? Because a mistake or difference in any of the three parts will have the same result. There's no information there for me to use. Certainly, do NOT post your Key, but i could do with a name at least. Using a false name like "McF" doesn't really help at all. No, they are not relevant. Pete

Sorry, i need to know more to be able to help you. What offsets are you using? What version of FSUIPC? "Reinstalling" FSUIPC only replaces FSUIPC4.DLL with FSUIPC4.DLL, which cannot change anything unless you are also changing versions. If the DLL was itself corrupted then it wouldn't run -- you'd get an error message in the Log as its signature check would fail. More likely that you have some SimConnect problem. but without information I cannot really advise further. Please check the FSUIPC log -- in fact, use logging. that's what it is for, to help you diagnose problems and obtain information. Regards Pete

You want an altitude hold which is stable, then. It doesn't have to be a specific altitude, surely, just one holding steady enough once you've got into the right position to receive the nozzle? Regards Pete

Sorry, I've no idea about GoFlight's own software. I think it needs to interface directly to FSX, but if it uses SimConnect it might work remotely too. I'm pretty sure it doesn't use FSUIPC and therefore not WideFS either, at least for FSX. The FSUIPC support for GoFlight devices is separate and only needs the GFDev.DLL interface which would normally also get installed with their software but which can also be downloaded separately from the Download Links subforum here. Ah, so you do mean using FSUIPC for assignments, and/or Lua gfd library support? When you said "have the Go Flight modules operational" I thought you might be referring to their own drivers, not the interface DLL. Yes, you can do what you say, or simply download GFDev.DLL from here and put it into the WideClient folder. If it were possible, which i don't know I'm afraid, I doubt that you'd notice much difference. The main reason to use networked PCs for hardware instrumentation would be when video displays are involved (which would take resources from FSX), or simply because of the location of things in a cockpit, to avoid overlong USB cables needing boosters. Regards Pete

Hey, that looks nifty. I'll be trying that myself! Thanks! Pete

You can avoid all that sort of bother by using joystick lettering instead of numbering. The numbers can be changed by Windows if you unplug devices, especially if you plug them in differently next time. Please check the chaapter in the user guide for this, it is entitled something like "Keeping track of multiple control devices". Once you use that you'll not have similar problems again. I very much doubt that simply unplugging things and plugging them back in has changed anything other than the numbers of the devices. Instead of starting again trying to reassign you would have been better off editing the INI file just changing the numbers to suit the new Windows assignments -- they are listed in the INI in a section called [JoyNames]. Before doing anything else, change to using the letters. Then you'll have to work out which device to assign for what all over again I suspect. I you still had your pre-disaster INI it would have been a lot easier to sort out, comparing the new numbers with the old. Regards Pete

LOL! Make it 100. 10 is too easy! ;-) Pete

Ah! It will look like the LuaSet command, so "LuaSet Fuel". Sorry, I hadn't noticed that. I don't think spaces are so relevant. I'll make a note to see if that can be changed so that the position of the space is important. Not sure why it is different in Key assignments as opposed to Auto entries. That's a bit strange as the same parsing code is used. (I'll have to do something about it, as the documentation for [Auto] actually uses a name starting with 'Set' as an example! :-( ) Regards Pete

No, but you could write a script to detect aircraft changes and run/rerun Lua packages that way. Or if all you are after is restarting the script on an aircraft change, build such a test into that script. There's an AIR file change counter at offset 32FC, and of course you can read the aircraft name in 3D00. The first flight is the one loaded when FS is ready, not when you go into the Flight menu to load one. Regards Pete

I'm surprised it is that high. FS is simply not designed to support such use. Each time you undock a window you lose performance. It doesn't matter how fast the video cards are, and SLI/Crossfire doesn't help -- if anything it makes it worse. Unless you get your processor running at speeds over 5 GHz (possible with very good cooling, i7-2600K, and nVidia GTX580 3Gb video cards (or ATI equivalents) all round, I don't think you'll get usable frame rates. And even then you'll need to cut down on scenery and aircraft complexity -- or go for liquid nitrogen cooling and 7+ GHz processor speeds. For undocked scenery windows the only answer really is networked PCs using FSX+WidevieW. For instrumentation there are many good packages providing external gauges and so on across networked PCs. Regards Pete

I think if you used a parameter of 200 it would increase by 200. It is simply that the minimum increment or decrement it actually uses is 100. Is this with FSX or FS9, or some other simulator? With FSX all changes go through SimConnect in any case, so it makes no difference -- and FSUIPC only supplies one offset in any case to adjust the A/P altitude. Note that the actual value in FS may well be changing -- I don't know whether the A/P will fly according to that precise altitude setting or not, though. It may only be the value fed back to the gauges which is kept to multiples of 100. I doubt it though. As I said in the first place, I don't think an altitude set to within 10 feet has any meaning in any case. It simply is not possible to set the altimeter more accurately than 1 hPA which means it could be 15 feet out either way in the first place, and that's assuming you do actually know the QNH all the time at your position and you constantly check and keep it correct.. And in fact the precise QNH at any point is also not determinable in reality -- all you can get is reports from nearby weather stations, usually delayed. A possible variation therefore, in my opinion, of at least 50 feet is likely, making 100 foot increments eminently sensible. So why do you want to achieve something not even possible in reality? What's the point? Regards Pete

Starting and ending of Lua plug-ins is also logged when you select "button and key operations" logging. This is because, apart from the [Auto] facility, that is how they would usually be started or stopped. The generic [Auto] only loads once, initially when FS is ready to fly. Only aircraft or profile specific sections [Auto.<name>] load on aircraft loads, when the name or profile applies. Also don't forget that aircraft or profile specific ones only re-execute on a CHANGE of aircraft or profile, not reloading or loading one of the same match. What version of FSUIPC are you using? Until recently there was also a bug where even the aircraft/profile specific sections didn't work unless you also had an [Axes], [JoystickCalibrations], [buttons] or [Keys] specific section too (though not necessarily for the same aircraft/profile). You could paste your [Auto... sections here for me to check if you wished. Regards Pete

Yes, that is the list of joystick IDs which are assigned by Windows and recorded in the Registry. As I said, that has nothing whatsoever to do with the individual sequence numbers differentiating identicasl devices scanned in the USB list, many of which may not even be Joysticks as far as Windows is concerned. I honestly don't understand how you could get so confused. After all the comment in the Lua for your information did say: Where is the ambiguity in that? It is both of those. But neither of those is what is described as the device number in the Lua HID device access. HID devices do NOT equate to joysticks only. For instance all of the individual Goflight modules are HID devices which can be programmed in Lua as such, but few of the normal modules show up as joysticks in Windows (the TQ6 being one notable exception). Okay. I've extracted the details for the three BU0836X boards you have connected, and they are all different: They will be devices 0, 1 and 2, but their inputs in the Luas will all be different. Here is a side by side comparison to show this clearly: Input Report Byte Length: 8 OR 12 OR 6 Number of InputValue Caps: 2 OR 4 OR 1 Number of InputData Indices: 34 OR 36 OR 33 Buttons range 1 -> 32 at indices 1 -> 32 OR 3-> 34 OR 0->31 More tellingly are the differences in the analogue inputs shown: Device 0: Value X at index 0, range 0 -> 4095, using 16 bits Value POV at index 33, range 0 -> 7, using 4 bits Device 1: Value U/RX at index 0, range 0 -> 4095, using 16 bits Value Z at index 1, range 0 -> 4095, using 16 bits Value X at index 2, range 0 -> 4095, using 16 bits Value POV at index 35, range 0 -> 7, using 4 bits Device 2: Value POV at index 32, range 0 -> 7, using 4 bits So, either all these are different, or you've wired them up differently and they then give different configuration information automatically. i honestly do not know which, but I'd guess the latter. All of your buttons WILL be there somewhere, I guess, but you cannot assume they are the same numbers as those you see in Windows (and therefore in FSUIPC assignments). Quite honestly, the only way to proceed to is to find out. I'd do it using special tools. The only tool you have at your disposal is the HidDemo plug-in, with logging (which you'll need to ernable. But don't run it at the same time as any of the others. You'll have to adopt a methodical approach, operating each button or knob and noting what happens in the log for each in turn, and do this for each device, separately. I'm afraid there's not much to "read up on". These Lua plug-ins were supplied as examples for programmers, not tools for beginners I'm afraid. Hopefully thee's enough in the way of comments to help. Regards Pete

They look pretty good. Thanks for the contribution. Since you asked, the only thing i would consider doing, just to make them a little more efficient, would be to use "elseif" for each alternative test on ipcPARAM after the first, so the value doesn't have to be uselessly compared with every possibility. In other words, instead of if ipcPARAM == ... then .... end if ipcPARAM == ... etc, you do if ipcPARAM == ... then ... elseif ipcPARAM == ... etc with one 'end' after the last alternative. Regards Pete

Why did you post a support question into the Announcements forum? Please don't do things like that! You are lucky I saw it! Sorry, I don't understand muchof that at all. What is supposed to be accessing your DLL? I've got nothing in FSUIPC which knows anything about your DLLs. The search pattern used by Windows to find referenced DLLs is pretty much the same across the board with different Windows versions as far as I know, but generally I keep my DLLs along with the program which is using them. I think Windows can also look in its own folder (C:\Windows for instance), but they can be in any folder you like if the program loading them uses the full path to them. The other thing to bear in mind with Win7 is that many of the folders are protected against being written to by users -- the folders you see are often aliassed, not the real ones, to protect program and system files. You can get around this by running Explorer by right-clicking on it and selecting "run as ... administrator". That runs it at an elevated administrator level, not the normal administrator level, and it can then write to more places. Pete

What "numbering in FSUIPC"? Are you referring to the Windows IDs used for Windows-recognised joystick devices? Those are absolutely nothing to do with what we are doing in these Lua plug-ins. The plugin is accessing the USB device directly, as a USB HID device, not via any Windows joystick facilities. As described in the comment in the plug-in, each device OF THE SAME VENDOR AND PRODUCT NAME is numbered in sequence. When the vendor and product names are different, they start from 0 again. Is is simply a sequence number for identical devices. If all the devices were different they'd all be number 0. Well, the latter is completely mystifying as you should at least get the same results with two identical cards wired up in an identical manner. It makes no sense otherwise. From what i know of the BU0836 cards they deliver Windows-compatible button and analogue inputs and drive outputs too, and are configurable in how you connect stuff. But they directly-read inputs may be much more dependent on the actual physical configurations than that. If i had your cards here I'd use a USB monitoring program to see what they are doing, but I strongly suspect that the button numbers provided by Windows' joystick drivers are not the same as the bits seen by the direct HID reading code used in the plug-ins. So your assumptions about button numbers might not be correct. All I can suggest is using HidScanner first of all to check what the properties of the three cards are -- to see that they are in fact identical in their button arrangements. And also then to use the "HidDemo.lua" plug-in supplied as one of the examples in your FSUIPC installation to log all of the results from all of your connected buttons or dials. I've a feeling that you are really outreaching your technical skills in these matters, but I'll try to help ... take a look at those two things first. Regards Pete

How can they be 0 and 7? To get to 7 you'd have to have 8 cards connected! Well 7 isn't surprising until you add the intervening 6 cards. As for 27+26 it really must be your connections because if the first two pairs are okay there's nothing stopping any others. What normal button numbers are you getting? You said you had 3 cards -- what if your second card is 2? They have to be 0,1 and 2 with three cards, there's no other option. Pete

When you install it doesn't it ask? I really don't know anything about FSMap, but I think it is by Thomas Molitor, who is very good and will help you if you go to the right support area. Why not use it with SimConnect over your network I run a mixture of SimConnect and WideFS programs over mine, plus some which have their own networking like AES Remote, SuperTrafficBoard and Aivlasoft's EFB. Yes, I believe it is. I think you have to install it on both machines. how it is all done I don't know, but i'm pretty sure it is all covered in its documentation. It always will. The window isn't used for anything. Either narrow it to a title bar only, or set it to minimise or hide (INI options). No. You are really looking at this the wrong way round. Decide what you want to do, then find the most suitable package for that. There's nothing wrong with SimConnect over a network, so it doesn't have to necessarily be a WideFS/FSUIPC solution. Regards Pete