| 00:15.16 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 00:45.02 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 01:15.45 | *** join/#bzflag Pimpi (~frank@p4FF43EFD.dip0.t-ipconnect.de) |
| 01:44.13 | *** join/#bzflag TyroneFHornigh (~dbw@108-197-33-160.lightspeed.sndgca.sbcglobal.net) |
| 03:34.55 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 03:56.01 | *** join/#bzflag rob1n (~rob1n@unaffiliated/rob1n) |
| 06:27.20 | *** join/#bzflag BZnotify (~BZnotify@192.30.252.40) |
| 06:27.20 | BZnotify | [13bzflag] 15JMakey pushed 1 new commit to 062.4: 02http://git.io/vt4ji |
| 06:27.20 | BZnotify | 13bzflag/062.4 140fc365a 15Jeff Makey: Use unsigned int vector indexes instead of casting the size to signed. |
| 06:27.20 | *** part/#bzflag BZnotify (~BZnotify@192.30.252.40) |
| 10:55.39 | *** join/#bzflag zuii (~akos@BC06BF93.catv.pool.telekom.hu) |
| 10:58.27 | *** join/#bzflag Guest1234 (481930af@gateway/web/freenode/ip.72.25.48.175) |
| 10:58.40 | *** part/#bzflag Guest1234 (481930af@gateway/web/freenode/ip.72.25.48.175) |
| 11:29.59 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 17:36.33 | *** join/#bzflag zuii (~akos@BC06BF93.catv.pool.telekom.hu) |
| 18:10.59 | *** join/#bzflag dngor (~abuse@p3m/dngor) |
| 19:18.01 | blast007 | well, got the files from SF copied |
| 20:07.52 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 20:56.30 | BulletCatcher | Changing minAntiAliasingSize to 6 in TextTool2 makes the 6pt and 8pt fonts look much better on my screen. |
| 20:56.31 | BulletCatcher | How is it for anyone else? |
| 20:57.01 | BulletCatcher | FWIW, the small fonts were antialiased in 2.4.2. |
| 21:13.31 | blast007 | hmm, yeah, the small fonts do look a bit bad in the current 2.4.3 |
| 21:18.03 | blast007 | I do prefer how the 2.4.2 small fonts look |
| 21:30.09 | BulletCatcher | I don't recall any complaints about the antialiasing in the small 2.4.2 fonts, so if nothing else it would be less of a change to keep them that way. |
| 21:37.53 | BulletCatcher | blast007, if Windows has M_PI defined in bzfsAPI.cxx then we don't need to compute it at line 2820. |
| 21:38.21 | BulletCatcher | Mac & Linux have it defined there. |
| 21:39.52 | blast007 | using M_PI there builds find on Windows |
| 21:39.55 | blast007 | fine* |
| 21:40.12 | BulletCatcher | Yay. I'll change it to use M_PI then. |
| 21:44.20 | blast007 | so, how worried should I be about breaking backwards compatibility with the ban file format? (regarding CIDR ban support) |
| 21:46.08 | BulletCatcher | I can imagine that someone would want to share a single ban file between old and new servers. |
| 21:46.18 | BulletCatcher | That doesn't mean we have to make it easy for them. |
| 21:47.17 | BulletCatcher | Because: progress! |
| 21:53.15 | BulletCatcher | Adding CIDR support in 2.4.4, which would be incompatible with 2.4.2 servers, would be less disruptive that way than the transition to 2.6 because there ought to be less need to run 2.4.2 and 2.4.4 servers simultaneously. |
| 21:53.55 | blast007 | ah, good point |
| 21:54.24 | BulletCatcher | I think we should just go for it. |
| 21:55.16 | blast007 | I was planning to add it regardless :) there's just probably a 'compatible way' and a 'proper way' to do it |
| 21:55.36 | BulletCatcher | Anyone who needs to run incompatible servers simultaneously will just have to use separate ban files between server versions. |
| 21:55.44 | blast007 | (compatible way likely adding a space before the /nn CIDR) |
| 21:56.59 | BulletCatcher | I haven't looked, but I suspect that a 2.4.2 server isn't flexible enough to preserve any ban file format other than the one it knows. |
| 21:57.50 | BulletCatcher | You may be able to include CIDR data that a 2.4.2 server would ignore, but it would be lost when the 2.4.2 server rewrites the file. |
| 21:58.07 | blast007 | hrm, yeah.. |
| 21:59.22 | blast007 | I'll have to test the behavior a bit |
| 22:04.57 | BulletCatcher | Here's the solution that is so simple I overlooked it: server operators who choose to share a banfile between 2.4.2 and 2.4.4 servers must not use CIDR bans. |
| 22:06.20 | BulletCatcher | We could even provide a command line option that prevents admins from entering CIDR bans to keep the file compatible. |
| 22:06.50 | BulletCatcher | But CIDR bans would be supported by default. |
| 22:26.31 | the_map | so, I can run "bzflag -e" in terminal to echo all console output from bzflag to the console window |
| 22:26.54 | the_map | is there a way to have it also include stuff like what team a player is? |
| 22:27.21 | the_map | in bzflag, the console colors callsigns according to team, but it doesn't do that in terminal |
| 22:27.34 | blast007 | what operating system? |
| 22:27.37 | the_map | ubuntu |
| 22:28.03 | the_map | I can work with the console output, so if it included any sort of indication, I could provide the coloring |
| 22:28.20 | blast007 | there a -ea/-echoAnsi command that can do add ANSI color codes to the output |
| 22:28.32 | blast007 | s/do // |
| 22:29.47 | the_map | woah, thanks |
| 22:30.36 | the_map | do you know if there's a way for a text representation of team color? |
| 22:30.42 | the_map | it would be easier to work with |
| 22:31.21 | the_map | otherwise I'll have to look into detecting color or something |
| 22:31.29 | the_map | ...maybe |
| 22:34.29 | blast007 | what are you trying to accomplish? |
| 22:34.53 | the_map | I have a program that works with console output, and colors output depending on what happened |
| 22:35.43 | the_map | like, lines that indicate that a tank grabbed a flag are colored orange; dropped, purple |
| 22:35.48 | the_map | etc |
| 22:35.58 | blast007 | well, for what purpose are you doing this? |
| 22:36.10 | blast007 | why can't it be a server-side thing? |
| 22:36.24 | the_map | it's for personal use |
| 22:36.46 | the_map | it started out as a simple program to translate messages that are in a different language than english |
| 22:37.04 | the_map | but then I started adding color coding |
| 22:37.41 | the_map | the translation part works, but I can't tell what color tanks are atm |
| 22:39.36 | blast007 | well, you'll either have to modify the game source code, or parse the ANSI codes |
| 22:40.02 | the_map | ok, thanks |
| 22:40.25 | the_map | I should be able to work with the provided colors, one way or another |