| 00:22.39 | *** join/#bzflag infobot (ibot@rikers.org) |
| 00:22.40 | *** 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:22.40 | *** mode/#bzflag [+v infobot] by ChanServ |
| 01:01.47 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-ymnuvudabngfosdl) |
| 01:15.24 | *** join/#bzflag bertman (~bert@unaffiliated/bertman) |
| 01:57.43 | allejo | is there a way to turn of maxFlagGravs? |
| 01:57.49 | allejo | maxFlagGrabs* |
| 02:06.38 | blast007 | without modifying bzfs? no |
| 02:14.40 | allejo | could making it a negative number be a feature? |
| 02:18.35 | blast007 | you'd have to be sure that the grabs value can never legitimately be negative |
| 02:19.33 | blast007 | current if it's less than or equal to 0 (after decrementing it) it will reset it |
| 02:20.49 | blast007 | currently* |
| 02:32.48 | allejo | right, so it's expected behavior to reset it once it's <= 0 |
| 02:33.07 | allejo | its* |
| 02:36.49 | blast007 | yup |
| 02:37.21 | blast007 | I mean, really, it's for the best that flags get reset. After a few uses they really start to smell. |
| 02:37.29 | allejo | lol |
| 02:37.50 | allejo | my concern is for maps such as bzmatchball where a flag respawning would ruin things |
| 02:39.13 | blast007 | yeah, I don't know the best way to handle that |
| 02:49.12 | allejo | allow the API to access the FlagInfo data and add an option to prevent resets for an individual flag? |
| 02:50.57 | blast007 | is there only one flag? does it need to be a specific type? |
| 02:51.19 | allejo | on this specific map, there's only one flag |
| 02:51.33 | allejo | of a specific type, i.e. and then 2 team flags |
| 02:52.27 | blast007 | so it's a problem if the non-team flag respawns? |
| 02:52.41 | allejo | correct |
| 02:52.50 | blast007 | is there jumping? |
| 02:53.16 | allejo | the non-team flag is needed to capture the flag. so it can be dropped right by the base but if it respawns, then you'd lose the position |
| 02:53.23 | allejo | no jumping on this specific map |
| 02:53.55 | blast007 | even if you make the API allow doing that, there's still cases where it would have to reset |
| 02:54.20 | blast007 | like, if it's an invalid flag drop area (over a pyramid, or death physic) |
| 02:54.21 | allejo | for example? |
| 02:54.36 | allejo | ah |
| 02:55.07 | blast007 | so it would be more of a 'doNotResetMostOfTheTime' kind of flag |
| 02:55.10 | blast007 | not the most straight forward |
| 02:55.34 | blast007 | (also, if flags on buildings isn't turned on, flags dropped above Z=0 are reset) |
| 02:56.35 | allejo | what about only resetting it if it's dropped on an invalid area? but otherwise it wouldn't |
| 02:58.08 | blast007 | maybe we don't need to have the randomization on the max grab count? |
| 02:59.05 | allejo | mind elaborating on that? |
| 02:59.10 | blast007 | then you could just set it to a really big number |
| 02:59.43 | blast007 | currently the max grabs for a flag gets set by multiplying _maxFlagGrabs by bzfrand() |
| 03:00.10 | blast007 | get rid of the rand, and then you could just /set _maxFlagGrabs 1000000 |
| 03:02.38 | allejo | i'd be fine with that |
| 03:03.43 | allejo | would removing the randomness of have any unintended side effects? |
| 03:07.37 | blast007 | flags might last for longer than 4 hours |
| 03:08.14 | allejo | hmm would removing the randomness be any different from ignoring the respawn on a negative number? it'd still respawn on unsafe areas |
| 03:10.03 | blast007 | it would make _maxFlagGrabs result in a predictable reset cycle for flags |
| 03:10.32 | blast007 | right now it's a random number between 0 and _maxFlagGrabs |
| 03:12.22 | allejo | ah that's fair |
| 03:13.10 | blast007 | or it's something like that. probably more like 1 and _maxFlagGrabs, since it does add 1 |
| 03:13.47 | allejo | yea it'd be 1 and _maxFlagGrabs |
| 03:13.52 | blast007 | or between 1 and _maxFlagGrabs + 1? |
| 03:14.18 | blast007 | so really, all the more reason to just set it to _maxFlagGrabs :P |
| 03:14.31 | allejo | hehe |
| 03:14.44 | blast007 | I think that's the last risky change of the three options |
| 03:14.46 | blast007 | least* |
| 03:15.20 | blast007 | (and it fixes a real-world annoyance that people have had with _maxFlagGrabs) |
| 03:16.35 | allejo | mkay. i'll push that change then |
| 03:20.19 | *** join/#bzflag BZnotify (~BZnotify@192.30.252.34) |
| 03:20.19 | BZnotify | [13bzflag] 15allejo pushed 1 new commit to 062.4: 02https://git.io/vHiiG |
| 03:20.19 | BZnotify | 13bzflag/062.4 14f2c6a59 15allejo: Set _maxFlagGrabs to actual value |
| 03:20.19 | *** part/#bzflag BZnotify (~BZnotify@192.30.252.34) |
| 09:03.56 | *** join/#bzflag [dmp] (~dennis@unaffiliated/dmp/x-546784) |
| 18:35.09 | *** join/#bzflag DTRemenak (~DTRemenak@2605:e000:7f0c:c401:e966:a4bb:97ca:708c) |
| 18:35.09 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 18:35.09 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 20:18.18 | *** join/#bzflag Leppp (~Leppp@cpe-24-94-29-105.san.res.rr.com) |
| 22:28.04 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 22:59.28 | *** join/#bzflag Delusional (~Delusiona@unaffiliated/delusional) |