Pete Dowson

And what is the latest version, please? Different people say different things in answer to that question. It is ALWAYS best to actually give version numbers. Neither of these really sound anything remotely connected to FSUIPC's actions. What makes you think they are? I'm sorry, I don't know FlightMax, but the first bug sounds very definitely like a code bug in the program itself. You need to report that to the author or support forum. You could also check whether it is a corrupted download you have there. The other bug sounds like a deficiency in that version of the program. Sorry, but I cannot really help at all with other programs, only those that I write and support myself. Not all the problems in the FS world are due to FSUIPC, honest! Regards, Pete

It's test data produced when you press a special hotkey which is unlabelled in FS's hotKey options page, but nevertheless functions in certain versions. Seems like you have that hot key assigned for some reason, AND you are using it? Just go to FSUIPC's HotKeys page and clear the bottom left HotKey assignment. In FSUIPC.INI it'll be the parameter "TestHotKey". What version of FSUIPC are you using, please? Pete

That's okay if you are programming a gauge. All the code in FS does when you call that is subtract the ground altitude from the aircraft altitude and return the difference. It isn't worth me having FSUIPC do this all the time just on the off-chance someone might want to read it, and I cannot simply do it when it is read because WideServer needs to be able to send changes out to clients as and when they occur, not when they are read (the reads on clients are 100% local). So, it is much more efficient for applications to use the data which is actually maintained and do their own subtraction. After all, it is not all that complicated, now is it? Regards, Pete

Maurizio, Lago's expert on FS innards, is actually much more of an expert than me on many aspects of FS -- remember FSAssist? FSTraffic? Stuff I can only guess at. He would probably know how to do all this display stuff, but I fear it is Lago proprietary information, and he wouldn't be allowed to share it. I just had a quick look at ABLSCPT.DLL and it looks like all the display stuff it uses is wrapped up in C++ classes and Heirarchies and Virtual Functions and all that sort of dreadful stuff which confuses me greatly (I'm an out-and-out procedural, bottom-up, programmer, ingrained on me for 40 years! ). So it could be a big job. I did solve a few of these sorts of indirect methods in order to get aircraft data in and out of SIM1, and weather in and out of WEATHER.DLL, but it was that which really cost me the last 5 months of 100 hour weeks! BTW in FS2004 those lessons come out white on grey, not on green. I didn't try FS2002 (no use looking backwards if I can't solve it for new versions). Regards, Pete

Well, I had a look, as promised. Unfortunately that display isn't using the same routines, which means in order to use it I would have to disassemble and trace further into the DLLs involved. So, whilst I'll leave it on my list to look at for a later version, I cannot actually promise to be able to do it. Regards, Pete

Okay. I'll take a look. But if it is using a different mechanism in FS it may not be something I can do quickly. Yes, it probably will be a version 3 update, as I effectively froze version 3 yesterday to give me time to do the docs, which I'll start tomorrow. However, if it is dead easy, which I may find out later today, I may just slip it in anyway . Regards, Pete

Well, you could always use AdvDisplay and have it any way and shape you like, of course, and even ShowText to do even more. That package is free and available on the Schiratti site, and, I think, allows far more realistic use of the text data. As for "ABL" displays, I must admit to never seeing any. If they use the same facilities in FS as those I am already tapping, then it should be easy to provide such an option. Do you have a test which provides an ABL display, or tell me how to make one appear? I'm afraid ABL is not something I've ever had time to look into. Regards, Pete

I don't know if any of those things can be changed without loading an amended AIR file and AIRCRAFT.CFG. Since any small change in them is likely to have an effect on many other flight parameters, I should imagine a complete new model calculation would need doing afterwards -- the sort of thing only performed when the aircraft is loaded. You can change the fuel on board of course, which will affect takeoff and total fuel weight. CofG could be changed if you have forward and aft fuel tanks, as in the Concorde, but the placement of fuel tanks in in the AIR or MDL files, or AIRCRAFT.CFG again. Pete

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