|
shalimar GURU
Joined: 04 Aug 2002 Posts: 4691 Location: Pensacola, FL, USA
|
Posted: Sat Nov 26, 2011 7:47 pm
New #EVENTs |
onMoveFail - for when there is no exit in the direction specified with #MOVE
onRoomNotFound - when #FIND gets no matches
Fixed definition |
|
_________________ Discord: Shalimarwildcat
Last edited by shalimar on Tue Nov 29, 2011 5:59 am; edited 1 time in total |
|
|
|
Rahab Wizard
Joined: 22 Mar 2007 Posts: 2320
|
Posted: Mon Nov 28, 2011 2:47 pm |
Hm. I like the idea, but there is no easy way for Cmud to tell when a move fails. The only way to tell is by triggering on specific phrases that indicate failure. Without that, Cmud can only tell when it sees lines that match the pattern for a room name/description, or a timeout waiting for such a match. If Cmud sees a room name/description, it cannot tell whether this is the result of movement 1, or movement 2, or a 'look' command.
I suppose you could have the event raised if the match times out or if the room name/description does not match what is expected. But that is not a guarantee that the move failed. |
|
|
|
shalimar GURU
Joined: 04 Aug 2002 Posts: 4691 Location: Pensacola, FL, USA
|
Posted: Tue Nov 29, 2011 4:49 am |
Well since #MOVE forces a #LOCATION object change (when it works), it should be easy to have it check to see if the %roomnum is not in fact the same as it used to be
As to the second one, i meant that for use of the #FIND command, not #LOOK, as it also resets the #LOC when a match is found. Though this may not in fact be a change of position. |
|
_________________ Discord: Shalimarwildcat |
|
|
|
MattLofton GURU
Joined: 23 Dec 2000 Posts: 4834 Location: USA
|
Posted: Tue Nov 29, 2011 5:04 am |
It would probably need to be %roomvnum(). %roomnum()--what GMCP uses--probably doesn't have to be unique.
|
|
_________________ EDIT: I didn't like my old signature |
|
|
|
Rahab Wizard
Joined: 22 Mar 2007 Posts: 2320
|
Posted: Tue Nov 29, 2011 1:38 pm |
True, it can tell when it enters a new room (and thus raises onRoomeEnter), so I was wrong about it not being able to tell whether the room description comes from a movement or a look. But if you are executing multiple movement commands in a row, it can't easily tell whether the new room is a result of a successful movement 1 or a failed movement 1 followed by successful movement 2. You might be able to figure it out by comparing expected room numbers to actual room numbers, and it would indeed be useful to have some kind of flag indicating "You aren't where you expected to be". There are definitely times when I could use that. I think someone posted some time ago about making code to do that. It would be useful in cases where the path is valid and mapped (and thus Cmud can predict where you should be). It would catch situations when movement failed for unexpected reasons, e.g.: unexpected closed or locked door; 'slippery' areas where movement is not guaranteed; unexpected traps that prevent or redirect movement; encumbrance that partially prevents movement; changes to the map; etc. The best way to handle all of these situations is with triggers to capture the mud-side messages warning about them, but new situations can come up that you haven't captured yet. And occasionally, the mud does not send convenient messages to capture.
It wouldn't be useful when the area is not completely mapped, or when one of the directions in the movement queue is incorrect. Cmud would assume that the movement is correct and prepare to make a new exit (if in mapping mode). This is where capturing mud warning messages becomes important. |
|
|
|
shalimar GURU
Joined: 04 Aug 2002 Posts: 4691 Location: Pensacola, FL, USA
|
Posted: Tue Nov 29, 2011 8:02 pm |
these suggested events are just a fail condition for two commands
|
|
_________________ Discord: Shalimarwildcat |
|
|
|
|
|