Opened 20 years ago
Closed 20 years ago
#1607 closed defect (fixed)
FOA: Game crashes when clicking statue part (Sentry Statue)
| Reported by: | (none) | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | high | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Indiana Jones 4 |
Description
- ScummVM version 0.7.OCVS Built April 23 2004 21:5248 - Englisch - Talkie - Win 32
Game always crashes with "ERROR: (31:210:0xC51C): New name of 340 overflows name table (max = 100)" when looking at the chest plate and clicking the very left statue part.
Savegame attached
Ticket imported from: #941275. Ticket imported from: bugs/1607.
Attachments (1)
Change History (18)
by , 20 years ago
| Attachment: | atlantis.s11 added |
|---|
comment:1 by , 20 years ago
I've increased the size of that table to 150 (it used to be 50, then 100). Let's see if that's enough to get through the remaining part of the game...
comment:2 by , 20 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:3 by , 20 years ago
Ooops, not so fast here! Be ware, are you sure you are fixing the problem here, and aren't just curing the symptoms?
I am still wary that we may have a bug which causes us to accumulate object names, w/o clearing them out. In theory, loading a new scene should clear the whole object name table, though.
Did you verify in that room there are really more than 100 object name slots necessarily?
comment:4 by , 20 years ago
| Status: | closed → new |
|---|
comment:5 by , 20 years ago
> are you sure you are fixing the > problem here, and aren't just curing the symptoms?
Only to the extent that I looked at the _newNames[] array and saw that it was filled with unique numbers between 143 and 1207. I don't know how to verify it, other than playing through the entire game and make a note about every new object name.
I wasn't aware of the clearing of the object name table though, so I added some quick debug messages to killScriptsAndResources(), which I assume is what you refered to. None of the names were cleared when I left the room. A few of them had 1 as their owner (Indy himself, perhaps?), one of them had 7 as its owner (Sophia?). The rest had 15 as their owner. I don't know what that means.
comment:6 by , 20 years ago
Yes I was refering to killScriptsAndResources().
It only will delete the object name if the owner is 0. But maybe it should also check for OF_OWNER_ROOM ...
The fact that _newNames is filled with unique numbers says little; more interesting is whether the object IDs it is filled with are for objects which are actually still in use...
comment:7 by , 20 years ago
I just saw your comment in the logs, erik :-). Owner 15 is exactly the OF_OWNER_ROOM I was talking about - i.e. it marks an object which isn't actually "owned" by any actor. Any object name for such an object should probably be cleared when the corresponding room is left.
comment:8 by , 20 years ago
I'm not familiar enough with this part of the code to know for sure how to figure out what objects the numbers correspond to. (I thought I managed it for MI2, but I can't remember how I did it. :-)
By the way, I wonder how the names of the rooms on the maze overviews are handled. Before you've entered the room, its mouse-over text is just a question mark, as I recall it. Afterwards, it's the name of the room. I wonder if that's done by object naming or some other mechanism and, if the former, what the owner of those objects are.
comment:9 by , 20 years ago
The maze is probably done via bitflags; shouldn't be hard to figure out by looking at the script dumps, though (just dump the scripts, descumm them, then search for the mouse over texts).
Anyway, the whole thing sounds to me as if killScriptsAndResources() should be changed to also remove object names for objects owned by OF_OWNER_ROOM... [trying that] This fixed the object name table overflow. However, it also caused this problem: Put the left most machine part on one of the pegs; the name of the peg will change to "mouth". Now leave the view (=room), and immediately return to it. The name has reverted back to "peg" which is wrong. Grmbl...
comment:10 by , 20 years ago
| Owner: | changed from to |
|---|
comment:11 by , 20 years ago
| Priority: | normal → high |
|---|
comment:12 by , 20 years ago
I don't know if the problem is fixed by now, whether you've just cured the symptoms, or whether this information is any helpful to you at all - anyway, I have finished the game in team, wit and action mode now without any further problems.
comment:13 by , 20 years ago
The original FOA and MI2 don't seem to use _newNames at all, as far as I can tell. Your idea of clearing object names for objects owned by OF_OWNER_ROOM (0xF) in killScriptsAndResources() is correct but only for scumm6.
comment:14 by , 20 years ago
Yup, of course MI2 and FOA do not use _newNames - we only changed this recently on the trunk. Which is the cause for this regression, of course. We are simply doing things differently than the original did internally. Hence it's not that useful to check the original code.
comment:15 by , 20 years ago
So, I still think we should clean the object names for OF_OWNER_ROOM objects... As I mentioend there is a problem with this, which is visible here: the "mouth" custom name for the pegs inside the body of the sentry statue is forgotten this way when you leave the room. My suspicion was that the very same would happen with the old code if you save and then reload. I just tried with bootparam 9901 in ScummVM 0.5.1 and found my theory confirmed. This is not a surprise: the old code did what the original engine did, that is, modify the object resource directly. the object resource in turn is part of the room resource... and when you save, quit, restart, load, then all of those will be unloaded, except for the one you are in right now. Hence the object name vanishes.
Of course since saving/loading is far less frequent than changing rooms, the problem is less noticable this way; but it is still there, and I'd tend to call this a bug in the original script. So we might just work around it with a custom hack. If any other spots feature similar problems with renamed objects, I'll be happy to treat those with yet another custom hack, too.
comment:16 by , 20 years ago
| Status: | new → closed |
|---|
comment:17 by , 20 years ago
I did as I said in CVS. Works like a charm so far, and with the custom save game, the object name count drops from 96/101 down to 10/15.
One last thought: Of course one could simply revert to our old code and *not* check for OF_OWNER_ROOM. Instead, we keep increasing the number of object name slots until we get no bug reports anymore. That way, we'd automatically retain all custom names for all objects without having to worry about dedicated work arounds in our code. Pro: All object names automatically stick, forever Con: There could hypothetically be thousands of them Con: Some of the old games may actually have the opposite bug: that is, they may rely on the object name being reset at some point (e.g. because a room gets unloaded). Though I somehow doubt that (but I can't be sure, obviously).
Savegame