Increase MAXUNDO for hugo

[GoogleCodeExporter]

A report on the mailing list indicated that in some situations the undo buffer 
in the Hugo interpreter is not large enough to provide a single undo.

This is controlled by the MAXUNDO parameter in the Hugo source code, so it's 
easy enough to change. However, the source code says: "We can only restore undo 
data if it was saved by a port with the same MAXUNDO as us."

I assume this just means that undo information in save files will be discarded 
and lost, rather than that the save files will become invalidated. However, 
that should be tested, and in any case this behavior should be documented in 
the release notes.

Original issue reported on code.google.com by bcressey@gmail.com on 30 Dec 2012 at 10:17

[GoogleCodeExporter]

If you play the recording and UNDO twice (the first UNDO undoes the RECORD OFF, 
for whatever reason), you can see where it has run out of memory (of course, it 
does the same thing if you play through the game manually).

Original comment by jonny.sh...@gmail.com on 30 Dec 2012 at 10:53

Attachments:

• cb2.hex
• cb2.txt

[GoogleCodeExporter]

Perfect, thanks for the test case!

Original comment by bcressey@gmail.com on 30 Dec 2012 at 10:57

[GoogleCodeExporter]

The two-UNDO thing was bothering me so I tracked down the problem with that 
(Hugo wasn't properly understanding "RECORD OFF" as a non-turn-taking xverb) 
and came up with a fix for it. Anyhow, here's a version of the game that 
doesn't do that.

Original comment by jonny.sh...@gmail.com on 3 Jan 2013 at 10:21

Attachments:

• cb2.hex

[GoogleCodeExporter]

Recently, I found the bad game code that was eating up UNDO memory (it 
eventually started affecting the regular Hugo terps' behavior, too). Now that 
it's fixed, the current version of the above game has a more lenient number of 
available UNDO slots at that particular point. This issue can be closed.

Original comment by jonny.sh...@gmail.com on 28 Mar 2013 at 5:05