Pete Dowson

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

Aha! Good find! In fact, that is correct. The conditions in the [Conditions] section operate just like the Conditions in the main unit section. Your line: 31=C13 C14 C2 C5 C8 C15 =1 says to make condition 31 "TRUE" when all those conditions are true. But if any one of them are not true, the line is ignored. There's nothing to make that condition "false". In the unit section this would simply mean the next line for the same display being checked, but there are no sequences of lines for conditions. This is actually a correct logical result of the design philosophy, but I can see now that it is a problem. With conditions you actually want them initialised to "FALSE" at the beginning of each pass -- this is different to displays. I'll take a look this morning. If it is easy to fix I should be able to get a revision to you today. Regards, Pete

You seem to have developed a style of programming which rests entirely on conditions rather than using the facilities the way I intended. I'm not sure what to make of it to be honest, though it is "within the rules" and so should workhmmm . The prime programming method was intended to rest with the details you could enter into the main parameter lines. You have no details in the main parameter lines at all. :wink: They aren't additive. Each line is computed in its own right, in sequence, conditions first then each unit in turn. Strange. All that seems to be understood correctly, yes, but you could try "L3.4==0" just in case -- the first = is absorbed by the Windows INI file system, so the parameter looks like just '0', which should be okay, but literal values would normally be "=0", so it is worth trying. Maybe there's a bug. I don't know -- I'm going to have to use your example and trace it through, see what I can find. Unfortunately I'm tied up 100% until Tuesday. Sorry. I promise I'll look at it as soon as I can though. Regards, Pete

Yes. I've made a note to see if I can get the water rudder information easily or not, but I won't be able to get to it for a couple of weeks at least. Regards, Pete

That's odd. Doesn't C# support the standard Intel 32-bit floating point format? Well, I do hope there will be someone who knows C# enough. Seems odd the way Microsoft develop these languages, making them more and more restrictive. I was surprised at many of the deficiencies and quirks of VB. Regards, Pete

Okay. I don't know if I can find the state, but if it's a "toggle" then it may only indicate on or off (down or up?) not whether it is moving. Is the rudder actually animated? Throwing a switch in itself is nothing to do with GFdisplay, unless you have programmed it so. Do you have the T8 also being driven by GoFlight's own drivers? If so then I think it will clear the LEDs on all sorts of occasions. On the FS PC this will be a GoFlight DLL in the FS modules folder. I think the current GF drivers do this even if you tell them that specific displays aren't programmed -- Doyle (GF proprietor) did say he would be making new drivers to avoid this. Check the GF website and ask there if nothing is evident. Regards, Pete

I don't thnk AVC uses FSUIPC so it won't be anything to do with WideFS. I don't know of a "Tuner". ActiveSky works very well through WideFs, that's how I use it. If you have problems with WideFS I need to see both Server and Client logs and INI files. Regards, Pete

From that description it sounds like they are using the byte to hold a VALUE, not a BIT. Why do you think those 0 and 1's are bit numbers? It looks like you should write a 0 to the byte (Offset Byte Set) to set 'normal' mode and a 1 to set "standby". Regards, Pete Many thanks David

Aircraft altitudes, like mountain tops and contours on maps, are of course measured from Mean Sea Level, as is this one. Why would you expect anything so wildly different from standard aviation (or even general) practice? Do you measure your home's altitude from the Earth's centre? :? It is available in two places -- 0020 and 0B4C. Both are listed. You can use them for radio alytitude calculations if you need such. Pete

I don't know. I'm not aware of a water rudder, I thought that would be in a boat simulator. Is this something for float planes? Is it part of FS or part of an add-on aircraft? What control do you use to operate it? FsInterroge would tend mostly to only find things which are already known. It was different in FS98 days when the interface was a simple window to FS globals. These days I have to analyse FS internal code to find and extract each snippet of data. Regards Pete

Good. Can you tell me exactly what you did, in case I get another case this year? :wink: Was it a later video driver, or did you find the COMCTL2.DLL somewhere and install it? Regards, Pete

That's odd. Perhaps my informer has identified it incorrectly. How about the other fields giving waypoint IDs, lat/lon/alt information, even bearings and ETE's? I'm at a bit of a disadvantage here, having never used either the FS planner nor the GPS facilities. The information on the contents of those offsets was all provided to me by others. I had assumed they had tested it. Maybe the current waypoint index is in another (undocumented) location. Maybe FSInterrogate will help find it? Regards Pete

I didn't see any picture, but I can guess what it looks like. This happens rarely (about six times to my knowledge in 5 years), but it seems to be due to a mismatch between the standard Windows libraries for dialogues and the extended library for common controls (COMCTL2.DLL) which is used to get the tabbed "property sheets". FSUIPC uses all standard Windows facilities and none of the Window dimensions or font sizes, and so on, are set by FSUIPC, but scaled according to your video drivers and screen settings. I think that what must happen is that sometimes video drivers (maybe other programs too?) install a version of the COMCTL2.DLL which is not truly compatible with the version of Windows you have installed. I think you need to find a way to restore the correct copy. At worst this may mean a reinstallation of Windows, but possibly there will be a way of telling it to update that one library. Regards Pete

I'm sorry, but nothing in any of my programs puts anything on desktops. WideFS doesn't create folders, doesn't create icons, doesn't touch the Registry. It does nothing of that sort. If you have something on your desktop, either you or another program must be putting it there. Are you sure you installed WideFS into a disk folder and didn't just put it on the desktop yourself? WideFS comes in a ZIP file and you are free to put the WideClient.EXE file wherever you like. Maybe you put that and the INI file for it on your desktop? If you delete the INI file, WideClient will make another one, of course. It needs one in order to run, and it needs the parameter inside which tells it what Server to use. Right-click on it and check the Properties. You should be able to find out where it is coming from. It is best to install WideClient.exe and WideClient.ini into a folder, usually in the same folder as the main application program you want to run. If you want an icon on the desktop, drag a shortcut to the desktop NOT the program. Regards, Pete

I'm sorry. I simply didn't have the time (nor really the capability) of doing a more friendly interface -- even if I did I think it would still be more of a programming language than anything easy, because I wouldn't want to sacrifice any of the flexibility. But that's why I made up for it by providing operational examples with a thorough walk-through. Or, at least, I did think it was thorough. Well the button assignment can be done directly in FSUIPC's Buttons dialgogue. You don't need to fiddle about with any parameter lines for that. I don't think anyone has any difficulties with that part. Several points here. 1) You don't need a condition for this. The LED is on if the Pitot Heat is on, off if the Pitot Heat is off. It's a simple one-to-one relationship. The conditions section is there simply to enable you to do much more complicated thinks, like, for instance, only lighting the LED if pitot heat is on AND the engine RPM is over 2400. Complex stuff like that. It is best to start simple, and you cannot get any simpler than one value one light! 2) The line "L3 C0" is missing the =. That's just a blatant syntax error. All Windows INI and CFG files are in the form ID=VALUE and these lines are no exception. 3) If you did have L3=C0 the line is still incomplete and therefore invalid, because you've provided a condition, but not said what to do when the condition is true. You'd also then need another line to say what to do when the condition was false. i.e. L3.1=C0 ..... L3.2=!C0 ..... However, as I said in (1) above, you really don't have any conditions to which this LED is is subservient. It is just supposed to be on when the pitot heat is on. So, the complete and total INI file you'd need would simply be: [GFP8.1] Needs=B E B=8 L3=X029C U8 This says that L3 is lit when the unsigned byte ( U8 ) at offset 029C is non-zero, and is not lit when it is zero. Please peruse the examples in my document again. You will notice that the conditions deal with things like "Is Project Magenta running or not" and “Is the CRS non-zero” (the latter so that 0 can be replaced by 360), and also conditions which determine whether IAS or Mach needs displaying. etc etc. They are all things which do actually condition whether a display or LED will display or light according to the rest of the parameter's definition. They never, themselves, define what the display should be! Regards Pete

Version 6.401 is very old now and is not supported. The current version is 6.47. Please upgrade first. Then if you still have problems, please note that it will be the WideClient Log which would be more relevant, not just the Server. You also need to say what programs "don't work". Regards, Pete

I just occurred to me that the CH quadrant has buttons operating at the detente in any case, so you should be able to use the CH manager to calibrate the axis range before the detente all to give zero (spoilers down), use the button to send FS the Spoiler Arm control, then the rest of the movement to give 1-100% deployment. Check Bob Church's stuff on this. To quote him from another thread near here: Let me know. I won't have time to change FSUIPC again before I release 3.48 and it may be a few more weeks before I can look at doing any spoiler calibration changes. Regards, Pete

Somewhere along the calibrated range of the axis, the arming should occur. You'll just need to find the position and mark it. A possible enhancement to FSUIPC's spoiler calibration, which I'll consider, is having a "centre zone" (labelled as "Arm"), which can be calibrated off-centre, so to speak, and give a range of values able to arm the spoiler. I'll have a look, see if I can squeeze it in. Note that, in FS2002 and FS2004, when calibrating and testing your spoiler axis, do it with the aircraft in the air. If you pass through the "arm" values when the aircraft is on the ground, the auto-deployment is usually activated and it'll go directly to 100% Regards, Pete