markdf

I'd certainly be interested in at least a potential conversation about it at some point - I'm a recently retired C/C++ dev (I'm assuming that's what it's been built in - if it's VB I'd unfortunately be lost). I spent most of my career in embedded systems development, but the last few before stopping working professionally involved Lua as a Train Simulator addon developer, even if nothing comes of it, it would be a shame if bug-fixing/maintenance ceased for such a useful tool. Obviously the important thing is this though: At the end of the day it's your code, and your decision what happens - and I respect that above all else.

Thanks for the many years of support. Is there any scope for another developer picking up the maintenance in the future?

It is entirely possible that by purely recompiling with the /LARGEADDRESSAWARE flag, that they can grant FSX access to more memory on 64bit OSs, even though the code is still 32bit which would vastly reduce OoM errors. Typically this can grant an increase from the default 2gb to 4gb, and in itself would be a worthwhile change - and if they haven't done so already, I'd be very surprised if it didn't follow as an early update. http://msdn.microsoft.com/en-us/library/windows/desktop/bb613473(v=vs.85).aspx states: A similar technique has been used (by reverse engineering/3rd party patches) to patch games such as Fallout 3 which also suffer out of memory issues from large collections of add ons, and has worked very effectively there to improve stability with large amounts of add ons loaded.