Pete Dowson

That's a real puzzle then. I'm sorry, but I think you have to look to the software in the PDA. Did you prove to yourself that the FS PC end was still sending? That is easy enough with PortMon. No. My abbreviation "RMC" stands for "GPRMC". The GP ones are all the standard NMEA-defined ones -- I just left off the standard "GP" part in the parameter definition for the INI file. The "PGRMZ" one stands for "Proprietary Garmin sentence Z". I don't know the prefixes PFSR, LXWP and so on, only the GP ones and a few of the Garmin ones. Regards, Pete

No, sorry. It is unlikely to be stopping from the FS PC end -- there's no flow control in GPSout, it simply keeps sending stuff. You can check that with "portmon" (a free utility obtainable from http://www.systeminternals.com). Run it before FS. Maybe there's some restriction in the PDA software? What sentences are you selecting in GPSout? If you have too many selected 1 second may not be enough time between them. The 4800 speed works out to 480 characters per second max. You need a good gap between them, so say 400. With an average sentence length of perhaps 60-80 characters that only allows 6-8 different ones. Even then things might get clogged up in the PDA. Try (1) increasing the time from 1000 to 2000 or more, and/or (2) only one or two sentences at a time. Do you know which sentences your software is expecting and needing? Regards, Pete

1. Please turn your Caps Lock off! 2. This IS the Forum! :roll: You are IN the Forum to read my messages and send yours. How else are you doing it? Look up the list of messages and you will see Announcements and other special items of useful information ("Stickies") at the top. Pete

Yes, as per the Read.Me from Microsoft (!) you need to update your very old copy of FSUIPC. Please refer to the announcements at the top of this forum for details of current supported releases. Yours pre-dates the release of the FS9.1 update last September! ("40901" = 1st September 2004, "30612" = 12th June 2003, the original FS2004 release). Regards, Pete

I don't think those signal lines can do that. If they are the wrong way round nothing gets transferred, that's all. Regards, Pete

All that means is that, at the time you looked, the incoming throttle value for FS was 8255 and, because you are not calibrating the throttle in FSUIPC, it is going straight through to FS unchanged, i.e. as 8255. If you move the lever then both values will (should) change -- but they will be the same unless you elect to calibrate in FSUIPC. Again, that's just one value. As you move the throttle lever the values must change -- if they don't the lever isn't working! The values should run through many different values. The 16380 value is just a maximum default used in FSUIPC. Why don't you try calibrating the throttle in FSUIPC? It isn't actually doing anything at all at present. All you are looking at are the values of the throttle figures as they pass through FSUIPC unchanged. Regards, Pete

Just enter ALL three parts of the registration as before. You are making a mistake somewhere. If you kept your FSUIPC.KEY file you could cut and paste from there, or else use the details as originally notified. Regards, Pete

Same place as the programs themselves, inside the exact same ZIP package. Go to http://www.schiratti.com/dowson and download FSUIPC.ZIP and WideFS.ZIP. Regards, Pete

Okay. It was easy enough to do. I've added another one byte offset, as follows: Try it -- test version 3.485 attached. Regards, Pete FSUIPC3485test.zip

That sort of thing can happen if one of the keys is an illegally generated one -- in this case presumably the FSUIPC key looks this way. If it is a properly purchased key then I need to investigate. Please ZIP up the FSUIPC.KEY file (with the FSUIPC line intact), and a copy of the email notifying you of the key and other details (e.g. from SimMarket), and I'll get on to it. Send the ZIP to me at petedowson@btconnect.com. Regards, Pete

Well, don't rush at that unnecessarily. I've put the idea of a flag in FSUIPC on my list. :wink: When I get to do it I'll send you a test version. Regards, Pete

Yes. Just copy in the correct DLL. Regards, Pete

It has? That's news to me. Ah, there's a "Rest Flight" in the Flight's menu. Is that what you mean? It's the same as the control usually invoked by Ctrl+; Ah, yes, you DO mean "reset flight", also known as "reload flight", as basically is does just that, reloads the last flight. In fact "reload" would be more accurate, because if you've saved a flight since loading one, it is that last saved flight that will be reloaded, it won't "reset" back to the original. You will find that to be a very important difference if you use something like my AutoSave module to do regular saves automatically. You wouldn't use 3110 to send a KeyPress like Ctrl+E. You use 3110 to send controls to FS. Controls are the things which can be assigned to keypresses (in FSUIPC and in FS) or to buttons (in FSUIPC and, yes, in FS). There's a list of controls provided in the FSUIPC.ZIP package, so you should have one somewhere. Controls have a name (as listed in the FSUIPC drop-downs, and used in the FS9.CFG file, in the Keyboard and Joystick assignments sections) and also a number -- the numbers are listed against the names in the document I provided. To make FS action a control you just write its number to offset 3110. FSUIPC then does it for you. What does Ctrl+E do on your system? Is that assigned to the Engine Auto Start? If so then the control is "ENGINE_AUTO_START" -- you can look up the number for that in the list. I'm pretty sure the control normally allocated to the Ctrl+; keypress is "SITUATION_RESET", so you'll need the number associated with that particular control. Regards, Pete

Yes. Go get the current version of FSUIPC (3.48). It sounds like the PMDG package you installed put a very old version of FSUIPC into the FS Modules folder, one which pre-dates the release of FS9.1 last September. I assume their package is that old too? The changes made by Microsoft in FS between 9.0 (dated "30612" = 12th June 2003) and FS9.1 (dated "40901" = 1st Sept 2004) were substantial, and the versions of FSUIPC available before then will not run -- in fact if they tried they'd crash FS in rather complex ways. Luckily FS9.1 looks like an incorrect version of FS to its checking. Incidentally, the Microsoft READ.ME for the FS9.1 update does include a warning that you will need to update your FSUIPC -- obviously any version pre-dating 9.1 will not be aware of it. It's a shame not many folks read READ.ME documents. :cry: Regards, Pete

No. The various means of braking (brake control, brake axis, parking brake, autobrake) all just increase and/or maintain brake pressure. Correct. They are actually implemented by FSUIPC, not FS, for compatibility with FS98 and before. The braking system changed in FS2000 and those offsets did nothing otherwise. Not really, not at present. I could set a flag someplace when I see a brake control or a brake axis increment. For the brake axis input I could actually make a copy someplace or the axis value, but that cannot be applied to the normal brake control (i.e. the one by default associated with the . keypress or F11/F12 separate left/right brakes). Maybe just a simple one byte count -- increment it each time I see a brake control or an axis increase, decrement it once per second or so, say. I would need to experiment to find the best compromise. Obviosly the flag would have to remain non-zero long enough for programs to see it. Regards, Pete

I don't know what you mean by "reset FS", but all of the controls you can allocate in FS you can also allocate in FSUIPC, and many more. If you know what control you used to "reset FS" (whatever that means) it will appear in FSUIPC drop-down lists too. Why an offset? If you are programming things you can send controls via an offset too. Check offset 3110. Regards, Pete

Why not? Use Key2mouse to convert keypresses to mouse clickes, use FSUIPC to program the keypresses from your buttons and switches. Regards, Pete

Don't they provide keystrokes? If not then you are probably stuck with mouse operation. PMDG were originally going to produce a development kit for folks to interface external switches and hardware, but if they did it was never released. If they are using FSUIPC offsets for any of it I don't know what they are, but most likely the overhead stuff is contained inside their own modules and gauges, not in FSUIPC address space. I really think you should be asking PMDG these things. Perhaps they haven't been under enough pressure on these points, otherwise we may just have seen the SDK by now? Regards, Pete

I'm not sure exactly wat you want to accomplish, but if it is just that you don't want to see parts of your aircraft -- window frames, wings, whatever -- when looking out of the windows at other angles than direct forward, then you need to edit the FS9.CFG file and set the "SEE_SELF" parameter in the [GRAPHICS] section to "0" instead of "1". I think this only affects the 2D cockpit view, not the virtual cockpit (where it wouldn't make much sense anyway). It won't affect the normal forward view, which is merely a bit-mapped background for the main panel parts. You remove the panel by pressing W (once gives you a mini-panel, twice removes that too). There's no way to make your aircraft completely invisible to others (e.g. in the spot plane or tower views) unless you can design an invisible model (i.e. one with either no graphics for the body, or possibly completely transparent graphics). Whether that is possible or easy I don't know. You'd need to ask an aircraft designer that question. Regards, Pete

There appears to be something wrong with your keys. Where did you purchase them? I can find no record of your name or email address here (but I don't have a complete list anyway -- perhaps you bought them at the Japanese website?). Please Zip up your FSUIPC.KEY file (it is in the FS Modules folder) and send it to me at petedowson@btconnect.com, and I'll check them out. Regards, Pete

I see. Isn't that somethong covered by Bob Church's helpful docs in http://www.stickworks.com? (Look for his CMNOTE02.ZIP). Regards Pete

Ah, so after all that it was some bug in Autoroute 2001? Well done! Regards, Pete

But the two have not got anything to do with each other! The "above" text you quote is not a warning, as you seem to think! You are simply reading text on the About page. PLEASE look again in the FSUIPC.ZIP package (or download it if you never got it). You will find a full set of user documents. Browse through the User Guide. That shows all the User Functionality you don't get till you register. Absolutely none of that is anything to do with support for application programs. It is about additional user facilities added above and beyond the basic function as an interface for programs to FS. Hmmm. You are using version 3.47 which was replaced by 3.48 some time ago. Please check the announcements at the top of this forum which lists supported versions. However, I can still help, but not a lot I'm afraid. This section of the Log: shows that something in the aircraft you are using is written to interface to FSUIPC in the wrong way. It is using a method which has been incorrect now for over five years (actually, since FSUIPC was introduced for FS2000). Because of this there is no way for me to identify it, nor is there any way it can ever be accredited for use freely with FSUIPC. Furthermore, because of the incorrect way it is programmed it is actually rather a hazard to other FSUIPC interface users. If you've never had a problem before you have been lucky, or you simply have not used many programs which interface to FSUIPC. Hmm. Circles? Sorry, some of those must have been elsewhere then, as I think I've replied to you twice in quite a short space of time. I'm sorry if it seems so frustrating, but not many of those circles have intersected this Forum, have they? Really, I'm afraid that the only way to resolve this is to either select a different aircraft, one which does not have a gauge incorrectly trying to interface to FSUIPC, or, possibly, to ascertain which gauge it is by a process of elimination (i.e editing the PANEL.CFG removing one gauge at a time) and thence finding a working replacement for that one gauge, or possibly looking for an update which has been fixed. If you do choose to pay for and register FSUIPC then I expect it would work as well as it did before (at least it would bypass this accreditation check), but I would warn you that as more and more programs, gauges and DLLs use the correct interfaces to FSUIPC, the very few remaining Gauges which do it wrongly like this do stand a chance of causing problems. You can see from the Log that SB3 itself already uses two DLLs which interface legitimately to FSUIPC: Regards, Pete

I'm not sure about that bit about "etc etc", but certainly unless you register (.i.e. purchase) FSUIPC 3 you do not get the full facilities. If they are freeware aircraft using FSUIPC then there are most likely freeware keys available for those. Or possibly there are updates which have those keys built in. Look in the FSUIPC,LOG file to find out which individual gauges you need to register. Registration started with version 3, that's why. No. VATSIM uses freeware software, all of which has free access to FSUIPC 3. You do not need to pay for FSUIPC to fly on-line. Regards, Pete

It would have to be that in any case for the separate throttles with reverse range, but the single throttle axis has no reverse range, so then your "J" curve (actually the upper part of the S curve) will do. Pete