| 01:08.00 | *** join/#bzflag meeba (~lamer@c-73-14-146-7.hsd1.co.comcast.net) |
| 02:16.21 | blast007 | I went a different route with the chat timestamps |
| 02:17.03 | blast007 | dunno if it's necessarily better though |
| 02:23.19 | blast007 | I'm storing the year, month, day, hour, minute, second in the ControlPanelMessage class |
| 02:24.44 | blast007 | feels like date might be unnecessary, aside from maybe screenshots or /savemsgs |
| 02:29.49 | alezakos | I would add an off/time only/time & date option, but that's probably a bit too much |
| 02:30.06 | blast007 | that is how I have it right now |
| 03:07.26 | macsforme | can it be switched on/off retroactively, or does it permanently apply the timestamp to any messages as they're first outputted? |
| 03:11.46 | blast007 | retroactively |
| 03:12.14 | blast007 | the PR didn't do that, it just added a timestamp at the time of adding a message to the list |
| 03:23.03 | macsforme | retroactively seems much more useful |
| 03:36.43 | blast007 | might also be able to add an option to /savemsgs to include timestamps, even if you don't have it enabled on the panel itself |
| 03:50.42 | the_map | blast007: for those of use that pipe the console to a log file (as in, bzflag -e > log.txt kind of thing), how will that effect it? |
| 03:51.04 | the_map | will it dump everything into the log file again? |
| 03:51.24 | the_map | or will it update the console but not redump everything? |
| 04:21.15 | *** part/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 04:40.17 | *** join/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 14:01.49 | *** join/#bzflag kaadmy (uid135503@gateway/web/irccloud.com/x-hwmkbyvgkvzjxvem) |
| 14:58.50 | blast007 | the_map: it would probably show up for that as well, but it would of course not be retroactive. |
| 14:59.13 | blast007 | so no, won't redump everything |
| 14:59.17 | blast007 | that would break horribly |
| 15:00.06 | blast007 | it wouldn't remove anything from the file, so you'd have duplicate lines |
| 15:00.18 | the_map | yeah, that was what I was worried about |
| 15:00.33 | the_map | obviously it wouldn't remove anything from the file |
| 15:01.39 | the_map | although (in theory) that shouldn't be *that* hard to program |
| 15:02.31 | blast007 | I don't think we *can* |
| 15:02.47 | the_map | if bzflag did its own logging, it could |
| 15:03.03 | blast007 | oh god, don't bring up logging ;D |
| 15:03.14 | the_map | and aside from that, if set up properly, a secondary program could be written to do it |
| 15:03.15 | the_map | what? |
| 15:03.27 | blast007 | was kind of a long standing joke |
| 15:03.56 | blast007 | there were plans for some advanced log control, at least for bzfs |
| 15:04.25 | blast007 | never happened, but got brought up and discussed every so often, sometimes as just a joke |
| 15:05.41 | the_map | ok, maybe logging wasn't the best idea |
| 15:05.56 | the_map | but you all should totally make a mobile version of bzflag! ;P |
| 15:06.32 | BulletCatcher | We'll call it Angry Tanks. |
| 15:07.03 | blast007 | it was kinda the same as adding karma to the game |
| 15:10.04 | blast007 | Flappy Tanks |
| 15:26.10 | BulletCatcher | The output of "git describe" is very close to what I think we should use to get version numbers for reproduceable builds. |
| 15:26.55 | BulletCatcher | "git describe HEAD" gives "v2.4.6-RC2" right now. |
| 15:27.34 | BulletCatcher | For the previous commit, "git describe HEAD~" would give "v2.4.6-RC1-3-g385b16c". |
| 15:27.53 | BulletCatcher | That means it is the 3rd commit after v2.4.6-RC1. |
| 15:34.10 | BulletCatcher | It doesn't work quite right for our development versions, though. |
| 15:34.47 | BulletCatcher | "git describe 2b89de6" gives "v2.4.4-8-g2b89de6" for what we consider to be a 2.4.5 version. |
| 16:44.19 | *** join/#bzflag zuii (~cauchy@BC06BF93.catv.pool.telekom.hu) |
| 21:08.12 | *** join/#bzflag jnoob22 (~jnoob@unaffiliated/jnoob22) |
| 23:36.44 | *** join/#bzflag Ebert (~Ebert@c-71-56-52-3.hsd1.ga.comcast.net) |
| 23:45.44 | allejo | ~brad-- |