Pete Dowson

No, 32 buttons. There are 8 extra "buttons" which are derived from 8 cardinal directions of a hat -- this is following an old convention in FS to number the 8 driections 33-40 (32-39 counting from 0). The restiction is not FSUIPC's, but the Joystick API it uses. That only provides one 32-bit value to indicate button settings. DirectInput (used in FS since FS2002) allows up to 64 buttons per joystick as far as I know. A device providing 256 buttons won't be usable in that way on FS or FSUIPC. In fact I don't see how it could be used unless either they split it into 4 or 8 "virtual" joysticks, or only allow it to be programmed by their own drivers. Please read the discussion on this exact question in the FSUIPC User Guide. Regards, Pete

I've found a problem with button operations which is to do with a recent change to use a separate thread for button scans, to speed things up a little. I don't know how it affects PMDG -- so far the only bad result I know of is the operation of the extra "Traffic Density" controls offered in FSUIPC. However, I'll send a test version to you (3.217). Let me know if this fixes things. Regards, Pete

Okay, so you mean FS is crashing when you use the dials. Now, what about the other questions? Are you programming those dials in the GofLight driver, or in FSUIPC? If in FSUIPC, are you programming them with keystrokes? If so, what keystrokes and do they work when using the Keyboard instead of the dials? You see, some sort of process if identification and elimination is needed even before anyone can start looking. If you are doing this with FSUIPC I also need to know the precise FSUIPC version number, please. When you uninstalled did it remove the DLL(s) it installs into the FS Modules folder? The active component may be there. Are those there now dated for the 800/900 release? Regards, Pete

No problem, don't worry about it! Good flying, Pete

I have EPIC buttons here which work okay, but on a USBEPIC. FSUIPC only recognises the change from the button state being zero (off) and non-zero (on). For normal buttons this should be okay. I see you are using "BtnToggle" for the Enque action. Why? Please read my Epic documentation. For "BtnToggle" it reads: which explains EXACTLY what you are seeing. Please consider how you want to use your buttons and select the more appropriate action. Just a simple BtnPulse might be okay for this sort of use, but if you want to be able to hold it pressed for repeat actions you program the On and Off for press and release separately. That doesn't access the buttons through the VXD at all. You should check things with my own utility, IsEpic or something like that. (Sorry, I've not used an ISA EPIC for many years -- I have no computers left with ISA slots!). Also check the buttons with the Windows Game Controller. Regards, Pete

Can you explain by what you mean "not exiting FS9"? Are you configuring some Keystrokes in FSUIPC for the new PMDG aircraft which do this? Or is this something special in the GoFlight drivers for PMDG? If you are configuring keystrokes in FSUIPC, do those same keystrokes work on the Keyboard? If not then it is obviously a case for PMDG support. Regards, Pete

There are two ways that I know to link two or more copies of FS -- one is FS's own multiplayer, the other is WidevieW (not WideFS, note -- WidevieW is by Luciano Napolitano -- see http://www.wideview.it). Regards, Pete

I think you would have to read the AI aircraft data (supplied for use in TCAS gauges and the like) and somehow work out where the turbulence areas would be, second by second. Obviously you'd disregard light aircraft and maybe even only concentrate on the bigger jets. Then, when the user aircraft passed through an area you had worked out as turbulent (bearing in mind that this will be moving with the air mass, so you need to adjust for wind speed), you could try to impose turbulence on the aircraft -- maybe through control interference, or maybe trying to write to some or the assorted accelerations and velocities (those used for aircraft carrier catapults and tail hook operations). I'm sure it could be done somehow, but it would take someone far more knowledgeable in spherical trigonometry and fluid dynamics than I, and it sounds like a lot of work, indeed, much of it experimenting to see what might work. Oh -- a fast machine would help too, once the computations get complicated! Regards, Pete

No, it is completely impossible. FS's gauges are simply data management routines which use the graphics power of FS itself to display. They cannot run outside of FS. You would need to install a full copy of FS on the other PC and link the two installations of FS with WidevieW. I suggest you investigate third party cpckpit offerings such as Project Magenta, and maybe FreeFD. There may be others. Links are provided on the right-hand side of the http://www.schiratti.com/dowson page. They interface to FS via FSUIPC and will therefore also work through WideFS. Regards, Pete

Okay, I looked at the log. There's no terminating zero in what you write to 8001, so the comparison check being done by FSUIPC will depend on whatever other rubbish might be there before. when that is zero, it'll work, when not, it won't. If you still have problems after correcting that, let me know, with the same sort of data please. BTW for DLLs, FSUIPC automatically also makes an entry in the KEY file, so you should check that next time too. It does this because it renews the accreditation scan every time an aircraft is loaded -- GAUges of course load with aircraft. Since the same mechanism is used by Gauges and DLLs, but DLLs may write 8001 only once at the start, it has to remember the details (which it does in the KEY file, as it has to check that in any case), so it can check without the 8001 write recurring. Regards, Pete

Values. All things are values unless it specifically says that the variable consists of a set of bits. Of course in this case it doesn't really make a lot of differnce. The value is a BOOLEAN. In C/C++ a boolean "TRUE" value is anything non-zero, whilst "FALSE" is zero. However, the normal "TRUE" value used is consistently '1'. Regards, Pete

Of course you are rightI thought FS2004 complicated it by allowing payloads (see for instance the FSUIPC variables at offsets 1400 ff.) but of course they will be included in the ZFW. Won't they? Pete

:D Well, when I get back to my model railway (N-gauge filling a 16' by 12' room), it will be to convert my Amiga 500 based controller software to run on a PC Notebook. Regards, Pete

Which one is that, please? I can see here if it has been given a Key. Does it register itself, or did you register it manually? Please run that with both IPC reads and writes logged. Send me the LOG and also the KEY file, zipped please, to petedowson@btconnect.com. Perhaps if you include the DLL so I can reproduce it here, it will be quicker. That effectively means the same thing -- 0's are suppliied if it thinks the DLL is not accredited. The warning message normally only occurs at some stage at most once in an FS session in any case. I suppress it at other times to avoid multiple message boxes and/or filling the disk up with log entries because the unaccredited DLL keeps retrying. Also, whether the DLL access is accepted without a Key is random -- the whole area is deliberately complex to dissuade piracy, you see. :wink: Regards, Pete

Evidently. For each of the (11 I think) possible tanks there's a capacity value and a percentage value. The fuel level in each is therefore calculable, and the total is obtained by adding them all up. The capacity variable is right next to the percentage value in each case. How could you have not seen them? Regards, Pete

Sorry, I have no idea what they've done. PFC.DLL only handles the FS spoilers. If they've invented their own, then there's nothing I can do. I can only suggest you find a spare button and program it to send the appropriate keypress, assuming they have one. For PMDG support I'd really recommend you check with PMDG. Perhaps there's something in their documentation? Regards, Pete

AhI did wonder when you were calling it "FliteStar" not "FliteMap", but since you clearly thought it had the moving map capability I naturally assumed you were simply using the FliteStar/Map naming interchangeably. After all, except for that feature, I think they are identical. No problem. Sorry it turned out not to be quite what you wanted, but at least we understand it now! Regards, Pete

Sounds feasible. You'd need to write a program to drive the output you need, interfacing to FS through FSUIPC. If you download the FSUIPC SDK from http://www.schiratti.com/dowson you will find all the documentation you need (sorry, in English only), plus parts for different programming languages. Regards, Pete

If it is the latest version, and installed into FS's Modules folder, there's nothing which will stop it sending sentences out to the selected COM port, assuming that is available. If it is an old version you need to install FSUIPC as well. And did you edit the GPSout.ini to tell it this was the one to use? Did you plug the cable into COM1 and not another? Did you ensure that the speed is set the same in GPSout.ini and FliteStar? Isn't there a Test option in the Connection menu, where you can see the data arriving, even if it isn't liked? There's really very little to go wrong with GPSout, it just sits there sending stuff out. You just need to get the ports and speeds matched. If the sentences aren't those that FliteStar likes, that can be changed, but first you have to see sensible characters arriving in the "test" window. Regards, Pete

Hey, thanks! I've downloaded it -- I'll enjoy it later today! :D Pete

Ah, when I have a little more time perhaps :wink: Meanwhile there's quite a bit of background about, in bits and pieces. Try the threads "How was FSUIPC possible", and "Will the real Pete please stand up". I'm sure there are others. As for "steam railways", they are still about you know, though diminishing. Have you none in your part of the world? There are many running here in the UK as preservation or museum lines, but my wife and I like to travel to parts of the world where they are still used, albeit not a lot these days, for 'real'. :D Regards, Pete

Well, I have added offsets for Prop De-ice and Structural De-ice, both of which are documented in FS's Panels SDK for FS2002 and FS2004. However, there is no mention of how to get an aircraft to actually implement the structural de-ice facility. It doesn't appear to be an AIRCRAFT.CFG file option. Maybe it can be enabled only in the AIR file, but at present I am unable to test this offset because I cannot find any aircraft which implements it. As far as the Prop de-ice is concerned, the default King Air implements this and it does appear in its AIRCRAFT.CFG file. However, the Toggle Prop Deice control doesn't operate it -- only the usual anti-ice switch. I can read the setting of the prop de-ice for the offset, but since writing to it uses the control, which doesn't work, it's pretty much useless. All in all it was a futile waste of time I'm afraid. I'll leave the code in, and hope it becomes useful in a future version of FS. Regards, Pete

Sorry, you'll have to do that yourself, or ask the author for an automatic running version. Regards, Pete

What's a context menu? I don't think I do any of those. I don't use tooltips either -- do you mean the "connected" message in the title bar? Ugh. There's something wrong there all right, but no specific failure reported from Windows. Very odd. All I know about Networks, and more (thanks to other's contributions) is embodied in the WideFS DOC. Once you've gone through all those possibilities and there's still something wrong I'm afraid I've had it. I hope some Netwrok expert can help you out here. You could try Katy over in the FS2004 Forum, she's helped me a few times. Incidentally, the ONLY time I've ever seen blocks actually being corrupted, as this indicates: 4492109 LAN data received: PREQ ulSize=1116, ulTime=146968, uSum=46782, fUsed=0 CC 02 00 FE 05 00 9A D0 2A 13 94 60 30 00 FE 17 4492109 --> Sumcheck error! was when I most definitely had a bad Network Card. No, it can't be the application, and it can't be WideFS either -- as you yourself can attest with 7 other PCs happy. It's going to be hardware or software drivers, more likely hardware. Possibly the Network card, or the PCI socket it's in (if not on-board) or the on-board Network chippery (try a Network card instead -- they are cheap these days in any case), or possibly just the specific port on the Switch (try swapping it with one of the others). I would also have suggested cables, but you say you've tried that already. Regards, Pete

Full screen display of windows over FS is very precarious in FS2004. When I asked Microsoft about this (I thought it was a bug) they said it was down to the way DirecX had changed, and nothing could be done excepting using the FS display system -- i.e. like a gauge. I don't even know how you have managed to make your window display okay when activated by menu. I got flickering. The FSUIPC dialogue gets around that by preventing the FS window from re-painting -- i.e. it intercepts the WM_PAINT and validates the paint area without doing anything. You could try something like that. There is a side effect -- if the user moves the FSUIPC window multiple copies of it will be left behind, because FS is prevented from repainting them. Regards, Pete