Pete Dowson

This was an occasional bug in an earlier version, fixed in this. Strange. Can you ZIP you FSUIPC.INI file up and send it to me at petedowson@btconnect.com please? It'll be tomorrow (Tuesday) before I can look at this I'm afraid. It's getting late here and this is my last scan through here before I retire. Regards, Pete

Sorry, I cannot support old versions. Please update to 3.70 and try again. There is nothing in FSUIPC which will produce such behaviour. you may need to ask PMDG support -- but read on. What option? If you aren't even registered then it is absolutely certain that FSUIPC is doing nothing with your throttle. The options for calibration and so on are only available to registered users. Sorry, but you really must look elsewhere for the solution to your problem, it is not FSUIPC. If it is PMDG which made it happen, please ask their support. But if it happens on all of your aircraft it is more likely to be a problem with your actual throttle settings in Windows and the sensitivity/null zones in FS. Check those first. Regards, Pete

On the very first page in FSUIPC options, on screen in FS, you will see a button lower right. Press it to enter application keys. That is why it is so labelled. For more details check the FSUIPC User Guide, it tells you how to enter Keys for applications., as well as a lot of other things about FSUIPC. That is what it is for. ;-) Pete

If you have a user registration, and you bought it this year, yes -- stop using such an out of date FSUIPC and get the latest one. Isn't that easy? :-( Pete

The announcement/sticky near the top rentitled Freeware application keys for FSUIPC does actually list a free key for AFCAD.EXE. Whether it applies to the version you use I cannot say, but if you want to try just follow the instructions for entering an Application Key into FSUIPC which you will find in the User Guide. (Note that if you have already registered FSUIPC as a User you won't need to do this, or, indeed, be able to). Regards, Pete

You are extremely out of date. 3.47 is sometimeback in 2005. The current version is 3.70. If you registered this year (2006) you need at least 3.53, as it said in the registration email you received and also in the top announcement here. If you registered last year or before, please check again with an up to date version, and let me know if you still have a problem. Pete

ErI have no idea what happened, but although your message is timestampec "Sat Jul 29, 2006 4:37 pm" I have only just seen it this afternoon (Monday) -- and I go check in here every couple of hours, even weekends. Sorry if you feel ignored, but something odd must have happened in the SimFlight server. Pete

No. There's no Network code at all in GPSout. It is aimed at programs written to receive NMEA standard data in the NMEA specified serial manner -- i.e. via a normal RS232 serial port (and actually specified at 4800 bps, but I do allow a better speed than that!). Pete

I've got one other report of this (making two only out of many thousands of registrations over the three years). I'd like to know if there's anything in common between your two machines, so I'm emailing you. Regards, Pete

It has not really been decided yet, but certainly the registration would need renewing (i.e. you'd need a new key). What sort of discounting there will be for recent subscribers needs to be worked out. A lot really depends how much work the new version turns out to be -- I wouldn't feel right charging folks again if I didn't have to do any work to make it happen, but equally I wouldn't want to have to work all hours for months, as I did last time, for no income. I expect some compromise will be decided upon which makes it fair to recent purchasers, but again I have no idea what "recent" would mean yet. And is FSX coming out as late as December or as early as September? You see, there are too many imponderables at present for me to help you decide. All I can say is that I'd certainly want things to be fair, in whatever circumstances exist by then. Regards Pete

Hmmm. Very strange. The registration window is just another standard windows dialogue. It sounds like it may either be a bug in the video driver you are using, or possibly a hardware problem such as faulty memory. Otherwise possibly something else, like "window blinds" is somehow interfering with the standard dialogue process. Are you running anything at the same time as FS? Do you have anything installed which changes Windows behaviour in any way? Sorry, I don't know what to suggest at present. See if you can find a different (more up to date perhaps?) video driver first. If you cannot find anything which clears this up, please get back to me and I'll see if I can add some extra code to give more information about what is happening. There's been no change in this area for three years, and, as I say, it is a standard Windows call to display the dialogue, so it is very puzzling. Regards, Pete

As I said, it's in the FSUIPC SDK. All information about programming ands interfacing to FSUIPC is in the SDK. That's what it is for. and it is on the Schiratti site, as it always has been, with all my other FS programs. Regards, Pete

With some space in FSUIPC offsets, you could simply assign a bit for each function and let your users assign buttons or keys to Set, Clear or Toggle the appropriate offset bits. You'd need to work out how may bits you needed (but I don't allocate less than 16 bytes at a time anyway, so that's 128 functions already) and ask me (petedowson@btconnect.com) for an offset allocation. Then explain to your users how to program Offset (Byte Word or Dword) Togglebits in the FSUIPC Keys or Buttons page. (See FSUIPC Advanced Users guide). I reaise this may look a little confusing but I feel it is far less so than assigning different FS controls with misleading names. Regards Pete

As well as what Patrick says, if it's an offset you need to change rather than a button or key to program, look at offset 2DC6. A simple search through the Programmer's guide (from the FSUIPC SDK) on the word "governor" would have found it straight away -- that's all I did. ;-) Regards, Pete

Not in any way I know, I'm afraid. Except maybe by reading the FS9.CFG file yourself? Unfortunately, for standard assignments for joysticks I think it leaves that in the default Devices CFG files. Of course, those are part of the FSUIPC Hot Button facilities (there are Hot Key facilities too). All this stuff is documented in the Programmer's Guide for FSUIPC, which is the prime reference document in the SDK. Surely you've seen it??? :-( Please don't rely on notes and comments in FSInterrogate files as the main reference. It isn't complete, it is abbreviated beyond recognition in places, and it certainly isn't guaranteed to be maintained nor accurate, though I do try hard. On the other hand the Programmer's documentation is meticulously maintained. Regards, Pete

Hmmm, an FSUIPC registration would help there then. I didn't realise you hadn't even bought FSUIPC! :-( Pete

No, I mean do one (1) process call for ALL the reads you want to do this cycle, not just arbitrarily bach them still with multiple calls to FS for no good reason. would you take separate trips to the supermarket to get three different things if you knew you wanted them all before you went the first time? You only need to separate them if you need the results of one read to decide what else to read, or to decide upon something to write. But that's a VB error, and the VB compiler or debugger will tell you precisely what is wrong, surely? That is why you use such a terrible language (my opinion, of course), isn't it? Because it is supposed to be easy? Surely it doesn't give obscure compile or runtime errors with no explanation? Sorry, but I cannot help with VB. Try me on C. Maybe someone else will help, but if VB never tells you where it failed I don't see how you can use it in the first place. :-( Regards, Pete

Sorry, I don't know about the mismatch (doesn't the compiler or debugger even tell you which line or variable has such a mismatch?), but your code is really enormously inefficient! Why are you calling FS for each little item of data separately? Please do all the FSUIPC_Reads, then one FSUIPC_Process at the end. The reads and writes cost nothing in PC terms, but every process call is swapping to Flight Sim, processing your requests, then swapping back to you. That's really dreadful! :-( The whole point of separating the actual request to FS from all the individual items is to enable you to write efficient programs. Think of the Reads and Writes being your shopping list, with the Process call being the check-out. Pete

I get that on some projects. Never found out why, and doing as it says ("NODEFAULTLIB") seems to make things worse. The warning doesn't seem to affect anything adversely so I learned to ignore it. Since I upgraded to Visual Studio .NET 2005 it doesn't happen any more, but that's an expensive solution if, like me, you want/need the Pro version because of the superior optimisations. In fact, considering I only use the C/C++ Native code part, and of course the Debugger, the whole package is ridiculously expensive, but you can't get the good optimising compiler on its own any more. :-( Regards, Pete

Please do make sure your users know, else they will just come here to complain! ;-) Regards, Pete

Sorry, I have no idea. Not having any CH gear nor, of course, the CH manager, I am not in a position to judge whether it does anything better or not. If no one else chips in with advice or experiences maybe you should visit Bob "Sticky" Church's place, http://www.ch-hangar.com. Regards, Pete

Hmm. I found this in one of the Microsoft headers: /* * VK_L* & VK_R* - left and right Alt, Ctrl and Shift virtual keys. * Used only as parameters to GetAsyncKeyState() and GetKeyState(). * No other API or message will distinguish left and right keys in this way. */ #define VK_LSHIFT 0xA0 #define VK_RSHIFT 0xA1 #define VK_LCONTROL 0xA2 #define VK_RCONTROL 0xA3 #define VK_LMENU 0xA4 #define VK_RMENU 0xA5 which would make Left Control 162 in decimal. You could try that, but I cannot guarantee it as it seems to imply that the API I'm using won't support it. It may just work if it passes through the values I give it unmolested. Otherwise, is it not possible to change the program's assignment? Regards, Pete

Erthat certainly sounds very unlikely. Are you really saying that you changed the DEFAULT flight to use these different aircraft and restarted FS each time, and it failed at the start each time? If so then it is more likely to be a DLL you have added in the Modules folder. Very few aircraft gauges use FSUIPC -- except in the very sophisticated add-ons. The main type of FSUIPC-using gauge folks add on to the default aircraft are TCAS ones (which should be easy to identify) and, possibly, pushback or fuel control ones. But certainly you would have had to add these yourself to the default aircraft. It sounds like either you are not changing the default flight -- the one loaded BEFORE you even get to the main menu selection where you can choose another -- or, in fact, you have some add-on DLL which is the culprit. Pete

FSUIPC always logs details of flights and aircraft loaded. This part shows the problem: The aircraft you have specified in your default flight is using a Gauge which is using FSUIPC completely wrongly. It is using an incorrect access method, which can occasionally work (by fluke) but is inherently dangerous. The only way to reliably use such a bad gauge is to register FSUIPC as a user (i.e. pay for it), as that allows FSUIPC to bypass these access checks. However, that may not prevent later problems. If you ever have two such bad gauges, or a module doing the same sort of thing, then they will be exchanging data with FSUIPC using the same memory area and they will corrupt each other causing unpredictable results. Even if this gauge is a freeware one it is not possible for it to use an access key as it is using an illegal access method. Furthermore, it is impossible for me to tell you which gauge it is as the access method makes it look like it is FS9 itself. Your best bet is to run FS past that point and change to a different aircraft, then save a new default flight. Then find the culprit aircraft, and its PANEL.CFG file, and see which gauge it may be that is using FSUIPC so wrongly. Edit the panel.CFG to get rid of it. You may have to do this first if you can't get FS past it (because the gauge in question crashes FS, perhaps -- though it doesn't look as if it does). A more drastic alternative is to delete your FS9.CFG file and let FS build a new one, so it uses its default flights. Regards, Pete

If you are getting the same error, then you most certainly have not installed version 3.65. Please simply copy the new DLL into the FS modules folder. There's nothing else needed to be done! I don't need a log for that error. All you need to do is change to version 3.65. I cannot support old versions in any case. I'm not sure what the relevance of that is. Are you saying it was okay before you did that? Sounds like either that installed an old version again or it was a bad aircraft in any case -- but if so it wouldn't be an FSUIPC error you were getting. Pete