Pete Dowson

But what if it is your program, restarted for some reason? Each fresh process ID looks like a fresh program. Also, I only keep memories of so many then they look fresh again. And as I said, there are other ways of getting the speed -- FS's own GPS for one, Goflight displays another, programs using the other IPC type interfaces, etc etc. WideFs doesn't look like a program to FSUIPC, it is an extension to itself. But if WideFS is running there will be Clients, and any client can read information and FSUIPC has no knowledge at all about Wideclient applications. Do you really think there's any point? If I implemented something like that it would only ever increment, never decrement -- I don't know when a program has finished accessing FSUIPC. How would you interpret it? Pete

The original FSLook works, on the FS PC only, via a special, very inefficient and otherwise unsupported "fiddle" in FSUIPC. I did this only to help Gauge programmers, in the early days. FSLook2 is merely using the normal FS offsets, those from the 2nd table in the Programmers' Guide. Anyone can do that. In that sense it is a variation on FSInterrogate. No, because it is far more efficient to do it via the offset mapping method, and this provides far more opportunities to get desired data. Furthermore the offset method works with WideFs. There's no way any token reading is ever going to be efficient on a Network the way that WideFS is. I don't think any of FDSConnections actual code is from FSUIPC. You presumably mean the code to interface to it? That is a published interface. It isn't the most efficient way to do it, but it is used because it was used by so many programs on FS95 and FS98, with FSUIPC's predecessors. There's nothing wrong with other programs supporting the same interface. I hope that the competition is so good by the time FS2006 comes out that I can retire from all this and get on with something else, so ...good luck to them! :) Regards, Pete

Nice one Frank! :lol:

Not really. As far as FSUIPC is concerned each access is a unique event. It can, for the purposes of accreditation checking, investigate each and every access, but it only does this by the process ID after the first access otherwise it would slow things down too much. Between accesses nothing is known about any program. The communication is all from the application to FSUIPC. So most of the time FS is running there are effectively no FSUIPC users (else only FSUIPC would be running and FS would stop, if you see what I mean). In any case there are several other programs which can and do access data such as airspeed without using FSUIPC. As well as FSConnect there is the GoFlight stuff for instance. Anyway, when you actually fail the ASI, doesn't the airspeed read from FSUIPC also fail? I'm sure, for instance, that when the pitot heat if off and the pitot tube freezes up programs like Project Magenta also show zero airspeed, and PM definitely reads it through FSUIPC. Of course, there's also Ground Speed which effectively by-passes the ASI and can be read in things like PM (thanks really to the INS available in airliners) and of course FS's own GPS gauges, and then there are the cruder estimates of speed available through DME read-outs if you are travelling to or from a VOR/DME. Regards, Pete

I think Squawkbox only uses FSUIPC for certain things, like your aircraft position and the setting of your COM radio. Oh, also setting the weather unless that option is turned off. In that case the FSUIPC connection sounds like it is still working correctly. The details about other aircraft are entirely performed through Multiplayer, FSUIPC isn't involved in that at all. Isn't it "SBRelay" which matches FS2004's Multiplayer to the FS2002 type data expected by Squawkbox? I hope someone who uses SB + SBrelay + FS2004 successfully can jump in and help you here, as it is truly outside my area of involvement and experience. Regards, Pete

Right. So, either it is still as I said, a slight timing difference, or there's something in the way the compiler optimises for P4. However, since the crash doesn't appear to be actually in FSUIPC, the former still sounds the more likely. One timing-related possibility is that some access made by FSUIPC into other parts of FS takes place at a slghtly different time and this has an effect of some thread synchronisation somewhere. I'm still pretty sure it must be video or Direct3D related, but there are so many threads running in FS that tying it down is problematic. Thanks for the answers. I'm none the wiser, really, of course, but I suggest you stay with 3.126 for now, and upgrade to the next version when it is available, and so on, and hope for the best. If we ever do get stuck we'll experiment again like now. Regards, Pete

Yes, that was mostly the circumstances in the old mainframe days. Certainly it was all good training for producing code as free of silly errors as possible. When I was working in the development labs, though, we used to be able to get all-night hands-on sessions. I was involved in developing engineering test programs and operating systems for machines in development, or in the field but under engineering investigation for one reason or another. In other words, the software couldn't trust any of the hardware to work and had to self-check al the way. If you couldn't trust the software either, well :) Regards, Pete

I don't know exactly why. It's just my peculiar capability. Sometimes I wish I could play a musical instrument instead :) I discovered it at the first programming aptitude test I took when looking for a job back in 1963. We had an hour for this paper and I finished it in about 20 minutes and couldn't understand why no one else had. I got 100% (I was informed afterwards). I've always made typo-type mistakes -- this comes from trying to type as fast as I think. I used to stutter for the same reason. Luckily, most typing errors in programs get caught by the compiler --- but not all. Quite a few of the silly mistakes I've made this year have been typos. Otherwise nearly all my mistakes are when modifying existing code to do something extra or different when I've not been near the code for a while. If I misunderstand what I was doing originally then I'm almost bound to mess it up, then spend a while working out why. I think the difference these last few years is just that -- memory. I used to be able to look at a piece of code I'd written years before and remember what it was all about despite my appalling coding style and imbecilic commenting, or more usually the lack of it. Now I think I remember but, evidently quite often, don't. I put it down to erosion of the "little grey cells" by the preponderence of home-made beer (keeps me awake and helps me work all night! I don't use coffee), and the delicious wines we like to have with our meals. Regards, Pete

Well, partly by not sleeping much, partly by not flying at all except to test things (I really must change that!), but mostly by the fact that this is now a full-time (+overtime) jobactually it has been for several years, but I didn't use to get paid for it. There is only one of me, honest, and I have a very understanding wife! Also I code pretty fast. I never even used to make errors either, which helps enormously, but my brain must be getting pickled with all this beer and wine as I make more and more silly mistakes each year these days. Regards, Pete

Okay, thanks. A few more things, though. Can you say which versions of FSUIPC you have used and not got this problem, and which ones with which you have? Are they all user registered, or none? If user regiistered, do you set any options to other than their defaults? What processor is your FS PC. please? I see it is 2.4GHz. Is that a P4? And what is FSUIPC actually being used for in those first 30 seconds? Is there an external FSUIPC application waiting to use it? Are you running FS with internal FSUIPC users, like other add-in DLLs, or Gauges in your cockpit? If you have FS loading up with other than a default cockpit, could you try making the initial flight a standard aircraft/cockpit, so it loads with it, and then switch over after it is all ready? In the past (FS2000, FS2002) starting FS up with a complex highly inter-active cockpit and aircraft was one of the main ways of crashing FS on or soon after loading. Some sort of thread memory interaction I suspect. I've not heard about this a lot on FS2004, but I doubt that such problems are eradicated. Finally, I will try to think of things to try in FSUIPC. Currently it is highly optimised, using the latest MS C compiler, for P4's. The previous version (3.11) used the previous, less capable, compiler, and was just optimised for Pentium class processors only. I don't see this will make crashes in FSUIPC any more or less likely, but it is sure to change the timing -- for the better, I would hope. I always strive to achieve nil impact on FS performance. Anyway, I could make a compiled version with the less competent optimisation and send you it to try too. I doubt if anything like this will solve the problem, just possibly avoid it. It would be better to solve it if possible, as otherwise it will just recur later after some other change. By the way, it was because of the difficulty of getting decent diagnostic information from WinXP, especially with FS2004's SafeDisk protection in operation, that I added code to FSUIPC to trap any and all errors occurring in its own code which would otherwise crash FS. These traps have been in since version 3 was released, and they are still in place. If you look at the FSUIPC.LOG file (which is now always produced) and see any crashes reported there, I'd like to see them -- the data logged includes code locations and register details. If you never see any such reports in its logs, but still get crashes, they aren't actually occurring inside FSUIPC's code. Regards, Pete

I know there are lots of folks with problems with FS2004. But they are not necessarily specifically related to FSUIPC. You can find such reports from folks who don't even use any of my modules. It's just that I get the blame first from those that do. Don't feel stupid. I am the same. :? I cannot get DrWatson reports from many crashes in FS2004 on Windows XP. Even when I do they are rarely at all related to anything FSUIPC is doing. Yes, but apart from it being "ReportErrors" not "errorreports", I'm not even sure it works properly in FS2004 as it has done in previous releases. I think that SafeDisk protection stuff gets in the way. :( DrWatson never captures anything on a system freeze in any case, it needs to actually crash to the desktop with an error message box. Sometimes, if the system really crashes hard, Windows CP tells you about it when it re-boots, sometimes with the module name (invariably a part of the video drivers or DirectX in my experience). I know. I think WindowsXP has messed all that stuff up. I haven't figured it out either yet. From what I read about the "new" system, running DrWatson is merely a way of setting what you want dumped and where to put it. It seems WindowsXP thinks it is making these dumps in any case, but so far I've never found the ones I think ought to be there! :( Perhaps the chap who did manage to make a DrWatson and send it to me can tell us how he did it, please, and where he found it? (However, I think he was using Windows 2000, where, indeed, I did use to be able to get dumps). If I can find out how to do it reliably on FS2004 in Windows XP, I will certainly tell you (and I'll update my documentation). But I don't think you are likely to ever get it with the sort of crash you are talking about. Windows XP is heavily protected against exactly the sort of problem you are getting. Nothing at normal user application level is supposed to be able to crash the system like that, in such a way that you have to reset/re-boot. The only things that can do that are low level things -- drivers. I think your best course of investigation is likely to be your video drivers, video BIOS settings, things like that. Try different versions, try reducing some settings. Use "DxDiag" (run it from Start-Run) and disable AGP there. If any of these things stop the crash, then you are near finding the cause. Really FSUIPC is not involved with any low level stuff, and certainly not anything video related. Most of the time it is not doing much at all, certainly not until a program starts using it (what program do you have using it in the first 30 seconds?). Whether it happens with one version and not another is not particularly relevant. All that is happening is some slight difference in timing, or arrangement of data in memory, makes some event somewhere more likely to clash with some other. It is easy to blame FSUIPC and folks do it all the time, but it isn't the way to find the answer. A more intensive process of elimination is needed. Regards, Pete

Well, I don't really know everything :D :) :o :( . One example is ActiveSky -- I don't know that well at all, sorry. In general I would recommend leaving most of the FSUIPC options to default, but ActiveSky documentation will probably advise you better in any case. Only in the visibility section would I advise setting some options -- enable the default maximums, the smoothing, the random METAR extension, and the graduated visibility. With FS2004 most of the other weather facilities in FSUIPC are really not so useful and are best left for the weather program to control. Nice picture by the way! :) Regards, Pete

Ahsomething simple really. Well done, and thank you for letting us know! Regards, Pete

Good. the problem must have been somehow related to the prop sync setting in FS then. I'm doing quite well with the other changes in PFC.DLL so I hope to be releasing the official update in about a week. Probably version 1.80. Regards, Pete

I've not heard of "Ground2K4", but it soounds like it needs something called "FSConnect". Maybe it doesn't use FSUIPC, but some other module? Have you checked? Aren't there any instructions with it? Regards, Pete

I think this question referrs to one of the throttle quadrant levers, not to the additional throttle on the yoke. That's why I thought a user defined quadrant might do it. Ahyes. Sorry. :oops: I did read it as if the context was re-use of the throttle on the yoke. Of course, any of the 6 levers can be used for almost any axis-type input. With the latest driver there is even a Flaps assignemtn on which you can calibrate 7 intermediate positions (good for the 737 for example). In the next version there will also be provision for a Spoiler/Speed Brake lever with both Arm and Flight detentes. Thanks for the clarification. I did make the wrong assumption. I'd advise Martin, if he's reading this, to check the PFC User Guide. There's a list of all the things you can assign to the PFC throttle quadrand axes. Regards, Pete

In that case it sounds like it is something to do with the "prop sync" or "throttle sync" facility I put into 1.72, which seems to be prone to misbehaviour. I've changed it all here ready for the next release. Probably the prop sync is enabled in your aircraft, even if you didn't do it yourself. Oddly enough I cannot reproduce anything like it here with 1.72. I can see no possibly reason why full forward thrust cannot be obtained, even if the idle position does appear to give reverse. I'll send you test version 1.73 to try. Let me know how that goes. And I'd really still love to know what actual output values you are seeing in the calibration screen, because for reverse it just has to go negative! Well the Baron doesn't have reverse but the King Air is a turbo-prop and has reverse both on throttle and propeller pitch. I see. And what are the calibrate output values showing in the calibration dialogue? It's those that are important for me to know, please. Regards, Pete

Not just weather from add-on weather programs, also FS's own downloaded weather. Because I've been unable to find out how to get to the current localised weather. I can read weather at a Metar Station, and write it to a weather station, but the weather experienced at the aircraft is calculated by FS as you fly, and is supposed to be interpolated from the nearest so-many stations. It used to be only 3 staations in FS2002 and FS2000, and I could work out which ones -- in FS2004 is it more like 30, or even more, I think, and I can't locate them and even if I could I wouldn't know how to "fix" them. I think the interpolation in FS is faulty. It should be reasonably smooth, but it seems it gets the directions screwed up quite often -- 180 degrees out being apparently the commonest error. The interpolation in wind speeds doesn't seem to be at fault as far as I've found or seen reported. Ah, but it doesn't intercept or control the wind. I wish it could. When and if I find a way to do that, I will do it. At present I can only do it for visibility. The problem is that the FS code in WEATHER.DLL is about the most diabolically convoluted stuff I've ever seen. FS2000 and FS2002 were a doddle by comparison. It's a result of all this encapsulated polymorphed multi-inherited severely sub-classed object-oriented C++ stuff they use these days. I'm just a poor old procedural programmer, used to low level assembly code stuff (since I started in 1963) but nothing like this. It took me several months of tracking doggedly through heaps of disassembled code just to get what we've got now. And I can tell you I gave up several times. I was going to chuck it all in! I may dive in again sometime, but when I do there'll be precious little else I will be able to do at the same time. And it may be pointless. I really hate being non-productive and after a few days of laboriously getting nowhere I get very very depressed. So mostly I implement things I can do, those things on my list that folks have requested that are at least possible. Regards. Pete

You are a bit too quick. The author applied only on Friday, It will be sorted out this week. Regards, Pete

(This thread is getting confusing. I write an answer to one person after analysing the information supplied, and I get a complaint from someone else in response. Well...) Remember, you yourself said "it looks like a graphics problem"? FSUIPC has nothing whatsoever to do with graphics. That's why I answered you in that way. But I also said, if you refer back: "It sounds like a potential problem which subtle timing differences have avoided so far. Without many more details I really have no chance to even start investigating." Isn't that understandable? If you want me to try to ascertain why you are having problems I will need a lot more information than you just telling me FS crashes, I'm afraid. I could at least do with knowing what the details are from the crash report, and a DrWatson if possible. I'd also need to know your system details, what else you are running -- especially what you are doing in that first 30 seconds -- and so on. Sorry, no. There will be a version 3.13 in due course, then a 3.14 etc etc etc. I cannot and will not go backwards. That is futile. If there is any problem in FSUIPC it must be resolved. However, the only other crash reported is most certainly a video-related problem, after analysing the data provided. With yours I really have no idea as you've not yet told me anything useful. Sorry. Regards, Pete

A beta too? Was this program ever released? Why not get the latest Beta if you are on the Beta list? Pete

No, there is no change in that and hasn't been for years. When you say "when the two throttles are at the minimum possition the plan is in Reverse mode when the throttle are in the middle the throttle ( in FS2004 ) is at iddle", what aircraft are you flying? There is no reverse range for the twin props for which you would use the standard twin prop quadrant. If you are seeing a reverse range in the aircraft (check FS's own throttle quadrant) you should be using the turbo-ptop selection. Look at the "scaled output" values shown in the PFC DLL options. They should show 0 for idle (the lever pulled right back) and 16384 for max thrust (the lever pushed full forward). These are the correct values for the ful forward range in FS. To get reverse the output has to go negative. PFC sends these values direct to FS, so there's really no other software getting in the way to change that. I can only think that you have the quadrant selection set to "automatic" and you are loading a turbo-prop aircraft (or at least one that identifies itself as one), and therefore, although you think you are using the normal twin prop selection in PFC DLL, it is actually poicking the turbo one, which does have reverse, and which you probably haven't calibrated. The fact that you cannot set full thrust also indicates that you are actually using an uncalibrated quadrant selection, since the FS values for full throttle are 16384 across the range. Regards, Pete

Yes. If the throttle on this yoke cabinet is detected by the digital circuitry in the digital throttle cabinet then yes, assuming it produced one of the same codes to the PC as one of the 6 standard throttle quadrant levers. But if it did the latter, what happens to the duplicated axis? If it is recognised but produces a separate unique code, then PFC DLL won't currently recognise it because it is certainly not specified. The axes PFC DLL sees are the 6 on the quadrant, aileron, elevator, rudder, left brake and right brake. These are the ones specified. My betting is that the extra throttle axis isn't recognised in the current firmware. But all this is a question for PFC, not I. I can only implement the software, it is they who design and make the hardware and firmware. Regards, Pete

You need to calibrate the correct twin prop quadrant to give you the correct results. Each quadrant you use (or each mode) has a separate set of calibrations. You need to calibrate each one separately. Please see the PFC DLL user Guide, which you will find inside the PFC DLL Zip! For twin prop you will see that there are three styles to select from, two of the normal style, where the Throttle calibrations have no centre nor reverse, and the turboprop style, where both throttles and propeller pitch lervers have reverse zones. The calibration is obviously different for each. Please select the correct ones. You can also tell the difference from the fact that the Throttle names (at the top of the calibration columns) have "R1" or "R2" at the end, not just the engine number. Regards, Pete

Okay, I've looked through the DrWatson file you sent. It shows rather a sorry collection of crashes, dating back several months. There were 4 from FS2002, then these (in order): 1 in Explorer 1 in Paintshop Pro 1 in Photoshop Album 1 in "FSPS" ? 1 in "DAP" ? 1 in DivX Player 2.0 1 in ATICDWIZ 1 in NR2003 2 in Acrobat 2 in FS9 (in the Base code) 1 in a Setup program 1 in FS9, without FSUIPC 3.125 (on 12th Oct), in a Gauge by the look Another 1 in PaintShop Pro 2 in NetGnd2 something thenthe 7 or 8 in FS9 with FSUIPC 3.125, all identical, with an Acrobat crash mixed in for good measure. With so many crashes in so many applications, aren't you a little worried about your system anyway? Or do you have explanations for all these? With reference to the FS ones, I think you have some video driver problems, or AGP, or overheating. It is certainly video related. All the crashes are in FS's HG2D module (graphics, 2D stuff -- polygons and cockpits), all in exactly the same place, and not in any path where FSUIPC is involved. Try changing the FS Options-Settings-Display-Hardware option "render to texture" -- set it off if it is on, on if off. Try reducing some of the sliders to ease the loading on the video side. I would suggest in any case trying to severely reduce the number of processes you have running. I know Windows is responsible for a lot of them, but 53 or so does seem rather excessive, especially considering you reported your processor as only a Pentium 2 running at 995 MHz. As it is this is severely under-powered for FS2004 I'm afraid. With so many processes I think you are asking for real trouble. I suppose you could say that a registered version of FSUIPC running was the "straw that broke the camel's back". I've really tried to find some evidence that FSUIPC itself could be responsible for this, but it isn't. Sorry. By all means try FSUIPC with "minimum weather defaults" selected in its first options page, but also investigate updated video drivers, changing AGP aperture settings or other BIOS things, and checking the air circulation around your video card. Regards, Pete