Pete Dowson

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

Thank you very much. It is much appreciated! Regards, Pete

Are you running anything called anything like that? Strange if not. The DLLs attaching themselves to FSUIPC successfully are well known ones, I don't think they are related. Regards, Pete

Sounds good. Nice looking models! You have equivalent performing ones in FS (scaled up presumably ;-) )? Pete

It still isn't a message from anything of mine! ;-) The log shows everything is fine. Sorry, I've no idea what software you have producing that message, nor what it means. Regards, Pete

It is one integer of 32-bits wich occupies 4 bytes 9a byte is 8 bits, 4 x 8 = 32). You also aren't counting correctly. After 02B4 comes 02B5 then 02B6 and 02B7 -- not that any of that is relevant. you don't want 4 separate bytes, you want one 32-bit value. Why are you counting byte addresses in 2's in any case? If you want the IAS that is at 02BC not 02B4. Please do take another look at the information provided. You can also try FSInterrogate2 which is highly instructive. Pete

Hmmm. Interesting. I really know nothing about Multiplayer -- nor even smoke. Have you checked that offset to see if it works locally first? Otherwise you may need to use one of the SMOKE controls. Well, it doesn't seem to provide a great deal for FSUIPC to do -- you could send the SMOKE controls direct to FS in any case. And FSUIPC really has nothing to do with Multiplayer at all. If I were you I'd concentrate on solving the MP side of things and not worry about the actual smoke enabling part until that's sorted. Regards, Pete

Nice to see you making progress, Kaela. Who really needs documentation, eh? ;-) Regards Pete

Sorry, I haven't a clue what it means either. It isn't from any program I've ever written. If you want to check the FSUIPC operation for errors, please find the file caled FSUIPC.LOG in the FS Modules folder and look at that. Show it here if you like. Maybe that weird message if from some program trying to use FSUIPC incorrectly. Regards, Pete