Pete Dowson

Yes, it is. Mine is 04-15-2004. There's also a version number in the COMM window -- 32 here. Regards, Pete

No. You are reading a cached file! There are notes on the website as to what to do, please read them. This is reported on every new release. No one reads the notes? See "Important information and download troubleshooting FAQ at the bottom of the page." Pete

Okay. I've looked into this, and those codes are wrong, and completely explain the problem. On my Jetliner the codes the A/T disconnect produce are: Press: 9C 08 Release: 9C 00 Now, according to the PFC protocol documentation that code is supposed to be TO/GA, and I understand that's how the original throttles were labelled, but in fact they are now labelled (correctly) "A/T disconnect", and I've programmed the 9C 08 code as A/T disconnect. In test mode, try your A/T Arm toggle switch. doesn't that also give you 9C 00 when off, 9C 01 when on? It does here. The 9C 00/01 code IS the A/T arm switch as far as my driver knows. that's how it is documented. So it looks like your button is wired to disconnect the A/T when pressed and reconnect it when released, exactly as if you flicked the toggle off and on. The driver cannot distinguish between identical codes. Check the toggle switch. Maybe they've got the wiring mixed up? Either way you certainly have a need for hardware support from PFC. Sorry I can't help with that. Regards, Pete

Have you gone to the site where all my software is downloadable and looked for the Software Development Kit (SDK)? The SDK has all the information and examples. That is what it is for! Seems you've not looked far yet? Maybe FS's own multiplayer or WidevieW could do that. Neither FSUIPC nor WideFS can link two copies of FS together. Regards Pete

Why have you started another thread when replying to the same subject? Please keep to the threads, else things get fragmented and hard to follow. Of course. I have one PC client running Radar Contact, ActiveSky, pmSystems, pmSounds, FSRealTime, SA_WXR and AIsmooth. The only real limit is the speed of that PC -- at some stage it'll get bogged down. But there are few appplications as greedy as FS! ;-) Pete

The buttons on the outside of the two throttle levers? Press either or both of them, and the A/T disconnects. That's it. I have them on my Jetliner and in my 737NG cockpit. Really? It isn't programmed to do that. It sounds like you've re-programmed it (in FSUIPC?), though I've really no idea what function would do that, at least not consistently. What does the PFC driver say in its "Test" mode page when you press it? What aircraft are you using it with in FS? Maybe it is a function of some add-on aircraft? No. That isn't possible. In the real aricraft that arming switch would actually flick off when you pressed that button, but that needs a switch with an electromagnetic catch. It's one of the occasions (the A/P disconnect is the same) where some of your switches become out of sync. To re-engage A/T you'd need to toggle the A/T switch off and back on. If the A/T disconnect has been re-programmed to operate the "speed" button then that might explain what you are seeing, though that would depend on what A/T mode you are using at the time, and probably on what aircraft you are flying. There are several A/T modes - Speed, Level Change and VNAV. No toggling of any of them disengages the A/T, only disengaging the A/T does that. Regards, Pete

Sorry, there is no way possible to use a single PC to run both FS and WideClient as a standard FSUIPC interface at the same time. You can make WideClient run by changing the Classname (see that parameter in the INI description in the documentation). But this won't support programs written to interface to FSUIPC unless they also allow the classname to be changed. You see, the FSUIPC interface is one connected to automatically by the application programs, knowing the name of the Window class ("FS98MAIN") to which they should attach, and that name is already used by FS when it is running. In fact that is the whole point. You presumably have FSUIPC running in FS, so if there are effectively two copies, how does Radar Contact know which to join? Yes, that it true. WideClient "pretends" to be FS so that application programs which link to FS (through FSUIPC) are fooled into linking to it. That's the way it works. that's its entire purpose. It enables FSUIPC applications to be run on PCs not running FS. Regards, Pete

This "rotary" is an axis? The term "rotary" is normally used for a rotary switch or encoder, which looks like one or more buttons to Windows. You mean, control two separate axis inputs in FS with one actual hardware axis? Hmm. Not with FSUIPC alone, nor with FS alone. You might be able to do it by assigning it as the Left Brake in FS, and the Right brake in FSUIPC, and reversing it in one of them. The tricky part would then come in calibrating it with enough of a null zone to stop both or one being on all the time to some extent. You'd need to experiment. Certainly in FSUIPC you could set it so that it doesn't have any effect below half-way or better, but I'm not sure whether the FS null zone will allow you to go that far. Try it. Regards Pete

Okay. You are lucky! I found the bank value -- it is stored in SIM1.SIM in the double before the pitch value, not the one after. I have remapped it (in FS2000 only). As I mentioned, this has been wrongly mapped forever (I mean for the whole life of FSUIPC). Obviously it hasn't been very important to many! ;-) The coordinator ball is fine though. The fix for FS2000 wil be in 3.60, hopefully on release this weekend. Regards, Pete

Okay. I got something working okay. It wasn't what I planned, but it should be okay. I cannot depend upon the "in fuel box" flag. Whilst parked in the fuel box, that flag seems to come on and off with the brakes -- if I use that then, by timing mischance, the tanks could fill before I can stop them. So, I've renamed the option "StopAutoFuel", and instead I prevent the fuel increasing in any tank UNLESS it is either done via FSUIPC offsets (for gauges and external programs), or via a Menu or Flight re-load. I've tested it in FS2004 and it seems to work well. It should work in FS2002 as well, but not in any earlier version. Sorry, I can't offer a pre-release as I'm in the middle of the final builds for release 3.60, but you should be able to get that over the weekend or so. I'm afraid if it isn't satisfactory then any fixes or changes will have to then wait till later in May. Regards Pete

I will try the slightly messy solution of resetting the fuel levels constantly whilst offset 032C is non-zero (but only when the levels are higher, not lower, else you'd get everlasting fuel by parking at a fuel box!). If it works reasonably well -- i.e. without too much noticeable jitter or other side effects, I will leave the facility in, but only enabled by an FSUIPC.INI parameter (too late for me to change the User Interface for this version). Probably something like "StopFuelBox=Yes". I'll let you know later. If it seems more or less okay it will be in 3.60, released this weekend I hope. Pete

Hi again, I've just done some tests on the fuel box at Meigs. It seems that FS re-fuels if you stop in the fuel box and apply brakes, even with the engine running. Seems rather daft to me -- I would have thought that you'd at least have to have parking brake engaged, and preferably engines and, most especially, battery off. Anyway, I tried the simple thing -- continually setting offset 032C to zero (that offset happens to be one of the few "original" GLOBALS.DLL locations which still appears to be used, dating back that way right to FS98 or even before). Unfortunately this had no effect. Maybe it needs to be done in some chain or other, or otherwise possibly it's an effect rather than a cause. Either way I'm afraid a solution would represent many many hours of work hacking into areas of FS I currently know little or nothing about. The only other way I can think of trying here would be to check the 032C flag and if set, to try to stop the values in all 11 possible fuel tanks from changing. I would expect to see them fluttering up and down all the time that you are in the fuel box. Even if that were satisfactory, you'd have to leave the fuel box in order to add fuel at all, even via the menu, unless the code could also detect that. A scenery solution, disabling the actual fuel boxes in the BGLs themselves, may be far nicer, but you'll need to ask scenery designers about that. Regards, Pete

Sorry, I've no idea. Please ask PM support. Regards, Pete

You could only do that by reading the value and if it increases, re-write it as the previous value. You'd also need to be able to switch that off if you ever wanted to put fuel in. I might be forgetting things, but I really didn't think the fuel boxes did anything unless you actually parked, engines off, in the fuel box. Surely no one in Microsoft would ever dream of re-fuelling aircraft with the engines running. Isn't that a bit of a fire risk? Either way, I'm pretty certain it is some sort of scenery action. There is an offset accessible through FSUIPC, 032C, which when true indicates "plane is in fuel box", and, it says, that is the same indication as scenery BGL variable 0288. I assume if you can find references to that variable in the scenery BGLs and remove them, you won't have any fuel box action. Being to do with scenery, it is all really an area unfamiliar to me. It is far to late in the life of FS2004 for me to consider disassembling parts I've not ventured into before, so possibly this is one for FSX. In any case, I am on holiday from Monday for a couple of weeks and I'm trying to get the latest version of FSUIPC on full release before I go, so I don't see how I can even start. Maybe your best bet is to ask around in a scenery design forum? I'm sure it's all to do with those BGLs. As I say, I still thought you had to do specific things to get refuelled anyway, not just drive through a fuel box. at least this was so in older versions of FS and I really can't imagine why they'd change that. How? Pete

Okay, you are losing some of the options then. Can't you simply send button press and button release as they happen? I've not programmed EPIC for many years, but surely the simplest button operations aren't pulsing and repeating? Even a pair of wires on a Game port can do better! Pete

But it was explained in more words in the original explanation! Pete

... but surely you'd put some controls on it? Of course ot, You can use the FS menus. But I thought you were againsta that for some reason, sorry. more realistic would be the fuel control gauges. No, fuel boxes must certainly be part of the scenery. What "add fuel" function? You've lost me now. I thought you were complaining about uncontrollable scenery fuel boxes? Pete

Please check with FSInterrogate and/or the Logging and Monitor facilities in FSUIPC. All the tools are there, at your disposal, to do these checks yourself. i cannot debug things from here. Pete

Not directly, that I know of, though I don't think it has ever been investigated. I assume it isn't related to any realism or other menu setting in FS? You could write a program to keep writing 0 or whatever to the tank levels to keep them empty. Better, there are probably fuelling programs or gauges you could use to deal with both re-fuelling and jettisoning fuel -- try searching on one of the main file libraries such as AVSIM. I must admit finding it odd that this is the first time I've ever heard of this being a problem in all these many years since FS first had the fuel boxes -- FS3 was it, or FS4? ;-) Another alternative would be to try to find a scenery editor with which the fuel boxes could be removed or moved. Regards, Pete

A button pulse is actually a bit slow for things like this because it has to send a press, wait for a many milliseconds, then send the release, emulating a normal button pressed and released with a finger. You'd be better of toggling the button state on each 'click'. Then in FSUIPC program both press and release to do the same thing (assuming you are programming the buttons in FSUIPC -- you don't say). Also make sure you are using the FS controls, NOT the FS keypresses. Since you don't say how you've programmed the buttons I can't help there. The only one which should be faster than any of those is the Course (OBI), as there's normally no graphics update going on with it, but you said that was slow too -- I've never seen anything able to slow down the course setting. If you tell me how you are programming the buttons I may be able to advise further, but it is likely that your main problem is trying to pulse the buttons for a rotary. The pulse facility is meant to reproduce human button pressing so never was fast. The delay with it pressed has to be long enough for FS to be able to recognise it whilst polling (as it used to in EPIC VXD and FS05/98 days). Regards, Pete

If you write a value less than the wind speed it is taken to be the gust difference, i.e wind varying by 15 knots (up to 40, say, if the wind is 25). If the value is greater than the wind speed it is taken to be the upper limit -- so if you set 15 with a wind speed of 5 you'd get 5-15. I think that's written up okay in the paragraph I quoted in this thread earlier. Did you miss it? Pete

Sorry, I don't know. I must admit to not going anywhere near any of those since FS5 days. Maybe some other reader may have a clue -- or ask in the FS2004 Forum? Regards, Pete

No. Why is it slow? How are you doing it? I'm sorry, I cannot help with no information. Pete

It's 16 bit of course (2 bytes), a "short" in C/C++ terms. If you only allowed one byte for it in your program, then your weird values would certainly arise from any non-zero rubbish it picked up from the upper, undeclared, byte. That should have been obvious from one of the weird values you quoted -- 62465, which in hexadecimal is F401. i.e. 1 in the first byte and F4 (244) in the second. Logging in FSUIPC would have picked this error up straight away. Regards, Pete

No. Not the current version. I'm thinking about rationalising all my assorted utilities for FS, though, for the next version of FS .. less to maintain, more value for those registering. But you are okay for all current versions. Regards, Pete