View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000244||LDMud||Efuns||public||2004-11-26 23:55||2009-10-01 17:09|
|Summary||0000244: Add priority to notify_fail()|
|Description||Short: Add a priority to notify_fail()|
Add a numeric priority to notify_fails(), so that a previous message
is replaced only by one with an equal or higher priority.
In other words: previous messages are not overwritten by messages with a lower
|Tags||No tags attached.|
|External Data (URL)|
||We currently solve this by an sefun, which also estimates priorities of different objects. But letting the driver take care of this, would also be nice.|
I'm not sure, if it's a good idea. In the end the wizards will have to adhere to a MUD-standard for notify_fail() call priorities for different situations (thus replacing our _notify_fail() and notify_fail()), but then it would just be simpler to use these two (s)efuns directly. Because its clearer what they're for: One case, if your not sure, that the object was the intended target; one case, if youre sure of it - at least, thats how we use it.
If we end up allowing all kind of priorities for notify_fail(), we will just make bug-tracking more complicated.
In the Tublib, we implement notify_fail() with priorities as sefun. If the driver takes care of this, it should be possible to receive all n_f()-messages which were raised during the evaluation of a player command (which is our current sefun implementation and very handy in rare cases of debugging).
I'm not sure if the handling of notify_fail() with priorities should better stay in the mudlib.