search

rezalas / riftshadow

Dedicated to the preservation of the game and modernization of a classic mud codebase.
MIT License
18 stars 14 forks source link

Unknown vnums reported at startup #129

Closed sean-gilliam closed 3 years ago

sean-gilliam commented 3 years ago

When riftshadow first starts, 3 bugs are reported related to unknown vnums.

... :: [*****] BUG: Read_object: vnum 16161 bad type.
... :: [*****] BUG: Read_object: vnum 16159 bad type.
... :: [*****] BUG: Read_object: vnum 16162 bad type.

These vnums look to be part of this file https://github.com/rezalas/riftshadow/blob/65e9aa4e0f4273a08c80729d9f682659bf28e3de/area/valleydra.are#L703-L739

The common vnum among them is ITEM_NOLOCATE. It appears that the vnum is unhandled in the switch table here https://github.com/rezalas/riftshadow/blob/65e9aa4e0f4273a08c80729d9f682659bf28e3de/code/db.c#L2239-L2326

rezalas commented 3 years ago

NoLocate is designed to prevent scrying detection, so I'm surprised to see it not supported but used. This zone was likely incomplete, so the creator (Steve) likely didn't know about the absence of support.

rezalas commented 3 years ago

I'll see if I can track down the code for scrying and determine what was used previously and either remove the references or provide support!

sean-gilliam commented 3 years ago

Cool beans. Just something that was nagging me every time I start riftshadow.

rezalas commented 3 years ago

In my searches I'm finding a ton of ITEM NOLOCATE entries, but only these three items throw this error. I'm trying to dig in to figure out why.

rezalas commented 3 years ago

Something is wrong with just these items, as nearly all the areas use NOLOCATE it seems. I found that no locate is used directly in the scrying spell vs in the processing engine, so somewhere it's being transformed and I haven't found where yet.

sean-gilliam commented 3 years ago

So I ran it through the debugger and whenever it hits that switch table with obj->item_type == 43 then it produces the bug. Looking through merc.h shows us that ITEM_STONE = 43. That makes sense since the 4th line of each of those vnums is stone.

If we put a handler for ITEM_STONE in the switch table, it should solve the problem.

rezalas commented 3 years ago

Issue closed by PR #132