Pete Dowson

Isn't this clear from PMDG? Yes, they are licensed to use FSUIPC without the user paying any extra, and no, there is no such thing as a "licensed version". They may ship a version, but it most likely will not be the latest. I only support the current version at any time so it is in your interest to download and install updates from time to time. Do not confuse "licensed access" and "versions of FSUIPC". Licenses for FSUIPC version 3 apply to ALL versions 3.xxx. There is no "licensed" version as opposed to an "unlicensed version". I have enough to do without maintaining such silly diversities. ;-) You can get the latest version of FSUIPC "for free" at any time in any case -- it is freely downloadable at http://www.schiratti.com/dowson, and there are often later interim versions, with more facilities, here, in the Announcements above. If you want access to the user facilities in FSUIPC you purchase a user key from SimMarket. See the links on the Schiratti website page, in the Announcements above, and in the FSUIPC User documentation which you will find in the downloadable ZIP. When you get the key, just follow the instructions. Regards, Pete

I would be very surprised if any aircraft needed FSUIPC for its autopilot, and most certainly not the GPS which FSUIPC doesn't deal with at all. The error message isn't from FSUIPC -- there is no such message. You really need to contact the support folks for the aircraft. However, when you say "open FSUIPC in the module folder of the menu, it says that I registered for the 3.48 version !" do you mean that the menu says you are running 3.48? If so, then you most certainly are running 3.48. Did you install something after installing 3.53? If so it has probably overwritten it with an older version. Incidentally, there is no such thing as "registered for a 3.xx version". The registration covers ANY version 3. You are NOT installing 3.53 then. Go to the FS2002 modules folder in Windows Explorer, find the FSUIPC DLL and right-click on it. Select Properties then Version. It will tell you the version there. You need to ask support for the aircraft about that. FSUIPC will play no part in such matters in any case. Regards Pete

Well, maybe it isn't as explicit as that (but see next paragraph), and I'm not sure it is my job to explain all things about FS, only to give advice about my programs, which I do, but what do you think joystick calibration is for in the first place? How can FS react in the same sensible way to joysticks with all sorts of different characteristics? I cannot understand how you could imagine that FS operates on your actual joystick values -- you've already shown how those can be "fiddled" to give you no reverse zone on a control for which half the whole range might otherwise be reverse, remember? The main reference data I provide for FSUIPC users is in the Table which appears in the Joysticks section of the main user guide. I realise this is only reference material, but you will see that it does state that the throttles operate the way I've just mentioned. Here is the relevant part from that table: Of course, the part you presumably referred to and misunderstood also rather implied, even stated, that idle was zero, don't you think? It also said not to bother changing it unless to could reliably set idle. The main place where the ranges of all the axis controls inside FS is made obvious and more exact is the programming guide for those writing programs for interfacing direct to FSUIPC. External programs exercising direct control need to provide the values FS is using. Regards, Pete

But as I explained (did you not read all of my reply?), and as should be quite clear from the documents, the FS throttle values for forward thrust operate from 0 to +16383. Idle is 0! Always! You are completely confusing yourself with the values your joystick is providing, which is nothing to do with the FS throttle values EXCEPT insofar as they are related to them via calibration! THE WHOLE POINT OF CALIBRATION IS TO ENABLE FS TO WORK WITH ALL SORTS OF DIFFERENT JOYSTICKS. Its values are the same always -- ZERO is always idle, a negative number is always reverse, and so on. Calibration is a process of mapping your values to FS's. Of course not! And I explained why! Please see above! You are asking FSUIPC to prevent the reverser when FS's throttle is above -15000. If is is below -15000 is it pretty much applying 100% thrust in reverse already!!! No FS aircraft allows this in any case -- max reverse is usually about -4096 (25%, it is set in the AIR file or by an Aircraft.CFG parameter). PLEASE read what I am saying, and also what the documentation is saying! I know EXACTLY what you want to achieve. Just delete the line you've messed up (MaxThrottleForReverser=-15000) and it should work fine, unless you cannot always get the throttles to a complete idle (0), in which case increase that parameter a little. It really should never need touching if you calibrate correctly! Look, I'll even reproduce the reference in the documentation: See the bit saying "the reverser will not engage until all throttles are reduced to this setting (normally 0, or idle)", even clarified by the bit saying "You can try a non-zero value here if you cannot calibrate your throttles to produce a stable idle zero"? Are YOU having difficulties setting idle? If not, why fiddle with this? If you are, you need to INCREASE it from its default of 0, not whack it right down to an impossible to reach value!! No. Sorry. Regards Pete

Why have you set this to such a strange value? The default is 0, or maybe 256. What this now says is "don't engage the reverser until the Throttle value is less than -15000". In other words, don't engage it until it is way below max reverse already (most aircraft have a max reverse of -4096 or so). This value is set to allow the reverser to work even if the throttle calibration isn't spot-on, and the current Throttle value (inside FS) isn't quite zero. Forward thrust throttle values run from 0 to 16383. If this parameter were set to 16384 then you could engage reverse even with throttle at full max thrust (most unrealistic). With your setting you can never engage reverse thrust! So, why did you change it? Are you reading something I wrote somwhere that suggested it was correct? :-( I've just re-read the description in the documentation and I cannot see how you could possibly have decided that -15000 was a good idea. (See where it says "idle zero" for instance?) FS's throttle runs from around -4096 reverse to 0 idle to +16383 full forward. This is what calibration attempts to achieve for you, converting whatever strange values come from your joystick into the values FS understands. Regards Pete

Pretty much all of the applications (other than aircraft installed INTO FS) which need FSUIPC to talk to FS -- check http://www.schiratti.com/dowson, there's a list of a lot (but by no means all) on the right-hand side. Myself, I use Radar Contact, ActiveSky or FSMeteo, FS RealTime, FS Flight Keeper, several Project Magenta modules, my own TrafficLook and WeatherSet2, etc etc. Surely you would decide what YOU want to do first, then configure things accordingly, not buy something then think of a use for it? That really was only ever useful in FS98 days, for Chris Brett's EFIS98 program, which had a set of gauge-type displays docked to FS's window. The bitmap was a way of providing it with a cockpit sort-of background. These days probably all separate FSUIPC applications don't dock to the FS window at all, so you don't really need or use the WideClient window -- though it does get used if you want its button capabilities mousable -- those are really designed for a touch-sensitive screen though. I use one in my cockpit. Otherwise you are better off minimising or even hiding the WideClient window, as it gives more screen space for real applications. Regards, Pete

That's annoying. What about the trim axis? If it is truly dead, I would need more code to maintain my own copy. If the axis works, I could make the INC/DECs work too, just a little indirectly (i.e. via the axis control). Try the Robinson, please. I think that's a prop internally. I won't get time to look at anything here till later next week. Pete

All that is very interesting, but none of it really can be at all to do with anything of mine. You've got something in a mess there. I suggest you review everything you've installed or changed recently and try to undo them one by one until you find it. Either that, or re-install FS altogether and start again. The fact that you are getting two of some things seems to imply you may have some duplication or other odd things installed in your modules folder. You haven't been messing with anything there have you? Most of the DLLs are essential parts of FS and shouldn't be changed, and certainly nothing should be renamed or duplicated. For general advice and help with FS2004 I suggest you visit the FS2004 Forum. Regards, Pete

WideFS is an extension of the FSUIPC interface, for external FS applications (i.e. those you can run OUTSIDE of FS). It says this clearly in the documentation. FSNavigator is exactly the opposite. It is not an FSUIPC application -- it does not use or need FSUIPC. So even if it was an external application it wouldn't run on WideFS which is an FSUIPC interface. However, FSNavigator is not even a separate application, it is installed into and runs as part of FS itself. How do you propose to even get FSNavigator, the program, moved over to your other PC? There's no separate program as such to move! Regards, Pete

Couldn't I use the trim values for that? i.e. an option to add the trim to the elevation value continuously (but keeping it in limits of course) -- assuming, that is, the trim values are only being ignored by FS, not being zeroed. (to find out, please monitor offsets 0BC0 and 0BC2 in FSUIPC's Monitor -- see Logging page. Monitor them as S16's. If they respond to trim inputs (keyboard or INc/DEC controls or an axis input), then this seems the easiest and most reasonable. BTW does this lack of elevator trim action apply to all FS helos, or only those using a truly helo model? One of the two in FS2004 is classified internally as a prop I think. Regards, Pete

Sorry, I don't understand you. what software? If you are using Microsoft FS (are you?), then the prop pitch and mixture controls are part of the basic FS design and have been available in most versions of FS I can remember. What sort of "update" are you talking about? FS supports up to 4 throttles, 4 prop pitch controls and 4 mixture controls, separately for up to 4 engines. It also provides a generic set which control one or more engines from one input according to engine selection facilities 9like E+1 2 3 4). All these are assignable in FS's own assignment facilities. Are you looking there? Or are you using FSUIPC's recent axis assignment facilities? You do really need to explain a little more about what you are doing and how you are doing it, and what the problem is. Regards Pete

But if you are using the correct FSI (version 2) and the FSI file I supplied, the Altitude display is shown as one 64-bit value not an Alt-Hi and Alt-Lo. But in that case, if you have defined the variable you read "Alt Lo" into as unsigned, it is actually impossible for it to take on the negative value you show. Something is screwy somewhere! Anyway, since you now have an even later development system than I do, why not move over to using 64-bit integers where they are appropriate, and make your life much easier? Pete

FSUIPC doesn't touch anything unless you ask it to. Just delete the FSUIPC.INI file in the FS Modules folder. It sounds like you have made a bit of a mess of the settings. By default none of the joystick, button of keypress programming options are active. Regards, Pete

In actual fact, the Alt is really just one 64-bit fixed point number. It is only represented in FSInterrogate version1 as Alt Hi and Lo because that program could not handle 64-bit fixed point. It cannot be negative, as the lower 32 bits of a 64-bit number has no sign bit -- the only sign bit in a 64-bit signed number is the one right at the top, which in your terms is in the Alt Hi part. The number is unsigned, but it is a fraction and has the same sign as the high part, so after evaluation, if the high part is positive, you add it to it, if it is negative, you subtract it. It is far easier if the language you are using supports 64-bit numbers (eg __int64 in C/C++). Okay, in that case you are nearly there. Since it should have been treated as positive, you need to add that to the most positive number that fractional part in metres could hold, plus 1. Since that would be 1 metre, in feet your answer is 3.28084 - 1.4066 = 1.87424 ft. Now you must add that to the feet from the high part, if that is positive, but subtract it from that if it is negative. One of you is approximating somewhere then, as that would make one metre equal to 3.28051 ft. However, it is close enough for normal purposes! ;-) Surely you are not still using FSInterrogate version 1? My last version of the SDK only provided an FSI file for FSInterrogate version 2, which is far superior. Correct, it is never negative as it has no sign bit. It is the way you are interpreting it, not the nature of the number. It sounds like you are using that dreadful Visual Basic which doesn't bother to provide any support for unsigned numbers! :-( Pete

No idea, but the Client log is only half the story -- you never said what the Server log showed, nor whether this was just on one of the Clients or all of them. If all that is happening is simple timeouts then you have something taking time off WideFS for long periods -- 18 seconds is allowed by the Client before it decides the connection is broken. But without any information I cannot tell you any more. Pete

Sorry, there is no solution apart from purchasing an FSUIPC registration. That F16.GAU is programmed rather strangely, and on some folks systems the registration never works, and on others it always does. I have no problem at all with it here. Some folks have found it works fine after they completely re-installed Windows, so it maybe something esle which interferes with it. You'll find lots of threads here about it, though none recently. It is the only GAUge on the planet which has this problem, which has proven intractible. In the past I've recommended folks try other freeware TCAS gauges which are well behaved and actually register themselves automatically -- look for those by Lee Hetherington, for example (ILH_TCAS.Gau and others, I think). Regards, Pete

The whole purpose of the separate throttles facility in FSUIPC was to provide an idle centre and a reverse zone. You could do what you want very easily just in FS alone. However: What would be the point of that in any case? You NEED an non-zero idle zone anyway to get an Idle position. What you are after is making the zone BELOW idle impossible to reach. If -15409 is the minimum your axis provides then you could do something like Throttle1=-16383,-15450,-14000,15805 for example. Now the reverse range (-15450 to -16383) is impossible to reach, and you have an Idle zone from your minimum (-15409) to -14000. If that's too big, adjust the -14000, as you like. Regards Pete

Ah, I see. In C a constant can be forced to be a double by simply adding a decimal part, thus 360.0 The VB "#" method is a bit like having to use "F" for float (the 32-bit version), as in 360.0F, or even 360F. Thanks, Pete

The explanation is in the Log: "Timed out response: connection assumed lost!" The poor client is not getting anything from the Server and times out after 18 seconds (the default for this). Is this happening on all Clients? Have you looked at the WideServer Log. Perhaps that shows a problem there? Pete

Wow, you read my answer too quickly! I amended it again when I saw some other errors. Please re-read it. Pete

No! You do all the reads and writes, as you like. Then only ONE process! The reads and writes (and gets) take almost zero time, the Process calls cause a process switch and take maybe hundreds of milliseconds each! One process call performs ALL your reads and writes in one call! Delete most of the code! For example: See? The single Process processes all of the queued Reads and Writes. That's its job, to pass ALL of your requests as one batch to FS! The only limit is the total size -- only 31000 or so bytes can be handled in any one Process request, counting the data plus red tape overhead of 16 bytes per read or write. Your list is nowhere near. Since you never process any of the results, why have a separate variable (r1 ...) for each? Even if you did check it, you should do so immediately, so you still only need one variable! Of course you could do the sequential Reads and Gets in a loop if you put the t1's to tn's in an array. Also, there's something wrong with your code in any case. You have but you are only reading an Integer into t1. The others are 64-bit doubles, as you seem to have recognised in the Reads by making the size 8 bytes. BTW I'm no expert, but doesn't the ZFW, by definition, already include all the payload, merely excluding the Fuel? Pete

It's actually FSUIPC, and you should always report the version number please. If it isn't the latest (3.53 or later at present), then update it first. Calibrating throttles will not affect the mixture. It sounds like you've calibrated the Reverser, which, as documented, uses the Mixture control by default -- though not the "Engine 1 Mixture Control" but the generic Mixture control, for all engines. If you fly props as well as jets you need to ensure that the option to have the reverser activated for jets only is selected. The only other possibility, which is nothing to do with FSUIPC at all, is that you have the Sensitivity in FS turned right down on that axis. Make sure the slider to well to the right. By the way, if you get yourself in a muddle with FSUIPC options and settings you only have to delete the FSUIPC.INI file, or edit it and delete just the Joystick calibration sections, and start again. Regards Pete

Doesn't the elevator trim work on that in a helicopter? No, that would be an horrendous thing to try to do in FSUIPC, the way things are organised. The whole calibration computations would be thrown out. The only thing I can think of is to use the axis assignment facilities to assign your control NOT to any analogue input at all, but to a series of INC/DEC controls (i.e. using the right-hand side of the assignment facility). Program a centre zone which sends the axis control with a zero, and a succession of zones either size which send one or more INCs or DECS (depending on direction), with probably a repeat action at the extremes. It's messy but you'd end up with something more like keyboard control but using the stick. This is almost exactly what elevator trim does, in effect -- I'm very surprised it doesn't apply to helicopters. Have you tried applying a trim axis? Regards, Pete

No. I have reproduced the problems here. It looks like Windows cannot handle either the record/playback or PostMessage systems for keys which cause programs to change from modeless to modal (as when entering menus). I have tried tracing it, and using Spy to check on the progress of the messages into the program, and Windows gets itself knotted and all of them screw up. The logic in WideClient is fine, it is definitely sending all the right things. I'm afraid there doesn't appear to be any solutionunless: The only way which seems to work is the directionless "SendInput" method, as I use in FS itself from FSUIPC. For this you'd have to leave off the "RunReady1" parts on the KeySend lines, and specify UseSendInput. The problem with that is that you must be sure to leave Traffic Look with the keyboard focus, otherwise the keystrokes will go elsewhere. My advise is to have both ground and airborne displays on view, side by side, as set up in the default INI I supply. Regards, Pete

I really have no idea how you get an overflow. You need to debug your code to see where it is occurring. It is nothing whatsoever to do with FSUIPC. Your code shows a Subroutine in which, everytime it is called, Opens a link to FSUIPC (this involves seriously heavy calls to Windows to create a memory mapped file and set a unique Atom for it), writes just one value, with one Process call, then closes the link, which closes the memory maped file. I really do hope this is not indicative of how you are programming, as yours will be the most inefficient program ever to interface to FSUIPC! :-( If the VB.NET code you are using (presumably from the examples in the SDK) follows the C source examples I provide, then the only purpose of writing to 330A (a read-only location) is to make sure I get an entry in the log showing the Version number of my original C source code in the SDK. The reason you get several is because you are repeatedly re-opening the link to FSUIPC. See above. The VB.NET debugger doesn't even show you the line which gives the overflow error? Are you sure? It must be the worst debugger in the world then, or you are seriously misusing it! If it won't point to the line, try single stepping through. Surely it supports single stepping? You have all the source code, and the error is occurring in your program. Sorry, I have to give up helping at this point. It really sounds like you have chosen the wrong language altogether if it is so bad as you make out. :-( Regards, Pete