Set up Teleport/Translocate to trigger on-release rather than on keypress. about bindcontrol HOT 21 CLOSED

I've looked at this a very little bit so far and I fear it might simply not be possible to do everything as described. Bindcontrol can only work within the capabilities of the keybind system in CoH, and I don't think that we can get this fine-grained on what happens on press and what happens on release for the teleport powers. The new powexec_location command, which is the "teleport to current cursor position" functionality, seems not as well-fleshed out as some of the other powexec_ commands, so it might either need to be abandoned or simply lived with. I'm not 100% sure on this yet, though, and I'm going to keep tinkering and looking into it. We might be able to approach it, even if we can't get all the way there. No actual update, just letting you know I'm looking at it.

from bindcontrol.

Starting to think this might be possible. BindControl's default teleport binds are a little hinky and currently interfere with each other -- "Teleport to Cursor" is "LSHIFT+LBUTTON" and "Show Teleport Reticle" is just "LSHIFT" leading to a situation where pressing left-shift and clicking fires both binds and, every other time you use it, leaves the reticle showing awaiting another click. This is suboptimal. The "Hide Windows" preference seems not to be completely working either. So this all needs some love, not least having the default keys not be overlapping like that.

My intent, I guess, is to leave "Teleport to Cursor" working basically as it is, just instantly teleporting to the current cursor position without showing the destination reticle. The "Hide Windows" preference wouldn't be part of this, as it's instantaneous and there's no step of picking a destination and clicking.

The other one, currently "Show Teleport Reticle," would be the press-to-target-release-to-teleport plan, and would hide the windows while the key is held down.

I feel like this is to some degree how CityBinder originally intended these separate binds to work, but there wasn't the /powexec_location command at the time to make the simple "teleport to cursor" bind.

Does this seem sane and roughly like what you're looking for? Still not 100% sure this will work but I'm starting to be hopeful.

from bindcontrol.

I don't know very much about how CoX handles keypress events, but I guess I'm imagining a "On keypress" event where it does something (hide windows and show the teleport destination reticle) and a "On key release" event it does another thing (actually do the teleport).

If there aren't separate events, then I guess having a modifier key do the first thing and then a modifier+key/mouse chord to confirm the teleport would probably do the same thing.

If those can't be done, then maybe just what you have now and a bind (additional? toggleable in-game? just selected from a dropdown in BC like the fly choice) for plain jane teleport like clicking the power from the power tray.

from bindcontrol.

Yeah, the game's bind syntax is very key-press-centric. There exists a weird syntactic way to access the key release situation -- it's how the game's stock movement binds work to start and stop motion with press and release -- but overloading it to do extra magic with executing powers is fiddly. There's no specific way just to say "on release do X" as a standalone bind command, sadly.

I -think- what you describe should be possible, though, the more I look into it, depending on how well the game takes to having an existing show-the-teleport-reticle in progress cancelled and replaced with a teleport-to-cursor. I'm going to be experimenting with this more tonight and tomorrow. Found another bug with keybinding along the way that distracted me for a bit, but I'm getting back to the teleport situation shortly.

from bindcontrol.

I have excellent news -- I have a proof-of-concept of press+release teleport working really very well. I'm going to polish it up some, including wrapping Translocation into this logic (assuming it works, but I have no reason to think it won't), and release it in the next day or so. I'm quite pleased with how well it works.

from bindcontrol.

I've just released v0.15 which has this functionality. If you want to tinker with it, check that the "teleport to cursor" and "teleport to cursor on release" binds don't overlap (they both contain LSHIFT by default, which is itself a tiny remaining bug). Read the release note:
https://github.com/emersonrp/bindcontrol/releases/tag/v0.15

from bindcontrol.

Tapping "F" to turn on flying will sometimes make you hop slightly, you can hear the flight power actuate, but doesn't actually turn on the flight but it's difficult to reproduce. (I think it's just a latency thing that can't be fixed; local client predicts what should happen, but the server doesn't tell it that it did happen in time). Fixed by holding "F" down "long enough".

Bug reporting, though: Holding down Shift (to trigger the "show reticle and hide windows" makes you move "down" along the character's personal up/down axis. It is not falling. Can check by rotating the camera while "SHIFT" is held down and you can control where you go.

This is not an artefact left behind by the previous bindings, as I did /unbindall and deleted the old bind directory before writing and loading these.

I have not tested this with Teleportation as I have a bunch of alts and don't know what I have where. I will add a new response here if Teleportation's Teleport also acts weird. (and probably make a spreadsheet with a list of powers... there's a program idea... something to provide a powers overview for all your dudes at a glance.)

from bindcontrol.

The "hop" is a result of the "blast off" notion -- it's trying to launch you into the air for as long as you hold the key. Just tapping the key super quickly can tangle things up. Most likely it's getting the "start upward" command, and then not getting the "activate the fly power" before the key release. Leaning more and more toward just removing "blast off" as a concept.

Aha yes the downward motion during the "show reticle" key holding is a buglet indeed. Part of the fiddliness of "on press" and "on release" hacking involves using a directional command to activate the press/release situation. Traditionally "down" has been the one used because we want to keep bind strings short, and it's the shortest non-side-effecty one ("up" causes you to jump in many cases). There's a correct way to do it such that doesn't actually cause the downward motion, and apparently I didn't do that, and only tested while I was on the ground already. Will fix, thank you.

from bindcontrol.

I did confirm the same thing happens on my Teleportation lady. Here it breaks the built-in hover, which does make you fall.

I spent an unfortunate amount of time trying to figure out why before I discovered the /showbind slash command.

/showbind lshift offers the following

Key lshift binded to: +down$$powexecname Teleport$$windowhide health$$windowhide chat$$windowhide target$$windowhide tray$$windowhide nav$$bindloadfilesilent F:\TCB\RegiJust\tp\tp_on.txt

or

Key lshift binded to: +down$$powexecname Translocation$$windowhide health$$windowhide chat$$windowhide target$$windowhide tray$$windowhide nav$$bindloadfilesilent F:\TCB\LaTina\tp\tp_on.txt

from bindcontrol.

Could you add the "teleport to cursor without showing a reticle or anything" bind? I know it's an easy bind to set up in-game, but it would be nice to have that kind of thing consolidated into the program.

edit: I have a reason why this would be a good thing... teleportation available without all the windows flying back and forth when you need a couple teleports but don't need the reticle.

from bindcontrol.

"Teleport to Cursor Immediately" does just that. Is it not working for you? Remember to make sure it doesn't overlap with the "Teleport to Cursor on Key Release" bind (or any other, really). The defaults have been "LSHIFT+CLICK" and "LSHIFT" which is an unfortunate historical artifact. Assuming they don't collide, then yeah, the top bind should do the instant teleport and the bottom one should do the press/release with the reticle.

I released v0.15.0.1 which addresses the "down" problem partially, before I really looked into the "breaks the built-in hover" issue with Teleport. That is still there and I'm investigating the best solution. There will be one. Meanwhile, holding the show-reticle teleport key will no longer fly downwards, though, again, it breaks Teleport's hover still.

https://github.com/emersonrp/bindcontrol/releases/tag/v0.15.0.1

from bindcontrol.

I should slow down and batch these fixes. This should do the right thing with Teleport now, not flying downwards, not breaking the built-in Hover. Please let me know your luck.

https://github.com/emersonrp/bindcontrol/releases/tag/v0.15.0.2

from bindcontrol.

LaTina - Copy.txt Sorcery toon
Regina Justice - Copy.txt Teleportation toon
Even after changing "Teleport to Cursor Immediately" (thank you for pointing this out) away from LSHIFT+BUTTON1 to something else, it is still creating that bind.

I have confirmed this by deleting the old folder, /unbindall, loading the new binds, and then /showbind lshift+button1 and it spits out

Key lshift+button1 binded to: +down$$-down$$powexecname Translocation$$windowhide health$$windowhide chat$$windowhide target$$windowhide tray$$windowhide nav$$bindloadfilesilent F:\TCB\LaTina\tp\tp_on.txt

If I bind some other command (I tried binding the movement command left to LSHIFT+BUTTON1 and it had unexpected behavior. I did move left, but then kept moving left. Resetting left movement back to "A" meant "A" had the expected behavior, but lshift+button1 was again written to the above.

(I did check a toon that had never had teleport in a BC profile and lshift+button1 responded "Nothing" for the bind, but if I remove teleportation as a pool from a teleporter's profile, it returns "nop".)

from bindcontrol.

Hmm that's a little mysterious. Just so I understand the steps here:
-- Change "Teleport to Cursor Immediately" to something else, Write Binds.
-- Delete binds folder, /unbindall, load new binds.
-- LSHIFT+BUTTON1 is still bound.

Yes?

Does the new thing you assigned to "teleport immediately" also get set as expected?
What happens if you clear the "teleport immediately" bind completely (right-click on the binding button -- this is not documented anywhere, so you probably never found it)?

I'll tinker with your profiles and see. A quick glance shows me that LaTina still has the LSHIFT+BUTTON1 saved in the profile for "teleport immediately" where Regina has "T" instead. I'll tinker around and see if I can make this happen. Currently it's a bit of a mystery how that might happen, though I have some vaguely-formed suspicions. Might not get to this until tomorrow.

Oh, with a toon where you're seeing this misbehavior of it being incorrectly bound, can you attach both the profile and the reset.txt file from that moment? Thanks.

from bindcontrol.

LaTina - v01502.txt
(I uploaded the wrong version before;forgot to save before sending)
reset.txt

lshift+button1 also got the same binding lshift did.

On a lark I decided to bind "teleport to cursor on key release" to LCTRL (as this would be new) and the binding was also written to LCTRL+BUTTON1 (A strange artefact of this is using LCTRL hides all windows, but does not show them again)

THEN I cleared all bindings and used /bind lshift "powexecname translocation", which worked, but lshift+button1 also got the binding. Trying this experiment with ctrl did not have ctrl+button1 get a binding.

from bindcontrol.

This is fascinating. It appears to be a game bug, not anything BindControl is doing. Trying to bind anything to LSHIFT will also bind LSHIFT+BUTTON1. Full stop. The game is just doing that, even if you do it completely by hand after an /unbindall.

I can file a bug with the Homecoming folks, but this is outside of BindControl's influence.

(Interesting side note that I'd forgotten -- binding to SHIFT doesn't actually make a bind for "SHIFT," in fact the game will say that "/showbind SHIFT" is an invalid key string. It instead creates a bind for each of LSHIFT and RSHIFT with the same contents, and, because of this bug, also LSHIFT+BUTTON1 and RSHIFT+BUTTON1. Weird stuff.)

So, apart from the spurious keybind, is teleport working as you expect? (I mean, if you click while the reticle is showing, you're going to get two teleports, one from the click and one from the release, which is a little hinky. That's also outside of BindControl's influence, just don't click before you release.)

from bindcontrol.

A bit more info. Binding something to LSHIFT+BUTTON1 also binds that thing to LSHIFT. In both cases, the actual bind seems only to fire when LSHIFT is hit, not again when the mouse button is pressed. This is some weird behavior, and I've filed a bug report with the Homecoming folks.

https://forums.homecomingservers.com/topic/51906-lshift-binds-and-lshiftbutton1-binds-et-al-tangled-up/

from bindcontrol.

Other than the weirdness when using LCTRL+button1 as the teleport bind hiding all windows and not restoring them after, I think everything else is fine.

from bindcontrol.

Just was tinkering with using LCTRL / CTRL for the teleport key, and I thiiiink the weirdness may spring from doing CTRL-R to reset the binds? That starts a teleport when you press CTRL, then does a reset midstream, which gets things in a very strange state once you release the CTRL key to finish the teleport. I might be able to make the windows behave a bit better but using CTRL for teleport is going to get in the way of CTRL+R unless, of course, you remap that in Preferences.

Edit to add: Yeah, remapping the reset key to something without CTRL in it makes everything work as expected if the teleport key is CTRL, at least for me. Let me know.

from bindcontrol.

Because of finger comfort, I think I'll adapt to using lshift and tab for teleporting about. Hopefully the Homecoming team can fix the weird "also binds to lshift+button1" bug.

from bindcontrol.

Going to go ahead and close this feature request.

from bindcontrol.