Pete Dowson

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

The usual problem is that for some unknown reason FS often sets the sensitivity to zero. Check that. Pete

Ernow you've lost me. Code for what? You don't mean EPIC I hope -- I've not programmed that for many years. I have a USB Epic but I just use the declarations provided to define all the axes as axes and all the possible buttons as buttons. Nothing more than declaring the interface to Windows as far as I recall. And I've not changed anything in that since the USB version first appeared! There used to be some EPIC forums where you should get loads of help. Have you searched via Google? Regards, Pete

Too much to expect I suppose! Yes thanks -- steam railways in Italy. ;-) Regards, Pete

The only thing I can think of is that you are using an Internet IP address for the Server, or at least telling WideClient this. Or it is an addrerss that has been set, in Windows somehow, as an Internat rather then LAN address. Please let me see your WideClient.INI and WideClient.Log files after such an occurrence. I really don't know how to invoke an Internet connection by program -- I've never written anything for the Internet, so I'm clutching at straws a bit. Regards, Pete

Sorry, it didn't appear. Just cut-and-paste into your message. Load FS and close it when it is ready to fly. Keep it short and the Log will be short. Regards, Pete

Please check the two or three checkboxes on the lower left. The defaults are different according to whether Advdisplay is detected as installed or not. Tell be which ones are checked, if any. Tell me what you've tried to change please. I have FSRealTime, but I don't know the option. Please tell me how to reproduce this message and I can also check it here. Regards, Pete

See the support details at the top of this Forum, the one entitled READ THIS IF YOU LOSE YOUR FSUIPC or WIDEFS keys. Pete

Hmmmupdating is only copying one file (the DLL) into the modules folder. That's it. One little drag and drop. BTW version 3.53 was released this year (Jan 1st actually! ;-) ) Where do you get such ruels? This would mean having to re-calibrate axes, and restore all the button programming and other options the way you like. Not only that, but it also it means re-entering registration details. And the Log is re-created from scratch every time you start FS, so that is totally irrelevant. Please simply copy new versions of the DLL into the Modules folder, EXACTLY as it tells you in the documentation. It couldn't be simpler. Don't delete a thing. The only thing about deletions is concerned with updating from a VERY VERY old FSUIPC to a new one, because some of the options may change names -- but that really isn't necessary even then, and most certainly hasn't been in the life of version 3.xxx. If you assigned it in FSUIPC then I'm not surprised, as you delete all your settings. Regards, Pete