On Mon, 25 Jun 2001, Welcor wrote:
> The guildguard specproc, however, wasn't capable of handling the
> situation, and refused to let liches enter the guild (it returned
> prematurely). Here's a quick fix:
This isn't really a bug, but a new feature. Anyway, blah, blah, blah.
> + int i, found = FALSE, block = FALSE;
Don't need found. You can clean up the for loop without it (as well as
fix a bug in your code -- I'll hit on this in a second) like:
for (i = 0; guild_info[i][0] != -1; i++)
if (GET_ROOM_VNUM(IN_ROOM(ch)) == guild_info[i][1] &&
cmd == guild_info[i][2]) {
if (GET_CLASS(ch) != guild_info[i][0])
block = TRUE;
else
return (FALSE);
}
In your version, you stopped processing when you found a matching class
and room, but consider:
int guild_info[][3] = {
{CLASS_MAGIC_USER, 25000, SCMD_EAST },
{CLASS_CLERIC, 25000, SCMD_WEST },
{CLASS_THIEF, 25000, SCMD_NORTH},
{CLASS_WARRIOR, 25000, SCMD_SOUTH},
.
.
.
};
I.e., a single room with more than one exit to a guild-only area. Your
code only checked the room and the class before presuming that no block
should be done. Meaning that none of the guilds above are actually
blocked from people of other classes entering. (The loop is always exited
with block = FALSE and found = TRUE because there would be a class match
within that room and the direction is only tested if the class doesn't
match.)
-dak
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/05/01 PST