Pete Dowson

Good. None of the entries in the Joystick Button programming section are generated by default. Anyway, the PollInterval thing is a bit technical and has the potential for wrecking FS performance if taken to extremes -- I didn't really want folks playing with it without good reason. To be honest, I never thought that some bug in some panel programming would make a change in this parameter necessary. It was really aimed at EPIC users who have to be pretty technically minded in any case! Regards, Pete

Ah .. the "default" actions are those which occur if there's no parameter to tell it otherwise. Possibly the parameter was left in from a previous version, when IPX/SPX was defaulted? WideFS doesn't generate an INI file, unlike FSUIPC. Or possibly the initial default INI files I supply in the ZIP have this parameter? They shouldn't -- I'll have to check that! Thanks! Pete

This just means exactly what it says. Your TONY PC does not know another PC in the same setup with the name Aston. Why, or how you fix it, I'm afraid I don't really know. Does the Aston PC show up in the Windows Explorer window (probably under "My Network Places" somewhere)? If not, then that's the first step -- get both PCs seeing each other properly. For IPX/SPX under NT, Win2000 or WinXP each Client needs the ServerNode explicitly provided (see the WideFS document) -- it seems only in the Win98/Me operating systems is Windows clever enough to find a server connection automatically when using this simple protocol. Regards, Pete

At present Heathrow local time IS +1 hour from UTC! I think you are confusing the terms slightly? GMT is the old name for the time now called UTC. i.e. UTC = GMT. But in the UK in Summer we use BST (British Summer Time) which is UTC+1. This is what FS is calling, correctly, "local time". Regards, Pete

Have you asked the FS Real Time author? I think when you install this program there are replacement BGLs installed which are supposed to correct time zone problems already in FS. It sounds like those BGLs got corrupted or something, but I'm sorry, I don't know which ones they are. Pete

I can implement automatic selection of some parameters based on something like the aircraft name, but I think it would still be better to keep them central, in the FSUIPC.INI, possibly with sections named after the aircraft. Folks do chop and change aircraft and exchange them, so parameters relating to one person's control kit could get imposed on another's, which could cause problems. Another consideration is that, although, in FS2002, I can actually derive the correct AIRCRAFT.CFG file path, this currently isn't the case for FS2004 and may not always be feasible in any case. All this will have to wait until I'm in a position to start thinking about new facilities in any case, and would probably go hand in hand with proper axis selection and assignment facilities (instead of relying on the FS CFG file as at present). We'll see. Maybe you'll want to remind me in a few months? Regards, Pete

There are NO password protected zipped versions of any of my modules, at least none supplied by me. I do not make a program called "FSWide", but if you really mean WideFS, then the current version of WideFS is still free and most certainly not password protected. There is no way to pay for anything until the new versions are released, probably at the end of July, and then this will be by access keys not ZIP password protection. If you are having problems getting a good download you need to contact the support for the web site you are using. Pete

This has ALWAYS meant simply that the protocol specified (IPX/SPX or TCP/IP) is not installed. Version 4.65 is pretty old now. It only supports IPX/SPX. I think you'll find IPX/SPX is not installed by default on XP. In any case I really cannot support old versions of WideFS. The performance of version 5 of WideFS is markedly superior to version 4. Since version 5.50, the current version, TCP/IP has been the default protocol as this is easier to set up with XP. Er, it is absolutely no use specifying "UseTCPIP" for version 4.65 as TCP/IP was not supported until version 4.70 at the earliest (but buggy then -- full support was version 5.00). Please go download the current version and use that. Pete

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