Pete Dowson

FSUIPC never clears that byte. As it says "This byte needs to be cleared by the application so that it can detect when the Hot Key occurs." Since FSUIPC doesn't know how often you are scanning, it cannot risk clearing anything. You should be scanning your list of hotkeys regularly, and clearing them down. If your program is going through phases where you only want to look at one key at a time you could conceivably do it by clearing byte 3 for those keys ABOUT to become 'valid', but obviously it would be easier to have a little procedure which checks all of them, and clears all of them, on each cycle whether you then act on them al or not. Take care only to clear Byte 3 on those entries you are using. These may not be contiguous of course. Other programs may have come and gone and occupied some of the slots. Regards Pete

It depends what you want to do. For most of the controls a pilot would have over his glass cockpit there are PM controls which are programmable directly in the drop-down lists of FS controls in the Buttons and Keys options pages in FSUIPC. There's an almost complete list in the FSUIPC Advanced User's Guide. For some of the controls there are parameters needed, and the complete list of those is best obtained from the PM documentation website -- the PM FSUIPC offsets document is the one. You'd only need to think about using KeySend if you want specifically to send keystrokes to the individual glass cockpit modules on their PC. But why would you want to do that? This sort of question is best asked over in the PM support forum/newsgroup, as you will get help from many others who've done all this stuff before. Regards, Pete

There's no way through FSUIPC I'm afraid. Provisions for doing what you want are, I think, built into the BGL programming system, as in "dynamic scenery". There are some variables you can use for two way communication between programs and scenery, but I don't know if they help. You could do with finding a scenery maker's forum. I'm sure there must be a place somewhere where the experts hang out? Regards, Pete

Did you search on the letters "ADF"? That's all I did! :? I don't remember all that stuff in the documents. Each time someone asks me here, I have to go look in the document too! :wink: Regards, Pete

Erit tells you right there on the screen, next to the checkbox which enables the limits, just immediately above where you enter the values which you enable by the check box! Isn't it clear enough? Regards, Pete

It's boolean then -- it can be represented by a number (1 for on, 0 for off) or just a single bit. I'll look to see where I can fit it. I'll add it before the 3.47 release I plan for the end of the week. Regards, Pete

Yes, thank you. Things are becoming a little clearer. This change in 3.410 is probably the cause (quoted from the History document): I must admit I forgot this change, a minor adjustment in a user facility. With an unregistered FSUIPC there is no possibility of the graduated visibility option being switched on, so it is a puzzle. I will conduct some experiments here. Considering this change occurred last November it is odd no one else has mentioned it. Perhaps all other SB users register FSUIPC? But that seems unlikely. I will look to see if I can fix it in the 3.47 release I plan for the end of this week. Thanks! Pete

You are correct about the other things, but where does it say to follow a keycode by K? Are you by any chance mis-reading the sentence: which is referring back to the Format of the [buttons] programming entry in the FSUIPC.INI file? i.e. The K is used in that entry to distinguish Keycodes from Controls ('C'). But that's all to do with FSUIPC buttons programming in the INI file, nothing whatsoever to do with programming hot keys in any application. You can find all the Virtual Keycodes in any Windows programming reference too. They are known by names starting VK_ and are returned by Windows WM_KEYDOWN and WM_KEYUP messages. Regards, Pete

Okay. It may help too if you did the same for a version you believe is working okay, so I can compare. Since there have been no changes at all in any of the weather facilities in FSUIPC since well before version 3.40 and all the other weather setting programs, like ActiveSky and FSMeteo, are working very well, it is a puzzle. The next release of FSUIPC, 3.47, is going to have to be frozen by tomorrow at latest so I can do final tests and documentation for release by the weekend. Then I only have a week before going on holiday until early April. If Microsoft are planning a new version of FS this year, 3.47 may the the last, or close to the last, version 3.xxx unless there are some really bad problems to fix. Regards, Pete

Please check it with the current test version (3.469 available in the Announcement, top of the Forum). Before running SB 2.3 (let's deal with one which always worked) enable IPC Write and Weather logging in FSUIPC's Logging page. Then run SB2.3 until you are sure that the visibility is wrong. Go to the FSUIPC Logging page, click "Stop Logging" and then close down FS. ZIP up the FSUIPC.LOG file and send it to me at petedowson@btconnect.com. Regards, Pete

Thanks. I'll put the known ones into the doc and the FSI file. Some easy questions for you though: int GPS_6190 at $6190; // Time when waypoint was crossed, int GPS_61B0 at $61B0; // Time of last update, see 61B8 int GPS_61B8 at $61B8; // Counter, incremented once every five seconds Are those two Times in the 5 second units (else why the referral to 61B8?) or in the single "seconds since midnight" of the Zulu seconds value? They aren't vectors based on world coordinates at all, are they? Sorry I haven't the time at present to investigate this stuff more myserlf. Thank you very much for the data, I'll add the known ones as I say. Best regards, Pete Also, 6008 starts a flight plan as 12, and is incremented when the approach is loaded, not not incremented when the approach is activated, and incremented when VTF is activated. If you then select another flightplan, it gets incremented by six. JohnS

Sorry, but FSUIPC does not control the weather, it only provides an interface for external programs to set the weather. That's a complaint you will need to direct to Microsoft or Jeppesen. Otherwise you might want to look at programs like ActiveSky and FSMeteo. Regards Pete

You mean the ADF identify switch. the one which makes the ADF ID sound in Morse? Check offset 02FB. Please use search on the Programmers Guide. That's what I have to do every time someone asks such a question. Search on ADF and you'd find it very quickly. Regards, Pete

Do you mean 3.41? The difference is in the checking of User Keys. You say "unregistered", but just try removing the FSUIPC.KEY file from the FS modules folder. If that fixes it then you have a bad user key in the KEY file. Zip it up and send it to me at petedowson@btconnect.com. Regards Pete

Do not "clear" anything. when updating just copy the new DLL into the FS Modules folder, exactly as written in the documents. Mostly the reason people get these crashes is because they delete things which are nothing to do with FSYUPC or WideFS. For instance there is an FS DLL called "FSUI" which contains lots of the FS User Interface. It is much easier simply to copy in the new DLLs. Don't delete anything. I don't have a page, only this Support Forum. My software is sent to about 50 sites. Maybe you mean Enrico Schiratti's website. Even so, it is always much clearer to state version numbers, please. What exactly happens then? You merely said you try to start FS and you get a blue screen with no other information! Regards Pete

I would have no idea how to recognise it if I saw it. Is it one of these: ROTOR CLUTCH SWITCH POS ROTOR CLUTCH ACTIVE and if so, what sort of value is it. BOOLEAN? (i.e. true or false), or some value? Time is getting tight for me now. I have to freeze FSUIPC by the morning in order to have time to do final testing and documentation. I need to make user releases by the weekend and I've only then got a week before my holidays and I have other stuff to get done! Regards, Pete

If FS didn't even start then neither of those are even running yet. It sounds like you didn't install them correctly or something else is wrong. Where did you get these "newest" versions -- and what actual version numbers are they? Pete

Aha! Now that you are specific, yes, I can confirm that the RPM data isn't obtained for the Robinson. It's a weird concoction. It is typed as a piston aircraft, not a helo. This in itself should mean I can get this data from the normal piston aircraft data structures, as for the Cessna, but they aren't there! I finally tracked them down in another structure, so I will get N1 working for the RPM (with the scaler calculations), and in N2 I'll put the % of 'maximum' (times 16384). This seems to be allowed to go up to 110 % oddly (which would be 18022 in the offset). I suppose the rotor RPM should be around too, but I can't identify it -- the values seem pretty close all the time (in % max terms) according to the gauge in the Robinson. Anyway, I've got the engine RPM here and it will be available in FSUIPC 3.47 which I'll release as soon as I've done some more testing and updated the docs. I may make one more pre-release (3.469) before then, so check the Announcements at top. Strange that this is now the 19th month of FS2004 and this is the first time anyone has missed these values! :wink: Regards, Pete

Yes. I would be an avid FSNav user myself if it were possible to move onto another PC, but it not only is not a separate program (it's an internal FS DLL just like FSUIPC), but it doesn't even use FSUIPC at all. I have the full version set up like that, and it works very well indeed. FSFK is a really good program, not just for its moving maps but its weather mapping, and especially its detailed logging functions. You don't really want a WideClient screen at all. I'm pretty sure the default INI I supply does that. Have you stretched it or maximised it? Best set the option to minimise it or even hide it. Well that's no use if you want to run it on the other PC! What's it doing there? You run FS9 on the main FS9 PC and client programs on the clients. That's the whole point. You'd not accomplish anything running it on the FS PC. It all worked fine here -- you have to have WideClient running on the client and FS9 with WideServer running on the FS PC, and I think there's some configuration you have to do in FlightKeeper to run it that way. It's all in the documentation. I just did what it said and it all worked. If you have questions on FSFK you are best off dealing with their support. I remember doing it and it seemed easy enough but I cannot remember it exactly now to tell you, and it's a bit pointless me quoting documents at you. Regards, Pete

Changing the throttle. Pete

The normal way is to set the visibility as part of the weather. This, for FS2004, is best done via the New Weather Interface. But then you set each weather station's weather in FS, so your program is a full weather-setting application. If you only want to change the visibility around the aircraft WITHOUT actually affecting the weather reports and so on, then 2DF0 is the only way. The reason for the time-out is to prevent the visibility being permanently stuck, should your program become disconnected or closed before restoring the location. If this happened and there were no corrective action in FSUIPC, the user would have to reload FS to fix it. Regards, Pete

Ah, yes. I see. quite right, and very good of you to look out for me! I should have thought of that. :wink: Ah, that's sounds good. But I am constantly also updating that document too, so when you are ready could you send me the relevant section and I'll merge the changes? Thanks! Regards, Pete

You do have it wrong. You are not thinking about the "per frame" part of the name. If this is set to 100, then FSUIPC attempts to get and update the positions of ALL aircraft on EVERY single FS frame (i.e. 20-60 times a second, whatever). And this IS ALL aircraft, so if there are 300 aircraft it would make at least that many calls into parts of FS to get just the positional data. Then it selects the nearest 96 and in-range airborne and 96 nearest and in-range ground aircraft, and then gets all the other bits of data with many further calls per aircraft. If it is set at 10, the default, it spreads all this work over 10 FS frames instead. In other words it only looks at 10% of the aircraft on each frame. Regards Pete

Actually I already do get the altitude. Internally it does occupy the DWORD following the Longitude, both for NAV1 and NAV2. In fact the NAV2 one is accessible now, just not documented -- check offset 083C. The only reason the NAV1 value isn't accessible is that I had no space where I mapped the other values, and really didn't think it was needed at the time. The place where it should be is 0888 but that's a location used since FS98 days for the 'active engine' flags. Shame really. Mind you, they only use the first byte (1st nybble really), so I suppose a reasonably accurate value could be stored there as a DWORD as well. Otherwise I'll need to map it elsewhere. Since in FS you don't get a DME with no VOR (else you couldn't tune it) wouldn't the DME Lat/Lon/Alt be the same as that of the associated VOR? Regards, Pete

No, because it is really a user configuration choice based on performance and traffic density. If your program is measuring the potential power of the PC and the expected traffic then I suppose you'd know how to adjust it, but this seems unlikely. What specific use do you have for such access? Regards Pete