Pete Dowson

Not related, no, but it is a silly WideServer bug. Thanks for spotting it! Pete

Nevertheless, the Log simply shows a total inability of this PC to be used for WideFS together with PFD. Something is wrong on that PC, but what it could be is going to be a problem isolating. That sort of sequence is normal once or twice whilst FS is loading on the Server. It just means WideServer isn't getting enough time to send responses to clients in a timely manner. Though why you have a series of 4 of these at 20/25 second intervals is indeed rather strange. Something is stopping the traffic for several seconds every 20/25 seconds. That doesn't sound very FS-like -- especially if the other Clients don't show a similar pattern. Check what other processes you have running on that client. After that, however, there are no reported errors for over two HOURS! Did you have a good flight for those two hours? What was happening? Or have you merely deleted a large part of the log because it was repetitive? Then the rest of the sequence looks like FS was closed so the service disappeared. Did it? 7491828 Error on client post-Connection Select() [Error=10053] Software caused connection abort 7491843 Ready to try connection again 7491843 Attempting to connect now 7493031 Error on client pre-Connection Select() [Error=10061] Connection refused 7493031 Ready to try connection again 7493078 Attempting to connect now These next errors are from the Client program (PFD), and show that it was in an odd state: 7515750 READSTATEDATA received with bad data size! 7515750 0 ReadLocal: Offset=8C000000, Size=0008 7521031 0 ReadLocal: Offset=8C000000, Size=0008 7523687 0 ReadLocal: Offset=8C000000, Size=0008 7526343 0 ReadLocal: Offset=8C000000, Size=0008 7531734 0 ReadLocal: Offset=8C000000, Size=0008 7534390 0 ReadLocal: Offset=8C000000, Size=0008 7537062 0 ReadLocal: Offset=8C000000, Size=0008 7539703 0 ReadLocal: Offset=8C000000, Size=0008 7542359 0 ReadLocal: Offset=8C000000, Size=0008 7547750 0 ReadLocal: Offset=8C000000, Size=0008 7550406 0 ReadLocal: Offset=8C000000, Size=0008 7553109 0 ReadLocal: Offset=8C000000, Size=0008 7555812 0 ReadLocal: Offset=8C000000, Size=0008 7561234 0 ReadLocal: Offset=8C000000, Size=0008 7566640 0 ReadLocal: Offset=8C000000, Size=0008 7569296 0 ReadLocal: Offset=8C000000, Size=0008 7572000 0 ReadLocal: Offset=8C000000, Size=0008 7574671 0 ReadLocal: Offset=8C000000, Size=0008 7577343 0 ReadLocal: Offset=8C000000, Size=0008 7580015 0 ReadLocal: Offset=8C000000, Size=0008 7582703 0 ReadLocal: Offset=8C000000, Size=0008 Finally, a shutdown actually gets seen? Not sure how that got through here: 7584578 Shutdown request received! and the performance figures actually show that almost nothing was ever received from the Server: 7585187 Reception maximum achieved: 0 frames/sec, 0 bytes/sec 7585187 Max receive buffer = 2710, Max send depth = 2 My first suspicions would actually fall upon the PFD program's use of OpenGL on that PC. See if you can run something else on WideFS on that PC instead, whether another non-OpenGL part of PM or some utility -- like my own TrafficLook and WeatherSet2 programs, for instance. If they run fine, with no problems, then you need to start looking at video drivers and checking out OpenGL and IRQ clashes in particular. PM support should be able to help with that. If you get problems with any and all WideFS client programs, then it is going to be a matter of elimination of each potential contributor, one at a time -- driver and Windows settings (compare with other PCs), Network card, cable, connection at hub/switch. Regards, Pete

Hmmm. I can't really see how any of that is really likely to be anything to do with Esoundit looks like you have other problems on your system to do with sounds. That is, unless Microsoft have made the DirectSound routines incompatible between DirectX 6 or 7 and whatever is current, which seems rather unlikely. The DirectSound routines in Esound haven't change in many years and always worked fine, and the access to FSUIPC variables is done in no different a way than any other FSUIPC user would use. NTDLL is simply a main support library in Windows. If I were you I'd check your sound drivers and DirectX installation. There's certainly nothing in any of that coding I'd want to go near in Esound, it was bad enough doing the research to make it work in the first place. DirectX is about the most unfriendly, complex and difficult API to work with that could be devised and I want nothing more to do with it ever again if I can possibly help it. Let me know if you decide not to bother with Esound any more and I won't do those other changes either. It will save wasting a day or two. On the other hand, maybe a simple re-compilation will actually help, though I really can't see why. The only other alternative I can think of is for me to produce a non-DirectSound version of Esound -- one with all the other facilities intact, but the sound playing reduced to a simply "PlayWave" call -- no speaker selection, no DirectX. Maybe no looping (I'm not sure whether the simple interface provides looping). However, this is quite a bit of work as it would involve wholesale changes. I'm not really inclined to do this. It would be a *lot* easier and quicker, I think, for pmSounds to be enhanced a little. Why don'y you put your needs together and ask Enrico? Regards, Pete

No. Any program can register a "hot key" with Windows. The hot key mechanism steals the keypress from all programs and passes it to the program who owns it, ignoring all things like keyboard focus and top windows. There's a similar facility in Windows to steal the mouse. Regards, Pete

I don't know where you are looking, but I don't provide any bank details whatsoever, anywhere, as I don't sell FSUIPC. You need to go to SimMarket. Check on http://www.simmarket.com. In the latest FSUIPC user guide I did update all those details so they should be in complete agreement with what is on the SimMarket web site -- but I do provide a link too, in the document, so you can be sure. Here it is (you must have missed the whole section on payment in the documentation?): http://secure.simmarket.com/paymentoptions.php I'm sure there's enough information there, including all the International Bank codes as well as the selling company's name and address. Regards, Pete

Since it is the client which is reconnecting, there will obviously be more useful information in the Client log file. There's none here. Perhaps I may be able to advise more if you showed me the relevant log? Also, try a process of elimination -- try the PFD on a different PC, to see if it's that PC or something to do with the PFD program. If the problem moves with the PFD then it is likely to be related to the OpenGL drivers. It may be related to them even if it doesn't move, supposing you have different video cards or drivers on each PC. Otherwise, it may be a bad network card, cable, port on a hub or switch, or something not set up right in Windows. It may be conflicting IRQscheck through the complete list of potential problems provided in the WideFS documentation. But the first step is to look at the apropriate Log to see what the errors are which are causing reconnections. Regards Pete

Ah, it's just that the source hasn't been updated for FS2004. You should be able to do that easily enough. As documented in the Programmer's Guide The prime reference for all information from FSUIPC, excepting the more complex weather interfaces). In fact it is from the offset 3308: Regards, Pete

Of course not! It doesn't "trap" anything! You evidently misunderstood me. All that happens is than when a program is in an amodal dialogue, all keyboard messages for that program are directed to the dialogue processing procedures, not to the main processing window code (which is where FSUIPC could see them). FSUIPC does not use any Windows specialised hot key facilities, those which Active Sky evidently uses, for instance, to grab keystrokes no matter what program has focus. If it did it could certainly process keypresses. I did explain this, but you must have missed it. I do not really think it appropriate for FSUIPC to act on anything which may be intended for programs outside FS. Regards, Pete

Thank you, but again I assure you it was not acquired from the FSUIPC.ZIP file on the http://www.schiratti.com/dowson page! I have downloaded that myself and checked it against my perfectly clean copy. I think you are mis-attributing the source of this worm you obtained. I do not think it is good to frighten folks here from using the latest version of FSUIPC, installed from a perfectly good and checked download. Regards, Pete

Well, I've been thinking this through a little more, and I am coming to the conclusion that, in fact, it would be best all done, optionally, in ActiveSky. Here's my reasoning: 1. If FSUIPC has to resort to using the Windows hot key merely to start a program, then it is not really an FSUIPC sort-of function. Any program can reserve a hotkey in Windows. Why FSUIPC? 2. If FSUIPC does have a facility to start a program on request like that, then, unless that program is written specifically to start up invisibly or minimised (as for instance WideClient can, through INI options), then it will take focus and display itself in any case. If FS is in full screen mode then it will probably get minimised as a result! Either way it won't be the hidden start you are wanting. 3. If ActiveSky has a mode where you can start it up (with a normal FSUIPC start, or a batch file start, or any other way, even manually), but where is doesn't actually try to establish the placing of the aircraft nor setting the weather UNTIL told to by a hot key, THEN I think it could all be done the way you say. If it sets and owns the hot key, it can free it up again for normal use as soon at it has started for real. It also doesn't have to gain focus or change your view of the FS screen. This sounds like quite an easy modification/option for ActiveSky. I don't think it would apply to FSmeteo, which works differently in any case, and I really can't think of anything else it might apply to, so you can understand my reticence in adding the facilities I suggested just for the one program, especially when it could probably do much better itself. Regards, Pete

One thing to check before anything else. You say you are using WideFS 6.41, but are you absolutely certain you are using both WideClient and WideServer 6.41? If you've just changed the Server and not the Client then this may be the problem -- the "WriteLocalDirect=No" parameter is used in WideClient 6.40 which was found to give strange problems like this, which was why it was scrapped in 6.401. Also, I assume you've not changed any of the default WideFs performance related parameters in their INI files? This certainly sounds like the problem is an older WideClient. I have just this moment programmed two buttons in FSUIPC, operated on a remote PC, to the PM MCP SPD INC and PM MCP SPD DEC controls, and they work fine. My PM MCP is running on the same PC as FS, unlike yours. So, I also tried running FS on another PC and having WideFS linked to the PM MCP on my erstwhile FS PC. I've programmed joystick buttons on the now-FS PC and on the now-only MCP PC, and in both cases they worked flawlessly. I don't think it is either FSUIPC or WideFS. I hate to do this, but if it is not some simple error you've made, like not updating WideClient, or changing some of the performance parameters, I think it is back to Project Magenta support -- I don't know what restrictions or differences the "Demo" versions of PM make, but possibly there's a problem with them? There have been problems with the FSUIPC offsets interface into PM from time to time, maybe the Demo is build on a version with such problems? BTW If you want to check the operation of WideFS/FSUIPC in commanding PM, simply use the FSUIPC Monitor facility -- on the Logging page. You'll need this information from PM's documents page (pm FSUIPC offsets): If you set FSUIPC to monitor offset 5418 as a U32, in Hex, and have it display to the adv display on screen (the easiest in this case) you will see, for example: Press PM MCP SPD INC: 5418 changes from 0x0 to 0x800 (bit 11) momentarily, then back to 0x0 -- this is FSUIPC setting the bit and PM's MCP clearing it when it has incremented the Speed. Maybe there is a bug in the Demo version which is causing the bit not to be cleared. However, that wouldn't explain why you get it working okay when pressing a button on the FS PC. Version 6.40 of WideClient may do, though. There's no difference as far as FSUIPC button programing is concerned where the button is coming from. Well, it isn't solving the original problem, but I must say that I run the PM MCP in the FS PC because I believe that gives the best performance -- the autopilot control needs the quickest feedback, and even the slight amount of latency you get across a network could be a little damaging. With a P4 with hyperthreading as the FS PC FS itself seems to be only using 50% of the capacity in any case. No, but then I'm using current releases of PM modules. Regards, Pete

It is very very unlikely -- unless their aircraft actually uses FSUIPC, which it doesn't as far as I know, it cannot really be involved. It is passive, used by you or other applications as required. The one possibility I can think of would be a badly installed FS9.1 update -- please see my FS9.1 announcement at the top of this forum and check the FS9.1 modules against the list I supply there. Incidentally, the current version of FSUIPC is 3.411 (which also does get around some bad FS9.1 update problems). Please upgrade to this latest version. Then, if you still want me to look, run FS for a short session, close it down, then show me the FSUIPC LOG file, which you can get from the FS Modules folder. Regards Pete

Sorry, that's only a combination sale offer, made by the retailer because there's less work for them to do when you do it in one transaction. It's a bit like those "buy 2 get 1 free" offers in supermarkets. Regards, Pete

Currently FSUIPC does not use the Windows "hot keys" facility -- that pinches keys from ALL applications, and i really wouldn't want to do that. All FSUIPC does is intercept the key presses arriving at FS's main interceptable window. I can't do that with dialogues, at least not without subclassing them, and that could be a real nightmare sort out which one is which. I think they all have class "FS98CHILD". A button on your joystick would be easier. Even then I'm pretty sure the button scan rate whilst you are in a dialogude is pretty low, so a quick press could be missed. Regards Pete

All I can think of is that, if I can actually detect the fact that the initial dialogue (also entered by ESCape and ending a flight) is displayed, I set a flag which programs like ActiveSky can read. What they do about it, I don't know. I must admit I am getting more and more perplexed by the amount of complicated shenanigans that folks (or is it only Agrajag?) seem to want to happen behind the scenes just to do something which seems, to me at least, to be so simple and understandable as it is. Maybe the ActiveSky scene is different. With FSMeteo, which I still use (I don't have an up-to-date ActiveSky), you need to load it up and have it running and setting weather for quite a while before it is "enacted". I actually like it that way. It is "comfortable". It does that whilst I am pre-flighting, planning the flights, setting up the FMS, and so on. Then a quick toggle of the AI traffic and I'm ready to get my ATIS then have my plan cleared by Clearance/Delivery. I can consider: 1). A new pair of FSUIPC assignable controls to Run/close a program, with the parameter number giving a reference to its startup line in FSUIPC.INI. 2). A flag to show when the Flight creation/options dialogue is open -- if I can detect this at all. I really can't think of any other way I can help in fulfilling this (to me) rather odd request. Regards, Pete

Even if FSUIPC is able to process the messages from ActiveSky, I don't think it can see keyboard messages when a dialogue is active. The window class used for FSUIPC's IPC interface is not FS's window class so operates independently. Possibly a button press might be seen -- experiment if you like, program a button to do something in a way you can detect (a bit difficult really, in a dialogue). If it does work then maybe another class of program loading could be added "RUNONREQUEST" with a new FSUIPC control to action it. Regards, Pete

Really? That's absolutely amazing! FSUIPC is supposed to be deliberately sleeping then. In fact, it almost will be -- it certainly doesn't get any frame rate calls, which it relies upon for nearly everything. Marvellous! So you've solved it! What's the problem that started all this then? Regards Pete

But what does that save? Toggling it off is an instantaneous process, almost. It is re-enabling it that takes a little time and shows a progress bar. Yes, but toggling the AI traffic seems to be a more sanitory solution, does it not? Either way, both can be accomplished automatically by ActiveSky if it so wishes. Regards, Pete

Well, that's a start, but to check his registration I'd need his KEY file too, which he should not really reveal to anyone else. There are now a handful of folks reporting similar problems, all of whom have been asked for LOG and KEY files and none of whom have responded with these details. At least one of these most definitely looks like a case of an illegitimate (forged) registration, and the circumstances make the others look similar. The fact that none of their email addresses used here are known as registered user addresses is also suspicious, though of course they may have more than one, or have changed it since registering. I am not a naturally suspicious person, but it is looking a little odd. I am, however, keeping an open mind. One thing which would prove it one way or the other would be to see if accredited programs run correctly WITHOUT the user registration -- i.e. without the KEY file. If so, then it is most definitely a case of an illegally forged user key. These always had the potential of wrecking the operation of FSUIPC. Regards, Pete

That's a nasty error! It looks very much like the WEATHER.DLL is not the official one, even though it bears the correct version number (as is borne out by my log entry "FS9.1 WEATHER.DLL" at the top). The crash is EXACTLY where it will be if the Weather DLL is the wrong version. Ask your user to re-check his FS9.1 installation -- he can check the modules against the list shown in my FS9.1 announcement at the top of this forum. If it still looks okay, I'd like to see the weather DLL please -- he can ZIP it up and send it to me at petedowson@btconnect.com. Regards, Pete

Okay, I can deal with that, but not just yet. Stick to FSUIPC offsets for now! Regards, Pete

You need the FSUIPC SDK. Get it from http://www.schiratti.com/dowson. There are at least three ways to get the dew point, depending on which temperature layer you want it for, and so on. Regards, Pete

I don't think FSUIPC can get a look in there. And what does "pause AI portion of the engine" mean? How? Regards, Pete

What's that supposed to accomplish? Well, here both FSMeteo and, I think, ActiveSky, take quite a while to set up all the weather stations in your area, so I can't understand why there's no delay. For efficiency and to avoid flicker whilst weather is being set, FSMeteo sets all the nearby weather stations in a "Pending" mode (there aren't executed by FS) and activates them when it has done the main local batch -- so the weather isn't actually correct at your airport till quite a while after you place your aircraft there. The same would apply no matter how you place it initially. I don't know what ActiveSky does, Damian doesn't keep me updated. Sorry, I don't understand that bit. But as I explained (a) it can't do that -- all that initial setup stuff is a dialogue and nothing else is happening, and (b) as soon as you press "Fly Now" the flight you've created is loaded into the simulation engine, overwriting anything that may have been set, if it were possible, in the first place. Right, that's a dialogue not a Windows menu. Terminology, it always gets in the way. :wink: Almost all the dialogues used in FS are, as in many other programs, "amodal", which means pretty much everything else is stopped whilst you are in them. FSUIPC daren't even start doing anything serious in any case at that time, even if it could, because most of the routines it calls in FS, and most of the memory areas it accesses, aren't even initialised. Regards, Pete

Just caught your message before I leave for the day. Strange it won't happen here on any of my three PCs on which I have FS9.1 installed -- two on XP Pro, one XP Home. It'll be some sort of timing thing. How do you start up FS -- does it go into the selection dialogue where you eventually press "fly Now", or have you got it going straight into the default flight? And when EXACTLY does the crash occur? Please let me see your entries. Regards, Pete