Pete Dowson

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

I'll check here when I get time. Maybe the version check or something, though, as I say, the same SDK code is used in the others. It may be Tuesday before I can get to this. Regards, Pete

0x0020 is one of the original "un-mapped" FS values so it should be okay. When you say "correct" your altitude, you mean you are needing radar altitude? i.e. AGL? Try the one computed by FSUIPC at 31E4. Which, the one at 0020? That may just be an FSUIPC cycle for lower priority items. Clarify what you are talking about and I'll check. Is that what you think is updating only every 200 mse? As far as I know all the values for the 6 variables, LLAPBH are updated by FS every frame. Regards Pete

I'm very sorry, but this is most definitely outside my sphere of knowledge. I really haven't the foggiest idea what that parameter is or what it does. I would suggest asking in the FS2004 Forum, or, better, a scenery designers forum where such things are bound to be understood better. Sorry. Regards Pete

It sounds like you are not reading them as 64-bit double floating point numbers, that's all. The code looks okay to read them as doubles. What are you doing to display them as text? It sounds like your print formatting is wrong. Let's see that. Was offsets are you talking about there? If this is something containing a signed byte then 255 is -1 and 128 is -128. It should run 127 to 0 then -1 to -128, in one direction, reverse in the other. It sounds like you are typing a signed byte as unsigned. Re-define it as signed. Incidentally, I see that you have 218 warnings from the compiler. This generally means that the compiler had to make decisions which by right you should be doing. For instance, your double values may be getting offered to a function as a different type, and so on. It's best to check all warnings and work on reducing them to zero. You'll be surprised at how many problems that process solves. Regards Pete

Ah. Good. I'll make that a general release then -- Tuesday, though. Thanks, Pete

The other programs you mention all use the same base code fron the SDK that the examples do. What exactly do you mean by "none worked" in this context? What specific example (I only provided one, the Hello one in the C part of the SDK. The others are copies for different languages). Regards Pete

No. Only FSUIPC_Process does the actrual Sendmessage. The Open function calls FSUIPC_Process as well, but that's only to verify the connection and obtain stuff like version numbers. The Read and Write functions are simple data format preparation to make it easier for programming. If you wanted to construct the data yourself you'd only use FSUIPC_Process. I think you misunderstand the nature of separate processes. Think of each process in Windows as being a separate PC all to itself. Processes can communicate via messages or shared data files. No other way. FSUIPC uses both -- messages to ask it to do something, shared files (in memory, known as "memory mapped files") to exchange data. Other forms of inter-process communication such as the debugging aids to read and write a process memory and DDE use variations of the same basic method. For you to call FSUIPC.DLL directly it would have to be loaded by your program and run in your process. In order to get information into or out of FS it would then have to use memory mapped data and messages to pass requests, just as the supplied library code does now. So the version of "FSUIPC.DLL" you would have in your program would effectively be just the code already provided for you but with macros or more layers to make the FSUIPC_Read and Process calls get single items of information. This would be very inefficient. It is best to build up the list of requests, whether read or write, and issue one Process call per cycle. If you time the cycles to approximate an FS frame rate, such as 20 times per second, then it works well. Note that if such a library (DLL) were to be provided, despite its inefficiencies, it would be completely wrong to call it FSUIPC.DLL because it would be nothing like it. Almost none of the code in FSUIPC would be at all useful running in your process. It needs intimate connections to the data and procedures in Flight Sim, and those are only accessible in Flight Sim's process. Additionally you should note that these "offsets" as such are mostly not offsets at all these days -- that's an illusion created by FSUIPC to maintain the interface as original designed for FS95 and FS98. You should think of the offsets as tokens for the variables rather than addresses or offsets from addresses. You could even equate names to each one to further this concept. Finally, the techniques needed inside FSUIPC to get this information vary enormously. Yes, with some there may be a procedure for asking FS for the data, but that is rare and even when it is needed it is performed asynchronously with requests, synchronously with the FS update rate (frame rate). Many values are mapped into assorted data structures privately owned by individual C++ classes in the separate DLLs making up Flight Sim. Regards, Pete

Please try the attached version 1.20 of GFdisplay. All I've done it initialised conditions to FALSE at the start of each pass. I think it should work, but, I'm sorry, I've got no time to test this till next Tuesday. So please let me know how you get on. Thanks, Pete GFdisplay120.zip