[POC] Weapon abilities #436

ImplementsLegend · 2025-10-28T15:39:12Z

POC Weapon abilities

Added MainAttackTrigger

Whenever there's any action registered to this trigger regular attack and breaking blocks become unavailable. It is triggered on repeat when attack is held.

Removed Invulnerability Timer

I belive that negatives of this feature highly outweight any positives. Removing it allows:

Attacking faster than 2 attacks per second.
Multiple projectiles hitting same enemy simultaneously.
An entity to be attacked by multiple other entities. That can be multiple players fighting a boss or a player surrounded by a horde of mobs.

Added abilities for Weapon attacks

"Sword": a chain ability of 3 attacks - 2 wide attacks followed by 1 narrower but higher range and damage attack. This is implicit on all swords.
"Dagger": a chain ability of 5 attacks - 4 wide attacks followed by 1 narrower but higher range and damage attack. Faster but lower damage and range than sword.
"Katana": a chain ability of 3 attacks - initial attack with large area and damege followed by 2 fast attacks. The strong initial attack won't be available until you stop attacking, looping the two weaker attacks.
"Spear": single attack - Slow but high damage, narrow but high range.

Other changes

Added some placeholder particles to visualize the different attacks.

Improved SphereShape to detect any intersection with entity hitbox instead of just checking the entity origin.

DamageEffect now correctly applies knockback. (closes #384)

Added option to configure damage attribute of DamageEffect.

Added requirements to chain ability entry, these requirements are applied to the chain ability instead of individual subabilities.

Added next to chain ability entry, it is IntProvider that determines the index of next ability to be activated. (mostly closes #367)

Various improvements for cooldowns.

Added FieldOfViewTargeting.

Added OffsetTargeting that moves position where ability effect happens. (closes #502)

Added more configuration options to ParticleEffect. (closes #505)

Reduced default attack speed.

Added SwingHandAnimation - ability effect that effectively runs /swing command

Removed Minecraft's implicits on swords.

Future work

Ability AnimationEffect - would be pretty nice to have custom animations for individual attacks.

More weapon types. (this should include custom mace and trident)

A trigger that would replace right-click.

Improve modifier display.

Make sure all targetings can target blocks and add a way to attack blocks

entities are now knocked back away from ability source

feat: implicit definitions for swords

feat: added OffsetTargeting

…ead of int

immortius · 2025-11-01T03:39:13Z

I think you should raise a discussion on the discord around some of these changes, particular the invulnerability change. I don't disagree with it, but I think it is the sort of thing that should be brought to the group.

immortius

Some thoughts. I'm particular curious about the purpose of cooldown margin.

src/main/java/com/wanderersoftherift/wotr/abilities/ChainAbility.java

src/main/java/com/wanderersoftherift/wotr/abilities/attachment/AbilityCooldowns.java

immortius · 2025-11-01T04:44:45Z

src/main/java/com/wanderersoftherift/wotr/abilities/requirement/CooldownCost.java

 import com.wanderersoftherift.wotr.modifier.effect.ModifierEffect;

-public record CooldownCost(int ticks) implements AbilityRequirement {
+public record CooldownCost(int ticks, int milliticks, int margin) implements AbilityRequirement {


Perhaps ticks and margin should be a floats. It is a little inconsistent. Not very fussed. Maybe we should change it to milliseconds or seconds for that matter.
Margin is a little odd. I see you have skills with a margin of 3000 for a 9 tick cooldown which is 33% of the range. I'm not 100% on the issue that the margin is solving, is it a network or early input issue? Another option would be a queuing system where an activation can be made early and will be saved until the cooldown is over perhaps?

The issue I intended to solve with margins is that when you have cooldown of 10 ticks and you get 9% cooldown reduction it won't even make a single tick of difference. That is equivalent to having no cooldown reduction at all. The margin allows activating the ability little early, but the remaining cooldown will get added to the next activation. That way even difference of less than tick can have some effect over multiple activations.

The original intention was to have it always be one tick, but that wasn't very practical. Even Minecraft's internal latency is large-enough that when Client realizes attack is possible, cooldown already fully expired on server. That would probably be even worse on remote server, so for attacking I'm now considering different activation method - client would only send "start atttack"/"stop attack" and server would be responsible for timing. Also for manually activated abilities (or by some normal triggers) it's basically impossible to hit a 1-tick window.

Also I guess it is functionally equivalent to the concept of charge cost I mentioned in the discord ability implementation thread - having margin 2*cooldown would give you 2 extra "charges" on the ability.

immortius · 2025-11-01T04:49:49Z

src/main/java/com/wanderersoftherift/wotr/abilities/attachment/AbilityCooldowns.java

        cooldowns = new LinkedHashMap<>();
        if (data != null && holder instanceof Entity entity) {
-            long gameTime = entity.level().getGameTime();
+            long gameTime = getGameTime() * 1000;


I'm not very convinced there is value in tracking at the subtick level, as opposed to rounding up the cooldown time, though this ties into the question around margin below.

src/main/java/com/wanderersoftherift/wotr/abilities/targeting/OffsetTargeting.java

src/main/java/com/wanderersoftherift/wotr/abilities/targeting/shape/SphereShape.java

immortius · 2025-11-01T08:01:26Z

src/main/java/com/wanderersoftherift/wotr/network/ability/AbilityTriggerablePayload.java

+        return TYPE;
+    }
+
+    public void handleOnClient(IPayloadContext context) {


So, what happens if the player changes item to a weapon with a main attack trigger and attacks before this payload arrives?

Well, I assume this will be covered by #180. Presumably the answer is ensuring the client has enough information to set this up client-side without needing to be told by the server (assuming the involved data components are replicated).

I guess that lets the normal attack through, huh? Should I test whether to override the attack in some other way, then? Or maybe stop the regular attack on server...

Mmm, there's probably not a perfect answer. I guess there could be a specific check client-side for the weapon giving a main attack trigger, since if the main attack trigger comes from somewhere else it won't have the same item switching issue (or it is much more unlikely at least). And yeah, otherwise having the server check for and remove the regular attack.

src/main/java/com/wanderersoftherift/wotr/abilities/effects/ParticleEffect.java

…ckOverrideTrigger # Conflicts: # src/main/resources/wotr.mixins.json

updated FieldOfViewTargeting javadoc

refactor: replace OffsetTargeting.x y z with Vec3

Replaced distribution_x, distribution_y, distribution_z with single distribution field Made distribution, speed, count optional

…ty activation

WarrenGore · 2025-12-08T03:27:02Z

Per discussions in design meeting/forum post, we should move forward with the invulnerability change and see how it feels in practice. May lead to future abilities/game settings relating to damage reduction/OHKO protection.

mal0ki · 2025-12-09T22:23:05Z

I just playtested this, and it feels very nice. It significantly improved the pacing in the rift.

…ckOverrideTrigger

feat: weapon abilities now use attack damage

…k speed

… attacks

immortius

Just a couple of small comments, otherwise looks good to me. Maybe a couple of issues to pull out for future work from the original review.

immortius · 2026-01-07T04:31:45Z

src/main/java/com/wanderersoftherift/wotr/abilities/attachment/AbilityRepeater.java

+            tracker.trigger(triggerType.value().clientTriggerInstance());
+            return !tracker.hasListenersOnTrigger(triggerType);
+        });
+        triggersToRepeat.forEach(triggerType -> tracker.trigger(triggerType.value().clientTriggerInstance()));


Is this triggering the triggers twice, since it also happens on line 61?

immortius · 2026-01-07T04:52:07Z

src/main/java/com/wanderersoftherift/wotr/abilities/requirement/CooldownCost.java

+
+    public enum CooldownMode implements StringRepresentable {
+        NORMAL("normal"),
+        INVERTED("inverted");


Could use a touch of doco on what the inverted cooldown mode means and when it is intended to be used. I assume it is for when the associated attribute increases to reduces cooldown time.

immortius · 2026-01-07T05:28:35Z

src/main/java/com/wanderersoftherift/wotr/client/MainAttackHandler.java

+
+    private static boolean shouldUseOverrideAttackNew(Player player) {
+        var result = new Ref<>(false);
+        Arrays.stream(EquipmentSlot.values()).forEach(slot -> {


anyMatch might be better than forEach here.

Potentially could flat map from EquipmentSlot -> modifierHolder -> modifier and then for each and generally flatten the stream processing that way.

immortius · 2026-01-07T05:34:21Z

src/main/java/com/wanderersoftherift/wotr/mixin/MixinAttributes.java

+    @Redirect(method = "<clinit>", at = @At(value = "NEW", target = "(Ljava/lang/String;DDD)Lnet/minecraft/world/entity/ai/attributes/RangedAttribute;"))
+    private static RangedAttribute redirect(String descriptionId, double defaultValue, double min, double max) {
+        if ("attribute.name.attack_speed".equals(descriptionId)) {
+            return new RangedAttribute(descriptionId, 1.0, min, max);


Would be good to capture a comment for why we're overriding the default. I assume it is because by default it is the time of the attack but we're using it as a modifier on the time defined in the attack ability?

ImplementsLegend added 14 commits October 24, 2025 18:25

Feat: Ability as main attack

de85633

wip first attack replacement

36ee89f

feat: can now attack continuously, basic sword attack

ffb09ce

feat: FOV targeting, improved Sphere targeting shape

ed5ffd7

fix: #384

ba33155

entities are now knocked back away from ability source

vanilla override: removed I-frames

7361087

feat: implicit definitions for swords

feat: added more options to ParticleEffect

750f97d

feat: added OffsetTargeting

feat: new particles

9bb62d2

feat: added another weapon config

857c1d2

feat: added even more weapon configs

d967bd8

feat: random chain ability progression

e0be327

refactor: changed ClientTriggerTriggerPayload to use TriggerType inst…

bc8fd7a

…ead of int

feat: millitick ability cooldowns

c36ec72

fix: FieldOfViewTargeting now better respects range

0a0a292

ImplementsLegend changed the title ~~Implements legend/attack override trigger~~ [POC] Weapon abilities Oct 28, 2025

ImplementsLegend linked an issue Oct 28, 2025 that may be closed by this pull request

Weapon Abilities #304

Open

immortius reviewed Nov 1, 2025

View reviewed changes

ImplementsLegend added 6 commits November 1, 2025 18:54

Merge remote-tracking branch 'origin/main' into ImplementsLegend/Atta…

229df4e

…ckOverrideTrigger # Conflicts: # src/main/resources/wotr.mixins.json

fix: FieldOfViewTargeting range limiting now excludes entities

7e3cf10

updated FieldOfViewTargeting javadoc

added javadoc to OffsetTargeting

09e4edc

refactor: replace OffsetTargeting.x y z with Vec3

refactor: changed ParticleEffect json format

240372a

Replaced distribution_x, distribution_y, distribution_z with single distribution field Made distribution, speed, count optional

refactor: added overload for AbilityCooldowns.isOnCooldown

70476c6

refactor: moved chain ability requirement consumption before subabili…

3454c5b

…ty activation

ImplementsLegend marked this pull request as draft November 6, 2025 15:25

ImplementsLegend added 3 commits December 14, 2025 11:51

Merge remote-tracking branch 'origin/main' into ImplementsLegend/Atta…

42e6b09

…ckOverrideTrigger

fix: corrected some math in OffsetTargeting

989fd89

feat: removed minecraft's implicits from swords

0c09ce5

feat: weapon abilities now use attack damage

ImplementsLegend added 9 commits December 15, 2025 18:30

feat: weapon ability cooldowns now use attack speed

4b4ec0f

refactor: FieldOfViewTargeting now uses degrees instead of cosine

a4a7481

feat: added SwingHandAnimation ability effect

f648e4d

feat: adjusted attack speed of tools to account for new default attac…

de18eb4

…k speed

feat: reworked how client notifies server of performing ability-based…

6a18ac5

… attacks

fix: adapt cooldown rendering to the modified cooldowns

a5e8e57

reduced attack cooldown margins to 1 tick

4a50bdd

fix: removed accidental commit

e1e358e

added altered golden sword

e6e05df

WarrenGore marked this pull request as ready for review January 3, 2026 21:32

immortius reviewed Jan 7, 2026

View reviewed changes

[POC] Weapon abilities #436

Are you sure you want to change the base?

[POC] Weapon abilities #436

Uh oh!

Conversation

ImplementsLegend commented Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

POC Weapon abilities

Added MainAttackTrigger

Removed Invulnerability Timer

Added abilities for Weapon attacks

Other changes

Future work

Uh oh!

immortius commented Nov 1, 2025

Uh oh!

immortius left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

WarrenGore commented Dec 8, 2025

Uh oh!

mal0ki commented Dec 9, 2025

Uh oh!

immortius left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

ImplementsLegend commented Oct 28, 2025 •

edited

Loading