Why Attacks Stop Movement

In the current public Demo baseline, stopping briefly when you attack appears to be part of the behavior players can encounter, not something you should assume a settings toggle will remove. Prologue players have reported that the character pauses in place on each attack. A community reply described a more specific bow case in which one arrow fires, a second attack input enters the queue, and both attacks finish before movement or a dodge can interrupt the second shot.

Those are specific prologue observations. They do not establish that every weapon, combo, class, or future build uses the same commitment rules. It also does not confirm a universal animation-cancel technique. Treat the steps below as a way to identify your exact case, reduce accidental queued attacks, and collect a clean reproduction if the character remains locked longer than the attack sequence you actually entered.

Read the behavior in the correct version context

As of October 28, 2026, this guide applies to public Demo Alpha 0.20.18.x. Early Access remained unreleased and was scheduled for January 7, 2027. An announced bow-combat rework had not been delivered in this baseline, so planned behavior is not evidence of what the Demo currently lets you cancel, steer, or dodge out of.

The reported behavior has two parts: a prologue player reported pausing in place with each attack, and a reply reported that a second bow input could be queued before movement or dodge could interrupt it. It does not confirm exact recovery times, button mappings, a continuous-movement setting, or a complete list of cancellable moves. If your result differs, record the difference instead of forcing it into the bow example.

First identify the kind of movement lock

Do not begin by changing several options or rapidly pressing more actions. First describe what the character actually does. The important distinction is whether movement returns after the one attack you intended, after an extra queued attack, or not at all.

The weapon mastery screen can help you document which weapon context you were using. Use it as a record, not as proof that a listed entry has a particular cancel rule unless the current interface explicitly says so.

Record the weapon category before comparing movement and attack inputs. Preview bindings may differ from your build.

Run a controlled input test

A controlled test is more useful than repeatedly trying the same fight. Change one input at a time so you can separate a single committed attack from a queued follow-up.

1. Move to a safe area where an enemy is not forcing immediate reactions. Keep the same weapon, class, and equipment.
2. Confirm ordinary movement responds before starting.
3. Press attack once, release it, and do not dodge. Note when movement responds again.
4. Reset and repeat, but enter a second attack input before the first action clearly completes. Watch for a second attack that plays without another press afterward.
5. On separate attempts, try to dodge after the visible attack and during it. Compare the outcomes instead of guessing an intended cancel window.
6. Repeat without changing the loadout. If the result varies, write down the exact input order.

This does not reveal an internal buffer duration. It shows whether a second press changes the visible sequence. If one press produces one attack and two presses reliably produce two before movement returns, accidental queuing is more plausible than a permanent movement failure.

Open the current Wanderer class menu and note the selected class. The image preserves context, but it cannot prove unshown inheritance rules or undocumented class-specific cancellation.

Handle the reported bow queue deliberately

If your bow result matches the reported bow case, the practical adjustment is input discipline. Enter one attack, observe its completion, then choose the next action. Avoid pressing attack again merely because the first arrow has not yet produced the response you expected. In the reported case, that second press was not harmless; it committed the character to another arrow before a dodge could take priority.

Use this sequence as a diagnostic and a temporary play adjustment:

• Establish distance before attacking rather than planning to create distance during the shot.
• Enter one attack input and keep the attack control released.
• Watch for the point at which directional movement responds again.
• Reposition first if the next enemy action makes a dodge likely.
• Only enter another attack after deciding that you can accept another committed action.
• If two attacks still occur from one clear press, record that separately because it does not match the described two-input queue.

These are suggestions derived from the observed queue behavior, not a proven universal fix. They may reduce unintended second shots, but careful timing is not confirmed to enable free movement during the shot itself. Dodge is also not confirmed to override every attack at every point.

Compare the same sequence across controlled conditions

After you have a stable one-input and two-input result, change only one condition and repeat the exact sequence. You might compare another weapon context, another class context already available to you, or another input device you already use. The purpose is not to declare one option faster. It is to learn whether the lock follows the input sequence or appears only in one reproducible setup.

Record the equipment screen before changing the loadout. It preserves visible items and stats for comparison. Do not assume that a displayed stat controls movement recovery or cancel timing; the available Demo information establishes no such relationship.

Use your own current loadout as the test record; these preview values are not a recommended build.

Keep a short log with the Demo version, class, weapon, equipment, input device, exact order of inputs, number of attacks played, and point at which movement returned. Note whether the result also reproduces away from combat. This prevents you from changing weapon, class, gear, location, and timing together and then crediting the most obvious change.

Separate attack commitment from a possible input problem

A brief attack pause and the reported bow queue can explain bounded interruptions, but longer or inconsistent loss of control needs a separate check. Use the visible end of the action as your dividing line.

If movement returns as soon as the single attack finishes, you have reproduced a bounded attack commitment. If two deliberate attack inputs produce two attacks before movement returns, you have reproduced behavior consistent with the reported queue. Neither result proves that the design is ideal, but both give you a predictable sequence you can play around.

A different category begins when the character remains unable to move after the visible sequence is over, one press repeatedly produces extra attacks, or the same input order produces inconsistent lockups from the same clean setup. Those symptoms are not confirmed bugs by the Demo reports, but they are reasons to preserve a reproduction instead of assuming the known bow explanation covers them.

Before labeling the result, also check whether ordinary movement works when no attack has been entered. If movement already fails outside the attack sequence, the attack queue is not enough to explain it. Keep that case separate from “movement pauses while attacking” so a report does not combine two potentially different problems.

Avoid unsupported fixes and assumptions

Several tempting explanations remain unconfirmed for Demo Alpha 0.20.18.x. Avoid building your troubleshooting around them.

• Do not assume there is an undiscovered setting that enables continuous movement during attacks. None is confirmed here.
• Do not assume a precise cancel window exists just because another action game uses one.
• Do not infer that a weapon mastery entry, class skill, or future unlock removes the pause.
• Do not treat the announced bow rework as already present in Demo Alpha 0.20.18.x.
• Do not use an older or future-looking clip as proof of current Demo behavior without matching its version and input sequence.
• Do not change a displayed stat and call the issue fixed unless the same controlled sequence changes consistently. No specific stat value is confirmed to remove this movement pause.

The public Demo is the relevant current play environment in the version snapshot. Early Access plans and broader advertised systems cannot fill gaps in Demo behavior. When a mechanic remains undocumented, a clean side-by-side test is stronger than a confident guess.

Adjust combat choices while the cause is still unclear

Create space before attacking, avoid adding a second attack until you know whether you need to dodge, and favor short, observable sequences over rapid chains. These choices do not remove attack commitment; they reduce accidental follow-ups and make the active action clear. Reproduce the behavior away from enemies first, then carry the same one-input rhythm into combat.

Document a result the developers or community can compare

If control loss extends beyond the visible attacks or behaves inconsistently, report more than “attacking freezes me.” Include the public Demo version, class, weapon, equipment context, input device, and ordered inputs without assuming button names.

Start any recording before the first input and end after movement returns or clearly remains unavailable. Keep one-input and two-input attempts separate. State whether a dodge was attempted between the reported first and second bow shots. This comparison helps another player distinguish the community-described queue from a longer lock that remains unexplained.

Choose the next action from your test result

If one input produces one attack and movement returns afterward, plan around that committed action and create space before using it. If a second input produces a second bow shot that blocks the dodge you wanted, stop buffering the follow-up and decide between repositioning and attacking again only after control returns.

If the character remains locked after the complete visible sequence, or one input produces extra actions consistently, preserve the version and reproduction details and report it as a separate possible issue. Do not promise yourself an animation-cancel setting, hidden unlock, or future bow behavior that remain unconfirmed in the current Demo.