Pete Dowson

Wow! Really? Hi Dave, Yes, really -- with the exception of debuggers (and programs of similar privilege) of course which can do anything they want, almost. All other crashes come about as a result of unexpected and unchecked data input, hardware glitches or other levels in the same process -- i.e. drivers and libraries. This is the whole point of the virtual memory system used in Windows for many years. Each process is in its own little universe. Okay, that's better. No indication from that what is wrong? 3BFA is a read-only value which is computed by FSUIPC from the number of flap positions it gets from the currently loaded aircraft. B737.EXE won't be able to change that (or at least I *think* I write-protected it). 0BDC could conceivably be anything in the range 0-16k. It's used to both control the flaps from a client program and to reflect the position. Can you say how values here could cause a problem, please? The logs I requested should help if all it is are unexpected unchecked offset values. ;-) Best Regards Pete

Wind smoothing on, your choice of values. Don't check (or uncheck) wind "suppress: turbulence, gusts, variance", and uncheck Cloud "suppress turbulence. Set QNH and OAT smoothing to taste. These are on the Miscellaneous tab. Everything else is your choice. Thanks, Pete

FSUIPC 4.234 is now up and waiting for you. The main change is that it tries much harder to eliminate the silly spurious thin wind and temperature layers. Regards Pete

FSUIPC 4.234 is now up and waiting for you. The main change is that it tries much harder to eliminate the silly spurious thin wind and temperature layers. [LATER] I spotted a couple of areas where I could improve things somewhat. So, please move on to version 4.235 for further tests. Regards Pete

FSUIPC 4.234 is now up and waiting for you. The main change is that it tries much harder to eliminate the silly spurious thin wind and temperature layers. [LATER] I spotted a couple of areas where I could improve things somewhat. So, please move on to version 4.235 for further tests. Regards Pete

FSUIPC 4.234 is now up and waiting for you. The main change is that it tries much harder to eliminate the silly spurious thin wind and temperature layers. Regards Pete

I got back earlier than I expected, so FSUIPC 4.234 is now up and waiting for you. The main change is that it tries much harder to eliminate the silly spurious thin wind and temperature layers. Regards Pete

If it is FDC crashing then the error MUST be in FDC. There is no way anything else can make a separate process crash. Possibly this B737.EXE program is writing stuff into FS, via FSUIPC, which is out of some range which FDC can cope with, but it most certainly should not make it crash. The first step to working out what is going on is to find out what Windows says about the FDC crash. Isn't there ano error message? Does it say "access violation" or "overflow" or what? I really think that without the FDC author helping to determine WHY his program crashes, it is going to be almost impossible to make any determination about what is that is wrong and therefore how to get it fixed. The best I can do for you is check the actions of the B737.EXE driver within the first few seconds, up to the approximate elapsed time of the crash. But to avoid complicating matters, I need to to see ONLY the actions of that driver. So, please do this: (a) Make sure NO OTHER FSUIPC programs are running at all. That is nothing of PM, nothing of any add-on aircraft, no oher FSUIPC-using DLLs in Modules folder. (b) Run FS. In the FSUIPC Logging enable IPC Write and IPC Read logging. © Run B737.EXE to the point where it would crash FDC if that were actually running. (d) Close FS, ZIP up the FSUIPC.LOG file and send it to me at petedowson@btconnect.com. That's the main thing. You could then also do exactly the same but run FDC as well, so I can see the difference, but that will be more confusing and useless anyway without that first log. Finally, you could do the same with only FDC, no B737.EXE. Be sure to rename the three logs appropriately. so I know which is which. Never just say "latest version". Folks have said that and actually meant "the latest version I have seen", and were using one a year out of date. ALL my software modules have version numbers. Please quote them. Regards Pete

Autogen too, eh? That's a real killer on my current machines. Your results bode well then for the PC I have my eye on. Are you using Vista32 or 64? Regards Pete

Don't know. More likely that whatever was stopping it terminating relinquished. Regards Pete

I wasn't really thinking of checking for equality! Even FSUIPC itself couldn't do that -- the values in FS are floating point, so you always check for "within a range" or "nearly". Can pmSounds not simply scan for "greater than", or would that make it repeat the announcement all the time? If so can it check for a range? Either way I've found (with my now discontinued Esounds package) that you need to check for a LOWER value than the announced value because of the time lag. Provided you'd set and confirm your V-speeds on the CDU I thought PM did say "V1""rotate" at the right times anyway. Isn't that coming from pmSounds? I'm using the whole suite, mind, pmSounds, pmSystems, MCP, GC, CDU, RCDU. Maybe it's something else? Try asking in the PM Forums on http://www.mycockpit.org/forums Regards Pete

I'm planning a new PC at present, and I'm looking at overclocking -- not by me, mind. I want it done by the supplier so I can blame them! ;-). What's the clock speed you got up to, then? The supplier I'm looking at uses water cooling and gets a Quad up to 3.75. I've read you can push to 4 GHz. Is the 4Gb memory fully used? I thought you could only use 3 Gb with 32-bit windows -- 2Gb for programs and the rest for Windows? I'm seriously thinking of asking for Vista64. I don't much like Vista, but reports seem to suggest that the 64-bit version is solid. It'd be up to my supplier to make sure they had the drivers, obviously. Best Regards Pete

That's excellent news! Thanks! Such close layering is the result of the weather interpolation bug which is causing all these problems in the first place. I have got code built in which, when it reads station weather with spurious layers, tries to remove them and writes the corrected stuff back. But to avoid a performance hit it doesn't do this too often, and it has to cycle around all of the surrounding WX stations before it will "correct" the weather at your position -- by which time you might have moved into another set. When I added the wind smoothing I reduced the frequency with which i do these corrections. Maybe I should restore it, but I am always concerned with performance. Additionally, it may be that the gap between those layers (10 feet) escaped my net. I don't think so, but I'll check... ... Ah, yes. It does slip through. I remove layers up to 100 METRES thick if their windspeed and direction are reasonably close, but currently I only remove layers less than 2 metres thick for such different winds as yours. I think I made this decision based on observation of lots of examples which had such thin spurious layers. Evidently I didn't review enough, or maybe it's a result of the way ASX is setting things. I'll increase the any-wind removal check to catch layers of 20 metres or less. I think that should do it. I'll do the same with the temperature layers which suffer similarly. What puzzles me, though, is why the winds produced by this silly thin layer weren't smoothed by my wind smoothing? Before I remove the very thin layers I shall need to do some experiments I think. I'm afraid I'm out most of tomorrow (Monday), so the next improved version will probably be Tuesday. Regards Pete

OK. Thanks for letting us know! Pete

I see you have all the turbulence and other wind effects disabled, so your smooth wind results are understandable now. I'm hoping that with the changes in 4.233, which you are using, you won't really need to do that. I see you also aren't using the Temperature smoothing. Did you find your TAT jumping about like others? I can't see whether you are using the QNH smoothing or not. Nice set of pix. Thanks! The frame rates look okay too. May I inquire as to what hardware you are using? WinXP or Vista? Regards Pete

I tend to add answers to all questions asked in the past to the documentation of the programs. Since the documentation is with them and really needs to be read before purchase and use, it seems the best way. No, only buttons and switches. Analogue axes are not supported in that way, though a program could certainly be written to do this via WideFS. The reason I never added such is not just a lack of demand (you are only about the third person to ask in the 10+ year life of WideFS so far), it is aslo that it doesn't work very well, at least for the main flight controls. The little bit of extra latency you get due to the network makes flying that much more difficult. You tend to over control. It would be okay for other axes no doubt, but it simply isn't worth it these days, when USB connections and extensions and hubs are so plentiful and easy to deal with. It was different in the "old days" when you only had a measly one or two game ports with up to 4 axes each, at most. (And you only got two game ports with some expensive add-on cards). That would have been justification for such an implementation, merely to multiply the number of connections. And in fact I did implement it via my EPIC drivers at the time -- of course that was with less heavyweight operating systems. I can't think of any off-hand. Old game port devices can be connected through very cheap game port-USB adapters, and anything with the few buttons and axes legacy devices had will be supported easily by one or other of the default generic drivers. There might be some programs already around which will do it. I don't know. Maybe if you ask on the cockpit builder's forum you might get lucky? Otherwise it would mean writing a little program to do it. Oh, BTW, I hear that the Microsoft XBOX game console can be used as a game controller for FS, or at least for FSX. Not so sure about FS9. Regards Pete

Ah, you want to do it all in FSUIPC? It isn't designed for such programming. FSUIPC is the conduit for other programs, that is its prime purpose. You can have conditions on button actions or keyboard actions, and you can even make "virtual" buttons operate when other buttons or keys are used. But there is no programming facility, other than the regular one of you writing a program, to scan offsets for you and take actions. You can easily do what you want in pmSystems logics. Do you use that? Else, isn't there an offset condition test facility in pmSounds? How were you going to test a bit in 66C0 in any case? If you can do that, can't you compare the IAS offset with a value directly? Regards Pete

The multiple cases of FSUIPC error can arise from having a hung (or not-quite-terminated) copy of FS still loaded in memory. The duplicate check finds the other one, which must have been still active. You cannot have two copies of FSUIPC running at the same time as applications will not know which to attach to. After any crash or hang, just because the FS window disappears don't assume that FS is not still running, albeit in a completely disabled state. Best thing to do is use CTRL_ALT_DEL to bring up the Task Manager, select Processes, find the FS9.EXE process and forcibly delete it. From your second message: I doubt if the registry cleaner did it as FSUIPC doesn't use the registry. More likely that some time after the problem first occurred the stalled FS9.EXE process did terminate. Sometimes it does take a while -- if you are using WideFS, for instance, the process isn't actually killed until WideServer has told all its clients. Other add-ons also often do tidy ups which take time. On your main problem, in FS9 I think most out-of-memory errors occur because of Landclass scenery files placed incorrectly. You may have to go through a process of elimination to find the layer responsible. However there is, or used to be, a program which could check this for you. Sorry I don't recall the name. Best to ask on the FS2004 forum. Regards Pete

Yes. 66C0-66FF are available for any private use, as needed. I don't allocate those to any add-on or FS function. Regards Pete

I suspect that's pretty realistic. In severely turbulent conditions I'm pretty sure the pilot has to take control -- or if it looks like continuing long, seeking avoidance by climbing or descending (with permission, of course). Yes, okay, but I may just have fixed it in 4.233, so please give that a whirl for a while first -- with all suppressions off please, and preferably avoiding "Severe" weather for now! ;-) Regards Pete

Odd, it's always worked in FS2004 and before. I'll try here with the latest ... ... It is certainly okay with 3.783, from the Other Downloads announcement above. One thing I just noticed though. If you read it first it contains 0. In other words it isn't a STATUS indicator, that's 31F0. If your software only sends something if it is different to what you are reading (for instance like pmSystems) then you'll need to write 3 first, then 0. But writing 0 does work, even when it is 0. I might fix it so it reflects the status too, though that shouldn't be necessary. Regards Pete

On the basis of some feedback regarding turbulence, especially in clouds, I've made some changes to the way the turbulence is handled. Please see if version 4.233, now available in the FSX Downloads announcement, is better. Regards Pete

As an experiment, I've made some changes to the way the turbulence is handled. Please see if version 4.233, now available in the FSX Downloads announcement, is better. Regards Pete

I've done some experiments and made some changes to the way the turbulence is handled. Please see if version 4.233, now available in the FSX Downloads announcement, is better. Regards Pete

I've made some changes to the way the turbulence is handled. Please see if version 4.233, now available in the FSX Downloads announcement, is better. Regards Pete