Using Simconnect with Multiplayer - Collection RADIUS & Gamespy Name

[Geoff_D]

(1) How do I increase the 200km RADIUS limit for collecting aircraft info
through Simconnect.

I see the RADAR XML Gauge sets RADIUS to 300nm, and can get Aircraft
Info out to that range.
How can that be done in Simconnect ?

(2) How do I get the AI Aircrafts GAMESPY NAME in Miltiplayer.

Once again, the RADAR XML gauge can do this, but it is not clear how to
do it with Simconnect.

(At least, it is not clear to me --- I can struggle though most of the
other DOCUMENTED Simconnect stuff, but I cannot seem to get resolve the two
variables above )

PLEASE do not tell me Simconnect itself cannot do these two functions,
when an XML Gauge can !!!

Geoff_D


Web Based FSX Multiplayer Aircraft displayed in real time on Google Map. Aircraft are Clickable and show Full Info Labels.
Problem is simconnects apararent 200km radius collection range for AI target info.
Design aim to to cover the globe ( or at least the whole of the USA ) withour resorting to BRUTE FORCE, and moving the collection point to multiple sample points, and then resolving overlapping duplicate aircraft !!!!
(On which case I wopuld need to get the Unique AI aircraft ID's for the aircraft !!! something else I cannot seem to get with Simconnect !!)

 

[lc0277]

(1) How do I increase the 200km RADIUS limit for collecting aircraft info
through Simconnect.

I see the RADAR XML Gauge sets RADIUS to 300nm, and can get Aircraft
Info out to that range.
How can that be done in Simconnect ?

I'm afraid that the 200 km is an hard limit in simconnect. Every time I tried a larger value it returned me an exception.
The gps/radar gauges are probably not using simconnect at all, but directly accessing FS tables instead, so no limitations apply.
If you are working inside a C/C++ FS module (DLL), you could also use the old ITrafficInfo interface for gathering traffic database. The documentation is missing in the SDK so you need to download the FS9 gauges SDK to get the .doc file and the header. No need to bother with ITrafficInfo.dll since it's built-in into FS now. I don't think the interface has changed (I heard some people had success porting FS9 radar gauges based on it).

Another solution is to monitor all aircraft additions and deletions, via subscribing to system events "ObjectAdded" and "ObjectRemoved" and then individually request position or whatever data with RequestDataOnSimObject when an object is added to the sim. Since you receive object events no matter how far objects are, you'll bypass the limitation in RequestDataOnSimObjectType().
The only problem is that your add-on need to be up, running and listening to events
when the simulation starts otherwise it won't catch up object additions.

(2) How do I get the AI Aircrafts GAMESPY NAME in Miltiplayer.
Once again, the RADAR XML gauge can do this, but it is not clear how to
do it with Simconnect.

using ITrafficInfo again. There is a function in it to get the player name. Unfortunately this data doesn't seem to be mirrored in any simulation variable.

 

[Geoff_D]

Thank lc0277

I am left wondering why such a limit was put on RequestDataOnSimObjectType(). !!!

I can understand a DEFAULT of 200km, but it would seem that setting the capture radius to "0" does not collect ALL data as documented ( maybe my mistake, was only TOLD about this, and have not seen it in MS print)

In any case, while I can see there are possible CRUDE solutions, none are really suitable, and I am left with the frustation of potentially having to write a lot of extra code, to FUDGE to do waht would seem to be quite a reasonable thing to want to do.

Starting to look at my HexEditor -- looking like a very attractive solution at the moment !!!

I am assuming it is not a CONSTANT hard coded into FS, but instead a variable, initialized at startup. If that is the case, there is some hope in maybe getting some way to change that variable.

MY frustration is compounded by a total lack of any response or support from the Simconnect team at ACES. (sigh)

I'm afraid that the 200 km is an hard limit in simconnect. Every time I tried a larger value it returned me an exception.
The gps/radar gauges are probably not using simconnect at all, but directly accessing FS tables instead, so no limitations apply.
If you are working inside a C/C++ FS module (DLL), you could also use the old ITrafficInfo interface for gathering traffic database. The documentation is missing in the SDK so you need to download the FS9 gauges SDK to get the .doc file and the header. No need to bother with ITrafficInfo.dll since it's built-in into FS now. I don't think the interface has changed (I heard some people had success porting FS9 radar gauges based on it).

Another solution is to monitor all aircraft additions and deletions, via subscribing to system events "ObjectAdded" and "ObjectRemoved" and then individually request position or whatever data with RequestDataOnSimObject when an object is added to the sim. Since you receive object events no matter how far objects are, you'll bypass the limitation in RequestDataOnSimObjectType().
The only problem is that your add-on need to be up, running and listening to events
when the simulation starts otherwise it won't catch up object additions.



using ITrafficInfo again. There is a function in it to get the player name. Unfortunately this data doesn't seem to be mirrored in any simulation variable.

 

[lc0277]

I am left wondering why such a limit was put on RequestDataOnSimObjectType(). !!!

I can understand a DEFAULT of 200km, but it would seem that setting the capture radius to "0" does not collect ALL data as documented ( maybe my mistake, was only TOLD about this, and have not seen it in MS print)

In any case, while I can see there are possible CRUDE solutions, none are really suitable, and I am left with the frustation of potentially having to write a lot of extra code, to FUDGE to do waht would seem to be quite a reasonable thing to want to do.

Starting to look at my HexEditor -- looking like a very attractive solution at the moment !!!

Hex editing is probably a solution (look for 00030D40h in api.dll) but you cannot distribute your application then due to copyright problems.

The documentation says that a 0 m range means no limit, but you only get the user aircraft then. I tried a large figure (800 km) with an aircraft 700 km away and I
received an OUT_OF_BOUNDS exception like the documentation said, but the information about the remote object was still sent !
Maybe the table is partially wrote when this exception occurs, I had only two plane in the sim at this time. I tried with an enormous range (7000 km) and notice a severe performance loss (a 0.5s freeze at each request), so the implicit limitation may be due to cpu usage.

I believe that the best solution is to use objectadded events and create a periodic request each time an object is added to the sim. Range requests seems to be cpu-hungry and I think that access to individual objects is done in constant time.

 

[Geoff_D]

Difficult to imagine why the RANGE would be a cause of the Freeze.

I would have thought the freeze would be directly proportional to the number of aircraft, and not what their individual rages were.

Your findings are the same as mine.

Would be "NICE" to hear something from the ACES Simconnect people.
I should really apply for a job with them ... looks like it is "sweet" little corner of MS to live in ....

OK - did that STICK get anyone's attention.... I am almost past caring what I say these days, I am so FRUSTRASTED with the lack of resonse I get, or I see anyone else get from this "TEAM" !!!!

Hex editing is probably a solution (look for 00030D40h in api.dll) but you cannot distribute your application then due to copyright problems.

The documentation says that a 0 m range means no limit, but you only get the user aircraft then. I tried a large figure (800 km) with an aircraft 700 km away and I
received an OUT_OF_BOUNDS exception like the documentation said, but the information about the remote object was still sent !
Maybe the table is partially wrote when this exception occurs, I had only two plane in the sim at this time. I tried with an enormous range (7000 km) and notice a severe performance loss (a 0.5s freeze at each request), so the implicit limitation may be due to cpu usage.

I believe that the best solution is to use objectadded events and create a periodic request each time an object is added to the sim. Range requests seems to be cpu-hungry and I think that access to individual objects is done in constant time.

 

[Geoff_D]

Hex editing is probably a solution (look for 00030D40h in api.dll) but you cannot distribute your application then due to copyright problems.

The documentation says that a 0 m range means no limit, but you only get the user aircraft then. I tried a large figure (800 km) with an aircraft 700 km away and I
received an OUT_OF_BOUNDS exception like the documentation said, but the information about the remote object was still sent !
Maybe the table is partially wrote when this exception occurs, I had only two plane in the sim at this time. I tried with an enormous range (7000 km) and notice a severe performance loss (a 0.5s freeze at each request), so the implicit limitation may be due to cpu usage.

I believe that the best solution is to use objectadded events and create a periodic request each time an object is added to the sim. Range requests seems to be cpu-hungry and I think that access to individual objects is done in constant time.

PROBLEM SOLVED -- you have "inspired" me lol
Thanks

 

[lc0277]

PROBLEM SOLVED -- you have "inspired" me lol
Thanks

Glad to hear this But for your multiplayer name problem it seems that there is no quick work-around, excepted writing a module that relays ITrafficInfo (or directly call it, I don't know what language and architecture you are using).
I heard that the upcoming FSX patch will have a number of new multiplayer features, including the long-awaited kick-ban option. Maybe the SDK will be upgraded as well.

 

[Geoff_D]

Glad to hear this But for your multiplayer name problem it seems that there is no quick work-around, excepted writing a module that relays ITrafficInfo (or directly call it, I don't know what language and architecture you are using).
I heard that the upcoming FSX patch will have a number of new multiplayer features, including the long-awaited kick-ban option. Maybe the SDK will be upgraded as well.

Not being able to access the certain MP & AI info through Simconnect is proving a problem still.
ie Each AI aircraft has a Unique ID, but that does not appear to be available as well through Simconnect.
Even if I was relay ITrafficInfo from a C++ Gauge, then associating those targets with the simconnect targets is a problem.
However, I am wondeing if I maight do better to get ALL my data from a hidden C++ Guage, and dump simconnect all together, especially as the simconnect calls I am using to get traget information are so CPU intensive.

Still very much in a learning mode here, so any advice or suggested directions would be welcome. At the moment, I can see that I will have to change the method I am getting data, as the CPU demands are far too high, for even a few 10's of planes, and the design goal is up to 1000 !!

At the moment I am using VB to prototype the simconnect application that provides the data feed to the website, while the website display app is being developed.

Geoff_D

 

[DocMoriarty]

I think you might really be best off by splitting your addon into a C++ dll (gauge or internally loaded dll) and an exe (VB) like i did simply due to the performance and lack of features issues. In my case the dll communicates via SimConnect client data areas with the executable which is enough for my app.
The dll also allows stuff to do that is not (yet) implemented in SimConnect which was my primary reason to create the dll.

 

[Geoff_D]

I think you might really be best off by splitting your addon into a C++ dll (gauge or internally loaded dll) and an exe (VB) like i did simply due to the performance and lack of features issues. In my case the dll communicates via SimConnect client data areas with the executable which is enough for my app.
The dll also allows stuff to do that is not (yet) implemented in SimConnect which was my primary reason to create the dll.

Thanks DocMoriarty,

Sounds like a plan.

It is "unfortunate" that the 100% simconnect solution is so CPU intensive.
Does not look good for future Simconnect products, and makes writting a MULTIPLAYER APP, using Simconnect a "JOKE".

What is FS coming to when an XML Gauge can run faster than a C++ Simconnect application !!!

Geoff_D

 

[fscats]

Did you ever manage to solve the user id issue? I am trying to write a mapping application for one of the bigger servers, and while I can easily get all the ground and airborne aircraft (using FSUIPC), I can't seem to find the gamespy user id in either FSUIPC of SIMCONNECT

Evan

 

[Geoff_D]

Did you ever manage to solve the user id issue? I am trying to write a mapping application for one of the bigger servers, and while I can easily get all the ground and airborne aircraft (using FSUIPC), I can't seem to find the gamespy user id in either FSUIPC of SIMCONNECT

Evan

Correct, I also believe that one CANNOT get the gamespy ID by FSUIPC or SIMCONNECT.

The "ideal" would be a NEW Simconnect function to get the Gamespy ID, and then convince Peter Dowson to have FSUIPC be able to return the Gamespy id (by interally using Simconnect, as it does for most FS parameters).

But step one is getting ACES to add that simconnect function, and I am unaware of any formal procedures or ways to get that done

 

[fscats]

I am so frustrated, the latest version of the SimConnect SDK is out, and still no gamespy id variable. I see statements by ACE/Msft that we should only use the SDK and not bypass it and they will not provide basic information!

 

[Geoff_D]

I am so frustrated, the latest version of the SimConnect SDK is out, and still no gamespy id variable. I see statements by ACE/Msft that we should only use the SDK and not bypass it and they will not provide basic information!

Two options, now that FSX has stabliized as Xpack or SP2.

(1) Find some way to ask ACES to add the extra functionality to simconnect, and wait for that to be done. ( Don't hold your breath )

(2) Bypass Simconnect, and figure out how to get the information yourself. At least with this method, YOU have some control over your success in getting the desired results.

Add to the list of "Multiplayer ID"

READ/WRITE MP Sim Date
READ/WRITE MP Sim Time
READ/WRITE MP Weather Mode ( might already be there ? )
READ/WRITE MP COM2 Freq (Indexing from COM1 to COM2 does not work)

 

[fscats]

Only problem with "bypassing" simconnect, is that I still don't know how to get at the multiplayer id, even if I created a "guage" to gather the data. Any hints?

 

[Geoff_D]

Only problem with "bypassing" simconnect, is that I still don't know how to get at the multiplayer id, even if I created a "guage" to gather the data. Any hints?

You can get MP IDS from within a Gauge.
See RADAR.CAB ... session_info.xml

What I do not think you can do is to get that information via Simconnect.

 

[fscats]

Thanks for the hint on the radar.cab! It may also solve another issue I am working on

Now I just have to learn how to program a guage that updates an external database. Sigh, more work to do.

Evan

 

[Geoff_D]

Thanks for the hint on the radar.cab! It may also solve another issue I am working on

Now I just have to learn how to program a guage that updates an external database. Sigh, more work to do.

Evan

That would have to be a "C" programmed Gauge ... I am reasonably sure that there is no way to access a database from an XML Gauge
Geoff_D

 

[Testili]

Hi Geoff_D,

I assume, your problem with the Gamespy IDs is solved already or you do not really need it, since you can go with the Gauge. I cannot offer a simconnect-solution, too.
So far I made a .dll, which still will get the multiplayer IDs - in a completely different way (actually by hooking into the game). You dont need a gauge for it, thats perhaps the point, and you can implement it in any managed simconnect solution.
It is so far still very slow (I will try to make it faster with the time), so if you are about speed, this will not help you. Its not really elegant up to now.
Another problem for me is, that I have a German computer, german FSX and everything is german. So I can never say, if my code will work for an international version of FSX as well, since many variables I need for getting the Multiplayer stuff are german too and so I can only guess what that should be in English.
If you ever might use my dll, you could give me a reply, if it is working for you, too.

You can download the .dll at www.fsxtools.de (Downloads --> gamespy.dll)

Some simple C# implementation example (actually a WPF with only one button):

...
using gamespy; // Actually thats my lib you can download
...
private void button1_Click(object sender, RoutedEventArgs e)
{
IntPtr tid = gamespy.gamespy.init(); //Init
List<string> testlist = gamespy.gamespy.Multiplayer(tid); //Get the Gamespy Nicks + Callsigns of Aircrafts
int i = 0;
string spielernamen = "";
while (i <= testlist.Count - 1)
{
spielernamen = spielernamen + " " + testlist;
i++;
}
MessageBox.Show("Online Player: " + testlist.Count + " - Namen: " + spielernamen);
...


Sincerely,
Chris.

 

[Geoff_D]

Hi Geoff_D,

I assume, your problem with the Gamespy IDs is solved already or you do not really need it, since you can go with the Gauge. I cannot offer a simconnect-solution, too.
So far I made a .dll, which still will get the multiplayer IDs - in a completely different way (actually by hooking into the game). You dont need a gauge for it, thats perhaps the point, and you can implement it in any managed simconnect solution.
It is so far still very slow (I will try to make it faster with the time), so if you are about speed, this will not help you. Its not really elegant up to now.
Another problem for me is, that I have a German computer, german FSX and everything is german. So I can never say, if my code will work for an international version of FSX as well, since many variables I need for getting the Multiplayer stuff are german too and so I can only guess what that should be in English.
If you ever might use my dll, you could give me a reply, if it is working for you, too.

You can download the .dll at www.fsxtools.de (Downloads --> gamespy.dll)

Some simple C# implementation example (actually a WPF with only one button):

...
using gamespy; // Actually thats my lib you can download
...
private void button1_Click(object sender, RoutedEventArgs e)
{
IntPtr tid = gamespy.gamespy.init(); //Init
List<string> testlist = gamespy.gamespy.Multiplayer(tid); //Get the Gamespy Nicks + Callsigns of Aircrafts
int i = 0;
string spielernamen = "";
while (i <= testlist.Count - 1)
{
spielernamen = spielernamen + " " + testlist;
i++;
}
MessageBox.Show("Online Player: " + testlist.Count + " - Namen: " + spielernamen);
...


Sincerely,
Chris.

Chris

If you can the Gamespy name for each MP player, then I assume by a similar tecchnique you can get the COM1 Frequency for each player.

Then the $64,000 question, is, can you get the COM2 Frequency ??

Currently, TrafficInfo doe snot seem to work with Indexed variables , so the only COM Freq that can be got by TrafficInfo, is COM1.

If you can somehow get the COM2 Frequency ( and the COM2 Transmitting state), the I would be most interested.