inconsistent broadcasting of keys

hey,

im trying build a video FX layout for the game thang online.

first route I went through trying was setting up VideoFX viewers with a mapped key on enter/exit.

This was setup in the ingame GUI, triggering a keystroke action Targeting a given Character slot, however the hotkey in game never gets triggered. The games engine is rather old, and does not handle rebinding keys. The key I'm trying to pass through is "x" on key release (horribly ugly version of GetAsyncKeyState to get the release based off last keypress)

I have confirmed the keys are being passed through fine, simply not in the right way for the client to register it as a hotkey. It does work perfectly fine in the chatbox, as expected since that is a lot more relaxed with keys.

Ill also confirm, it is not a foreground issue, testing directly on the targeted client using a hotkey bound in isboxer does not work. Broadcast/Repeater mode does work, Which is what leads me to think its something to-do with the way keystroke actions are ran.



I also tried using Video FX Repeater pass-through to instead use an item from the hotbar however getting click events to pass-through video FX is inconsistent, I suspect this is a game engine issue as capturing the mouse through a videoFX element is rather clunky too Thus the idea for going through using the enter/exit bounds instead.


Is there a way to control what sort of an action is actually passed through on a keybinding?

I have attached my xml just encase its something i simply have miss-understood on how to do the keybinding correctly, the key map I have been using for testing is "Client 7 MP"


This is probably one of those really rare cases but hopefully there is some trick to it. Worst case, i suppose ill have to just switch clients or broadcast but i was hoping there would be a more elegant solution.

[bob]

There probably is some trick to it, but it would probably require code to fix it, and it is probably not an ISBoxer fix (although I'm not an authority on that).

As you have determined the game is doing something weird with the reading of the key states, and while recognising that it has been told about a keypress, it then goes and looks up which key is currently pressed, rather than taking the message received at it's word. And the Z and X keys are just really odd in the handling, because they are behaving differently to any others as far as I can tell.

Anyway. What I've found.
If you set the hotkey to process a Step when "pressed", then the hotkey (SHIFT+ALT+3 in this case) is read, and the inventory panel comes up, presumably because it is reading the 3, rather than the keystroke "A" I was sending (I was trying something other than X). The SHIFT+ALT was being ignored, and so was the keystroke being sent to the game.
If you set the hotkey to process a Step when "released", then the game does not recognise anything is happening when you press the hotkey.

I found out after some fiddling, is that it doesn't like you using SHIFT as part of the hotkey. Presumably this comes back to it's reading of the keystate somewhere. If you swap and just use ALT+ or CTRL+ then it seems to work, and you need ISBoxer configured to execute a step when "Released". Setting to pressed means the game reads the source key without modifiers, as well as what is sent.

BUT, this did not carry over to the X and Z keystrokes though, and the game just ignored those ones again with any and all modifiers or hotkeys. They did work however if I used the hotkey of Z or X for those mapped keys. This may not be of any benefit to you though if you are trying to setup hotkeys for individual toons, but it might be possible to have all toons Z/X at the same time (note: I was only testing with one toon to evaluate what does and does not work).

All up, you may be able to get something working but it will have a few restrictions on what you can do currently. Lax might be able to be looked at it at some point, but only he knows when this might occur, and whether he can work around how the game deals with input. It also looks like it uses a software cursor, but it seems to be not too bad considering. Certainly means clickbars and menus will probably be ruled out in any config, unless they are off the game client area.

/e: After some fiddling with 2 toons, the Z and X keys certainly don't want to work in any way shape or form, even with broadcasting enabled, unless the client is the active foreground window, so there is definitely something going on there. Other keystrokes seem to work fine.

After a little more playing, I did find that if I added a Do Mapped Key Action, and called the Always On -> Next Window on the Z remap to self mapped key, then the game focus would switch to the other game, this this would work. Although if you use a modifier, like CTRL+Z to send Z to the current window, then you need to let go of CTRL between each Z press, so this method would only be really useful for spamming Z or X and effectively round robining through the windows, but in a actual switch focus kind of way.
If you hold the modifier then it stops switching on the second toon, and both games would behave as though broadcasting was enabled, and both games would respond to the Z key (or X if that was the mapped key you were spamming). Although as soon as you clicked the mouse or hit an non ISBoxer Hotkey, you lose this behaviour. So maybe this is something to do with how the foreground/active window is being focused??

Quite a lot of insight you have there!

impressed you actually went and tested yourself too.

as for the broadcasting, isboxer seems to mess with the clients ability to detect a keypress (which is generally a good thing, an example of this is with the client set right running two clients without isboxer, x and z will pass-through to every client by default. isboxer somehow captures the key and stops that from happening. in this case, thats an advantage. i suspect in your testing the problem is the pass-through option - ofwhich apart from disassembly, i dont have an official copy of that bit of source to look at in detail from a programmatical sense.)

Give it a try with the passthrough function enabled on the clients and see if it works better for you, because it seems your having even more issues than I in getting anything to pass through correctly. options -> etc -> Accept Keys when inactive

Ill do some testing without using shift, and/or other modifiers to see if i can get anywhere there. It is an interesting point you bring up there.



The software curser is a bit of a pain for clickbars and menus, i found for the ingame isboxer GUI, i had to override the software cursor with a overlay ontop of that to know where my mouse actually was. Not really a fault of isboxer at all, simply the implementation the game uses. I did find performance to be near on perfect in a dxnothing window so i might try and see if its simply a game limitation on VideoFX passthrough elements, as that could easily be a simple work around if it works.


Fully I see this as a rather rare case, and less important on lax's todo list is at all. but hey, whats the harm in putting the thought out there!

Edit:

So testing out in a dxnothing container, VideoFX passthrough works pratically perfect, so that does leave the option of simply storing things i want to be able to click on in a dxnothing window off to the side. Not how i was first looking at doing it, but functionally, it just means i use an extra bit of screen space on another monitor or adjust the resolution to fit it all onto one screen.
Would love to passthrough keys accurately still though so that ill do more testing on but sleeping on it, and reading over your advice made the software cursors affect on VideoFX (and clickbars etc for that matter) pretty clear.

[bob]

I played with the pass through option the first time around. It didn't really make things much better. In fact I had it enabled for the 2 toons testing, which highlighted to me that there is some oddity about how the setting of the active window occurs. I spent most of the tests without the ISBoxer option of "Make game believe it is foreground", so maybe I'd get some different results if I turned that on.

All in all it looks like there is an odd implementation behind it all though, and it appears to treat some keys differently to others, specifically SHIFT, Z and X are all a bit odd.

But then, if you can get it going with video fx, then that might be the way. Sometimes that is the way to go with a new game. Just fullscreen them all, put a big dxnothing over the top of them all, and then use a bunch of viewers to play the game through. I did find that it would be useful to setup a mouse sync hotkey though, because the mouse tends to get out of position on each of the toons every once in a while. It probably wouldn't if I didn't mouse out to lother applications, and was only playing the game, but the nature of testing this stuff means that I do, and thus mouses were in the wrong places.


/e:
If I set the "Make game believe it is foreground" option, turn off the pass through off in game (well, "Accept Keys when Inactive"), and then use a straight key on self (Window:Current) on the Z/X keys, with a call to the Always On -> Next Window, after sending the z/X to self, I can get a round robin on the heal/mana fill that works consistently, although this does mean that you switch windows, but with a few steps involved you can spam it and cycle back to the starting toon, then stop with a popup or a timer to halt it briefly.
Other than that, the rest of the commands seem to be interpreted fine when setup via mapped keys, although for the most part this looks like it will be a mostly broadcasting setup, like D3.
With a mouse sync mapped key as I mentioned above (or rather, set the hotkey for the repeater/broadcast enabled/disabled to something really convenient), setting the FPS to be the same on all games (I used 30/30) - because i found they would easily get out of sync when using 60/30; and a few Hold to Control mapped keys (use the Action RPG setup, rather than standard MMO), then it all becomes rather playable. Not too sure on how the game play actually pans out as I was just mucking around in the starting areas to see what worked.

I'm sure there are a bunch of other quirks, and finding a corner to resync toon position is few and far between in the areas I was playing. The toons do get out of sync if you click click click to move. You need to be sure that they have finished their previous movement or very near to the end of it. I also found that sometimes the games would show the other toon in a different position to where the game screen for that toon was showing them. It wasn't just lag either. That was a little annoying as I though I needed to resync position, but I really didn't.

Finally the Camera leaves a bit to be desired. Getting it set right on all the screens is a pain, unless you play all zoomed in or all zoomed out, and once you turn the view, you are stuffed. Hopefull this resets once I exit. It would be nice if there was an in game camera reset.