Pete Dowson

Are you in flight mode, with the menu starting "Flights ..."? FSUIPC cannot start until you get past the opening selections. If so, and there is still no "modules" folder, either you haaven't installed FSUIPC to the correct FS Modules folder, or you are running some windows' interfering program like Windows Blinds. Regards, Pete

Okay. There are 29 crashes reported in that file, only the last few seem to be relevant. Ah, but using 3.11 unregistered, you would have been using zero of the "settings". The fact that you use 3.125 registered, compared to 3.11 unregistered is significant. Since with an unregistered FSUIPC none of the user options would have done anything, whilst in the rtegistered version they all operate (albeit in default settings), is the main point. I'll look at the dumps you sent tomorrow, but none are actually in FSUIPC, nor at first glance or caused directly by FSUIPC. I'll know more tomorrow some time. Meanwhile, please set "minimum weather defaults" in the first FSUIPC options page and let me know. It looks like a graphics problem and the attempts by FSUIPC to enhance the weather slightly may be exacerbating the problem. What external FSUIPC applications are you using? I don't recognise any of the names listed in the DrWatson, and you have a HUGE list of aplication programs running: *----> Task List <----* 0 Idle.exe 8 System.exe 228 smss.exe 252 csrss.exe 272 winlogon.exe 300 services.exe 312 lsass.exe 496 svchost.exe 528 spoolsv.exe 556 ccEvtMgr.exe 640 Ati2evxx.exe 668 svchost.exe 684 GEARSec.exe 716 navapsvc.exe 736 NPROTECT.exe 796 regsvc.exe 824 r_server.exe 904 MSTask.exe 932 stisvc.exe 1004 ntstart.exe 1028 trayman.exe 1048 PQV2iSvc.exe 1072 vfdrv32.exe 1084 WinMgmt.exe 1096 WinVNC.exe 424 svchost.exe 1280 Explorer.exe 1440 TotRecSched.exe 1396 LVCOMS.exe 1424 CTHELPER.exe 1452 ccApp.exe 840 WinPatrol.exe 1492 atiptaxx.exe 1504 realsched.exe 1512 SETI@home.exe 852 SECCOPY.exe 1524 TextAloudMP3.ex.exe 1532 SpellMagic.exe 1556 acrotray.exe 1548 appbar.exe 1568 Icondesk.exe 1576 fs20.exe 1592 KeyText.exe 1680 rnathchk.exe 1552 SYSTRA~1.exe 696 ntvdm.exe 1376 WISPTIS.exe 1728 FS9.exe 1852 drwtsn32.exe Which of these is using FSUIPC? Can't you reduce the number of background processes a bit? FS9 is notoriously precarious in such overcrowded PCs! Try the freeware "EndItAll". Thanks, Pete

Ah, I never saw the one with the throttle before. It does say, just below the picture: "If used in conjunction with a PFC flight console: These yokes can be specially wired to work with our hardware controller found only in our Flight Consoles and Throttle Quadrant Console." Has yours been so re-wired? I had a Jetliner yoke which I had to rewire for this. I think you need to talk to PFC about it. Regards, Pete

"Cabinet Digital"? Is this a PFC product? As far as I know, all current PFC digital gear, connected via COM port, is usable AND programmable through my PFC.DLL. Maybe some earlier stuff is only supported through their own drivers, I do not know. PFC.DLL supports all the switches and buttons that are supported by the current digital control boards inside PFC systems. Furthermore, they are made visible to FSUIPC too, for even more flexibility. I don't know what equipment you are using, but if it is PFC and current, then everything should work as far as I know. If not you need to contact PFC to see what is going on. You have a throttle built into the Yoke? This is not a piece of equipment I am familiar with then, sorry. You need to get support from the makers. Regards, Pete

Just coincidence. TrafficLook has nothing to do with it, it writes nothing to FS at all. It is only reading information which is being maintained by FS in any case. Pete

Yes, I think you are lucky, just as I am. I think also it helps keeping the flights short. The global weather (on which the FSUIPC wind smoothing does operate okay) stays relevant for a while after being set, it just gradually becomes "locaslised" and then beyond FSUIPC's reach. You can get the weather program to then restore it all, and carry on, but it's annoying to have to do that. I have it on good authority that the next version of ActiveWeather (version 2 I think), which uses local weather like the current FSMeteo, will smooth the wind data in advance, via an option which I think is called "Route-Based Wind Smoothing". Regards, Pete

Well, that's indeed most unusual because most find it fine, most of the time. It probably depends where you fly and the reliability of the weather station reports nearby. I think the extreme variability comes from nearby weather stations filing reports at different times. Why not check with the author about progress with the new version? I don't know how he's dealing with this, but I have suggested that some smoothing might be applied before the data is sent to FS. You mean you never get any winds with your Jeppesen downloads? Have you left the option for upper winds turned off? If so, then certainly you will not get any winds at cruise levels. Not realistic at all. Whenever I've used FS downloaded weather (and with the upper winds obtained as well), it is okay in sparse areas, but fly somewhere where there are multiple weather stations, like Chicago area, and the wind shear (180 degree reversals even) can be quite frequent. I think this is a problem partly of the data and partly of FS's poor internal smoothing. I expect it varies a great deal from download to download, just as it must with ActiveSky or, indeed, FSMeteo. With what weather sources? The facilities in FSUIPC just do not operate with localised weather at all. I have no way of getting to it. And, unfortuately, all global weather becomes localised after a time, as discussed in the references I gave you. Regards, Pete

As it says in the FSUIPC documentation, its wind smoothing only works for global weather. Please see the "Important" announcement at the top of the forum, or the similar section about FS2004 global weather problems near the end of the FSUIPC documentation. I have actually come to the conclusion than the smoothing options in FSUIPC are really of no practical application in FS2004, except the visibility one. Only the visibility works well, because I found ways to by-pass FS's processing for visibility control. I've not actually removed the facilities (yet!) in the hope that I can make them work better in the future, but it isn't looking promising I'm afraid. Meanwhile, both FSMeteo and ActiveSky authors are hard at work trying to solve the problems with more control over the way the original data is processed before being sent to FS. I think the newer releases, as they appear, will be superior, even if they may not quite fully solve wind shear problems. Just as an aside, you should know that severe wind reversal problems can and do occur quite often just using native FS2004 weather downloading facilities as well. It isn't by any means a fault of the weather programs or of FSUIPC. There is something wrong in the FS2004 weather interpolation algorithms, I'm afraid. Regards, Pete

2500 meters? FSmeteo certainly should not be setting unlimited in that case. What does the author say? 9999 metres (Europe) or 10SM (America) are auto-visibility values which just mean "more than" the stated vis. In that case it is best to use FSUIPCs "extend METAR max", which will give you a random value above that. FSMeteo just sends data to FSUIPC. FSUIPC sends it to FS. Either or both. Sorry, all the options are for personal choices. In the UK I tend to keep the maximima quite low, for realism. Elsewhere the preferences would be different. Sorry, this is a question for FSMeteo. I suspect it's an early version of the program you are using, and it is being improved all the time. Regards, Pete

Thanks for letting us know. I hope you manage to sort the problem out! Pete

Okay, that's good! But I will change the coding in GPSout so this shouldn't be necessary in future. I have it on my list. I have a lot of other things too, but I should be able to fit it in before Christmas. Thanks! I'll take a look. Regards, Pete

Hey, that's great. Thanks! I will check for these in FS2004. Is the 'remaining time' in seconds or milliseconds? As a 32-bit integer? I will add these to the programmer's guide. Thanks for finding them! Regards, Pete

Aaaarrrggghhh! Ouch! No, it isn't a typo. It is actually implemented like that! Oh, how horrible! I don't dare fix than now, it will muck up 'button to keypress' assignments or keypress programming. The Hotkey definitions and the Button keypress conversion use 4=ALT, 16=TAB, whilst the Key press programming (the 'input' as you say) uses these bits the other way around. I really must have had a bad hair day when I programmed one of those! Sorry. It'll just have to stay like that now. Stupid. :oops: :oops: :oops: Thank you very much! I surely won't need to make many changes, as your English is pretty good already. :D Regards, Pete

The details are: Write (in one FSUIPC write, or else at least with the AI ID last and in the same Process call): offset 0x2900 --DWORD, the ID of the aircraft (from the TCAS table) offset 0x2904 --DWORD, The FS control (see list of FS2004 controls on http://www.schiratti.com/dowson) offset 0x2908 --32-bit integer, the parameter for the control, if it uses one Not all the controls will do anything. In fact, by experiments to date, not many will do anything. Hopefully none will actually crash anything, but I wouldn't swear to it. I have tried ENGINE AUTO SHUTDOWN and ENGINE AUTO START, and these seem to work. Aircraft deletion can be achieved, and this uses the same mechanism, but set the FS control to 0xFFFF (i.e. 65535). That works and so far I've seen no ill effects (apart from aircraft being zapped of course). You can send several controls one after the other, in the same FSUIPC Process if you like, for the same or different aircraft. FSUIPC takes action when it sees the ID being written, so make sure the other bits are either written at the same time (same FSUIPC Write), or beforehand. Let me know how you get on, please. Regards, Pete

Ah, right. Still, try the revised PFC driver. Maybe you'll find the PFC throttle sync useful, or try the FSUIPC one initially but then switch it off, and save a Flight there and then! Pete

It's an additional control you can assign. there;s no checkbox for it. You'd only be able to use it if you re-programmed a button or switch for it. You mean the FS prop sync I assume. That doesn't mean it isn't enabled. It only means you have no way to see if it is, nor switch it on or off by mouse. The switch is still there, in FS, and may or may not be "on" when you load your Flight. You can check. It'll be the "PropSync" parameter in the [systems.0] section of the .FLT file. I'll send the interim PFC driver (it'll be 1.73, the last stable one I've got -- i.e. one without half-baked new code in it -- but I'm working through a list of things I need to do, and it'll probably get to 1.80 for Release). Regards, Pete

What was the last version you used before 3.125? An EXE file? It should surely just be a ZIP. I would be most reluctant to run an EXE if I received one. Where did you send it? Can you tell me any more about when and how it is crashing? I have no details at all. The data you listed for your PC is all very good, but it tells me nothing about FSUIPC. Regards, Pete

It is most definitely okay here, both on FS2002 and FS2004. I can only think that FS2004 is loading a different run-time library that includes this quirk. Naturally, the standard NMEA sentences should not be "distorted" merely by having difference locale settings, and I should be able to program around this (computing the decimal fractions separately from the units, as I have to already for the Lat/Long figures). But before I make any such changes I'd like to be sure that it is indeed the locale problem which is doing this. So, could you please, temporarily perhaps, set your locale preferences to standard English/American, i.e. numbers using . for decimal point, and then let me know? I'm sure you can change back if you wish afterwards. Thanks, Pete

Sorry, I don't understand what you mean by "Key Input" and "Key Output"? All uses of TAB add 16 (the 24 you use for TAB+X). The value 12 would generate an ALT, not really recommended (as FSUIPC loases control when the Menus open up). This is consistently true here, it doesn't matter what the other key is. Phew! Well done! I must admit my brain is boggling a bit at all this. Would you care to write it up with just a little more explanation as to what you are doing, and why, so I can add it as an example (to boggle other Advanced User's brains too! :) ) in the Advanced Users Guide? With full credit (or blame? :) ) if you like? Thanks for solving it. But I'm still puzzled about your Key press problem. Regards, Pete

A log from the PFC driver would be more relevant I think, but let's see: 1254484 GetRealAddr(24000D72)=01852D7A (orig 2EC8) All these are not useful in this context. You would get a more readable log just enabling IPC read/write, not extra data too. 1254484 WRITEex 0890, 2 bytes: 00 40 1254484 WRITEex 0928, 2 bytes: 00 40 Sets mixture full rich, engines 1 then 2. 1254484 WRITEex 09C0, 2 bytes: 00 00 1254484 WRITEex 0A58, 2 bytes: 00 00 Mixture full lean engines 3 and 4. 1254484 WRITEex 088E, 2 bytes: 6A 3F Prop lever, engine 1, nearly full forward (poor calibration perhaps?) 1254484 WRITEex 0926, 2 bytes: 00 40 Prop lever, Engine 2, full forward. 1254484 WRITEex 09BE, 2 bytes: 00 00 1254484 WRITEex 0A56, 2 bytes: 00 00 Prop levers, engines 3 and 4, off. 1277515 WRITEex 088E, 2 bytes: A7 3D Engine 1 prop lever reduced a little. Well, that's it! Sorry, there are no changes to any throttle settings recorded here. Maybe that's the problem? If you have throttle sync active in the PFC driver it will (in the currently released version) try to set all 6 axes (two throttles, two mixtures, two prop settings) each time any of the Engine 1 set of 3 change. Since there are no throttle settings made yet, the recorded value for the thottle will be zero. This is all done differently in the next version, but the solution in the current one is to (a) not use throttle sync, and (b) ensure prop sync is off in FS. Regards, Pete

Yes, I've got one, though mostly I use the Jetliner Console. That's only for the FSUIPC throttle sync hotkey, which is for throttle controls in FS from game port or USB joysticks. Sorry if it isn't clear enough. The PFC throttle sync is in the PFC.DLL, but it needs fixing. That sounds like the throttle sync or prop sync was enabled in the PFC driver. The FSUIPC options don't operate on the PFC axes - the latter bypasses all that stuff. This is because (a) the PFC axes don't go via the FS joystick assignments, and (b) the FSUIPC throttle sync only operates if you assign a Hot Key to it, and press it. That sounds very much as if the "Prop Sync" was enabled in the aircraft in the earlier instance but not the latter. On request I originally treated FS's Pro Sync like PFC's Throttle Sync, but after similar problems, and not really knowing what other panel makers do with "prop sync", I am separating the facilities and not touching FS's prop sync at all. That sounds like there's another input to FS's throttle somewhere. Either that of your PFC unit is palying up and giving occasional bad returns. If you want to try an interim version of the PFC driver with the throttle sync facility 'fixed', write to me on petedowson@btconnect.com. But meanwhile, if you don't use PFC's throttle sync and make sure FS's prop sync is always off, there should be nothing wrong. I cannot understand your throttles going to idle though, that's suspiciously like alternative inputs somewhere. Regards, Pete

Doesn't it sit on the ground if you specify zero altitude? Regards, Pete

I don't know of a way to detect that easily, offhand, but I've never looked. There's only the recording flag at offset 0760 that I know about. Maybe there's an easy way nearby. Did you try using FSInterrogate to look? I'll add it to my list to look at for the next version, but the list is getting longer and longer. I cannot promise anything. Regards, Pete

That's fine. But we started this with you trying to use separate CFG and INI files altogether. So the whole FS session had one set of button interpretation or another. To replicate that with conditional buttons would be easy enough, and less wasteful of buttons by using a keypress (which you only have to ever use once per session, after loading FS) to select the appropriate interpretation. If you wanted, you could for each such key press, set one flag and clear all the others. It's a lot of lines but then you could change the button configuration at any time. Yes, okay. You are meaning to hold the button, but you want three other cases (not shown) where you are pressing both 6 and 7, or not pressing either, or pressing 7 but not 6. I hadn't realised you wanted all your button modes to be active all the time, even pressing up to 3 buttons at the same timewell, not quite, you have to get the order correct every time unless you've provided multiple versions of these for the other orders of button pressings and releasings. Sounds like for your 4 conditions you need a total of 8 pairs like those above, so you can press 6 or 7 in any order. Actually the two pairs with neither pressed would be identical or even redundant, of course, so that makes 6 pairs. This assumes you "main action" button is always pressed last. Don't see why you'd need to, but go on ... Okay. Now I understand what you are wanting, it starts to make more sense. It doesn't seem at all to relate to the original problem you asked me about, hence my confusion. But I would be concerned about the order of your button operations. Remember that these lines are only scanned when a button changes, and that's the "active" button in the lines, not the conditions. Conditions changing don't do anything, the conditions are simply states which are tested when the active button changes. Doesn't it work the way you thought? Is it simply the order of button operations which is mucking things up? Regards, Pete

But there's no difference in GPSout between FS2002 and FS2004. These sentences haven't been changed since GPSout was first written, several years ago. The track has been shown correctly on many applications for those years. Maybe it is to do with your computer settings? The only thing I can think of is that you have your PC set to use "," for decimal points instead of '.'. Though if that is the case I would have thought someone would have noticed this in the last 5 years of so? Can you check, please. The formatting is definitely correct here, but it does use the MSVC run-time library. I've not known that to change formatting before, but it may well do. And what does it expect? Surely it doesn't expect to receive details of up to 96 targets (FSUIPC's airborne table capacity) over a 4800 bps serial line? I don't know what you are after here. Can you explain more? You might be better writing a separate program to read the TCAS data from FSUIPC and sending it direct. It doesn't sound like anything GPSout should be doing, even if I had the time to fit it in. Regards, Pete