27 Feb, 2010, jurdendurden wrote in the 1st comment:
Votes: 0
I'm getting together a list of commands I want to prevent players from ordering other players to do while charmed, here's what I've got:

delete, alias, mclass (command for multiclassing), sacrifice.

What else would you add to prevent stupidity/cheating/etc..?
27 Feb, 2010, Idealiad wrote in the 2nd comment:
Votes: 0
Just a suggestion, do it the other way around – make a list of what you want players to be able to do when charming someone. Less room for mistakes that way, especially when adding new commands.
27 Feb, 2010, jurdendurden wrote in the 3rd comment:
Votes: 0
Mmmm good idea, thanks for that!
27 Feb, 2010, Koron wrote in the 4th comment:
Votes: 0
+1 for Idealiad's suggestion. Don't take the risk.

Haha, ninjad!
27 Feb, 2010, Lyanic wrote in the 5th comment:
Votes: 0
I third the motion. Deny by default is usually the best strategy for anything. I setup my interpreter with list groupings of like commands, then create lists of lists as needed. I've been transitioning a lot of my commands/conditions to check these lists for command permissions. For example, I have a list of OOC commands (who, score, level, finger, etc) that can be used at any time under any condition.
27 Feb, 2010, Skol wrote in the 6th comment:
Votes: 0
Here's my list:
if (!str_cmp (arg2, "delete") // Lol, perm death?
|| !str_cmp (arg2, "mob") // Stops them from making pets use mob commands.
|| !str_cmp (arg2, "alias") // Has been known to fubar a char
|| !str_cmp (arg2, "unalias") // See alias
|| !str_cmp (arg2, "quest")
|| !str_cmp (arg2, "petition") // Joining clans
|| !str_cmp (arg2, "induct") // Forced induction if you charm a recruiter/leader
|| !str_cmp (arg2, "promote")// clan promotions
|| !str_cmp (arg2, "demote") // forced clan demotions
|| !str_cmp (arg2, "decline") // decline other players entry into clans
|| !str_cmp (arg2, "ooc") /* Charm is 100% in character so No OOC* DSL */
|| !str_cmp (arg2, "bank") /* Pure character rape* DSL */
|| !str_cmp (arg2, "discharge") // clan jumping
|| !str_cmp (arg2, "shop") // player shop robbery
)
{
send_to_char ("That will NOT be done.\r\n", ch);
return;
}


It's not a huge list, just things that can really mess things up.
27 Feb, 2010, Skol wrote in the 7th comment:
Votes: 0
Er, more:

if ((is_name (arg2, "ooc") // Just lame ones,  say no
|| is_name (arg2, "clan")
|| is_name (arg2, "buy")
|| is_name (arg2, "sell")
|| is_name (arg2, "pray")
|| is_name (arg2, "story")
|| is_name (arg2, "note")
|| is_name (arg2, "idea")
|| is_name (arg2, "warnote")
|| is_name (arg2, "description")
|| is_name (arg2, "quest")
|| is_name (arg2, "decline")
|| is_name (arg2, "nosummon")
|| is_name (arg2, "prompt")
|| is_name (arg2, "title")
|| is_name (arg2, "auction")
|| is_name (arg2, ".")
|| is_name (arg2, "\"")
|| is_name (arg2, "deaf")
|| is_name (arg2, "craps")
) && (!IS_NPC(och)))
{
act ("$N shakes $s head at $n but remains faithful.", ch, NULL, och, TO_NOTVICT);
act ("You shake your head at $n but you still like them.", ch, NULL, och, TO_VICT);
act ("$N shakes $s head at you but $s eyes seem to still worship you.", ch, NULL, och, TO_CHAR);
}
else if ((is_name (arg2, "delete") // Really lame ones, lose charm
|| is_name (arg2, "mob")
|| is_name (arg2, "alias")
|| is_name (arg2, "unalias")
|| is_name (arg2, "petition")
|| is_name (arg2, "induct")
|| is_name (arg2, "promote")
|| is_name (arg2, "demote")
|| is_name (arg2, "bank") /* Pure character rape* DSL */
|| is_name (arg2, "discharge")
|| is_name (arg2, "shop")
|| is_name (arg2, "practice")
|| is_name (arg2, "train")
|| is_name (arg2, "password")
|| is_name (arg2, "tithe")
|| is_name (arg2, "cast")
|| is_name (arg2, "sacrifice")
) && (!IS_NPC(och)))
{
affect_strip (och, gsn_charm_person);
REMOVE_BIT (och->affected_by, AFF_CHARM);
act ("$N shakes $s head at $n and $s eyes seem to clear.", ch, NULL, och, TO_NOTVICT);
act ("You shake your head at $n and defie the order as your mind clears!", ch, NULL, och, TO_VICT);
act ("$N shakes $s head at you and $s eyes seem to clear.", ch, NULL, och, TO_CHAR);
}
else
interpret (och, argument);
27 Feb, 2010, Lyanic wrote in the 8th comment:
Votes: 0
Skol has just posted a good example of what not to do. No offense, Skol - I'm sure you only did it that way because that's how you learned to do it from stock Diku.
27 Feb, 2010, Runter wrote in the 9th comment:
Votes: 0
Lyanic said:
Skol has just posted a good example of what not to do. No offense, Skol - I'm sure you only did it that way because that's how you learned to do it from stock Diku.


Yeah, biggest issue is when you add more commands that should be black listed, specifically really-bad ones to force someone to do, and then forget to update that. This is why you should explicitly define the things that they can do. Such as maybe all skills (which doesn't need expanding if done right) and specific commands.
27 Feb, 2010, Kline wrote in the 10th comment:
Votes: 0
Koron said:
+1 for Idealiad's suggestion. Don't take the risk.

Haha, ninjad!

I've got command groupings but they aren't used much, yet, except for display. I added a ghost state to players after they die and limited commands there by adding an extra field to the command table (since being ghosted will be a normal, frequent part of gameplay). For shorter duration stuff like charm or other spells it's on an allow certain, deny all.

if ( IS_GHOST(ch) && cmd_table[cmd].ghost_cmd == false )
{
ch->send("Not while you're dead!\r\n");
return;
}
28 Feb, 2010, Malek Kervanes wrote in the 11th comment:
Votes: 0
one thing you could do is add to each command function a flag like this:

forgive my crappy pseudocode

if ( IS_SET( ch->aff->AFF_CHARMED) )
then show message that it won't happen
.


just an idea.
28 Feb, 2010, Scandum wrote in the 12th comment:
Votes: 0
What worked for me is giving each command in the command table a trust level between -10 and 99 as well as a bit vector. Charmed mobs have a trust of -9 and aren't allowed to do all that much. Additionally you could set a CMD_PLAYER flag that checks if it's a command mobs shouldn't be using, and typically those are the ones you wouldn't want a charmed player to be forced to execute either. Not sure why a charmed player shouldn't be forced to execute sacrifice, the controlling player could just as easily sacrifice things himself.
28 Feb, 2010, kiasyn wrote in the 13th comment:
Votes: 0
Runter said:
Lyanic said:
Skol has just posted a good example of what not to do. No offense, Skol - I'm sure you only did it that way because that's how you learned to do it from stock Diku.


Yeah, biggest issue is when you add more commands that should be black listed, specifically really-bad ones to force someone to do, and then forget to update that. This is why you should explicitly define the things that they can do. Such as maybe all skills (which doesn't need expanding if done right) and specific commands.


Biggest issue is probably it won't block 'del' for delete.
28 Feb, 2010, David Haley wrote in the 14th comment:
Votes: 0
Well, unless there was some previous logic that expanded arg2 to its full matching command of course.
28 Feb, 2010, Koron wrote in the 15th comment:
Votes: 0
Scandum said:
Not sure why a charmed player shouldn't be forced to execute sacrifice, the controlling player could just as easily sacrifice things himself.

If you have anti-alignment gear or skills and sacrifice can be used to change your alignment by choosing good/evil gods, you could really mess with people with sacrifice. I'm sure I could come up with other scenarios, but this line of thinking seems the most plausible. Sacrifice doesn't have to be benign!
28 Feb, 2010, Skol wrote in the 16th comment:
Votes: 0
Lol good point Lyanic, it was legacy code.

If I was to do it NOW, I'd probably just expand the structure of the commands table to include a bool for 'can be ordered'. Then when a new command is put in, it'd be done already. This would also stop partial commands slipping past (although is_name accomplishes that above).
28 Feb, 2010, Scandum wrote in the 17th comment:
Votes: 0
Koron said:
Scandum said:
Not sure why a charmed player shouldn't be forced to execute sacrifice, the controlling player could just as easily sacrifice things himself.

If you have anti-alignment gear or skills and sacrifice can be used to change your alignment by choosing good/evil gods, you could really mess with people with sacrifice. I'm sure I could come up with other scenarios, but this line of thinking seems the most plausible. Sacrifice doesn't have to be benign!

I guess you could have the alignment change go to the controlling character, but that might be a little too much work.
28 Feb, 2010, triskaledia wrote in the 18th comment:
Votes: 0
Typically I would code this charm bit like you are, what you don't want them to do, but after reading everyone elses opinions, I've changed my mind. If you have a vape command for the players that upset you, can a max level pet use that? What commands like addlag, rename, quit, and those helpfiles that are longer than the players 'scroll' (can charmies be sent into a helpfile)? I have to agree that the best thing to do would to only allow charmies things like kill, some player skills/spells, and the like. That would prevent them from abusing any old/new command in the MUD.
Random Picks
0.0/18