Pete Dowson

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

What's "crashing out" precisely? Where's the log. A failure of a gauge to gain access to FSUIPC rarely makes anything crash at all, let alone 2out" -- all that happens with TCAS gauges is they don't get any targets to show. Removing a gauge doesn't fix the panel anyway unless you edited the panel configuration. you should simply change the name of the gauge being called up in Panel.CFG. That's really a job for whoever supplied the aircraft/panel, but all gauges are called via entries in their CFG file, of course. I don't have the aircraft you are talking about. The FSUIPC_Reg.Bin is merely a diagnostic output created by FSUIPC to make it easy to find problems with registrations. It appears to show the correct key for the correctly named gauge, ILH_TCAS, so if anything it is one more indication that the aircraft you are using has a renamed gauge which has no valid key. The problem is not with ILH_TCAS the fact that it has been renamed to L_ILH_TCAS2. Why they've renamed it I've no idea, sorry. Just try editing the Panel.CFG file, changing "L_ILH_TCAS2" to "ILH_TCAS". Regards, Pete

Yes. Well donenow, do some flying! ;-) Pete

There are only a couple of separate ON/OFF light controls (Landing and Panel), but the others have TOGGLEcontrols instead. These work okay, but of course you can get a toggle switch out-of-sync with the switch state in FS. After loading a new flight you may have to use some method to re-sync them -- such things can actually be done with conditional button programming in the FSUIPC.INI file, when the action of the button is nothing when the relevant offset (a bit in 0D0C for lights) is already in the correct state. The same offset (0D0C) can be used to drive the GoFlighht LEDs, using GFdisplay. But, back to your problem: I don't really understand why the panel-writer would override legitimate controls from other sources. It sounds rather like lazy programming. To do it properly he whould have to monitor the light switch states in FS and make his graphic depictment match. It sounds like he is simply reading his own switch setting at intervals (half-a-second you said?) and restoring FS's to match them when they disagree. If this is the case then there's no answer except to find a way to set his switches -- if he doesn't provide keystrokes then all I can think of is using Luciano Napolitano's "Key2Mouse" module to operate the switch on screen. But that of course has its own drawbacks -- the screen must show the switches in the same position each time you want to operate them. Regards, Pete

Nothing that I've written -- I found out how to make the messages other Applications asked for display show white instead of red, so it was added as an option. But that only ever affects messages written to FSUIPC by applications. I've never written anything which even attempts to actually change built-in FS messages like its ATIS. And the only program of mine which even intercepts those messages (so they can be re-distributed to other windows, or to WideFS clients via ShowText) is AdvDisplay, which it appears you've never used. It's okay. These things can be very frustrating, I agree. I'm wondering if, when you clean re-installed FS, you didn't leave something which is still causing it. As I said, I don't think the uninstall cleans everything. After doing an uninstall you still need to go round deleting all the Flights in your "My Documents" FS folder, and probably the original FS folder too as added-on things will still be left there. I really cannot see how, after a truly clean re-install you could have the same problems, unless your FS CDs are corrupted which isn't really plausible! I'm almost 100% sure that FS itself doesn't keep obscure option settings in the Registry. Regards, Pete

I think it will be "ThrottleN cut" -- try it. You can program that on the button release. If not that then just use "ThrottleN set" with a parameter of 0. Regards, Pete

Please assign the button to the PTT on/off controls in the FSUIPC dropdown -- "on" when pressed, "off" when released. These controls (called PTT Transmit On (SB3,RW,AVC) and PTT Transmit Off (SB3,RW,AVC)) do not use keystrokes but direct commands to SB and they will be mucvh more reliable and efficient. They will also work across to WideFS clients without any additional work or parameters. For SB3 there's also controls for Private Voice PTT. Regards, Pete

That's different from your "reinstalling FSUPC", then, and makes it start to sound a lot more to do with SB's behaviour than anything in FSUIPC or WideFS. But thenin the KeySend parameters in WideClient.INI did you use the RWon/RWoff facilities (which have been there for years), or did you assign keystrokes and tell SB to use the keystrokes? There's a lot of difference. Yes. Please try it. It does not use keypresses, it uses direct commands into SB, provided by SB (to match the erstwhile Roger Wilco). Sounds like you must be using keystrokes then -- but even then, repeating is not a good idea. It should have been "press key" for one and "release key" for the other -- the standard keyboard driver in Windows does the repeats. Because it was only relevant for versions before August 2005. That complicated method has been obsolete since then. Regards, Pete

And how, exactly, are you programming this PTT? Have you made sure the button isn't also assigned in FS? What programs outside FS are associated with it and crash? What do you mean by "the latest version of FSUIPC" please? Everyone says that, but it is meaningless really as they mean "the latest one I saw" -- sometimes it has been a year or more old! :-( Tell me about assigning buttons in SB3 please -- if SB3 can read PTT buttons directly, why are you using FSUIPC? Regards Pete