Pete Dowson

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

Six -- three with Run and 3 more with RunReady. That should be perfectly clear in the WideFS documentation. Isn't it? FSUIPC allows a further 16 -- up to 8 by Run and another 8 by RunIf. That too is explicitly stated in the documentation -- in fact in the first paragraph about the Programs facility in the Advanced User's Guide. Pete

Sorry, I didn't even know there were FS-controllable operating doors until recently -- I thought those were fiddled special graphics effects using things like spoiler or flap settings. Inside FS I have found just one indicator for doors -- for the main doors only. This may simply be the usual trouble with the interference of multiple controls being sent every second by complex panels -- I assume it is complex panels you are using? The same problem causes difficulties like the acceleration of changes to the heading, speed and other settings (for which I provided a "work-around" in FSUIPC). The difficulty is easily seen if you try to use FS's pushback. You press Shift+P to start the pushback. That's fine. But then you press 1 or 2 to turn you left or right (or whichever way it is). If any other control comes between the Shift+P and that 1 or 2, then you are sunk -- it will not be directed to the correct part of FS. The Shift+P mode is closed, finished, not taking any more input. I think the Doors are controlled by something like Ctrl+E (or is it Shift+E?) then the door number (1, 2, 3 ...). Isn't that right? This will be working the same way as the pushback -- and if any other control is seen by FS between the Ctrl E and the number, that's it -- the selection is done. (The result should then be that the default, the main doors, are operated -- is this so?). I really don't know what the answer is unless you dispense with the panel. It's not really a fault in FS -- though a design that needs a follow up like that is bit flawed in my opinion. For the pushback I did experiment with setting the 1 or 2 as a parameter (programming it in FSUIPC's Buttons or Keys), but that doesn't work. When MS were questioned about this sort of thing, in relation to the unwanted acceleration of A/P values, they did imply that the panels which are doing this continuous sending of controls are really not designed correctly. Of course they didn't outright condemn them as "bad". Regards, Pete