Jump to content
  • 0

[v278] Keybinding tests, bugs and remarks


mutonizer

Question

Below are various tests of selective keybindings. The video's not really interesting, I just had capture on while testing this and it takes 2 minutes to edit..so there.

 

https://www.youtube.com/watch?v=Mdy-c0sjI7c

 

 

To sum it up, as it stands now, we have separate keybinds for:

- Select > to select and drag-select actors

- Multi-select > doesn't work afaik

- Move > to give a move order

- Interact > to interact with props, lootables, zone transitions

- Attack > to validate the use of an ability, or an attack command

- Attack Cursor > switches cursor to attack command mode

- Cancel Action > cancel any action, move

 

Some remarks:

1) Why split Select, Move, Interact and Attack?

I'm all for more keybinds usually but shouldn't these be contextual and all merged into a single "Select" keybind?

- If I click on empty ground, it's a move order.

- If I click on a friendly Actor, it's a select order.

- If I click on a neutral Actor, it's an interact order.

- If I click on an enemy Actor, it's an attack order.

- If I click on a prop, lootable or zone transition, it's an interact order.

- To force attack a friendly or neutral Actor, I use Attack Cursor, then Select

 

2) Despite all these keybinds, in menus, inventory and whatnot, all interaction keybinds are static (LMB and RMB)

 

3) Only RMB, LMB and MB2 can be bound currently in game. However, a simple modification directly in the registry clearly shows that you can remap use MB3, MB4, MB5 and it works just fine as seen below. Allowing them to be bound in the game options would be nice at some point.

 

post-115688-0-58938200-1410020877_thumb.jpg

 

4) All keybinds you'd usually find bound to mouse buttons worked fine using keyboard, even drag multiselecting using for example A as the keybind (just need to hold the key down and move mouse). However, Drag Formation doesn't work that way and is basically unusable via keyboard binding.

 

5) Queue keybind (the missing string) seems to work fine afaik. That said, you cannot assign SHIFT currently in the options, which I believe is the most common form of queuing modifier.

 

Link to comment
Share on other sites

4 answers to this question

Recommended Posts

  • 0

I disagree on point 1. More options are always best, and it's the reason why contextual inputs are very often bad, particularly in console-to-PC ports.

 

It's good to have these actions split up. Say for example you know you just want to attack a certain unit, having an 'attack' command means there is no way you can accidentally misclick and move your squishy wizard into harm's way, for example.

 

The keybinds using modifiers don't currently work for Shift/Ctrl/Alt- i.e. you can't set it to 'Shift+' (or 'Shift+None' as it's displayed) though other keys mostly work. No doubt they'll be fixed before release. I'm sure the same goes for extra mouse buttons being bindable too. 

Edited by piercehead
Link to comment
Share on other sites

  • 0

Fair enough on 1), as said, I'm usually all for more keybind options but that just seemed overkill for a cRPG. As long as they work fine if all bound to the same key/mouse button, who cares right? ;)

 

As for the rest, just putting it here to have a trace since I was testing them around anyway.

Link to comment
Share on other sites

  • 0

Keybinds should mimic the IE games, and only add extras rather than change anything.

 

That said RMB cancel isn't working in v278 which makes me annoyed.

 

Hmm, worked for me, can see it in the video at the end when I test it (4:41 or so)

Edited by mutonizer
Link to comment
Share on other sites

×
×
  • Create New...