ToME: the Tales of Maj'Eyal

Hello Fellow TOMErs

I recently got into this game and I have been running into relatively frequent crashes that are corrupting my saves. Most recently my game crashed when entering Derth for the first time. I entered the zone and the loading progress bar got to 100% and then just stayed there until the game eventually crashed.

I am on Windows 11 with an i9 and a 4070. I am playing the game on 1920x1080 Windowed. I am using the Steam version, unsure of the exact version at the moment. I have all the shaders turned off. My drivers are up to date. My Steam overlay is disabled.

From the te4_log.txt the game appears to start trying to save but then gets in a loop and eventually crashed

This is where the save starts Then after about 2,000 lines of those messages repeating the log terminates in the following. Yes, it was cut off mid-line by the looks of it
I checked the Windows event viewer and saw the following. From my understanding this is a crash from Heap corruption.
After the crash the save is unable to be continued. The save file is replaced with the temporary, game.teag.tmp. Dropping the .tmp extension does not work for forcing the game to load, though I have not tried it on this exact save asI wanted to preserve the logs for reporting.

Does anyone else encounter this crash on Windows 11? Are others playing on Windows 11 or are you on a different OS?

I have a workaround to backup my local saves but sometimes I forget and will lose more progress can my little old heart can bear.

Welcome to the forums, Tesserekt.

If you've not already done so, take a look at the Help! My Saves keep not working thread - there are several options offered there which might help with your situation here.

Thanks. I had browsed through that thread before. I had tried to drop the tmp from my broken save and thinking back I did see some lua errors when that file failed to load. Perhaps that save could be fixed but I was playing on Roguelike and not that concerned about fixing the save file.

I am more interested in figuring out why the game keeps crashing on my machine. My latest theory is that it is being caused by running on a laptop with 2 GPUs and the default setting for TOME was to "Let Windows decide" which GPU to use. I experienced some odd graphical behavior when selecting "New Game" which seemed GPU related. The game would be in fullscreen, I press New Game, then the game loses focus and then goes full screen again, sometimes several times. I have since specified for TOME to only use the high powered GPU but I have not gotten around to testing it yet because . . .

I have another computer which is a tower (only 1 GPU) that is still on Windows 10. I managed to play quite a bit on that machine without crashing or experiencing any graphical oddities. I am unsure if the crashes I am encountering are Windows 11 or dual-GPU laptop issues. For now I can play the game on my tower but I would love to know if upgrading to Windows 11 would cause the game to crash on my tower as well.

Given the log files above show issues occurring with game saves, experimenting with the save options available (disabling background saves and disabling online functions) might be worth doing. Also look out for anything running on your system that might be accessing savegame files (e.g. anti-virus scanners, cloud synchronisation tools) - the linked thread mentions using Process Monitor to check for this.

In terms of graphics, TOME is pretty undemanding (I've run it on a 2011 laptop with an ATI Radeon Xpress 200M GPU) so you should be able to use either GPU on your system.

The root cause of this is rather mundane. There is a flaw in the logic of the save process that if the rename of the temp save `game.teag.tmp` to `game.teag` in the C code it is just treated as if it succeeded. It then reports back to the LUA code that the save worked. The LUA code will then attempt to validate the new `game.teag` (which does not exist because the rename failed) which will fail validation triggering another save attempt. This happens infinitely until you get that yellow dotted line crossing your screen and the game crashes, likely corrupting your save because it was trying to save a new `game.teag.tmp` failing in process.

I have a LUA patch which prevents the crash and save corruption. When checking the validity of the save file if the `game.teag` is not present it will validate if `game.teag.tmp` is there and consider that good enough. Subsequent saves all still fail to rename but a new `game.teag.tmp` is cut each time. Your progress is continually saved to the `game.teag.tmp`. The minor issue (albeit better than corrupting your save) is that after exiting the game you still only have `game.teag.tmp` so you cannot load back into it yet through the games menu. You need to manually drop the `.tmp` extension (in effect doing the rename the engine failed to do) and the voila you can load your save.

I am currently putting off actually fixing this because I just do not want to install Visual Studio or C build tools on my leisure machine. The fix could be done in many ways and I have not decided on the best approach so instead I will layout the issue. In `serial.c` the function `finish_zip` handles the deletion, save and rename. This is where the flaw lives. There is 0 error handling and 0 examining of the results of any of the actions taken. Meaning that if they fail the engine does not care and just chugs along erroneously reporting to the LUA that it worked. The very first step is to delete your save file which usually works. Then it attempts to rename the file which some times fails (at least on Windows 11 currently) then it tells the the LUA code where it can find the now-deleted, never replaced `game.teag`. This function needs to be fault tolerant and at least know when it failed so it doesn't trigger an upstream infinite loop.

Why does the rename fail? I do not know because the engine doesn't even know that it happened and reports nothing back. It is possible this is some Windows 11 quirk but it can be coded against defenisvely so it doesn't hang the engine and corrupt your save.

The rename fails because Windows says `game.teag.tmp` is open in Tales of MajEyal. When the game is unable to rename the file I was also unable to rename the file manually. Closing the game allowed me to rename the file.

tesserekt wrote: ↑Sat Jan 10, 2026 2:40 pm ...Your progress is continually saved to the `game.teag.tmp`. The minor issue (albeit better than corrupting your save) is that after exiting the game you still only have `game.teag.tmp` so you cannot load back into it yet through the games menu...

Thanks for the update and analysis.

In my experience, the savegame (.tmp or .teag) is only updated when you save a game. I do however have online functionality disabled - enabling this results in TOME regularly updating your online profile and it could be updating the save game also at that point. If so, disabling online functionality is worth trying as a workaround (and noted in the other thread mentioned).

If the file rename is failing on your system, it could be due to intervention by another process (anti-virus, indexer, online storage agent, etc) - Process Monitor would be your best bet to identify the culprit (more details in the other thread).

In terms of coding changes, Dark God has not been active on these forums since July last year (hope he/she/it is OK...) so necessary alterations may need to be considered by one of the active modders.

I have ruled out the online features, part of my testing was done using the download from the forum and I did not sign in. I do not think there is any other process interfering with the save file. My AV is disabled and I am not syncing the files anywhere. In fact my first short term fix for the probem was to back up the files locally. Any process that wants to copy those files elsewhere can do that at will. The thing that nothing can do is rename or delete the file because it is still open in TOME.

There are correct ways of handling files in C for Windows that would allow you to rename an open file but as far as I can tell that is not being done here. There are specific sharing rules that will allow certain actions for a file when you open it. I have not investigated closely enough to know if that is in the games code or a library it is using (PhysFs).

I am fairly certain this is an issue with TOME. I have a hard time believing that Windows is non-deterministicly leaving file handles open for only the lifespan of the TOME process.

What seems more likely to me is that there is some file handle leak happening where the handle for the temp file is not properly disposed of and lives on in the process memory indefinitely. That could also affect the game running on Linux but you would never notice because Linux lets you rename open files by default without needing special handling. The memory not being properly disposed of could be Windows 11s fault but I have no evidence of that.

This could potentially be fixed by updating the platform specific (Windows) C code that handles the file to allow renaming an open file but that just masks the problem instead of fixing it. Determining if there is a file handle leak would be the next course of action. Hopefully I will have more time to dedicate to this in the near future.

I've let DG know about this issue and analysis, thank you.

I am sharing my workaround in the event it can help someone in the near-term. This prevents the game from immediately crashing when you have an issue with save files on Windows. When this code works you will need to find your save file and rename it manually from game.teag.tmp to game.teag. No guarantee this fixes your issues.

You need 7zip to do this unless you know more about compression and can re-compress an archive exactly how the game expects.

• Find your game engine file, in a folder like this. ex. Steam\steamapps\common\TalesMajEyal\game\engines

• Inside that directory should be a file with a name like te4-1.7.6.teae

• That is a secret zip file. Rename it to te4-1.7.6.teae.zip.

• Open the zip with 7zip. No do not extract or decompress

• Find the file at engine/Savefile.lua right click and Edit within 7zip

• Update the Savefile.lua as follows
  Optional, add this log before the first function so you can verify your changes are in effect. That will show up in the games log at the root directory of the game, te4_log.txt

  Code: Select all

  print("[SAVEFILE DEBUG] Using OVERRIDDEN Savefile.lua")

  Find the function checkValidity and update it to match this
  

  Code: Select all

  --- Checks validity of a kind
  -- @string type "Entity" | "World" | "Level" | "Zone"
  -- @param object the object to check
  -- @return true if valid
  function _M:checkValidity(type, object)
  
  	print("[SAVEFILE DEBUG] checking", type)
  	print("[SAVEFILE DEBUG] final exists:",
  	    fs.exists(self.save_dir .. self['nameSave'..type:lower():capitalize()](self, object)))
  	print("[SAVEFILE DEBUG] tmp exists:",
  	    fs.exists(self.save_dir .. self['nameSave'..type:lower():capitalize()](self, object) .. ".tmp"))
  
      local base = self.save_dir ..
          self['nameSave'..type:lower():capitalize()](self, object)
  
      local path = fs.getRealPath(base)
  
      -- Windows: final file may not exist yet, but tmp does
      if not path or path == "" then
          local tmp = base .. ".tmp"
          local tmp_path = fs.getRealPath(tmp)
          if tmp_path then
              print("[SAVEFILE] checked validity of type", type, "=> tmp accepted")
              path = tmp_path
          end
      end
      
  	if not path or path == "" then
  		print("[SAVEFILE] checked validity of type", type, " => path not found")
  		print("[SAVEFILE] path info", self.save_dir..self['nameSave'..type:lower():capitalize()](self, object), "=>", path)
  		return false
  	end
  	fs.mount(path, self.load_dir)
  	local ok = false
  	local f = fs.open(self.load_dir.."main", "r")
  	if f then ok = true f:close() end
  	fs.umount(path)
  	print("[SAVEFILE] checked validity of type", type, " => ", ok and "all fine" or "main not found")
  	return ok
  end

  When the game attempts to save but fails this code will prevent an infinite loop. It will notice you only have a tmp save and no permanent save, tell you "tmp accepted" and then act like the save worked as expected

• Save the file, 7zip will offer to update the file in the archive, say yes.

• Rename file to drop the zip extension and you are done

The way this works is when the save fails it will just write your new save to game.teag.tmp and treat that as your permanent save. These tmp saves are not detected by the game when loading so you need to rename it to game.teag after you exit to be able to load it next time.