IRC log for #bzflag on 20170505

00:19.08*** join/#bzflag infobot (ibot@rikers.org)
00:19.08*** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.10 released! https://forums.bzflag.org/viewtopic.php?f=8&t=19401
00:19.08*** mode/#bzflag [+v infobot] by ChanServ
04:05.16*** join/#bzflag BZnotify (~BZnotify@192.30.252.42)
04:05.16BZnotify[13bzflag.org] 15allejo pushed 1 new commit to 06feature/api-events: 02https://git.io/v92OB
04:05.16BZnotify13bzflag.org/06feature/api-events 14e28b07d 15allejo: Make code blocks scrollable
04:05.16*** part/#bzflag BZnotify (~BZnotify@192.30.252.42)
04:06.23*** join/#bzflag Gnurdux (~Michael@c-174-63-82-49.hsd1.ma.comcast.net)
05:26.57allejoif I want to document the version of bz something was made available, should I use the stable (even) version of the dev (odd) version it was introduced?
05:28.20blast007is it developer documentation or end-user documentation?
05:29.21allejowell, for future reference, both
05:45.07blast007I'd say for developer docs you could include the git hash and the first released version it appeard in
05:45.10blast007appeared*
05:45.18blast007and for end-user just the first released version
05:46.42blast007cuz we first introduce all features in a odd version number since that's where we do development, so it doesn't really mean much to say it was introduced in an odd version :)
05:47.27allejo"first released version" would be the stable version, right?
05:47.46blast007and for the git hash, I'd make optional info even
05:47.47blast007yeah
05:50.12allejomake the git hash optional?
05:50.25allejoer... yea. that's a good idea
05:51.58blast007release version is the important part
06:00.48allejoagreed
08:27.08*** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-bjkzyjqimgmsqyav)
09:58.07allejowho owns github.com/bzflag?
10:00.17blast007someone has a paid account with private repos there
10:01.08blast007hmm, or at least it was.  I don't think it used to link to bzflag.org
11:26.32*** join/#bzflag Delusional (~Delusiona@unaffiliated/delusional)
12:58.24*** join/#bzflag Delusional_ (~Delusiona@unaffiliated/delusional)
14:48.22JeffMit always did, I had github send them a message once, they never responded
15:48.36*** join/#bzflag Zehra (~Zehra@unaffiliated/zehra)
17:29.46allejoaw :(
19:44.30Zehrathis is somewhat confusing
19:45.36Zehrathere's some functions and events
19:46.25Zehrasince there's bz_incrementPlayerTKs
19:46.54JeffMwhat are you asking?
19:47.09Zehrathere's no function to reduce tks...
19:47.14JeffMthere is one to set it
19:47.39Zehrait kind of would be a cheap way of fixing tk..
19:47.49JeffMhuh?
19:48.02JeffMincrement is just a common operation, so we made a utility to just do it
19:48.08JeffMit's shorter then Get, +1, set
19:48.17JeffMif you need to do anything else, get, mod, set
19:48.42JeffMget mod set is SUPER common in APIs
19:49.48JeffMthe increment function is the oddity ;) it's candy
19:50.45Zehrai'm thinking of getting the tk part fixed a bit
19:50.53JeffMhuh?
19:51.10allejohttps://wiki.bzflag.org/Bz_setPlayerTKs
19:51.31Zehrawell, i want players to die if shot, but not have a "tk" set or have a point lost
19:51.41allejoor just give bz_incrementPlayerTKs a negative number
19:51.49JeffMthen keep track of the score you want, and force it
19:52.01JeffMyeah or incrmeemnt negative
19:52.04JeffMyou can do it all
19:52.16JeffMthere just isn't a simple function to do it, you have to do some work
19:52.19JeffMwelcome to programing :)
19:52.30Zehra:p
22:37.59*** join/#bzflag sk8 (49363b89@gateway/web/freenode/ip.73.54.59.137)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.