Pete Dowson

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

Is that the "Toggle Autofeather Arm" control? You can assign it to a button or key, or control it via the IPC interface using the controls facility at offset 3110. That should have worked in FS2002 as well I think. If 2E88 didn't work in FS2002 it is highly unlikely to work in FS2004. But no one ever asked for this before. I can look at hooking it up in both FS2002 and FS2004 in the next version of FSUIPC, if you like. It doesn't look too difficult. What does autofeather actually do, by the way? Regards, Pete

Hey, that's cool! I'm still learning something new each day! :D Thanks! Pete

I'm confused. Are you pressing these buttons whilst doing something else? If you just press and release you are setting and clearing the flag, so nothing really happens. If you want to press and hold a button why bother to use a flag? Why not just use the button directly in the condition? Second, you seem to be making them mutually exclusive -- neither does anything unless the other isn't pressed. I can understand that if you wanted a third condition to operate if they are both pressed at the same time, but you've not listed anything like that. And in any case it is practically impossible to press or release two buttons simultaneously unless its done by wiring and a third button (or position on a multi way switch). You seem to be making things very complicated, so much so that I now don't understand what you want to do. I thought you had a few buttons which you originally wanted to have different actions for different *loads* of FS -- i.e. not even changing in one session. Consequently, all you want are a set of Flags (one for each such "Mode"), which you set based on, probably, a set of KeyPresses. Say TAB+1 for flag 10, TAB+2 for flag 11Tab+9 for Flag 18 etc. Then for each button you want to have multiple uses just define each such use with the appropriate Flag condition. Once a Flag is set it remains set for the whole session unless you program a way to clear it, or use "toggle" for the key press. The order only matters where things are dependent, and doesn't matter at all where the events are different. Since 1 and 3 are merely events of Releasing buttons 6 and 7 respectively, they would be ignored when such an event is not being processed. So it doesn't matter where they are. Well, I have no idea what you are trying to do there. It doesn't seem to bear much relation to what we were discussing. But certainly you don't need to use flags at all to mark that you are holding a button pressed -- the button itself is the flag! Regards, Pete

The FSUIPC throttle sync was implemented a long time ago. All I added revcently was alignment of the prop pitch and mixture. But it does absolutely nothing at all if you don't use it! And it most certainly is not intended to be used with PFC gear. What "box" is this? In FSUIPC? Why do you mean by "no. 1 controls .." and "no.1 jumps around"? The FSUIPC throttle sysnc option is used with game port and USB axes, just as all the FSUIPC joystick calibration facilities are. Please use the PFC facilities only for PFC axes. I think you must be misinterpreting something else going on witth your kit. If you'd explain exactly how to reproduce your problem (don't use throttle sync in either FSUIPC or PFC for now) I'll look at it, but you are telling me nothing except that you seem to be using the wrong facilities. I know the throttle sync facility in PFC isn't right, unless you set all of throttle, prop pitch and mixture/condition from PFC's levers (then it works fine). I have fixed that here, ready for the next version of PFC.DLL, but I have a lot of other stuff to do in the PFC.DLL yet. Regards, Pete

No, there are no separate controls. Regards, Pete

Ah, so you ARE running WideClient on the client PC, not the Server as you implied originally? That's good. It is a Windows error message. As far as I know it simply means that you haven't given the correct name for the Server. Why don't you just show me both the WideClient Log file and the WideClient INI file? I'm sure it will be obvious, but you are feeding me information in such small tidbits that I cannot tell you anything useful yet. Regards, Pete

I don't know VB, but the 64 bit value at those offsets is not a double floating point value, but a 64-bit integer. Regards, Pete

Run FS. Go into FSUIPC options via the Modules menu (select FSUIPC). You can also get there by ALT M F. In the first screen you see (called "About") there will be the version number amd other stuff on the left, and the whole right-hand side is all to do with Registration. To register an application you use the lowest button, labelled "Register an Application Program". It is bottom right on the "About" page. If you don't see it, it will be because you have registered your copy of FSUIPC. If you have a registered copy of FSUIPC you do not ever need to separately register any programs at all (except WideFS if you use that). You automatically have access rights for all FSUIPC interfacing programs. Don't forget that Squawkbox uses Multiplayer to send airecraft images back and forth, and FSUIPC is not at all involved in that. FS2004 Multiplayer is not compatible with the FS2002 version, and I think you have to use something called SBrelay to make Squawkbox work. Regards, Pete

You can have two conditions on each, which gives you four possible meanings for each button just from two flags. Or you can have N flags with only ever one set at a time, and hence have N possible results for each button with only one condition on each -- each one testing a different flag for "on". What limitation are you seeing? Regards, Pete

Okay, thanks. It isn't my home page, actually, but a page maintained by Enrico Schiratti. I will forward the details to him. Regards, Pete

I used MSVC C++ 6 until a few weeks ago. You are wrong! :) "float64" is merely FS's term for the standard C "double". You can most certainly use it in your compiler. It is an ANSI standard and appears in the C definition of many years ago, and it is implemented in all C compilers as far as I know. I seem to recall that in the very first edition of C (in 1978 or close) there was "float" (32 bit) and "long float" (64 bit), but the latter was re-named "double" soon after. There was even a "long double" mooted but I've never seen anything "longer" than 64 bit implemented. If you want to call it FLOAT64 instead of double, just declare it: #typedef double FLOAT64 Regards, Pete

You must not try running WideClient on the Server! WideClient runs on the Client PC. The Server has "WideServer.DLL" installed into FS. Both WideClient and WideServer produce Log files (called WideClient.Log and WideServer.Log respectively) in their folders. When anything goes wrong all the detrails will be in there. You need to check the Logs -- show them here if you have problems you don't understand. Please also check the WideFS documentation. There's a lot in there. Regards, Pete

Good catch! You've found a facility in FSUIPC which I'd forgotten all about, and which hasn't been changed to work with FS2004! Many apologies. I'll try to fix this for the next release. This statement worries me though: "the section {FSUIPC} is disapeared from the fs9_x.cfg when FS9 is closed". If FS2004 is removing sections which it doesn't recognise, then I will have to find another way to specify these parameters. Incidentally, you say "the files are containing a small difference in button programming". Couldn't you accomplish this difference at all using the conditional button programming, possibly using flags changed by a Key Press? I don't think there should be any need for separate configurations for buttons -- only for axis assignments (though that's an area I also want to tackle eventually). Regards, Pete

So, what version have you got? I take it you are not a Beta tester? If the relevant program details are the same then the same freeware Key would work. I cannot support old versions. For freeware I can and will supply freeware keys, so it shouldn't be a problem. But in this case no one has supplied any details for me to generate the key except the author. If the details for whatever version you are using are the same as for the version he got the Key for, then all that is needed is for the Key to be published so it can be entered manually. I spent quite a lot of time of that system so that it wouldn't be a problem, but I am dependent on information supplied. Regards, Pete

Yes, FS2004 certainly messes with the weather, but not just with themes. There's a discussion about this in the back of the FSUIPC User Guide (see "FS2004 global weather control is problematic!"), and this is also reproduced in the "IMPORTANT" announcement at the top of this Forum. In short, I don't think any weather program using the global weather setting methods of FS2002 and before will give good results in FS2004. Both FSMeteo and ActiveWeather have been changed substasntially to get over this. Regards, Pete

From FS2004's Flights dialogue you should see them in the "My Saved Flights" section, as AutoSave simply calls the same routine as used when you save a flight explicitly. As for the actual folder, it depends what version of Windows you are using I think. In Windows XP it will be in your "My Documents" folder, in the subfolder "Flight Simulator Files" (or equivalent in your FS language version if not English). This is where the "My Saved Flights" go. Regards, Pete

Okay, I've now found the relevant website and checked this out. Yes, GndMaker does have a FreeWare access key for FSUIPC, but this is built into version 1.1 of GndMaker, which at present, according to the site, is only available to Beta testers with a password. Since the key is built in you don't need one supplying separately. If you are not on the Beta tester list, it looks like you need to await the official release. Regards, Pete