Pete Dowson

No, I don't think any of them are pressure altitude -- that isn't the same as AMSL which is the true altitude above sea level. Pressure altitudes vary according to pressure and are used in aircraft performance calculations and conversions between TAS and Mach, things like that. The ground altitude is provided in two places -- 0020 and more accurately at 0B4C. the aircraft's altitude is given at 0570. Both of these are AMSL and have no dependency whatsoever on any altimeter setting or pressure variations. Calculating the aircraft altitude AGL is simply a matter of subtracting one from the other, which is what all currently implemented radar altitude gauges do. FSUIPC also calculates the altimeter reading based on the difference between its pressure setting and the QNH. This is at 3324, and is provided only to save those programming altimeters the slightly more complex calculations. Regards, Pete

How would you use it -- like FS2002 acting as a moving map? Do you have FS running in a LapTop when flying for real, that sort of thing? I must admit I'm a bit at a loss to see the real use of this. Can you explain? I know using a real moving map, like Jeppesen FliteMap, with a GPS can be very useful, but what would you be expecting FS to do with the GPS positional outputs? Regards, Pete

No. I wouldn't know how to influence any of that -- most over- or under-sensitive behaviour comes about through the aircraft design parameters (in the AIR file and CFG file). Designing aircraft correctly, or writing proper autopilots, are not in my area of knowledge nor really something that I would think belongs in FSUIPC. However, all the facilities for writing your own autopilot through FSUIPC's interface to FS are available. Programs like Project Magenta provide external autopilots which work very well for specific classes of aircraft, provided they are set up with the correct parameters. Isn't that where they are, already - in the AIR file or, increasingly, in the AIRCRAFT.CFG file? Or am I misunderstanding your suggestion? If you aren't a programmer or an aircraft designer but want to see a good autopilot designed for a particular aircraft, I think you might need to spread your request to a wider audience. There may be some readers here who can do this sort of thing, but it really isn't likely to be the best place. Regards, Pete

I don't know this device -- unless you mean the throttle console, which has a 6-lever base station onto which you can affix the throttle units of your choice. If it is the latter then the connection to the PC is not analogue, but via the COM port (or possibly USB via an adapter). The Elite versions use Elite protocols, but may be switchable to PFC protocol (supported by my PFC driver in FS) -- if so, then the switch is inside the unit, accessible when you remove the throttle unit by undoing the two bolts. If this isn't the device you have, and doesn't connect via a COM port or standard Game Port already, then it is likely that it is purely designed for the Elite and nothing else. Have you checked with PFC themselves? Regards, Pete

Hmmm .. weird. But it still must be down to the way the 767 software works. If my suggestions above have no effect then I've really no idea. I don't suppose the 767PIC authors are fixing things any more. Regards, Pete

Thanks Dave, I don't mind the thread continuing whilst there are still misunderstandings, as I'd rather things were clear, and it also helps me make sure that my wording of the formal detailed announcement of prices, methods and so forth, when I get to it, is unambiguous. Anyway, if I locked that thread folks would start another and maybe not even read what has already been explained, which could be worse! Thanks again, Pete

Go to http://www.schiratti.com/dowson and download the FSUIPC SDK. It will show you how to extract whatever information you like, in any of several languages -- C/C++, Visual Basic, Delphi, and variations. Java soon. Regards, Pete

Hi Robert, I'm away Monday throgh to Friday next week, inclusive, so please forgive a lack of response on my part. Pete

LOL! Something like thatsome of the actions have got to be defined properly yet, though. I'm away most of next week so I'm now aiming to sort it all out and publish it more exactly in the first week in July. Best regards, Pete

I've examined the actual corrupted part of WideServer's linkage a little closer, and it appears to have been overwritten by something with the text "&Wea" in it. Of the added DLLs you have, this seems to point to one of the weather-ralated ones, viz: WCFSM.dll or WeatherCenterDisplay.dll I've not seen the latter, but I have just found a copy of "WCFSM.dll", and that certainly contains the text: "&Weather Center" so now I'm wondering what it does with it. Maybe it is the FS title bar text? WideServer currently allows for up to 127 characters in the title bar excluding what it might add. Maybe you have something making it longer? What do you normally see in the FS title bar? (You'll need to switch to windowed mode to see it). Have you actually changed anything or installed anything which would make the text there longer? What options do you have set in the WideServer.ini file (send it or show it here if you like). If this seems to be the cause of the problem, then I can send you a modified WideServer with the title text length allowed to grow much larger, to see if that helps. If it is the problem and it is in WideServer, it is mighty strange that it has never happened before. That limit has been there since WideFS began, some 6 or more years ago! Of course, it may be WideServer's modification of the title bar, so the text is longer, which causes the Weather module to corrupt the memory. I wouldn't be able to fix that -- you'd need to write to the author. However, one option you can try is stopping WideServer modifying the title bar at all -- the following documented option can be used for that (set it to No): ==================== TitleBarUpdate=Yes: Set this to ‘No’ if you don’t want any sign that WideServer is running. Sometimes other programs and add-ons can be affected by the changes that WideServer makes to the Flight Simulator title bar. With this set to ‘No’ these add-ons may run correctly. ==================== Let me know. Regards, Pete

Thanks. That log was most useful. The normal module linking to FSUIPC, performed by FS when loading the various modules, is corrupted. It contains some ASCII character rubbish by the look of it! How that could happen I have no idea, but my suspicion falls on one or other of the many other add-in modules you seem to have installed. These are the add-ins you have, most of which I know are okay: APS.DLL (for 767PIC perhaps?) ViMaCore.dll (Lago stuff) wideviewlt.dll (WidevieW) AutoSave.dll (mine) FSNAT.dll (is this for Lago scenery perhaps?) A22V1_System.dll (?) WCFSM.dll (a weather DLL of some sort?) WeatherCenterDisplay.dll (ditto) FSUIPC.dll (needed for WideFS in any case) WideServer.dll (of course) FSNav2002.dll (FSNav) FSSound.dll Quite honestly I've never seen so many add-in DLLs in one installation! Now I'm not saying any of them are no good, but I'm a little concerned as to how data which WideServer needs and which is really outside of its control (the FS linkage) is betting trampled on. Could you try this experiment. First, take ALL the above DLLs out of Modules except for FSUIPC and WideServer. Does it run now? If not, supply me the DrWatson and I'll think again. If it does run, add the modules back in one at a time till it doesn't run again. Which module was it? Just to be sure, then remove all modules again EXCEPT FSUIPC and WideServer, and the tentative culprit. Does it still not run? If so then that's a rogue module. Let me know which one it is (I may need a copy to check it here). Note that just doing all this may well appear to cure the problem in any case -- the order of the Modules in the folder will get changed, so FS will load them differently, and different areas of memory will be used so different things wil get corrupted. There's not really a lot we can do about that. On XP I've not found a way of keeping folder orders EXCEPT by literally moving everything out so it is empty, then moving them back in, one at a time, in the order you want them. The trouble is I don't know of a utility which will actually tell you the order they are in to start with! On Win98 the DOS "dir" command would do it if you didn't specify sorting, but the XP version seems to always sort. Let me know. Thanks, Pete

Hmm. I'll take a look myself. Maybe it is only by implication. If you found the question and answer sequence above useful, maybe I'll add it as it stands into the DOC (without your name of course! ). Regards, Pete

Sorry, I''ve no idea. Something has evidently changed. Do you know what you might have changed? When you say "latest version", could you elaboarate, please. Do you mean the latest versions as detailed in the Versions list at the top of this forum? You should really quote version numbers, just in case. The "latest version" to many folks actually means "the latest version I've seen" which in some cases has been mighty old! Can you also be more explicit about what actually happens when it crashes. What does it actually say, apart from "pointing to WideServer.dll". There are usually ways of getting rather more data than that. Are you using Windows 98 or Me or XP? Can you get a DrWatson log, in the manner explained in the FSUIPC User Guide under "If FS crashes ..."? In the end the best way to proceed is to try to work out what might have changed, between when you had it working and when it stopped. Could the Network software, or drivers have become corrupted? Is the network working well on its own, outside of WideFS? Maybe if you deleted the Network card from the Device Manager and reinstalled it along with its driver it might resolve the problem? This might seem like clutching at straws, but you need to consider every possibility. I've not changed anything on your system, the currently released WideServer is being used by many without problems, so it is something odd there somewhere. Maybe it's the WideServer DLL itself which has become corrupted? Try reinstalling it from the ZIP. Pete

I don't think so. FS simulates flight. It is recalculating all those things on each frame and updating them. Those really are *output* values from the simulator. It isn't actually designed to let you set up a dynamic situation from which is can then continue computing. It has hundreds, maybe thousands, of values to compute and derive the next situation from. All sorts of accelerations, motions, drag, resistance, thrust and so on come into it. Please see the different velocities and accelerations at offsets 3060-30B8 and 3178-31D0. You might be able to write to those and achieve something, if you know what you are doing, but even there I'm not sure which are causes and which are derived effects. I suspect they are all both, at one time or another during the simulation process. Slew mode is different. Slew mode says go here, go there, move this way, move that way. There's no aerodynamics to compute, nothing to simulate about flight at all. The only other possible ways apart from slew mode are Pause mode (which stops the simulation so your values don't get overwritten), and "frozen" mode, where you tell the simulator to proceed at 0 frames per second (zero in offset 0C1A). You could try one or other of those, but I doubt they'd give much benefit over slew mode really. They are all effectively preventing the simulation process doing its job of simulating flight. They are results, derived from simulation. You can't set them. They don't mean so much in slew mode, but you can control the speed and slew directions et cetera in locations 05E4-0%EE instead. Regards, Pete

Not sure how WideFS would come into it. Yes. What do you mean by "value of max/avg reception"? I don't understand. WideServer sends out updates for requested data as it changes, normally at a maximum this would be at FS frame rates. The signals should travel along the wires pretty instantaneously. Block sizes will vary, usually quite small, but up to the maximum it allows, but at a typical Ethernet speed of 100Mbps, even a large block or some 4kbytes is only taking something like a half a millisecond to send/receive. As it tells you, the number 10053 means "Software caused connection abort", at least that's the text from Winsock. Looking it up there's a further expansion "An established connection was aborted by the software in your host machine." So, where's the host machine log? Only it can tell you why it disconnected. After this you immediately got: [Error=10061] Connection refused, so whatever it was it didn't come back. Regards, Pete

I don't know. I ask that myself quite often. I think it was because I started doing it -- for myself really. I gave it away afterwards, and that was the real original mistake it seems. I'm being told by many that I should have sold it from the outset! What if something happens to you ? Ok, I guess some guy can have the source code. But having the code and understanding the code are 2 different things. Quite true. Sometimes even I don't understand it. I really must put one or two comments in sometime -- but there's always something more important to do! Best Regards, Pete

Thanks Chris! Yes, you understand it very well! I'm glad at least one person does. I was beginning to think I'd lost all my powers of explanation, having said the same thing over and over -- or so I thought! :-) It more folks seem to understand your wording than mine, can I pinch yours please? ;-) Best regards, Pete

Well, it'll work with yours too . You don't actually have to buy your own full copy of FSUIPC if you don't want all the facilities. But it will be cheap in any case, probably with a special offer for a time. I think you should find it worth it. The price will be firmed and published in a couple of weeks. I'm nearly there, but I'm out for a few days next week. I hope to be able to publish everything within the first two weeks of July. Regards, Pete

This is only with the PIC767? If so then I think the most likely cause is the PIC 767 software clobbering the message queue -- it has a nasty habit of getting into some weird state where is is sending many Windows messages continuously, every second. This fills up message queues and causes other problems. I don't know *why* it does this, and it doesn't do it all the time. It's very inefficient in this way. All FSUIPC is doing with your pre-programmed buttons is sending the related keypress, as a message (or a sequence of messages -- keydowns and keyups, as needed). It does this as soon as it sees the button press. Alternatively, or, indeed, as well, given this statement: It is possible that the system is rather overloaded and the detection of the buttons being pressed is lagging, or even being missed. The button actually has to be held down during one of the scans for the change up-down or down-up to be noticed. The joystick drivers don't actually queue these things. I can only think of a couple of things you could try: 1. Limit the FS frame rate at something below your normally observed rate, so that FS itself spares more time for other things. For instance, on a 2GHz PC I would suggest something like 25fps or 20fps. Lower on lesser PCs, not much higher on faster ones. Experiment with that. It's in the FS Options-Settings-Display-Hardware dialogue. 2. Try making FSUIPC poll the buttons more frequently. This is done by a parameter "PollInterval" in the [buttons] section of FSUIPC.INI. the default is 55 mSecs which gives about 18 tests per second. Read the section "Button Programming" in the Advanced Users Guide. I'm not saying either of these will "fix" the problem, but they're the only things I can think of which stand a chance, short of getting the 767PIC software problems fixed. Regards, Pete

If this is addressed to me, please state your problem here. I do not have time to go chasing threads is other fora. Thank you. Pete Dowson

You need to refer to the Programmer's Guide. In the table in that document it explains this as "Autopilot altitude value, as metres*65536". In other words, that 32-bit integer holds the altitude in metres times 65536. Since 65536 is, in hexadecimal, 0x10000, this is effectively saying that the top 16 bits is the whole number of metres and the bottom 16 bits is the fractional part in 1/65536ths of a metre. If you want feet you simply convert metres to feet by multiplying by 3.28084. Please try the supplied utility FSINterrogate. You can read the values in that AND see the conversion in operation. Pete

Hold it there. 1. If your aircraft accesses FSUIPC, then, yes, you need FSUIPC installed. Not many add-on aircraft access FSUIPC, but it is feasible. 2. If you access FSUIPC then, effective from FSUIPC version 3, you need an access key (unless the user has bought a full license for his FSUIPC). This is true for any version of Flight Sim, not specifically FS2004. You will see in my announcement that I invite all developers to apply for full details of the registration scheme so they can be prepared. 3. If your plane is freeware -- i.e. you are not making money from it -- then the Acess key you need is provided free. No one pays anyone anything. Surely this is clear for everything I've said? Why are you not reading any of it? It makes no sense to me either, especially as, right from the very start, I've made it clear that this wouldn't be the case. Please go back and read what I actually said. Maybe so. And I'll will go get a different job. But whilst I am full time on this I need some income. Okay? :-( Pete

Oh, didn't I answer that one? Sorry. Taking the last point first, no one ever has to pay for FSUIPC more than once. If he buys the full license for FSUIPC then not only does he have access to all of its facilities, but it will work with all add-ons, whether accredited or not. He doesn't need to pay anything at all if he has no need for the extra facilities and all his add-ons are "accredited". As for vendors "passing on additional costs", I don't think this is a defensible position. To start with there are no software products I know whose price is based on costs. It is impossible to work out such pricing. Software prices are based on estimates of market worth -- i.e. "how much are folks likely to pay?", "what is the optimum price for this to give maximum returns?". Often a lower price will secure better returns, but it's all a guessing game in the end, with experience and knowledge of the market place as guidance. Adding in the relatively miniscule amounts vendors or developers will be paying me will make not the blindest bit of difference to this, I assure you. Regards, Pete

Is there no "Modules" entry in the FS menu? I mean here the main menu at the top of the screen when you are actually in FS flight modes, not when you are waiting at the flight selection dialogue. If there is no "modules" menu, then you have put FSUIPC.DLL into the wrong place. There's no need to "access" it if all you installed it for was to run add-ons. But if you want to look at its options dialogues then you select FSUIPC in the Modules menu, as documented in the User Guide. Regards, Pete

I have to allow vendors to package FSUIPC, as there will be many folks who (a) don't know what it is and don't care, and (b) have no access to the Internet or don't want to bother anyway. I keep asking vendors to make sure their installation programs do NOT overwrite a later version if one is found already installed. Most do incorporate this check, and I write to those who don't and complain. But this is the most I can really do. Note that there is no conflict regarding the *access* rights to fSUIPC these differing installs might have. Their access is through a key, which is operated at the time of the access. There is nothing different about the module itself. And if the user has purchased FSUIPC for the additional facilities, these are parts of his installation. He will want to preserve the Key file, or at least the information he entered when registering, but this should not be affected by vendor installs. Hope this makes it clear. Regards, Pete