Pete Dowson

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

Yes, it also happened. After I got the FIRST error message, I tried to change the trigger, thinking that it might be a syntax error. But the error appeared every time after that, regardless what I actually entered. The only cure was to disable all triggers and restart FS. So you are probably right, and it happens when loading the plane. We still seem to be talking at cross-purposes here. There are still serious inexplicable conflicts in what you say which prevents me understanding what you are seeing. You say "Yes, it also happened" in answer to the question "you did NOT mean actually operating the A/P switch, for example?", but you end by saying "So you are probably right, and it happens when loading the plane." All I can derive from this is that (a) it happens when loading the plane, AND (b) it happens when you operate the A/P switch in FS The former is probably because PANELS.DLL is calling upon SIM1.DLL to suply data before an aircraft is fully loaded, but the latter can only be down to a problem with the Sound itself, as far as I can see. There's no point in me solving one part if the other is still a problem. So, please, can you be more specific? Just a simple statement of what you do and what you see, including WHEN you actually operate the A/P switch itself. Have you tried using the FSUIPC offsets instead yet? Does this fix the aircraft loading problem but not the sound-crashing problem when you operate the switch? I am out most of tomorrow, so there will be a delay in further replies. Apologies. Regards, Pete

What "goofy work-arounds"? I really don't see why you've got such a thing about something so simple. What difference does it make when ActiveSky is started? If it changes the wind direction at the departure airport you still need to restart the AI traffic. The FS menu isn't even created then. Anyway, don't many folks, like me, have FS starting up without that "fly now" interface? Mine boots straight into my default flight. The only time I ever see the initial setup dialogue normally is to get into the Scenery Library options -- and that's only because MS removed them form the World menu. If you mean can I trap keys being used in a dialogue, no, that isn't possible. Windows directs them on instruction from the main message loop in FS. Well, quite honestly, I really don't see what you are considering goofy. You seem to be making something very complicated out of something very simple. And if its "realism" in your set-up procedures you want, you certainly wouldn't be using that start-up dialogue, would you? You would fly from A to B and have your default flight set to the last saved flight so that next time you loaded your aircraft would be where you left it at B. And so on. I also don't see what you solve by changing where or when the weather program is started -- when the wind direction is changed, the runways being used by AI Traffic and announced by ATIS will be wrong. How does anything you've said change that? If FS was even able to allow ActiveSky to set weather before FS is actually running properly, alll that would be immediately negated when you press "fly Now", because that is the moment that the flight you've defined, with the weather you've defined, is executed. Considering that they don't "allow" (or rather, provide for) any sort of third party control over the weather at all, in any shape or form, I would have thought wishing for something even more esoteric was a bit daft. Let's wish for a weather control capability first! Regards, Pete

How? WideServer is not starting till it is safe to do so, so how is it going to tell the clients? If you want applications to start before they can talk to FS, simply use Run instead of RunReady. Also, why would you want such a thing? Do you think there's anything they could do even if I could arrange it? Regards, Pete

Sorry, FSUIPC does not offer any calibrations for slew. You need to get the controls reasonably well calibrated in Windows first. Then use FSUIPC just to make the flight controls and so on more precise. Since FSUIPC is dealing with flight controls only, the Slew controls don't come into it. Alternatively, just use the keyboard for Slew, like I do -- it's more precise in any case. To do this, go into FS's Options-Controls-Assignments and delete all assignments of axes in slew mode. Regards, Pete

Ah, so I did misunderstand you when you said "Whenever I tried to change a trigger ..." -- you did NOT mean actually operating the A/P switch, for example? That's how I read it. In fact you now seem to be saying that the error occurs during the load of the aircraft -- Esound is somehow getting to run before FS has loaded the aircraft, hence the panels crash. Right? OR do you really mean this apparently conflicting statement (in answer to me asking "It occurred whilst everything was relatively stable?": Once we can understand each other, so I can picture what is actually happening, which is difficult at present, then I can make the best suggestions. If it is because of access whilst FS is still loading, then some small changes to Esound (to check certain new FS flags, for instance) could probably fix it okay. Alternatively I could trap errors and discard them, which may or may not answer everything. But my main problem is that Esound isn't suitable, as it stands, for re-compiling using my current development system. If it was then either of these solutions could be achieved quite quickly. As it is, it is about a day's work to move it over. I can probably fit that in soon, but not this week or weekend, I'm afraid. Please clarify exactly what is happening, resolving some of the conflicting statements, and I'll make some decisions on this. Meanwhile, if this hypothesis is correct, it would have probably failed in the same way on your system in any version of FS -- it's just extremely odd that I cannot make it do so here. You may be able to do what you want better using FSUIPC offsets instead. Regards, Pete [/i]

I've just tried your exact CFG file, except with my devices and different (FS) sounds, and it works fine here in FS9.1. How can I make it fail? Incidentally, I note that you start the Autopilot Active sound in a loop when the autopilot is switched on, but you have nothing to terminate the loop, so it will continue forever after then. Well, more flexible and a little less dangerous, but all of the early uses of Esound were using the gauge tokens. It shouldn't matter. Sorry, I don't fully understand that part. You mean the Panels DLL error did NOT occur whilst loading an aircraft? It occurred whilst everything was relatively stable? If so, then I certainly don't understand that -- there's nothing in the Esound access which won't work with a stable setting. Furthermore, if you mean it doesn't crash until you change something (e.g. switch on the A/P) then it really isn't going to be related to token access -- Esound will have been looping like mad reading that token in any case. Things to check: 1. Are you using the current version of Esound? (2.572). 2. Does this occur with the default FS panels? 3. Does it occur with default FS sounds or only your own creations? Item 3 is looking the most likely. If, as you say, either "nothing happened", or a panels.dll crash occurred, but only when you expected a sound to trigger, then it seems most likely that the WAV files you are trying to use are clobbering something in FS. Esound doesn't play sounds independently from FS, it is using DirectSound and, if these are on the same sound device as FS, blending them into FS's sounds. I'm wondering if it is possible that your WAV files are not compatible with FS's WAV files. Regards, Pete

I can look at it, but I can assure you that there's nothing changed between 9.0 and 9.1 which would affect Esound. For token-named variables it does use panels.dll, just as a gauge would do (Esound started life as a gauge). PANELS.DLL will crash quite readily if token value requests are made of it when there's no aircraft loaded and ready -- e.g. during initial loading and during relading of flights and/or aircraft. However, in those times Esound doesn't really get a look in, and I've never seen a crash brought about in this way. It shouldn't be a problem at all for FSUIPC offsets -- Esound calls FSUIPC for those and the latter provides the protection for unloaded aircraft. Mind you, I haven't used Esound for many years. I simply do a re-test and make minor adjustments if necessary for each FS release. My standard test may not be extensive enough though. I just tried again with 9.1 and cannot get it to fail. At what point do you get a failure? Have you actually programmed it to do anything yet? Maybe if you sent me your Esound.CFG file to try here? BTW isn't pmSounds able to cope with virtually everything now? Regards, Pete

Odd, I've read all the threads there and I didn't see that. Never mind, must have missed it somehow. Are you using FSUIPC 3.411, the current release? Please check the Release details at the top of this forum. One bug in 3.40 which was corrected in 3.41 is listed in the details and affects spoiler calibration. Please do read the notices in this forum, especially the details of new releases, and always make sure you are using the latest version before posting problems -- I can't support old versions I'm afraid. Regards, Pete