Pete Dowson

Hi again, Just reviewing this thread, I see I already replied to you before and I actually already gave you explicit offsets within each slot, so even if you didn't understand the C format structure you should still have worked out your error. In case you missed it, here's the relevant part again: Now do you see how, if the first byte above is at offset F080 (i.e the first slot), the Latitude cannot possible be at F080 or F082? You see it says the Latitude is at bytes 4-7? F080 + 4 = F084. Not F080 nor F082! Both those offsets are part of the ID because they lie in the range F080-F083 as occupied by the ID, which is in the first 4 bytes of each 40 byte slot. Okay? What is not clear about this? I really am running out of ways to make this as simple as possible. Regards, Pete

Hmmm. Unfortunately, FSInterrogate is missing the numeric format used for much of the data in the AI Traffic tables -- the 32 bit floating point values, type "float". It does have a "double" floating point format which is 64 bits, but I couldn't use up that much space for each aircraft or there'd only be room for half the number. Pelle was working on an update to FSInterrogate, but I fear work commitments have got in the way. Certainly that is possible -- the ID is a mere 32-bit unsigned integer ("DWORD"). Hwever, this is the ID only of the first slot, not necessarily populated by an aircraft. There are 96 such slots, the next starting another 40 bytes further up, at F0A8. Since the offset F080 is pointing to the 32 bit (= 4 bytes) of the ID, the whole of the offsets from F080 to F083 inclusive are occupied by that ID. A DWORD is 32 bits = 4 bytes = 4 address values. See? There is no possibility of the same 32 bits being simultaneously used for two different values. Things can't work that way, it is not possible. So neither F080 nor F082 will ever contain the Latitude. As shown by the structure, the Latitude is a float and follows the Id, so will be 4 bytes further on, at F084 (assuming that slot is actually populated). PLEASE PLEASE see the Documentation I provide in the SDK. Surely the structure shown there, albeit in C format, is perfectly clear? The structure shows a number of values occupying fixed positions inside each 40 byte slot. The 40 bytes is made up of 4 for the ID, 4 for each "float" value, 2 for each word, and so on. The types are standard C or Windows types and the structure can be used exactly as provided there to define those positions and types in a C or C++ Windows program. Just cut and paste. I'm sure conversion to whatever language you wish to use shouldn't be so hard. What is really the problem? You are talking rather as if you are new to computers. If so, then I'm afraid I am the wrong person to try to teach you. If not, then I'm sorry for continuing to misunderstand you. Regards, Pete

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