Jamie Fox

As far as I know, transponder modes are not implemented in FS2004 (or any earlier version). They are implemented within Squawkbox. Squawkbox 2.3 provides no direct facility to change or access the current mode. Squawkbox 3 provides a facility to control it (along with many other things), using an FSUIPC-based interface. (Joel still doesn't seem to have worked out the different between Dowson and Dawson though.)

Have you registered Squawkbox in FSUIPC using the freeware key listed in the 'Freeware Keys' thread on this forum? That catches a lot of people out, especially non-FS2004 users.

Is there new information available about the TeamSpeak PTT?

When you run WideClient, its title bar should change from 'Waiting for connection' to 'Connected'. Has it done this successfully?

That should be possible just by using the Squawkbox installer, although there might be a problem if you don't have FS installed at all. If so, then you should be OK just copying the Squawkbox directory manaully. Make sure you run SBHost before Squawkbox itself.

Yes, you can do this with WideFS. Yes, you can fix the pausing problem: see the option 'pause on task switch' in Flight Sim (probably in a section with the word 'general' in its name), you need to turn it off; it's on by default.

If you're familiar with GCC you might be happier using the MinGW or Cygwin ports of GCC for Windows, instead of the MS compiler.

That sounds like a firewall blocking incoming ping (ICMP echo request); this is the default behaviour of Windows Firewall. You need to ensure that the server PC (running FS) is allowed to listen on the port used by WideServer (the default is 8002 TCP I think). In Windows Firewall you can do this either by program (SP2 only) or by port. Windows XP SP2 prompts you for this the first time. Post back if you have any trouble enabling this.

The following is quoted from the Free Software Definition: Surely you must be familiar with at least one of the following words: GNU, BSD, Apache, Debian, Linux, Mozilla, KDE, GNOME. No?

I have never heard of any other GPL, although there are several other *PL licences. It would be confusing to refer to any other licence as GPL, although if one wishes to be precise, 'GNU GPL' removes the ambiguity. I guess they probably have, although I haven't heard of it. No, probably quite a good idea actually. Yes, but see below. Yes and possibly yes. When the word 'free' is used in the GPL, it is a reference to freedom, not price. In this context FSUIPC itself is certainly non-free. Technical Issues You could do this using WideFS. Think of it something like this: Flightgear <-FlightGear IPC-> your program <-FSUIPC user library-> (<-WideFS optionally here->) MSFS I don't know what inter-process communication facilities are available in FlightGear. If there aren't any, you could either add some yourself. Alternatively you could integrate the program into FlightGear itself, subject to certain conditions. Legal Issues 1. If you modify parts of FlightGear, then you must either distribute those modifications under the GPL, else not at all. 2. If you wish to link your program directly into FlightGear then your program must also be licensed under the GPL. One of the most controversial parts of the GPL is what constitutes a 'derivative work'. The FSF's stance seems to be that static or dynamic linking counts as a derivative work, but other IPC mechanisms (such as sockets and, in my opinion only, the interface between FSUIPC user library and FSUIPC.dll) can be considered as independent. In any case, if you only want to distribute code that is yours, you can add a 'special exception' to the license text to explictly allow linking to FSUIPC-related stuff. Have a look on the FSF site for for 'special exception' and you should find what you're looking for. I hope that makes sense. I think I've gone on too long. Just one final important question for Pete: Is the FSUIPC_User.lib code public domain? I was under the impression that it is, but I can't find any notice in the code. (Public domain is taken to mean that all copyright holders have explictly disclaimed their copyright.) I guess it must be pretty close, as there are plenty of proprietary programs linking against it.

Are you using FSUIPC_Open or FSUIPC_Open2? Using the external interface (FSUIPC_Open) from a gauge is a very bad idea, for reasons described in the SDK. Keys will only work if you use the correct access method: FSUIPC_Open2 for an internal module or gauge. You can use the box in FSUIPC if you wish, and you need to enter the full filename INCLUDING .gau, with your key. However, a better way is to write "B2AOZMKV9W9Y154_B2_APU_1_3.gau" to offset 0x8001 immediately after opening the link to FSUIPC. This saves your users the trouble of entering the key manually.

I'm not sure that this is the complete solution. I occasionally have a similar problem, but have never been able to reproduce it reliably. Sometimes WideClient saves incorrect position and size information (to the Window= parameter) often involving large negative numbers. When it's restarted, the window exists but is entirely positioned off the screen and is thus invisible. This can be fixed by manually removing or editing the Window= parameter in WideClient.ini. Perhaps WIdeClient is incorrectly saving its position and size information on exit?

This is a problem with Squawkbox and DirectPlay. It has nothing whatsoever to do with any of Pete's modules. (Most users find that this is fixed by upgrading DirectX to the latest version.)

You have two options: 1. Anyone else using your program will need a registered copy of FSUIPC. 2. You can apply for an access key for your application, so that your end users won't need to pay. This is free if your application is distributed free of charge. If your application is distributed at cost then you will have to reach a mutually acceptable agreement with Peter.

Yes, you're right. I hadn't made the distinction and was comparing latitude/longitude with this double float offset as if they were. In the interests of clarity of the thread (I'm not a VB user): does this mean that double floating point offsets (eg 6408) can be read directly into a VB double?