Pete Dowson

Er .. what measures force on a control? I don't understand. If you just mean the value of the axis, then of course it is available in FSUIPC -- see the list of variables in the FSUIPC SDK. Regards, Pete

Yes, I know. Sorry, the FSUIPC limits are a function of the design and won't be changed now. But FSUIPC does include the nearest 96 in the air and the most significant 96 on the ground (nearest active, rather than sleeping). I haven't come across any aplication that cannot be satisfied with that. No, sorry. It uses the same interfaces, but it isn't limited to a form of memory mapping to support the communication of this information. Yes, but active planes are more important for most purposes -- extra sleeping ones are the first to be lost off the end of FSUIPC's list. What exactly is your problem? Regards, Pete

Yes, and it is either an old one (FS98 or very early FS2000), or one written by someone not following the rules for accessing FSUIPC, because it is using the external application interface even though it is a DLL or GAUge. This is the indication of this: 5312 Client Application: "fs9" (Id=2808) 5312 C:\Program Files\Microsoft Games\Flight Simulator 9\fs9.exe 5312 Product="Microsoft Flight Simulator 2004 - A Century of Flight" 5312 Company="Microsoft Corporation" 19500 Illegal read attempt: offset 0238, size 3 [P2808] 19500Program or module not accredited for use with this unregistered FSUIPC AIBridge is loaded later and is accepted okay: 21375 Client Application: "AIBridge" (Id=156) 21375 C:\Program Files\FSFDT\AIBridge\AIBridge.exe 21391 Product="AIBridge" 21391 Company="Jose Oliveira" 21391 Key is provided in comments field 21531 Client Application: "fs9" (Id=2808) Unfortunately, because the rogue add-in uses an unsupported access method there's no way of identifying it (it "looks" as if it is FS9 itself only because that is the process in which it is running). I'm afraid there are only two ways out of this: Either (1) find out what is doing it by a process of elimination. If it is a gauge, try changing your startup flight to one of the defaults with default aircraft and see if it still happens -- if it does it will be a DLL in the Modules folder, otherwise it will be one of the Gauges in your previous default aircraft. You will need to remove it, whatever it is. OR (2) pay for an FSUIPC key and register it. The makes FSUIPC bypass all application access checks. This will work provided you only have one such badly behaved DLL or Gauge. If ever two get loaded at the same time it is likely that they will both suffer corrupted data, as they will be sharing the same data exchange memory file. Regards, Pete

As documented quite clearly, you need to re-enter the registration details if you move to another PC or re-install Windows. Keeping the KEY file is good, as you can use it to cut-and-paste into the dialogue -- it is a Text file so any editor will be able to display it. Pete

Actually the current "new versions" are 3.617 and 6.616, respectively. I'm not sure what state WideFS 6.596 was in, that's from many weeks ago. Please check the Interim Versions announcement above and keep up to date if you want to try non-Release versions. Well, I can most certainly assure you that this isn't anything to do with that change. The relationship between the flaps and the PM indications are contained in the Aircraft files declared to PM. It really does sound like you must have changed something else at the same time. Please check your flap settings in a default FS aircraft such as the 737. I think you will find they are all fine. you may need to check your PM setup with PM support. I have no idea how you are setting or calibrating your speed brake, as you give no useful information whatsoever, but most certainly if you use the axis facilities in FSUIPC they work fine. Are you assigning them to spoilers in FS? Do they work without FSUIPC in FS? Please sort things out with default aircraft and panels -- calibrate things properly -- before blaming FSUIPC or WideFS for everything. Pete

Sounds like you simply need to recalibrate in FSUIPC. Follow all the steps again -- the idle area, where it currently stops, is the "centre" which should have two distinct values. The minimum calibrated value is the bottom of the 'feathered' zone. Pete

Sorry, I cannot write the manual any simpler than I have, else I would have done, wouldn't I? :-( You most certainly do not need any "advanced informations" in any case! You only need to go to the Buttons & Switches tab, press the button (as it tells you to), select for FS control, then find the control you want in the drop-down list. The FS controls are listed by their name in FS -- the altimeter Kollsman window setting (the one you call QNH, though it isn't QNH unless you set it to be!) is mis-spelled by MS as "Kohlsman" and the two controls are "Kohlsman inc" and "Kohlsman dec". (I don't know how MS came to use that incorrect spelling of the inventor's name, but it has been that way in FS as long as I can remember). Please tel me, what is so "advanced" about that? What is wrong with the descriptions of how to do this in the User manual? Surely this is even easier than understanding anything about flying a plane? :-( Pete

Yes, but WideClient and MixW only run on PCs, so your need a PC for each such 'remote device'. Well, I'm not sure about "proprietary", but I think such a solution might be a lot easier than trying to port complex applications which are very PC dependent and far more complex than needed just for this, onto a PDA. Don't forget, for WideClient this is simply a trivial receive-data-and-pass-it-on exercise -- its main functions, in its purpose as support for FSUIPC applications, are far greater. If you throw all that away what's left would be easier to write from scratch for a PDA. Additionally, as I said, I have no idea how MixW does what it does in the first place. I'm not sure where the "PDA application guys" come into it, unless you mean someone who knows how to program PDAs. You'd need someone like that in any case. I'm very sorry, but I am simply not interested in doing any development in this line whatsoever. The tools and information are available in the FSUIPC SDK to anyone who wants to take this on, but it won't be me. I have enough on my plate to last years as it is -- and, if fact, in future the GPSout function is likely to get absorbed into the FSUIPC user utility package in any case. Regards, Pete

I don't know how to work firewall permissions, sorry. Is the port number relevant? 8002? I don't like having firewalls between my PCs, as there's only me here (why make things difficult for myself), and the internet connection is through a router which provides the protection from outside. Regards, Pete

No way, sorry. Surely the application running on the PDA is the one with the COM input and you connect that to the COM output on the PC? Someone who knows how to program Windows CE should be able to to this in any case. It doesn't need GSPout, just an FSUIPC client program in the PC and a receiver program in the PDA, talking over TCP/IP or whatever. How you deal with the virtual serial ports that MixW provides I've no idea. That's not my program in any case and I've no idea how it's done -- it may not even be possible on Windows CE. Pete

You know there are 60 minutes in a degree? Of course you do! So 54.35 minutes is 54.35/60 degrees, which = 0.9058333 of a degree. Your value above is slightly inaccurate (rounded) -- the 54.35 must be an approximation. 0.905769 degrees is 54.34614 minutes (just multiply by 60). Similarly for latitude. There are still 60 minutes in a degree of latitude too. The signs in FS are - for W, + for E, and of course - for S, +for N. Easy eh? ;-) Pete

Yes, sorry. Not only N1 -- many Engine 2,3,4 values would have been wrong. In my hurry to get a fix to you (in joy on finding the answer so easy) I made a mess with the structure containing the data and misaligned all of the Engine 2-4 data! Ugh!. Try 3.619 attached, instead, please. Note that, at present, I have assumed that the same (Engine 1) gear ratio applies to all engines. If you know of any aircraft which has different gearing for different engines please let me know, as I will have to make the code rather more sophisticated then ... Regards, Pete FSUIPC3619.zip

You cannot use FSUIPC 3.44 with a 2006 registration, and in any case such old versions are not supported. And what, in fact, IS the "latest version" according to you, please? Don't guess, go into FS and look at the About/Registration page. Read the version number. Never ever just say "latest version", please, as every one has their own opinion about "latest" -- it usually means the last one they saw. Regards, Pete

Okay, found it! Knowing the exact value to look for and having two aircraft with specific known values made it quite easy after all. I am now scaling the value in 0898 (etc) by the gear reduction ratio. (I can't do this for the value in 2400 (etc) because that offset is actually mapped directly into the variable inside SIM1.DLL itself. Please try the attached FSUIPC, version 3.618. [DELETED - see 3.619, later in thread] Regards, Pete

It won't be in the FS axes drop-down list -- only in the direct-to-FSUIPC list. FS itself doesn't have such a control. I'm sure I said "direct assignment" in the release notes? You can use the regular rudder control for your main rudder (i.e. set in FS), but this one is special to FSUIPC. Once assigned there you go to the calibrations page and calibrate it. both the rudder and tiller need calibrating in FSUIPC. Regards, Pete

I bet this is the culprit: gear_reduction_ratio= 1.778 //Propeller gear reduction ratio For the Cessna and Baron that value is 1.0. I'm not sure I can find that internally in order to apply it -- odd that no one else has ever been bothered by it these last 34 months of FS2004! Regards, Pete

Okay, let's compare yours with mine: RPM shown by the Gauge: ~1100 (idle) -- Okay I get an idle of 1050, approx. definitely below 1100 Value by FSinterrogate2std (0898): 3707 -- I get 3634, close enough. Value by FSLook (Engine_N1_RPM): 6590.88 -- Yes, I get 6461. Calculated RPM using 0898: 610,894 -- How do you arrive at that? 0898 is 3634, 08C8, the scaler is 10800, and 3634 x 10800 / 65536 gives 599 (using my figures -- but yours cannot be 1,000 times bigger!). Offset 2400, which is the RPM directly from SIM1.DLL gives 599 too. Calculated RPM using Engine_N1_RPM: 1086,143. -- Yes, similar here. Interesting. The value direct from the Simulator is something like 1/1.8 of the value shown on the gauge and given by the gauge interface, and that ratio seems consistent. There must be something else in the Aircraft CFG or AIR file which scales it, other than the scaler. I'll take a quick look Pete

But that is what I meantthe first thing I did with a much faster machine was let the frame rates go as high as they like. But this results, quite often, in them varying. See if it helps setting a frame rate limit. You mean you haven't checked it with a default aircraft yet? That's the first thing to do. Check without it, just in case. Pete

Are the frame rates in FS fairly stable, or jumping up and down a lot? What you are describing, especially if not related to some complex add-on aircraft/panel, sounds more like a performance issue to me. As in FS not processing a bunch of controls for a short time, then suddenly processing them all at once. I'd investigate all the assorted performance parameters in FS first, and especially the video settings, possibly also looking for a newer (or at least better) video driver. As a test, try going into Windowed mode and making the window relatively small, so that video rendering is not such a time consumer. Regards Pete

No, not ported as such. It is intricately "wired in" to the innards of FS. There's pretty much no code whatsoever which could be useful outside of the FS process. You are welcome to write a module for that simulator which provides a compatible external interface for applications. That should be easy enough for you to do, at least with a subset. You'll need the FSUIPC SDK, which contains all sources for the external part, so the interface is readily discernible. It isn't copyright, you can use it freely. Regards, Pete

The purpose of providing direct axis assignment in FS was really to allow clever things to be done, like assignment to axes not supported directly by FS (reversers, steering tiller, rudder and aileron trims, and so on) -- previously you'd need to "pinch2 a real FS axis and assign it to one of these in the FSUIPC INI file. A bit messy to say the least. The other major purposes of FSUIPC assignments was to allow different assignments for different aircraft types -- for instance, to support those with a separate prop and jet or prop and helo control system -- and to provide direct "raw" value assignments for programmable hardware systems such as EPIC to directly control other FS values. I really think it is overkill for what you need. Just do a full and proper calibration, with null zone and suitable slope, all in FSUIPC after assigning axes in FS and setting FS's sensitivity to max and null zone to min. The step by step instructions in the FSUIPC manual should get you exactly what you want. Go take a look. You can move the slider both ways from the linear (straight) default response. One way is less sensitive in the centre (more horizontal), the other is more sensitive in the centre (more vertical). In both cases the compensation is then the opposite in the extremes. If you look at it it becomes obvious. Regards Pete

Hmmm, I'm not sure that the FSUIPC option ever helped with anything but button operations on those, though I suppose it is just possible. This problem only affects certain add-on aircraft in any case, and the FSUIPC facility was a work-around until the aircraft programmers (hopefully) fixed their code. You could, with effort and ingenuity, program keypress or buttons to add or subtract 1 or 10 or 100 directly to the variable offsets, using the Offset controls in FSUIPC's dropdowns. But this would only really be feasible with those offsets which do actually use units you can manipulate easily. The Course/OBS settings are okay, as would be Altitude and IAS, but the heading is in units such that 360 degrees = 65536 units, so the inc/dec for 1 degree would be 182.0444.... You can't add the fractional part, so it would occasionally repeat, and the true setting could ultimately be up to a degree off what you thought owing to the fractions. You'll need the documentation in the FSUIPC SDK for offsets and units. And you cannot program button ops that way. Well, no, not really. The time it uses is quite lax in any case at around 400 mSecs (nearly half a second). I really wouldn't know how to change it permanently, at least not without hours spent rummaging around in several FS Modules. I'm not really keen on doing any more of that on a 30 month old product when I've got some much else to do. Sorry. It should be quite satisfactory as it is, and as it really has been like in all the versions of FS I can remember. It was only the introduction of third party advanced aircraft panels which send loads of controls every second which ever messed things up -- that started in FS2002. Try one of the default aircraft, if you still have a problem then it sounds like you have a faulty mouse rather than anything else. And I don't think you'd like it off permanently in any case, or it would take ages to change settings by more than a few degrees or feet or knots. Regards Pete

Unfortunately you are mixing up two different things. You need the FS sensitivity at max and null zone at min in order that FS not only provides the axis values, but provides the full range of axis values. The sensitivity value is used as a kind of divisor. The higher it is the shorter the range of values from the axis, and the more coarse the calibration. The null zone in FS merely makes an initial part of the axis unusable, so reducing the number of possible values still further. When calibrating (not assigning) in FSUIPC you don't want either of these reductions to occur, as they detract from the accuracy and precision with which you can calibrate. If you want to actually assign axes in FS, then you probably would need to disable joysticks in FS altogether as, yes, FS does have the habit of assigning axes automatically. I suppose an alternative would be to set the FS sensitivity to zero, so that the axis, assigned in FSUIPC, wouldn't have any affect in FS first. FSUIPC's "centre" null zone is achieved by following the step-by-step instructions for calibration. There are TWO (2) centre values. They need to be different, i.e. relate to different points on your joystick axis. The whole of that little central range is then the "null zone" -- i.e. it has no sensitivity whatsoever, only sending '0' back to FS. This is what "null" means -- "nothing"! Please re-calibrate and follow the instructions step by step. The slope is used to affect sensitivity in FSUIPC. It is very different from FS's method in that, whilst it can reduce the sensitivty in the centre, at the same time it increases it at the extremes so that the full deflections are still usable. Take care not to use the "inverse" slopes -- those increase centre sensitivity whilst reducing it at the extremes. (One good use of that is for more sensitive steering via the steering tiller facility in FSUIPC version 3.617, available above). The filter facility is intended to reduce jitter, it has nothing whatsoever to do with sensitivity or null zones. It applies a low pass digital filter to the values, that's all. Pete

Sorry, how many elevator trims are you seeing, and where are you actually looking? I'd need to understand what you are asking first. If you are talking about control lists, they are extracted from the FS module "CONTROLS.DLL" -- that's how they are specific to each FS release. In that list the only ones I am aware of are: Elev trim up Elev trim dn Elevator trim set Axis elev trim set The first two are the equivalent of the keyboard 1 and 7 keys (on the number pad), and the "Set" ones are both Axis controls, needing a parameter and normally assigned to a lever. All "set" controls are like that. The only reason there are two axis controls (as there are for pretty much every main control) is that the ones starting "Axis ..." are new ones added in, I think, FS2002, apparently by a new programmer in the FS team who hadn't realised, I think, that they were already all there since FS98. It was done at the time they changed FS from using the standard Windows joystick API (which FSUIPC still uses) to using DirectInput. So, please explain what is confusing you, and why Elevator Trim only when I think there are similar variations for most of the main aircraft controls. Regards, Pete

First, please note that 3.44 is very old now and not supported. Current is 3.60, though you can download a better, later one here in the Interim Versions announcement. Assuming you only have the one prop pitch lever, go to FSUIPC's Joystick calibrations and map the single prop to 4 props. then page forward to the 4 props page and calibrate it on that page, with the centre zone being your idle rpm setting. No. Control 66429 is Throttle4. Just assign your rudder trim axis to throttle 4 in FS then calibrate the rudder trim in FSUIPC. If you use the latest FSUIPC you can assign these axes directly, without allocating "false" axes via FSUIPC.INI and FS assignments. Take a look. It is much easier. It pays to keep up to date with this software. Regular perusal here to see what updates may be available, and what the new facilities are, should prove very useful to you. Regards, Pete