Pete Dowson

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

There's the problem -- your program is called "AFCAD2", which has not got a Key. It should be called AFCAD. Did you rename it? It is certainly now issued as AFCAD. Rename it and you'll be okay. Regards, Pete

Okay. This "connection refused" error is a message from Windows. All the Windows documentation says about this is: "No connection could be made because the target machine actively refused it." I really don't know enough about Networks to know what could do this, but my first guess would be some sort of firewall, either, for example, the one built into Windows XP, or maybe some add-on protection you have running, like Zonealarm. Hopefully someone else here may have an answer, or you could try Katy Pluta over in the FS2004 Forum. She's helped me on innumerable occasions in the Network area. Regards, Pete

Since the maintenance of the world surrounding the aircraft and the graphics updates this entails is the major part of the work FS is doing, you really have that the wrong way round. FS and its forward views should be on your main, fastest PC. It's the panel parts, and so on, which can be best run on other PCs. See Project Magenta, for instance. They do a nice Airbus setup. Not cheap, but top quality. For multiple FS views on mutliple PCs there's really only WidevieW, by Luciano Napolitano, and that's not available for FS2004 (yet?). For that you'd need a full FS installation on every PC, so they all need to be pretty good. Regards, Pete

If it accepts normal keystrokes and will detect them even when it doesn't have focus, you can do of course do that with both FSUIPC and WideClient already. If neither, then you can't. Roger Wilco couldn't, it isn't the same -- I use direct commands via the message system for PTT in Roger Wilco. That's mch more efficient and really what is needed. Regards, Pete

AhI doubt if the Throttle module has any provision for that extra axis. if it has, I don't know about it and it isn't in the 'spec. But, again, aquestion for PFC. Sorry. You might improve that with better calibration, but, yes, no two pots are the same. But take a look at where the thrust levers are in a real aircraft some time. Unless it's fly-by-wire, they are rarely exactly lined up for the same thrust. You want ease of use, or realism? . I have provided Throttle Sync in the most recent version, in case it is really important, but then you only need to use one lever . Regards, Pete

There is no difference in WideServer between FS9 and FS2002, provided you have registered WideFS. The differences are in FSUIPC. Have you copied your FSUIPC.KEY file from one to the other, or re-registered WideFS in FS2002's copy of FSUIPC? Are you even using a compatible version of FSUIPC in FS2002? Please check all your version numbers (see the list of supported versions near the top of this Forum). If they all all okay, check you are registered (see first option page in FSUIPC). If all that looks good, then, as usual, I need to see WideServer Log and Ini files, and WideClient Log and Ini files. Regards, Pete

There is nothing in FSUIPC which will do this. 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. Pete

If you are happy with it as it was, through the Game Port, then why not leave it be? I don't really see any advantage in making it USB unless you have a PC with no Game Port -- even then you can get game port adapters for USB. The re-wiring for the Throttle Quadrant system was not that hard for me, even with the pedestal-based Jetliner yoke -- the wires had to be fed through the whole stem and resoldered. I would think it not a hard job with your yoke. But why not take advice from PFC themselves? Check their site, send them an email. I think their support is good. Explain your level of competence, electrics and wiring-wise, and see what they advise. I think they would need to send you a new bit of circuit in any case. If it is connected through the game port, then it is assigned in FS's assignments. Just go into FS options-controls-assignments, select the joystick axes, and re-assign it there. It is quite easy. Regards, Pete