Pete Dowson

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

Erthe trim wheel on my Jetliner Console affects the elevator axis input -- there's no separate trim wheel input into my driver. If PFC have revised the Jetliner Console with additional axes, they've failed to inform me of any of the details. Please get back to them and clarify this. I'm rather busy today, then I'll be away from tonight (Tuesday eve) until next Tuesday, 1st November, so it would be better for you to re-check. Isn't the trim wheel a little thumb wheeled pot to the left of the pull/push parking brake switch? Regards Pete

I don't have a web site, only this Support Forum. Possibly you mean the Schiratti web site I referred to? But first, surely, you downloaded FSUIPC.ZIP from the website. If you did, then just read the documentation inside. If not, go and download it. No. That would be silly, because the document is INSIDE the Zip file, so how could it tell you that? This is what it explains early in the documentation. It is part of the reason documentation is written and supplied in the first place! User documents are provided to help users, who are therefore asked to read them. It is a lot easier and quicker that getting confused here is, really! Please just go and take a look, eh? Regards, Pete

You purchase a key, not "a full version of FSUIPC" (there IS only one version). As explained on the site where you ordered the key, you download FSUIPC from any site which carries it, the most usual one being http://www.schiratti.com/dowson. However, this is an odd way to do it -- normally you'd download it, take a look, read the documents, then decide whether you want to part with any money! If you are using Windows XP you don't need to "work with ZIP files" -- Windows will open the ZIP for you, just double click on it. If you aren't using WinXP, then apart from advising you to update soon, you will need to find a free copy of WinZip or similar. Then, the user documentation is inside. Just read the first few pages to start with. Excuse me for asking this, but I'm not sure why you've bought it if you don't know what it is for or how to use it? Are you sure you haven't just wasted your money? Regards, Pete

Sorry, it isn't my area. I don't even know DirectPlay. Maybe someone else here can help, but you may like to check other technical (programming) forums too. I don't think VB has many easy provisions for using the sorts of interfaces FS provides. Regards, Pete

Not using muliplayer, no. You can get user and AI aircraft positions from FSUIPC, but to use multiplayer you have to program to the multiplayer interface, not FSUIPC. I think there's an official Microsoft SDK for it -- check Microsoft's FS website. Regards, Pete

But Version 3.50 is most definitely later than 3.47. The 8/30/05 1220pm is correct for 3.50 The 10/5/05 502pm version is not one I have released -- the most recent one is Interim version 3.505, available at the top of this forum. That is dated 9/16/05 0013am. I certainly released nothing on the 5th October, I was on holiday still then, somewhere in Ecuador! Maybe some program you have changed the date on it. To verify the real details, right click on it, select Properties then Version. Regards, Pete I do not remember doing this before on other versions. Thanks Rocky

Okay. It was easier than I thought, and I was misleading myself with the Debug/Optimising differences. It was, in fact, only differences in the INI file. The problem is simply that if you go into the dialogue and make a change ONLY to a slope (or several slopes), then on confirming and exiting from the options, FSUIPC is not writing the changes back to the INI file. I stupidly omitted to add the slope tables to the things it needs to check on exit. I can fix this quite easily and will do so in the next interim release, but I have some other little things to do first. Meanwhile, there are two solutions for you, both of which are better than going in each time and making the change on every reload: 1. You can simply add the SlopeRudder=n parameter to the relevant INI section manually (n is -15 to 15, as per the number in the Slope display). You can do this for your other axes as well -- currently you have no slopes set. 2. Alternatively you can use the options dialogue but just be sure to change something else too. It need not even be for the same axis. just toggle a Filter checkbox or similar. Go in again and toggle it back if it matters. The slopes will be saved for all axes on any other changes, they are only omitted when nothing else changes. Thanks for spotting and reporting this error, and apologies for the temporary inconvenience. Regards, Pete

I can reproduce the problem with rudder. I'll double-check the other axes. You say the slopes are working on those, BUT there appear to be no slope values stored in your INI file. the slopes are NOT given by that /n value -- that value represents a set of flage for the other options, like filter and reverse. Slope parameters are like this: The problem appears to be that the "SlopeRudder" parameter isn't being written. [LATER] No, that isn't it either! I'm not sure what is hapening there. It is rather odd. I recompiled FSUIPC in Debug mode so I could trace through what was happening, and then it works okay! There's some difference between the optimised issued code and the debug code. I hate that sort of problem, it is very difficult to isolate. And I've not got a lot of time this week. I'll see what I can do, but it may have to wait until next week (i.e. November). Sorry. Regards, Pete