SimConnect

#1
First of all I would like to congradulate you on SimConnect. FS community is large and loves to add on to flight sim. This is perhaps the single greatest reason why so many people use Microsoft Flight Simulator.
Being 'developer friendly' should be a top Microsoft priority.
I have some suggestions though.
First, is to document more examples for the managed code SimConnect API. The documentation for managed code in the SimConnect SDK is minimal.
Second, the construction of .BGL files should be released. Developers have the need to make custom/modify .BGL files to produce great addons. This is currently a weakness in the SDK. Eventually the developer community will accomplish this objective anyway.
Third, in my opinion SimConnect should also be released and documented so that developers can develop their own socket based clients for SimConnect.
Fourth, I can not stress this enough, the more developer friendly and open the SDK is the better, it is the reason for FS's success.

Ok there are some ideas.
 
Last edited:
#2
One other weakness of SimConnect API is the inability to 'time stamp' information received from FSX, i.e. sending a tick count (ms uptime since last reboot) with packets/data received from FSX. (.net and win32 both provide tick count functions)
Can not account for the latency of client applications, especially when the client application is not on the same machine as the machine running FSX. Network latency can not be accounted for between FSX and the client program. Makes synchronizing AI AC representing multiplayer aircraft potentially poor. I have extensively tested this and under some conditions is noticeable visually.
I have built a number of client test apps that I run from PC's other than FSX. It is actually how I develop my client applications. Easier to have FSX running on a high end game pc, and developing the apps from another pc, usually my laptop. Saves having to compile and publish apps and then installing and/or running on the FSX machine, for every potential build.
'Time stamping' packets transmitted to FSX would be a nice feature as well. I can think of several useful purposed for that as well.
Something to consider.
What makes you think that some of the packets are not time stamped ?

Geoff_D
 
#3
Fifth, if anyone wants to get together on developing a communication standard for FSX servers, that would be a good thing. Would be nice to have compatible addons. I am currently writing an FSX server which is all laid out. Would possibly be willing to bring some people on so that we can build compatible network apps. Also when that project is complete I will be building (hopefully) a separate client app so that those with FS2004 can fly on the FSX server. The main concept of the server I am building is to use TCP/IP connections from client to server, to promote stability. Then use peer 2 peer connections between the clients. However if the peer 2 peer connections fail because of routers/firewalls the server will be able to transmit position and other data to the client directly, but at a slower rate to conserve bandwidth. Thus if players on the server want to have good quality multiplayer experience they will configure their routers etc. With this technique we will not get the lame "can not connect to all players" or disconnects or the inability to connect. That was the big weakness of Direct Play. Concept here is maintain the connectioin on TCP/IP, failover to server client connection TCPI/IP, if UPD peer 2 peer is failing for that particular client. Testing has worked greatly so far.
Ok there are some ideas.
I think there are many that would love to see a decent "stand alone" FSX Server, and I guarantee we would have had at least one very powerful one by now, fully compatable with FSX, FS2004 & FS2002 if Aces had released a FSX MP SDK.

From what I have seen, the FSX MP system, that no longer uses Direct Play, is a far better MP and is true Client-Server, and would be a great starting point for further development.

Geoff_D
 
#4
Third, in my opinion SimConnect should also be released and documented so that developers can develop their own socket based clients for SimConnect. I personally do not care for the SimConnect managed API. It is very limiting to have to rely on the UI thread Windows message pump, especially in terms of latency and multithreading.
You don't have to use the Windows Message Pump to process messages, that's just one option. You can provide an event handle on the "new SimConnect(...)" line and process that on a background thread - in fact, this is the only way to do a SimConnect based WPF app (that I've found so far anyway :-> ).
 
#5
Hi gggdude,
What kind of variables are you using to change the AI position ? Only Lat/Lon/Lat/PBH, or also aircraft speed and acceleration ?
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#6
Guys, this is the forum for future SDK improvement suggestions. If you want discussions, please open a new thread in the normal SimConnect forum please.
 
#7
What I would would like Is access to the ATC String when the user replies to an instruction by Pressing a menu item.
Regards Frank
 
Top