Saber Def

1
I already explained how saber def works and why it is bad years ago to the CTF folks. I wanted to post the pictures I made back then here, but since I couldn't find them, I just wrote a much more detailed explanation similarly to the "Damage" topic so that balance can be discussed.

Before I start, let's see what the class idiot has to say:
_Peaceful player.: can I have saberdef3 from ctf
The logic is the same regardless of the gametype. Gameplay differences such as the fact that disruptor primary spam usually one shots in siege and slower movement just makes it feel worse when it's actually the same.

Saber def is able to block world projectiles, disruptor hitscan shots and other sabers. I will not be covering the overly complicated (and RNG based) saber vs saber blocks. Even though projectiles and hitscan blocks have a lot of logic in common, there are some differences that are worth mentioning.

1. Impact locations
  Reveal hidden contents
First of all, a word on impacts locations. Whenever the game wants to determine where a shot (or saber impact) landed on a player model, it does a special kind of trajectory tracing called "Ghoul2 Trace". Ghoul2 is what the game uses for models and their animations. The "trace" is simply going to find the first surface point that was hit on the model, and it does so by using a simplified version of the model to run checks against. In fact, the checks are only run on the bones of a skeleton that is common to all humanoid models (which you probably already saw if you ever opened the humanoid skeleton files or any model in ModView). Something similar to this:

Image


This approach has some noticeable consequences.

Since all checks are run against the same skeleton server side regardless of the shape of the actual model, impacts are sometimes visually hard to predict. This is extremely noticeable with models that are very different from the default humanoid skeleton. For instance, this snipe won't hit:

Image


Client side, the crosshair code uses the skeleton of the actual model you see to tell that you are looking at it. This is why you see my name above the crosshair. The client uses the reelo skeleton, and thinks I'm aiming at it, so it draws the name, but the server uses the common humanoid skeleton for impacts.

As I already mentioned, the trace is dynamically based on animations, so the results also vary based on them: https://i.imgur.com/dySgzMd.gifv
(the red box is the world collision hitbox used when moving around. you can see how the name appears/disappears even on local tracing due to the clothing on top of the skeleton here).

This means that the visual inaccuracy propagates even more when you add animations into the mix. In a dynamic game where all player animations vary greatly, it does have consequences. Most of the time, when an impact location doesn't make sense, you can't just tell what's wrong visually because you don't see what's happening exactly on the server, especially with animations.

On top of that, the problem isn't just about the trace hitting/not hitting the skeleton. For better performance, huge simplifications are done in the trace function, and when the trace actually hits, the impact location is also inaccurate due to huge roundings.

Guess what the Ghoul2 trace results (impact coordinates) are used for?

1. Location based damage, but everyone already figured how shitty that one is.
2. All projectile, missile and hitscan (conc, sniper) impacts, if d_projectileGhoul2Collision is enabled (otherwise, the red hitbox that you saw is used... like in JK2)
3. Saber impacts, if d_saberGhoul2Collision is enabled, otherwise it does a normal box trace
4. Kicks, if d_saberKickTweak is enabled, otherwise it does a normal box trace.
5. Other trivial stuff that does not require too much accuracy.

(I think d_perPlayerGhoul2 also controls whether or not the server uses the common humanoid skeleton for everyone, but don't quote me on that one)

2. Saber Def blocking logic for weapons
  Reveal hidden contents
Here is the slightly simplified but accurate logic that handles projectile blocking:

Run a trace (affected by d_projectileGhoul2Collision).

When a blockable projectile touches the saber blade directly (trace impact ON SABER)...
- if saber def 3 OR jumping/going backwards, reflect it
- if saber def 2, deflect it
- if saber def 1, remove the projectile

When a blockable projectile touches the player model directly (trace impact ON MODEL)...
... AND if the blocking cooldown has expired (see below)
... AND if "we can block" ** (see later)
- if jumping/going backwards (regardless of the level), reflect it but with 350ms cooldown (don't ask me why)
- if saber def 3, reflect it with 50ms cooldown
- if saber def 2, deflect it with 150ms cooldown
- if saber def 1, remove the projectile with 250ms cooldown

That logic is pretty standard, the actual blocking condition ("we can block") will be explained later. Of course, if the projectile hits the saber directly, we don't need to check for the block condition, which is why it's not present. Side note though, there is no blocking cooldown for direct saber hits (I doubt mad spin blocks would be viable though just for the fact that you turn and expose angles that are hittable).

In general I think saber def is pretty balanced against projectiles, which are only really good up close against high saber def. You can't fire faster than these cooldowns, even the 350ms one I think, but two teammates who sync their shots with E11 for instance could easily rape even the 50ms cooldown with some luck (don't forget though that for the cooldown to be applied, the shot actually has to be blocked, so it has to pass the blocking condition explained later, which is not guaranteed against high rate of fire spam).

And the logic for disruptor:

Run a trace (affected by d_projectileGhoul2Collision).

If it hits the player model...
- Dodge if the seeing dodge condition is met. * (see below)
- If not saber def 3, don't block in any case
- If the blocking cooldown has not expired, don't block in any case (!!! same cooldown as with projectiles !!!)
- Block if the blocking condition is met. ** (see later)

Even more simple, same thing for primary and alt fire (the only differences is going through multiple people at once for alt fire). Interestingly though, with disruptor, impact on the saber blade itself is not detected. The saber may as well be off (just like projectile body impacts). It will simply go through. This isn't a behavior that could be easily changed, since you need to have an actual projectile to collide with the blade itself. However, the hilt skeleton is added to the body skeleton when tracing, which means it will effectively block shots. Moreover, the blocking cooldown that is created from projectile blocking is checked here, but not modified at all! This means that two teammates can sync fire with an E11 and a sniper for instance, but not two snipers.

* Force dodge takes precedence over saber blocking. You probably already know the dodging conditions (only seeing 3, not in air, not in an anim, 300ms cooldown). The only notable part is that force dodge always fails on feet and legs and always succeeds elsewhere, which means it is also subject to the impact location error described above.

** See the next section.

3. The blocking conditions
  Reveal hidden contents
Common to body projectile impacts and all sniper impacts that were not force dodged (but also saber vs saber and saber throw), this is what ultimately decides if an impact is going to be blocked.

The list of game conditions is huge and I'm only going to focus on the interesting one. The rest is just common sense (no hand animation, no broken parry, no attack...).

As explained above, body impacts are what trigger this check. How are we going to block a shot that was traced to the body...? Well, Raven opted for a very, very simple approach but which has huge consequences. Instead of using saber position data or something similar, they completely ignore the saber and just fake a saber block in case the check succeeds.

The concept is simple, here's a simple first picture so you can really see what is being compared here:

Image


The square is the world collision hitbox that you saw in the GIF earlier, so imagine a player sitting inside that box. The model origin is always at the bottom center of this hitbox. After an impact point was determined (with questionable accuracy) from the trace, we have a new origin->impact vector that we can use to compute an angle θ with the forward angle vector (the direction we are looking at). The angle is calculated in the X/Y 2D space, so the height of impact doesn't matter (but it doesn't mean that higher ground gives no advantage, since you can hit surfaces more easily, but I will get to to that in a moment).

Here is what a 60 degrees upper arm shot would look like:

Image


You probably guessed it, that "sophisticated check" is just a dot product between the two normalized vectors, which is equivalent to doing a simple angle check. The angle gets wider with higher saber def level. I converted the values to actual angles:

Saber Def 1: 26 degrees
Saber Def 2: 53 degrees
Saber Def 3: 73 degrees if d_saberGhoul2Collision is enabled, 87 degrees otherwise *** (see the very end of the post for more info about this)

If the impact angle is greater than the threshold, the shot won't be blocked, otherwise the player will do a fake saber block animation. Since the player origin never moves within the box, only the impact vector varies. This means that we can draw at all times an effective protected area around the player model (which spans infinitely on the Z axis):

Image


(cyan = 26°, blue = 53°, pink = 73°, dotted green = unused 87°. The vectors were moved downwards so that it reflects reality more despite the perspective the picture was taken at which moved the head down, but it's obviously still not 100% accurate).

I deliberately chose the idle staff stance because I proved several times that even with saber def 3 it's the weakest sniper blocking stance in CTF, so I hope this illustrates it well: almost half the model is vulnerable. You can aim at anything that isn't in range of the area. With saber def 3, lucky headshots are trivial, a large area of the upper right arm is vulnerable, the entire left arm can be hit (that arm is notorious for the "sniping through saber" effect. we demonstrated that it does not matter if you snipe through the blade or not. Just see how easy it is to hit that left arm, the only thing actually blocking you is the hilt).

The area is exactly the same regardless of the shooter's origin. If you are behind them and still hit a part of their body that is in the protected area, it will be blocked. Your positioning when shooting only influences your ability to hit unprotected spots, nothing else. That also means that when defending, your goal is to expose these areas as little as possible. As a rule of thumb, directly facing the opponent is what intuitively works the best, but again that is just a consequence of changing body orientation and it varies with the stances you take (since the skeleton also varies).

It becomes most interesting when you add animations into the mix. And that's where you will really see the link with section 1: the origin doesn't move within the box, the forward direction moves with you and so does the box, so the forward direction also doesn't move in the box's reference. But the positioning of your player model moves inside the box, based on its animation, without moving the origin! Different animations are spaced differently inside the box, yet the area of protection is static: this means that different animations are protected differently.

Just check the staff walk animation: it is already much more protected. The weak areas alternate between the two hands and legs as you walk:

Image


Going through each and every animation in JKA would be a lot of work. You mostly already know the vulnerable ones just by playing for a while. Most jumping animations have the same weak spot near the hand regardless of saber type, for example. The detection system itself is very performance friendly, but when you add the whole variety of animations in the game... it starts not making sense at times. Especially when you can spam primary fire as scout and get lucky hits even w/o perfect aim.

We simply can't check or even control our animation at all times. Combined with somewhat inaccurate impact detection and the difficulty to visually match a model with what is actually being traced server side, this is why saber def looks so random at times.

NB1: as long as the animation doesn't change your camera angle, it doesn't change your view angles server side. For instance the force jump animation that kinda looks like a mid air roll doesn't force you to look anywhere, and thus it doesn't change the protected area. Yet it's easy to kill someone in such an animation because of the exposure of other areas. Other animations like wallruns and katas do change this angle and the protected area therefore varies. Crouch is also a good animation to block because of the reduced exposure (except the foot), but it's rarely useful when you are in the middle of the map going for an objective under scout fire.

NB2: all of this is also true for saber throw and saber vs saber, but with reduced angles.

*** This d_saberGhoul2Collision check is completely out of place. The function has absolutely nothing to do with saber collision, since you have to not collide with a saber in order to get there. This is most likely a derp from Raven: maybe they thought the direct saber hit block w/o cooldown was good enough to justify reducing the radius? Anyway, that cvar is necessary for actual saber gameplay, because it's used in other places, so it shouldn't be toggled just to test wider angles. But if I had to change something, I would remove that random cvar check there which would increase the radius from 73 to 87 degrees and see if that helps. I think that was the original intended behavior before someone moved code around and that check stayed.

Re: Saber Def

2
Proposed changes:

1. Increasing the angle like it was originally intended, as described in my 1st post. Makes it tougher to hit up front (almost 180 degrees protection for the bones in front of the hitbox), but still vulnerable to random hits and animations shifting more surface towards the back of the hitbox, making for easy hits.

OR

2. ONLY FOR DISRUPTOR (keep current behavior for projectiles): Instead of calculating the angle between the defender's view direction and impact direction, calculate it between the defender's view direction versus attacker's view direction. Keep the different angles for saber def levels (possibly adjust them too). Don't even do an inaccurate Ghoul2 trace, just compare both players' angles and have a 100% block rate when facing in range of the threshold / 0% block rate when outside of it. This is the behavior one would expect from saber def imo. Look at the guy, block the shot, look away and get shot. Still vulnerable to multi scout crossfire. Maybe more skill depth for jedi who will have to control their angles/play in the open instead of perma hiding from scout/doing w/e b/c they know they would get randomly shot. With this system, lower saber def levels could either keep their zero sniper block behavior, or have a very small angle that would increase low saber def playability vs scout (you could for example have a saber def 1 angle that makes it so that you have to basically perma lock your crosshair on the enemy scout to block snipes). However primary disruptor spam against jedi who are actively looking in your direction won't yield any lucky hit.


I'm personnally cool with 2. But keep in mind any change will affect gameplay for all maps with sabers, regardless of def level.

Also, changing the fact that all models use the same trace skeleton would impact gameplay too much imo (fat models would be easier to hit, breaks forced client models...), so I didn't propose any change in that regard.

Re: Saber Def

3
First of all, thank you for the detailed post, I think it does a great job at explaining how blocking is determined. Especially since lately I have been pretty annoyed by getting sniped through saber def 3 (hence the quote). If sniping through saber was an issue in CTF, it is an even bigger issue in siege, where you have a class dedicated to primarily using disruptor, and being able to one shot jedi with it.

I think what bothers me most about disruptor, is the fact that your saber is irrelevant. Common sense dictates there is no way the left hand would be hit through the blade, and yet it does. I definitely think this should not be the case, and would like to express my interest at changing the way this system works.

Alpha mentioned 2 options, and I will be happier if either of them gets implemented. However, I think we should definitely go for the second option. Really, facing your opponent should be the logical defense against it.
alpha wrote: This is the behavior one would expect from saber def imo. Look at the guy, block the shot, look away and get shot. Still vulnerable to multi scout crossfire.
Really, just thinking about it got me really excited. It would make saber def 2 not utterly useless. Even saber def 1 could be useful. Right now you either have saber def 3 or scout will delete you if he can aim. There is zero difference between not having saber def and having saber def 2 as long as scouts can one shot jedi.

I understand that such a huge change might change the dynamics of how siege works, but I think it would move siege forward. Yes, I imagine class balance would have to be revisited on most of the maps we play, but it is well worth the effort, if it brings consistency, in my opinion. It could bring an era where instead of praying to rng gods, you would have a consistent method of blocking.

So yeah, I am voting for the second option, and I hope to see it implemented!

Re: Saber Def

4
Well, if we're going to implement it we should do that for all projectiles, not only for disruptor (second option). Like alpha said, any change will affect gameplay for all maps with sabers, regardless of def level.

Jedi is very fast and has great attack and maneuverability so when I usually play against him I always expect I'll one shot him (aiming at his foot, arm, etc.). With this change all saber classes will have an advantage over any sniper. For example: your teammate decides to play scout to counter non-jedi classes but he has no luck because now enemy team has 2 or 3 jedis, so all you can do is start praying to not lose the objective. If we really want to use this change we should also change
g_delayClassUpdate
(instantly broadcast class changes) to avoid such a scene I mentioned above.

Re: Saber Def

5
dem0n wrote: Thu Jun 14, 2018 2:00 am Well, if we're going to implement it we should do that for all projectiles, not only for disruptor (second option). Like alpha said, any change will affect gameplay for all maps with sabers, regardless of def level.
Why though? I think the way they currently work is fine, there are no issues of projectiles bypassing saber for no reason. Actually, coming to think about it, would there be any difference between the suggested rework, and the current one for projectiles? Looking at the idle staff stance it looks to me that all the vulnerable spots against disruptor are protected by the blade against projectiles.

dem0n wrote: Jedi is very fast and has great attack and maneuverability so when I usually play against him I always expect I'll one shot him (aiming at his foot, arm, etc.).
I think this in itself is the very problem. I'm going to go ahead and make an assumption, but I'm pretty sure if a mapmaker gives a jedi class saber def 3, he does not want the class to die against scout. And, at least to me, when someone manages to hit a spot unprotected by saber defence, it doesn't feel like I was outplayed. It feels game randomly decided my lightsaber is not worth a thing, and thus condemned me to death.

dem0n wrote: For example: your teammate decides to play scout to counter non-jedi classes but he has no luck because now enemy team has 2 or 3 jedis, so all you can do is start praying to not lose the objective.

Right now if your teammate is playing scout against jedi, he is already very likely to be yelled at by duo. I don't really see how this would change anything, apart from removing the rng factor from the game. Just imagine if the scout manages to hit the unprotected areas on both jedi, and thus save the objective. The team with the 2 jedi are being punished here, they did everything right, they brought a counter class to scout, and yet instead of being rewarded for actual counterplay, they died all the same. This should not be the case in my opinion.

dem0n wrote: If we really want to use this change we should also change
g_delayClassUpdate
(instantly broadcast class changes) to avoid such a scene I mentioned above.

I'm not sure. All this would accomplish is people would frantically spam class changes while waiting for respawn, and whoever gets lucky gets to counter the enemy team. I think we should never change it back to what it was.

Re: Saber Def

6
Very nice work. I agree with everything Onasi has written in this thread. I also completely disagree with everything Sith has written and agree with Onasi's response to Sith.

The #2 method sounds good to me. I think you could make it as Alpha proposed, where def 1 would only block the shot if you are highly accurately locked onto the shooter with your crosshair. How would this impact existing classes? Let's see:

Hoth:
  • Offense: Def 3 - Removes bullshit "RNG hits". 👍🏿
  • Defense: Def 1 - Allows a small amount of saber block if you are perfectly aiming at the lando. Increases skill cap. I don't think it would affect the class that much really, because while attacking the walker you are vulnerable, and indoors you would have to not be attacking and be perfectly locked onto the scout to block. 👍🏿
Nar:
  • Offense: Def 3 - Removes bullshit "RNG hits". 👍🏿
  • Defense: Def 3 - Adds improved blocking against offense landos. When I made this map in 2010, I originally intended this class as a counter against offense lando, and was really annoyed at how you could seemingly randomly get hit through def 3. I wanted the class to have staff stance, so I never changed it to any other stance; I was just left with seemingly RNG blocking. The change actually makes D jedi more like what I originally envisioned this class to be -- an offense scout counter. And this is a good thing because currently there is no offense scout counter. 👍🏿
Cargo:
  • Offense: Def 3 - Removes bullshit "RNG hits". 👍🏿
  • Defense: Def 3 - Removes bullshit "RNG hits". 👍🏿
Urban:
  • Offense: Def 3 - Removes bullshit "RNG hits". 👍🏿
  • Defense: Def 3 - See note above about Nar D Jedi. 👍🏿
Bespin:
  • Offense: Def 3 - Removes bullshit "RNG hits". 👍🏿
  • Defense: Def 1 - This class is shit-tier right now. See note above about Hoth D Jedi; I think it's definitely an improvement. 👍🏿



So essentially:
  • Def 1 classes: these guys can now have a small amount of block if they are perfectly aiming at the attacker. 👍🏿
  • Def 2 classes: The only classes with def 2 that I am aware of are Korriban classes, so none of this matters for that. In fact, the proposed change would essentially create a new def 2 option since it doesn't really exist at the moment on guns maps; mapmakers have always just used 1 or 3 due to disruptor. This allows for more variety in siege classes moving forward. 👍🏿
  • Def 3 classes: As Onasi wrote, "I'm pretty sure if a mapmaker gives a jedi class saber def 3, he does not want the class to die against scout" - def 3 guys still have basically the same blocking ability but without bullshit "RNG hits", and staff is no longer a shittier saber block than the other stances even when it has def 3. Also worth noting, this similarly fixes the bullshit "RNG blocks" whereby you can block a disrupt in the back even though it clearly should have damaged you, e.g. on hoth 2nd obj rush. 👍🏿

I think the idea is excellent. I see no downsides, and I vote to implement it.

Re: Saber Def

10
Dup wrote:Very nice work. I agree with everything Onasi has written in this thread. I also completely disagree with everything Sith has written and agree with Onasi's response to Sith.
What a time to be Onasi.

So if I've got this correct you can change it so that if a Jedi is facing within x degrees of scout block will be 100% (no weakspots) and 0% outside of these angles?

This to me is how saber defence should be. Following this for example saber def 1 can be 10 degrees, def 2 can be 90 degrees, and def 3 can be 160 degrees (random figures which sound about right)?

It's odd actually I've always found staff to be the hardest to shoot through (it's probably me aiming at the wrong places).
cron