Pete Dowson

After a recent hardware change, I have, for the first time, been able to consistently reproduce the black screen problem (no freezes or crashes though) on a screen mode switch, and I have discovered a work around. Please try it and let me know -- I've written it up in the IMPORTANT announcement. If this does deal with the reported problems then it most definitely points to some bug in FS itself, as the work around only changes the order in which the various parts of FS subclass the main window. The techniques for this have been use identically in many modules since FS95 days without such problems. Regards, Pete

Just to round off this rather unpleasant exchange with some possibly good news, those of you still bothering to read it this far, please now visit the IMPORTANT announcement. Thanks to a recent hardware change, I have been able to reproduce the black window problems (though not any crashes as such) and I may, or may not, have found a work-around. Regards, Pete

Okay. now I have been able to reproduce this black screen problem reliably, I've narrowed it down. It is related to the FS window subclassing order. Something is screwing up the subclass chain. This affects these modules of those I've tested: FSUIPC.DLL AdvDisplay.DLL PFC.DLL ViMaCore2004.DLL It seems that, here at least, I can eliminate the problem by ensuring that the window subclassing is performed as early as possible. This can be done in FSUIPC simply by adding the parameter: InitDelay=0 to the [General] section of the FSUIPC.INI file. Please, those of you with black screen problems, try this and let me know if it works. If it does seem like the correct solution, I will default this parameter in the next version of FSUIPC -- but only when it is run in FS2004. Unfortunately the same easy change does not apply to AdvDisplay nor PFC. I will release revised versions soon. I will also write to Lago about the similar problem with ViMaCore2004.DLL. Regards, Pete

I don't get time to surf the web and browse such things. I've always told people that. If they want me to notice things they need to write to me -- originally by email, now here in this Forum. It still takes 50% of my otherwise productive programming time to deal with all this. If i don't do any more programming I could browse, but what's the point? No one wrote and asked me, that's how it "slipped off"! Regards, Pete

I just changed my motherboard and processor, and I'm now getting all sorts of problems now with FS2004. Hangs, machine resets, weird graphics, and -- black screens. More importantly from the point of view of others, I can now actually generate a black screen problem using a very specific sequence of actions. Almost (but not quite) 100% of the time. This is how: Make sure you have FS2004 loading in Full Screen mode. Then get into Windowed mode (whether maximised or not doesn't seem to matter) by using ALT + ENTER. Go and deal with another program (FS losing focus seems to be essential). You don't actually have to do anything, simply click on another program's window. Then go back to FS and before doing anything else, press ALT + ENTER to send it into Full Screen mode. When I do this, it changes to a full screen sized black hole on my Windows desktop (my full screen resolution is lower than my Windows resolution). Note that it does not go wrong just continually using ALT + ENTER to switch modes -- the intervening access to another program (i.e. a loss of focus) is essential. Interestingly, FS2004 is not actually hung. ALT brings up the menu, and going to the Options-Settings-Display-Hardware dialogue and changing anything there does recover it. FS does then go properly into full screen mode and redraws okay. Aha! I thought. So, now I can reproduce it reliably, I can maybe work on some fix in FSUIPC? Maybe there's some activity in FSUIPC which I can stop when there's a loss or change of focus? Bah! Wrong!As another test I removed all my own additional Modules, FSUIPC, WideServer, PFC.DLL, Advdisplay, AutoSave, GPSout, andit still did exactly the same thing! The only other add-in modules I had left were FSNav.dll, ViMaCore2004.dll (for Venice scenery), and PMDGOptions.dll (for the PMDG 737). Now, if I remove those tooBingo! No problem! So, a process of elimination is needed. Trying each one in turn (excepting WideServer and PFC, which depend on FSUIPC in any case so can't be installed alone): ViMaCore2004 onlyproblem occurs! PMDGOptions onlyno problem FSNav onlyno problem AdvDisplay only problem occurs! AutoSave onlyno problem GPSout onlyno problem FSUIPC onlyproblem occurs! none of the aboveno problem Soit isn't specifically an FSUIPC problem, it is a problem related to something being done by at least a few disparate add-ins which is affecting FS badly during the changeover from windowed to full screen mode. I want to see if there are any steps I can actually take, inside FSUIPC (and, apparently, AdvDisplay too), to minimise or even eliminate the possibility of these things happening. But at present I really haven't a clue about what I can do. I will continue to experiment. At least I have something to work on now I can reproduce it! Watch the IMPORTANT announcement in this forum for any progress I may make. Regards, Pete

Sorry, you'll need to tell me more than that. Does "Team Speak" have a hot key arrangement for PTT? If not then that's a problem, you would have to get onto its author. If it does use standard hotkey methods then the existing WideFS facilities for converting KeySends into keystrokes should work fine. The problem with Roger Wilco was that it didn't use normal Windows hotkey or keyboard input techniques for its PTT. It uses the keyboard "asynch state" -- the actual keys prssed at the time, which there is no way I can get into from WideClient. However, in Roger Wilco there are Registered messages it uses as well for PTT, and this is what the WideFS "RWon" and "RWoff" use. If "Team Speak" does similar things to Roger Wilco to get its PTT key presses, then this would explain why you cannot get KeySend keystrokes to work. In this case you would need to find out, from the author, whether there are Registered Messages which can be used instead. I would then have to add extra facilities to WideClient to generate those. Regards, Pete

Ah, so it is a bug in FS for 3 engined aircraft only? And you say this has always applied in FS versions -- since FS4, FS5, or only recently? Has it been reported to Microsoft? You'd think they could have fixed that by now, if so? Odd that I've never heard of this before. Yours is the first mention I've ever seen. But then I only ever had some short experience with a 727 some time back (FS2000 or even FS98). Otherwise all I've ever used is 1, 2 and 4 engined aircraft. I'll add a new HotKey simply to select all Engines (no copying of throttle values) to the next version of FSUIPC. It will be a couple of weeks or so yet, but it is now officially on my list. Regards, Pete

First calibrate your axis in Windows. Then assign it to the Flaps axis is FS assignments. Make sure the sensitivity is set high and the null zone low (both sliders are in FS options). Finally, if you wish, tune the range of your axis in FSUIPC's flaps setting facility. I have on my list a plan to provide, in FSUIPC, specific calibration points for each detente. I've just done this for PFC equipment, in the PFC DLL 1.60. But I have so much else to do first, so it won't be for a while yet. Regards, Pete

I don't do anything with views at all, sorry. They are all FS's responsibility. Regards, Pete

Have you contacted Enrico Schiratti, the author of Project Magenta, about this? I'm sure it has come up before. Regards, Pete

1. FSUIPC wind smoothing is only appicable to global weather. FSMeteo 6 sets local weather, just like FS's own weather downloads. 2. Local weather is really the only sensible option for FS2004, for reasons I explain in the IMPORTANT announcement at the top of this forum. 3. With Local Weather, FS is supposed to be interpolating the weather for you as you fly, from several nearby weather stations. This should generally result in smoothing. However, it obviously isn't doing it very well sometimes. 4. The same variability can be found in FS's own downloads. It is hard on Marc to blame FSMeteo when even Microsoft and Jeppesen can't get it right. I have tried to get into it to smooth local winds from FSUIPC, but failed miserably I'm afraid. I might have another look when I get time, but it is pretty horrendous stuff in that WEATHER.DLL. BTW this is actually explained in the FSUIPC documentation. Please check the subsection entitled "Wind shear and other such problems" in the extensive "Important Notes for FS2004 Users" section, near the end. Regards, Pete

Er, no. I never knew there was such a bug. The E + 1 2 3 4 facility always worked for me. Are you saying that sometimes pressing E and the list of engines you want to control doesn't work? This is in FS2002 only, or all of them? I've never had such a problem. All the E + numbers facility does is set the mask in 0888, Now you know how to use the FSUIPC Monitoring facilities, test it yourself. Monitor 0888 on screen (the "AdvDisplay" option, or in the Title bar) and play with E + 1 2 3 4 in various combinations. Doesn't 0888 change to match (F = all 4, whilst 1, 2, 4, 8 are individual single engines, and so on)? If all you need is a hotkey or control to set 0888 back to F (or more probably 7 for a 727), then I could add one. Basically it would do the same as E + 1 2 3 4 should or does do. I don't remember that not working with 4 engines -- I never flew a 727 in FS2002 so I wouldn't know about 3 -- but I thought it worked okay with the 747. I'm surprised. I'll just go try it. Well, I've not got a 747 installed in the copy of FS2002 on this machine, but the Concorde has 4 engines, and so far, no amount of selecting and re-selecting with combinations of E followed by 1, 2, 3, or 4 have failed to select the correct engines and let me adjust their throttles. Are you sure this is not just the problem trying to use this by pressing all the keys together? That would be a keyboard matrix problem. But you don't need to do that. Once you press E then the 1, 2, 3, 4 keys 'belong' as engine numbers. There's not even a time-out. They stay as selectors until you press some other key, or E again to restart the selection. This has always been the case as far back as I can remember. What about FS2004, or aren't you using that yet? Regards, Pete

Sounds good. I think Marc's pretty busy though (aren't we all :) ), so it may take a while. Well I was in touch with them during the Beta phase of FS2004 development, of course. But, although individuals like to be as helpful as they can, they are under very tight restrictions on what they can release. There's a strict policy of releasing information only through the SDKs, which, judging by past efforts, are quite good for some things, but very poor for trying to get inside FS and do things Microsoft haven't planned for. If there ever is a weather SDK I will be the first to rejoice, as it's been a complete headache for over four years now! Thanks, Pete

Thanks for the logs and things. I am now a bit puzzled. I see from the FSUIPC INI file that you only have one throttle. The "throttle sync" facility was designed to synchronise multiple throttles using the input from one, but if you only have one in the first place how are you managing to get the throttles out of sync? I think this may be the cause of your problem. It is actually not doing anything for you except changing a throttle input with no reverse into one with reverse, which you clearly do not want. Only the separate throttle inputs from FS come with a reverse range. Maybe there's something I should change, and I will check this, but first I need to understand why you are using the facility and what you hope to gain with it. So far, it only looks like I need to be more explicit with the documentation, but I am open to other ideas when I understand what you are wanting to do. Thanks, Pete

Hmmm. There's no recalibration done -- I don't know how that's happening. As I said, all it does is copy the current Throttle 1 input value and send it to FS as the common throttle value, after setting the Engine mask to all engines. Just those two lines of code, that's all. It's probably one of the simplest functions in FSUIPC. Incidentally, if it is getting a full reverse (negative) value on one of the throttle 1 inputs (either the normal generic throttle or the specific throttle 1 input) then maybe you have an assignment you didn't know about? Have you checked the FS assignments for any spurious assignment to a throttle control anywhere? If so, delete all those you are not using. You don't say what sort of throttle configuration you've got set up so I couldn't hazard any better guess yet I'm afraid. How many throttle inputs have you got? How are you assigning them? Are you using any of FSUIPC's mapping facilities, or calibrations? Maybe if you send anything you ought to include your FSUIPC INI if so. Regards, Pete

There are some rather unfriendly folks about who delight in blaming FSUIPC for problems, and flame here even though they've not even paid for a full registered copy of FSUIPC. It is upsetting me greatly, and making me very averse to trying to help even if I could. Of course, if I thought FSUIPC had anything to do with it, I'd be slaving away at all hours trying to work it out until it was fixed. I always have been very attentive to problems and never like to see anything wrong in any of my programs. Anyone who knows me and my work over the last six or more years will fully realise that. Let's look at my situation with respect to the accusations that it is FSUIPC which causes black screen hangs in FS2004 when the user switches modes from minimised to full screen, or windowed or maximised, or is it vice versa? (Sorry I am not sure of all the possibilities here). I have, at present, FS2004 installed on three PCs: 1. A P4 2.0GHz with an nVidia Ti 4400 video card and some oldish nVidia drivers, with Windows XP Pro. 2. An Athlon 1800+ with a WinFast-made nVidia Ti 4600 video card with Winfast drivers 4351 which I assume are based on nVidia 43.51 version. This PC is running Win98SE. 3. A P4 3.2GHz with a Matrox Parhelia video card and their latest 1.04 drivers. This is on Windows XP Home. Now, of these, and apart from the external "heavy rain" problem found and fixed recently, the only time I've had black screen hangs in FS2004 was when switching modes with earlier Parhelia drivers on PC #3. Since version 1.04 drivers I've not seen this happen. During the FS2004 Beta periods, and before there was even an FSUIPC to install, the same sorts of black screens were occurring on both the PCs I had FS2004 installed on then. Others in the Beta were getting them. But gradually all of us settled on drivers which seemed to fix the problem. There are circumstances which obviously make it more likely that folks will be switching video modes in FS2004. Notably, these are when running applications which interface to FS through FSUIPC. It is obviously very difficult to carry out the exact same sequences without FSUIPC installed, since its very presence changes what those applications do and therefore the timing and sequence of events thereafter. So, it is a very difficult situstion to resolve. It is easy for folks to blame FSUIPC, and it is almost bound to look like the "common factor". I am willing to investigate this and see if there are any steps I can actually take, inside FSUIPC, to minimise or even eliminate the possibility of these crashes. If I can, perhaps, detect the change in video state and try to prevent some things from happening whilst the video processes are on-going, then maybe this will hlep. I don't know what states I'm looking for, nor what things should be prevented, but I can perhaps experiment. The video parts of FS and DX are really totally foreign to me, I have never been involved with them at all. For this I could really do with being able to reproduce the problem, consistently, here, on one or other of my PCs. So, can anyone give me EXACT step-by-step instructions on how exactly to make these hangs happen, if not with 100% certainty, at least with a very good chance? Do I need specific drivers? Which of my three PCs look the best candidates? Otherwise, I want some registered, friendly and reasonably technically-minded user, who CAN reproduce the problem regularly without trouble, to volunteer for some tests. Maybe together we can find some compromise solution. Who knows. Just in case this is confusing anyone, please note that I still remain 100% convinced that it is NOT FSUIPC wihch is causing the problem, it is something related to activities inside FS during its video re-construction phase, which is causing some corruption. It could be a DirectX bug or an FS bug or a Video Driver bug, but whatever it is, it is being exacerbated by something in the interaction between the FSUIPC application and FSUIPC. If I can somehow avoid whatever it is that is upsetting things, for the duration of the video re-draw (if I can detect it), then maybe we can overcome the problem. Thanks for reading this far. Regards, Pete

All throttle sync does is set the normal FS engine select mask (the one affected by the E + 1 2 3 4 keypresses) to select all engines, and send any throttle 1 input to FS as the generic all-engine throttle value. That's it. It doesn't invent any new values, do any calibration, nothing. It is realy simple and hasn't changed since first implemented. I really have no idea how your throttles are connected or why they are going wrong in that way, but you could try logging the throttle input settings and results, using the new Monitoring facilities in FSUIPC 3 -- see the logging page. If you've not got the SDK, these are the locations (in hex, as used in the Monitor) which may be relevant: 0888 (U8), selected engines mask 3330 (S16). throttle 1 axis value 088C (S16). throttle 1 setting 0924 (S16), throttle 2 setting You can monitor these on screen, and also log them, but in the latter case if you plan on sending it to me please keep it short or edit the relevant parts. Regards, Pete

I hope someone might see this and jump in and help you, but I'm afraid multiplayer is one area (of many, I hasten to add :) ) I know absolutely nothing about. FSUIPC and WideFS don't come into it at all. I do know that multiplayer is not quite the same on FS2004 as it was on FS2002 -- the protocol has changed somewhat -- but I don't know if this explains your problem or not. Sorry. But maybe Jose will see the message. He pops in here now and then. Regards, Pete

I think it did have the 'new' label when it when it was new, nearly two months ago now, but I wouldn't swear to it. Sorry. Almost everything there has been "new" at least once in the last two months or so. Pete

I don't think Enrico gets around to updating the individual descriptions in each box. He did list FS2004 compatibility at the top. But the definitive guide to versions is my own, here in the Forum announcements. I write these myself and keep them up to date. Regards, Pete

Oh, right. Sorry. But that is really a graphics thing -- the added cloud layer graphic so that the mist is visible below when you ascend above it. This was MS's response to the many complaints it got about the ground being too clear below, suddenly, when you ascend out of the mist. It was actually a late addition, and in fact in many (even most in many parts of the world) situations it does make it better. I suppose they cannot win really, whatever they do someone isn't happy. All of the other visibility aspects in FS2004 are surely good -- certainly a big improvement on FS2002 which was dire in my opinion, and more like FS200o which was pretty good in this respect at least. However, that is not the point. The visibility facilities I provide in FSUIPC are better implemented, now, in FS2004, than they ever were in FS2000 or FS2002. You can certainly get rid of most of the ice rink effects be establishing maximum visibilities and some suitable graduation, to keep the mist clearing slowly to a suitable altitude. Yes, because it was so bad in FS2002 and so much better in FS2004. Sorry, but this has been one of my hobby-horses ever since FS2002 came out. It was nearly bad enough to make me go back to FS2000. Well, not exactly, though it may have been a possible easy side result. The main thing I would like to achieve (and this goes back to FS2002 release, not just FS2004) would be to allow the ATC text and responses to be handled by an external program, even via WideFS on a separate PC. To do this I thought I could hook into the routines which display the ATC window and re-direct the messages before it got drawn. Unfortunately I failed to do this in FS2002 and wasted as much time again looking for a way in FS2004. Another possible advantage of finding a way into it would have been to be able to make use of the same neat FS translucent window mechanism for others to use -- eg instructor programs, Squawkbox and Radar Contact type applications, and so on, rather than the current AdvDisplay window. There are so many potential benefits of cracking this area that I've not dismissed it altogether. It's just that I cannot afford to get buried into that and let everything else slide. I will look again when I get time (hah! :) ) Regards, Pete

No, not the near future. It's a horrendous task. To get anything else done with weather at all I think I would have to completely crack the WEATHER.DLL. It's a complete re-write from the FS2000/FS2002 version -- and much more complex. The FS2000 version took me about 9 months to do all the weather things I did in FSUIPC for that. I was lucky nothing much was changed in FS2002. With FS2004 I reckon its a good year's work, and I have other things to do as well. I just can't afford to drop everything else, ignore everything and do only that. To start with it might not get me far. Many of the last few months were completely wasted trying to get somewhere with it. And it isn't fun. Now that FS is almost all black-box closed-in style C++, rather than the nice open C and ASM structures of the past, it's simply horrendous. I expect FS2004 will be my last foray into this stuff. :( Sorry, Pete

I spent a week full time (my full time = 12 hours per day) trying to find out how to intercept the message to that window, so I could divert them completely, as in AdvDisplay, and failed to even get close. I really am not going to be able to devote so much time hacking again through that tortuous Microsoft code to find such things. I really think if it is that important to you you might like to try it yourself? :) It is no fun, and I would certainly not even consider embarking on such a horrendous investigation for something like that. I'm very sorry. You aren't using FSUIPC 3.05 or later then! The visibility smoothing, limits and graduation are FAR better the way I've done them in FS9 than they were in FS2002! To start with, they are universal, and this time really smooth. From what you say, it is obvious you haven't tried them yet. :cry: It's always been mentioned in the documentation. Regards, Pete

Strange. Most all of my flying is with mists. There must be some setting related to the video options, or possibly a function on the video card or its drivers? Maybe the "fogging" tables or something? I'm afraid that this is a bit beyond me. You might want to try posting in the FS2004 forum. Kety Pluta, there is an expert on video card settings and so forth. Regards, Pete

I'm not sure it is possible. How would you think it could be done? Have a little program perhaps which sits waiting for the window to appear, then move it? Wouldn't that be very irritating -- it would appear in its default position then move every time. How does it identify the window? If the title always the same in all language versions of FS? It can't tell by the window calss as they are all "FS98CHILD" I think. Yes, and that works. Sorry, what are you implying? That facility just intercepts attempts to move the windows (any children of FS) and doen't pass them on to be implemented. It doesn't work when Windows is set to show Windows whilst dragging, as by the time it sees the message it is too late. Regards, Pete