Pete Dowson

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

That's the main entry point provided by the basic library code needed with any Windows program. Sounds like you've excluded all the standard libraries. WinMain is the entry point in your code which it calls, for a Windows (as opposed to DOS) type program. There's a Windows API called "Sleep(milliseconds)". But your whole program reads like a DOS program. A Windows program should surely at least have a message loop to process messages, and a Window (even if hidden/invisible) in which to process them. Then it would be much more user friendly to use SetTimer to generate a wake-up call every 500 mSecs., allowing the program to process messages (like WM_CLOSE) as well, and generally be responsive. If you do it the way you've done it you could instead rename WinMain as main and compile it as a DOS program. (A "Win32 Console" program is probably the more proper name -- whatever, it would run in a DOS window). Regards, Pete

All WideFS provides is simply a Network copy of the FSUIPC interface. The FSUIPC interface is used by programs to extract information FROM Fs and input information TO FS. That includes all the weather data which ActiveSky downloads and processes, but it does not include actual graphics, aircraft, cockpit panels, scenery, or anything that has to be installed INTO FS. In particular, cloud textures go into FS's textures folders and are only picked up by the weather system in FS based on codes (for cloud type, height, and so on) in the weather data, which can be sent via WideFS as it is part of the FSUIPC interface used by ActiveSky. To put it another way, if you don't know what you want WideFS for, I don't think you want WideFS. Please do not pay for it just because it looks interesting. It is a solution to specific requirements. If you have those requirements you will know you need it. If it is still not clear, tell me what you want to achieve and I will tell you if WideFS can help or not. Okay? Regards, Pete

All the options which can be applied can be applied at the same time. Yes. Regards, Pete

I really cannot explain it any clearer than I have in the manual, else I would have done so there. Sorry. I can answer specific questions but otherwise I'd only be repeating what is there. It has rarely confused any one else. What specifically is the problem? As for "best" that is completely a matter of personal taste. For the values themselves my own taste is reflected in the defaults, that's why they are defaulted. All you need to do is enable them. I D/L FS2004 WX for my flights with no other programs. Just enable the smoothing and graduation and leave the values as they are -- unless you fly light GA aircraft in which case you may wish to lower the upper graduation altitude to something a little below your normal cruise level. The visibility limits were mainly designed to give higher frame rates in FS2000/FS2002 in cloudy conditions, without losing realism. In FS2004 reduced visibility doesn't seem to have any real beneficial impact on performance, so whether you want to set any is completely your choice. Regards Pete

I guessed your name was Italian :wink: . My wife comes from Bristol -- I went to University there. Nice city. I am from London (well, close) originally. Actually Eastcote, Middlesex. Regards, Pete

Yes, it is easy enough. I'm looking to release 3.48 early next week. But I'm not sure you will actually get better results because I thought you still saw this phenomenon using FS's own weather downloads too? FSUIPC doesn't change those with this option. Maybe you just had bad luck with FS/Jeppesen weather? If so you may see things better with FSMetar. As it says on the left somewhere, I'm near Stoke-on-Trent, also UK. In fact I'm about 15nm almost due south of EGCC. Regards, Pete

I assume that it is Squawkbox supplying the weather? Have you set any weather options in FSUIPC? Check the visibility page in FSUIPC options. Have you set a high minimum visibility there? The other, and more likely, possibility is a problem with your FSUIPC user key (or your WideFS key if you are using one). To check this, please try again with it registered, then close FS. Zip up the files "FSUIPC.LOG" and "FSUIPC.KEY" (both from the FS Modules folder) and send the Zip to me at petedowson@btconnect.com. I will check the keys here. So far all instances like this have been due to bad keys, so that is the best check I can do. Regards, Pete

No, I've never noticed it at all using FSMeteo or ActiveSky. I assume they set their own visibility values. Also, none of this explains why you also see it with FS's own weather downloads, as FSUIPC cannot and does not then operate that feature. Maybe, but there are rather too many as it is. Personally Ii don't see a problem in assuming more than 10.4 miles for 9999 metres. I doubt that anyone will notice -- and you wouldn't really expect to see grey murk when the visibility is quoted as 9999 (or even "at least 6.2 miles", which is what it means), would you? Regards, Pete