Pete Dowson

No -- the wind smoothing works fine. There was a bug a few versions back which did that, and there's also one in FS itself (but the wind smoothing overcomes that). Please double check that you are actually using 3.60 -- look in the FSUIPC Log file. There's an option in ActiveSky for "direct wind control" (or similar wording) -- if it is on, turn it off. If that fixes it then it does sound very much like you actually are using an old version of FSUIPC -- perhaps installed by an add-on? If you are absolutely sure you are using 3.60, and you can reproduce the problem easily, set Weather logging on and induce the problem. Keep the session short or the log with become very large. Also check for updates to ActiveSky. The current version seems very good, very smooth. Regards, Pete

For an all WinXP setup you shouldn't need to specify Server name or IPaddress, or even protocol -- you can set a PreferredProtocol in the Server. The Clients will find the Server automatically provided all PCs are Win2000 or WinXP, and all in the same WorkGroup. Then this problem wouldn't arise. I don't get the problem here in any case, I've been trying to reproduce it -- it is certainly some sort of timing difference. If you have a WinME client, that will certainly need the server and protocol set. The auto stuff won't work on WinMe or Win98. If I determine a way of preventing the problem I may need to ask you to test it for me, please. Regards, Pete

No, sorry, that's pretty weird. Are you using a CH driver for the pedals, or one found for you by Windows? It has got to be some sort of USB level interaction -- but why it was ever delayed like that in the first place baffles me. That's definitely usually down to USB power management problems. In fact if they interfere with each other then any delay in that is odd anyway. Something hardware-wise is changing, voltage is going down or temperature up. There is another thing to try -- see if you can find another USB - Serial driver for the PFC. The original one I had was problematic in WinXP, I think it was old and designed for Win98. Try http://www.ftdichip.com/ -- most of the seerial adapters use FTDI chips I think. Regards, Pete

Great! Good flying now! ;-) Pete

Ahif the system thinks there's a Game Port device there, but it is unplugged, it can't tell EXCEPT by awfully inefficient timeouts. That indeed does sound like the culprit. More modern game ports did these things asynchronously, but the old design (as invented in fact for the very first IBM PCs) was rather a kludge really, timing the discharge of a capacitor through the pot -- the worst case being of course a disconnected pot as when there's no joystick. Regards, Pete

No, this isn't a shutdown code from the Server, it is generated inside WideClient because of this: Error on recv() [Error=10054] Connection reset by peer With UDP (only), being connectionless, it is the only way I can actually be sure to see when FS is closing -- the error 10054 should only occur because a server Port which we received from now says it is disconnect. I don't know why you are getting that immediately like that (it doesn't happen here), and what is even odder, it is being logged before the Client even lgs the connection succeeded. For now use TCP or SPX. I will have to think about this -- I thought I could rely on Windows errors such as this, but it seems not. Maybe I have to ignore the first few or something. :-( Please tell me, what Windows versions are you using, Client and Server? Regards, Pete

WideFS cannot "see" WidevieW at all -- it is not an application so much as an FS module. This sounds like an easy thing for Luciano though. Isn't it in his FS Menu already? If it is in the Menu on the Server, then you may be able to operate the menu from a Client by sending keystrokes to manipulate it -- even programming the "virtual buttons" on WideClient's screen, or from your application using the new keystroke controls in FSUIPC via offset 3110. Regards, Pete

Yes, thanks. I have made a change to FSUIPC to get the string from the right place. I've tested it with the Italian language DLL and it works, but I also discovered an interesting thing which I cannot fully resolve ... The FLT files from the English version, with [Air Traffic Control] as the window name still appear with that name. It looks like there are some small differences in the ATC.DLL after all, as it seems to cope with the language of the file changing tooI don't know what happens if you exchange FLTs with others. Hmmm. Anyway, I'll make FSUIPC cope with English and the current FS language. I cannot add a complete list in and I have no foolproof way of otherwise identifying the windows to suppress. Look out for interim version 3.602 maybe tomorrow, in the Interim Versions thread above. Regards, Pete

Sorry, no, it doesn't. In fact the log shows everything behaving very well. This log actually shows entry times and exit times for message processing, and there are plenty of gaps between. It is either a problem with the Network at some level before anything I can see in WideClient, or possibly a problem with something like button scanning. Are you programming any buttons from Client devices to the Server? Might you have something to do with EPIC of GoFlight present, or maybe some now unused but still installed joystick drivers? I seem to vaguely recall there was a problem with something like that a while back. To test, set ButtonScanInterval=0 in the [config] part of the INI. That will turn all the joystick, EPIC and GoFlight checking off. I see you also have a GPSout capability configured on this client. It looks to be operating, but that's another thing you could try eliminating, just as a test. Maybe there's something up with the serial port it is using. Regards, Pete

Ah, okaycan you please ZIP up and send me (petedowson@btconnect.com) the Language.DLL from your main FS folder. I should be able to fix it with that. Seems like I'm getting the wrong "Air Traffic Control" string. There's one used in the FLT files too, for the Window settings, and I've a feeling that will be left in English so that FLT files are interchangeable. Regards, Pete

If they take keyboard commands, yes, via the KEYSEND facilities in FSUIPC and WideFS. They may need to have keyboard focus though, depending how they get the keypresses, which could be a problem if there are more than one. Not without WideFS, as there are no network features at all in FSUIPC. Regards, Pete

Sorry, I don't want the name of the DLL -- it is always ATC.DLL. It is the name of the Window, as shown in the title bar of the Window!! Can you answer any of the other questions at all, please? I'm puzzled as to exactly what you see and when you see it. I don't want it in any case, it isn't relevant - the Log shows that the DLL is the same (or same enough) because otherwise the patches would not be applied. AND never ever send any files in their raw state in any case. ALWAYS zip them. Most ISPs and protection systems will stop any files looking like programs or registry data! Regards, Pete

If it isn't even mentioned in the Log, then there's only two possibilities -- either it isn't even trying to connect to FSUIPC (in which case you'd need to look elsewhere for a reason), or it is wrongly trying to connect as if it were an external program. In the latter case you may see it in the log identified incorrectly of course as FS itself! However, in the latter case, provided your FSUIPC is registered, it should still work -- UNLESS you have more than one Gauge or DLL trying to do it the same way. In the latter case they'd clash badly and neither work correctly as they'd be using the same data exchange memory. SimMarket then. No, it must be okay if the Log says you are registered AND the other TCAS gauges are working. Regards Pete

Okay, I found the FSRealTime options for messages, and enabled both "When crossing a new timezone" and "When an AutoUpdate occurs". UNLESS I check the bottom left option in FSUIPC, to suppress single line messages in FS, both types of messages appear -- scrolling across and disappearing if the option is set this way in FS, but annoyingly displayed permanently with the other FS option. I checked what FSRealTime is doing (this was with version 1.73) and it is writing the message with the option for "scroll or display till replaced" -- i.e. no time limit, unfortuanately. So it is working okay here. If this is not how it works for you, with that option unchecked, I need more information to reproduce this please. Regards, Pete

Yes. Pete

It shouldn't no. There have been cases where folks seemed to get FS2002 to load from the main FS9 folder, but in my experience it only loads from the Modules folder. No, both are written at the same time, as one 8-byte transfer. So that is okay. It should work flawlessly. However, in your original message you said: I would be worried about several things here. One is that 250 mSecs. It is very large. It would be better shorter I think, say 50. Another is that things could change between steps 2 and 3 -- Best to read the whole struct in step 2 and accept it if the ICAO matches. Even more puzzling is that once the ICAO is written, the weather for that station is continually updated at 1 second intervals thereafter unless and until a different read request is made. This being so, you should always get the correct weather UNLESS something else is using the same facility. Try it with WeatherSet2 for instance -- that actually simply tries to set the ICAO when you ask, with a zero signature so it doesn't interfere with anything else. I notice you mentioned WideFS. Are you running your program on a client? If so, reads are not done through FSUIPC in any case -- that would be far too slow for WideFS to keep scanning for changes to send to all of its clients. WideFS reads go direct to FSUIPC memory, and read/write logging is an option for WideServer/WideClient. The only reason the Writes are logged is that they have to be passed through FSUIPC for action. So, first test on the FS PC with logging in FSUIPC, check the sequences are all okay. Then go back to WideFS clients. Please update to the latest WideFS interim versions above first, as if we start on logging I need to relate to the versions I can debug. I had intended by now to release WideFS 6.60 (there are lots of changes) but too many things keep cropping up (including holidays! ;-) ). Rather than outright data logging in WideClient/wideServer, try the Monitor facilities just to keep an eye on the critical locations -- 8 bytes at CC04 for instance. You could do that in both WideServer and FSUIPC on the FS PC, just to crosscheck timings and events. Another logging which may tell you a lot in the Weather logging in FSUIPC. Regards, Pete

Actually, it does hereif it is called "ATC Window". Now I thought I got the name from the Language DLL so it should recognise it with a different name too, but maybe it doesn't. Can you confirm the name please? It is mainly aimed at doing that, yes. If you get any appearing, could you let me know please? What language version of FS are you running? The main thing RemoveATC=Yes really does is make three patches to ATC.DLL to prevent that DLL crashing in certain strange circumstances which ONLY otherwise happen if you switch off all three ATC options in FS -- the window interception was done first in an attempt to fix the crashes, but that didn't actually fix them. This explains the name of the option, though. I would like the option to match the name I gave it if possible (and it certainly does here). This is the reason for my continued questioning. If I cannot then I will need to change the documentation in any case, but it did work as advertised on all the test cases before release. Regards, Pete

Ouch. Something obviously changed then! I really don't think that could happen with nothing changing. Is this BEFORE any client applications (using WideClient) are running, or after? One reason you can get this is a client application stuck is a very tight loop calling WideClient. Other reasons are all tied up with the Network, as any loops in WideClient involve Network calls. Which shows a good connection and nothing more. In which you have "Log=DebugAll" in the wrong section -- it won't do anything there, so please delete it. Logging is controlled in the User section. Before we go into more logging, could you please try the latest WideFS (Server and Client) available above in the Interim Versions thread? A lot has changed and I cannot really deal easily now with 6.51 detailed logs -- I had planned to release 6.60 before now but other things keep getting in the way! ;-) Let me know. If it is still the same, use Log=DebugAll, but in the correct section of the INI. The log will get large so don't run it longer than necessary to see the problem. You'd need to ZIP it up then and send it to me at petedowson@btconnect.com. If it is a Network problem then I may not be able to help easily even then, but it is worth a look. Regards, Pete

What does it say when it appears? You mean whilst you are flying or taxiing, ATC talks to you and shows the Windows, or is this only for AI traffic? I'm sorry, but I still don't understand your term "normally" in these circumstances. There are windows, of course, but ATC windows? Which ones? YOU are calling the ATC window yourself? Why, if you are using RCV4? Surely you don't use both? My patches should eliminate the ATC windows coming up automatically. No, not at all yet. Sorry. What is the title on these ATC windows (literally, please), and when, precisely, do they appear when using RCV4, say? Regards, Pete

Well a key has been issued for an "M4000", but I don't know what it does. By "targets" what do you mean? Is this a combat HUD or something? Or another TCAS gauge? If you are properly registered it wouldn't need a key in any case -- where did you get the registration key? Do they use FSUIPC? What do they display? Evidently then no one else has a problem with the M4000? Please do a short session, getting the problem, close FS down then show me the FSUIPC.LOG file you will find in the FS Modules folder. Regards, Pete

Can that be done? I'm sure they all still use only the one digital control board, which in this case is in the Pro Console. If two RICs are connected it will likely either fail or provide the same signals for each. There's only one firmware controlling it all, in the console. How, if they look the same to the software? Please check all this with PFC. Regards, Pete

Are you using FS9.1? What are the "correct drivers"? Each new version corrects and improves some things and introduces new problems. It may be worth trying a different version. Also try asking around on the FS2004 Forum. There'll likely be more experience of this there. Regards, Pete

Yes, that's okay. It's is "fixing" ATC. Please now explain exactly what you are doing and what you are seeing. Regards, Pete

There's nothing at all in FSUIPC that touches that unless you program it to. Regards, Pete

3.601 is an FSUIPC version number but the parameters you are talking about relate to WideFS. You may have something bad going on with UDP causing a jam -- maybe you use a hub, not a switch? I do exactly as you and everything connects fine. Try TCP or SPX. Please note that there is no way I can offer detailed assistance without knowing more -- in this case WideFS version number, WideClient and WideServer INI and LOG files. Regards, Pete