New Approach Idea?

ID:152198
 
Oct 13 2007, 7:14 pm (Edited on Oct 13 2007, 7:19 pm)
You'll understand it from da example code. Probably won't be revolutionary but just another way to do stuff. 
//1: good ol'

mob
    var/muted
    verb/Shout()
        if(muted) src << "J00 are mut4d."
        else world << "[src.name] shouts."
    admin/verb/Mute(mob/M)
        M.muted = !M.muted

//2: New Approach Idea?
mob
    verb
        Shout() world << "[src.name] shouts."
        Shout_muted()
            set name = "Shout"
            src << "J00 are mut4d."
    admin/verb/Mute(mob/M)
        var/talk_verb = /mob/verb/Shout
        if(talk_verb in M.verbs)
            M.verbs -= talk_verb
            M.verbs += text2path("[talk_verb]_muted")
        else //if M is muted (or is a messed up mob.)
            M.verbs += talk_verb
            M.verbs -= "[talk_verb]_muted"
    New() //just to make this a shorter example
        src.verbs -= /mob/verb/Shout_muted

You get the idea. Save some negligible vars. Have shorter var dumps! Yay or nay? Good or bad? Worth it or not? Am I bored?
Oct 14 2007, 1:42 am
O.o, I don't see the point of removing Shout() and replacing it with Shout_muted(), although it IS different.
Oct 14 2007, 9:17 am
In response to Kakashi24142
The effect basically disables the verb, but you don't need to make a boolean or as such for each X verb you want to toggle, resulting in tons of extra vars that could've been handled a better way (not necessarily like this though of course).
Oct 14 2007, 10:09 am
In response to Kaioken
If I wanted a mute system, I'd only have a mute var. It would shorten the vars, but I don't think it's necessary to make separate verbs in place of vars. That's why we have vars in the first place.
Oct 14 2007, 10:21 am
In response to Kaioken
I just take away their shout() verb or whatever. When they are unmuted I give it back. Your stuff looks like a lot more work then it is worth.
Oct 14 2007, 10:32 am
In response to Revenant Jesus
Of course, but sometimes you want to do something in the alternate case. Muting is just a common example. Though removing the command will cause errors if a player attempts to use it, which isn't preferable. This stuff is some work but just a nice idea I had. This is just a basic example just to show the idea, you can make a system and have it way more dynamic, and not have to do any extra work after you get that over with, just coding verbs in 2 separate parts.
Oct 14 2007, 10:37 am
In response to Kaiochao2536
The vars list is a var, so basically you're just using it instead of your own. Of course you can do similarly the normal way too, and not have that too-common extra-var-for-anything method, instead of having tons of vars for things you can often combine them into a single general var like 'status' etc and use efficient bitflags, or other things such as lists and text strings.
Oct 14 2007, 2:33 pm
In response to Kaioken
Kaioken wrote:
Though removing the command will cause errors if a player attempts to use it, which isn't preferable.

If you physically take the verb, but if you for instance have the verb on a menu, you an jsut disable the menu button; greying it out. :D
Oct 15 2007, 6:11 am
I'd probably go the "good ol'" way, seeing as I don't like using verb-replacement hacks. You should apply that variable to a client, though.
Oct 16 2007, 8:29 pm
In response to Mecha Destroyer JD
You can't stop players from attempting to use via typing the command or using a macro to do the same. :P

@peanut: You're correct, sure. This is just a lil example though.
Oct 17 2007, 9:56 am
In response to Kaioken
Kaioken wrote:
You can't stop players from attempting to use via typing the command or using a macro to do the same. :P

That is why I reccomend the use of a single variable that determines wether you have the right to speak.
Oct 17 2007, 10:12 am
In response to Kaioken
You could if you used Version 4.0, you can just not add in the command prompt.
Oct 19 2007, 10:36 am
In response to Revenant Jesus
It's not that simple. No matter what the Option & Messages box will always have an option that lets up type in a command which is the same thing as using an input box.
Oct 19 2007, 12:04 pm
In response to Revenant Jesus
...Besides, that would be quite an awkward, and, excuse me, rather silly workaround. Disable the player's useful ability to type all commands, some unrelated to the commands in your game, just because there is some lack in your code that can cause an error to appear? If already you could attempt a different workaround with less consequences, perhaps such as overriding client/Command() to remove such errors and whatnot.
Oct 19 2007, 12:13 pm
Nay, relogging defeats the system so long as you aren't saving the verbs the player has in a savefile. And if you do save the verbs, you better have a competent host because I'm going to add /mob/admin/verb/Mute to myself by editing my savefile.

-- Data
Oct 19 2007, 12:43 pm
In response to Android Data
Android Data wrote:
Nay, relogging defeats the system so long as you aren't saving the verbs the player has in a savefile.

Well, verb saving is kind of self-implied by this approach. You'd usually do it anyway regardless.

And if you do save the verbs, you better have a competent host because I'm going to add /mob/admin/verb/Mute to myself by editing my savefile.

Of course, of course. But that accounts for basically all approaches.
Oct 19 2007, 1:12 pm
In response to Kaioken
Kaioken wrote:
Of course, of course. But that accounts for basically all approaches.

Not if I make a muted list and check that, and upon reboot retrieve my list from a central server. =P

-- Data
Oct 19 2007, 1:19 pm
In response to Android Data
+10 pts!