Pete Dowson

If you've had anything changing the scenery library (SCENERY.CFG) or the traffic files, then, yes. No, of course not. They have nothing to do with scenery files. Why would you even think so? Sounds like either a corrupt or missing Traffic.BGL, or the Scenery library is no longer pointing to the folder containing it, or it is but its entry is disabled, or you've enabled multiplayer -- MP and AI traffic don't work together. Can't think of any other possible reasons. Pete

Metres, I assume? Okay. Let's see: a1:=306; FSUIPC_Write($0EA4, 2, @a1, dwResult); //lower cloud layer base a2:=762; FSUIPC_Write($0EA2, 2, @a2, dwResult); //lower cloud layer ceiling a3:=$FFFF; FSUIPC_Write($0EA6, 2, @a3, dwResult); //lower cloud layer coverage a4:=100; FSUIPC_Write($0EA8, 2, @a4, dwResult); //lower cloud layer variation a5:=9; FSUIPC_Write($0EFE, 2, @a5, dwResult); //lower cloud layer Type FSUIPC_Process(dwResult) Well, I don't know Delphi (is "dwResult" a pointer to where the result is placed? If so, why is the @ needed in front of the data variable names? Shouldn't it be @dwResult for the same reason?), but it looks okay except that you should really be writing to the weather SETTING area, 0F1C onwards, as documented. You are writing to the current weather reading area. However, FSUIPC should be converting those offsets for you -- but it may be misleading you, reading back there, Your values will go to the write area. Please check the Programmers Guide, look at what it says at 0E9A and 0F1C. The main thing that would help me (and you) would be to see the section of the FSUIPC Log showing what is happening. You *do* use the logging, don't you? Go to the Technical page and enable both weather and IPC write logging. Then we can both see exactly what happens. You use FSUIPC Writes with the command as offset and the parameters in their correct structure positions as parameters. What is the problem, exactly. In AWI the offsets are used as the commands, the data is still just data. FSUIPC interprets these upon receipt. Where is your misunderstanding? Shame, as with either you could use the FSUIPC Logging to see how it is done. In fact any program, right back to the earliest FS98 weather program (freeware) would show you, through logging. It was by putting logging in that I first worked out what all the offsets in FS98 were used for so I could write FSUIPC to be compatible in the first place. Regards, Pete

Which ones? I don't know of any that you should be able to write to that you can't. Please list them and tell me the problems. I cannot hope to help, or fix things if they are wrong, without more details. You should know that ActiveSky and Squawkbox both use the FS98-style weather offsets to set weather, FSMeteo and WidevieW use AWI. This is the deifference between memory mapped access and command + parameter procedural access. The AWI uses the "offset" field in the IPC interface as a command number, not as a memory offset. The data then becomes the parameters for that command. You have to get used to a completely different way of thinking. I know it is complicated, that is why not many people have used it, and also why I am changing back to a memory-mapped method in the NWI, for FS2004. If I were you, if you do not understand the AWI, I would stick to the old FS98 method until you get FS2004 and want to use the NWI. Yes, sorry. I never had time to do much about that, and the only people who were interested in the AWI (Marc Philibert for FSMeteo and Luciano Napolitano for WidevieW) figured it all out from what I published without any help from me, so nothing else was ever needed. It really should be easy enough for an experienced C programmer, but maybe too much otherwise. I won't have time to help with the AWI until after FS2004 release, and after I've completed the SDK updates, and by then I really think you'd be better using the new interface. Let me know why you think you can't use the FS98 interface and I'll try to help with that. Sorry to say it, but if you cannot manage to set/read weather with the old method you probably don't stand any chance with AWI. Ask me the questions, tell me the problems, please don't just say it doesn't work and give up. Regards, Pete

Can you be more specific? If you are intending to do weather programming for FS2004 then you wil be pleased to know I'm providing a New Weather Interface (NWI) for this version of FS, which is much easier to program and is much more powerful -- it includes facilities for setting and reading weather for any METAR station, not just being confined to the global default weather like the FS98 interface or the AWI. I can supply details of the NWI for you, now, if you like, in advance of the FSUIPC SDK update. Let me know. But the NWI will not be compatible with FS2002 or before. If you need to stick to something for FS2002 and before as well, then you have to either handle the old FS98-compatible weather offsets, or deal with the AWI. On the latter I can answer specific questions but cannot provide a tutorial, Sorry. This statement does does seem to relate to your first. The AWI is not variable or offset based, but it completely procedural, in the sense that it consists of commands and parameters. If you really do mean "offsets", which ones are you wanting to write which are "read only" and which "don't work"? Regards, Pete

... and you read these when they are incorrect, or what? It is easily possibly to get such a ground elevation. In fact in some parts of the world the elevation can get down to nearly -1500' (-457 metres). I think over the Oceans you will see small variations around 0. This is all due to the satellite data FS uses for its underlying mesh. Anyway, FSUIPC is not doing anything with that value, it is providing direct access to FS there. The value provided explicitly by FSUIPC is the one at 0B4C, but that's in metres not 1/256ths of a metre. There's no radar altitude provided by FS. You have to subtract the ground elevation (0020 or 0B4C) from the plane's altitude (0570). Pete

No it isn't. Only the muiltiplayer interface can do that. AI traffic are just one step up from the older dynamic aircraft, as exploited so well by Lago's original FSTraffic package. Yes, that is part of its function. Unfortunately you can't have both AI traffic and MP traffic in the sim together. Don't ask me why. At least, it was that way in FS2002 and I don't think it has changed. Maybe someone will prove me wrong? Let's hope so. Regards, Pete

No problem, it didn't come over as rude. Regards, Pete

That's quite unusual, but go on ... FSUIPC is not at all involved in loading or configuration of aircraft. If FS says there are missing gauges or things aren't working, then something's gone wrong with your installation or maybe the download is incomplete. Just because something says it needs FSUIPC does not mean that if it goes wrong it is automatically FSUIPC's fault. Those aircraft are VERY unlikely to need FSUIPC for very much, perhaps it is only a TCAS display. In all cases when you have problems with any add-ons it is the author of the add-on you need to talk to about it. I really am not all-knowing nor all-wise. I do not have all add-ons nor can I possibly test them all. Sorry. Good luck in sorting it out! Regards, Pete

You can use any spare axis you like. It's just that FSUIPC comes with the Mixture axis ready-configured for you to use as a reverser. You only need to read the ADVANCED user guide if you want to use a different Axis. Please refer just to the main User Guide. You should read the part that says: "However, in the case of the Jet Reverser, it is so useful that FSUIPC by default assigns the AXIS_MIXTURE_SET control to this—the standard mixture lever you would use on Prop and Turbojet aircraft. There is a checkbox on Page 7 so that you can have that lever operating as a reversing lever only when a Jet aircraft is in use. " Sojust check the checkbox. Pete P.S. The "numbers" of the FS controls are all listed in my Controls Documents, available on http://www.schiratti.com/dowson, but a few of the more useful ones in this context are also clearly listed in the Advanced Users guide, under the sub-heading "Valid Axis Controls" in bold.

There's no such thing as a slimmed interface. There's no double payments. The fees paid by developers are the same sort of thing as the purchase by them of other tools, such as compilers and debuggers. FSUIPC is just a tool, and there's a Software Development Kit (SDK) for the developers to help them develop their product. I put a lot of effort into all that, supporting developers, and that's what I'm asking them to contribute towards, at least those that make a profit out of it. Just don't bother to register FSUIPC if you don't want the extra benefits. What is fairer than that? Do you think it would be fairer to you for me to REMOVE support for applications in the fully registered product? What good would that do anyone? I think I've arrived at the fairest and most flexible solution to a difficult problem. Please try to understand what is going on here and not always read the worst into everything. Pete

I found a possible problem with timing. AutoSave accesses one of the PANELS routines, like a gauge, to get some deta relating to ground movements, and for some reason the recent code changes I made can, sometimes, cause a crash by accessing the panels routines in FS before the aircraft is fully loaded. Odd that I managed to get it to happen two out of three times on one PC here, but not at all on another. Sorry not to have spent enoiugh time regression testing it before I released it. I put it down to overload on FSUIPC for FS2004. Please find version 1.45 of AutoSave attached. I will release it to the other websites now. Regards, Pete AutoSave.zip

Hmmm. That's odd. Seems okay here. I'll look at it immediately. Thanks! Pete

The version of PFC.DLL released last week is FS2004 compatible. In fact, if you visit http://www.schiratti.com/dowson you will see that ALL of my modules have been re-released with FS2004 compatibility except for FSUIPC and WideFS, on which I am still working. The new PFC.DLL only needs a compatible version of FSUIPC to work on FS2004. I also posted the details of the latest versions at the top of this forum -- checked the one entitled Supported Versions, which was revised on the 8th July. Regards, Pete

Calibrate first in the Windows "game controllers", or with the driver that came with the joystick. FSUIPC isn't a replacement for that. The FSUIPC facilities are mainly a way of getting precise "dead zones" at centre or either end of the travel, and compensating for "off-centred" centres. It is difficult for me to help unless I know which specific steps in the manual you don't understand. If I could have explained it better than I did, I would have done, if you see what I mean! Anyway, you can't do any harm -- if you get into a mess just reset the FSUIPC calibration so it will be ignored, and start again. Have a go, just following the steps one by one, then come back with specific questions. Okay? Regards, Pete

Yes, it would be a start, but it isn't satisfactory. The earlier edition (pre 1.3) of 767PIC had only a keyboard interface, and programming the PFC (or other) rotaries to increment and decrement the A/P values reliably was precarious to say the least. I suppose that a separate control for each decimal digit would do the trick, though even then it is so easy to get an overrun if there's the slightest hesitation in the acceptance of the keypresses. 767PIC is notoriously bad with keyboard only. Regards, Pete

If you have a spare axis you can set it as reverse in FSUIPC. This facility is described in the documentation. Go to the FSUIPC options in FS (ALT M F) and check the last page (7 of 7) of the Joysticks tab. By default the reverser is assigned to the axis configured in FS as the Mixture control, but you can change this -- by editing FSUIPC.INI before loading FS. This alteration is described in the Advanced User Guide. Regards, Pete

Versions that haven't been released, only sent on request. I don't support them, but you can try them. The VXD had to be changed so that it would install on a PC with no EPIC card. EPICLINK was changed to send analogues as well as buttons, Qproc events and pigeon holes. Write to me on petedowson@btconnect.com and I'll send you what I have. Regards, Pete

You can use your existing FSUIPC.INI file. No problem. But if you are using some of the extra facilities, like the joystick calibrations and button programming, then you need to Register your copy. Full details will be announced here next week. Regards, Pete

Why use ActiveSky to get weather information? There's FS's own ATIS, and there's also my own WeatherSet, part of the FSUIPC package, which will report the weather at the aircraft. Isn't it ActiveSky, if you are using it, which is supplying the weather to FS, the very weather you want reporting? I don't understand what you want to use it for if it isn't supplying the weather? Maybe these questions are better directed to the ActiveSky folks? After all, they may know more about it than someone who doesn't even use it? Sorry I can't be of much help here. Good luck! Pete

Sounds like a video driver issue to me. Have you asked in the ActiveSky support forum (is there one?), see if others have similar problems with, perhaps, similar hardware? I think the first thing to try is updated or different drivers. I can't think of anything else that could screw around with stuff like hardware acceleration settings. Pete

Each SLOT is 40 bytes. So if you read 40 bytes at F080 you get all the data in Slot 1, in the format defined. There are 96 such slots, the next one starting at F0A8 (40 bytes ater the start of the first one). In fact these size and count values can be read (size is at F000, the number of slots is at F002, as documented). However, they are likely to remain fixed, at least for another two years, so can be assumed unless you are really worried about long term compatibility. You *can* read the whole set of 96 slots in one go, by reading 96 x 40 bytes at F080. This is actually what my TrafficLook does. Providing you don't do that too frequently this is fine. However, there is a 96-byte array of single byte counters at F008 which tells you which slots are changed, so if you wanted to be more efficient you could read only the slots which have changed. This is more programming work, but less data transferred. For a TCAS scan rate of say once or twice per second it probably doesn't matter. All this information is there. If it was in the same form as the simple data it would say "TCAS data: F000, 4096 bytes" because the whole block of 4096 bytes (F000-FFFF) is reserved for the Airborne traffic data. In fact, if you look in the main table it IS there, in exactly that form! However, specifying the data for up to 96 aircraft like that wouldn't help much, now would it? How would you decode the 4096 bytes without the additional data I give in the earlier parts of the document? Please explain what it is you don't understand. I find it rather difficult to be more explicit, everything is defined quite precisely already. Regards, Pete

Well, there must be plenty of VB programmers around. I expect one or two here would be able to help if they see your message. I'm having some trouble understanding your question. In the Programmers Guide I provide a structure. Admittedly it is defined for C use. Can't it be converted to VB? Doesn't VB support any types of structure? If not, all you need to know is that each 40 byte slot, starting with slot 0 at F080, contains: Bytes 0-3: ID number as a 32-bit number (0 = slot not used) Bytes 4-7: Latitude as a 32-bit floating point number Bytes 8-11: Longitude as a 32-bit floating point number Bytes 12-15: Altitude in feet as a 32-bit floating point number Bytes 16-17: Heading as a 16 bit number in regular FS format Bytes 18-19: Ground speed as a 16-bit number Bytes 20-21: Vertical speed as a 16 bit number Bytes 22-37: A zero-terminated ASCII character identity Bytes 38-39: The COM1 frequency tuned in, in BCD (see Guide) In the next version of FSUIPC, when it is used with FS2004, the string at 22-27 will be shortened by one byte and byte 37 will contain a status byte telling you what stage the AI aircraft has reached (taxi, takeoff, etc). Hope this is clear. Regards, Pete

I have heard about this before and I think it is known to the PM folks, to whom you need to address your inquiry. It is not a function of my software. Please check with PM support. Regards, Pete

Okay, it is easy enough. I'll send a Beta WideClient when I get a chance to put it in. Please write to me on petedowson@btconnect.com with the request so I can be reminded and return the result as an attachment. Only that existing applications couldn't connect to a WideClient with modified class names. But obviously you can have one copy of WideClient with standard names as well as the others which can only be accessed by your modified interface applications. Yes, it is only checking against a conflict with the class names. Regards, Pete

I've never heard of that. Are you observing any incorrect Lat/Lon values being read? If your program is reading bad values you should surely be able to detect them? Maybe there are occasions when FS (or your PC) is doing something whch causes the call to FSUIPC to time out and return an error. If you are not detecting this and taking action to avoid the non-data return, then possibly you are reading (0, 0) as a valid location. No doubt that would be many thousands of miles off course! Pete