Pete Dowson

Well, the actual EXE code, by the time it is running in the process, is the same in the end -- this is how the crackers crack it. The huge size of the CD checking version is down to all the protection that is added -- not only CD verfication, but complex anti-hacking scrambling, and also code to spawn another process entirely, with a weird name, whose sole job seems to be to watch for debuggers. But this is really mostly irrelevant in this case, as the sizing and moving business is done though windows message intercepts. That's why is seemed strange to me. Regards, Pete

The default buttons don't affect joystick assignments at all. I think it must be related to something either in the button programming or, more likely, joystick calibrations pages. This is why I asked you to try it with NO FSUIPC.INI file (save your copy), so that FSUIPC starts off with no preprogrammed anything. If that makes the brakes work, then we look at the various things you have set in the Buttons and Joysticks pages. Okay? I am poring throgh the code now, but it would help enormously if we could narrow it down like this. Thanks, Pete

I have had one other such report, but I cannot reproduce it here, and I have not made any change which I know of which can cause this. Basically it doesn't care at all about the ordinary Brakes control. The new facilities in the "Fix control acceleration" option are identical for both keyboard and joystick controls and in any case don't do anything unless enabled. Since I cannot reproduce it, I am stuck in an information collecting mode at present on this. Can you tell me more. Like all default aircraft? Anything programmed in FSUIPC? Can you make a safe copy of your FSUIPC.INI file and delete it from the FS Modules folder, so that FSUIPC runs with defaults only? Is it user registered or not? Anything else which may be relevant that you can think of? Can you turn FF off in FS? Does that make any difference? Regards, Pete

Of course that is the reason. The only way it has of identifying the internal caller is by tracing the return address on the stack, looking for an address within a loaded GAU or DLL file. This is why, in the full log you saw, it gets all the addresses of all the modules loaded. Then it backtracks the stack till it finds an address corresponding to a listed Gauge or Module. That is how it identifies gauges and DLLs from internal calls, except for those programs which use the automatic registration systems supported (as this one certainly does not). Now on both my WinXP installation and my Win98SE installation, this process works well with the F16 gauge, the exact one I attached earlier. But on your system the stack is completely and hopelessly indecipherable. If finds no modules or gauges and cannot therefore identify the caller. Did you check out the Lee Hetherington TCAS gauge? Regards, Pete

Hmmm. Very strange. Thanks for letting me know. Regards, Pete

If you've lost it completely, please see the sticky thread above entitled READ THIS IF YOU LOSE YOUR FSUIPC or WIDEFS keys. If your registered install is still registered and working then the data is in the FSUIPC.KEY file. It is a text file. Regards, Pete

Sorry, I get no such result here. where are you seeing this? Check with FSInterrogate, or using the FSUIPC Monitor (on the logging page). By "disconnect"/"reconnect", do you simply mean FSUIPC_Close and FSUIPC_Open? Are you doing this from an EXE program? Pr a gauge or module? There is absolutely no way that influences the data being read or written. For an EXE program it merely closes a memory-mapped file and creates a new one. FSUIPC knows nothing much about that. In the case of an internal gauge or module, the Close does nothing but clear a pointer value (set from your data pointer in the Open2 call) which causes Reads and Writes to fail till you Open2 again. Please do some cross-checking, and some logging perhaps (FSUIPC does provide IPC read and write logging you know). If you still don't understand, please provide more information. Regards, Pete

Great! All's well thatwell, you know the line. :) Regards, Pete

Well FSUI is the Microsoft standard User Interface DLL. From your logs and all the other stuff, though, it certainly seems that FSUIPC is working well with FS2004 on your system. I just have no idea why that gauge isn't working. Sorry. Did you look to see if the Lee Hetherington one will work for you? I suspect there's something else installed on your system, a non-standard or different library someplace maybe, which makes that Gauge run rather differently. Your log shows no trace of it on the stack when it calls FSUIPC. Possibly it is calling it from a different thread than the main FS one, but this is unlikely and in any case it would be a problem then here too. Regards, Pete

No, they are wrong. I merely advised programmers that they could do it themselves. The electrical system is exposed in the FSUIPC interface. It doesn't take a genius to work out how to stop the battery voltage falling too far, just a reasonably competent programmer. Sorry, for users this option is just one of the many benefits of purchasing FSUIPC. I add more all the time, but I cannot really erode these. In any case it wouldn't be fair to those who purchased it already. Regards, Pete

Erthose two statements are not compatible. Show me this "normal" WideClient log please. You say "after like 2 mins", but in fact WideServer was only active for 84 seconds. Are you sure you gave PM enough time to initialise itself before closing FS down as you did? I find that the PFD in particular takes at least that long before it is in real interaction with FS in any case. When you say "crashed and shutted down", which do you actually mean? What sort of crash? How was it visible as a crash? How did it shut down then? I need to get a full picture. Have you changed any of the WideClient or WideServer INI file parameters, apart from the ServerName or IPAddr in the client? The changes in this version actually enable PM modules to connect more rapidly and reliably, so something seems very strange with you seeing the very opposite. Regards, Pete

I think that there must be something amiss with the F16 gauge you are using. I downloaded an F16 panel from Eric's site just to get the F16.GAU file, and have now tested it with unregistered FSUIPC installations on both Windows 98SE and Windows XP. With that "F16.gau= ..." line in place in the [Programs] section of the FSUIPC.KEY file I had no problems at all using it in FS2004 on either operating system. The log you sent is nothing like the sort of data I get, which always shows F16.gau on one of the analysed stack trace entries. Just in case your F16.gau is different, try the one attached, which was obtained from the F16 panel on Eric's home site yesterday. Regards, Pete F16gau.zip

Whatever the supported NMEA sentences support. Altitude figures in at least one of them. Attitude information doesn't figure in any as far as I know, but there is an unpublished mode specifically intended for a proprietary program which does include such data (but not rates I think) -- nothing to do with GPSs and standard NMEA sentences though. I suggest you check out the NMEA specs. I think there's a site which lists the more common ones, at least all those GPSout supports. Search on "NMEA 0183". If you do find a sentence type you need for a specific GPS or PC application which accepts them, let me know and I'll see if I can add it. But if you are thinking more in terms of writing your own applications and need information from FS, I would refer you to the FSUIPC SDK and advise using that interface instead. Regards, Pete

You are Dave, yes? No, sorry, I never got such an email that I can actually identify as being from you. But I would really only forward it to SimMarket in any case. Published codes get blocked in each new release and the original users get blacklisted at SimFlight, who will probably also take additional action. That counts as straight theft. The other violation is counterfeit codes, generated by illegal means. Those can give rise to all sorts of problems in FSUIPC and as a result I have already built up a list of about thirty suspected or confirmed dishonest users. I think it is just because it's there. :wink: And it's a cycle of diminishing returns -- the more effort put into protection, the more effort will be made to crack it. It's almost inevitable these days. I don't really blame the guys that do it so much -- they're just insecure lonely youngsters who want to prove how clever they are. It's the ordinary users who succomb to the temptation to save a few bob (read Dollars, Euros, whatever) and steal, maybe for the first time in their life, or maybe it is now a habit. Then things go wrong, and they expect support .... go figure! :) Regards, Pete

"Thanks anyway", what? Why? :? :shock: Are you implying you are entering the correct program name and key? The key you just showed me was certainly not correct. Can we talk straight on this at all? If you don't know what you are typing, just show me the FSUIPC.KEY file -- the details are saved there in simple text format. Regards, Pete

Well, you need to tell me what you enter into the program name field too. It should be just pmSounds. Anyway, the key you are entering is wrong. If you cannot distinguish between 1s and l's or 0's and 0's then you should cut and paste instead. The correct key for pmSounds is as listed in the FreeWare keys list above. i.e. The third character is a 1 (one) not a letter i, and the 10th is a 0 (zero) not a letter o. Two errors in 12 characters is pretty good going for error density isn't it? :wink: Regards, Pete

Yes. :wink: Please yourself, but why the "Jeeeeeeeeeez"? There's no easy reference downloads in Forums. The main download site for ALL my software has always been kindly supplied by Enrico Schiratti at http://www.schiratti.com/dowson (for at least for 6 years, maybe longer), and that is published in my documentation, and in the appropriate Announcement (List of current supported versions) at the top of this forum! How could you miss all the references? Jeeeeeeeeeeez. :( Regards, Pete

Version 3.45 of FSUIPC has been available since early Sunday morning. Try that first. Regards, Pete

Yes, that's pretty much exactly the sort of thing I would expect if the registration key was wrong in some way -- e.g. counterfeit or stolen. If you believe you have a genuine properly purchased key, please run it again, close FS, ZIP up both the FSUIPC.LOG and FSUIPC.KEY files (you'll find them in the FS Modules folder), and send them to me at petedowson@btconnect.com for investigation. I'll add you to my list of folks whose similar files I am still waiting for. Thanks, Regards, Pete

I don't use it with Active Sky and don't have a problem. Is this what AS says to do? Seems a bit extreme! ActiveSky does override most of them in any case I think. Actually, the "minimum weather defaults" was always MEANT to be much more extreme that the simply "defaults" option. The "normal defaults" actually keep some weather facilities active, because they are active by default. The "minimum weather" version is actually a "set defaults AND minimum weather" option -- i.e. it was doing MORE that the original button. The way you suggest, for them to be complementary rather than alternatives, is a good idea. But it is rather odd that it's never cropped up before. It has been the way it is now for years! :wink: I can certainly change it, but I shall change the button label too just to emphasize that is now doesn't set any defaults whatsoever. How about "Minimise weather settings", or simply "Weather settings off"? This won't be till the next version, at least a month off, as 3.45 was just released this past weekend. Regards, Pete

Hmmm. There's a load of parameters in the CFG file that I haven't the foggiest idea about -- those concerning the graphics especially. Maybe some setting amongst those affected specifically the drawing in the types of gauges you were having problems with. Regards, Pete

Thanks for the Log. I'm investigating now, but at initilal glance it does seem to be doing the right thing. I don't understand why the Key isn't being used from the KEY file. The correct entry is the one: F16.gau=DSVTJE5S6DUO Can you delete the other two for F16 in that file, just in case that's confusing the issue. Also, can you tell me please what version of Windows you are running? Thanks, Pete

With older versions it is hit and miss. To save time (before I worked out a better way), the accreditation was done on a sampling basis, much like customs searching for instance. But it's been more thorough for some time now. I can see what is going on more precisely if you turn on some more logging. You'll have to edit the FSUIPC.INI file and add the lines Debug=Please LogWrites=Yes LogReads=Yes LogExtras=2048 to the [General] section. Replace those lines if they are there already. Keep the run short or the Log will get too big -- just run it to verify the gauge isn't working. Close FS, ZIP up the log, and send it to me at petedowson@btconnect.com. I probably won't be able to fix it, but I can probably say exactly what is happening. In the end, for old pre-FS2004 gauges which are written in this way, I suspect the ultimate answer is going to be user registration of FSUIPC, or find alternative gauges. The TCAS gauges by Lee Hetherington (ILH) work well, for example. Regards, Pete

Nothing has changed in any of the weather handling in FSUIPC for a long time. Most folks' complaints about FS2004 (is it FS2004, you don't even say?) are that you can still see the ground when above so-called overcast cloud layers. If you have no clouds it is probably the visibility layer below and the thin film of stratus FS puts over the top so that as you climb you don't suddenly come out of mist and see sharp ground below. There is a minimum visdibility setting in FSUIPC. You could try setting that to something over 10 miles, though then you may never get mist or fog again. Also check whatever weather it is you are using. Pete

Well, there doesn't appear to be any correct attempt by the gauge to access FSUIPC in the way that a gauge should. It seems Eric has programmed it incorrectly, using the external access method for an internal program. That has been incorrect now since FS2002. It may work most of the time with a fully user registered FSUIPC, but it can easily go wrong if other internal modules do the same thing, as their memory mapped files will be cross-referred. I'm afraid you will need to either get help from the author, or register FSUIPC. Sorry. I cannot cope with incorrect access. With FSUIPC 3.45? The problems would be the same on FS2002. Regards, Pete