I am in the endgame, and just before I can finish the game, I get the error message "Out of Heap Space" at which point the game just stops. Has anyone else encountered this problem? Can anyone help me fix it?

Thanks

Hey SHODAN24601277 :)

I am far from being the best person to answer you, as i’ve never even played QFG3.
However I found a similar problem reported on a different game.
It could be worth trying the suggested solution :)

https://steamcommunity.com/app/10110/discussions/0/618453594761991577/

You could probably tweak the DOSBox config, but it would be easier to just download ScummVM and play it in that.

If you would like to give it a try, I would suggest to always download softwares from their official website :)
https://www.scummvm.org/downloads/#release

Thanks for the suggestions. I have tried tweaking DOSBOX settings, hoping to somehow increase the heap. Nothing I have tried there has worked, and I am out of ideas for what to tweak.

As for Scumm, I'd have to start the game over again as there is no way to import my saved game. I've also heard there is no way to import the character exported from DOSBOX into a Scumm game, so that would mean restarting the series. If I have to do so, I have to do so, but after spending over a month in this game alone building up my character, I'm hoping to avoid that.

Oh wow, I was assuming the savegames were generated in their native formats. But you are right, they sadly aren’t compatible across emulators. :(

I’ve only found one more relevant result, and it isn’t a very good news:
https://advgamer.blogspot.com/2013/12/game-38-conquests-of-camelot-heap-of.html?m=1
(Make sure to lookup for ‘heap’ keyword within the page, since the page is pretty dense.


Basically, even backed by Corey Coles.
Since the problem seems to originates from the game engine itself, scummvm shouldn’t help in any way. Reloading from an earlier save seems to be the best way to go. That’s unfortunate :(

Quote:
[i]
Lars-Erik11 December 2013 at 07:17
Ooooh, time to geek out!

Conquests of Camelot use SCI0, the first version of SCI (although a late revision of it). This version have no support for either XMS or EMS, it can only use conventional memory, the first 640kB. Of this, DOSbox frees 632kB in a default installation.

Now to the "Out of Heap Space" from SCI. This doesn't refer to the usable conventional memory, but the internal SCI heap. This is allocated as a 64kB portion of memory, where all game objects are placed including their code (scripts). This heap size can not be changed in SCI. The problem with the way SCI allocates objects is that when a new object is loaded is has to find a contiguous portion of free memory in the heap for the object and its script. When an object is unloaded from the heap the heap isn't reorganized, so you can never defragment the free portions into one huge contiguous space. And if there isn't one big enough for the new object, "Out of Heap Space".

That's why restarting a game, or reloading an earlier save often helps. This way you take the shortest path to success, and SCI won't allocate space in the heap for objects you don't see instead of keeping the result of all of your attempts in a fragmented heap.

It's all a matter of the programmers trying to squeeze to much out of a limited engine I'm afraid, with not enough error handling. Bad news, Trickster. Either it's replay time or finding a save from somewhere else. You can have mine if you want, as I restarted the game due to missing the lodestone the first time.[/i]

This must be it!! This quote is brilliant. It offers an explanation as to why QFG3 crashes randomly after playing continuously for more than an hour. More importantly, it might explain the save rot bug in QFG4 that's responsible for corrupting save files to the point that they become unplayable. I'm curious as to why QFG1 EGA/VGA, and QFG2 don't suffer from crashes. Could the fragmentation issue only be present in the later two games?

Judging by my own personal playthroughs, the patches for QFG 3 and 4 now work with the latest version of ScummVM, as do the debug modes in 1VGA and 3 (which need separate script files to initialise)

Hell, even the EGA randomizer works in ScummVM now (and the effectively infinite heap means you can check your journal and checklist at any time), so there's no reason not to make the switch - aside from speedrunning. 2 VGA is still a little buggy though, I would recommend using the latest official AGDI engine for that.