Aim a Bow with a Controller

A universal controller button sequence is not confirmed for Demo Alpha 0.20.18.x. For the public Demo Alpha 0.20.18.x baseline, treat bow aiming as four separate things to test: target direction, attack input, any attack already buffered, and menu navigation. Confirm the bow in your equipment view, use the binding displayed by your own build if one appears, return to a neutral state, and test direction and attack separately. Do not assume a particular stick, trigger, or shoulder button is correct simply because another action responds.

This limitation matters because the developer's October 26 announcement says bow combat needs more work and will be reworked. That rework is not confirmed as completed in Demo 0.20.18.x. Patch 0.20.18.x fixed some controller shoulder-button and navigation faults, but it does not provide an exact bow mapping.

What is confirmed and what remains unknown

Emberville is represented here by its public Demo, not a released Early Access build. Early Access is scheduled for January 7, 2027, so advertised future behavior should not be used as current Demo instructions.

Use the checks below to identify where the input chain breaks before changing a binding. If your on-screen prompt disagrees with an old screenshot or diagram, prefer what your installed build displays.

Set up a controlled bow test

Use a quiet area where you can observe your character and a fixed direction without needing to dodge, collect items, or navigate a menu.

1. Check the build. Look for the version shown by your installed Demo. These checks apply to the 0.20.18.x public baseline; a different build may behave differently.
2. Confirm basic controller recognition. Move through one ordinary menu, then close it. This proves only that some menu input is arriving, not that combat aim is mapped correctly.
3. Verify the weapon visually. Open the equipment or inventory view and confirm the bow you intend to test. Do not use damage output alone as proof that the correct weapon is active.
4. Return to neutral. Stop moving and avoid repeated attack presses. Wait until the visible action ends before the next input.
5. Test direction alone. Move only the control that your build presents as camera, cursor, facing, or aim input. Watch for one observable change without deciding in advance which control should work.
6. Test attack alone. Use the attack binding shown by your build, if available, with other controls neutral. Observe whether an action starts, holds, releases, or does nothing.
7. Combine them once. Set one direction and perform one deliberate attack. Repeated presses can hide whether you are seeing the current command or an earlier buffered action.
8. Change one variable. Alter only direction, distance, controller connection, or input method per attempt. Changing several variables makes the result ambiguous.

The equipment screen gives you a visual checkpoint before combat diagnosis. Use it to confirm the bow and displayed character state, not to infer an undocumented controller layout or hidden damage formula.

Separate the four input layers

Controller problems can feel like one failure even when they occur at different stages. Keeping the layers separate is a diagnostic method; it does not claim that the Demo exposes four configurable systems.

Target direction

Target direction is the direction the game appears to use for the next bow action. Look for a visible change in facing, camera alignment, cursor position, or another cue that your build actually shows. The exact aiming cue is not confirmed for this layout, so record what changes instead of naming a control in advance.

If direction changes only while another control is held, note the sequence without treating it as intended design. It may involve a mapping interaction, build-specific behavior, or input overlap; the cause remains unconfirmed until you reproduce it under controlled conditions.

Attack input

The attack input begins or completes the bow action. Successful menu confirmation does not identify the attack button because interface navigation and combat commands are different test paths.

Watch the character before the damage number. A starting animation, held state, release, or no action gives a cleaner signal than final damage. A specific charge threshold, release timing, or required button combination is not confirmed here.

Buffered attack

For diagnosis, treat a buffered attack as a command entered before the character is ready for the next action. Repeated presses may make a later action appear to ignore a new direction. Perform one attack, wait for its visible action to finish, reset direction, and try again.

If single presses behave differently from rapid presses, record the difference. It narrows the problem to timing or input order, but it does not prove a bug, define a buffer window, or provide a permanent fix.

Menu input

Menu input shows whether the controller can navigate an interface; it does not certify combat aiming. A controller may operate equipment or mastery screens while a combat action still fails. Conversely, a menu fault does not prove that bow combat itself is broken.

Use one stable menu as the recognition check, close it, and test combat. Build version matters when comparing results with old reports because 0.20.18.x includes some controller shoulder and navigation fixes.

Read the result without guessing the cause

These comparisons suggest what to test next. They are not universal fixes.

Changing input method is only a diagnostic comparison. It does not prove controller support is absent or require you to abandon the controller. Its value is keeping the weapon, scene, and build constant while changing one part of the input path.

Do not use damage as the only aim indicator

Low damage does not establish that controller aiming has failed. Without a confirmed damage formula for this Demo setup, a low number cannot tell you whether aim, range, equipment, timing, the target, or another factor caused the result.

First classify the visible action: did direction change, did the bow action begin, and did the attack occur? Only after those are repeatable should you compare damage. Keep the weapon, target, position, and input sequence as consistent as practical. Treat a changed number as an observation, not proof of an undocumented accuracy or charge mechanic.

Use the menus as checkpoints, not as a button map

The weapon mastery menu can help you confirm that you are viewing bow-related information in your build. It cannot establish an unlock requirement, combo sequence, or controller binding. Check the current entry and control prompt for each of those details.

The preview shows the Bows mastery category; it does not establish a controller aiming button.

The current Wanderer class menu can provide context for the active character or class view. It does not prove a hidden inheritance submenu, a class requirement for aiming, or a route to unlock bow behavior. If the class menu does not open, treat that as a separate interface problem rather than folding it into the bow diagnosis.

These checkpoints keep three questions separate: whether the controller is recognized, whether the character is in the expected weapon or class context, and whether the bow accepts directional and attack input.

Build a repeatable controller practice routine

Once one deliberate attack responds, practice consistency rather than hunting for a secret button. Begin from neutral, set one direction, perform one attack, and wait until the visible action ends. Repeat at the same position before changing distance or direction.

In the first short set, change direction only. In the second, keep direction stable and vary only the timing between direction and attack. In the third, compare single presses with the rapid inputs that caused trouble. Do not convert a difference into a universal rule unless the game explains it; the announced bow rework means behavior and prompts may change later.

If you try different controller connections or profiles, change one at a time. Record the version, controller type, whether menus respond, whether direction changes, whether an attack begins, and whether another input method behaves differently. This short record is more useful than a description mixing several attempts.

Know when the result remains unresolved

Stop searching for a definitive button answer when your build shows no binding, repeatable tests disagree, or only old instructions claim a specific stick or trigger. Those mappings remain unconfirmed for this Demo, and the announced bow rework means older control advice may change.

This does not prove every failure is a game bug. It means the cause remains unconfirmed after the supported checks. A useful report would include the displayed Demo version, controller model, connection method, the menu action tested, the exact combat sequence, what appeared on screen, and whether another input method differed in the same scene. Avoid claiming low damage proves failed aiming unless you can also show direction or attack input failing.

For Demo Alpha 0.20.18.x, the defensible method is to confirm the bow and build, verify basic controller recognition, test direction and attack separately, remove repeated buffered inputs, and compare one variable at a time. If that produces no stable aiming behavior, document the result as unresolved in the current Demo rather than forcing an unverified button mapping.