dirkdeftly

3rd December 2003 05:10 UTC

getkbmouse() wish
I wish upon a star that we had a new getkbmouse(,,) function:
getkbmouse(input,press (move up/left)/release (move down/right)/hold (still))
so we could compress code structures like:
plmbs=clmbs;clmbs=getkbmouse(3);
click=1-equal(plmbs,clmbs)*clmbs;
to:
click=getkbmouse(3,1)

...For those of you who don't understand my blathering, I want to add a change in position identifier to the getkbmouse() function, so we can track actual presses and releases instead of just down/up. And come to think of it, it'd probably just be easier to define it as the change in state since the last frame. So getkbmouse(3,1) would be the change in left mouse button state, and getkbmouse(3,0) would be it's current state.

OR we could have a seperate function altogether: changekbmouse(blah).


By now I've lost my train of thought, but I'll post it anyway if anyone else thinks it's worthy of attention....

UnConeD

3rd December 2003 06:33 UTC

I don't really see the use in it, plus it would be annoying to code, requiring AVS to get the status of every key, every frame rather than just the ones the script needs.

dirkdeftly

4th December 2003 02:49 UTC

Why would it need to do that? And imo being able to track clicks rather than whether the mouse button is up or down in a simple function would be pretty useful

sidd

5th December 2003 10:14 UTC

i feel you dawg, i keep running into the same problem.

Im sure you can easily come up with some code that does the same thing. Making new evallib stuff would get pretty messy.

hungryskull

5th December 2003 21:14 UTC

Not neccesary. Code can do the same thing. Changing it in AVS would just present new bugs for an addition that only a few people will use.

dirkdeftly

6th December 2003 02:02 UTC

1: easier on user code, since otherwise we have to use three variables for every key we want to track clicks for
2: shouldn't be too hard to implement in the avs source code
3: my ass only a few people will use it.

akx

13th January 2004 16:06 UTC

Yeah, why not "getkbmouse2(key,state)"
with key = -1 for mb1, -2 for mb2, -3 for mb3 and positive numbers as ASCII values?

Oh well.

UnConeD

13th January 2004 17:24 UTC

First of all, the reason the parameter is this weirdo 'virtual key' and not an ASCII value is because keys do not map to ASCII values. Most keyboards have 2, some 3, glyphs per key. Some keyboards have dead keys which have no effect on their own, but combine with the next key (e.g. if I press my '^' nothing happens, and then press 'a' I get 'â').

Some non-characters keys have an equivalent ASCII code (escape, tab, backspace, ...).

The link to the keylist has been added to the FAQ btw.

akx

13th January 2004 18:37 UTC

I know.

Well, ASCII values range from 0 to 256.
Keycodes are mapped from whatever to whatever, so why couldn't keys > 1000 be mapped as (keycode-1000)?
It *could* work.

Maybe polling, saving, responding for all keys' WM_KEYDOWN, WM_KEYUP events would be too much to keep AVS smooth, *BUT!* there's plenty of space in the options panel for "Main" (currently only "Clear at every frame"), so a listbox could be set up there to list all the keys this preset could use in the getkbmouse2 context... Clear? No? Good. :)

Phew.