Pete Dowson

Yes, and I have just spent some time answering you there. I'll need now to repeat it here for others' benefit. I'm not sure what could be doing it, but one possibility is an FS memory leak. Check the memory use (in the task manager) -- compare it when it is performaing well, early on, with how it is later when it seems so slow. I think lack of physical memory will affect the way the Windows socket buffering operates. There are a number of causes of memory leaks in FS. They are far less if you are using 9.1 rather than the original 9.0 release, but some still exist. One famous one if when you have landclass BGL data in the Addon Scenery folder. I had to move a whole bunch of freeware scenery from there to the normal scenery folder to get rid of one such case. Please always check the Announcements and Stickies at the top of this Forum! As you would then see, 6.47 is the current release, though there is a Beta pre-release also available (it will come out as 6.50 shortly). But there's no change I can think of which would affect what you are observing. Regards Pete

I attach GPSout 2.584. Try it. I've taken your word for it that receiving programs shouldn't be upset by the 6 decimal places for Lat/Lon, but I've added a parameter as well -- "PosTo6Decimal", which should be set to "No" to make GPSout revert to 4 places. Currently it will default to 6. The fractional seconds are being set to the number of hundredths of a second since I last saw a change in the Seconds value. This is being done just before sending the data out, so it's the most accurate I can make it. Let me know how you get on with it. Regards, Pete GPSout2584.zip

I'm not sure what "simulated" window mode actually means. Are you running something like FS Real Time or similar which is set to correct the time? That's the only time I see such things -- if the time is adjusted by more than a few seconds, FS will reload textures. It's to do with its time of day or shading algorithms I think. Doesn't this occur in Windowed mode too? If not then my guess is wrong and your other advisors are correct, it's to do with your video card and its drivers. It sounds like their memory "expires" and their huge cache of textures needs reloading. This is one of the problems of large memory video cards -- similar effects can be obtained with sound cards which do a lot of wave file caching. But I've no answers, except to (a) run in Windowed mode instead -- there is, these days, usually no penalty apart from the title bar at the top of screen, which can be kept very small at high resolutions, and (b) why go into the Menus in any case when flying? If you are not flying at the time, then surely the time spent for FS to sort itself out is nothing to get upset about. If you are flying then using menus is extremely unrealistic and disruptive in any case. Sorry if you expected more from me, but graphics and video behaviour has never been my subject at all. Regards, Pete

Yes, I can do that. Just more work, is all. ;-) I understand all that, but with FS the only smooth thing is inside FS itself. Once you bring in other threads trying to multiprocess, and operations via asynchronous serial links, I don't see how such precision is anywhere near attainable. Check it wourself -- are your 100 mSec intervals working out at even close to 100 mSecs? If your main processor and video cards are underloaded, and you don't have very detailed scenery or complex panels in FS, then maybe it will be regular enough. Of course, but it is because that's where the priority lies that other activities don't necessarily get time when they would otherwise want it. Well, I think the best I can do is, when I see the FS second value change, reset a millisecond timer, and adjust subsequent times in the sentences accordingly. This would essentially be a fictitious time because I don't actually know WHEN FS changed its seconds value. Of course. That wasn't the problem -- you misunderstood what I said. I can "invent" the fractional seconds in the way I just described. They just won't necessarily be related to FS's actual time correctly. Regards, Pete

Done. Thanks! Pete

If there's no short cut key for them, the only way is to have something that produces a mouse click in the right place. Luciano Napolitano's "Key2Mouse" program comes to mind. You'd then program FSUIPC to make the button send that key. Regards Pete

Why bother with the Advanced User's manual? Just go to FSUIPC options in FS, Buttons page and program it there. There's no point in making easy things hard! If you select the Offset Word Setbits control in the dropdown you can enter the offset (x050A) and the bit value (1 in this case) directly. Anyway, in this case, because the PM document says "Bit Toggles" I think you need to toggle the bit, not just set it. So use the FSUIPC control Offset Word Togglebits instead. Pete

Erthe log entries you *should* be getting with that option look like this: 229125 *** AXIS: Cntrl= 65762 (0x000100e2), Param= -16383 (0xffffc001) AXIS_ELEVATOR_SET 234765 *** AXIS: Cntrl= 65762 (0x000100e2), Param= 16383 (0x00003fff) AXIS_ELEVATOR_SET 253812 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -16383 (0xffffc001) AXIS_AILERONS_SET 298906 *** AXIS: Cntrl= 65763 (0x000100e3), Param= -16383 (0xffffc001) AXIS_AILERONS_SET 303656 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 16383 (0x00003fff) AXIS_AILERONS_SET The calibration messages come from an entirely different option, originally put into FSUIPC for Aerosoft (Australia) for their GA-28R Piper Arrow III cockpit (of which I have one of the only five made, I think)! ;-) Check your FSUIPC.INI file. There's a parameter "AxisCalibration=No" -- it sounds like you must have that set to "Yes"! The calibration is done when you have this as "Set". This enables automatic calibration to occur when FS is first loaded by moving all the controls to each extreme. This is how it is done for the GA-28R (I think some others do too). A section in the INI is generated called [AxisCalibration] and the values placed there. I don't know how or why you have that parameter set, but if you don't want to use the facility (and it certainly sounds like you don't, delete the section and change the parameter back to "No". HmmmI'm not sure about any of that. Those "something's" were probably "SCALE" and represent the sensitivity slider positions in FS -- but I can assure you, those do not affect stuff written directly. I have tested that conclusively by setting all sensitivities to zero and all null zones to max, which should well and truly clobber all the axis inputs, but it has no effect whatsoever on these direct inputs. Regards, Pete

The sensitivities and null zones are ONLY applicable to true joystick inputs. You most certainly do not need real joysticks or dummy ones. The controls are what happens AFTER all that stuffas I thought I explained? It uses pretty much the same system you are using. There is certainly no problem on a system which has no joysticks -- in fact most all PFC installed systems have no Windows type joysticks and never have had any. I repeat, there is no need to have any real joysticks, and never has been. You do not need them or dummy ones. Something else is going wrong, you need to check your system as I suggested. There are plenty of tools provided for you to check! Pete

Hi again Tuomas, One thing I should warn you about since you are wirting direct to the control offsets. Aircraft panels with their own A/P and A/T such as PMDG and PSS, and external autopilots such as the Project Magenta one, will not work too well with such a system unless you take steps in your code. For throttles, in the Beta FSUIPC I provide a facility for an alternative set of offsets: You'd be best off using these for throttle control so that the AutoThrottle action can still override as needed. For the main control surfaces when the A/P is engaged you may need to simply not move your controls (and trust they are stable) -- in a real airliner I believe sufficient control movement disconnects the A/P in any case, so perhaps that's what you'd need to do too. Regards, Pete

BB6 and BB2, you mean I hope? But turns out I have a problem now: The controlling works right. But it is a lot like when you set "sensitivity" to very low in FS in the joystick options. I can see from the iocards monitoring software that both fsuipc variables seem to move the full range (-16383 to 16383) - but the control surfaces in FS do not move much. Thus control sensitivity is very low. I assume this is with FS2004? I cannot see how that is possible, as, since FS2002, the only way FSUIPC has of effecting those controls is by sending the values directly as parameters to KEY events such as KEY_AILERON_SET, whch are the same as would result from a normal joystick input, after FS's calibrations sensitivities and null zones. I get a full deflection here, fine. I don't know what you are doing wrong, but have you checked with FSInterrogate, or even used logging in FSUIPC to see? Check in any case with a default aircraft -- some of the more sophisticated ones do intercept some of these controls for "fly-by-wire". The Axis logging in FSUIPC won't log these by default, since the method used to send the controls by-passes it, but if you get the latest Beta (see top of Forum) you can force FSUIPC to log your axis changes too by changing the FSUIPC.INI file as follows: Add to the [General] section Debug=Please Then, after loading FS, go to FSUIPC's logging page and set Axis event logging on, and "Extras" to the value 16. Always compare what you are doing with what can be done simply in FSInterrogate, and also just using the keyboard Num keys to raise/lower elevators and so on. Regards, Pete

The NMEA 0183 specs I read seem to specify 4 places explicitly. If I change that it may muck up some receiving programs. Is this a change in a later version of the specification? Since the current "accuracy" of 1/10000th of a degree is, at worst, only 36 feet (and that, for longitudes, is at the equator). I'm not sure there's a lot of point in going further with FS as the timing of you receiving the data is going to vary far more significantly -- unless the thing you are tracking is very slow moving, like a boat? If I could be sure that it would not upset any other receivers I could add two more digits though. There's no fractions of a second in FS's time of day. If I "invented" them, what should they be? Just add something now and then? It would make little sense. I don't actually know the instant FS updates its second counter. Although there is a millisecond counter internally I think that carries on regardless of FS's simulation rates and so on. It wouldn't be the precision of the Lat Long but the lack of any precision in the timing. Expecting your data to be precisely every 100 mSecs apart when it can take longer to do a process switch or suffer a delay through thread timings is possibly a little bit optimistic I'm afraid. Regards, Pete

Sounds like it's license has expired? Otherwise you really need to check with PM support -- I cannot support their programs. Sorry. In any case I would need more details. The Log you supplied shows nothing because it isn't finished - no errors are shown, nothing really useful is shown, except maybe this: 172 Opening GPSout port COM1, speed=4800 -- FAILED! which is due to an error in the Beta wideClient -- if you don't add a GPSout section to the INI file it does it for you, but it shouldn't. I have a later version which fixes this, but in your case it shouldn't do any harm in any case as the COM1 port is evidently either already occupied or it doesn't exist. Does your PM MCP directly connect to anything on a serial port? Please always close down the relevant programs before showing a log. An unfinished log is not often useful. Regards, Pete

Yes, that is the one added to get around the ERJ145 problem. Ah, you didn't look carefully enough then ;-). Just searching on _SET for example, or scanning the Joysticks section for the table showing all the controls, would have led you to the bit in the table on the separate Throttle controls, and the explanation is in the right-hand column there, viz: Oddly, in the 5 or 6 years FSUIPC has been operating this for both older and newer axis controls, only two instances of aircraft panels actually using the old ones (for their own purposes) have arisen -- and both in the last few months! Regards, Pete

At a guess, it sounds like you are using FSUIPC for multiple throttles, posssibly to get reverse on the same levers, and haven't set the cirrect options? Without a lot more information I would have no other ideas. Instead of simply removing FSUIPC altogether why don't you try simply resetting your throttle calibrations and mapping in it? If you don't actually ask FSUIPC to do things it doesn't do them. In the next version (3.50) you can have different joystick settings in FSUIPC for different aircraft, so you could then switch the throttle stuff off for the MD80 without losing them for everything else. If you want to try that there's a Beta version available at the top of this Forum. BTW the AVSIM reference you provided also included this paragraph: Perhaps you missed that bit? The option mentioned is at the bottom of the separate throttles page of FSUIPC 3.48 onwards. Pete

I'll look on my Win2000 installation. It may not be called that anyway -- it wasn't called that in earlier versions of Windows in any case. [LATER] In my Win2000 Pro installation the joystick settings are in Settings-Control Panel-Gaming Options. Please try changing the ButtonScanInterval=20 parameter to ButtonScanInterval=0 in the [Config] section of the WideClient.ini file. That will stop Wideclient looking at any buttons, whether Windows or GoFlight. Regards, Pete

That's really good to know. Thanks! Is there some place you could post this on the PMDG support forum too, please? Good flying! Pete

That's really weird. It seems likely to be something to do with the video drivers in that case. Can you go into Options-Settings-Display, Hardware tab. See if "render to texture" is checked. If not check it, if so uncheck it -- see if that makes any difference. The other thing to try is different video drivers. What video card is it, and what driver version (in case it is relevant ot others reading this)? Regards Pete

How strange. Sorry, I've no idea what the PMDG team have done which would cause such odd things. The only things I can suggest are: 1. Instead of docking it, try locking it into a suitable position. It won't come and go with panel parts then, but you can program an FSUIPC hot key to hide and display it. 2. Try hiding it completely ("hide Always) and run the little utility ShowText instead. Being a completely separate program it should not interact with anything in FS. Of course you may need to run FS is maximised windowed mode instead of full screen mode -- but the only penalty from that is the presence of the title bar, which is barely noticeable in high resolutions. [As an aside, maybe the problems won't occur in Windowed mode anyway??] 3. If you have another PC, use WideFS and apply the ShowText solution to that. I haven't got the PMDG 747 and it isn't something I'm interested in, but if PMDG are interested in resolving this they can contact me. I might need a copy of the aircraft "on loan" to look at it. By the way, PMDG seem to have a little (short) history with AdvDisplay. I seem to remember some folks having trouble with the AdvDisplay text flickering when the PMDG landing lights were switched on. Weird. No one ever got to the bottom of that -- I presume it still happens on some systems. Regards, Pete

Okay. You are not getting WideClient to run anything else, so that's not the problem. The only thing extra which WideClient will be doing when it connects to FS is to start scanning Buttons, in case you want to send button presses to FSUIPC for programming. It does this two ways. For normal Windows-connected joysticks it simply calls the standard Windows API "joyGetPosEx". That is supported in all versions of Windows and most certainly Win2000 as well. The only possible thing I can think of which might go wrong is if there's a joystick installed with a driver which is not Win2000 compatible -- though how you'd get it installed would be somewhat of a mystery. You could try checking for joysticks using the Control Panel "Game Controllers" facility (or whatever it is called on Win2000). The other thing it runs, if it can find it, is a module called "GFdev.DLL", which is the GoFlight device access library. Now I've checked that here and it, too, most definitely does not use "GetRawDeviceList" -- and in fact it works fine on Win2000 as well as WinXP. However, maybe another module by the same name is being picked up. Is this possible? Can you search your Windows folder for a GFDev.DLL (you will have to change folder options to unhide system files and show full names). I really cannot think of anything else that could be happening. If neither of the above yields any results for you I can try supplying a modified version of WideClient with a new parameter to set to make it bypass all the button-checking options. But could you also edit the WideClient.INI file and set "Log=DebugAll" in the [user] section, and let me see the log. (If it is too big, Zip it and send it to petedowson@btconnect.com). Regards, Pete

The log does not show any such plane being loaded nor any gauge being unauthorised. If you want me to help at all I would need to see a log which is relevant. There's absolutely no useful information in this one at all. There's also absolutely no reason an unauthorised gauge to prevent an already loaded and working DLL from working -- unless the code in that gauge itself is going berserk and corrupting ActiveRadar in memory (which would indeed make it a dangerous gauge in any case). But why would it pick on ActiveRadar and leave everything else okay? Sorry, but it is really up to the authors of the ActiveRadar module to determine exactly WHAT it is that doesn't work in their code, and sort that out. From what has been said so far it sounds as if it "almost works". If its access to FSUIPC were being lost surely it wouldn't work at all? The authors should be able to diagnose this easily enough with the correct logging. I cannot do so as it isn't my program and I don't even know what it is trying to do which doesn't work! Regards, Pete

Well, that USER32.DLL procedure isn't used by WideClient, nor is it called by anything WideClient calls (I've just used ProcExp to do a dependency check). It looks like something WideClient is running needs that procedure. Can you show me the WideClient.INI file from that PC please? What operating system are you running on the other PCs? I've checked the USER32.DLL in Win2000, and indeed it doesn't have a "GetRawInputDeviceList" procedure -- it looks like that is specific to WinXP (maybe also Win98/Me). Something is not compatible with Win2000 by the look of it. Let me see the WideClient.INI file first, please. Regards, Pete

Sorry, I don't understand. If whatever you are clicking operates one of the FS controls to do something (and most if not all, at least in the default panels, do), then you already know those controls and can use them -- they are listed in FSUIPC's dropdowns in the Keys and Buttons options pages, and also in the List of Controls documents I provide. If such button clicks do not simply give rise to an FS control -- and that is indeed the case with several default mouse places and very much true for most sophisticated add-on panels -- then the click action is processed by code within the gauge itself or passed on internally to some other part of the panel, or even a co-operating DLL (as for instance in PMDG aircraft). There is no way FSUIPC or anything else can get into that sort of operation. What do you expect it to be able to do, exactly? Incidentally, what do you mean by "limited to basic default commands". Is there something you need missing from the many hundreds of FS controls available? Regards, Pete

I think these must be all (default) libraries which come with Windows development kits. Certainly "uuid" is, and I think "LIBC" is a standard Microsoft C library. Possibly your compiler package doesn't support Windows without adding a lot yourself? I think you may find it more constructive to use the SOURCE I provide for the interface code and make your own library suitable for your compiler, or else just build the code directly into your program. There really isn't much of it. There's nothing hidden there -- everything is provided in the SDK. Regards, Pete

Thanks, Lefteris. Do you think he'd object to me putting something like that in the SDK? Regards, Pete