Pete Dowson

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

I didn't receive any email from you, I'm afraid. Maybe my mailwasher removed it -- there seems to be some email addresses that get on its blacklist. If you'd like to try again I'll take a careful pre-look first. The Access Registration document in the FSUIPC SDK explains what I need by way of information to make the Key, and also explains how you can build the key into your program. Regards, Pete

"My software" being only FSUIPC? You know I provide a module called EPICINFO which can send data to EPIC? If you wish, of course you can. You will have to learn how to interface to FSUIPC (the FSUIPC SDK) and also how to program the EPIC, both from the PC and internally in EPL. Alternatively you could take a look at EPICINFO and see if that will do the job for you. I believe there's also a program called FSCommunicator or similar which can handle EPIC. Regards Pete

Just place the FSUIPC.DLL module into the new FS modules folder, along with your FSUIPC.INI file if you want to retain your previous settings, then, after running FS, re-enter your registration details as you did originally. If you save or print the FSUIPC.KEY file (in your old FS Modules folder) you can copy the details from there. It is a simple text file. Regards, Pete

Go into the Buttons section of FSUIPC, press your button, and assign the appropriate keystroke. If the gauge's ident function is only provided with mouse operation, then the only way would be to get Luciano Napolitano's "Key2Mouse" program and make your assigned keypress combination operate the mouse movement and click. But in general most of those new panels provide keyboard shortcuts too. Regards, Pete

FSUIPC doesn't do any calculations. The ground altitude is read directly from FS. I don't know where it gets it from -- when over an airport it's definitely set by the airport elevation, which overrides any mesh settings. Otherwise I would have thought that it would be the ground altitude set by whichever mesh it is using at that place. I can't see FS deliberately going to find other values when it needs the currently operating mesh to actually draw the surface and detect crashing/landing. Regards, Pete

Sorry, you need someone who knows about hardware interfacing first. Then your software will depend how the hardware connections are accomplished. There's a cockpit builder's Forum near here. Perhaps a message there might elicit some useful suggestions? Once you sort that side out, you may need the FSUIPC SDK, from http://www.schiratti.com/dowson. Regards, Pete

How is the PFC TQ connected? If you are using my PFC driver (PFC.DLL) then you can re-assign and calibrate any of the levers in the option screens there -- just use one of the User Configuration pages, and assign it to the aircraft so it is automatically selected when you load the aircraft. Please check the documentation provided. Regards, Pete

They are signs that something is not quite right, but if the errors are so infrequent, and do not become noticeable in the flight, I wouldn't worry so much. Sumcheck/length errors can only occur if a block gets corrupted or truncated in transmission. Theoretically this can only happen on a faulty cable or switch, or possibly more likely, a faulty Network Adaptor. Less likely are memory errors on one of the PCs or interrupt (IRQ) conflicts. But as long as it doesn't get worse I wouldn't worry about it. Regards, Pete