In order to access to a separate VAS, a program must run as an external .EXE. Anything that runs in-process with FSX, which means any .DLL/.GAU file that are loaded either by DLL.XML or in the panel.cfg, will take away from FSX VAS space.

 

Maybe you are referring about the PMDG running its own internal system simulation in the background, but in order to do this without taking away memory from FSX, it would need to run as a separate .EXE file, which I don't think it's the case.

 

Some example of FSX add-ons that have their LOGIC running entirely outside the FSX are:

 

- Ultimate Traffic 2, because it generates AI traffic from the external UT2Services.exe program.

 

- Our own GSX, that runs all its code under the Couatl.exe program.

 

Note that, I've said the program's LOGIC is not taking any memory away from FSX, when it runs as an external .EXE. The graphic objects created by FSX when instructed to do so by such programs WILL, of course, take memory away from FSX, both because of their allocated space in RAM, but also (IN DX9) because the portion of the VRAM they use is also copied into system RAM.

 

To continue the example of the two add-ons above:

 

- When UT2 is making its own calculation to decide which AI it must create, by reading its database of schedules and locations, THIS processing doesn't take any memory from FSX, because it's happening in the VAS of the UT2Services.exe program. But every AI that is being created, will take some memory from FSX, just like if the same AI was created by the regular traffic engine.

 

- When GSX is calculating a path to move a vehicle from its starting location to the airplane door or it's calculating all the tricky mathematics needed to figure out a pushback route, THIS processing doesn't take any memory from FSX, because it's happening in the VAS of the Couatl.exe program. But the actual created vehicles will take some memory away from FSX.

 

To reply to the original question if the 32 bit memory limit can be somewhat "fixed", it can be, but only marginally, by moving everything that CAN be moved ( = code logic, systems simulations, etc.) outside the FSX process, under an external .EXE

 

The main issue is, although this IS a saving, and it also has additional benefits such being scheduled on free cores thanks to the automatic code allocation made by the OS without requiring any specific multi-core programming, it's not really much.

 

Code logic is not usually very large, not compared to GRAPHICS and, unfortunately, it's graphic that sells products which means, there's a strong drive for developers to push graphics further and further, which means whatever memory savings could be obtained by moving all code logic on external .EXE (which is the only option we have, as long as FSX remains a 32 bit app), I'm afraid they will always overshadowed by how easily memory gets used up with graphic, which CAN'T really be moved outside FSX.

 

Fully agree with Umberto.

 

Ultimately, as much as possible of the risky non-graphics stuff should be moved outside the simulator process.

 

That's why we designed our voice control program in a way that only a tiny dll runs inside the simulator process, mainly to give our FO knowledge of what's going on in the sim, and the heavy part (speech engine and audio dll) runs outside it, in its own 4 GB address space.

 

The FO audio dll file alone, never mind the speech engine, when mapped to the FSX VAS would reserve about 200 MB. Not actually physical RAM usage, but that's chunk of VAS other add-ons who don't have the luxury to decide where they run (aircraft, scenery, weather and AI), won't be able to access.

 

And trust me it's not just the VAS limitation. Should anything unusual happen, our process would eventually die (or be intentionally terminated), but crucially won't bring the whole simulator down.

 

I mean, what do you do for example when after a 1 hour flight, suddenly your FO gets stuck in some kind of loop, or the speech engine doesn't respond anymore? Restarting the flight would be your only option.

All we'd really need is some rich hero showing up and buying the rights of the FS engine and then releasing a 64bit executable for us.. :lol:

Thanks to all for your comments on this topic.  The conclusion appears to be a recompile of FSX core code to 64 bit along with the addon universe - no simple fix.

 

Thought I would ask the question - my assumption is that this limitation is a "niche" problem in the world of software gaming, but the responses here illuminate that the problem has been considered, but there is no easy solution - pending MS deciding to get back in the game and releasing an update (unlikely), someone buying the rights to FSX code (assuming that is different from what LM purchased with P3D and a business case can be made on the investment), or LM developing a 64 bit version that we can rent.

 

Scott R

 

 

Or make a 64bit sim and have 18446744073GB available

 

 

There already id a 64bit sim, it's called XPlane 10 64 bit. Trouble is that it is a catch 22 phase. A lot of people have FSX and a lot of addons that they are not keen on parting with, as such the addon makers are keen to keep producing stuff for it because it makes money . Without they addon makers giving it loads of support, people will not dump FSX , all there addons and move from FSX to XPlane. Especially after buying a $90 PMDG 777

 

There is a future with XPlane when FSX finally reaches the cliff but I think it is a way off yet.

There is a 64-bit sim, but there's nothing that appeals its usage as much as FSX right now. It'll be a long wait before XP covers that hole.

 

 

There is a 64-bit sim, but there's nothing that appeals its usage as much as FSX right now. It'll be a long wait before XP covers that hole.

 

Yes, I agree, even if I regret having to :-/

 

There is yet another excellent 64 bit simulator - DCS World - but limited for us civil flight sim users :-/

 

Given that LM P3D v2 is going to stay 32 bit and that probably the EULA limitations will not be relaxed... I believe it is a Long Lives FSX!!!