Pete Dowson

I assume that upper panel is undocked, then, a separate window? It sounds like it is constantly re-drawing itself. Have you tried "Locking" AdvDisplay in place instead of docking it. If it makes no difference, which panel part are you docking it too (check the panel.cfg file). I had one devil of a job getting it to work on the main FS window without flickering. I'm not sure that I would be able to come up with a solution, but I'll make a note to look at it. But please try locking it first. Regards, Pete

No. If it's the grey sky versus blue sky business I explained, then it could only happen on a change of visibility around the FS threshold, 10. something miles, I think. It cannot smooth the graphics representation. FS is presenting a blue sky when the visibility is, say, 10.40000 miles (or close), and a grey sky when the visibility is 10.39999 miles (for example). No matter what smoothing occurs, if the value crosses the threshold FS changes graphics. It's completely insane, I agree, just like the 4 mile threshold in FS2000 and FS2002 was insane -- but 4 miles is, in my opinion, less insane than 10 miles! I don't think much will make any difference, except possibly disabling the Extend METAR max option and/or using a good weather program. Same here. :wink: Sounds like a combination of joystick calibration differences and the silly dynamic time-related reaction FS started by default in FS2000. You need to add "stick_sensitivity_mode=0" to the CONTROLS section of your FS9.CFG file. That makes the response linear as it was in the good old days of FS98. :) Well, some of the "realism" options are known to be somewhat overdone, but it also does depend a lot on the modelling. You may like X-Plane, but that's even more sensitive to the modelling and you need to get things right. In FS I would advise you to first put all the realism sliders about centre, or not much higher, then try a variety of third party add-on aircraft. Some are excellent, some are awful. You should always trim out any pressure, once in stable flight, whether climb, cruise or descent. Real aircraft vary a lot too. The Cessna 150A I trained in was very twitchy in comparison to the Piper Cherokee 180, for instance. I had to give up real flying because of my eyes (retinitis pigmentosa, causing deteriorating peripheral vision to the point of extreme tunnel vision, as I have now). Regards Pete

Grey overcast is surely to do with clouds, not visibility? What do the weather read-outs say in the two cases (in FS Weather dialogues and in WeatherSet2)? If it isn't due to clouds it will be because the visibility is set very close to the threshold above which you see blue sky (and stars at night) and below which you see mist (your grey) and no stars at night. In FS2002 and FS2000 I think this used to be around 4 miles, but in FS2004 for some reason they extended it to around 10. Someone did measure it precisely once, but I don't recall what is was. Something like 10.4 sm (1040 FSUIPC units of 100ths of a statute mile). You could check yourself using WeatherSet2. What's "default weather" in this context? Visibilty settings of 50, 18, 15 and 10 represent half a mile, 0.18 mile, 0.15 mile and a tenth of a mile, respectively. You should have 5000, 1800, 1500 and 1000 respectively! The units are 1/100ths as clearly stated. By "extended random weather", I assume you must mean "random extend METAR max"? That's important if you use an external program but it has no effect for FS's own weather. For an external program providing METARs in Europe, the variation it is setting will vary from 6.2 miles upwards, so if the weather program is re-sending the visibibilty changes regularly you may get fluctuations above and below 10 miles, so you could try switching that off. What "smooth changing" is set to 2%? I don't provide any smoothing adjustments by %. The visibility smoothing is 10%, you can only vary the timing. Baro smoothing doesn't work in FS2004 with FS's own weather, though it can with a weather program. Why have graduated visibility off? My only recommendations would be as per documentation. All variations are then a matter of taste. You cannot stop FS hiding the blue sky when the visibility drops below its threshold -- if you never want to see a grey sky you'd need to set the minimum to 1100 or so -- it defaults to 0. But that will only apply to externally set weather. Quite honestly, I've never seen sudden loss of blue sky except when descending into a poorer visibility layer, and that does approximate to what can happen in reality. The main thing which is totally unreal in FS is that the visibility restrictions apply in ALL directions (except, stupidly, down!) -- and the least realistic part is that a 10 mile or less visibilty makes the sky directly above grey too, whereas of course it should graduate from grey to blue (or grey to cloud textures). I regret the changes in FS visibilty since FS2000, which I think had the best visibility effects. FS2002 was totally naff in that area, but the improvements made in FS2004 are offset by rather insane blunders like this 10 mile (approx) cut off. Finally, you may find the payware alternatives like Active Sky and FS Meteo are far better. I've used both for years and have never suffered from the sorts of problems you describe. Regards Pete

Ooops. Sorry. Fell through the net. Actually there are a couple of other bits there which may just possibly be useful too. One of them is 2^2 which is set if FSUIPC is fully registered. Regards, Pete

What's the "Elite" tab? There's nothing in any of my software like that. Ah, you have a separate "Elite" driver which uses FSUIPC? In that case it sounds like one of two things. Either the driver checks the version number of FSUIPC, and specifically doesn't work with version 3, or your FSUIPC user registration isn't actually valid. To check the latter, try removing the FSUIPC.KEY file from the FS Modules folder and see what happens when Elite tries to run then. In either case, check the FSUIPC Log file (also in the FS Modules folder) to see if there's anything relevant recorded there. In fact, close FS after getting one of those "Elite FS needs FSUIPC version 2.9x or ..." messages and show me the entire FSUIPC Log file. Are you saying that, before this, you only used your Elite driver with FS2002? If so, it sounds very likely that you need an update from them to work with FS2004. Have you contacted their support at all? Let me know what you find. Regards, Pete

Sorry, I've been too busy with other things to really spend that much time on it. I did dedicate a whole week to it last year, and in nearly 80 hours got nowhere. Maybe I'm getting too old. :cry: I'm not starting to look any deeper into FS2004 now. I'll maybe look again when FS2006 is out and dealt with. I also don't really like the current built-in ATC very much, preferring to use Radar Contact, so my heart is not in it. Sorry, I don't really understand that part. Regards, Pete

If this is using keystrokes, then surely keyboard users must be complaining too? If it is using keystrokes but the keyboard use doesn't suffer so much (i.e. having to press the key a hundred times to get one degree change, or hold it down for 10 seconds or so), then the reason will because you/they are not programming all 4 button numbers for the rotary, and not using both the press and release -- as Ii said, a single click is a press or release. They alternate. I can't really help much more as you are not actually telling me anything. :wink: Regards, Pete

It doesn't work like that. If you are having problems it isn't likely to be with the Keys -- if it is there will be entries in your FSUIPC Log file saying so. The SB3 program has several of its own DLLs in the FS Modules folder and they each have their own key already, built in. I'm sorry, but that's as much as I know. Every request for keys from the SB3 team has been met and they've all been programmed in -- there are several. If you have problems (I understand it is still in Beta and what you have will be a "release candidate" in any case) then you need to tell the programming team, as this is why they make these pre-releases. If you have a paid up user key for FSUIPC, and it is legitimate, you won't get any registration problems with any FSUIPC programs in any case. If you have an illegal key then you will get problems with most programs -- in that case delete your FSUIPC.KEY file and run FSUIPC in unregistered mode. Regards, Pete

Do PMDG use their own CRS variable then? Seems odd -- the normal FS one is normally used, even by advanced cockpits, as it's so simple to use it without any side effects and, after all, it's there (both 1 and 2). Even Project Magenta leaves that simple task to FS. If it doesn't increment/decrement on every click of an RP48 knob then they must presumably be using some units other than degrees -- what, 10ths, 16ths, 100ths? Is this via a keyboard assignment? If so, then surely that must equally irritate keyboard users? That's seems rather hard to believe. Don't forget, too, the FSUIPC implements a different button for "fast" turning as opposed to "slow" -- so if you are getting few increments when turning the knob, maybe you only programmed the slow turn or vice versa? Each knob produces 4 button numbers in FSUIPC, two for each direction. You could program one click (which on a GF rotary is a seen as a "press" or "release", so needs doing in both places) to operate their control 10 or 20 times, whatever. But, again, if the only control is via keyboard, this will tend to fill the keyboard buffer rapidly and be jerky as a result. If you are talking about using some hacked locations in FSUIPC memory for the CRS, then you only need to change the programming for your RP48 to use the offset cyclic increment/decrement controls with a larger increment value. Regards, Pete

Have you looked these up in the FSUIPC programmer's document? Both are listed. Use a search on the text. Engine 1's MP is a 16-bit word at offset 08C0 in inches * 1024, so you can display that simply by something like (for example): D0=X8C0 U16 D22 /1024 ;MP in inches as nn.nn The prop 1 RPM is best taken from the 64-bit floating point value at offset 2400, so, for example: D1=X2400 F64 D40 ;RPM as nnnn or -nnnn (neg for contra-rotation) Change the formatting to suit your needs. These are only examples. Regards, Pete

I thought the "TrafficInfo" DLL provided most all the information needed for TCAS type operations. Doesn't it? Apologies if not, I only glanced briefly at it when it first came out -- I was deep into other FSUIPC matters then. I think that is most unlikely, or at best extremely difficult. You'd probably be able to do it by having a bare bones C DLL, made following the Panels SDK but as a DLL, which did nothing but call your separate non-FS loading VB-made DLL. If the latter was placed in the FS Modules folder you'd need to call it something else, like .BIN or .PRG or something, but it's a trivial matter to call procedures in a DLL by any name. It isn't really a matter of finding where it is stored so much as finding the internal C++ class pointers and deriving the virtual functions and their parameters and return formats so you can call them and use the returns. Things are several layers down, and it gets horribly complicated. Then, after all that, you have to work out a way of doing it all without impinging upon FS performance -- the latter is where I spend as much time designing in FSUIPC as I do finding the stuff in the first place. Regards, Pete

Not without a complete change in design and interface, which I'm not really willling to contemplate at this stage. Sorry. The main requirement always was for TCAS, which is met admirably. There is a traffic SDK, and a new DLL could be written using MS's own interface (which arrived far too late for me to use) to supply whatever you needed. If you are a C or C++ programmer it may be well worth investigating. This is true only if that option is set (and repeatedly set) by an application. It will remain as it is now by default. Okay. I'll be looking at doing all this in the next week and will post a test version here in due course. Regards, Pete

Yes, but also the GF modules in the FS Modules folder don't actually use GFdev.dll -- the latter is a module provided by GF for use by other programs, like my FSUIPC, WideClient and GFdisplay programs. Sounds good. Regards Pete

Well, that isn't really comparable, and it can be done now in GFdisplay, because there are definable events for each of those changes, i.e. the value in the gear position variables. In my example for the gear LEDs on the GF-LGT unit does similar, excepting of course it uses RED for motion, not flashing. Flashing is also used on an MCP for VOR/LOC when it's engaged but not yet acquired, and GS too -- except there's no GS LED on the GF MCP, so you'd have to make use of the APP LED instead. Flashing "for a time" rather than until an event occurs is different. I'll need to add code for that. It's on my list. I'll see when I can fit it in. Hopefully within the next two weeks. Regards, Pete

No, there are no timer facilities in there at present. Hmmm. Yes, I'll think about how to do that. You want a time associated with an action, effectively splitting in, in this case, into two actions -- button off = slow flash, set timer timer expired = indicator/display off ??? That's a bit complex to weave into the design philosophy I adopted. If it's only for flashing (for instance) then how about some flashing variations instead, like Slow flash for N secs then off Slow flash for N secs then on steady Fast flash ditto, ditto Steady for N secs then off (not really a flash but still) If that will do the job it will be easier to plug into the existing program. What do you think? Regards, Pete

How about something like this? This is only a proposal at present. If it suits folks I'll see about implementing it in an interim test version sometime next week. Regards, Pete

I appreciate that. I'll try to please everyone if I can. It isn't easy. I for one have never seen the ground table fill up completely, even though I use Ultimate Traffic, one of the heaviest traffic additions. The airborne table often fills though. Regards, Pete

Only the Buttons page will show anything. There are no joystick axes on a GF45 and FSUIPC doesn't handle GoFlight quadrant axes in any case. Sorry, I don't understand that statement. Can you elaborate? Does the GF45 work with GFconfig at all? FSUIPC needs to find the GFdev.dll in the place pointed to by the Registry as the folder containing GFconfig. If you correctly installed the most recent version of the GF software (from the GF website) then this should be okay. If you didn't install the software using the GF program then FSUIPC may not be finding that interface DLL. Check the folder containing your GFconfig. Does it include GFdev.dll? The Registry key which is set by a correctly installed GF driver is: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\\GFConfig.exe So, two things to do: 1) Check the folder containing your GFconfig.exe program. Does it contain "GFdev.dll" as well? If not, then you have a very old GF software installation. Please get an update from the GF site and install it. You should then be good to go. 2) If that folder does contain GFdev.dll, then the most likely thing is that the Registry link to the folder is broken or missing -- maybe you re-installed Windows or recovered your Registry from a time before you installed GF. In this case, I'd still recommend re-installing as above, but an alternative which may also just work is to copy the GFdev.dll to the Windows or Windows\System or Windows\System32 folders -- one of those should work as I think Windows looks there as well as the specific folder requested. Regards Pete

Yes, if it is one of the 96 nearest to the user aircraft. No otherwise. This is the same criteria as used in the air, except there is also a (documented) low distance limit on ground aircraft. Where is the user aircraft when this program of yours is being used? On the ground at the airport, or in the air near it? Because that makes much more of a difference. The range is 3 nm only if the user aircraft is on the ground. This covers the size of most airports, but does it cover all? If the user aircraft is in the air the range is 6 nm. This is clearly documented. That's all very well, but for other applications is it just as important to see what aircraft are parked in which gates and so on, especially as these are approached by a taxiing user aircraft. The most I think I could or should do is treat "sleeping" aircraft as further away than active ones -- so effectively the furthest among them would be replaced by further active ones (within the 3 or 6 nm) once the table becomes full. How would that be? I think, in general, that would pretty much meet both criteria. Originally of course the idea was only to provide TCAS information -- i.e. data for TCAS gauges, so only airborne craft. The ground traffic addition was a little "nicety" added for fun. It seems nowadays that the tail is wagging the dog! :wink: Regards Pete

Nothing as far as I know. But someone who knows SB3 may be a better source of information. I really can't think of anything in FSUIPC's user options which are likely to be used specifically for SB3. Regards, Pete

Not easily. None of the TCAS table options are currently application-settable. And exactly what algorithm would you suggest be implemented? Obviously "active" aircraft ignoring distance can't be the option -- this would include aircraft in nearby airports too. So some balance,is needed. But what? What exactly is the application that needs this change? I'd like to understand the reasons. Regards, Pete

Using WideFS on your Network, yes, any switch or button recognised by FSUIPC -- which includes all buttons and switches recognised by Windows as well as all GoFlight buttons and switches -- can be assigned to PM functions in a registered copy of FSUIPC. The actual networking of this is performed via WideFS by the PM modules themselves -- they respond to changes in their allocated FSUIPC offsets. Regards, Pete

See this item in the Release Notes (top of the Forum) for FSUIPC version 3.47, released about 5 weeks ago: If you are using an out-of-date version of FSUIPC please update it. If you still have a problem then you may have to look elsewhere. Possibly you have another button or axis operating the brakes? Regards, Pete

No. At present the criteria is purely distance from the user aircraft. The 96 nearest the user aircraft are retained. For most purposes I think this is best -- even if the aircraft is merely parked "sleeping" and not assigned its flight plan yet. It may be an improvement to also take into account the status of the ground aircraft, but I'm not sure. It's nice to show the occupied gates in programs like Trafficboard, even for sleeping aircraft. If I were to include the first 96 active aircraft, and only sleeping aircraft when slots are still available, some of the programs out there would lose some of their interest and usefulness. However, I'm open to other arguments on this if you have any. Yes, if it is one of the 96 nearest to the user aircraft. Regards, Pete

When it disappears it will also disappear from the TCAS tables in FSUIPC. Watch the list in TrafficLook. Aircraft come and go all the time. Disappearing on the tarmac gives the same results as going out of range and disappearing from the list that way. This action will happen some time during the next full scan, and that depends on the scan rate set in the FSUIPC.INI file. With the default of 10% per frame a full scan takes 10 frames -- say half a second or so. Regards, Pete