Pete Dowson

Do you program your "Button 1" to send a keystroke to Team Speak, using the "Buttons" page in FSUIPC? If so you should be able to apply the same technique via WideFS, but this time making KeySends do the job. You do not specify Keys to be pressed in WideServer! You CAN specify buttons in there, to be converted to KeySend numbers, but it is far easier to program the buttons in FSUIPC. Just program the button to send KeySend 1 when pressed and KeySend 2 when released. Please see the FSUIPC documentation. As far as having those parameters in WideClient.ini, they cannot possibly work! Key code "32" is the Space Bar! That cannot trigger PTT if it is programmed via F12! Please check the key list in the FSUIPC Advanced Guide -- you will see that F12 is keycode 123. Also, you need to refer to the WideFS document. You have to have special shift state values for separate "press" and "release" operations. In your case above KeySend1=32 just means "press space bar and release it" (but still needing ,8 to do that!), whilst the "32,17" in the second one means "press Shift+Space and hold them down"! Why do you want to do that? Please check the document -- you will see that the shift state needs to be 16 to press a key on its own and not release it, and 24 to release it. Regards, Pete

When you say "not connected", what do you mean? If you are connected -- i.e. if the FSUIPC_Reads and Writes work, then you are "connected". Or are you talking about WideClient being connected to WideServer? 0x337E was added for the latter purpose, and you can also of course read values like the FS timer at 0x0310. There's nothing else really. Regards, Pete

The only reason there's an example for FS2000 is that before FS2002 there was no support in FS's configuration for proportional toe brakes. The facilities in FSUIPC allowed the toe brakes to be used, but it needed some assignments manually adjusted in the CFG file. Since version 2002 FS has supported toe brakes properly in any case. There is no need to edit the CFG file -- indeed it is very difficult to do so these days. Please assign and calibrate everything using FS2004's own facilities for this. If you wish, you can then make final and more accurate settings for dead zones and centres in FSUIPC, but you need to get it right in FS first. Regards, Pete

Not sure where you read anything of mine saying that winds don't work. They seem fine here. Are you setting them manually in the FS weather dialogues, or downloading the weather from the Internet? The only thing I've said seems wrong with the downloaded weather is that when you are flying close to several different weather reporting stations, with conflicting wind details, the interpolation used by FS sometimes seems to produce violently changing wind directions instead of any smoothing. Some of this wind shear may well be genuine, but it seems wrong. Regards, Pete

Sorry, I really don't know much about WeatherCentre. Isn't it now taken over by Damian of ActiveSky fame? You will probably need to check with him. A slight stuttering is noticed in FS2004 even when FS itself updates its weather from its own downloads. I don't notice it here, but it probably depends on your machine and its loading. Certainly a one second stutter seems excessive. But also check your cloud settings -- there are some notes on that near the end of the FSUIPC documentation. Regards, Pete

Great! Thanks for letting me know! Pete

Yes, sorry. You have no such options at all if your FSUIPC is unregistered. If this 'fix' does work I will then change the defaults in FSUIPC so that it is =0 normally, and then it should (may?) work for you too. But I am not doing this till I know it is the best solution. BTW 3.06 is the current version. Regards, Pete

But oddly enough, on three different PCs, I've never had a freeze when toggling screen modes at all, not since early FS2004 Betas, and this is without taking any special precautions. Only since a change of motherboard, yesterday, have I been getting a black screen when changing from Windowed to Full Screen mode. And that isn't a freeze as such, either, though I suppose it would look like one. When it happens I can still access the menus, and going into Options-Settings-Display-Hardware and changing something there does recover the situation and give me proper full screen mode correctly operating. What you say is certainly interesting, but perhaps some greater detail from my findings might help. The fix for my particular black window problem, which of course may not be the same as yours, shows that it isn't anything FSUIPC is actually doing, EXCEPT that it is hooking into the main FS window subclass chain. Many add-in DLLs do that. But in FSUIPC, ADVDISPLAY and PFC I delay this subclassing for a number of seconds after FS starts. This seems to be a problem, in FS2004 only. Somehow the subclass chain is getting corrupted and something is getting left out. With my current ability to reproduce the problem at will, I actually eliminated everything FSUIPC was doing, so in fact it loaded but didn't hook anything, didn't do anything, was never called, nothing. Okay, no problem. Then I gradually added things back, one at a time. The only addition to cause a problem was the subclassing, and this still caused a problem even when my subclassed window was bypassed so that it did nothing at all but pass messages on! I experimented further and found that if I do the subclassing immediately my module is initialised then it works fine! So it's the delayed subclassing which is the problem. Why or how I have no idea. The same applied to ADVDISPLAY and PFC.DLL, but none of my other modules. It looks like the same applies to Lago's new "ViMaCore2004" module too, so I've written to them advising of the solution I found. Until I get feedback on the test I've asked folks to do (the "InitiDelay=0" parameter) I won't know if this is just a peculiarity of the problem I've seen and can reproduce, or whether it really does cover the other cases. Hopefully I will get feedback which will clarify this. Perhaps you could try the fix I suggest too (but take care not to get the issue confused by other add-in modules). Thanks! Pete

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