| 00:00.39 | blast007 | getting my spare box set up with a 7900 GTO |
| 00:05.54 | short_circuit | is that newer or older than geforce 9800 gt |
| 00:08.29 | short_circuit | ooOoo.. almost the same Byzantine pieces of ......... |
| 00:18.47 | blast007 | short_circuit: older |
| 00:20.13 | blast007 | my new box has a GTX 980 Ti, which is far newer than both - yay for somewhat meaningless numbering :P |
| 00:22.13 | short_circuit | Right!?!?> |
| 02:03.00 | the_map | the letters are algebraic variables that make the numbers actually go in ascending order |
| 02:41.31 | blast007 | BulletCatcher: hmm, now typing into the chat box with the numberpad keys types twice :) |
| 02:42.28 | short_circuit | sweet 11 |
| 02:45.14 | BulletCatcher | Is it registering both key up and down events? |
| 02:46.19 | blast007 | think it's the SDL_TEXTINPUT part |
| 02:47.04 | BulletCatcher | It does it for me, too. |
| 02:47.11 | BulletCatcher | But not with SDL 1. |
| 02:48.21 | BulletCatcher | Or should I say SDL 11? |
| 02:50.16 | BulletCatcher | The doubles were introduced by my 00f647d commit above. Not sure why. |
| 02:52.25 | blast007 | perhaps cuz the keydown never worked before, but the SDL_TEXTINPUT did? |
| 03:35.30 | BulletCatcher | When I press a key it does SDL_KEYDOWN and SDL_TEXTINPUT, then SDL_KEYUP when I release. |
| 03:35.31 | BulletCatcher | The duplicate character is from the keypress, so I think you are right about the cause. |
| 03:37.33 | *** join/#bzflag ropil (~ropil@f-d1-232-fw-dip-188-32.core.deakin.edu.au) |
| 03:41.04 | blast007 | I don't actually get why we do both, but when I commented out the SDL_TEXTINPUT part, then I couldn't trigger most normal keys... |
| 03:41.34 | BulletCatcher | 11 is the new 1 |
| 03:42.28 | blast007 | perhaps we should only use SDL_TEXTINPUT when we're accepting text input (a text box in a menu or sending chat/commands) and use the SDL_KEYDOWN otherwise |
| 03:46.43 | BulletCatcher | Maybe we just need to expand the scope of "if(symNeedsConversion(event.key.keysym.sym))" in the SDL_KEYDOWN case. |
| 03:54.11 | blast007 | I'm not actually sure why we're even getting SDL_TEXTINPUT events.. we don't have a call to SDL_StartTextInput anywhere |
| 03:56.12 | *** join/#bzflag AAA_awright (~aaa@ns4001783.ip-198-100-144.net) |
| 03:58.43 | BulletCatcher | Maybe macsforme can explain what he did in commit bbc15394. |
| 04:00.33 | BulletCatcher | symNeedsConversion() seems to assume text characters have contiguous values, but maybe that isn't true. |
| 04:03.06 | blast007 | I don't like that we're blindly using lastKeyDownEvent even when it hasn't been set yet |
| 04:13.33 | BulletCatcher | symNeedsConversion() is probably fine, as is, but the way we use it means that it doesn't indicate keypad numerics. |
| 05:24.20 | macsforme | in SDL 2, there's no way to get the actual char value from an SDL_KEYDOWN event... so for example, shift + a will give you a keysym of 'a' |
| 05:32.02 | macsforme | so, for printable characters, the SDL_KEYDOWN event gets cached until the SDL_TEXTINPUT event, when the character value is actually available |
| 05:37.12 | macsforme | it does assume that the SDL_KEYDOWN and SDL_TEXTINPUT events will always come in that order, but that has never been a problem... it is a bit of a hack, but it was the least invasive fix that I was able to come up with at the time |
| 05:42.46 | macsforme | what would be the benefit to having Xcode use the BUILD_DATE macro? |
| 05:48.58 | macsforme | and I can't reproduce the double key presses for some reason, but it does sound like it could be related to the two events generated by the same keypress |
| 05:58.41 | the_map | 2.6.* clients will be incompatible with 2.4.4 clients? |
| 05:58.51 | the_map | 2.4.* clients, rather |
| 06:03.16 | *** join/#bzflag Gnurdux (~Michael@c-73-149-20-29.hsd1.ma.comcast.net) |
| 06:54.35 | allejo | all 2.4.* clients must behave the same way with respect to game-play and will use the same protocol with bzfs |
| 06:55.05 | allejo | a 2.6.* release will allow us to fix client side bugs that affect gameplay and move features away from the client to the server |
| 06:57.19 | the_map | how does a move from 2.x.* to 2.y.* work? |
| 06:57.41 | the_map | if people with different clients can't play with each other, then some will be on each |
| 06:58.01 | the_map | how long does it usually take to get everyone from one to the other? |
| 07:01.47 | allejo | that's why minor releases don't happen often (clients can't play with each other and servers need to be updated) |
| 07:02.22 | allejo | it works once it's decided that the current version is done and start working on a new version |
| 07:03.21 | allejo | i forget how long it took to move from 2.0.x to 2.4.x. probably like a week or 2 for the majority of people? |
| 07:07.56 | the_map | is there anyone still on 2.0.x? |
| 07:08.41 | allejo | there are still a handful of 2.0.x servers last time |
| 07:09.01 | allejo | and i think some older linux distros still distribute 2.0.x clients |
| 07:11.27 | the_map | are there many players on 2.0.x? |
| 07:11.40 | allejo | doubt it |
| 07:11.52 | allejo | though, there aren't many players on 2.4.x either :p |
| 07:12.39 | the_map | anyone on 2.6.x? ;) |
| 07:13.50 | allejo | 2.6.x is identical to 2.4.x atm with the exception of a handful of client bug fixes and lack of servers :p |
| 07:36.22 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 10:00.30 | *** part/#bzflag debitux (~debitux@unaffiliated/debitux) |
| 10:09.05 | blast007 | the_map: allejo meant "that's why *major* releases don't happen often" |
| 10:32.59 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 12:12.16 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 12:28.20 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 13:26.27 | *** mode/#bzflag [+v spldart] by ChanServ |
| 13:28.46 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 15:36.16 | blast007 | macsforme: is there a reason we can't use SDL_GetKeyName, which takes the sym (such as SDLK_X or SDLK_KP_0) and returns a string like 'X' or 'Keypad 0'? |
| 15:36.33 | blast007 | at least for normal key binding stuff |
| 15:37.31 | blast007 | there's also the opposite, SDL_GetKeyFromName, which gives you back an SDL_Keycode when you give it the key name |
| 15:39.01 | blast007 | the SDL_TEXTINPUT event will be useful once we start accepting UTF-8 chat messages, but only when we're in compose mode |
| 15:50.35 | allejo | blast007, to be fair, with our release schedule, I'm not wrong :p |
| 15:51.51 | blast007 | allejo: well, in the past maybe... but we'll probably have at least 3 minor releases this year ;) |
| 15:54.22 | allejo | hehe true |
| 17:14.23 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 18:01.10 | blast007 | as for keybinding, do we want the numberpad keys be separate? |
| 18:02.58 | blast007 | I'd see keyboard input as having two modes: playing and composition |
| 18:07.02 | *** join/#bzflag Void7 (~Void7@205.157.147.198) |
| 18:41.51 | *** join/#bzflag KaadmY (uid135503@gateway/web/irccloud.com/x-dmbtossxfuldknoe) |
| 18:42.52 | Void7 | hi |
| 18:43.58 | blast007 | hello |
| 19:51.34 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 23:32.08 | BulletCatcher | Allowing keypad keys to be bound differently from their corresponding keyboard keys would be more flexible, but I don't need the extra complexity for my setup. |
| 23:52.01 | *** join/#bzflag Void7 (~Void7@205.157.147.198) |