Pete Dowson

Or, so you can process Widows messages too: Open FSUIPC Set a timer (SetTimer API) for 50 mSecs, say On timer: READ data from FSUIPC; USE data from FSUIPC EXIT. On Quit: KillTimer Close FSUIPC link. Regards, Pete

See the WideFS documentation -- look for "SendKeyPresses". Also check out the virtual button options, which are superior. Pete

The problem is clear --- the F16 module is initially accessing FSUIPC using an illegal method -- the method designed only for external applications. It is being identified as "FS9.EXE" which has no key. Only subsequently is it identifying itself correctly, but it is too late and it won't work using the incorrect interface. Check if there's a later version of the GAUge available. I'm sure the most recent versions don't use the wrong interface. Incidentally, this incorrect access method has been incorrect since FS98 days, i.e. many years. It isn't a new problem. Before there were access checks in FSUIPC 3 such gauges could cause other problems, crashes in FS and so on. Regards, Pete

Please don't use ALL CAPS. It makes it more difficult to read, and it comes across as shouting. F16.GAU is rather notorious for this. Something in its code clashes somehow with other things on a few folks systems. Mostly it is okay, but when it isn't then the only solution, on some systems, has been a Wnidows re-install. I can't help as it works fine with the issued freeware key on all my systems. It also works fine with a user-registered FSUIPC. There are other TCAS gauges which aren't so problematic -- for example, one by Lee Hetherington (ILH_TCAS I think). Meanwhile, be sure that you are entering the correct application key as an application key and not a user key. Regards, Pete

Sorry, I am of no help at all on EPIC these days. I don't even have FSComm. Regards, Pete

Neither of these messages are part of FSUIPC, so they must be from another program. What program or module or panel are you trying to use? What does the FSUIPC.LOG file show? (You will find it in the Modules folder). Pete

If GPSOUT.DLL is in the Modules file, and the Port specified in its INI file is definitely available, there is no way you can stop it sending data out. It is not dependent upon anything else. So if you see nothing it is because it cannot open the port you have specified. Show me the GPSOUT.INI file please. Also be sure you have the latest version. Pete

Inside FS, is there a Modules entry in the Menu? When selected is there an FSUIPC entry? When selected do you see details of the FSUIPC version? What does it say? If it looks okay, what does the FSUIPC.LOG file show (also in the FS Modules folder). Run everything, get the errors, close FS, ZIP up the FSUIPC.LOG and FSUIPC.KEY files and send them to me at petedowson@btconnect.com. Regards, Pete

It doesn't suddenly cease to function, it is simply not guaranteed to work in all cases of strange panel behaviour. All it does it disable FS's auto-acceleration when two different controls arrive. It sounds like a panel you are using is doing something involving the 1/2/3/4 engine selection. It works fine here with all default panels and most add-on panels I've tried. If it doesn't work with a specific panel perhaps you could ask the author. He may be able to help. An alternative method of engine selection is to use the advanced key/button programming features of FSUIPC to write the appropriate selection mask to offset 0888 using the "Offset Byte Set" control. For this you'd write 1 for Engine 1, 2 for 2, 4 for 3 and 8 for 4, 15 for all 4. Regards, Pete

Sorry, I can answer questions but not provide code. What is the problem? It is only a matter of setting a value in an offset. What part don't you understand? Pete

It was broken in 3.4x (not sure which version) and fixed in 3.50, so what you say is most odd. Can you try 3.505 (from the top announcement above) and let me know, please? Regards, Pete

I don't know NAVGPS nor the HP4700, but if you can write such an application I expect it is possible. The FSUIPC SDK gives you all the interface information for the FS side. You need programming information for the HP4700 and how to talk to it from the PC. Regards, Pete

That is not 60623 but -4913, You are reading it as a 16bit unsigned (U16) whereas it is in fact a 16-bit signed. All you are seeing is the maximum reverse thrust setting. Yes, exactly, except 65024 is -512 etc. You need to read SIGNED values! That is the same for all aircraft with reverse thrust, except that the stopping point is different for each according to the AIR/CFG file max reverse parameter. The FS decrement is 512 -- so it decreases first for 0 to -512 then to -1024 etc. Because you are reading it incorrectly. It is a signed number. There are no such numbers as 65024 in a 16bit signed number, the only possible range is -32768 to +32767. You need to read a little about computers to understand numeric representations a little. There is absolutely no difference in the reverse thruat arrangements in your aircraft from any other FS jet aircraft. Regards, Pete

FSUIPC doesn't actually care about the name of the FS executable. I have even just tried it here -- renaming FS9.EXE as FSGW.EXE works fine, and FSUIPC functions as usual. If it doesn't work there there must be more drastic changes that have been made. What are the symptoms? Incidentally, if all that is needed is for FS to load a different CFG file (which as far as I can see if all that you achieve by renaming the EXE), why not simply load FS from a shortcut with a command line parameter in the form "/CFG:name"? Regards, Pete

The trouble is, I think it may be a new controller board, not just a firmware update, so even if they could do it and could could change the wiring to it, I doubt that it would be a cheap upgrade. What do you mean by "locks up"? I can enable them all here with no ill effect (I still have an ordinary Jetliner console too). All that happens with the trim inputs enabled is that, if (and only if) any such inputs arrive, then they are obeyed. But none should arrive. Possibly, for some reason, your controller board is providing such trim inputs with spurious values? Can you check? Try logging the axis inputs (one or other of the options on the Test page). Well, the warning would need to be applied to the main controls as well. It is possible to have no axis inputs (Jetliner yokes can be supplied which are direct-connected to the PC, same with rudder). In fact almost any mixture of inputs is possible, so the only sensible warning is "don't enable this unless you have it connected". But isn't that, like, common sense? Regards, Pete

Only the throttle -- F2 is default assigned to "throttle decrement". If it is at zero, then F2 does make it go negative. That's how it works. If you are not seeing that you are looking in the wrong place. Regards, Pete

It's actually "Dowson". Only one 'n'. That was a long time ago -- almost a year in fact! Please check the "supported releases" announcement near the top of this forum, where you will see that the latest GPSout, version 2.60, does feature all those changes done way back then! Regards, Pete

Assuming you mean reverse thrust, then this is simply the same as a forward throttle setting except it is negative. Whilst full forward thrust (100%) is obtained by a throttle setting of 16384, the maximum reverse thrust is less, varying from aircraft to aircraft, but usually around 25% -- ie -4096. You can read the maximum reverse (i.e. minimum thrust value, going negative) at offset 0B00, as documented. Also, if you look at the document entries for the separate throttles (e,g, 088C for Engine 1) you will see they are described as "Throttle lever, –4096 to +16384". Didn't a negative throttle value suggest reverse to you? Regards, Pete

WideFS doesn't link one FS session to another. It links client PCs not running FS to a server PC which is. In that situation, FSUIPC on the FS PC will recognise any buttons pressed on any joysticks, EPIC devices and GoFlight modules connected to the client PCs running WideClient -- the latter sends them to WideServer inside FS and that talks to FSUIPC. However, provided you are not going to be using WideClient to support application programs (using FSUIPC) on a client which is also running FS, you can set a parameter inside WideClient.INI to make it use an alternative Class name, in which case it will load and run even with FS running on the same PC. This may certainly allow you to do what you want to do. Regards, Pete

I don't issue nor have a record of registrations I'm afraid. You should be able to retrieve the details though -- please see the sticky announcement above about what to do if you lose your key. Please, next time, make a backup of your FSUIPC.KEY file, or a hard copy (printout) of your details. Regards, Pete

LOL! Actually I'm not away till tomorrow. Pete

Only trims which alter the main control do that. ;-) Pete

What address in what program? Sorry, you need to be a little more explicit. Are you writing a program, designing an aircraft, or merely trying to calibrate a throttle quadrant? What programs are you using? Is this with FS2004? Pete

If you don't mind losing the view options on one of the right-hand rockers you could program one of those for electric trim. Or you could use the buttons fore and after if you prefer. Regards Pete

It is easy enough to check. Go to the flight Controls page of PFC.DLL options, watch the elevator values being read whilst you move the trim whhel. If they change, then it is only a trim pot altering the elevator input value. That's what happens here -- it alters a centre zero reading, input value 69, between 46 (output -2304) at "full" nose down trim, and 87 (output +3328) at "full" nose up trim. This is hardly the full range you may need in any case. Really, if it is truly operating as a trimpot on the elevator axis, then it is best to keep it centred. Once it is off-centre you'll get less range on the elevator in one direction than the other -- it may effectively distort the response altogether. It would be similar to those levers on CH yokes which offset the pot's centre position. Play with it and see what I mean. Of course it could be an adjustment performed in the firmware on the controller board, in which case this wouldn't be so much a problem. If you have a Jetliner yoke, or any of the PFC yokes with the trim rockers on the handle, use those for trimming. Incidentally, I've not had time to check but I think that if the trim axis is actually wired up then the appropriate page in PFC.DLL's options should see it and operate with it. On the Jet Cockpit all three trims (elevator, rudder and aileron) are actually separate axes and so feed directly the trims in FS. Regards Pete