01:20.00 | BulletCatcher | Yes, but I want it to be 0.2. |
01:29.10 | blast007 | so that part is a non-issue then. You don't actually have a 'radar short' defined. |
01:42.06 | *** join/#bzflag ukiki (~ukiki_@99-29-155-149.lightspeed.bcvloh.sbcglobal.net) |
01:42.29 | *** join/#bzflag heartnet (~msk@90-104-16-160.host.anywhere.rr.nu) |
01:44.34 | *** mode/#bzflag [+v spldart] by ChanServ |
01:47.15 | *** join/#bzflag Gnurdux (~Michael@c-73-149-20-29.hsd1.ma.comcast.net) |
01:50.24 | BulletCatcher | Fair enough. |
01:52.12 | BulletCatcher | But the fact remains that my "1" key on the keypad, as I have it set up, works cleanly with SDL 1 but not SDL 2. |
01:55.46 | BulletCatcher | Using the default of 0.25 doesn't make SDL 2 work any better. |
02:07.43 | blast007 | does look like there is a separate keycode for the numberpad numbers https://wiki.libsdl.org/SDL_Keycode |
02:11.04 | blast007 | and we have separate handling of numberpad (keypad) numbers |
02:11.39 | blast007 | the SDL2 platform code looks to be the only one that references Kp0, though, for instance |
02:12.55 | blast007 | there is code in SDL2Display that is supposed to make it treat them as actual numbers, though |
02:13.13 | blast007 | starting from like 268 there |
02:15.58 | blast007 | the numberpad numbers don't work initially, but if I hit 1, 2, or 3 at the top of the keyboard (and have number lock on), then 1, 2, and 3 on the keypad work |
02:19.59 | blast007 | I'll look into it further in the morning |
02:21.58 | the_map | it's morning in greece |
04:41.16 | *** part/#bzflag heartnet (~msk@90-104-16-160.host.anywhere.rr.nu) |
06:10.51 | *** part/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
06:18.40 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
06:29.24 | *** join/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
07:35.09 | *** join/#bzflag cods (~fred@tuxee.net) |
07:36.42 | *** join/#bzflag cods (~fred@rsbac/developer/cods) |
07:40.20 | *** join/#bzflag cods (~fred@rsbac/developer/cods) |
08:00.28 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
08:26.16 | *** join/#bzflag ruskie (ruskie@sourcemage/mage/ruskie) |
10:16.10 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
14:27.40 | *** join/#bzflag TheRedBaron (~ZeeBaronR@73.42.43.169) |
14:29.00 | *** join/#bzflag TheRedBaron (~ZeeBaronR@73.42.43.169) |
14:32.33 | blast007 | whoops, starting from line, not like |
14:49.17 | blast007 | Is there a debugger GUI on Linux that doesn't suck? Using Nemiver right now, but that's pretty horrid. Can't add/remove breakpoints while the program is running. |
14:51.38 | zuii | you may laugh but qtcreator debugging? |
14:54.13 | zuii | it uses a lot mem but it works |
14:54.54 | blast007 | I'll give it a shot |
14:55.39 | blast007 | "a lot" meaning how much? should I have more than 2GB RAM in this VM? |
14:56.20 | zuii | http://doc.qt.io/qtcreator/creator-projects-autotools.html |
14:57.34 | zuii | dunno how much |
15:02.33 | zuii | http://doc.qt.io/qtcreator/creator-debugger-operating-modes.html#launching-the-debugger-in-different-modes |
15:03.13 | zuii | Debug->start debugging -> attach to process |
16:37.47 | blast007 | zuii: thanks, that's such a better experience |
17:07.02 | BulletCatcher | Up through v2.4.4, man pages contained "the date configure was run" and the game version string contained "the date buildDate.cxx was compiled." |
17:07.10 | BulletCatcher | Commit bf8e847 (HEAD, at the moment) changes both to be either "the date configure was run" or the date specified by SOURCE_DATE_EPOCH for autotools-based builds. |
17:07.15 | BulletCatcher | I will refactor that commit so it does not assume /bin/sh is bash, and that the "date" command is the GNU implementation. |
17:07.21 | BulletCatcher | I am still interested in getting some kind of identifier from Git into the game version string, but we don't need to hold up 2.4.6 for that. |
17:07.26 | BulletCatcher | Do we want to make any other effort to make builds reproducible before we release 2.4.6? |
17:39.39 | blast007 | BulletCatcher: I don't know what else we'd need to do |
17:40.08 | blast007 | testing such a thing locally sounds rather complicated/infeasible |
17:41.44 | BulletCatcher | Which thing? |
17:41.55 | blast007 | testing for reproducible builds |
17:42.17 | blast007 | Debian has a rather complicated system for that, and requires lots of different hardware types |
17:43.05 | blast007 | as for the BUILD_DATE generation, I used the one from here: https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal#Bash_.2F_POSIX_shell |
17:43.30 | blast007 | says for GNU systems, so what part of it isn't for GNU date? |
17:43.59 | BulletCatcher | Your commit is fine for GNU systems, but Solaris isn't GNU. :-p |
17:44.18 | blast007 | oh, nvm, I read your message wrong :) |
17:44.36 | blast007 | thought you said you were refactoring it so that the 'date' command is the GNU implementation |
17:45.46 | blast007 | https://tests.reproducible-builds.org/reproducible.html#variation <-- this is what Debian is doing to test |
17:47.07 | BulletCatcher | Changing $() to `` is easy enough so it works with a real Bourne shell, but Solaris does not seem to provide a lightweight method for a shell to convert 1463054400 to a formatted date string. |
17:48.23 | BulletCatcher | I don't really care about reproducibility on Solaris, so I'll probably just punt when "date -d" isn't supported. |
17:48.30 | blast007 | would that only prevent Solaris from using SOURCE_DATE_EPOCH? or would that prevent it from generating the date completely? |
17:49.05 | BulletCatcher | "date -u +%Y-%m-%d" works fine on Solaris. |
17:49.30 | BulletCatcher | But not "date -d @1463054400". |
17:53.06 | blast007 | does this work? echo "1463054400" | awk '{print strftime("%Y-%m-%d",$1)}' |
17:55.07 | BulletCatcher | Nope. awk and nawk are too old on Solaris. |
17:55.39 | BulletCatcher | I may fall back to perl if date fails. |
17:58.46 | BulletCatcher | This works: perl -wle 'use POSIX; print strftime "%Y-%m-%d", gmtime $ENV{SOURCE_DATE_EPOCH}' |
17:59.42 | BulletCatcher | It makes configure depend upon perl, but perl *is* available on Solaris and it is no worse than depending on the GNU version of date. |
18:01.44 | BulletCatcher | I suppose it is worth noting that I am on Solaris 10. Solaris 11 may have GNU date. |
18:35.21 | *** join/#bzflag nitroxis (n@nxs.one) |
19:34.58 | *** join/#bzflag BZnotify (~BZnotify@192.30.252.41) |
19:34.58 | BZnotify | [13bzflag] 15JMakey pushed 2 new commits to 062.4: 02https://git.io/vrG4o |
19:34.58 | BZnotify | 13bzflag/062.4 1412e07cf 15Jeff Makey: Use Bourne shell compatible syntax when processing SOURCE_DATE_EPOCH.... |
19:34.58 | BZnotify | 13bzflag/062.4 1432fcd8d 15Jeff Makey: Ignore include/config.h.in~, which results from running autogen.sh again. |
19:34.58 | *** part/#bzflag BZnotify (~BZnotify@192.30.252.41) |
19:39.32 | BulletCatcher | That ought to do it for autotools builds. |
19:39.37 | BulletCatcher | Xcode can probably set BUILD_DATE in the PBXShellScriptBuildPhase section if desired. |
19:47.36 | blast007 | thanks BulletCatcher |
19:48.24 | blast007 | the SDL2 number pad thing has a number of problems in the code |
19:48.45 | blast007 | the first is that the order of keys doesn't go from 0 to 9, it goes 1 through 9 and then 0 |
19:49.28 | blast007 | so the 'else if ((sym >= SDLK_KP_0) && (sym <= SDLK_KP_9))' would never apply |
19:50.29 | blast007 | and second, the values of 'sym' aren't near the normal ASCII ranges. for instance, SDLK_KP_1 is 1073741913 |
19:51.03 | blast007 | so subtracting 208 from it and shoving it into a char probably isn't going to yield a meaningful result ;) |
19:51.59 | BulletCatcher | That's all fixable. |
19:53.00 | blast007 | yup |
19:53.32 | *** mode/#bzflag [-v short_circuit] by ChanServ |
19:54.17 | blast007 | I don't know if the values are guaranteed to be the same every time or if we'll have to do a switch statement for each of the SDL_KP_* enums |
19:54.58 | blast007 | I should compare with Windows, since it seemed to work fine there |
19:57.14 | blast007 | I get the same value for sym on Windows for keypad 1 |
19:58.00 | BulletCatcher | I' be in a fun match right now, but I can look at fixing it later unless you get to it first. |
19:59.16 | blast007 | huh, actually it's doing the same thing on Windows now. (numpad only works after using the top row once) |
19:59.40 | BulletCatcher | Yay for cross-platform consistency. |
20:00.12 | the_map | BulletCatcher: you're in a fm? |
20:00.32 | blast007 | yeah, that's actually good, because now I can use Visual Studio to debug ;D |
20:49.22 | *** join/#bzflag [Gort] (~gort@82-69-126-225.dsl.in-addr.zen.co.uk) |
20:49.23 | *** join/#bzflag [Gort] (~gort@unaffiliated/gort/x-9231432) |
20:55.09 | *** join/#bzflag echelon (~echelon@bzflag/player/echelon) |
21:10.44 | *** join/#bzflag echelon (~echelon@bzflag/player/echelon) |
21:41.16 | *** join/#bzflag debitux (~debitux@unaffiliated/debitux) |
21:44.20 | debitux | hi, got a little problem with BZFlag client 2.4.2.20131114-MAINT-linux-gnu-SDL. if starting bzflag after connection to my openvpn routing vpn with default routing through it, i cannot start the server anymore. it says exit 2. |
21:46.58 | blast007 | from the 'start server' menu in the game? |
21:47.05 | debitux | yes |
21:47.39 | blast007 | I'd recommend just running the server (bzfs) from the terminal |
21:47.53 | debitux | thanks, trying that |
21:47.57 | blast007 | the start server menu won't show you any of the error output |
21:48.16 | blast007 | 'bzfs -help' and 'man bzfs' will show you documentation for running the server |
21:49.06 | blast007 | for instance, 'bzfs -ms 5 +r +f good{2}' would run a server on the default 5154 port with 5 shots, ricochet, and 2 of each good flag |
21:51.37 | debitux | yeah, server is reacheable in the vpn \o/ thats the first step. thanks blast007, im going to read bzfs' man :) |
21:56.57 | *** join/#bzflag echelon (~echelon@bzflag/player/echelon) |
22:36.34 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
22:54.43 | BulletCatcher | A straightforward switch statement in SDL2Display.cxx for SDLK_KP_* solves the keypad trouble for me. |
22:55.57 | BulletCatcher | It still won't go fullscreen. |
23:05.09 | blast007 | when you try to start it fullscreen from the terminal, does it spit out errors? |
23:07.12 | blast007 | also, I'm not exactly sure what the SDL_TEXTINPUT is supposed to be for. It references a lastKeyDownEvent (which is an SDL_Event) that only gets sent from SDL_KEYDOWN when symNeedsConversion return true |
23:09.24 | BulletCatcher | Starting fullscreen prints nothing. |
23:09.26 | BulletCatcher | I get a black screen, but the desktop is exposed so I can use the window manager to open a new xterm and kill -9 the bzflag process. |
23:09.38 | BulletCatcher | When I do that the desktop is restored. |
23:16.08 | blast007 | run |
23:16.47 | blast007 | which nvidia card and is that the proprietary driver or the open one? |
23:16.50 | blast007 | fun* |
23:17.38 | BulletCatcher | GeForce 7025 with proprietary driver. |
23:39.03 | *** join/#bzflag BZnotify (~BZnotify@192.30.252.40) |
23:39.03 | BZnotify | [13bzflag] 15JMakey pushed 1 new commit to 062.4: 02https://git.io/vrGwy |
23:39.03 | BZnotify | 13bzflag/062.4 1400f647d 15Jeff Makey: Do not assume any numerical relationship among SDLK_KP_* values, nor that simple arithmetic will convert them to corresponding ASCII values. |
23:39.03 | *** part/#bzflag BZnotify (~BZnotify@192.30.252.40) |
23:43.31 | *** join/#bzflag [Gort] (~gort@82-69-126-225.dsl.in-addr.zen.co.uk) |
23:43.31 | *** join/#bzflag [Gort] (~gort@unaffiliated/gort/x-9231432) |