Blatant rage about 2h facehugging uber power

[FRANK_THE_TANK]

I know that. He killed me and then fired it up again and hit the noob he was aiming for.

I did say, "pretty much", not "he one shoted 10 people and a horse. It was like Rambo OMG OMG"

:{p

[San]

I said it before and I'll say it again: Fix the 1h swing animation collision detection. It's easier to out-footwork 1h swings than 2h/pole anyways.

[MouthnHoof]

It is not the collision detection. The mechanics are the same for all weapons. The difference is in the animation and the absolute length of the weapon.

Regarding the animation: the game considers the weapon and a straight line coming out of the right fist with length equal to the "reach" stat. Depending on the animation, you can have your fist inside the target before the rest of the blade hits. This is bound to happen if in the animation the wrist rotates, so effectively in the early stages the hilt is traveling before the tip, which catches up later. The system will register a "0" distance hit (from your fist).

With 2H animations, the orientation of the blade during the swing is such that it rotates less than the 1H blade. The 1H animation chamber position really pulls it behind you back. Compare for example  the right swing -  in 1H you start with the blade tip pointing nearly backward and the hilt travels in front of the blade. Not so much with 2H. Also the overhead - in 1H you start with the blade so far behind your shoulder that a short range hit is like hammering the opponent with your fist which the blade is in the opposite direction.

Regarding the absolute length: the game modifies the damage depending on the relative values of the "reach" parameter and the distance of the hit detection from the fist. With short weapons, every cm makes a much bigger difference. Since there is also some discretization in the hit detection it is very likely that with short weapons it will produce extreme readings, meaning many hits will register as 0 range hits (hand inside the opponent mesh), but fluctuations to the other side do not truncate to full range hits, they just become misses. short weapons become increasingly sensitive to this and daggers in particular are terrible because of this.

TL;DR
Not much can be done, unless the modders can mess with how damage is modified according to the hit detection distance. If they can, the variation in damage as a function of the relative distance along the blade (0--100%) should scale less as the weapon is shorter (i.e. smaller difference in damage between 0 and 100% of the reach). Dagger length weapons should not be affected by this mechanism at all.

[Vibe]

Not much can be done, unless the modders can mess with how damage is modified according to the hit detection distance. If they can, the variation in damage as a function of the relative distance along the blade (0--100%) should scale less as the weapon is shorter (i.e. smaller difference in damage between 0 and 100% of the reach). Dagger length weapons should not be affected by this mechanism at all.

Don't worry, just PM cmp and he will get it done in a day or two.

[Paul]

Well, by default the 1h, 2h and pole share the same sweetspot bounds.

(click to show/hide)

Code: [Select]

   def get_sweet_spot_factor(deliverer_agent_no, receiver_agent_no):
            if deliverer_agent_no < 0 || agents[deliverer_agent_no].is_couching():
                    return 1.0
     
            attack_direction = agents[deliverer_agent_no].attack_rec.direction
     
            if attack_direction == at_overhead:
                    anim_progress = agents[deliverer_agent_no].action_channels[1].progress
                    sweetspot_lower_bound = 0.3
                    sweetspot_upper_bound = 0.9
                    sweetspot_optimal_upper_bound = 1.0
                    sweetspot_optimal_lower_bound = 0.45
            elif attack_direction == at_thrust:
                    anim_progress = agents[deliverer_agent_no].action_channels[1].progress
                    sweetspot_lower_bound = 0.3
                    sweetspot_upper_bound = 0.85
                    sweetspot_optimal_upper_bound = 0.7
                    sweetspot_optimal_lower_bound = 0.45
            else if agents[deliverer_agent_no].horse_agent_no < 0 and receiver_agent_no >= 0:
                    pos_diff_vec = (agents[deliverer_agent_no].position - agents[receiver_agent_no].position).vec2().normalize()
                    anim_progress = pos_diff_vec.dot(agents[deliverer_agent_no].movement_dir.vec2())
                    sweetspot_lower_bound = 0.05
                    sweetspot_upper_bound = 0.9
                    sweetspot_optimal_upper_bound = 1.0
                    sweetspot_optimal_lower_bound = 0.55
            else:
                    anim_progress = agents[deliverer_agent_no].action_channels[1].progress
                    sweetspot_lower_bound = 0.2
                    sweetspot_upper_bound = 0.9
                    sweetspot_optimal_upper_bound = 0.7
                    sweetspot_optimal_lower_bound = 0.45
     
            if anim_progress <= sweetspot_lower_bound:
                    return 0.0
     
            if anim_progress <= sweetspot_optimal_lower_bound:
                    return clamp((anim_progress - sweetspot_lower_bound) / (sweetspot_optimal_lower_bound - sweetspot_lower_bound), 0.0, 1.0)
     
            if anim_progress >= sweetspot_optimal_upper_bound:
                    return clamp((anim_progress - sweetspot_upper_bound) / (sweetspot_optimal_upper_bound - sweetspot_upper_bound), 0.0, 1.0)
     
            return 1.0

Could be split so 1h gets a less bitchy stab but that would need some work to get it done correctly. But cmp lazy and me too.

[Vibe]

This is me not knowning the whole code but

couldn't you just make a duplicate function with different sweetspot values and use it only for 1h? Or is it a bit more complicated than that?

[Tomas_of_Miles]

What language is that? Python?

[Vibe]

What language is that? Python?

Yes, that is Python.

[Paul]

It's easy to do coding wise. It's just difficult to balance it correctly and once 1h gets softer bounds, 2h and polearm will cry rivers.

[Vibe]

It's easy to do coding wise. It's just difficult to balance it correctly and once 1h gets softer bounds, 2h and polearm will cry rivers.

I'm a 2h and I won't cry rivers. 1h deservers a better stab.

I promise

[Xant]

It's easy to do coding wise. It's just difficult to balance it correctly and once 1h gets softer bounds, 2h and polearm will cry rivers.

Have tears stopped you before?

[MouthnHoof]

Well, by default the 1h, 2h and pole share the same sweetspot bounds.

(click to show/hide)

Code: [Select]

   def get_sweet_spot_factor(deliverer_agent_no, receiver_agent_no):
            if deliverer_agent_no < 0 || agents[deliverer_agent_no].is_couching():
                    return 1.0
     
            attack_direction = agents[deliverer_agent_no].attack_rec.direction
     
            if attack_direction == at_overhead:
                    anim_progress = agents[deliverer_agent_no].action_channels[1].progress
                    sweetspot_lower_bound = 0.3
                    sweetspot_upper_bound = 0.9
                    sweetspot_optimal_upper_bound = 1.0
                    sweetspot_optimal_lower_bound = 0.45
            elif attack_direction == at_thrust:
                    anim_progress = agents[deliverer_agent_no].action_channels[1].progress
                    sweetspot_lower_bound = 0.3
                    sweetspot_upper_bound = 0.85
                    sweetspot_optimal_upper_bound = 0.7
                    sweetspot_optimal_lower_bound = 0.45
            else if agents[deliverer_agent_no].horse_agent_no < 0 and receiver_agent_no >= 0:
                    pos_diff_vec = (agents[deliverer_agent_no].position - agents[receiver_agent_no].position).vec2().normalize()
                    anim_progress = pos_diff_vec.dot(agents[deliverer_agent_no].movement_dir.vec2())
                    sweetspot_lower_bound = 0.05
                    sweetspot_upper_bound = 0.9
                    sweetspot_optimal_upper_bound = 1.0
                    sweetspot_optimal_lower_bound = 0.55
            else:
                    anim_progress = agents[deliverer_agent_no].action_channels[1].progress
                    sweetspot_lower_bound = 0.2
                    sweetspot_upper_bound = 0.9
                    sweetspot_optimal_upper_bound = 0.7
                    sweetspot_optimal_lower_bound = 0.45
     
            if anim_progress <= sweetspot_lower_bound:
                    return 0.0
     
            if anim_progress <= sweetspot_optimal_lower_bound:
                    return clamp((anim_progress - sweetspot_lower_bound) / (sweetspot_optimal_lower_bound - sweetspot_lower_bound), 0.0, 1.0)
     
            if anim_progress >= sweetspot_optimal_upper_bound:
                    return clamp((anim_progress - sweetspot_upper_bound) / (sweetspot_optimal_upper_bound - sweetspot_upper_bound), 0.0, 1.0)
     
            return 1.0

Could be split so 1h gets a less bitchy stab but that would need some work to get it done correctly. But cmp lazy and me too.

Isn't this determining the factor due to the stage of the animation during which the hit was detected (using anim_progress)? I was talking about the modification due to the distance to the hit relative to the length of the weapon (hilt vs. tip).

[Paul]

Well, that is basicly how the illusion of length dependency is done. A facehug stab hits early, thus at the beginning of the animation and receives the penalty for being at the lower bound. There is no special length check.

[Zisa]

fuck that shit...
Fix the waggly stab nonsense if you are going to play with the stabs. please.

[ThePoopy]

1h have allready been buffed enough just cus majority of 1handers sux, theres nothing wrong with the stab, if u actually hit the target...