What codebase? Since you're referring to spec_funs I'll guess SMAUG or something similar. If you're attempting to force players to wait while the mob performs actions, consider creating a function that makes use of WAIT_STATE. I believe there's even an mpdelay command they can use via progs that does exactly this.
If you're wanting to prevent people from moving out of the room entirely while the mob is there, consider adding a new ACT flag like 'blocker' and create an ifcheck in the move_char function that checks for mobs in the current room of the player that has this, send them a message and return prematurely.
Hope that helps! If you still can't figure it out, please elaborate more on what you're trying to do and we'll see what we can do.
check out the godwars codebase, there is a vampire skill called bloodwall I think that can show you how to do this. I'm sure there are other codes that have similar skills too but I don't know which ones off hand.
You wouldn't do this with a spec_func. You would do this by intercepting the movement attempts and stopping them. spec_funcs are things that the mob does every once in a while, like an AI routine if you will.
EDIT: That said, I wouldn't do this with a mobprog either. I would have the move functions test for presence of one of these wall things. If you don't like testing the character list on every move, you can instead set flags and so forth, but then you have to be extremely careful that the flags are always removed when appropriate lest you end up with blocked exits with no walls present.
I think you're confused with what a spec_func actually is ;). Just take a look how they're called. It's in update.c. spec_func's are not triggered, they are executed every time a mobile is updated. You need something that is triggered (an event is raised, caught, and reacted to). People suggesting mprogs is one way to go about this, simply because of the fact they're triggered on an event. These are currently the -only- things that are trigger based.
You'd have to come up with some other form of mechanics to do what you're suggesting with hard code.
Edited because I have a problem with trigger/triggered :)
02 Sep, 2009, boblinski wrote in the 13th comment:
I'll explain a little more..
To stop people moving out and -in- to the room with the wall in it, there are now two mobs.. one in the room.. and one in the room next to it… If one is killed- I want the other one to die too.. can this be done with hard coding in any newbie-friendly fashion?
Uhh, I dunno. Do you have a way for the mobs to be aware of one another?
Edit: Just a side note. The way you appear to be doing sounds kinda… uhh bad? My guess is one mob is created to block players from leaving, the other is to block players from entering. Instead, you should just have an exit flag (EX_BLOCKED?) that handles this all for you. The only issue here, is the way exit flags are saved/loaded from the game. It uses some funky 'lock' system to make sure that locked doors are closed, etc (logical stuff). One way to handle it is perserve the logical checks by setting/unsetting the specific bits, and then saving the flag variable instead. This way allows you do expand exit flags to do other stuff, like hidden exits, damage-causing exits, etc. Being a coder and using solutions fit for a builder seems… odd :P.
Extend my solution to check for walls in either the target room or the current room; problem solved without needing to deal with triggers or multiple copies of a mob, or exit flags, or anything like that.
02 Sep, 2009, ATT_Turan wrote in the 18th comment:
You can do what Skol says, or you can use some unused part of the mob's data - for example, I'm making the presumption that your walls are inert and do not participate in combat. If that's the case, when you create one you can create another mob in the room it's blocking the way you have it now, and set their CHAR_DATA *victim field to each other; this way, they each know where their other side is.
Then, you'd make an ACT_WALL flag to set on them each - this flag will want to do the following things: * Not set their CHAR_DATA *victim field to players who attack the wall. * Not clear their CHAR_DATA *victim field in violence_update because their victim is not in the same room. * Check for its presence upon a mob's death, and if it's set as a wall, destroy the mob pointed to by CHAR_DATA *victim (and display a wall crumbling message in its room).
I would definitely do the movement-blocking aspect as David suggested and make sure that's part of your move_char.
If your walls are not inanimate (golem walls or made of elementals or something that you would want to attack characters back) then you'd have to do what Skol said and add a new field to the MOB_DATA structure instead of using CHAR_DATA *victim, but this should give you an idea of how to do it.