E2 - Input Support

[ZeikJT]

Not to threadjack, but I'm having trouble with some helper functions I wrote for the input support.

[highlight=lua]
registerFunction("cKeyValue", "s", "n", function(self, args)
local op1 = args[2]
local rv1 = op1[1](self,op1)
return string.byte(rv1)
end)

registerFunction("keyValue", "s", "n", function(self, args)
local op1 = args[2]
local rv1 = op1[1](self, op1)
if !InvertedKeyMap[string.byte(rv1)] then return 0 end
return InvertedKeyMap[string.byte(rv1)]
end)
[/highlight]

Ah very cool, I was thinking about adding something like that but I figured the e2 already had some helpers. It does, they're toByte(s) and toChar(N).

Also, the E2 user should never ever need the InvertedKeyMap nor the KeyMap, as they utilize the clientside KEY_* values which a user never sees nor interacts with. I made it all work with the Ascii values.

Thats what I've got so far, I'm fairly certain I'm doing it wrong as its not giving me the right values. This probably is because of the discrepancy between serverside and clientside key values.

Honestly when I wrote the initial version I used the regular input values from the wiki, but some people had mentioned they wanted ascii support so I changed to that, and it was confusing as hell to set up for me too. What I did was make the numbers the user supplies be in ascii and then it converts it to gmod values before sending. So to do it with regular letters you can do:

listenForKey(toByte("a"))

keyDown(N) uses the IN_KEYS ones, correct?
cKeyDown(N) uses ASCII then?

Well, the IN_KEYS list has both. The keyDown() is serverside keys, so it uses the IN_* values. I didn't use Ascii here because those keys might be mapped to the mouse and the movement keys can be anywhere. They are all rebindable.

cKeyDown() takes ascii which are transformed into the KEY_* values in the function, the user isn't aware of this part.

What value would string.byte() return, IN_KEYS or ASCII?

Ascii

InvertedKeyMap is ASCII to IN_KEYS and Keyboard_ReMap is the opposite?

No, the ReMap is KEY_* to Ascii, and the Inverted is Ascii to KEY_*
Easy way to check is look at the actual file in the wire_keyboard folder, it has the regular ReMap and goes KEY_* to Ascii.

I know its a lot of questions, but I'm considerably confused on the matter, and I think these functions would be helpful.

Also, any possibility of this being SVNed? I'd love to be able to use it on other servers.

I don't mind answering questions, it's good to know someone's using the inputs and even adding on to them.

As per the SVN part, I doubt it, but you never know.

[Pyroclastic]

Hmm. Then what I have should be working. Instead of returning 8 for "w" however, it is returning 33 the KEY_W value instead of the IN_FORWARD value. And the KEY_W value is apparently always down. How would I get the IN_FORWARD value for an input of "w"?
(Aggghh. E2 is creeping its way into my brain, I keep trying to Ctrl+Space validate my posts and programs.)

EDIT: I just tested it, and fromAscii() does the same thing, when I put 119 ("w") in, I get 33 out. When I put 33 in toAscii() I get 119. However, the only value keyDown() sees as "w" is 8, it registers 33 as never down, even when press w.

[Syranide]

Hmm. Then what I have should be working. Instead of returning 8 for "w" however, it is returning 33 the KEY_W value instead of the IN_FORWARD value. And the KEY_W value is apparently always down. How would I get the IN_FORWARD value for an input of "w"?
(Aggghh. E2 is creeping its way into my brain, I keep trying to Ctrl+Space validate my posts and programs.)

This uses the keyboard keys, rather than bound keys (that's why you can see if ANY key is pressed).
That's why you get KEY_W instead of IN_FORWARD.

(EDIT: yeah, ctrl-space turned out really well ^_^)

[Pyroclastic]

The thing is keyDown() uses the bound keys. So it only knows w as 8 (Its IN_FORWARD value) instead of 33 which is its KEY_W value.

[ZeikJT]

I'm sorry, I read all of that and got nothing out but more confusion, here's is how I made it work:

keyDown() uses the serverside keys, so you HAVE to look on the wiki for the values, keyDown(KeyNumber)
The IN_* enums are the only ones useful to you IN KEYS - GMod Wiki
In my example on the Input page I used forwards, backwards, left, and right keys. It worked great for me.

cKeyDown() uses ascii key codes, you can look at the keyboard for those, or just use use toByte(KeyString) to get the number you'll want to use. Note that this will not work on many of the keys that are not alphabetical, look in the wire_keyboard ReMap file for miscellaneous keys.

[Syncaidius]

Any chance of this being in the SVN at all?
I know its on the wiki as an extra addon but, would it hurt to put it in the SVN?

[ZeikJT]

Yes, it would hurt.

[Syranide]

Slap me if you want attention :P

Absolutely, I think this could be good addition to the SVN (but it depends on what ZeikJT thinks as well of course), but there are some things so far, to/fromAscii is misleading and incorrect, toChar/toByte is ascii, yours is just an arbitrary keytable. I think it would be better to consider having the functions accept/return strings instead, so one specifies "W", "LALT", etc instead of having to fumble with additional functions or numbers all the time. It just makes it unnecessarily complex and hard to read code. In the same way, it would also be a bug plus to be able to use listenForKey("W,A,S,D,LALT,RALT") or something similiar instead of having 6 calls to the function.

Also perhaps change cKeyDown() to clkKeyDown() or clkKey() to keep that naming convention going.

E:cKeyDown() has to go obviously to prevent people exploiting (bitching about) it, however, I think it could be nice to have it work for vehicles/pods (for whoever enters it), but I understand the complexity of actually implementing that, so it's probably best not to even bother.

runOnKeyDown(N) would be a very useful addition in my opinion, to prevent people slapping interval(10) on every expression.

Perhaps cIgnoreChat should be default as well, I can't think that most people would actually want that as default (and perhaps name it similarily to the rest of the functions keyIgnoreChat() or something, the "c" feels rather arbitrary right now?).

Also, I'm not sure, but it seems like if there are two expressions that listens for a key now, if one stops listening, it will stop for the other one as well. It also needs cleaning up after expressions get deleted or the player leaves as well.

(Also note that since you do not store the keys it listens to in the local expression-storage (self.data), your example on the page is wrong, if you only call listenForKey during first(), duped expressions will not listen for keys)

[ZeikJT]

A c in front of the function name means it's a clientside one, I guess I should have kept that standard for the listen functions too. The others are serverside.

As per the ascii, I can't remember exactly who (think it was Chinoto), someone asked for it to use the same ascii keys that the keyboard uses.. so I thought what the heck, I'll just confuddle the code some more and make it the default :P

The checking of other people's keys was just for fun, as this is an unofficial addon, and I thought what the heck. If this ever were to be cleaned up for SVN those would be the first code blocks to get deleted.

listenForKey("W,A,S,D,LALT,RALT") sounds like a good idea, I've made string parsers before and this looks fairly simple compared to the previous project implementations.

I'll make the chat ignoring the default too. As for the listening, it is a global thing, and I think it should remain that way. It's not a good idea to make it too complex by having it on a per-chip basis. If you think it's absolutely necessary or too much of a plus to pass up though it could be implemented.

I guess I'll get right on that restructuring to make it SVN worthy.

EDIT: Oh, and there's no need to worry about cleanup, the returns are clientside, so as soon as the player leaves the chip won't receive anymore inputs. I guess rejoining *might* pose a problem however.

[Syranide]

A c in front of the function name means it's a clientside one, I guess I should have kept that standard for the listen functions too. The others are serverside.

Ah!

As per the ascii, I can't remember exactly who (think it was Chinoto), someone asked for it to use the same ascii keys that the keyboard uses.. so I thought what the heck, I'll just confuddle the code some more and make it the default :P

No, you're right, I got a bit confused myself and thought the conversion was the other way around, they are correct, it's just that it's a bit like saying E:fromIceCream(), sure, but what is the icecream turned into? :lol:
So perhaps name them something like "keyToAscii" "asciiToKey" instead to actually have them relate to something, if they should be kept.

The checking of other people's keys was just for fun, as this is an unofficial addon, and I thought what the heck. If this ever were to be cleaned up for SVN those would be the first code blocks to get deleted.

Of course, I kind of assumed that

listenForKey("W,A,S,D,LALT,RALT") sounds like a good idea, I've made string parsers before and this looks fairly simple compared to the previous project implementations.

string.Explode(",", rv1), simple as that, and then just loop over the array.

I'll make the chat ignoring the default too. As for the listening, it is a global thing, and I think it should remain that way. It's not a good idea to make it too complex by having it on a per-chip basis. If you think it's absolutely necessary or too much of a plus to pass up though it could be implemented.

No-no, not at all, it is fine the way it is now, I just meant that you should change the example to not have them inside "first()" as it will not dupe correctly then. But you still need to remember the keys on a chip-basis to allow for cleanup and prevent E2s stopping other E2s from listening (and perhaps for runOnKeyDown if you implement that). But, it doesn't need to do anything with the stored keys (like restore or anything), just to have them as reference to prevent E2s from interfering with each other. Or perhaps that's what you meant?

I guess I'll get right on that restructuring to make it SVN worthy.

Only if you want to
This was just my feedback if it should be put on the SVN.
Awesome work anyway!



EDIT: Hmm, as for having keyDown for vehicles/pods, it should be straight-forward to implement for the KEYS_*-version, which should also be sufficient for most uses, don't you think?