Pete Dowson

Fixed in versions 3.967 and 4.583, which I'll upload to the Updates announcement later today. Meanwhile, I've been experimenting along the lines you suggest here: I've deliberately set the same sensitivity, dead zone as you, and assigned through FS9 only, not through FSUIPC. I also removed my "sensitivity mode" setting, to be sure it was all identical. I calibrated the slew fwd/back and left/right controls in FSUIPC and tested them. Yes, I agree, they are actually still usable despite the shenanigans FS has put the values through before they reach me. [More about why that might be in a minute ***]. The only thing I found wrong (and this is with FS9 only -- FSX seems okay), is that when re-loading FS and going into Slew mode, FS produces an erratic negative value on the elevator axis, which is of course the fwd/bwd axis. The value is way outside my calibrated centre "dead zone" (the FSUIPC variety), so the aircraft immediately dashes backwards at some huge rate. It is perfectly okay, though, as soon as i make any slight movement on the joystick. I think that must be some residual value FS is using, and may be specific to my joystick and its driver (I use a MS SideWinder FreeStyle Pro for such testing). Anyway, that was with simply reloading FS9 after closing it. No other changes. Then the same after Restarting Windows (using Win7 too, but 64 bit). Result: same as simply restarting FS9. So, another test: with the joystick disconnected during Windows' restart. Result Same. Finally, disconnect joystick, power system off, Then back on, reconnect joystick when Windows is ready. Run FS9. Result: same. So, sorry, but I reached no conclusions, except possibly that in your case wither Windows or FS9 is reconfiguring the joystick sometimes. I've no idea why or how except possibly it's that assigned GUID which is changing. Of course it could just possibly be something to do with that "Logitech Gaming Software (LGS)" you are also using. As part of the process of elimination, perhaps you could see if the same problems occur without that? ... One last thought on this. You do have the joystick connected and powered up BEFORE you start FS9, don't you? I think if you don't then it will be even more likely to treat it as a new connection and make its own choices. *** On the point of how FSUIPC's calibration may be overcoming the problems I believe are caused by lower sensitivity and increased dead zone in FS, I think, in slew mode, you don't notice quite so much the loss of resolution you incur with those FS slider settings. FSUIPC's calibration still spreads the remaining values it does actually see across the whole range needed for full use of FS's slew controls, but with, possibly, only as few as 25% of the different values the joystick is capable of actually being used, you may simply be finding it easier to locate a fixed joystick position for a fixed-speed slew. This is something I've not really experimented with before, because I find slewing infinitely (exaggeration perhaps ) more controllable using keyboard taps on the numpad. The only reason I provided separate calibration for slew was for those trying to slew from inside their cockpit, out of reach of a keyboard. Regards Pete

Well, maximum dead zone -- it cuts out a huge portion of the axis capability. The lettering of axes is only relevant to axes assigned in FSUIPC. In your case you only appear to have one device in any case: 0=Logitech Force 3D Pro USB A=Logitech Force 3D Pro USB When you assign, in FSUIPC, to an axis on Joystick "A", FSUIPC finds that in the list above, then uses the name to find the Windows ID number, 0 in this case. But with only one device even if without this, if things did get mixed up, it would only result in no assignments working at all -- because the joystick wouldn't be on the ID number programmed into FSUIPC. Since you are assigning only in FS, none of this is at all relevant. FSUIPC is not reading the joystick, FS is. All the calibration in FSUIPC does is calibrate the internal FS controls, not the joystick itself but the results after passing through FS's assignments and manipulations. What can happen, if you disconnect and reconnect devices which were assigned in FS is that the assignments are re-made, affresh, because FS can assume the device is new. I think this is because the Windows registry entries for the device get re-built, and FS uses some strange "GUID" number to match things up which might change in the process of Windows continually re-installing a USB device. The GUID in the FS CFG extract you showed is this: {9FC5FA50-0906-11DF-8001-444553540000} See if that changes at all. That could certainly mess things about. No need to be sarcastic. FSUIPC calibration has nothing whatsoever to do with FS's CFG file. FSUIPC calibration works on the internal FS controls. It knows nothing about joysticks, assignments, whatever. That was all I was saying. If you use FSUIPC assignment, I can tell you exactly what is going on, because then FSUIPC is reading the joysticks. I cannot help with what FS might do when you assign there, except my advice already given and made clear in the documentation -- zero dead zone, max sensitivity, Sensitivity Mode zero. It really makes it less than worthwhile. It makes what it is trying to do -- i.e. make the whole range of your axis usable for the whole range of FS's capabilities -- a bit futile. It does not at all, as I thought I said. Erthe "Slope" button won't be there after a Reset because Reset cancels the calibration altogether. Do you mean after pressing "Set" again after "Reset", to re-enable the calibration? I'll have a look to see whether the Slope should be reset to 0 or not. [LATER] Ahem. That's a long-standing bug. The slope should be getting reset to 0 when you "Reset", so that it is 0 next time you calibrate. Thanks for reporting that. I'll fix it now. If a control is not being calibrated then it isn't even being looked at -- no changes whatsoever, just as if FSUIPC wasn't there. The slope is just part of the translation of "IN" values to "OUT" values that calibration performs. They should be reset if you've pressed the Reset (so the control is no longer even looked at) , and then go to re-enable FSUIPC calibration via the "SET" button. But there's evidently a bug which I shall fix. Sorry. BBut it won't affect non-calibrated controls. Ah, yes. That is a problem. Sorry about that. I have no idea how to support force-feedback. But with no assignments made in FSUIPC, don't worry about using letters or numbers for joysticks in FSUIPC as it isn't relevant. If things are changing you need to see if FS is reassigning things sometimes, and consequently possibly altering your null zones and sensitivity settings. Else, I'm sorry, but I haven't a clue. Perhaps you could try without FSUIPC at all, because if it works fine without it I'd certainly want to know and would need to find out more. Regards Pete

No, you don't buy a specific version of FSUIPC, you only buy the Registration Key for FSUIPC3 or FSUIPC4. You are expected to get your copy of FSUIPC from the Schiratti site, usually BEFORE you buy, but any time, and you ought to then keep it up to date. Older versions are not supported. There have also been a few updates here, on this Forum since then. Currently 3.96 is the earliest supported release, but I would advise to to get 3.966 or later after you've installed 3.96. You can always get updates and read about the latest changes in the Updates and other Goodies Announcement above, in this Forum. Yes, of course. You should! The registration is for any version 3.xx, forever. Regards Pete

There are a few companies around these days making those, though whether they come flat-packed or pre-assembled I don't know -- most likely flat-packed as they're shipped world-wide. For 737NG especially you can get the MIP (main instrument panel, pilot only or both pilot and copilot) pre-cut and ready for glass screens and switches, also overheads and centre pedestals, all of which you can fit the switches and gauges and do your own wiring. Your choice of fittings and electronics, or they'll supply too, usually. Sim-Samurai does such a middle-path cockpit, or even just the plans. Maybe you should look at his site after all? No, you'll be surprised at what you can find if you look around. My eyes were opened when I first visited the Lelystad FS Weekend a couple of years ago. There's a tremendous variety of stuff available, and more, it seems, every day. Pay a visit to MyCockpits some time and scan through the variations there, for starters. http://www.mycockpit.org Regards Pete

100% dead zone? That would mean no live part at all! You cannot mean that. And 50% sensitivity might be okay if you aren't calibrating in FSUIPC, but if you are then it's a complete waste of your device's capabilities. For FSUIPC calibration you either want to assign in FSUIPC, or you want full sensitivity (100%, or full right) and no dead zone (full left, zero). Something is obviously changing in between. Sorry, but there's nothing in anything I've ever written which would explain such erratic and completely unpredictable behaviour. Something is evidently changing in the route between the joystick and where it gets to FSUIPC -- check the "INPUT" numbers, see the differences. Ouch! It is starting to sound like some sort of driver or USB problem on your PC. Well that's not at all relevant to me, except that you most certainly should have zero NULL and maximum sensitivity. If you don't, then please don't bother trying to calibrate in FSUIPC. There's no point. It is all designed to operate correctly only on the full undisturbed range of your controls. I think you are undermining it somewhat. The other thing which may also be a factor is the way FS handles joystick inputs. It was changed after FS98 from being a linear response to a time-based response. In my opinion that was a bad move, and combined with messing so badly with the numbers by having wrong sensitivity and null zones I think you could end up with a mess in any case. You could try doing as advised in the FSUIPC user guide, setting Stick Sensitivity Mode to 0 (this reverts FS's treatment to pre-FS2000 methods, more linear). But I still can't vouch for what will happen with your odd null and sensitivity settings which will tend to screw up the numbers in any case (they operate as subtractors and divisors, respectively). I notice from that that you've not even bothered to calibrate your controls in FSUIPC, only the slew axes. Have you never even tried to use FSUIPC for its truly intended purpose in this area? (Oh, I see you have, later in your message. Odd you should have then deleted those). It's a long time ago now (10 years) but I think it otherwise exhibits non-linear behaviour based on the speed you change the axis. Faster movements = greater change, I think. I've never delved into it that much, it was noticeably a bad idea from the get-go. Have you thought of assigning in FSUIPC in any case, and bypassing all that unpredictability? Regards Pete

The PMDG aircraft will present you with major problems for your overhead. There is one hardware interface which has been made -- I saw it at the Lelystad FS show last year. But otherwise you face utmost difficulties as virtually none of the insides of the PMDG aircraft are available to outside programs. They are secret to PMDG and never revealed, by policy. You might be better off choosing an easier aircraft. But if you stick to the PMDG, the full one with its own logics, you'll need to contact some folks who frequent the MyCockpit forums. Or check out Ian's site at http://www.737ng.co.uk. You will find Ian very helpful and he's been through all the problems you are going to face. I use the PMDG 737NG model and visuals, but throw away all of the panel parts. I use Project Magenta (http://www.projectmagenta.com ) for the instrumentation and subsystems. It's probably the most expensive choice, but I've been involved with PM for a long time. The more recent additions to this area are Sim-Avionics (http://www.sim-avionics.com ) who are good for the 777, and Flight Deck Software (http://www.flightdecksoftware.com ), for the 737NG. Regards Pete

There's no one "Lua plug-in". A plug-in is simply an extra bit which plugs in. As to how it works, wellFSUIPC contains a Lua compiler and interpreter and runs the little plug-ins on request, or automatically. The plug-ins can extend the facilities offered by FSUIPC. Really, if you are not a programmer, and don't even yet understand the relatively easy user facilities provided by FSUIPC, I don't think you want to worry about Lua plug-ins or FSUIPC offsets or anything. It was just that you suddenly ask, out of the blue, about reading Voltages and Amps as if you were going to write a program to use them. If you are not, what can you possibly do with such offset information? Why ask in the first place? Such packages will only do such things for you if you use the ready-built hardware which they include drivers for. If you are building your own hardware you will almost always need to do some programming, though there are some good hardware interface cards available for which folks have done generic drivers where you more or less just need to fill in parameters. If you are really talking about interfacing homebuilt hardware, I would really recommend you to go to MyCockpits forums instead. I have never ever built my own cockpit and don't know much about the hardware and programs available. There's a lot of experience over in MyCockpits. Go to http://www.mycockpit.org/forums/forum.php Regards Pete

By program? Are you a programmer? Or you can get such stuff via a Lua plug-in, but then what do you do with it? The default FS aircraft do have such values in offsets, excepting the Frequency. FS doesn't simulate the subsystem that well. Most of those subsystems aren't really simulated in detail by FS, but they are usually dealt with in add-on aircraft like those from PMDG and LevelD. Alternatively there are packages like Flight Deck Software, Project Magenta, and SimAvionics which simulate them. I use PM's "pmSystems" for all the overhead-based subsystems in my 737NG. For FS offsets and programming information you need to refer to the documents included in the FSUIPC SDK. For the other packages you need their documentation. For add-on aircraft you are problably going to have difficulty, but you could ask in the MyCockpit Forums. Please do try looking up the values and offsets you might need in the available documents. If you ask me, I have to go and find my copy of the document and search it here, I don't remember it all! You could easily do the same, please do help yourself in such ways, it will be more efficient for us both. Regards Pete

In the field handily labelled "offset" which appears when you select an Offset control! It does actually tell you this in the User Guide, in the Buttons chapter, in the part about additional controls beginning "Offset controls". The offset field never appears for controls other than Offset controls. It is used, surprisingly enough, to supply a parameter to those controls which need a parameter, like the Offset controls, and pretty much all those controls ending in "set", plus a fair few others. If you never want to use any such controls, you don't need to worry. If you do need to use such controls you'll know what the parameter means. Pete

Sorry, they are the FSUIPC assignable controls I mentioned to you, here (in bold red): Sorry, I thought you knew how to assign controls to buttons already? See the Buttons & Switches tab in FSUIPC options. There's a whole chapter about assigning buttons in the User Guide. Please look in your FS Modules folder and see some of the documentation installed for you, including the Lua documents. There's also the same in the Announcements here in the Forum. It would always be worth your while looking through the Announcements here from time to time. They are there for your benefit! Pete

Souinds like Bob Sidwick of RC Simulations, down in Bristol? I've known him for many years, at least as far back as FS4 days. ;-) Those DBox systems are expensive, aren't they? Okay for GA I think, but I couldn't get my 2000 lb 5' x 7' 737 cockpit onto one! And even if I did I wouldn't trust it not to fall through the floor destroying my dining room below! ;-) Good flying! Pete

The advanced users guide is for advanced users doing more advanced things with their systems, like building and programming a cockpit. Don't look at it if it confuses you, just do the simple things you understand. And none of the User Guide is related to or about "programming", it is mostly about aircraft controls and how they relate to the way FS is made. If you can understand how to fly an aircraft AND how to work out what Flight sim is all about from Microsoft's "documentation", there will be nothing in the User guide which is beyond you. My documentation is technical, yes, as an A.O.M. would be, because I try to be precise and to the point. And the subject is technical, after all. The SimSamurai guide, written by a chap who writes complete guides for FS users, may be more your style, more chatty and less technical. Take a look at that. Change the "UseProfiles" parameter in the FSUIPC INI file (in the FS Modules folder) from "No" to "Yes" before loading FS, then create a named Profile for each type. You shouldn't need any exceptions. The end result will be much easier to manage. Regards Pete

What "general brake command" could that be? The full stop key by default operates the simple "BRAKES" control, which puts temporary pressure on both brakes simultaneously. The differential analogue brakes can be AXIS LEFT BRAKE SET and AXIS RIGHT BRAKE SET, or the older BRAKES LEFT and BRAKES RIGHT -- the latter two are usually assigned to F11 and F12 on FS9 and before, but I think that changed with FSX. The only other braking actions are the parking brake and the AutoBrakes (the latter only on aircraft so equipped). So which of these do you think is acting without you requesting it? Are you sure it isn't the simple matter of the brake action from your pedals needing reversing? Most pedals are wired so that unless you reverse the axis you get full braking with feet off and no braking only with full pressure on both. As well as reversing (and re-calibrating afterwards), you will find you also need to calibrate the "brakes off" position with both pedals slighly pressed, otherwise you can find yourself inadvertently getting braking when simply using the rudders. If in doubt as to what is going on, try using the Logging facilities in FSUIPC. You can log both normal and Axis events. The log (written to the Modules folder) will show their use and even name the control responsible. Regards Pete

Have you tried the individual light switch bits in FSUIPC offset 0D0C? You can set and clear individual bits there using the Offset Word SetBits and Offset Word Clearbits controls. Of course if the PMDG aircraft does its own thing for the lights then that won't work, but you say the normal FS landing lights work okay? No. But if the buttons come in via normal Windows joystick scanning, you could write one as a Lua plug-in. Did you ask in the MyCockpit forums as I suggested? Regards Pete

And a short answer. If you program an on/off locking toggle switch to operate a Toggle control, there is no solution UNLES you have a program which is monitoring the state of your switches and restoring the state of whatever it is they control whenever it sees that state change. That might be a separate program interfacing to FSUIPC, or it might be a Lua plug-in. either could do it -- providing you can read that state. But if it is only the Action of the switch which concerns you, not its physical position in relation to the current state, then never assign it to toggling type controls, only those which switch things on specifically, or off specifically. If such a control doesn't exist, then for most FS internals there's likely to be an offset which you can set or clear using the Offset controls. Are the landing lights on the aircraft controlled by the FS internals, or PMDG's own implementation? If it is the FS landing lights then it is easy: there are separate LANDING LIGHTS ON and OFF controls. If it is PMDG, then it depends whether they provide separate on and off facilities or only a toggle. Regards Pete

But Project Magenta operates via offsets too, but they provide offsets for the Altitude adjustment knob, so you can increment it and decrement it. Normally the only use of the actual Altitude readout is so you can display that value on your hardware MCP. How does S-A handle all of the buttons and knobs you might want to add? They surely cannot all be via actual final display values? That would mean just about every user needing to write interface programs. Er .. so how does the MCP application change the offsets? Are you sure that the Sim-Avionics suite isn't designed to use WideFS or some sort of networking? Sounds a bit odd if not. Regards Pete

Doesn't that come with it's own control program with assignment facilities? I don't think any of the buttons and switches on it are recognised as normal Windows buttons, so it isn't supported by FSUIPC in that way. I did read about someone who'd decoded its interface and was looking at doing an interface program which would allow FSUIPC button assignments, but I can't find that thread now. I've also asked Saitek for more details of their products and perhaps a sample so I could try things. Not heard from them again yet, though. [LATER] Found the thread you ought to look at! viewtopic.php?f=54&t=78823 Regards Pete

Via wideFs, simply by assigning to the PTT controls in FSUIPC. As far as I am aware there is no difference there between local or remote or between SB3 and SB4. I'm simply not able to move to SB4 because they don't support the offsets for Transponder mode and Ident nor respond to offers from me to add new messages for them to process for those functions. Regards Pete

It's a bit of a mismatch. Such offsets are designed to be read/written by programs, not by simple controls. Doesn't Sim-Avionics react to the normal FS A/P altitude Inc/Dec controls, or have any INC/DEC type assignments? That's what you need. There's no way you can assign simply controls in FSUIPC to do the sort of computations that software needs for that offset. At the very least you'd need to write a Lua plug-in program to read the offset, compute a suitable increment or descrement, then write it back. So what is the problem? Cannot those tools be used from hardware at all? If not, what is the precise application of the tools? Does the Sim-Avionics documentation declare that offset as a FLOAT32? If not then writing a float value to it will certainly give weird results. You quote this: but FSUIPC offset 07D4 is the FS AP Altitude and is a DWORD, not a Float32! FSUIPC does not offer any DWORD increment/decrement controls (the range possibility is too great) but if it did the increment for 100 feet would be computed just as shown in your example, i.e. 1 * 1997537 = 1997537. But to use that knowledge you'd need to write a program or a small Lua plug-in for certain. I thought Sim-Avionics was designed for cockpit builders using hardware such as the Leo Bodnar cards? Doesn't the documentation help? If not it might be a good idea to talk to their support, or visit their Forum. There are also a lot of users of both the cards and S-A (though possibly not both) on the MyCockpit forums (http://www.mycockpit.org/forums ) so you might also ask there. Regards Pete

I cannot reproduce your error at all, even by removing the Registry entry for FS9 which was missing in your installation. I realise it is too late now to ask for for a screenshot of the error message over the top of the Install log, so I'm posting this for anyone else who may get this problem. I need to actually see it for myself. This is because There is no relationship between this: the last line of the Install log, and therefore the point at which the error occurred, and this: The very next line of code in the Installer, after logging "NOT FOUND" etc is the one which creates a File selection dialogue where the user can locate FS9.EXE. When he does so, everything continues normally. If he selects something other than FS, THEN and only then can the program generate the error above (the "Found FS7" should really be "Found unknown", because it wouldn't have been an FS executable the user selected). I am correcting the installer so that it says "unknown" instead of "FS7". However, if this is what really happened, then the Log would have shown extra lines at the end, thus: Here I deliberately chose an EXE which is in Windows 7's Program Files folder, but which is not the EXE of a recognised version of an FS installation. Now the error message I get IS exactly as you reported, but all of the reasons why are properly shown in the Log. So, I think what might have happened is that for some reason you misunderstood the need to find the FS9.EXE file, and instead selected some other EXE. Then, when you pressed OK or Select, then you got the error. I think you must have truncated the Log when you pasted it into your message here. Regards Pete

This is a short tutorial for those needing to know more about how to deal with bit numbers, and masks, and values to use when setting, toggling or clearing bits. BINARY Binary numbers, the ones actually used in computers, are made up of "bits". Each bit can only be "on" (1) or "off" (0). So, with one bit you can only count 0 then 1. With 2 bits you can count from 0 to 3, via the combination of the two bits, thus: 00 = 0 01 = 1 10 = 2 11 = 3 A binary number can have as many bits as you need, but computers generally have addressable groups of bits, as follows: BYTE = 8 bits, running from 00000000 to 11111111 (decimal 0 to 255). WORD = 16 bits DWORD = 32 bits The addresses known in FSUIPC as "offsets" actually point to BYTES, but any size data may start at that byte address. Note that in decimal, each higher digit in a number is worth 10 times the adjacent one. So Decimal 245 = (2 x 10 x 10) + (4 x 10) + (5 x 1) In Binary the same sort of thing is true, but now each digit is only worth 2 x the adjacent one. So Binary 1101 = (1 x 2 x 2 x 2) + (1 x 2 x 2) + (0 x 2) + (1 x 1) = decimal 13. Okay so far? BIT NUMBERS Documentation like that for Project Magenta often refers to "bit numbers", like "bit 0" or "bit 17". All this refers to is the position of the bit in the overall number. Most usually (but not always) bits are numbered from the bottom, the bit of value 0 or 1. So, in the example of decimal 13 above: 1 1 0 1 the bits, left to right are bits 3, 2, 1 and 0. Using this system of numbering, the VALUE of that bit in the number can be computed as 2 to the power of the bit number, like 2^N (the power should be superscripted, but i don't know how to do that here -- the ^ convention is used in programming languages). Thus. If 2^3 means "2 x 2 x 2", the 13 could be written as 2^3 + 2^2 + 2^0 (note that mathematical convention dictates that a number to the power of zero is always 1). HEXADECIMAL Writing numbers in binary all the time is laborious and error prone, so often a different number system is used -- octal (base 8 ) and hexadecimal (base 16). In today's PCs hex is better because most units are made up of multiple of 4 bits, and 4 bits, as we saw, have the capacity to count from 0 to 15: so 16 values in all. So, whilst you can treat hex numbers as base 16 numbers, with each more significant digit being worth 16 times the adjacent one, in cases where you are really handling bits, as here, you merely need to think of the binary number being divided into groups of 4 bits. The different values of 4 bits, from 0 to 15, are represented in hex like this: Binary 0 0 0 0 = Hex 0 = Decimal 0 Binary 0 0 0 1 = Hex 1 = Decimal 1 Binary 0 0 1 0 = Hex 2 = Decimal 2 Binary 0 0 1 1 = Hex 3 = Decimal 3 Binary 0 1 0 0 = Hex 4 = Decimal 4 Binary 0 1 0 1 = Hex 5 = Decimal 5 Binary 0 1 1 0 = Hex 6 = Decimal 6 Binary 0 1 1 1 = Hex 7 = Decimal 7 Binary 1 0 0 0 = Hex 8 = Decimal 8 Binary 1 0 0 1 = Hex 9 = Decimal 9 Binary 1 0 1 0 = Hex A = Decimal 10 Binary 1 0 1 1 = Hex B = Decimal 11 Binary 1 1 0 0 = Hex C = Decimal 12 Binary 1 1 0 1 = Hex D = Decimal 13 Binary 1 1 1 0 = Hex E = Decimal 14 Binary 1 1 1 1 = Hex F = Decimal 15 So, to convert a binary number to hex you simply divide it into groups of 4 bits (from the bottom, least significant part) and use the above equivalences. For example Binary 1 0 1 0 1 1 1 1 0 0 1 0 1 1 0 1 becomes 1 0 1 0 1 1 1 1 0 0 1 0 1 1 0 1 so it is hex AF2D. The reverse conversion works too. EXAMPLES So, I was asked how we get the hex value "10000" for bit 16 and how we calculate the value "20000000" for bit 29. Now it should be easy for you all: Bit 16 is the 16th bit up counting from 0, so in binary it must be (I've already divided it into 4's to save time): 1 0000 0000 0000 0000. which you can convert to hex as I showed above ---> 10000 Bit 29 is likewise the 29th bit up counting from 0: 10 0000 0000 0000 0000 0000 0000 0000 So, hex 20000000. Of course you don't need to write down all the bits. 29 divided by 4 (the number of bits in a group) is 7 remainder 1, so it has 7 hex 0's after a 2^1 group, and 2^1 = 2. Good flying! Pete

So it was easy to understand? If so, maybe I should make a permanent copy in the Announcements section? Regards Pete

Yes, thank you. I'm not sure what is going wrong there. I'll check it out again. Thanks. Certainly your FS was not installed correctly (the Registry is not updated with its path)but I see you've now rectified that. I'll work on fixing the Installer. Not sure why that wasn't presenting you with the correct dialogue. Regards Pete

I have it connected and using their software it works in many ways, but I agree that in some areas it needs better assignments. I was considering whether to try and support their units more directly in FSUIPC, like with GoFlight, but I'm not terribly keen on using their SDK as it stands as it looks as if each unit has to be dealt with separately. I've not had enough time to look into it more deeply as yet. Not sure when I will at present -- maybe in a few weeks. I'm not doing any HID drivers. That's outside my scope and would need special stuff from Microsoft regarding IDs and so on, which all cost too much. If VRInsight do HID drivers that would be fine, but i think it unlikely in any case with the ordinary serial port style interface -- the MCP combo is not using USB except as a serial port adapter, FTDI I think. Yes, I can see it's a bit of a mess if you want to do anything sophisticated. I will get to it, I just cannot promise when, nor even what I can do. The idea that each unit needs special handling puts me off a bit. If it looks like I can unify things, then maybe. Regards Pete

We would need to come to an agreement. When you are a bit nearer the time write to me at petedowson@btconnect.com . I'll be uploading the FSUIPC4 update with the nearest airports offsets later today. I got it all working last night. ;-) Regards Pete