from decker^
This is not exactly a high priority because it deals with compatibility between the actual IWD client and GemRB. First, loading any GemRB (IWD) save games causes IWD to crash (I only mention this because the same issue was mentioned somewhere for BG).
Now, if a game is created in the IWD game client, GemRB will load the game just fine. However, if that game is then saved and then loaded again, it fails and crashes.
I believe the problem has to do with the saving. Here are some resources to help explain show.
Here are some save game examples: http://tgull.php.cs.dixie.edu/gemrb/mpsave.7z
Here is a screenshot of GemRB loading a game saved in the actual IWD client:
http://tgull.php.cs.dixie.edu/gemrb/works.png
I then saved this game, and then tried to load it. Here is the screenshot:
http://tgull.php.cs.dixie.edu/gemrb/crashed.png
You can notice some other text printed out like the +---DECOMPRESSING--+ and what not. Still figuring out the client so those are just my own debugging output while I looked for where it was crashing.
It looks like it tries to save some file twice, (in this case it is ehpomab.sto) I have seen other files named, so I don't know if it's arbitrary or a specific order or what. But it writes out the compressed data size as 0. I believe this DWORD of 0 is also the end of the save file, so whatever is supposed to be written afterwards is cut out.
I posted this in #gemrb thought I would put it here too just in case. I don't know if this happens in other clients also, but I will check that out.
Thanks.
sorry new to sourceforge so I didn't know how to make those URLs into links, I assumed it would happen on it's own.
This is a real problem with gemrb (crash happens in gemrb), so i increased priority. My only idea at the moment is different capitals in filename, so the file goes twice in the cache.
IWD crashing on GemRB saves may be completely different and caused by many different reasons. One such cause could be a decompressed .tis file of an area (the original engine didn't like .tis decompressed without the other files of the area)
This is a windows problem. I remember this. The duplicated filenames in the compressed file are replacing default.tot/default.toh files. There is some problem about windows unable to open a file twice, i think. I thought it was already fixed, though.