For 'recycle' message (and others) put the #dbref
Opened this issue · 7 comments
This is a sourceforge issue. NOTE: the scope of this may not include MUFs (as suggested in the original issue). I will see how much work it is to do the MUFs as well. I am also tempted to put a tune parmaeter for this so admins can toggle it off if they have some reason to do so, but I think that could be a lot of extra branching for an edge case? Maybe something to determine when digging into the code, consider it a "nice to have" rather than a "must have".
When you recycle something currently, you see the message, "Thank you for recycling."
I think it would be infinitely helpful to insert the name and dbref of the object that you have just recycled in that message.
Example:
Server says:
Thank you for recycling Arcana's Bug Report(#500).
This would make it easier for people to realise they recycled incorrect objects and make them "assured" that they recycled correct objects.
--
As a general request, it would be nice if every error message and feedback message would give this sort of information to the user so it is easier to discover what is going on. When exits, rooms, and objects are created, their names and dbrefs are returned to the user, which is good. But it would be very nice for these to be returned in many cases, such as:
-When you @set a flag on an object
"Flag W set on Arcana(#34PBC)"
-When you @edit a program
"Editing program cmd-thing(#100LM2)"
-When you try to perform a command on a nonexisting object
"I don't see nsdfaskasjdflj here." (instead of "I don't see that here.")
This may require some modification to MUF code instead of server code.... but it's a feature request nonetheless.
Messages with more detail like this can help especially when you're uploading a script and something goes wrong. Seeing a bunch of messages like, "I don't see that here." doesn't help you much if your script is wrong, and I think that giving more details will make scripts easier to debug.
Would it make sense to introduce a function that returns either an object's name or its unparsed name depending on the tune? And then use that for these messages?
Would the tune default to yes? We have a mix right now (I think) of showing the dbref and not, so I'm not sure.
Yeah, tune default to yes. If you want to do it that way, mind. I'm kinda iffy on if it is necessary? I mean ... most MUCKs have custom MUFs for most of these functions so I'm not sure its really necessary to go to the effort to make the tunes. They can always just alter their own functions.
For the huh? message, we may want to allow the %s substitution in it to indicate where the command is, since that is overriden by tune variable already.
I'm kind of talking myself out of bothering with the tune stuff :) But if you do it, making a function as you propose makes sense.
I'm not going to make a tune parameter for this, I don't think it is necessary. I will, however, consider altering the MUFs if it looks reasonable to do so. There's a lot of ground to cover on this issue so the MUFs may need to get split off into their own thing.
Okay, there's definitely some work to do here, it's kind of a patchwork and there's a good bit of edge cases not covered. Anyway, i'll stop spamming these comments and actually get to it :D
I've worked my way through create.c which I think is the majority of this.
This one is kind of a pest. I'm going to shift it to a later milestone and shelf it for a bit, as I would like to get 7.1 out and I think this is just slowing it down for an issue nobody's really clamoring for (and can be solved in MUF). I have this work on a separate branch of my code for when I get back to it.