Simmconnect is evil...

[BobP 56]

My name is Bob and I hate simconnect. I love FSUIPC. Yes, I know that FSUIPC is old technology. Yesterday's news, out of date. But you know what? It had one attribute that simconnect lacks. The darn thing worked. I have spent hours trying to get ASX to talk to FSX via a client. I give up and I hope that the ACES engineer/designer/programmer who thought that mess up (and two versions since RTM) also had a rotten fourth of July. I'm a pilot, not a network systems analyst. All I want is to install a program on a client, setup the network, like FSCommander,RC Contact, FlightKeeper, FSmoving Map, FS Realtime etc, that work great across the network via FSUIPC. I'm sure all the programmers are elated at the flexibility of simconnect, but for the END user, the customer, it is a confusing nightmare.Thanks for reading and I feel better already.:)Bob..

[DadJokeCinema 145]

I'm glad you feel like this is some place you can come and just vent and wish ill-will on others just because without adding anything constructive to the forum.

[BobP 56]

Thank you for the comments. And I do feel this website is a place to vent frustration once every ten years or so. I've been member on this forum since the late 1990's and have contributed what I can. The venting was at the end of days of following posts throughout the Internet to get it working. It was also at the end of several beers, yesterday. LOL. The fourth of July was lousy here because it rained. However, ASX still won't talk to FSX. Any suggestions?

[BobP 56]

Success. Part of it doesn't make sense. I had left out the local part of simconnect.xml file. That makes sense. I reinstalled simconnect sp2 on the server and client. Didn't work. Then I just installed simconnect sp1 on the client and it connects and updates weather. So, I have two different versions of simconnect (sp1 and sp2) installed on the client. Go figure. But I still like FSUIPC better and you can of course remove this thread if you feel it distracts from the forum. Thanks.

[Pete Dowson 558]

>Success. Part of it doesn't make sense. I had left out the>local part of simconnect.xml file. That makes sense.No, it doesn't. It works with FSX SP2 because they changed SimConnect to support local connections by default even if it is omitted. But if you were still using SP1 or RTM then removing the local connection would stop FSUIPC and all other local Simconnect clients altogether.>I reinstalled simconnect sp2 on the server and client. Didn't>work. Then I just installed simconnect sp1 on the client and>it connects and updates weather. So, I have two different>versions of simconnect (sp1 and sp2) installed on the client.>Go figure. That figures because each SimConnect client program is designed and compiled to work with a specific version of SimConnect. FSUIPC is one of the exceptions in that, whilst it needs the RTM version to get loaded, it then configures itself to use the latest it can find.But evidently the version of ASX you are using is compiled to use SimConnect SP1. I think it says as much in its dox. If you want your client PC to support any and all SimConnect clients you should install all three SimConnect's there -- RTM, SP1 and SP2. Then it will be like your FSX server PC.This is what Microsoft's "side-by-side" library version control is all about.RegardsPete

[BobP 56]

Thanks Pete and I said I'm a pilot, not a programmer. :) Until your clear explanation above, I assumed running multiple versions of simconnect was a bad idea. Life was simpler with FSUIPC.:)Bob..

[Luke 782]

>Life was simpler with FSUIPC.:)As a C# developer, life is simpler with FSUIPC as well.Cheers!Luke

[flying_w 58]

>>That figures because each SimConnect client program is>designed and compiled to work with a specific version of>SimConnect. FSUIPC is one of the exceptions in that, whilst it>needs the RTM version to get loaded, it then configures itself>to use the latest it can find.>Using some standard OO techniques in C#, it is possible to build a SimConnect application that automatically associates itself to whichever version of FSX/Simconnect you have installed. The SuperTrafficBoard product I'm developing will only require one SimConnect client to be installed, be it SP2/Acceleration, SP1 or RTM. If you have multiple installs, it will use the most up to date level.

[Guest ziporama]

MS delivers different manifests for each version of SimConnect (there are currently four I think - SimConnect RTM, SP1, SP2 and one for ESP 1.0.It is possible, but not easy, to write a single client that will dynamically associate itself with whatever version of SimConnect it finds installed on the client based on what version of FS (ESP) is detected. What is much more difficult is to detect what version of FS is serving Simconnect requests if the client is not running on the same machine running the simulator. The only thing required on the development end is to re-compile the code (minor variations in features) with a different dependency manifest, it shouldn't be that hard to distribute two or three versions. Still not ideal.There is much less of an issue for clients that work inside the FS process space as by definition, the version of the simulator can be detected, and the right SimConnect layer attached at runtime (that would be the simconnect.dll file). Going through the Simconnect manifests installed on the client doesn't work either because more than one version can exist in the side by side model.I appears possible to use mismatched versions, provided that you don't use a more recent client than the server unless you only need version information. Minimally, you can connect with any client to any server and receive the server's simconnect version, but not start adding definitions or receiving other data if versions are mismatched. SimConnect will generate a VERSION_MISTMATCHED exception, but not for all requests.For example, it looks like SP1 clients can connect to SP2 servers and have full functionality. It doesn't seem that an SP2 client can do anything with an SP1 server outside of getting the initial connection and obtaining the version information.What I run into is that once the DLL is in memory, there's no option but to display a message "mistmatched client/server" and get the user to quit. That's because you can't unload the DLL from memory until the host process quits.Cheers,Etienne