Pete Dowson

Please don't be discouraged. I suspect most folks who visit here are looking for help with using software rather than writing it, and those who do try writing stuff for FS who come here seem to be mostly using Visual Basic or C# or similar. Those already committed to C/C++ (because they realise how much more powerful and efficient it can be) probably don't think of looking here. There's an FS programmers Forum I saw over in AVSIM somewhere. Sorry, I've lost the link now, but you might find a more appropriate audience over there. Please do continue here as well, though, if it isn't too much troubleI suspect you have secret admirers who are simply too stunned or shy to comment -- yet! ;-) Also, it is Summer in the Northern Hemisphere and I've always noticed that a lot of hobbyist programmers are Seasonal -- its a way of occupying the long nights of Winter. I myself suffer from the lack of long nights at present, as I am an "owl" in terms of programming work! Regards Pete

You are making an error, then The registration system doesn't change. You must enter your Name, Email and Key all EXACTLY as originally. Even if you get the Key correct, one mistake in your name or email address and it will not match. That is why you are advised to keep your original notification and /or a copy of the FSUIPC.KEY file. I have no records of keys here. See the "sticky" above about retrieving lost keys. If you think you have everything correct, email all three details to petedowson@btconnect.com and I will check them here. Pete

I don't think there's anything anywhere in Eric's gauges which uses FSUIPC other than for TCAS (on the ND I assume?). Pete

No file. They send the Key by email. What's this about a file? You are probably getting mixed up with the instruction to download FSUIPC "manually" -- you get that from http://www.schiratti.com/dowson. How many days ago did you purchase it? If more than one whole day (24 hours) you really need to raise a problem ticket at SimMarket -- perhaps they has some problem with your payment, or perhaps you entered the email address incorrectly and so cannot receive anything. All this information is pretty clear on the SimMarket site. You get confirmation of the order almost immediately (that is automated), and the key within 24 hours. Regards Pete

It's called "Installation", and consists of just one step -- copy the FSUIPC.DLL out of the ZIP and put it into the FS Modules folder. It will overwrite the previous one. Hey, Presto! You are upgraded! That's all there is to it and all there ever has been -- and it is the same with all of my programs and modules. Why make it more complicated than it needs to be? ;-) Only if you delete them. Just don't delete anything. your settings are in the FSUIPC.INI file -- if you delete that, you lose them all. No. Yes. Leave them where they are. Make safety backups of them too, of course. Regards Pete

Sorry, these are things from Squawkbox, not from FSUIPC. I haven't got Squawkbox and have never used it, so I have no idea at all what it means. You really need to ask at the SB support place, wherever that is. But I can look at the FSUIPC Log file for you if you like. Load up FS, get the problem, close FS, then show me the FSUIPC.LOG file -- it will be in the FS Modules folder. Oh, and what did you change yesterday? Things don't normally change by themselves. Regards Pete

Amazing how many folks set the parameters in Wideclient INI so restrictively! I make things as easy and automatic as possible, and it is all defeated by folks specifying IP addresses and protocols explicitly! :-( Please just delete the ServerIPAddr parameter. If you must specify the Server (eg you are using Win98 or WinMe), please use the ServerName for now. Sorry, but that cannot possibly be anything whatsoever to do with WideFS. In fact the reverse is likely -- you have something wrong with the Network and that is affecting WideFS too. Note that the problem mentioned in this thread and reproduced here is simply that if you specify both the Protocol and the ServerIPAddr parameters in Wideclient.INI, then WideClient doesn't connect. More than that, it doesn't even attempt to connect -- in fact it touches absolutely nothing on the Network at all! That was the problem -- a particular combination with no code to back it up. Why are you sure then? I tell you, it is not possible for it to be anything at all to do with WideFS. Sorry, but there it is. Regards, Pete

Okay, I've reproduced the problem. I'll fix it in the next update. It only occurs if you specify a Protocol and the ServerIPAddr. Somehow this combination slipped through my test list -- there are too many combinations now! ;-) Since you are using TCP protocol you do not need the Protocol parameter. It is odd that you still have it, as WideClient automatically removes the old "UseTCPIP=Yes" parameter and doesn't replace it -- it only puts a Protocol parameter in if you were using SPX before. Since you are using XP on all PCs you do not need the ServerName or the ServerIPAddr parameters either -- unless you have two Servers running at the same time, which is usually very unlikely. Really, for an all WinXP setup, the best and most flexible way is to specify nothing at all in the Wideclient INI files (no protocol, no server details), and just use ProtocolPreferred in the Server's INI to select TCP, SPX or UDP. I use UDP throughout these days, but configuring it as I say allows you to change over just by changing that one Server parameter. Regards, Pete

It isn't just FSUIPC which 'keys' on the aircraft title, it's the whole system -- that's how FS identifies the aircraft from the FLT file when that's loaded. It is that which gives it a place in the selection dialogue. There is a TYPE variable, but that is obtained later, after the loading is complete -- I need to switch things a little earlier. Also the TYPE is one used for ATC and can sometimes be misleading. Oh, right. Still using the title.Yes, that would be easy enough. I'll make a note for the next update. Thanks, Pete

Have you looked at the FSUIPC documentation? Have you even got it? If not please go and download FSUIPC.ZIP now from http://www.schiratti.com/dowson and look at the document called the FSUIPC User Guide. In the Contents page (the one after the title sheet) you will see "Entering Registration Details". Find that page and move down to where it says "Application program or gauge registration". There's even a picture to help! Note that 99% of all programs and gauges using FSUIPC actually register themselves automatically. Only a few very early ones (over three years old -- written BEFORE FS2004!) don't do this. You should really look for more up to date products for best use with FS2004. Er .. hold on. You paid for and registered FSUIPC as a User? If you have done this you do NOT have to ever register any gauges or programs in any case. Ignore the Gauge Key, that is irrelevant -- their documentation evidently isn't very good or they'd tell you this. Just go fly! Regards, Pete

AhI'll try that. The code for all this changed substantially to make the automatic protocol ("ProtocolPreferred") and so on work well. ServerName usage is much preferred over IP addresses in any case, but if you have Win2K or WinXP all round anyway it is far easier just to leave any mention of the Server out and let WideFS do it all automatically -- that was the case in 6.51 too. Meanwhile, I'll re-test the case of IPAddress specified here. Thanks, Pete

Odd, because WideClient 6.65 actually corrects a problem in 6.51 with WideClient not reconnecting after a restart of FS. I need to see the WideClient INI and WideServer.INI files, and I need to know what operating system you are using in Server and Client PCs please. And how does that compare with the 6.51 log, please? All it looks like is that the Mailshot transmissions from the Server aren't being seen at the Client. I can't guess at that yet. Let me see more information, please. Regards Pete

I really don't think there's anything whatsoever kept in the Registry by FS itself regarding options, only install and uninstall paths. If you have enough disk space why not try a complete new virgin install to a different folder or partition, and see if that does the same? Test it before adding anything to it. I often do this sort of thing as a cross-check. if you rename the original folder 2Old ..." and install with the same folder name as before, everything else won't be the wiser. You can swap between them or rename folders back as you like. Regards, Pete

No, I don't think sothe first log is showing that there is something wrong with your Key. I do see your registration in my list, so I should check the Key for you. ZIP up the FSUIPC.KEY file and send it to me at petedowson@btconnect.com please. No, I've never had it there. It doesn't matter where it is at all -- the FSUIPC interface is not conscious of anything to do with folders or directories. It would be a horrible mess if all the FSUIPC-using add-ons had to reside in one folder, let alone the FS one! Regards, Pete

The GFMCP DLLs are from GoFlight, of course. No one else writes drivers for their hardware. The problem arises because if you ever have more than one such users (that DLL and, for example, a Gauge -- there are a few such around), they will both be using the same memory mapped file for the inter-Process communication (the IPC in FSUIPC) they are wrongly using. Thus one will corrupt the other quite readily. The results will be unpredictable. The correct method for using FSUIPC from within the FS Process is a simple straight-forward recompilation using a different library and one small programming change. The correct methos is direct, efficient and safe. Sorry, the world is not perfect and not all software works 100% This is nothing to do with versions, just one incorrectly written module from GoFlight. By all means quote my messages from here if you like. It may help GF's programmer understand. ;-) Regards Pete

First you start with the SDK's "ReadMe.Txt" file. that points you to all the other things. The details and examples for C (which is a subset of C++) are in the C Zip. You open the C ZIP and find the "ReadThis.txt" file. This covers everything, but you can also look at the example code and headers, of course. The only difference for the internal user is the Open2, where you supply the buffer memory for the data blocks. That's all. It does say this in the Text files. Regards, Pete

First you need to use the "module users" library, with FSUIPC_Open2 instead of FSUIPC_Open. Please see the ZIP inside the main SDK ZIP. The rest is identical to using FSUIPC for an external C++ program. Regards, Pete

Show me the FSUIPC Log file please. Load FS, when it is ready, run FSInterrogate2, get the problem, then close FS and show me the FSUIPC.LOG file. Pete

That cannot be the one which came with the original GoFlight MCP, because that didn't use FSUIPC. It seems that the new one (is that for the MCP Pro?) does use FSUIPC -- but GoFlight have never asked for an access key, so I assume they require folks to register FSUIPC? Even if they had an access key it wouldn't work with the DLL encoded like it is -- they are using an incorrect method entirely! Unless you upgraded to the MCP Pro I'd advise you to go back to the older version. Hmmm. It sounds like they started using FSUIPC then, in that case. Not specifically 3.6 -- ANY version of FSUIPC. You were only "lucky" with 3.6xx because of the Beta parts in it. That module would fail with all versions from 3.00 onwards -- i.e. any version of FSUIPC which works with FS9! You have two choices as far as I can see: 1. Get GoFlight to re-write the module so that it either doesn't use FSUIPC, or does use it but correctly and with an agreement with me for an access key. 2. Purchase a registration for FSUIPC. That will stop the message. it won't make the access they are using correct -- that is and always will be a bad method and may cause unpredictable problems. But you won't know what is causing them anyway. It is nothing, repeat, nothing to do with 3.6!! It is ALL versions for FS9! You do not need to know anything about FSUIPC versions. If you are using FS9 you have this problem with that module. There are no two ways about it. Complain to GoFlight, please. I have no GoFlight module. I added support in FSUIPC and WideFS for the buttons on the new GF modules -- registered users have always had FSUIPC programming facilities for older GF modules. As for whether you need to register FSUIPC to use GF hardware -- it sounds as if they are forcing you to do so, yes. Please contact them and sort it out. Regards, Pete

I don't even know if it will help -- you really really do need to look at your FS Modules folder and see how many non-Microsoft DLLs you have there. Anyway, if you remove ActiveRadar.DLL from there before you start the log will be MUCH smaller -- that module is constantly reading 1024 bytes to get the I traffic locations. Just take it out and keep it elsewhere for the test. Pete

And both show the same problem: As I keep telling you, this is a problem caused by a bad module or gauge. The only reason it doesn't cause an error message in 3.615 is because of the Beta nature of the release, as I have explaned at least twice before. Pete

Yes, because as I said right at the beginning: "due to an error on my part, versions 3.6xx (before 3.65) included some debugging code not normally included, and some of the checks would have been by-passed until the Beta period expired (which it just has). " In actual fact, the Beta period for 3.60 passed, but 3.615 will work till the end of July I think. I am not talking about external modules (which all of those are examples of), but about a DLL or GAUge installed in your FS. It is NOT ActiveRadar.DLL, but some other DLL or GAU -- probably a DLL, as I explained. You seem to be missing much of what I am saying! :-( Pete

There's a lot of 3.60's there!? I thought you mentioned something about 3.65? I did explain the business about Beta version codes and 3.6xx, remember? But certainly if one worked this morning, the same one will work this afternoon -- there is no "memory" in FSUIPC's operations. However, that would have been pure luck, a fluke. You have something illegally using FSUIPC in a completely wrong way. Usually these add-ons date back to FS98 days, or at least not much later, and just have not been correctly revised. The log certainly did not show a 767 being loaded, but the Cessna, as shown: 8312 FLIGHTS\other\MEIGS.flt 8406 AIRCRAFT\c172\Cessna172SP.air If you've not added any gauges to the Cessna then it must be an added DLL which is causing the problem, as I suggested. As I said, you need to find out which add-on is causing the problem. I cannot do that for you. It is a process of elimination -- look first in your Modules folder and remove each non-Microsoft DLL in turn till you find it. I'm pretty sure ActiveRadar.DLL is okay, but just try removing that first, as a test. I have it here someplace too, so I'll try it now ... [LATER] ... No, that's fine here. Whatever is causing the problem for you is starting out by trying to read the time. Does that give you a clue at all? I'd get more information from your log if you go to FSUIPC's Logging page and enable IPC Read and Write logging. Then close down FS and restart it so we get the logging right from the start. I don't know if it wil help, but it may do. Regards Pete

What was the previous version of FSUIPC you were using? There's been no changes to most of the access permission checking at all for a long time, but, due to an error on my part, versions 3.6xx (before 3.65) included some debugging code not normally included, and some of the checks would have been by-passed until the Beta period expired (which it just has). The relevant part is this: 2953 Client Application: "fs9" (Id=2456) 2953 C:\Program Files\Microsoft Games\Flight Simulator 9\fs9.exe 2953 Product="Microsoft Flight Simulator 2004 - A Century of Flight" 2953 Company="Microsoft Corporation" 18140 Illegal read attempt: offset 0238, size 3 [P2456] 18140Program or module not accredited for use with this unregistered FSUIPC This indicates either that there is an add-on DLL installed which is accessing FSUIPC incorrectly, or that the aircraft your are using contains a Gauge which is likewise accessing FSUIPC using entirely the wrong method. The fact that the error occurs so early (before the flight is logged as loading) tends to point towards a DLL (but not ActiveRadar which is okay). Unfortunately, because it is accessing FSUIPC as if it is an external program (VERY inefficient and likely to cause many problems even with a registered FSUIPC), it is identified as FS9 itself, which it obviously isn't. There's no way for me to identify it -- you need to check through your add-ons and find the culprit by a process of elimination. Regards, Pete

Er, I think you are a bit confused there. There are no offsets for PTT. The numbers you quote are CONTROL numbers - i.e. numbers programmed on buttons or keypresses. Those above 65536 ae FS control, those below are those added by FSUIPC. You can use offsets to send controls -- check 3110. You write the control number there as a 32-bit integer (i.e. length 4 bytes). Regards, Pete