It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
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
No posts in this topic were marked as the solution yet. If you can help, add your reply
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
avatar
ubipred: 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]
avatar
ubipred: 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?
avatar
SHODAN24601277: 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
The former is correct (saved games made using the original interpreter) will not work in ScummVM and vice versa.
But you CAN OF COURSE import characters from DosBox into ScummVM and vice versa.
You just need to put the file where ScummVM expects it, which is the saved game directory. And call it accordingly.

So you can export your character in QfG 3 and then import it in QfG 4 under ScummVM.
avatar
reddvii: 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?
QfG3+4 simply have way too much content.
If I remember correctly there was also some memory corruption script bug, which could cause all sorts of random issues. Several Sierra SCI games have issues like that, like scripts using vsriable where nothing was written beforehand and so on. It's all a mess.

Anyway these issues do not happen in ScummVM, because ScummVM uses a different memory model and also takes care of these uninitialized usages too, it also fixes countless of script bugs on-the-fly internally (you will not even get told that they were fixed) - MIND YOU though, GOG uses several fan patches, will cause their own issues.

You should look into these fan patches and REMOVE them if you consider using ScummVM to play these games, because these fan patches may cause issues under ScummVM. You just need to remove the fan patches from the game directory. Mind you: when you do this, your saved games under DosBox will stop working in case they were made while these script patches were active.
Post edited November 05, 2022 by m_kiewitz
avatar
SHODAN24601277: 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
avatar
m_kiewitz: The former is correct (saved games made using the original interpreter) will not work in ScummVM and vice versa.
But you CAN OF COURSE import characters from DosBox into ScummVM and vice versa.
You just need to put the file where ScummVM expects it, which is the saved game directory. And call it accordingly.

So you can export your character in QfG 3 and then import it in QfG 4 under ScummVM.
avatar
reddvii: 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?
avatar
m_kiewitz: QfG3+4 simply have way too much content.
If I remember correctly there was also some memory corruption script bug, which could cause all sorts of random issues. Several Sierra SCI games have issues like that, like scripts using vsriable where nothing was written beforehand and so on. It's all a mess.

Anyway these issues do not happen in ScummVM, because ScummVM uses a different memory model and also takes care of these uninitialized usages too, it also fixes countless of script bugs on-the-fly internally (you will not even get told that they were fixed) - MIND YOU though, GOG uses several fan patches, will cause their own issues.

You should look into these fan patches and REMOVE them if you consider using ScummVM to play these games, because these fan patches may cause issues under ScummVM. You just need to remove the fan patches from the game directory. Mind you: when you do this, your saved games under DosBox will stop working in case they were made while these script patches were active.
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.
Post edited November 16, 2022 by N7Kopper