new command: block <target>?

[najdorf]

not sure if this has been discussed before.. This is already in place for guarding a single direction: guard <direction>

syntax: block <target>
Skill used: Guard
Bonus for blocker: Agility
Bonus for target: Agility, running status
success rate: Definitely lower than the actual guard <direction>

Code Select Expand


The tall, blonde man stands here.

block tall
You stepped closer to the tall, blonde man, blocking his path.

The tall, blonde man tries to walk south but you blocked his path.

The tall, blonde man tries to walk east but you blocked his path.

You failed to block the tall, blonde man as he walked away from you to the east.

It has many goods. For instance, it will prevent people from unrealistically spam running to a random direction in a [NESW] area when raided..

Any thoughts?

[RogueGunslinger]

Love it.

[A Large Bag]

This is a good idea. I think strength should play into it too though. If I'm bigger and stronger than you and you try to block me, I'm going to just shove you out of my way. Maybe a combination of strength and agility playing into it. Maybe, agility+skill vs. agility+skill for getting in the way and attempting to block. Str+skill vs str+skill to see if you can stop them once you've gotten in the way.

[Drayab]

What about subdue?

[Nyr]

If you want to stop someone from going anywhere, have the power to do so.  Either subdue them, incapacitate them (several ways to do that), or have all exits blocked.  If someone is spam running away from your elaborately-planned, well-RP'd raiding scene, you need to spam knock them the fuck out.

[najdorf]

If you want to stop someone from going anywhere, have the power to do so.  Either subdue them, incapacitate them (several ways to do that), or have all exits blocked.  If someone is spam running away from your elaborately-planned, well-RP'd raiding scene, you need to spam knock them the fuck out.

true but i also believe players would prefer less hostile ways, if it was possible. it will be just a soft warning to the victim, rather than an instant KO. on the other side, from the victim's perspective: if someone tried to subdue my super dangerous character, i would annihilate them but blocking my path would give more room for rp

[A Large Bag]

If you want to stop someone from going anywhere, have the power to do so.  Either subdue them, incapacitate them (several ways to do that), or have all exits blocked.  If someone is spam running away from your elaborately-planned, well-RP'd raiding scene, you need to spam knock them the fuck out.

true but i also believe players would prefer less hostile ways, if it was possible. it will be just a soft warning to the victim, rather than an instant KO. on the other side, from the victim's perspective: if someone tried to subdue my super dangerous character, i would annihilate them but blocking my path would give more room for rp

Good point.

[BadSkeelz]

if someone tried to subdue my super dangerous character, i would annihilate them but blocking my path would give more room for rp

Or just a 5 second delay before you annihilate them to get rid of their blocking.

As much as people escaping bugs me, this just seems superfluous. Between guard, subdue, bash, and straight up zerg rushing people, there's lots of tools already in place to keep people in one place.

[Drayab]

I don't think one person, in the middle of the desert, can reasonably block another person from running off in an arbitrary direction. Blocking one direction, sure, but to stop them from going anywhere, seems like you should need (3 or 4) friends to surround them or else lay hands on them (bash or subdue). That's how the code works now, and I think it makes perfect sense.

What I would like to see is some kind of approach code, such that if somebody tries to walk out while you've got their attention, you get a chance of an action. For example, approach amos subdue will try to subdue amos if he tries to leave the room.

Edited: pardon my stupidity

[Nyr]

What I would like to see is some kind of approach code

[Malifaxis]

What I would like to see is some kind of approach code

I think this has enterred the official "Nyr needs this as his Avatar" competition.

[Drayab]

Yeah, yeah. I am aware I'm not the first to come up with this idea, and probably implementation is not as easy as it is in my head.

But just for fun, let me expand on this idea a little. Call the new command threaten, and it takes a target and an aggressive action as parameters. It echos to the victim '<aggressor> looks at you threateningly,' and it echos to the aggressor 'You prepare to <action> <victim> if they make a run for it.' The action triggers if the victim tries to flee self or run/walk in a direction, and it gets cancelled if the victim somehow ends up in combat. The aggressor gets one shot which prevents movement if it succeeds, and the victim gets away if it fails. Perhaps flee works better for escape than just walking/running.

The aggressor doesn't lose any opportunity that could have been had by using the aggressive action directly, and the victim doesn't lose anything except a chance to spam run from a raider that came in to rp.

[maxid]

That's actually a neat idea.  No idea how feasible, but it's a really cool idea, and could help counter people who spam walk away from everyone always.

[Feco]

I don't see any way a person could simply run around getting in someones way so much that they can't leave an area -- any effective "blocking" seems like it's going to involve some level of grabbing, shoving, etc.  This makes it sound just like another iteration of subdue, really.

[Ktavialt]

What about a guard ability that works during combat?  Also, does guarding a doorway exit work better than guardian a regular exit, because it seems like it really should because of it being narrower?

[Drayab]

What about a guard ability that works during combat?  Also, does guarding a doorway exit work better than guardian a regular exit, because it seems like it really should because of it being narrower?

It's called bash.

[Synthesis]

How exactly could you (mundanely) block someone's egress in a 360 degree manner, without being vastly more quick or agile?

There are at least 4 combat skills, 2 poisons, and several magick/psionic abilities related to keeping people from retreating that a) work and b) are more realistic than this.

The only instances where it would make sense are those times where the "blocking" PC is in fact vastly quicker or more agile.  It might apply to elves vs. dwarves or humans, and under other circumstances that I'm not going to talk about.  At any rate, it wouldn't be skill-based, it would be stat-based, or stat-based -and- skill-based.

[maxid]

I didn't assume it'd just autowork when I posted my approval.  But yeah, if Joey "Poor Agility" Dwarf is trying to run from Johnny "AI Agility" Elf?  Johnny should be able to stab Joey in the ass with his spear the moment Joey tries to run forcing him to use flee to escape, and giving a round or whatever for a bash to go off.  Instead, right now, Joey can just do run;e;e;e;e;e;e;e;e;n;e;n;e;n;n;e;e;n;w;s;w;s;w and be completely unrealistically free of Johnny.

Sure Peraine, Heramide, bash, etc. exist.  But you don't always want to be the person to actually initiate violence if you're looking to raid/discuss/threaten/intimidate, unless they decide to run for various reasons (Certain spell effects, not wanting the raided person to die, monologuing, etc.) Though, one immediate issue I can see with it already is that it seems as if it would give delves yet another boost if it went into effect as you said above, Synthesis.

[A Large Bag]

The only instances where it would make sense are those times where the "blocking" PC is in fact vastly quicker or more agile.  It might apply to elves vs. dwarves or humans, and under other circumstances that I'm not going to talk about.  At any rate, it wouldn't be skill-based, it would be stat-based, or stat-based -and- skill-based.

Maybe a combination of strength and agility playing into it. Maybe, agility+skill vs. agility+skill for getting in the way and attempting to block. Str+skill vs str+skill to see if you can stop them once you've gotten in the way.

[Ktavialt]

It's called bash.

Well this sure was an unnecessarily scathing reply to my genuine question, not to mention also incorrect and even to the extent that it does work, it overlooks scenarios where bash is insufficient.

So, up yours too buddy.

[Synthesis]

I didn't assume it'd just autowork when I posted my approval.  But yeah, if Joey "Poor Agility" Dwarf is trying to run from Johnny "AI Agility" Elf?  Johnny should be able to stab Joey in the ass with his spear the moment Joey tries to run forcing him to use flee to escape, and giving a round or whatever for a bash to go off.  Instead, right now, Joey can just do run;e;e;e;e;e;e;e;e;n;e;n;e;n;n;e;e;n;w;s;w;s;w and be completely unrealistically free of Johnny.

Sure Peraine, Heramide, bash, etc. exist.  But you don't always want to be the person to actually initiate violence if you're looking to raid/discuss/threaten/intimidate, unless they decide to run for various reasons (Certain spell effects, not wanting the raided person to die, monologuing, etc.) Though, one immediate issue I can see with it already is that it seems as if it would give delves yet another boost if it went into effect as you said above, Synthesis.

Sounds like a 'threaten' command is what you want.  Search the numerous old threads about this for more.

[Drayab]

It's called bash.

Well this sure was an unnecessarily scathing reply to my genuine question, not to mention also incorrect and even to the extent that it does work, it overlooks scenarios where bash is insufficient.

So, up yours too buddy.

I didn't mean to be scathing. 

I think bash works pretty well, though. It's not 100% effective, but then I don't think anything should be without risk.

[maxid]

^^Drayab, you still didn't address his actual issue or question, you just snarkily quipped at him.  It was, and remains, unproductive.

Sounds like a 'threaten' command is what you want.  Search the numerous old threads about this for more.

It was mentioned here in this thread too so I thought that it was being discussed, I see now that you were talking about the 'block' command, rather than the 'threaten' one, so my bad, I wasn't reading closely.

[MeTekillot]

only if any other race trying to block a half-giant gets stepped on and instantly killed

[Drayab]

^^Drayab, you still didn't address his actual issue or question, you just snarkily quipped at him.  It was, and remains, unproductive.

I sincerely apologize for any perceived snark. It was not intended.

I thought the 'guard ability that works during combat' was being propsed as a way to stop people from fleeing while in combat, like how the block <person> is being proposed as a way to stop someone from running away outside of combat. Bash works for exactly this purpose, as does charge. What am I missing?

[maxid]

I thought the 'guard ability that works during combat' was being propsed as a way to stop people from fleeing while in combat, like how the block <person> is being proposed as a way to stop someone from running away outside of combat. Bash works for exactly this purpose, as does charge. What am I missing?

Well this sure was an unnecessarily scathing reply to my genuine question, not to mention also incorrect and even to the extent that it does work, it overlooks scenarios where bash is insufficient.

A simple example, to explain what -I- see to be Ktavialt's possible question to mean, or a possible scenario where it could be useful:

Let's say me and you are fighting.  The room has a west exit, to the desert, and an east exit, deeper into a cave.  I decide I want to CombatGuard West, so you have the option of fleeing, but only to the east.  This could, potentially, lower my defense, and make me a lot easier to hit, since I won't be able to move and dart about with impunity, but it'd also make you have to pass a guard check to go west, in order to try and escape the cave.  Bash would put you on the ground, and render you unable to go east or west, which may not fit in with my nefarious plans for running you into the cave.  There are likely other examples as well that I haven't thought of yet.

To Ktavialt: No there isn't anything like that, though it'd be a pretty neat bit of code in my opinion.

[Synthesis]

Now we're talking about (at least) three different things in this thread:

1.  A pan-exit "guard" command vs. a single target (neither PC in combat)
2.  Threaten
3.  Exit-guarding that isn't dropped by combat

You really should make these things separate threads.  The OP was talking about #1 only, and if you get it confounded with the other two, this thread is going to devolve into confusing nonsense that will be dismissed outright by anyone who might have the unique combination of time, interest, and ability to code it.

Yes, there is an underlying issue that is at the root of all of these proposed code solutions ("it's too easy for Amos to run away"), but that doesn't mean it will be fruitful to bring up every possible solution to the problem, when the OP specifically is only proposing one solution.  It would be more helpful to discuss why you think that solution is or isn't good, and maybe suggest the others and provide a link to an old thread about them, or start a new thread for them, so as not to derail this particular thread with arguments that are irrelevant to the OP and thus confusing to anyone who hasn't bothered to read every post in the series.

[Thunkkin]

I like the original idea.

While I think other commands/means can achieve similar results, I think the flavor of this command is very appealing. Just because you can kill someone with a sword doesn't mean that killing them with a fireball is redundant.

The objection that blocking someone from moving every direction is unrealistic has some merit. However, the OP states that this skill/command would have a higher rate of failure than the normal block. Moreover, if you've ever been bullied or had someone step up right in your face, you'll know that it can feel as if there's very few avenues of escape and a competent aggressor can actually herd you and physically shut down your movements without necessarily tackling you.

Great idea, najdorf.

[A Large Bag]

I like the original idea.

While I think other commands/means can achieve similar results, I think the flavor of this command is very appealing. Just because you can kill someone with a sword doesn't mean that killing them with a fireball is redundant.

The objection that blocking someone from moving every direction is unrealistic has some merit. However, the OP states that this skill/command would have a higher rate of failure than the normal block. Moreover, if you've ever been bullied or had someone step up right in your face, you'll know that it can feel as if there's very few avenues of escape and a competent aggressor can actually herd you and physically shut down your movements without necessarily tackling you.

Great idea, najdorf..

Yes agreed. Much harder to do than just guarding a single direction but possible if skilled enough, agile enough, and strong enough to get in the way and stop them.

[Synthesis]

I don't see how it could be justified in terms of crime-code.  If subdue and fist-fighting (outside pre-approved establishments) will get you crim-flagged, this sort of pan-guard should also get you crim-flagged, because there's no way you could bully someone around like that without at least resorting to some pushing and shoving.  Now, that might be acceptable.

However, I can think of a few scenarios where pan-guard could be used in PK situations where it would be functionally like subdue without the risks inherent (to the aggressor) to subduing someone.

So...
1.  It should crim-flag you if you do it in a lawful area.
2.  There probably should be some restrictions or penalties on ranged targeting of folks who are being pan-guarded, similar to the current penalties for actual melee, since for all intents and purposes you're in melee, just not yet swinging weapons.
3.  Similar penalties should apply for other relevant skills that incur penalties when used against targets in melee (e.g. charge).
4.  'Rescue' and 'guard' should work to prevent someone or rescue someone from being pan-guarded.
5.  It shouldn't be possible to pan-guard someone on a mount.  It may be acceptable for someone -on- a mount to pan-guard someone, but I would put a heavy ride skill-check on this.
6.  It shouldn't be possible to pan-guard someone if they have something going on that would prevent them from being subdued and/or bashed.

Feel free to add to the list.

[Drayab]

Moreover, if you've ever been bullied or had someone step up right in your face, you'll know that it can feel as if there's very few avenues of escape and a competent aggressor can actually herd you and physically shut down your movements without necessarily tackling you.

I think that feeling of being trapped has more to do with fear than actually being physically constrained. For example, being afraid that he will do something as soon as your back is turned.

It's not that every time you try to turn around the big oaf skitters back in front of you. It's that you're afraid that if you don't face him then you won't be ready when he actually tries to harm you.

[A Large Bag]

I don't see how it could be justified in terms of crime-code.  If subdue and fist-fighting (outside pre-approved establishments) will get you crim-flagged, this sort of pan-guard should also get you crim-flagged, because there's no way you could bully someone around like that without at least resorting to some pushing and shoving.  Now, that might be acceptable.

However, I can think of a few scenarios where pan-guard could be used in PK situations where it would be functionally like subdue without the risks inherent (to the aggressor) to subduing someone.

So...
1.  It should crim-flag you if you do it in a lawful area.
2.  There probably should be some restrictions or penalties on ranged targeting of folks who are being pan-guarded, similar to the current penalties for actual melee, since for all intents and purposes you're in melee, just not yet swinging weapons.
3.  Similar penalties should apply for other relevant skills that incur penalties when used against targets in melee (e.g. charge).
4.  'Rescue' and 'guard' should work to prevent someone or rescue someone from being pan-guarded.
5.  It shouldn't be possible to pan-guard someone on a mount.  It may be acceptable for someone -on- a mount to pan-guard someone, but I would put a heavy ride skill-check on this.
6.  It shouldn't be possible to pan-guard someone if they have something going on that would prevent them from being subdued and/or bashed.

Feel free to add to the list.

1. Agreed
2. Definitely. Like if someone is being "blocked" and someone else tries to do a ranged attack on that person they get a message: You try to take aim on <blocked guy> but <blocker> is in the way.
3. Yes, with the exception of the blocker initiating those other things that would initiate melee.
4. Good idea. A successful guard, stops the block from being initiated against the target. A successful rescue, frees up the blocked person.
5. Absolutely.
6. Like? I'm having trouble thinking of what you're getting at.


7. It should be impossible for a non half-giant to successfully block a half-giant. Attempting so should be similar to when a non half-giant attempts to bash or subdue a half-giant.
8. Being armed should give a bonus when blocking an unarmed person.
9.Being armed should give a bonus against being blocked by an unarmed person.
10. The more exits there are from the area, the easier it is to escape from. The fewer, the harder.

[maxid]

6. Like? I'm having trouble thinking of what you're getting at.

Magick, possibly certain other things.  I can think of a couple effects that should render pan-guard a nonissue.  That's heavily IC territory though.  Otherwise, yeah I pretty much agree with all that was said thus far.  Except maybe you don't get crim-coded until you actually do block someone from trying to move, rather than immediately upon initiating the pan-guard code and combat ensues.  I just don't see Zalanthans as being too upset about someone getting in someone's face, so long as it didn't erupt into a full fledged fight.

[MeTekillot]

Someone mentioned being able to use guard while still in combat. Atonement has that. That is, where you can guard an exit and still engage someone in combat, as long as they aren't focused on you.

Let's not have that. Let's not have that at all.

[maxid]

Someone mentioned being able to use guard while still in combat. Atonement has that. That is, where you can guard an exit and still engage someone in combat, as long as they aren't focused on you.

Let's not have that. Let's not have that at all.

What an insightful and wellt hought out post, that explains several reasons as to why it is a bad idea, in order to foster discussion.  Thank you, sir, for the time you took to craft it for us all.

[MeTekillot]

It's a bad idea because, while it may be feasible in a realistic sense for someone to batter you and simaltaneously prevent your egress from them, it shouldn't be possible from a code-side sense because killing someone really isn't all that hard if you have a couple of dudes with you already.

I'm not commenting on the block <target> thing specifically with that post, or this post, technically I guess? But it seems like it hasn't had enough thought put into it and would have to have cumbersome restrictions put on to it to actually not be ridiculous.

[maxid]

It's a bad idea because, while it may be feasible in a realistic sense for someone to batter you and simaltaneously prevent your egress from them, it shouldn't be possible from a code-side sense because killing someone really isn't all that hard if you have a couple of dudes with you already.

I'm not commenting on the block <target> thing specifically with that post, or this post, technically I guess? But it seems like it hasn't had enough thought put into it and would have to have cumbersome restrictions put on to it to actually not be ridiculous.

So it's not a good idea because it might be used to kill someone.  On Zalanthas.  Ok.  Just making sure.

[Kismetic]

I would think guard offers more opportunities for RP than anything.  As opposed to say, bash, which is specifically for mercing on a fool.

[Sav]

I don't see how it could be justified in terms of crime-code.  If subdue and fist-fighting (outside pre-approved establishments) will get you crim-flagged, this sort of pan-guard should also get you crim-flagged, because there's no way you could bully someone around like that without at least resorting to some pushing and shoving.

Honestly I thought of five ways of using this to be obnoxious before the combat applications sunk in.

The tall, muscled man asks you, his eyes wide and pleading, "But why did you sleep with my brother?"
n
You try to go north, but the tall, muscled man blocks your way!
The tall, muscled man asks you, nearly crying as he steps in front of you, "WHY WON'T YOU LOOK AT ME? IS HE REALLY THAT MUCH BETTER IN BED?"
n;n;n;n
You try to go north, but the tall, muscled man blocks your way!
flee man
Panic! You try to flee, but instead fall into the tall, muscled man's arms.
The tall, muscled man tells you, crying as he wraps his arms tightly around you, "I JUST LOVE YOU SO MUCH BABY, PROMISE ME YOU'LL NEVER LEAVE."

[Kismetic]

lol @ Sav.  Well, you can already do that ...

Code Select Expand


The tall, muscular man begins guarding the east exit.
The rangy, long-necked breed begins guarding the west exit.

The short man with an underbite looks up at you, digging beneath a fingernail with an obsidian shiv's tip.


But I couldn't really agree with a "pan-guard" usage, anyway.  It's not something you would realistically do without touching someone, at which point, you are in the territory of subdue.

Aaaand ...  what pan-guarding might look like.  lol

[Synthesis]

It's a bad idea because, while it may be feasible in a realistic sense for someone to batter you and simaltaneously prevent your egress from them, it shouldn't be possible from a code-side sense because killing someone really isn't all that hard if you have a couple of dudes with you already.

I'm not commenting on the block <target> thing specifically with that post, or this post, technically I guess? But it seems like it hasn't had enough thought put into it and would have to have cumbersome restrictions put on to it to actually not be ridiculous.

Once again, we're not talking about combat not breaking guard.

This could be an issue if you had 2 aggressors and 1 victim, and one aggressor pan-guarded the victim while the other aggressor attacked, but I think that could be handled either with an auto-break on the pan-guard, or a heavy penalty against success while combat is initiated.

The idea isn't necessarily to make it easier to kill someone, although making it harder to flee -does- increase the risk somewhat, in some circumstances.  I think if the code put enough penalties on those circumstances where it becomes a primary PK method rather than a "stick around to RP" method, it would be a useful addition.

The major problem is identifying all the circumstances where this could be abused to serve primarily as a PK function.

lol @ Sav.  Well, you can already do that ...

Code Select Expand


The tall, muscular man begins guarding the east exit.
The rangy, long-necked breed begins guarding the west exit.

The short man with an underbite looks up at you, digging beneath a fingernail with an obsidian shiv's tip.


But I couldn't really agree with a "pan-guard" usage, anyway.  It's not something you would realistically do without touching someone, at which point, you are in the territory of subdue.

Aaaand ...  what pan-guarding might look like.  lol

It serves some similar functions, but here are the major differences:
Pro:
* Possibly higher degree of success (depends on coding)
* Doesn't leave the aggressor vulnerable
* Don't have to dismount to use it (if your ride skill is very good)
* Multiple people could pan-guard the same target, increasing the chance of success

Con:
* It doesn't place the victim in nearly as vulnerable a position as subdue would
* The target can use the delay when you pan-guard to attack and flee
* Things (perhaps very nasty things) that are impossible while subdued can still be done while pan-guarded

Anyway, the list of considerations is now:

1.  It should crim-flag you if you do it in a lawful area.
2.  There probably should be some restrictions or penalties on ranged targeting of folks who are being pan-guarded, similar to the current penalties for actual melee, since for all intents and purposes you're in melee, just not yet swinging weapons.
3.  Similar penalties should apply for other relevant skills that incur penalties when used against targets in melee (e.g. charge).
4.  'Rescue' and 'guard' should work to prevent someone or rescue someone from being pan-guarded.
5.  It shouldn't be possible to pan-guard someone on a mount.  It may be acceptable for someone -on- a mount to pan-guard someone, but I would put a heavy ride skill-check on this.
6.  It shouldn't be possible to pan-guard someone if they have something going on that would prevent them from being subdued and/or bashed.

7. It should be impossible for a non half-giant to successfully block a half-giant. Attempting so should be similar to when a non half-giant attempts to bash or subdue a half-giant. (Subcategory of #6)
8. Being armed should give a bonus when blocking an unarmed person.
9.Being armed should give a bonus against being blocked by an unarmed person.
10. The more exits there are from the area, the easier it is to escape from. The fewer, the harder.

11.  If the victim is engaged in melee with a third party, pan-guarding should either be impossible or very difficult (again, a subcategory of #6).

[Reiteration]

What I would like to see is some kind of approach code

I think the entire Code Discussion subforum should be turned into a redirect to this image.

[najdorf]

i believe it is more of a feasibility issue. When first submitting the idea, i thought it would be easy to implement: after all a new command that uses guard skill and a couple stats for bonuses.

But as you dig deep into it, many factors come into play, which complicate and perhaps make the idea unfeasable. (Such as blocking someone in a fighting situation, multiple people blocking a person, size/str issues, clan-members auto pass authorization need a change, etc.)

[Nyr]

What I would like to see is some kind of approach code

I think the entire Code Discussion subforum should be turned into a redirect to this image.

Nah, just pointing out that approach code has been a pie in the sky for a while. Interesting idea but not sure it will be implemented as requested by players. It would (IMO) require a fundamental change to combat code to account for it.

[brytta.leofa]

Nah, just pointing out that approach code has been a pie in the sky for a while. Interesting idea but not sure it will be implemented as requested by players. It would (IMO) require a fundamental change to combat code to account for it.

Intriguing.