n4gix

There's a misunderstanding there. FSUIPC injects nothing at all into FS9. That is all done through the multiplayer interface, it is nothing to do with FSUIPC. What may be injected into FSUIPC's "TCAS" tables, for reading back by TCAS gauges and the like, are details of the same traffic that is being sent via MP to FS. This used to be done by Jose Oliveira's "AIBridge" program for SB2 but I suspect SB3 has it built in now? I don't know about the IVap programs I'm afraid. Ah, thanks for clearing that up. I'll have to ask Joel how he's getting the SB3 traffic back into FS9 then... ;) I am reading the data directly from TrafficInfo.dll, and it works perfectly with AI as well as multi-player when connected via the ZONE or peer-to-peer over the internet or a LAN. It only fails when logged onto VATSIM. The true puzzle is that Lee H's TCAS will read data either from your FSUIPC TCAS tables or TrafficInfo.dll, and both modes display identical results when connected to VATSIM, which clearly proves that the data is there to be read... Lee has confirmed via an email exchange that he is actually only reading three bits of data from either source: lat/lon/alt. He calculates the remaining data points needed for TCAS display with his custom algorithims. As I said, the problem is clearly mine. :oops: I'm just seeking clarification on certain processes/issues, and I thank you for clearing up one misunderstanding! 8)

Hi Pete, I have an interesting (yet frustrating!) problem implementing TCAS in our Avidyne gauges while connected to VATSIM. We are successfully reading the TrafficInfo.dll to display AI traffic, as well as multi-player traffic whenever connected LAN-to-LAN using the default MP connection in FS9, or peer-to-peer over the internet to another host, and also when connected via the ZONE. Whenever connected to VATSIM however, we are coming up with a big nothing... Lee's TCAS will display VATSIM traffic using either FSUIPC access or TrafficInfo.dll access without error, so I have to assume that FSUIPC is successfully injecting VATSIM traffic into FS9... Well that, and the fact that we can SEE the other traffic pretty much confirms that the process is working properly. I know that it isn't "your problem," but do you have any idea at all why our code will work with "regular multiplayer," but falls down when on VATSIM? :oops:

Pete will be out of pocket for the rest of the week, so it may take a bit of time to get a reply...

Yet another option is to use MaxiVista, a program that will allow networked computer monitors to be seen as a "Virtual Monitor" on the host computer. The latest version of MaxiVista will support up to three "Virtual Monitors," IOW, three networked computer's monitors.

All .bgl files used for navigational data in gauges follow the following file naming format: aa9#####.bgl (a = alphabetical, # = number) Could that 9 after the first two letters stand for Flight Simulator version 9 maybe? I've also noted that each geographic folder in the Scenery folder, such as Eurw for Western Europe, has many of these BGL file ##### numbers starting as 39170. For example all the AP9#####.bgl (airport BGL remember) files start from 39170, all the AB9#####.bgl files start at 39170, all the HL9#####.bgl (coastline data I believe) start at 39170 and so on. Then if you look in the North America - Central folder (which is Namc), the files have a ##### number starting at 18080. The rest of the other folders similarly have their own unique 'starting number'. I'd say that's a good place to start to try and guess at what indexing system is in use. nv9AFRI0.bgl (I guess this is Africa region) nv9ASIA0.bgl (Asia) nv9AUST0.bgl (Australia) NV9EURE0.bgl (Eastern Europe) NV9EURW0.bgl (Western Europe) NV9NAMC0.bgl (North America - Central) NV9NAME0.bgl (North America - Eastern) NV9NAMW0.bgl (North America - Western) nv9OCEN0.bgl (Oceana) NV9SAME0.bgl (South America) You might be pleased to know the navaid database is actually stored in plain XML files that are then compressed into these BGL files by Microsoft's BGL compiler tool, as found in the Scenery SDK. The uncompressed .bgl files load very nicely into Visual Studio .Net 2003 too. Once loaded you can simply use VS.NET's file editor to view either the plain XML or a Data view (click on the XML or DATA tabs at the bottom of the editor window). In DATA view mode you can see that each XML file contains the following tables: FSData SceneryObject LibraryObject Ndb Vor Dme Airspaces and Political Boundaries are in the \Scenery\... geographic folders, and contain the specific drawing instructions! AT9NAME0.BGL is the filename used for each of the geographic areas. After decompiling the file with NewBglAnalyze.exe, I can now see all of the data for *all* types of airspaces, along with coastlines and political boundaries... ;) Example: type="CLASS_C" name="CHICAGO MIDWAY"> lat="N41 45.35000" lon="W087 38.91683" minimumAltitudeType="MEAN_SEA_LEVEL" altitudeMinimum="579.12" maximumAltitudeType="MEAN_SEA_LEVEL" altitudeMaximum="1096.97"/> lat="N41 41.61667" lon="W087 34.01683"/> lat="N41 47.15850" lon="W087 45.14167"/> type="CLOCKWISE" index="0" lat="N41 44.51667" lon="W087 58.03349"/>

Well, "FSUIPC" is certainly more euphonious than "PAUDEW"* :lol: *"PetesAmazingUniversalDoEverythingWhizbang"

Which, of course, is not what he wants to do. BTW, nice job on the 'generic panel!' ;)

Just to put a period on the thread here, Pete is quite correct. You cannot use VB to produce compiled gauge for FS's .dll system. I too use MSVC++ .NET (although I use the v7.0 optimized compiler) for gauge building. Your absolute best resource for learning gauge development is the Aircraft & Panel Design forum at avsim.com... Most of the "power developers" for FS gauges hang out there... ;)

No. Such data isn't even "simulated," much less available. ;)

Why not simply change the filename of fsuipc.dll temporarily to see if the problem persists? I'll bet that it does... :roll:

MS didn't really provide enough information to answer the question. However, it is clear that the sim itself is "parsing" the XML instructions and "translating" them to some other executable form. It's fairly certain that at the end, KEY_INCREASE_THROTTLE © & INCREASE_THROTTLE (XML) are both acting on the same internal FS stack, but it's unlikely that parsed XML code is using the PANELS "trigger hey event" routine, as there are too many differences in the list of available commands. There are some XML commands that do not have XML counterparts, and vice-versa.

Pete, most of those problems are cause by (ehem!) poor gauge programming that constantly triggers an event. Most often, this occurs with XML gauges, since they are so simple that a lot of "non programmers" will give 'em a go... :wink: The only "troubleshooting method" that seems effective is to disable all VC gauges, then systematically disable (// out) each 2d panel gauge until you've found the one (or more) that are causing the problem...

Well, as one of the designers of the Cessna Citation series, I can assure you that is exactly proper behavior for our aircraft! The spoilerons are used to help "dump lift" on the wing to assist in establishing the bank angle. This technique is used on all sweptwing, high speed aircraft.

Uh, which aircraft? Many of the larger jet a/c DO exactly that! :)

It's the same as FS2002, and has nothing to do with FSUIPC. Simply check the FS9 options and toggle OFF "Pause on Task Switch."