cbloopy wrote:dlcs18 wrote:If this fact helps, the dialog became broken in the first place when I placed some text into interchange 99 and saved the dialog.
Thanks, that helps a bit, although it still took over an hour of testing before I hunt down the real culprit. I think I understand the bug a little better now, but it's going to be hard to avoid. I'll let Patrick know right away as it is pretty bad.
Without going into details (since there's still quite a bit I don't quite understand yet myself), there is a count of something that's stored in the dialog file (it's the first byte in fact). When that count goes above 101, the AIOOB error occurs. I'm not sure what exactly it counts (could be number of interchanges, interchanges + answers, I don't know), but due to the bug, it isn't even counting correctly!
Here's the bug: right now, every time you save the dialog, the count is incremented by one
no matter what. So if you merely open a dialog and then immediately save it without actually making changes, the count still goes up by one. Here's a test I did:
1) create a new dialog, put some text for interchange 0, and then for answer 0 and answer 1. Save the dialog. Open the dialog file in a hex editor and see the value of the first byte. It's 02.
2) Now, create another dialog with the same content, except you save each time you add some text (so save after entering the text for interchange 0, then save again after answer 0, and again after answer 1). If you open the dialog file in a hex editor now, the value of the first byte is not 02, but 04!
3) Now the kicker: re-open the dialog from step #2 in WA Editor, and then save it again without actually changing anything. Open the dialog file in the hex editor again. The value of the first byte changes to 05! Even though you didn't make a single change in the dialog editor!
So basically, the more number of times you save the dialog, the worse the mis-count becomes, until it eventually goes above 102 and kill your dialog file with it. This also explains why Emerald141 didn't encounter the problem when he re-created the dialog--when he creates it again from sctatch a 2nd time, the number of times the file was saved would be a lot less than the 1st time.
Obvious this is very evil. Patrick needs to fix this serious issue.
In an absolute emergency, there is a way to recover the dialog file shall you hit this problem, but it'll be a little tedious and you'll need a hex editor:
1) make a backup copy of the "damaged" dialog file.
2) open up the dialog file in the hex editor, and look at the value of the first byte. It's probably 66 (which is 102 in decimal).
3) decrease the value of that byte by some sizable amount, say to 46 hex (which is 70). Save.
4) open up the dialog file in WA Editor. It should now load, but don't get happy just yet. Try saving it now and see what happens.
5) It may still crash. If that's the case, this means you need to decrease the byte by a larger amount. Repeat steps 2-4 again lowering the byte more (to say 36 hex or something).
6) If it doens't crash, then congratulations, you dialog's back. But you may lose a little of your work as a result. Open up the dialog again in WA Editor and see what gets discarded as a result (it'll cut off starting from the highest interchange, so start there).
If the amount lost is too much, you have the option to restore from the backup copy, and repeat steps 2-4 decreasing the first byte by a smaller amount, in hopes that you can lose less work while still avoiding the crash.
-------------
I'm going to try and see if Patrick can describe the format of the dialog file to me, so that maybe I can try to write a program that does a better job of doing the recovery described above.