Pete Dowson

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

Ah, yes. FSUIPC has to deal with that situation in any case. It must have been in the INI file -- it would have automatically created the [AxisCalibration] section. If there was nothing in the INI file doing it, then deleting it wouldn't have had any effect, now, would it? ;-) Pete

Hi again, Just as extra information on this matter, I have a PFC 737NG cockpit, and the trim indicator scale in that is marked in units going from 0 (full nose down) to 19 (full nose up). What is effectively happening on this is that the full trim scale (offset 0BC2) of -16383 to +16383 is being maped, linearly, onto the sale of 0 to 19. If you are trying to drive a separate indication somewhere, I'd use the 0BC2 indicator, a 16-bit integer, rather than the 64-bit floating point value at 2EA0. Simply scale -16384 -> 16383 to the needed range 0-19. In other words something like: Aircraft Trim Set = ((FStrim +16384) * 20) / 32768 Here I am assuming that the aircraft scale is actually linearly proportional to the trim position. I cannot imagine that it might be otherwise. Regards, Pete

It sounds like you have edited the FSUIPC.INI file and set the "AxisCalibration" option to "Yes" at some stage. This facility was added to allow hardware devices implemented without their own calibration facilities, which had drivers interfacing to FSUIPC, to be semi-automatically calibrated by FSUIPC -- the only example still existing that I know of being the Aerosoft (Australia) Piper Arrow cockpit, GA28R (of which I am a proud owner! ). The facility is described in the Advanced User's documentation. I don't know why you may have enabled this -- it cannot be enabled by default nor through the in-sim options. Edit your FSUIPC.INI file, delete the AxisCalibrations parameter, and the entire [Axiscalibrations] section, and you should find it is all okay. Regards, Pete

The units on the aircraft scale are not radians or degrees of trim angle, which is what 2EA0 represents, with 0 = Neutral. In your picture the actual 2EA0 value is not the factored one but the small value (.076) in radians. I assume the factored one is a conversion to degrees. I suspect aircraft trim indicator units are rather arbitrary, and used simply in relation to the performance tables which show correct trim values for different circumstances (mainly safe take-off trims for different weights etc). The values are arbitrary I think, as I said. You'd have to find out for the specific aircraft -- when 2EA0 reads zero, see what the trim indicator reads. Well, I would have thought that would be obvious. It must relate to the panel. That's what the pilot would see. On a real aircraft you don't actually have offsets like 2EA0 visible through FSUIPC, and the folks who made the panel are trying to simulate the real aircraft. No offsets whatseover. It's purely related to the markings on that particular aircraft's trim indicator. Pete

I've made some substantial improvements to the way the initial connection checks work, and also found a way to allow the COM port in use to be changed during a session without reloading FS. The improved version is 1.998 and is available above now. I could find nothing wrong with the quadrant assignment mechanism, and am loathe to fiddle with it as it has been working well for many years. I did check to see when and why the "assign to aircraft" button is missing, and this can only happen if (a) There is no known name for the current aircraft (yet). This can happen if the options are entered whilst FS is still initialising or loading a Flight or Aircraft. The solution is to quite the PFC options and try again when FS is settled. (b) The 737NG cockpit hardware has been selected as the 'console'. In this case most of the other options are inhibited and access to re-assignments is restricted to trained PFC personnel. To get out of this you would need to close FS and delete the PFC.INI file, i.e. start again. However, in the current version you cannot inadvertently select the 737NG console. Note that (a) also explains the occasional delay whilst the automatic assignment of a quadrant occurs. This is not an error or even a problem. The assignment may take a second or two to activate after any Flight or Aircraft load, or after any change in the PFC options. Regards, Pete

Didn't you find the documentation in the ZIP? It's called "WIDEFS.DOC". It does explain the parameters there -- you can tell the Client the name of the Server in the ServerName parameter. Anyway, I thought you said you had it working in FS2002 but not in FS2004? Why not simply use the same INI files for both? WideFS isn't bothered by what version of FS it is -- it leaves all that to FSUIPC. Is your client PC not running WinXP or Win2K? If it is, are both PCs in the same workgroup? It is a little odd that the Server is broadcasting its details but the client isn't seeing them -- the broadcasts use the Windows Mailslot facilities, which only work in Win2K and WinXP (and seem to need the PCs in the same workgroup). Otherwise you have to specify the server to the client, as in earlier WideFS releases such as the 6.47 you were using last time -- you did specify the ServerName that time, it was just wrong. Regards, Pete