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 |
| Reporter | Assigned To | ||||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Summary | 0000244: Add priority to notify_fail() | ||||
| Description | Short: Add a priority to notify_fail() Date: 2001-05-16 From: Gnomi Type: Feature State: New 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 priority. | ||||
| 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. |
