new command: block <target>?

[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.