Simconnect - interim rating :-)

[Guest rbumm]

Hi, I just wanted to post a short overall rating of Simconnect. We have succeeded in porting a complex FS addon in only some weeks to FSX via Simconnect without major problems. Simconnect has shown to be stable, scalable, event driven, peek&poke-free, fast and, once you get the hang out of it, very efficent from the programmer's point of view. We can do almost everything that is needed with the SDK - there are only a few points like setting the sim speed to integer values directly or the problem that FSX, in windowed mode, 'forgets' it's sound as soon u switch to a different application window (if anybody has a solution, please post a reply!). On the other hand, writing a sim-aircraft and helicopter full working display of all objects on the EFIS of our addon took no longer than 24 hours. I have read elswhere that FSX and Simconnect have shown to have bugs and -hangs. We have not experienced that here after several man weeks of testing on two systems, and from 2300 client downloads we had only 2 with major problems, both were able to repair their Simconnect installation. So: Please, developers, consider writing your new FSX sources via DIRECT Simconnect interaction and USE the SDK. It's really easy ! And - calling a DLL (you know which) to make it call another DLL which calls FSX (and back) is a waste of system resources (if not client bucks). Maybe a good opportunity to wish all of you a happy and successful 2007. People who thank Microsoft usually get bashed. Nevertheless: Thanks, MS, for this superb SDK. FSX - Great things to come !rudolf

[Guest DocMoriarty]

I agree to some extent with your point of view. Though IMO SimConnect lacks some very basic functionality and i'm not absolutely satisfied with some aspects of the managed wrapper, which is why i started to write my own.Basically SimConnect is what FS developers should have provided already like roughly 1000 years ago when they realized that opening the product for modders by providing an SDK is very beneficial for FS.What i'm missing most is an "official" SimConnect way for very simple dialog stuff, such as displaying a message like "Entrance open", "Passengers boarded" etc. The icing would be a way to pop up a dialog like the ATC window with some text and a number of options (1-0) that a user can select from and the result being transferred back to the simconnect client as client event or something like that.Another thing that i would like to have is, that missions can by defined way more dynamically, that is that i set up waypoints, triggers and whatnot right while the player is in the sim (something like a "BeginMissionDef" + "Define this and that and a reward" + "EndMissionDef(activate=true)". This would allow to implement some Mission templates and then filling them in with current situational data without interrupting the immersion of the player. I guess though there might be a way to to that nearly seamless with what we currently have.I also would like to be able to place objects permanently in a scenery in a non-SDK-FSX-average-joe-version. For example when the player gets an object as mission reward or "buys" something like a hangar, office building, fueltanks or whatever it would be nice to be able to permantly set this up somewhere in the scenery without interrupting the immersion.And i'm sure there are many more ideas around of what should be included.I'd say SimConnect is very good start but definitly not the end.Edit: oops forgot something: i'm one of those that experienced weird startup behaviour of simconnect that goes as far as locking and/or crashing fsx when multiple clients attach. That should be adressed ASAP imo.

[Guest rbumm]

>Basically SimConnect is what FS developers should have>provided already like roughly 1000 years agoabsolutely :-) >What i'm missing most is an "official" SimConnect way for very>simple dialog stuff, such as displaying a message like>"Entrance open", "Passengers boarded" etc. The icing would be>a way to pop up a dialog like the ATC window with some text>and a number of options (1-0) that a user can select from and>the result being transferred back to the simconnect client as>client event or something like that.Yes, true, forgot about this. I wish it would be possible to create FSX dialog boxes AND 'clean' FSX child windows with simple SDK functions.>I also would like to be able to place objects permanently in a>scenery in a non-SDK-FSX-average-joe-version. For example when>the player gets an object as mission reward or "buys">something like a hangar, office building, fueltanks or>whatever it would be nice to be able to permantly set this up>somewhere in the scenery without interrupting the immersion.This very much sounds like 'Second Life'. I points into a totally different and interesting direction - creating a global scenery and flight system which can be interactively expanded by the users and used by FSX clients (if they click 'expand scenery' and 'allow third party use' ??), allowing them to set up own more detailed parcels, airlines, ATC sectors, flight schedules, flight schools, air shows, transporting passengers and cargo and providing interesting public areas and adventures for exploration, even 'loosing' a inbuild plane after a crash for a certain time period. You should no longer need to scan long 'new addon' lists in FS websites, but just visit an aircraft manufacturer within the sim, have a look at a demo flight of the new product or select newly available scenery or freeware for auto-download and installation upon start of the simulation ...BTW: Basic flying in 'Second Life' (http://www.secondlife.com) in planes and helicopters is possible. Passenger transport can be realized. The programming interface is very limited, flight models are unrealistic, but we were at least able to set up basic flight systems there. I like the idea of walking around there as a 'person', working in a private hangar, interacting and meeting with users and more. But this (in a flightsim) is all very far away, if not too complex to realize ...

[Pete Dowson 558]

>So: Please, developers, consider writing your new FSX sources>via DIRECT Simconnect interaction and USE the SDK. It's really>easy ! And - calling a DLL (you know which) to make it call>another DLL which calls FSX (and back) is a waste of system>resources (if not client bucks).Hear hear! I was more or less committed to write a new version of that DLL as a sort of interim measure to allow as many add-ons as possible to be carried forward from previous versions in the early months of FSX. After all, this is 'that' DLL's prime purpose -- compatibility. And as it was for almost temporary use, I deliberately restricted myself to using SimConnect as much as possible, rather than face the severe pain of all that hacking (many thousands of hours) I've had to do with all previous releases, even though the traditional methods would have been so much more efficient. There are still three specific "hacks" used, but all of these I hope will be resolved in future SimConnect updates.I hope that eventually SimConnect will meet everyone's needs fully, and used directly. That is the aim and it was always the aim during its development, which I participated in fully. The early problems that some are experiencing (and it is indeed a small proportion -- much smaller than the proportion you quote for your product by my reckoning based on my own user figures) will hopefully be resolved by the first update in any case, and then I would expect a surge of SimConnect client applications. By the time FSXI (?) comes out I most certainly hope to have had a lot more time to actually fly my simulators rather than only program and test!Happy New Year!RegardsPete Dowson

[Guest rbumm]

>Hear hear! I was more or less committed to write a new version>of that DLL as a sort of interim measure to allow as many>add-ons as possible to be carried forward from previous>versions in the early months of FSX. After all, this is 'that'>DLL's prime purpose -- compatibility. And as it was for almost>temporary use, I deliberately restricted myself to using>SimConnect as much as possible, rather than face the severe>pain of all that hacking (many thousands of hours) I've had to>do with all previous releases, even though the traditional>methods would have been so much more efficient. There are>still three specific "hacks" used, but all of these I hope>will be resolved in future SimConnect updates.Pete, that is one of the reasons why I wrote this post. As Simconnect is reliable, fast and safe I wanted to suggest that developers should use it directly rather than doing it the 'quick' or 'interim' way. I am amazed with SC's concept, was able to extract all AC parameters, weather information, AI and MP data via Simconnect, basic sim data, joystick data. To be honest,I did not expect this was going to happen in FSX. You read many comments recently in which users say: I bought FSX, but will stick to FS9 for some time because ... So there is, imo, plenty of time to implement direct Simconnect algorithms into addon sources. I can imagine how much work went into the offset work, I even found one or two (in hours) myself when we enhanced FDSConnection for FSPilot. Needless to say that this continous work is much appreciated !>>I hope that eventually SimConnect will meet everyone's needs>fully, and used directly. I think it already does>The early problems that some are experiencing (and it is>indeed a small proportion -- much smaller than the proportion>you quote for your product by my reckoning based on my own>user figures) It is 2 out of 2300 here. BUT: I don't know how much it will be when addon developers will start using SimConnect widely - having a 5-7 simultaneous SimConnect addons sending data requests. Difficult to test, this ....I read one or two posts from your website and had the impression that there were some more problems reported recently. Must be difficult anyway to comment on problems with addon X or Y (in combination with Z) using FSUIPC and/or Simconnect standaloneHappy new yearrudolf

[Pete Dowson 558]

>>I hope that eventually SimConnect will meet everyone's needs>>fully, and used directly. >>I think it already doesWell, no, not everyone's I assure you. From where I sit there are many shortfalls, which are known to Microsoft and I hope are on their list for "dealing with" in due course. One of these is quite basic -- the weather setting facilities just don't work properly. Just one "little" example, when the METAR string is sent to set the weather, the upper wind settings are set except for the direction which is always a copy of the ground wind direction. I know that the ActiveSky folks have done a marvellous job trying to overcome this, but the facility is actually plain broken.Other things: the input and output METAR formats are completely different in all detailed aspects, and you cannot actually read back some details of the weather even though you can, theoretically, set them.There are no facilities to set the weather at the aircraft or influence visibility or other factors in that vicinity. The best I could do was to go through a long process to identify the 9 nearest WX stations around the aircraft and read/modify/write the weather for each. Unfortunately that produces even more problems (like the sudden appearance of 0000 visibility, and horrible graphic effects which are then hard to remove).There's no way to make temporary changes to the wind effect at the aircraft to provide special effects like local turbulence, windshear, microbursts, and lift/sink for gliders. The variables are amongst the very many that FSUIPC could write to in previous releases which are read-only in SimConnect.There is no support for deleting a selected AI aircraft unless it is one created by your own program. This is despite the fact that any user can do it via the Traffic Toolbox.There is pretty much no support for changing options set via menu dialogues. I had to hack into the code again even to do relatively basic things like reduce or restore the traffic levels, something which can be quite important for automatically optimising approach frame rates, amongst other things.There is no support for showing add-on windows over full screen FSX. Again, I had to hack into the code to provide these facilities which we've been using via FSUIPC since FS2000 days.There is still no possibility of interaction or control of the built-in ATC, a problem I've been wanting to solve and not managed since FS2002.We can't interact with Scenery variables through Simconnect as we could with FSUIPC on previous versions.Do you want any more details?I have negotiated with MS to resolve these things, and I do have some confidence that most if not all will be resolved in due course, hence my statements in my earlier message. But "meeting everyone's needs fully" at present? Sorry, I think not.Happy New YearPete

[Pete Dowson 558]

>It is 2 out of 2300 here. Once you whittle out problems where Simconnect isn't installed correctly, for some unfathomable reason (there are a lot of those, needing a folder deleted and FSX repaired), and the firewall/security blockages, and the problem that enabling MultiPlayer mode kills the data returns from SimConnect until you re-connect, all of which are completely independent of any particular add-on Client, then a similar or better proportion applies to my programs too. Maybe your users who suffer these things resolve them elsewhere. I do notice non-FSUIPC users asking the same sort of questions in my Forum.After those above, the most common one is where two clients or more are starting together. SimConnect most certainly corrupts something else in FSX when this happens. Since FSUIPC is probably the most likely "other client" folks will be using when they have more than one, I tend to get these reported to me also. Maybe a proportion of those would otherwise be yours too?The one other main SimConnect bug is that, when it is busy, and usually with more than one client, and FSX is fairly heavily loaded, SimConnect often logs an "I/O Error" and simply stops talking to whichever client it was talking to at that time.All these bugs have been reported both directly to the FS Team and via tell_fs@microsoft.com, and I know they have reproduced some (e.g. the security blockages and the MultiPlayer bug), so I have high hopes of fixes in due course.I really don't know if they've yet discovered how or why on some systems SimConnect just doesn't install correctly in the first place, though.Oh, one other niggle. In case you are not aware of it, if someone follows the instructions to set up a remote client (over a Network), and includes the example SimConnect.xml in their FSX PC accordingly, then SimConnect stops servicing all local clients -- DLLs, EXEs, whatever. It appears that the "global" setting does not really mean "global" but "remote", and a "local" entry needs to be added too. I would class this as a bug too.Best RegardsPete

[wsieffert 0]

When I read Rudolf's first post, I thought Pete wasn't going to be happy. I was pleasently surprised by Pete's "Here-here".While I don't cruise this forums or use MSFS as much as I did in the past six years, I want to thank Pete for FSUIPC and all his work with or without MS help. I don't believe MSFS would be as well received or used. if Pete hadn't taken up the interface cause.It is nice MS finally provided an interface tool.Happy New Year to all aviator's and simulator aviator's!!W. Sieffert

[Guest rbumm]

>and the problem that enabling>MultiPlayer mode kills the data returns from SimConnect until>you re-connectThis is strange. We tested FSP in MP mode and used it for a nice ILS approach with autolanding in Vancouver. I remember I did this twice because there was a very skilled traffic controller online (worth connecting again, anyway). I did not notice any data loss during the MP session .... >all of which are completely independent of any>particular add-on Client, then a similar or better proportion>applies to my programs too. Maybe your users who suffer these>things resolve them elsewhere. I do notice non-FSUIPC users>asking the same sort of questions in my Forum.>That may be the case. Well, I am sure these problems will turn up then. >The one other main SimConnect bug is that, when it is busy,>and usually with more than one client, and FSX is fairly>heavily loaded, SimConnect often logs an "I/O Error" and>simply stops talking to whichever client it was talking to at>that time.>We will try to install more addons to test this. If you need to please use our FSXP to create a fairly high simconnect workload (numerous variables are requested and written, and drawing the EFIS consumes cracky bits of CPU power). I'll send you a regkey direct mail ...>I really don't know if they've yet discovered how or why on>some systems SimConnect just doesn't install correctly in the>first place, though.Right, that happens, and I don't know why too >Oh, one other niggle. In case you are not aware of it, if>someone follows the instructions to set up a remote client>(over a Network), and includes the example SimConnect.xml in>their FSX PC accordingly, then SimConnect stops servicing all>local clients -- DLLs, EXEs, whatever. It appears that the>"global" setting does not really mean "global" but "remote",>and a "local" entry needs to be added too. I would class this>as a bug too.>This is all very interesting stuff, Pete, and it's good to know that people at MS are notified. Kind regardsrudolf

[Pete Dowson 558]

>This is strange. We tested FSP in MP mode and used it for a>nice ILS approach with autolanding in Vancouver. I remember I>did this twice because there was a very skilled traffic>controller online (worth connecting again, anyway). I did not>notice any data loss during the MP session .... No, sorry, I think you misunderstand. The problem only occurs on the transition from non-MP mode to MP mode, not during MP mode. Any client currently receiving notifications of data variable changes (the SimVar data) or SimEvents, via the excellent message method (rather than the poorer polling method) stops receiving any data after MP mode is started, and it doesn't resume unless the client re-establishes all of its data definitions and requests -- or re-connects.Luckily this one easy easily worked around by simply using a timeout and reconnecting. It has been reproduced and identified by MS so it will certainly be fixed.>If you need to please use our FSXP to create a fairly high>simconnect workload (numerous variables are requested and>written, and drawing the EFIS consumes cracky bits of CPU>power). I'll send you a regkey direct mail ...Okay, thanks. I'll try it tomorrow.Best regards,Pete

[Guest scotthendry]

>>>I hope that eventually SimConnect will meet everyone's needs>>fully, and used directly. >>I think it already doesI'm sorry Rudolf but I have to disagree with you there. As a cockpit builder I had certain hopes and expectations for SimConnect. The main one was that we would be finally freed of the "polling for variables" that is required with FSUIPC (Sorry Pete). I was hoping that we'd get a truly event driven interface so that cockpit systems could be changed as sim variables change.How many times does the landing gear cycle in a flight? A: two. So why should my program have to keep asking FSX if the landing gear lever has moved every n milliseconds? Come on Microsoft, you can do better.BTW the callback functionality in the Simconnect SDK still requires polling via CallDispatch to get updates sent.

[Pete Dowson 558]

>So why should my program have to keep asking FSX if the>landing gear lever has moved every n milliseconds? Come on>Microsoft, you can do better.I don't understand. I don't keep asking for FS SimVars or Events. They are notified when things change. I can even say "only notify me if they change more than this amount" (the fEpsilon value), and I can restrict the frequency to once per frame, per visual fram or 1 second, at a maximum.What SimConnect are you using which is so different?>BTW the callback functionality in the Simconnect SDK still>requires polling via CallDispatch to get updates sent.No it doesn't! Just use the Message facility. Then, when there is data for your program it receives a message, and THEN you use CallDispatch to get whatever is ready.It sounds like you aren't using SimConnect very efficiently. What worries me much more is the latency, imposed by it being not just asynchronous (as FSUIPC's interface is in any case owing to the Message system and process switch), but the use of TCP which appears to be grossly inefficient for this application, at least for internal DLLs, part of the FSX process.Best RegardsPete Dowson

[Guest scotthendry]

>What SimConnect are you using which is so different?>>>BTW the callback functionality in the Simconnect SDK still>>requires polling via CallDispatch to get updates sent.>>No it doesn't! Just use the Message facility. Then, when there>is data for your program it receives a message, and THEN you>use CallDispatch to get whatever is ready. Ok, I haven't twigged to that yet.:-roll I just looked at the examples and most of them poll CallDispatch. I thought that was pretty inefficient. I'll have a bit more of a digThanks PeteUpdate: I found an example program that I think is what you meant by the message facility, it's called "windows". Is this the right one to use as a guide? If not, how do I "use the Message facility"? Did you mean the SubscribeToSystemEvent? If so and I use the code

while( 0 == quit && ::WaitForSingleObject(hEventHandle, INFINITE) == WAIT_OBJECT_0)		{			SimConnect_CallDispatch(hSimConnect, MyDispatchProcWE, NULL);		}

Isn't that just polling a different way?

[Pete Dowson 558]

>Update: I found an example program that I think is what you>meant by the message facility, it's called "windows". Is this>the right one to use as a guide?No idea, not looked at it. I've never got around to looking at any of the examples. Sorry. I thought they were all a bit primitive and not good examples at all in any case.>If not, how do I "use the>Message facility"? Did you mean the SubscribeToSystemEvent?No.>Isn't that just polling a different way?I don't do anything like that.Just create a Window. A message window will do, so it doesn't have any overheads like normal windows. Message windows are cxreated by something like this:hWndSimC = CreateWindow("your unique classname", "your unique window name", 0, 0, 0, 0, 0, HWND_MESSAGE, NULL, NULL, NULL);Pass the Window handle in the SimConnect_Open call, along with a message number:hr = SimConnect_Open(&hSimConnect, "your client name", hWndSimC, WM_USER, NULL, 0);In the WndProc for the message window, just process the WM_USER message, doing the SimConnect_CallDispatch there, thus:if(WM_USER == uMsg){ HRESULT hr = SimConnect_CallDispatch(hSimConnect, MyDispatchProc, NULL);...This probably isn't documented very well, I admit. I don't know if there are any examples.RegardsPete

[Guest scotthendry]

Pete:You're a hero! I'm actually programming in Delphi, but I think I can translate what you've done here. Thanks a squillion:-beerchug