FSXA FSX on Steam: Compatibility?

Heretic

Resource contributor
#81
Further notes:

- The filesizes for the default gauge .dlls are different to the ones in FSXA. Looks like Dovetail went all out on the recompilation.

- One thing that would be useful for FSXSE users is making a .bat file that replaces or deletes any (unwanted) default files (e.g. the default aircraft traffic .bgl or the broken SDK or...) after an update (as if that'll happen...).

- The "Verify Integrity Of Local Content" function in Steam is a nifty way of fixing broken or missing default files after an add-on-uninstaller has run amok and took its job a bit too seriously.*



*I've replaced the "AutogenDescriptions.spb" file with the minimal version right after the first installation and several content verifications since haven't replaced it so far. So it might just be that the function leaves altered files alone or overlooked this one.




This may have something to do with the STEAM overlay shell that runs in the background. Like I said before, STEAM presents a bit of an overhead. A loss of few fps is to be expected. The Steam overlay is accessible via Shift+TAB and with every steam game, it is heavily tweaked to provide full internal integration; depending on how heavily the integration was done, the game can report to STEAM "personal achievements" also, data is stored on the STEAM cloud, the amount of time you play the game and even save points if such things existed in FSX.

In windowed mode the shell overlay does not exist and the game doesn't have to deal with the overhead of having it run silently in the background.
The overlay can be turned off on a per-game or global basis. See each games' "Global" tab in its "Properties" menu in Steam.
 
Last edited:
#82
*I've replaced the "AutogenDescriptions.spb" file with the minimal version right after the first installation and several content verifications since haven't replaced it so far. So it might just be that the function leaves altered files alone or overlooked this one.
I'm hoping it would check presence of all files required, not their being replaced/modded. That would indeed be helpful with overly eager uninstalllers.
 

Heretic

Resource contributor
#83
I'm hoping it would check presence of all files required, not their being replaced/modded. That would indeed be helpful with overly eager uninstalllers.
It really seems to be presence only. Every content verification restores the damn default airplane traffic and has me wondering about why my framerate has suddenly taken an awful dip.
 
#84
Further notes:

- The filesizes for the default gauge .dlls are different to the ones in FSXA. Looks like Dovetail went all out on the recompilation.

- One thing that would be useful for FSXSE users is making a .bat file that replaces or deletes any (unwanted) default files (e.g. the default aircraft traffic .bgl or the broken SDK or...) after an update (as if that'll happen...).

- The "Verify Integrity Of Local Content" function in Steam is a nifty way of fixing broken or missing default files after an add-on-uninstaller has run amok and took its job a bit too seriously.*



*I've replaced the "AutogenDescriptions.spb" file with the minimal version right after the first installation and several content verifications since haven't replaced it so far. So it might just be that the function leaves altered files alone or overlooked this one.






The overlay can be turned off on a per-game or global basis. See each games' "Global" tab in its "Properties" menu in Steam.
Not all games are setup this way, for FSX it will reside in the General tab with an option to turn off the steam overlay. However, the steam client continues to run in the background to relay information back and forth between the game.

What people should be concerned about is the LOCAL FILES tab. When ever you mess with the internal directory structure of a steam game, it messes up the BuildID "the integrity of the directory and file structure" some games and add-ons modify FSX settings heavily and some run background services.....STEAM is very PICKY and in some cases, if your BUILDID does not match those of other people........STEAM will think you have reversed engineered the game and here we go again, VAC will get you (Valve Anti-Cheat) only time will tell how things will turn out.

I actually bought the game myself last night just to try it out, can't go wrong for that price! and my original FSX copy no longer works and Id rather not deal with the activation system which, the steam version has been stripped off.
 
Last edited:
#85
I just re-tested the frame rate in our ACG Wattisham scenery that we are just finishing off. In FSX_MS I get 55fps full screen mode, 33 fps in the same situation with the Steam Overlay running and 36 fps with it turned off. So yes the Steam Overlay does seems to eat a few fps, but it doesn't account for the much bigger drop overall.

John
 
#86
Has anyone found the compilers that are suppose to be in the SDK. It appears that BGLComp and Shp2vec are missing amoung others.
 
#87
There is something of a coincidence in FSX/SE in comparison to P3DV2.0?? I have just went thru my notes and tried a few aircraft that worked in P3DV1.4 and FSX Gold. When P3D went to V2.0 my notes indicate broken gauge codes related to no legacy. These aircraft at current work in P3DV2.4 and FSX Gold, however not in FSX/SE. When I looked at the PA Airbus with the FD panel and KBT L188 and P3 some of the Switch animations are broken as is AP functions, The Iris C27J also has some issue's minor related to the Light switch animations. I believe it was Father Bill who noted this crazy gauge and animation behavior in P3DV2.0. I just winder if Dovetail didn't do the same as Lockheed did lol. Should also note P3DV2.4 has no issue's with W8.1 and disconnecting controllers, but FSX/SE still suffer's from it. Wonder if a bird could sing a fix.
 

n4gix

Resource contributor
#88
Has anyone found the compilers that are suppose to be in the SDK. It appears that BGLComp and Shp2vec are missing amoung others.
I suspect that someone at Dovetail Games screwed up and accidentally left out some of the required .exe files. In any case, one can use the free Prepar3D v1.4 SDK to use instead. The files will be identical.
 
#89
Potential Heads Up.

I am running into difficulties with developing in a side-by-side situation with FSXA and SE on the same HD. I recompiled everything with SimConnect.lib from SE and adapted the installer code to handle the new config locations and that worked fine. In fact everything seemed good until I noticed that the recompiled code wouldn't load anything into the fuel and payload stations under FSXA. Works fine with Steam, same code, using the Steam SimConnect.lib in compilation and the 10.0.60627 client from Steam. It connects and appears to work for FSXA -- but some functionality appears broken internally. It reports S_OK (success) with the commands to load fuel and payload, but nothing in the aircraft actually changes.

Anyone else see anything like this? It may be something I have done wrong. I'm experimenting with various combinations of the library and client. But it looks like I might wind up having to have an separate executable for the Steam version, which I don't want to do.

I'll report more later when I figure more out.
Dutch
 
#90
After several hours of careful testing, I have reluctantly concluded that the SimConnect distributed with Steam is not backwards compatible with FSX Acceleration. At least, on my system it is not.

Programs compiled with the simconnect.lib from Steam will work with Steam, but at least two major problems pop up when they are used with FSXA.

1) This code is present in the SimConnect callback processing function:

switch(pData->dwID) {
case SIMCONNECT_RECV_ID_OPEN: {
OnRecvOpen((SIMCONNECT_RECV_OPEN*)pData);
break;
}

I can confirm that SIMCONNECT_RECV_ID_OPEN was never received.


2) SimConnect_SetDataOnSimObject(hSimConnect, LOADSTATION1, SIMCONNECT_OBJECT_ID_USER, 0, 0, sizeof(double), &Value);

Although this code returns S_OK, the value that is being set does not change.

There may be more but this is what I've found out so far.

Merely re-compiling with the simconnect.lib from FSXA (and the simconnect.h from FSXA, it's crucial those match, if they don't it won't work) make these work on FSXA but it will not connect to SE.

Compiling the same code with the simconnect.lib/simconnect.h from SE fails with FSXA but works perfectly with SE.

All tests were done with the SimConnect client from both FSXA and SE installed.

If there are some magic words to say that someone might know, please tell me!

Dutch
 
Last edited:
#92
After several hours of careful testing, I have reluctantly concluded that the SimConnect distributed with Steam is not backwards compatible with FSX Acceleration. At least, on my system it is not.

Merely re-compiling with the simconnect.lib from FSXA (and the simconnect.h from FSXA, it's crucial those match, if they don't it won't work) make these work on FSXA but it will not connect to SE.

Compiling the same code with the simconnect.lib/simconnect.h from SE fails with FSXA but works perfectly with SE.

All tests were done with the SimConnect client from both FSXA and SE installed.

If there are some magic words to say that someone might know, please tell me!

Dutch
You will note that the SE version is different from the FSX (original) and the public key is also. Also the SE version installs simconnect.dll in the GAC. (i don't think that was a good idea)

So you are going to have numerous Simconnect.dlls to deal with. P3D added the older versions to their system. FSX-SE did not.

FSX/A ver 10.0.61637
FSX-SE ver 10.0.62607
 

n4gix

Resource contributor
#93
So you are going to have numerous Simconnect.dlls to deal with. P3D added the older versions to their system. FSX-SE did not.

FSX/A ver 10.0.61637
FSX-SE ver 10.0.62607
FSX-SE also includes .msi installers for the three previous SimConnect versions in the
..\FSX\SDK\Core Utilities Kit\SimConnect SDK\LegacyInterfaces folder.

All one need do is, well... install them! :cool:

I have all of these now in the ..\winsxs folder:
Code:
FSX:RTM    10.0.60905
FSX:SP1    10.0.61355
FSX:A      10.0.61637
FSX:SE     10.0.62607
 
#94
FSX-SE also includes .msi installers for the three previous SimConnect versions in the
..\FSX\SDK\Core Utilities Kit\SimConnect SDK\LegacyInterfaces folder.

All one need do is, well... install them! :cool:

I have all of these now in the ..\winsxs folder:
Code:
FSX:RTM    10.0.60905
FSX:SP1    10.0.61355
FSX:A      10.0.61637
FSX:SE     10.0.62607
I just did that with the \FSX\SDK\Core Utilities Kit\SimConnect SDK\LegacyInterfaces folder. Lost functionality of the Default Airbus systems Ie the AP system.
 
#95
FSX-SE also includes .msi installers for the three previous SimConnect versions in the
..\FSX\SDK\Core Utilities Kit\SimConnect SDK\LegacyInterfaces folder.

All one need do is, well... install them! :cool:
Well going to zip it now. Giving bad advise.:tapedshut Thanks for the correction Bill.
 

n4gix

Resource contributor
#96
Not to worry too much, Ron! It actually took me a few days to even notice the ..\sdk folder, and another day (and a few hints) to discover that their ..\sdk folder is missing all of the required .exe files, as well as the entire ..\bin folder (so, no modeldef.xml file)...

Fortunately, the free Prepar3D v1.4 SDK is entirely compatible with the missing stuff! :wave:
 
#97
My previous report was my error, I'm glad to report. Somehow, I had compiled the test version with the 61242 version, which is FSX-SP2. It would not connect to FSX-SE. However when I recompiled with the 61259 version, it would connect to FSX-SE, and load payloads and everything seemingly correct.

So a binary compiled with 61259 simconnect.lib appears to be the sweet spot.

It still appears to be true that a version compiled with 62607 lib will not work properly with a 61259 or earlier server even if the 61259 dll is installed. No errors, just failure to operate properly. There's a more detailed post in the SimConnect forum from me about it.

Bill, I would add FSX-SP2 10.0.61242 to your list of SimConnect versions. The "Legacy Interfaces" folder inside FSX-SE also lists that as the FSX-SP1 revision in simconnect.h. I don't actually have SP1 around to compare.

My FSX/Acceleration SDK says 10.0.61259.0 as its rev as does the SimConnect.msi when I install it.

Dutch
 
Last edited:
#98
I am a little bit late, and maybe this is totally useless, but:

There is a file in the installation dir called FSXSEConfig.exe.

I clicked run, and tought it didn't do anything.

But in fact, it resetted the place of the config files from FSX-SE to FSX.

I only use FSX SE atm, so I don't know if this has any effect if you have the old one installed as well.
 

n4gix

Resource contributor
#99
Well, I'm delighted to report that my new installer(s) will now work for FSX:MS or FSX:SE (stand-alone) or FSX:SE (side-by-side) or Prepar3Dv1 using the HKEY_CURRENT_USER scenario... :wave:
 
FYI,

I am having trouble with the FSX:SE version putting the managed simconnect.dll in the GAC. I cannot create a managed VC++ CLI project pointing to the FSX (MS) version of the managed simconnect dll. It keeps overriding my selected version and using the GAC version. (I simply don't want to play this game. Yes I can remove FSX:SE, but what happens if I want to develop for FSX:SE also.)

I have read that you can add something to the app.config file or policy in your project, but can't get it to ignore the managed simconnect dll in the GAC.

Suggest any simconnect programmers out there check the managed simconnect version of their managed code.

Anyone help?

edit:

instead of hijacking this thread - I'll repost this question/info in the simcconect/ FSX:SE compatability thread
 
Last edited:
Top