Hi there!
I have had some problems with Sam's OLC routines.
First one appears to be in act.build.c: do_rset case 4 (rset exit disconnect 2)
where there is no attention paid to the fact that the oposite exit back
from the other room sometimes doesn't lead you back to the room where
you attempted to disconnect the rooms. So I have fixed it as follows:
if(*arg4 == '2') {
if(get_zon_num(world[r_num].number) != ZONE_BUF(ch)) {
send_to_char("Can't disconnect outside of the zone.\r\n", ch);
return;
}
if (world[r_num].dir_option[revdir] &&
(world[r_num].dir_option[revdir]->to_room == ch->in_room))
/* ok to clear exit back */
world[r_num].dir_option[revdir]->to_room = NOWHERE;
else
send_to_char("Opposite dir from the room doesn't lead you here, t
hus saved it.\r\n", ch);
}
Another buggy code is to be found in act.build.c: add_reset_com() where
we count the reset commands to create another array. First, you
search for the cmd 'S' in zone_table[].cmd[].command and increase
the counter according to the reset commands found in the array.
Then you increase once more the counter (named commands) and
do CREATE(tcom, struct reset_com, commands); But there's where you
have mistaken because we have to consider the new reset command to
be added to the new array. So we have
CREATE(tcom, struct reset_com, commands+1); and no more crashes when
adding a new reset.
that's all that far.
I'm also having a hard time to find a bug in the add_zone routine.
the problem is that when you do zed create <zone number> it goes
fine 'til you don't want to edit the zone you just created.
It seems the problem is that the zone_table recreated in
add_zone() in act.build.c isn't pointed by the zone_table
variable later on. wierd? anyway, gonna debug some more :)
regards,
margus
ps. What about your next version of OLC, Sam? suppose you have already
noticed the bugs I described here?
pss. hope you bear with my english which is awful I guess :)
This archive was generated by hypermail 2b30 : 12/07/00 PST