#1607 FOA: Game crashes when clicking statue part (Sentry Statue)

- 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

[Anonymous]

Savegame

[Torbjörn Andersson]

Logged In: YES
user_id=577918

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...

[Max Horn]

Logged In: YES
user_id=12935

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?

[Torbjörn Andersson]

Logged In: YES
user_id=577918

> 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.

[Max Horn]

Logged In: YES
user_id=12935

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...

[Max Horn]

Logged In: YES
user_id=12935

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.

[Torbjörn Andersson]

Logged In: YES
user_id=577918

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.

[Max Horn]

Logged In: YES
user_id=12935

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...

[Anonymous]

Logged In: YES
user_id=1021210

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.

[kirben]

Logged In: YES
user_id=34715

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.

[Max Horn]

Logged In: YES
user_id=12935

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.

[Max Horn]

Logged In: YES
user_id=12935

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.

[Max Horn]

Logged In: YES
user_id=12935

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).