Pete Dowson

You can run as many copies of WideClient, one on each Client PC, as you like. The licensing covers the use of WideServer, the part which goes into the FS installation. Regards, Pete

Sorry, I really have no idea what these are, let alone where to find them inside FS. It has taken me many months to find enough things to allow FSUIPC to provide as much compatibility as it does, and I probably haven't covered all of the listed values yet in any case. When I get time, in a few weeks maybe, I'll perhaps start looking for new data on request, but you'll have to help me. I'd need to know exactly what this is and how to use it. Please ask me again in September. Meanwhile, if all you want to do is control this from outside FS, use the control values which those equate to and send them through the FS controls facility at offset 3110. Regards, Pete

Yes. But you have to use WideFS -- usually you would then also run the FS appplication (e.g. Squawkbox) on that other PC too. Under WideFS you assign KeySends to "RWon" and "RWoff" (in the wideclient.ini file on the RW PC), and then program your buttons in FSUIPC ot use the KeySend controls, not the RW controls. There's stuff about this in the FSUIPC Advanced User's Guide as well as in the WideFS documentation. Regards, Pete

Sorry, I never actually produced random wind (perhaps you mean turbulence?), and, for the time being, at least, I've not implemented the random rain or storm functions. I have a strong feeling that most of my weather features will not get used very much when folks get to experience the FS2004 weather engine. It is far better than anything before, and I don't think I can do much to improve it. As in previous releases, I can really only influence "global" weather, and really you wouldn't particularly want to use FS2004 with a single global weather setting, the local differences are far too attractive now. If feedback indicates that people would still prefer FS2002/FS2000-like weather effects, albeit with better graphics, I'll consider adding some of the facilities back, but I would be very surprised. I actually felt a bit daft putting in the facilities for global weather which I have done. Regards, Pete

Rightyes, that test hot key was enabled in that. Sorry if it confused you, but there's no harm done. Just delete those files, and go into the FSUIPC Hot Keys page and reset the assignment for the bottom left entry (which probably says "reserved"). In the Betas for version 3.00 I used the same system to produce binary dump files for other things, not aircraft specific data, but your message has reminded me to remove this before I issue it, this time! :) Thanks, Pete

I thought UK release date was at least another week off. Normal release dates here are Fridays, so I'm guessing 1st August at the earliest. Do you know different? Pete

No, FS2004 gauges are part of FS2004, just like FS2002 ones are part of FS2002. They are not separate applications, they cannot run on a separate PC using WideFS. They don't interface to FS through the FSUIPC interface even if they were separate programs. Nothing in FS2004 is dependent on FSUIPC. If you have an existing program which runs okay on WideFS with FS2002 then it will with WideFS version 6 once you have registered WideFS so it works. The only doubt I have is on the database front. I think FlightMax generates its database from scanning FS AFD files. These are not the same in FS2004. You might have to make do with FS2002 data. Regards, Pete

I think that means the the value the FS tells you about the position may not always be the value you tell it. I think it can depend on something else, maybe something in the AIR file. I don't know. I'd have to take a specific aircraft and see what outputs I got for different imputs. I remember seeing one case (long ago -- when I added that comment, whenever that was) where the output was about twice as high as the input. Why? I've no idea. Maybe it was a mismatch, an FS98 aircraft in FS2002 or something. Sorry. The note I put in there was merely a warning, a result of such an observation. Writing to one will cause FSUIPC to actually send the appropriate control to FS. Writing to the other will do nothing at all. That sounds eminently reasonable. No, I don't think so. I hope they do always match. I have just seen occasions when they don't. Ignore my warning notes if you like. They may mean nothing with modern well-behaved aircraft. Regards, Pete

As it says in the announcement at the top of this forum. I am on-time still to meet the release date I promised, or a bit early in fact -- expect to see it at the usual places this weekend. Regards Pete

Please check the announcement at the top of this forum. Thanks, Pete

On your own system, using a private program? It depends on the version of FSUIPC you are using. More and more of the "unused" areas are being used. 8000-810D are used in FSUIPC 3, as are areas above C000. The areas below 8000 are fast being allocated for specific applications, and I'll be starting to allocate above 810D in a few months I expect. In some versions of FSUIPC I used areas 9000-BFFF for exploring other data parts of FS, as a sort of Window, and though I usually turned that off before release, I didn't always. So, if you are designing something for others to use, I'd say not. If it is for your own private use and you can control whatever else you run, then 810C - BFFF could be used at a pinch. But WideFS/IPC is not an efficient way of transferring large lumps of data. I would have thought you'd be better off making your own arrangements outside of FSUIPC. You could write a file, for instance, and simply pass the notification and location via FSUIPC. Or you can use pipes, or your own Ethernet links. Regards, Pete

Well, I didn't know about if before now. It is a tiny bug in the tables. You just reported it in time for me to fix it in Version 3.00, due out this weekend. Thank you! Regards, Pete

Okay, good. It was maybe worth all this hasle in the end, then? Regards, Pete

Some good news for you. I experimented a bit with the function I am already calling in FS to display messages, and I found a way to get white-on-green rather than red-on-green, but only for static (non-scrolling) messages. I'll make this an option in FSUIPC's Technical page. I cannot make it programmable at present -- too close to release to make drastic changes. I've had to modify AdvDisplay.DLL as well, in case it is installed. FSUIPC sends things direct to FS if AdvDisplay isn't installed, but else they are routed through it. These facilities will be in FSUIPC 3.00 and AdvDisplay 2.11. Regards, Pete

Very likely you can, and I was trying very hard not to sound like I was talking to a complete beginner, but it was very difficult. After all I had already given you all the information. Even the original documentation in the SDK does have an explicit structure. The TCAS facilities were originally publish nearly two years ago and I've not had to go to anything like these lengths before to explain them. The SDK is actually aimed at programmers so does make assumptions about basic knowledge. If it was the structure business you didn't understand you would have asked, surely? Then the fact that you thought that two different 32 bit values could occupy the same or overlapping offsets seemed very strange and I though must indicate some very basic misunderstandings of how computers work. Maybe there were other reasons for this, and if so I'm sorry to have made incorrect assumptions. Pete

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