Closed
Conversation
…ements fail
Stop combat swing execution when Magic.castSpell fails due to missing requirements.
Also clear transient spell flags ("spell", "one_time", and "autocast") in failure
paths to prevent follow-up clicks from inheriting stale cast state.
- Add CombatSpellsOnPlayer to handle interface spell clicks via ItemOnPlayerInteract - Route spell interactions through approach system using wildcard handler - Dynamically resolve spell names from interface definitions using cast_id - Support modern (192), ancient (193), lunar (430) spellbooks - Remove redundant isMagicSpell check from Interact tick loop
- End ItemOnPlayerInteract after initial cast to transfer to Combat mode - Removes updateInteraction that reset launched flag and re-pathed - Manual casts now behave like autocast: approach once, stand at range - Prevents step-forward on each spell click
- Add source parameter to multiTargets() to filter out attacker - Prevents ice barrage/burst from hitting self in multi when adjacent to target - Updates spell handler to pass caster reference
- Remove one_time assignment in CombatSpellsOnPlayer
- Reject Walk packets when movement_delay clock is active and show "magical force" message
- Add early return in Movement.tick() to clear steps and skip calculate/step when frozen
- Use hasClock("movement_delay") in engine to avoid game-module dependency
- Fixes object/NPC clicks still pathing during freeze (e.g., trees, doors)
Refs: Freeze effect, PlayerOnObjectInteract
Owner
|
Also closing for #959 the issue was more that |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Players could still walk to trees, NPCs, and other interactables while under the freeze effect. Walk packets were blocked, but object/NPC interactions queued a new path on the next tick because the engine
Movementnever checked the freeze timer.This PR makes freeze authoritative in the engine and blocks it at the input layer.
Changes
content/entity/Movement.kt
instruction<Walk>whenhasClock("movement_delay")is trueengine/.../mode/move/Movement.kt
tick()if (character.hasClock("movement_delay")) { character.steps.clear(); return }get("movement_delay", -5)) which never fired because freeze uses a clock, not a varnoCollisionbypass) – matches 2009-2011 behaviourWhy hasClock?
Freezestartsmovement_delayas a clock, not a variable. The engine cannot depend on the game-moduleplayer.frozenextension, so we check the clock directly. This keeps engine ↔ game separation clean.Testing
::freeze 20on selfNo regressions to forced movement (cutscenes/teleports use
noCollisionsteps but are also cleared – intentional, freeze should override player-controlled forced walks).Closes the last known freeze bypass.