Cool, thanks for the new outlook on how to dit it. I was thinking
from the players point of view. So, perform the check in perform_move,
do some damage and then send a message to the players and room once
they are in the new room? I do not want a death trap effect, for
example, I have a zone where I have a room where I want the floor to
fall thru if a certain weight is present in the room. (Or simply more
than 2 PC's) I simply want to transfer the players to the room below,
do maybe 1-10 points of falling damage and then update the PC's and send
some nifty messages.
Thanks for the insight,
Chuck
Daniel Koepke wrote:
>
> On Fri, 22 May 1998, Chuck Carson wrote:
>
> ->of him has a spec_proc assigned and is room flagged
> ->ROOM_HASTRAP, how could I lookup what spec_proc the
> ->room has assigned and how would I execute it (as well
> ->as pass arguments to it)?
>
> Although it's not politcally correct to do so, any longer, I'm going
> to say, "RTFC." I took a look into the room_data structure, and
> lo-and-behold, there is a SPECIAL(*func) -- a pointer to a the special
> procedure function! We could then do,
>
> /* we want to do the check to the room the person is going to? */
> if (ROOM_FLAGGED(EXIT(ch, dir)->to_room, ROOM_HASTRAP)) {
> int spec_room = EXIT(ch, dir)->to_room;
> if (GET_ROOM_SPEC(spec_room) != NULL)
> (GET_ROOM_SPEC(spec_room) (ch, world+spec_room, 0, 0));
> }
>
> If we want to check _what_ the spec-proc is, that is easily
> accomplished by,
>
> SPECIAL(my_trap_fun);
>
> if (GET_ROOM_SPEC(spec_room) == my_trap_fun) {
> }
>
> But, is it _really_ necessary to do this _here_? I don't think so.
> Room special procedures are called on commands -- including movement,
> so you don't gain anything from all this code except a more direct
> path to the room with the special procedure.
>
> SPECIAL(move_trap)
> {
> /* trap on the north exit */
> if (!CMD_IS("north"))
> return FALSE;
>
> /* perform the movement */
> perform_move(ch, cmd - 1, 0);
>
> /* ehh -- it'd be bad if the player just moved into a DT ... */
> send_to_char("Ahh! A trap ...\r\n", ch);
> act("$n just got snagged by a trap!", FALSE, ch, 0, 0, TO_ROOM);
> .
> .
> .
> return TRUE;
> }
>
> This trap works as one on a doorway, so going through the exit results
> in the trap being set off. The person makes it to the otherside of
> the doorway, but the trap is set off in the process of going through
> the door and they suffer whatever ill-effects you had planned for the
> trap. Note that you don't need a ROOM_ flag for this at all.
>
> The only limitation I can see right now is that exiting from the room
> through the trapped door will set off the trap, but not entering
> through that door.
>
> But, I wouldn't really do this with spec-procs. It seems like it'd be
> much easier and make much more sense to just have types of traps that
> you can set in rooms. It'd take a few new variables. The upside,
> however, is that you can allow players to set and disarm traps
> wherever they wish, and implementing new trap types (especially ones
> that just damage the victim and give a spiffy message) can be made an
> online job for the builders. Maybe a few days worth of hacking away.
>
> -dak
>
> +------------------------------------------------------------+
> | Ensure that you have read the CircleMUD Mailing List FAQ: |
> | http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
> +------------------------------------------------------------+
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST