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.16 | BZnotify | [13bzflag.org] 15allejo pushed 1 new commit to 06feature/api-events: 02https://git.io/v92OB |
04:05.16 | BZnotify | 13bzflag.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.57 | allejo | if 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.20 | blast007 | is it developer documentation or end-user documentation? |
05:29.21 | allejo | well, for future reference, both |
05:45.07 | blast007 | I'd say for developer docs you could include the git hash and the first released version it appeard in |
05:45.10 | blast007 | appeared* |
05:45.18 | blast007 | and for end-user just the first released version |
05:46.42 | blast007 | cuz 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.27 | allejo | "first released version" would be the stable version, right? |
05:47.46 | blast007 | and for the git hash, I'd make optional info even |
05:47.47 | blast007 | yeah |
05:50.12 | allejo | make the git hash optional? |
05:50.25 | allejo | er... yea. that's a good idea |
05:51.58 | blast007 | release version is the important part |
06:00.48 | allejo | agreed |
08:27.08 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-bjkzyjqimgmsqyav) |
09:58.07 | allejo | who owns github.com/bzflag? |
10:00.17 | blast007 | someone has a paid account with private repos there |
10:01.08 | blast007 | hmm, 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.22 | JeffM | it always did, I had github send them a message once, they never responded |
15:48.36 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
17:29.46 | allejo | aw :( |
19:44.30 | Zehra | this is somewhat confusing |
19:45.36 | Zehra | there's some functions and events |
19:46.25 | Zehra | since there's bz_incrementPlayerTKs |
19:46.54 | JeffM | what are you asking? |
19:47.09 | Zehra | there's no function to reduce tks... |
19:47.14 | JeffM | there is one to set it |
19:47.39 | Zehra | it kind of would be a cheap way of fixing tk.. |
19:47.49 | JeffM | huh? |
19:48.02 | JeffM | increment is just a common operation, so we made a utility to just do it |
19:48.08 | JeffM | it's shorter then Get, +1, set |
19:48.17 | JeffM | if you need to do anything else, get, mod, set |
19:48.42 | JeffM | get mod set is SUPER common in APIs |
19:49.48 | JeffM | the increment function is the oddity ;) it's candy |
19:50.45 | Zehra | i'm thinking of getting the tk part fixed a bit |
19:50.53 | JeffM | huh? |
19:51.10 | allejo | https://wiki.bzflag.org/Bz_setPlayerTKs |
19:51.31 | Zehra | well, i want players to die if shot, but not have a "tk" set or have a point lost |
19:51.41 | allejo | or just give bz_incrementPlayerTKs a negative number |
19:51.49 | JeffM | then keep track of the score you want, and force it |
19:52.01 | JeffM | yeah or incrmeemnt negative |
19:52.04 | JeffM | you can do it all |
19:52.16 | JeffM | there just isn't a simple function to do it, you have to do some work |
19:52.19 | JeffM | welcome to programing :) |
19:52.30 | Zehra | :p |
22:37.59 | *** join/#bzflag sk8 (49363b89@gateway/web/freenode/ip.73.54.59.137) |