Pete Dowson

Oh, thanks. Yes, it has always been writable -- it is used quite a bit, by PM for example. It must be a simple error. I'll fix it for the next update. The same applies to the NAV2 OBS as well, of course, at 0C5E. They use the "VOR1 SET" and "VOR2 SET" FS controls (or "Sim Events" as the official term goes). Thanks & Regards Pete

I hope you've still got that. Looks like I'm going to need some logging done to get to the bottom of this. That's weird. That's a trivial thing for the A/P to deal with. PMDG have offered to look at this from their end for me, if I can provide a reproducible setup. Do you think that is possible? If you save the flight just when it starts to go wrong, will it do the same when you reload that flight (without ASX or whatever running)? If so maybe you could Zip up the FLT + WX + FSSave files and send them to me (petedowson@btconnect.com)? Groan! I increase the "thin layer" removal from 2 metres to 20 metres, and now we find that we get 500' layers also causing problems! At that rate I shall remove all layers! (Actually, that's the way I did wind smoothing back in FS2000 days -- removed all layers and controlled the one layer left. Maybe that's the only way ...:-( ). I need to understand why the smoothing can't cope with this. If you think this is reproducible at 39000, could you do another test with the same weather, please? First edit the FSUIPC4.INI file, adding Debug=Please to the [General] section. In FSX, before you get to the 39000 cruise, say 1000 feet below, sace a Flight, then go to FSUIPC's Logging tab and enable Weather logging AND enter the number '65' in the box for "Extras", below. This sets special debugging logging data on. Carry on the flight with the worsening directional fluctuation until it settles or you leave the level, then go back to the Logging and turn both off again (Extras to 0). Zip up the Log plus the saved FLT, WX, FSSave files and send to petedowson@btconnect.com, please. Ouch! That is nasty. That seems to indicate really bad corruption somewhere in the weather stuff. If you think you can repro this could you apply that Logging above to this phase too, please? Maybe you could save a Flight at the time? Zip up the LOG, FLT + WX + FSSave file and send them to me? Thanks, Regards Pete

Test with a default aircraft first. It is possible that an add-on aircraft implements its own methods for some aspects of the aircraft. Additionally you need to be more specific. I've no idea which FS controls you are trying which "don't work". Name them. Maybe they don't work in FS at all -- try assigning them to a keypress and see if they work then. It is probably totally irrelevant that you are using GoFlight modules. You can use FSUIPC's Logging facilities to see if your buttons/switches/dials are sending the right things to FS. Just go to the Logging tab in FSUIPC options and enable Button logging, and also Event (non-Axis) logging. Operate the buttons you are having problems with and check the entries in the FSUIPC Log file (in the Modules folder). With the Event logging enabled you could also operate these things directly on the aircraft's panel, and see what the panel actually uses, by checking the log afterwards. That way you might find you are using the wrong FS controls and can select the correct ones instead. No. GFDisplay only operates GF displays. Nothing else. Regards Pete

I assume there's some third party software driving the throttles? Else how does do the servos get operated? Sounds like there's a mix-up between how they are driving the throttle controls in FS to start with. There are so many ways of doing it, and I really haven't a clue without more information. Have you talked to the folks who produce/provide the driver? No idea. What do you mean by "some throttle settings"? FSUIPC can be used to assign and calibrate single or multiple throttles, reversers, and map one or two throttles to three or four. But it does none of this without your say-so. There are also throttle sync facilities, but again user-instigated. On the other hand a client program to FSUIPC can do almost anything, whether via axis controls or directly into the thrust lever positions understood by FS, bypassing the axis inputs. It can also disconnect axes as it likes (used for instance for Fly-By-Wire). Project Magenta's MCP uses the direct method, disconnecting and reconnecting the axes appropriately, and even optionally watching them for enough movement to indicate user-instigated auto-A/T disconnection. Without more information it's impossible for me to say anything I'm afraid. Someone associated with your throttle installation must know how it works, what it does. Don't they provide any support at all? You could try using the FSUIPC Logging facilities to see what it does. If it is writing directly to FSUIPC throttle offsets you'd need to have IPC write logging enabled. For the servo operation it is presumably reading them, so that's IPC reads. It may well be using normal axis inputs for throttles, in which case the Axis Event logging. But the problem is you are going to have a HUGE log, and with PM running, really really huge, with most of it being irrelevant. It would take hours and hours of analysis to finds the relevant bits and tie them together. Without some help from whoever designed / built / supplied your quadrant system it is going to be very difficult, near impossible, unless you can make it go wrong with no PM modules running, no other FSUIPC clients at all. THEN it might be worth looking at the log. Regards Pete

I see that there were gusts listed for the surface wind up to 3000 at this time, disappearing. According to your WeatherSet2 pix. Shame there appears to have been no turbulence in either wind or cloud settings to test that aspect. But still, it is very encouraging. Thanks. Regards Pete

Hmm. Strange one, that. The axis assignments tab would be calling stuff in Windows, but nothing in FS9 itself. Regards Pete

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