Pete Dowson

I'm not sure why you would be worried so much about "absolute" values -- your joystick will be using a potentiometer or a rotary encoder or something which effectively generates arbitrary values. The incoming numbers themselves do not matter at all, they are completely irrelevant. It is the sole purpose of calibration to take the stupid input numbers and manipulate them to produce sensible and well-behaved output numbers. It is the latter which are used, not the former. That is why this (and almost every other) calibration system is based on real PHYSICAL positions -- you move your joystick to the spots where you want the entremes and the centre zone limits. You shouldn't care what the numbers are! You can edit the INI file and put arbitrary or artificial figures in there, but I honestly do not see the point. The whole reason for calibration is to convert chaotic real world values into usable internal values. By assuming specific numbers will work well you are assuming the stick is producing well-ordered outputs in the first place -- for instance, that its centre is exact and always produces zero. Also, instead of an extra wide, or narrow, or (in your words) "accurate" (?) centre dead zone, why don't you try applying one of the slopes provided which flatten the response near the centre, reducing its over-sensitivity without losing range? Regards Pete

There's been a lot of changes since 3.411. This may take some finding. Leave it with me for now -- I'll get back to you if I need more information. The separate reverser assignments are not relevant unless you go to the last page and set them. Regards, Pete

There's only one altitude hold. Lock is just another word for it, used inside FS -- MCPs/FCUs are generally marked "hold". You are misreading the other. Offset 07D8 is ATTITUDE hold, not ALTITUDE -- there's quite a difference! Unfortunately I have never known FS's attitude hold to work. Regards, Pete

No, the autopilot maintains heading if heading hold is engaged. The heading shown (and set) is magnetic, not true. Don't forget that the autopilot must also be engaged. Setting a heading hold without autopilot is valid, but only gives you flight director guidance, not control. Generally you would set heading hold then change the heading value -- this is simply because of the way FS works. Just set the hold then adjust the altitude. The autopilot must be engaged or, again, it is only a flight direction facility. Test with a default FS aircraft. You talk about the FCU, but none of the defaults have an FCU (the Boeings have MCPs of a sort). Many add-on aircraft panels do not use the FS autopilot facilities so you may be wasting your time writing to these places. Regards, Pete

Of course it does, because you are pressing the button to register FSUIPC -- this is for a personal key, to give YOU full access to all FSUIPC facilities. Please note that Visual744 is an APPLICATION, it is not a user -- people are users, programs are programs. Look again at the first options page in FSUIPC. Cast your eye down to the button at bottom right. what does that say? Something about applications, yes? Try that. Programs do not have user names and email addresses. Programs have program names. The name for this is Visual744. That's all. That and the key. There are places for you to enter these. Please please check the FSUIPC documentation. The business about user registration and the difference for program access is explained there. Regards, Pete

The CDI deviation is just another variable provided by the simulation engine. Are the segments of course short? There may well be small errors in the great circle calculations which will show up as such errors on longer segments. But I don't use either the FS plans or GPS nor FSNav so I've no experience of their accuracy or otherwise. The CDI is likely to be more accurate as it derives directly from FS's real time simulations. BUT check this on a default aircraft -- other gauge implementations may differ. You may get some more help in the FS2004 Forum, too, where there's a wider range of users I think. All NAVAID position and frequency data is contained in the scenery. For VOR radial deviations the CDI is calculated in real time based on the position of your aircraft, the position of the VOR and the selected radial. Naturally, as you get closer and closer to the VOR the radials become closer and therefore minor deviations look more and more significant. When you are quite close the VOR radial indications become almost useless because the radials are too close and you are above the VOR rather than so much laterally spaced from it. It is normal to ignore VOR deviations when close, just maintain heading and resume the opposite radial well after crossing. How that all works when using the GPS to set the course I really don't know. Regards, Pete

No. what would that mean, exactly? Sorry, I'm not understanding much of that if any. What are those numbers --- how are 0 and 512 related to speed of stick? What numbers are those and what is meant by a "tight stick" and a fast or slow one? Regards, Pete

No, except the one below yours. The changes in 3.48 since 3.47 are really not in-line with normal execution, with the sole exception of the provision of bank and pitch data being supplied for AI aircraft. I really cannot imagine that have such a great effect, even if you've set the AI scan rate to 100% (default is 10). Try setting it to less than 10 (5 or 8, say), see if that makes any difference. Let me know. Generally, on most systems I've tried it on, you'd be hard pressed to measure any difference between 100% and 10% AI scanning per frame let alone the addition of two more small items of data. All the other changes (which are few in any case) only have any effect when used, like button programming fixes. Regards, Pete

Hmmm. I've not made any changes recently to anything that might affect that. Can you tell me the version number of the last version you used with this working, please? I may have inadvertently messed it up, but I need to know when it may have been to narrow it down. Please attach your FSUIPC.INI file too (in text form if you like Thanks Pete

Run it again. close FS. ZIP up the FSUIPC.LOG and FSUIPC.KEY files (both from the FS Modules folder), and send them to me at petedowson@btconnect.com. Regards, Pete

Yes. Something installed in your FS9 is not closing down correctly when you terminate FS, and this is actually stopping the session being closed -- the windows are all closed, but this add-on (probably another DLL rather than a Gauge) is still running and waiting for some event. You can deal with it each time by using Ctrl-Alt-Del and closing the Process from the task manager's Process list (FS9.EXE), but you really need to find out what does it. Certainly earlier versions of ActiveCamera could do this, and also, I've heard, some versions of WidevieW. There may be others. Check each added-in DLL to start with. The reason FSUIPC complains and prevents you continuing with a second instance of FS is that there would then be two instances of the FSUIPC interface for applications, and this would cause problems when you tried to run other programs. Those problems would be much more difficult to diagnose. Regards, Pete

If you can be a little more precise on what the message is, I can maybe determine if it is anything to do with FSUIPC itself or a message produced by an add-on. Also, if, after this happens, you check the text file "FSUIPC.LOG", which you will find in the FS Modules folder, it will contain information which may precisely identify the culprit. If you don't understand the file, paste it here for me to check. Regards, Pete

Have you calibrated the reverser (or 4 separate reversers) in FSUIPC? By default they use (steal) the mixture axis (axes). There are options for having this only apply when you have a jet aircraft loaded. Perhaps you need to set that option? Regards, Pete

Or at least what it does now:wink: Regards, Pete

:oops: :oops: :oops: Thank you for your appreciation. Though it is mainly my hobby rather than a job as such, so I enjoy it anyway, knowing it is appreciated does make it feel all the more worthwhile! Best regards, Pete

As I've explained earlier in the thread, the FS threshold for the grey/blue representation is 10 miles in FS2004 (about 4 in FS2002 and FS2000). This is the reason. All versions of FS have that effect. In FS2004 Microsoft did try to get around that problem by adding a very thin layer of stratus cloud at the top of the visibility layer. But many people didn't like that either because, being cloud and not visibility/mist/fog, it only gets drawn to the cloud drawing distance (one of the slider options), then stops dead with a straight edge. Looks very odd. Also, if there is rising ground within the affected area, the cloud cuts off as the ground rises above it and also looks very odd with a straight edge. Because of these effects I think many of the replacement cloud graphics offered on assorted websites actually somehow defeat that thin cloud layer. Mostly, yes. There maybe something you can do, using an appropriate cloud graphics set and a good weather program, but in the end FS will not show blue skies with visibility 10 miles, but it will at 10.1 mies. To stop that sudden change you would either have to impose a maximum of 10 miles and never have blue skies, or a minimum of 10.1 and never have true mist or fog. Hopefully this is a matter which will be addressed in the next version of FS, whenever that might be. Regards Pete

It is nothing to do with FSUIPC, as you can see by simply removing FSUIPC from the modules folder and trying again. It is part of the CD and anti-piracy protection build into FS2004. As well as the disk copy check they build in, they detect and stop debugging programs attempting to get inside the running code. At least that certainly appears to be the function. The "no CD" hacked version which has been circulated does not create that process. Regards, Pete

Okaybut if you do subsequently find that, probably optionally, the delayed display options should postpone actions resulting from value changes, let me know. I'm sure it could be accommodated. Regards, Pete

FSUIPC really does NOT deal with the axes themselves. It deals with the Axis controls which FS generates as a result of access value changes. You can actually log these in FSUIPC's logging page. The most likely thing that's wrong is the sensitivity setting in FS. Go to Options-Controls-Sensitivity and check. FS2004 in particular seems to have a tendency to reset certain axes to zero sensitivity (= 'dead') for reasons of its own. Until the axes work reasonably well in FS, there's little point in calibrating them or chaging them in FSUIPC -- it only gets passed what FS would use in any case. It is those values which you then 'manipulate' with more precise calibrations, sloping responses, filtering or reversing. Regards, Pete

Blimey! That's certainly a 'bonus'. I wouldn't have expected it to workHmmm. I wonder how it does? I think I'll delve into the code next week, to see how it's being cleverer than me! :wink: Regards, Pete

Sorry, I wasn't intending to tell you off. Possibly you want it to work the way you suggest? i.e. if there's something which should hapen for n seconds after an event, that it should happen for those n seconds no matter what similar or counter events follow in that time? If this is really a need I can think about how to accommodate it, but it does make things a little ambiguous about what should happen about these intervening changes. Should they be ignored, or have a result which is queued until the n seconds are up, or what? It does get rather complicated as you can perhaps see. Regards Pete

I've heard of this sort of thing before. It's not common, and I don't know what causes it, but it has something to do with Windows and drivers on one or both machines. WideFS itself cannot queue data. If it runs slower because of resources, that just means a slightly jerkier update rate -- because when it passes the data frames to Windows for transmission it fills them with the current values, not some values which were valid even a second ago, let alone 25 seconds! So, the queuing is occurring someplace either in Windows on the sending PC, Windows on the receiving PC, or possibly a buffering switch, hub or router in between. How you determine where things a going wrong and why I am afraid I do not know. I think one of the sufferers of this type of problem got around it by a complete re-install of Windows etc, but I also seem to recollect another found there was some interaction with some other networking software, presumably firewall or virus check or something. I hope one of the earlier folks will see this and chip in here. The threads which contain the original chats will still be here, in this forum, somewhee, but searching for them may take some time with there being some many accumulated messages now. If you are using Project Magenta you may try using the PM newsgroup, as there are almost bound to be folks there who've seen this too. Regards, Pete

No, that isn't the case. GFdisplay has to be able to respond logically to changes in the values -- how else can it deal with them. As soon as the value changes, the action caused by the previous change ceases and the logic is re-scanned. As the release notes said "These all apply only when, without the flash/delay option added, the display would have been enabled/lit." Maybe I should have said "while" rather than "when", but I did think it was clear. Up to four offsets can be monitored in a number of formats using the FSUIPC Monitoring facility (see Logging page, right-hand side). You can check the Advdisplay option to have these shown in the normal FS message window, or run AdvDisplay and have it elsewhere. Regards Pete

I don't know this "glPrint", But if it is based on the standard library printf routine the formatting directive %d tells that routine that the value is a 32-bit integer, not floating point. You need %f. Please look up the definitions for printf formatting. // 20° up line glBegin(GL_QUADS); glVertex3f( 0.4f, ((double)_pitchrate/1800)-1.43, 0.0f); glVertex3f(-0.4f, ((double)_pitchrate/1800)-1.43, 0.0f); glVertex3f(-0.4f, ((double)_pitchrate/1800)-1.40, 0.0f); glVertex3f( 0.4f, ((double)_pitchrate/1800)-1.40, 0.0f); glEnd(); The notation 0.4f tells the compiler that the 0.4 is a 32-bit float. For doubles, as this should be, you don't append the 'f'. Please check with a C programming book on these matters. Regards, Pete

As expalined in the instructions, just copy the updated FSUIPC.DLL module into your FS Modules folder, overwriting your older one. All versions 3.xxx use the same valid keys. You only need to re-register (with the same key) if you reinstall Windows or move to another PC. Regards, Pete