Improve auto move support (autorun)

[Cervator]

Edit: Initially implemented by #2647 - list below updated to cover improvements

Came up while thinking about crouching functionality (see http://forum.terasology.org/threads/crouch-and-prone-controls.1622/#post-14015) and seems to generally be an appreciated feature.

At present we have switch default walk/run ("change speed permanently") on caps lock, which isn't great. We don't have auto-move. Suggestion as noted in the forum:

• Add auto-move functionality (bound to r by default)
  • Needs an entry in the input settings + translation key
• Move the walk/run toggle from caps lock to ALT-R (depends on Add support for modifier keys to input mappings #2551 - can leave on caps lock until that one is ready)
• Consider alternatives for the movement to not break on jumping or strafing
• Consider options to achieve full regular speed (auto-move is slower than a regular run, and toggling walk/run has no impact)

One thing to keep an eye out for: with auto move available you could start moving, open a UI, and keep moving. Can this cause trouble? Interaction screens tied to blocks should likely auto-close after a certain distance, while the player's own inventory screen could stay open.

[zeokav]

Hi! I'd like to work on this. Where do I start implementing this idea?
Also, about the opening UI and continuing to move issue, can't we just drop the auto move state of the character when an interaction screen connected to a block is opened? I have used auto move in a game that I used to play and as far as I remember, opening a menu used to stop the movement.

[rzats]

@zeokav: you can look into https://github.com/MovingBlocks/Terasology/pull/2544/files which is a PR in a fairly similar area 🙂

You'll need to have a new BindButtonEvent bound to r, then add a new event to LocalPlayerSystem that will start periodically sending move forward events when the button is pressed (and stop when it's pressed again).

[Cervator]

This feature was made functional in #2647 but I guess I'll leave this open for a bit for additional improvements so we don't lose them (comments in the closed PR aren't very visible.

Will update the checklist in the top comment.

[zeokav]

Aye @Cervator ! I got back to trying to get this to work without having to give an ImpulseEvent every time. But I kinda need an explanation on why my approach doesn't work. Here's what I put in -

@ReceiveEvent
    public void onAutoMove(PeriodicActionTriggeredEvent event, EntityRef entity) {
        if (event.getActionId().equals(AUTO_MOVE_ID)) {
            if (isAutoMove) {
                ClientComponent clientComponent = entity.getComponent(ClientComponent.class);
                Vector3f viewDir = entity.getComponent(LocationComponent.class).getWorldDirection();
// The commented code was how I was making it work.
//                clientComponent.character.send(new CharacterImpulseEvent(viewDir.mul(8f)));
// I get the input for forward movement, and instead of sending a CharacterImpulseEvent, I create an event to simulate the forward key pressed for 200 seconds.
                List<Input> inputs = bindsConfig.getBinds(new SimpleUri("engine:forwards"));
                Input forwardKey = inputs.get(0);
                clientComponent.character.send(KeyDownEvent.create(forwardKey, 'W', 200));
                logger.info("Down");
            } else {
                // If isAutoMove turns false, cancel the action.
                delayManager.cancelPeriodicAction(entity, AUTO_MOVE_ID);
            }
        }
    }

However... Nothing happens when I do this. Why isn't it registering the event?

[Cervator]

Ideally we could drag in @portokaliu or maybe @pollend on some ideas on physics/movement stuff since they've had some exposure there. Maybe @SkySom or @rzats too :-)

Feel free to push a sample branch to your fork any time, makes testing out things easier.

[zeokav]

@Cervator Before someone thinks that this issue is still undone - Everything on the checklist is covered except the modifier input binding, which, to be honest is slightly out of context (Plus #2551 isn't done yet). Can this be closed?

[Cervator]

Good catch @zeokav thanks! Closing this as complete :-)