Sign in to follow this  
Guest rbumm

Simconnect - interim rating :-)

Recommended Posts

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

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

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.

Share this post


Link to post
Share on other sites

>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 ...

Share this post


Link to post
Share on other sites

>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

Share this post


Link to post
Share on other sites

>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

Share this post


Link to post
Share on other sites

>>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

Share this post


Link to post
Share on other sites

>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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

>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

Share this post


Link to post
Share on other sites

>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

Share this post


Link to post
Share on other sites

>>>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.

Share this post


Link to post
Share on other sites

>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

Share this post


Link to post
Share on other sites

>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?

Share this post


Link to post
Share on other sites

>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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

That would also be a great opportunity for people like Jeroen Hoppenbrouwers and the PS1 community to jump in, since they have been using this system for years (over a TCP network). It IS the most efficient process to update a program's data, since it reduces the amount of polling and network/memory traffic significantly. If I use my application through FSUIPC on FS9 I get trouble-free operation on the same machine, but WideFS is restricting the traffic I can send to my remote machines making them hiccup a little. If (either local or remote) machines were to be simply notifed by FSX itself that some value changed, things would go a lot faster. Windows itself uses the same principle too, instead of every window polling where the mouse is every millisecond (the famous Shrek 2 line "Are we there yet??" applies here) a window is notified if some user clicks on it. With the 50fps we accept as a reasonable frame rate this is more than sufficient, and OpenGL applications can be built on the principle too (via GLUT).My current software is going to a stage where a generic event system will be used, which may be the best addition yet to connecting to SimConnect.On the side: Has anyone tried this on two SimConnects together (with two FS sessions) to do something like WidevieW?

Share this post


Link to post
Share on other sites

>If I use my application through FSUIPC>on FS9 I get trouble-free operation on the same machine, but>WideFS is restricting the traffic I can send to my remote>machines making them hiccup a little. If (either local or>remote) machines were to be simply notifed by FSX itself that>some value changed, things would go a lot faster.Something is seriously askew with your assessment here. WideFS is, in fact, doing pretty much EXACTLY what SimConnect is doing now -- sending only previously requested data when it changes. It always has been working in that way. The polling is only between the application program and WideClient, certainly not between Wideclient and WideServer as you are assuming.Direct polling is a result of Adan Szofran's original IPC interface, inplemented in FS5IPC, FS6IPC and FSUIPC as well, but most certainly never between WideClient and its Server! The problem with any such client/server system, however, is latency, and we are already seeing this as a problem now with SimConnect, even on the same PC as FSX. I am already getting requests to bypass SimConnect and go directly to the data inside FSX's block-box modules again. I am of course resisting, but nevertheless I can see both sides of the coin here.RegardsPete Dowson

Share this post


Link to post
Share on other sites

>Something is seriously askew with your assessment here. WideFS>is, in fact, doing pretty much EXACTLY what SimConnect is>doing now -- sending only previously requested data when it>changes. It always has been working in that way. The polling>is only between the application program and WideClient,>certainly not between Wideclient and WideServer as you are>assuming.Hi Pete and thanks for the quick reply,I may be using an old version of FSUIPC and the WideFS combo, and I know the problem is much worse when you use managed code (the .NET variant) than direct C/C++ communication with the FSUIPC library. I have been able to get very decent frame rates through a WideFS connection, however I know that at least older variations of WideFS allow for a larger amount of time between received data frames (I have read a doc saying 500ms should be between requests), but I don't know in how much it changed in newer versions of WideFS. I do know that Project Magenta is using heavy amounts of data interpolation (check the pmRJ EICAS for an example) instead of using the more accurate data directly.>Direct polling is a result of Adan Szofran's original IPC>interface, inplemented in FS5IPC, FS6IPC and FSUIPC as well,>but most certainly never between WideClient and its Server! Does WideClient implement a "Request/Response" mechanism or does WideServer actively monitor FSUIPC data constantly and send out a packet to all clients with the changes once they occur? It's the classic "push vs. pull" discussion that has actually baffled programmers for decades already (and became only more prudent after near-real-time applications like games came to the PC's)>The problem with any such client/server system, however, is>latency, and we are already seeing this as a problem now with>SimConnect, even on the same PC as FSX. I am already getting>requests to bypass SimConnect and go directly to the data>inside FSX's block-box modules again. I am of course>resisting, but nevertheless I can see both sides of the coin>here.I'm not sure where the latency comes from. Since most systems capable of running FSX have a decent amount of computing capacity and enough memory, that should not be as much of an issue (Moore's Law is fast enough here). But SimConnect may be relying on a socket or mapped memory file in the Windows kernel at some point for communicating with FS, and here is where it may go wrong, possibly causing underruns or overruns in the shifting of memory around. If SimConnect somehow interacts with the FSX main loop directly and gets its events there, there shouldn't be much trouble, but it is also possible that SimConnect gets a piece of (mapped) memory from FSX and has to monitor it for changes every cycle, causing latencies.I know that the people working with Aerowinx PS1 have built successful simulators (like Matt Sheil's full-mission 744 flight deck) based on a communication protocol that is as simple as plain text TCP messages. The trick they use is to split up some tasks of the simulator (mainly simulating and visual generation), offloading the load on the "server" machine providing the simulator data, but increasing the amount of network usage. Since most simulators these days are built upon 100MBit or even Gigabit networks, that will not quite form the bottleneck for the years to come. Visual generation on those sims is done through a 'slaved' session of FS, while Aerowinx Precision Simulator is used for the simulation logic. That is also exactly the way professional simulators do their thing and guarantee reliability. If one of the core simulation systems fails, another takes over since it has an upsynced copy of the internal simulator data. Most sim systems work in sets of three (like an autopilot system on a 747/767/777) and constantly correct each other for minor glitches in the FDM.I've been to the SIMONA sim in Delft where i study and there it's clearly visible: a set of six IBM SimFinity systems providing visuals and flight dynamics in groups of three. Since a flight dynamics system itself isn't very taxing on a system (at least not the FDM level used by consumer level sims) it wouldn't be unthinkable to make a threesome of older systems run the FDM and use a more elaborate system for the visuals. Keep in mind that even commercial simulators have graphics that are way beneath the level displayed in FSX -- the only upside is that they are way more smooth and visually accurate in terms of terrain, etc. but no telephone poles, trees, randomly generated buildings or reflective sea water.

Share this post


Link to post
Share on other sites

>I may be using an old version of FSUIPC and the WideFS combo,>and I know the problem is much worse when you use managed code>(the .NET variant) than direct C/C++ communication with the>FSUIPC library.No idea about managed code. Sorry. It always seemed a dreadful idea to me, most inefficient.>... I know that at>least older variations of WideFS allow for a larger amount of>time between received data frames (I have read a doc saying>500ms should be between requests)No, you misread it then. There's no allowance needed except between the very FIRST request for data -- WideServer does not supply all data willy-nilly (just like SimConnect which does not, either). It has to be requested. Once requested, the data is supplied (Server to Client) whenever it changes, irrespective of how often the client application asks Wideclient for it. However, obviously the first time new data is requested by a particular client there are two transactions required -- a frame to the Server and a response back. That's usually still much less than 100 mSecs altogether, but WideFS always offered an initial delay of 500 to be sure. With most application programs that only occurs during their initialisation.All versions of WideFs, for the last 8 years or so, have operated on the Server/Client basis exactly the same as SimConnect.>I do know that>Project Magenta is using heavy amounts of data interpolation>(check the pmRJ EICAS for an example) instead of using the>more accurate data directly.Becasue it is trying to update the larger gauges at higher frame rates and smaller increments that can be supported by FS's frame and data update rates. Compare the jerky ratcheting FS panel gauges with the smooth PM gauges some time -- that's why Enrico does such things. It's a lesson gauge makers could take on board too.>Does WideClient implement a "Request/Response" mechanism or>does WideServer actively monitor FSUIPC data constantly and>send out a packet to all clients with the changes once they>occur?Er ... that's not fully a sensible question, put like that. WideClient operates an FSUIPC interface to the client applications. Its interface with the Server is exactly as I said -- it requests data the first time an application asks for it, and thereafter the Server keeps it updated without further requests being needed. WideServer maintains seperate data lists for each client, according to their needs, and watches for the changes. This is why WideFF is more efficient using a network via a switch -- it isn't sending the same data to every client.>I'm not sure where the latency comes from. Since most systems>capable of running FSX have a decent amount of computing>capacity and enough memory, that should not be as much of an>issueAsk folks who want to make smooth changes to an aircraft's position, for STOL and VTOL operations, for example. with FS2004 and FSUIPC's direct control over FS's values they can get virtually instant and smooth control. Via SimConnect and its asynchronicity the results are too jerky to be usable. There's too much delay between input and result. I'm hoping MS will be able to imporve it, but I'm not sure how much they can do.>But SimConnect may be>relying on a socket or mapped memory file in the Windows>kernel at some point for communicating with FSSimconnect is using Windows sockets, TCP protocol, in both directions. I thought that was well known by now.RegardsPete

Share this post


Link to post
Share on other sites

>>I may be using an old version of FSUIPC and the WideFS>combo,>>and I know the problem is much worse when you use managed>code>>(the .NET variant) than direct C/C++ communication with the>>FSUIPC library.>>No idea about managed code. Sorry. It always seemed a dreadful>idea to me, most inefficient.Tell me about it, that sort of thing is never meant to run even at near real-time applications. I've used a port of the FSUIPC user library to .NET and can tell you it is dreadfully slow, which is to be expected.>>... I know that at>>least older variations of WideFS allow for a larger amount>of>>time between received data frames (I have read a doc saying>>500ms should be between requests)>>No, you misread it then. There's no allowance needed except>between the very FIRST request for data -- WideServer does not>supply all data willy-nilly (just like SimConnect which does>not, either). It has to be requested. Once requested, the data>is supplied (Server to Client) whenever it changes,>irrespective of how often the client application asks>Wideclient for it. However, obviously the first time new data>is requested by a particular client there are two transactions>required -- a frame to the Server and a response back. That's>usually still much less than 100 mSecs altogether, but WideFS>always offered an initial delay of 500 to be sure. With most>application programs that only occurs during their>initialisation.I did misread it then, and that may have also been the cause of my performance issues -- since in the first versions of my app I used more than one request to pull out several aspects of the aircraft's data out of FS -- in the latest version I'm using one request for everything. Isn't it possible to pull a whole chunk of memory (from the beginning of the FSUIPC data to the end) in one go by any way? That way I could process it in-memory later which may even be faster than using token variables.>All versions of WideFs, for the last 8 years or so, have>operated on the Server/Client basis exactly the same as>SimConnect.>>>I do know that>>Project Magenta is using heavy amounts of data interpolation>>(check the pmRJ EICAS for an example) instead of using the>>more accurate data directly.>>Becasue it is trying to update the larger gauges at higher>frame rates and smaller increments that can be supported by>FS's frame and data update rates. Compare the jerky ratcheting>FS panel gauges with the smooth PM gauges some time -- that's>why Enrico does such things. It's a lesson gauge makers could>take on board too.I'm doing bits of interpolation on my displays too, but they're small bits and I don't want to interpolate large changes as this results in a virtual "inertia" on your gauges (e.g. giving them a maximum rate of change). >>Er ... that's not fully a sensible question, put like that.>WideClient operates an FSUIPC interface to the client>applications. Its interface with the Server is exactly as I>said -- it requests data the first time an application asks>for it, and thereafter the Server keeps it updated without>further requests being needed. WideServer maintains seperate>data lists for each client, according to their needs, and>watches for the changes. This is why WideFF is more efficient>using a network via a switch -- it isn't sending the same data>to every client.Okay, so the server always keeps tabs on the data that is requested by some application or another, and sends out a packet when neccessary. I know WideClient is just a front end for applications that use FSUIPC natively, is it possible to connect to WideServer directly? (obviously for that you will need the data / protocol format, but I'm not sure if you're willing to share that)>Ask folks who want to make smooth changes to an aircraft's>position, for STOL and VTOL operations, for example. with>FS2004 and FSUIPC's direct control over FS's values they can>get virtually instant and smooth control. Via SimConnect and>its asynchronicity the results are too jerky to be usable.>There's too much delay between input and result. I'm hoping MS>will be able to imporve it, but I'm not sure how much they can>do.For the fastest works, use FS04 with FSUIPC on the same as FS is running on. Works for me all the time.>Simconnect is using Windows sockets, TCP protocol, in both>directions. I thought that was well known by now.If they use TCP for local connections also, then you have practically isolated the problem since Winsock is a really dirty piece of software. Especially when you use TCP to communicate data that is in a different part of the same machine's memory you're shooting a mosquito with an AA gun -- a very slow one, that is. Count to that the common programming mistakes first-time socket programmers make (e.g. writing or reading one byte at a time through TCP) and you're introducing seconds of latency along the way. Using sockets to communicate locally is not incorrect, however, since UNIX servers do it all the time and have no problems with it, but it's not exactly suited for real-time applications. For a real-time app you'll be wanting a simple UDP-based interface (something changed? Drop a UDP packet), since most UDP packets are translated into Ethernet packets almost directly (especially on a local network) and can be very smartly routed by the switch. You can do broadcast and multicast on UDP, something you cannot do on TCP, and UDP packets are message based (advantage, allows you to send/recv an entire struct in one go instead of waiting for a boundary character to come by), which reduces the amount of hassle on the network layer by orders of magnitude. Flight simulators like X-Plane and FlightGear have been using UDP packets since the start of their development, the only downside of UDP is the lack of reliability (that can be overcome by a simple parity/checksum mechanism).

Share this post


Link to post
Share on other sites

>that may have also been the cause>of my performance issues -- since in the first versions of my>app I used more than one request to pull out several aspects>of the aircraft's data out of FS -- in the latest version I'm>using one request for everything.Once you've asked for any item once, any further requests do not cause any extra traffic between WideClient and the Server in any case, so this is only an initialisation delay.The inefficiency in using multiple "FSUIPC_Process" calls instead of one per cycle (whatever your cycle may be) in in the process switching in that PC between your process and Wideclient (or FS+FSUIPC in the FS PC). This is the same no matter where you run your application. When you use "FSUIPC_Read" you are only adding another request to a list in memory, which is dealt with locally by Wideclient or FSUIPC when you do the Process call only.>Isn't it possible to pull a>whole chunk of memory (from the beginning of the FSUIPC data>to the end) in one go by any way?Yes. Have you never tried to use FSInterrogate and done this there?But it is EXTREMELY inefficient. Within those 65536 bytes many different ones will be changing, and everything that is changing will have to be sent every time, even if you aren't really interested. It will slow FS down enormously as well as your local PC. It is ALWAYS much much more efficient to build up a minimum list of your needs by FSUIPC_Reads, then do the one Process call. On a Client PC the first time this may take hundreds of milliseconds, but after that it will be fast.>Okay, so the server always keeps tabs on the data that is>requested by some application or another, and sends out a>packet when neccessary. I know WideClient is just a front end>for applications that use FSUIPC natively, is it possible to>connect to WideServer directly? (obviously for that you will>need the data / protocol format, but I'm not sure if you're>willing to share that)Why would you want to? It's a *connected* link, so if you are connected no other application on the same PC will be able to. That is very limiting!I've no documentation of the WideFS packet formatting and protocols, they were evolved rather than designed, but I have heard of folks decoding them for implementation on, for example, MACs. I don't object to any of that, but I'm really not willing to spend the time documenting them or supporting other implementations. This is especially so now that SimConnect provides the function and I would expect, over time, folks to change to that.>If they use TCP for local connections also, then you have>practically isolated the problem since Winsock is a really>dirty piece of software. Especially when you use TCP to>communicate data that is in a different part of the same>machine's memory you're shooting a mosquito with an AA gun -->a very slow one, that is.Do you think I don't know this? I am thumping on MS's door all the time about this method of connection. I expressed my doubts way back, but they assured us that their performance checks showed otherwise. I'm not sure what they were measuring, but it really didn't turn out good enough -- yet. I am still hoping.>For a real-time app>you'll be wanting a simple UDP-based interface (something>changed? Drop a UDP packet)I use the UDP option for WideFS on most of my 10-PC cockpit Network, but you have to watch it. There's no checking, it isn't guaranteed to arrive, and packets can actually arrive out of order (especially, for instance, in a firewire looped network as I used once).It isn't too bad for simple things like gauge updating, because if you miss one the next will be along soon enough, and out of order packets self-correct next time too. But controlled switching and so on is much more critical.I check my WideFS logs regularly -- if any errors are reported (it logs missing frames and out-of-order sequencing) I have to find and fix the cause or change that PC back to TCP. I use TCP for my pmSystems and ActiveSky PCs in any case since almost all of their work involves writing TO FS, not reading back, and order is more critical and omissions a pain.RegardsPete

Share this post


Link to post
Share on other sites

>>No idea about managed code. Sorry. It always seemed a>dreadful>>idea to me, most inefficient.>>Tell me about it, that sort of thing is never meant to run>even at near real-time applications. I've used a port of the>FSUIPC user library to .NET and can tell you it is dreadfully>slow, which is to be expected.I'm playing catch up a bit on this conversation, and I apologize for being late to the party, but I think things like the new XNA framework and the older Managed DirectX kind of show that it is feasible, when using the built in garbage collection properly, to run real-time applications with managed code.

Share this post


Link to post
Share on other sites

>>I'm playing catch up a bit on this conversation, and I>apologize for being late to the party, but I think things like>the new XNA framework and the older Managed DirectX kind of>show that it is feasible, when using the built in garbage>collection properly, to run real-time applications with>managed code.I really want to give XNA a try, maybe it can turn out into something really useful for developers. I know you use it, but have you got any working examples (binaries) that I can toy around with? Maybe it'll run even better on Vista.

Share this post


Link to post
Share on other sites

I've got a pretty sketchy half finished primary flight display. Right now it's just the artificial horizon, but it works.I had to create a WinForms object and hide it, just to get back to the system messaging, since the XNA framework doesn't support it or hides it really well.Other than that, I've been making a 2D game engine. I have some free time tonight, what sort of thing would you like to see get done with it?

Share this post


Link to post
Share on other sites

>I have some free time tonight, what sort of thing would you>like to see get done with it?Just putting it online somewhere would be great, so I can have a test and all. My first experiments with glass cockpits were in GDI+ and Visual Studio .NET and I found it really easy to manipulate code or to do things quickly. I later switched to OpenGL for performance reasons.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this