Opened 15 years ago

Closed 15 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
Keywords: Cc:
Game: Indiana Jones 4


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

atlantis.s11 (18.5 KB ) - added by SF/*anonymous 15 years ago.

Download all attachments as: .zip

Change History (18)

by SF/*anonymous, 15 years ago

Attachment: atlantis.s11 added


comment:1 by eriktorbjorn, 15 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 eriktorbjorn, 15 years ago

Owner: set to eriktorbjorn
Resolution: fixed
Status: newclosed

comment:3 by fingolfin, 15 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 fingolfin, 15 years ago

Status: closednew

comment:5 by eriktorbjorn, 15 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 fingolfin, 15 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 fingolfin, 15 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 eriktorbjorn, 15 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 fingolfin, 15 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
[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 eriktorbjorn, 15 years ago

Owner: changed from eriktorbjorn to fingolfin

comment:11 by fingolfin, 15 years ago

Priority: normalhigh

comment:12 by (none), 15 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 Kirben, 15 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 fingolfin, 15 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
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 fingolfin, 15 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 fingolfin, 15 years ago

Status: newclosed

comment:17 by fingolfin, 15 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).

Note: See TracTickets for help on using tickets.