MM4-5 savefile

[bbcjoke]

Greetings,

So I was playing World of Xeen (DOS Version) on ScummVM - great project btw, congratulations - and came up with a weird bug on the game. On Darkside, Sandcaster, an enemy wizard spawned inside the city wall, preventing me from killing him and finishing the main city quest.

Now I decided the best way to fix this would be to hack the savefile part containing the party location, change it to this exact monster location, kill it and return to the playable part of the map by casting the Time DIstortion spell. I know for a fact that the DARKXX.SAV file 0x003788 and 0x003789 contain respectively the X and Y location of the party (I've done this before on DOSBOX, so it works).

And to my surprise, the Xeen engine on ScummVM does not create/use the original game savefiles, but rather creates its own file structure (likely for compatibility between machines), which I don't know enough about to hack. So I bring these questions below, most likely adressed to dreammaster, the developer of the Xeen engine:

1) Can you tell me the memory addresses where the X and Y party location are stored in the worldofxeen.000 savefile? Are they stored in the same way (one after the other, exact same numbers as the original savefile)?

2) Is there any way to force the game to use the original game savefiles (save/load)? I've tried adding the "originalsaveload=true" line to the Xeen part of the scummvm.ini, but I got no results (ScummVM keeps rewriting the file and removing the line).

Thanks!

[Raziel]

On Darkside, Sandcaster, an enemy wizard spawned inside the city wall, preventing me from killing him and finishing the main city quest.

I take it that shouldn't happen?
So, it's a bug in the game scripts or in ScummVM (probably in the game scripts, since you also experienced this under DosBox..)

I wonder why this hasn't been fixed back in the original engine (does it occur there too?), since it sounds to me as a game breaker.
Or is that just a hacky shortcut cirvumventing the original game's path (saving time)?

[bbcjoke]

Ok, let me clarify this.

I did not experience this bug on DOSBOX, only on ScummVM. What I meant is that I managed to create a new game on DOSBOX and placed my initial party on the spot the monster got stuck in my ScummVM game (yes, the wall is empty there).

The place in question is Sandcaster X=13 Y=4. I know for a fact (by playing around) that Sandcaster X=12 Y=3 is also an empty inner wll. You can even break the wall from the inside (but not from the outside) and get out of there, so I don't discard this being an issue on the original game (sounds like a place to hide monsters until the player steps on a certain spot).

[Raziel]

Ok, let me clarify this.

I did not experience this bug on DOSBOX, only on ScummVM. What I meant is that I managed to create a new game on DOSBOX and placed my initial party on the spot the monster got stuck in my ScummVM game (yes, the wall is empty there).

The place in question is Sandcaster X=13 Y=4. I know for a fact (by playing around) that Sandcaster X=12 Y=3 is also an empty inner wll. You can even break the wall from the inside (but not from the outside) and get out of there, so I don't discard this being an issue on the original game (sounds like a place to hide monsters until the player steps on a certain spot).

Ah, ok, but then it sounds like a genuine bug in ScummVM's Xeen engine and should get fixed

[dreammaster]

One solution to your problem is to use the ScummVM debugger. If you press Ctrl-Alt-D, it will open the debugger. Then type in the command 'intangible on' to turn on intangibility. Then press Escape, and you can walk through the walls. Just repeat the process with intangible off to turn it off again afterwards.

[bbcjoke]

One solution to your problem is to use the ScummVM debugger. If you press Ctrl-Alt-D, it will open the debugger. Then type in the command 'intangible on' to turn on intangibility. Then press Escape, and you can walk through the walls. Just repeat the process with intangible off to turn it off again afterwards.

That's a great solution! Solved my problem! Thanks!

[bbcjoke]

On a second note, I still would like to know if there is any way to generate the original savefiles for the game. Maybe with the ScummVM debugger? Or is there a reason it was not implemented?

[dreammaster]

There's no way currently. It was just never a priority to add support for loading original saves. Or creating them for that matter. Xeen in particular took a long time to finish adding support for, so by the end of it I was more than relieved to move onto other things. Of course, if anyone else decides to work on it further, I have no objection to them adding such functionality.

[bbcjoke]

It's a pity, but I understand. Thanks for the hard work on adapting the game in any case!

[bbcjoke]

Let me ask one more last thing... If there is a specific statistic of one character in my party I want to change, is there a way to do so through the debugger? I did not find that option there.

[dreammaster]

Let me ask one more last thing... If there is a specific statistic of one character in my party I want to change, is there a way to do so through the debugger? I did not find that option there.

Not really. In the rare cases I needed to change a single stat to a specific value, I just used the Visual Studio debugger to manually change the specific stat in question. Otherwise, there are two general commands I used for testing.. invincible, which make the party immune to attacks, and strength, which makes attacks super strong.

[bbcjoke]

Ok, it seems you were changing the value directly in memory.

I'm trying to mess with the savefile, but it seems that everytime I make a new save, the data gets all shuffled. Only some kind of header is kept. I've attached a picture of an hexeditor comparing two savefiles (worldofxeen.00 and worldofxeen.002) taken within a second from each other, with no in-game difference whatsoever.

Do you know if there is some kind of encrytion going on for the savefile?

[dreammaster]

Save files in ScummVM are automatically gzipped to save space, unless the given engine specifically tells the framework not to. So that's why the files keep changing. It's been a whie, but if you really want to, I think you can rename the file to .gz, and then use a tool to uncompress it. Then change the file accordingly, and then re-encode it accordingly.

[bbcjoke]

Save files in ScummVM are automatically gzipped to save space, unless the given engine specifically tells the framework not to. So that's why the files keep changing. It's been a whie, but if you really want to, I think you can rename the file to .gz, and then use a tool to uncompress it. Then change the file accordingly, and then re-encode it accordingly.

Yes! That was what I was missing! Thanks a lot, I was able to find the parameter I wanted to modify!