| 00:53.30 | Notify | 03BZFlag:Allejo * 8899 /Functions(API): Moved incorrect function |
| 00:54.23 | allejo | so I might have made a mistake... I created a bz_isPlayerSpawnable to match bz_setPlayerSpawnable's convention but the wiki mentioned of a planned bz_canPlayerSpawn function... should I replace isPlayerSpawnable? |
| 00:55.20 | blast007 | bz_isPlayerSpawnable is fine |
| 00:56.39 | allejo | cool, then could you forward this page (http://wiki.bzflag.org/Bz_canPlayerSpawn) to bz_isPlayerSpawnable? |
| 00:57.10 | blast007 | can't we just delete it? |
| 00:57.52 | allejo | sure |
| 00:57.59 | blast007 | wonder if 2.99.x had that |
| 00:58.36 | allejo | not sure, wiki said it was 2.3+ |
| 00:58.42 | Notify | 03BZFlag:Allejo * 8900 /Functions(API): Removed nonexistent bz_canPlayerSpawn() |
| 00:58.52 | blast007 | 2.99.x has bz_canPlayerSpawn |
| 00:59.06 | blast007 | https://github.com/BZFlag-Dev/bzflag/blob/2.99/src/bzfs/bzfsAPI.h#L1292 |
| 00:59.35 | allejo | ah.... |
| 01:00.55 | blast007 | I prefer the name you picked though since it shows the relationship better |
| 01:01.38 | blast007 | also, our platform code needs a sift kick in the backside for 2.8 or 3.2... |
| 01:02.00 | allejo | yay that makes me feel better |
| 01:04.28 | *** join/#bzflag Constitution (~josh@bzflag/developer/Constitution) |
| 01:06.58 | allejo | and I was thinking about what I had asked earlier. instead of adding it to the allow spawn event, what about making it accessible in a function? |
| 01:08.24 | allejo | or... |
| 01:08.55 | allejo | no, it does make sense in the event |
| 01:09.36 | blast007 | are there any other spawn events that are always called when a player is going to spawn? |
| 01:09.51 | allejo | bz_eGetPlayerSpawnPosEvent |
| 01:10.17 | allejo | bz_ePlayerSpawnEvent |
| 01:11.01 | blast007 | hmm, unfortunately that one is called after the spawn position is picked |
| 01:11.12 | allejo | yea |
| 01:11.31 | allejo | either allow spawn or get player spawn |
| 01:11.56 | blast007 | what is your use case for this feature? |
| 01:12.00 | allejo | i already bumped allow spawn, so was just gonna continue working on that. that was my reasoning at least |
| 01:12.21 | allejo | a plugin wants to force a player to spawn at their base for whatever reason |
| 01:13.01 | allejo | say, an obstacle course. wants to reset a player's spawn location without calling killPlayer() |
| 01:15.01 | blast007 | and this would be changing each spawn? |
| 01:15.32 | allejo | well ideally it'd only change once and then it'd be handled automatically |
| 01:15.49 | allejo | well for my use case |
| 01:16.19 | allejo | someone could easily randomize spawn at base or freely based on solar flares |
| 01:18.15 | blast007 | guess I'm trying to figure out why per-player |
| 01:18.33 | blast007 | you can already turn it on and off for everyone mid-game |
| 01:18.50 | *** join/#bzflag rob1n (Nomsayinth@unaffiliated/rob1n) |
| 01:19.28 | allejo | how for everyone? |
| 01:19.41 | blast007 | change the freeCtfSpawns BZDB variable |
| 01:20.05 | allejo | hmm... |
| 01:20.11 | blast007 | src/bzfs/SpawnPolicy.cxx uses that to figure out if it should spawn people on bases ever |
| 01:20.29 | blast007 | doesn't let you force it for next time, but allows you to prevent it from spawning them on the base |
| 01:21.34 | allejo | that could be of use |
| 01:22.37 | allejo | here's another use case. for leagues. if player subs, they always self destruct/kill to spawn randomly. that would be a per player basis. but it'd only be enforced once and then it's automatic |
| 01:22.51 | allejo | not leagues but matches in general |
| 01:24.21 | blast007 | just feels unrelated to allowing a player to spawn |
| 01:24.50 | allejo | i agree |
| 01:25.08 | allejo | would get player spawn pos be more apt? |
| 01:25.27 | blast007 | like I said, that's already too late |
| 01:25.54 | blast007 | spawn position is picked before it calls bz_eGetPlayerSpawnPosEvent handlers |
| 01:25.56 | allejo | oh I thought player spawn event was too late |
| 01:26.23 | blast007 | (but that lets you alter the position, for instance, how airspawn does it) |
| 01:28.52 | allejo | yea |
| 01:34.52 | allejo | can this be a function? or when is this value reset |
| 01:35.20 | blast007 | allejo: grep -r setRestartOnBase . |
| 01:35.22 | blast007 | :) |
| 01:35.59 | allejo | --exclude-dir=.git |
| 01:35.59 | allejo | :p |
| 02:37.19 | BulletCatcher | "git grep setRestartOnBase" |
| 02:41.26 | blast007 | neat |
| 02:41.47 | allejo | teach me your ways, bc |
| 02:42.25 | BulletCatcher | The path begins with "git --help". |
| 02:42.59 | BulletCatcher | Soon after that, "git --help -a". |
| 02:43.26 | allejo | :O |
| 02:45.13 | *** join/#bzflag BZnotify (~BZnotify@192.30.252.45) |
| 02:45.13 | BZnotify | [13bzflag] 15allejo pushed 1 new commit to 062.4: 02http://git.io/vOZJ1 |
| 02:45.13 | BZnotify | 13bzflag/062.4 14d7457dc 15allejo: Add functions to force players to spawn at base... |
| 02:45.13 | *** part/#bzflag BZnotify (~BZnotify@192.30.252.45) |
| 02:46.01 | allejo | restartOnBase is reset after each spawn, so that function will set it for the next respawn |
| 02:54.50 | Notify | 03BZFlag:Allejo * 8901 /Functions(API): Added new spawnAtBase functions |
| 02:57.18 | Notify | 03BZFlag:Allejo * 8902 /Functions(API): Moved spawnable functions to the player state section |
| 03:47.14 | the_map | a lot of people find it hard to see blue tanks on the radar; what does everyone think of changing blueradar from "0.0 0.0 1.0" to "0.0 1.0 1.0" to change it from blue to cyan? |
| 04:07.07 | BulletCatcher | The actual color used for the blue team on radar is 0.08 0.25 1.0, as defined in src/common/Team.cxx. |
| 04:07.23 | BulletCatcher | Most of the other colors aren't "pure" either. |
| 04:08.09 | BulletCatcher | If it is going to be changed the whole setup needs to be considered. |
| 04:13.17 | Constitution | I think cyan is generally the color for the observer team... not that there are observer shots on the radar, except when the DR guy is around |
| 04:17.27 | BulletCatcher | Haven't seen him in a long time, fortunately. |
| 04:31.00 | the_map | I thought that obs were white |
| 04:31.04 | the_map | except in replays |
| 04:31.27 | the_map | also, I was suggesting for the radar, not necessarily anywhere else |
| 04:32.31 | the_map | although I guess other places would need to be cyan for consistency |
| 04:42.17 | the_map | but it would be a lot easier to see |
| 04:57.18 | Notify | 03BZFlag:Allejo * 8903 /Bz_setPlayerSpawnAtBase: Created page with "{{apicall | name = bz_setPlayerSpawnAtBase | description = Forces a player to spawn at their base on '''only''' their next respawn. | version = 2.4.3 | param1..." |
| 04:58.27 | Notify | 03BZFlag:Allejo * 8904 /Bz_getPlayerSpawnAtBase: Created page with "{{apicall | name = bz_getPlayerSpawnAtBase | description = Check if a player is supposed to spawn at their base on their next respawn | version = 2.4.3 | param1..." |
| 05:59.01 | *** join/#bzflag macsforme (~josh@bzflag/developer/Constitution) |
| 15:44.18 | *** join/#bzflag infobot (ibot@69-58-76-73.ut.vivintwireless.net) |
| 15:44.18 | *** topic/#bzflag is http://BZFlag.org || https://www.ohloh.net/p/bzflag || http://wiki.BZFlag.org/Getting_Help || Channel Logs: http://ibot.rikers.org/%23bzflag/ || 2.4.2 Current version https://goo.gl/ZaiNzX |
| 15:44.18 | *** mode/#bzflag [+v infobot] by ChanServ |
| 15:45.59 | *** join/#bzflag BZnotify (~BZnotify@192.30.252.40) |
| 15:45.59 | BZnotify | [13bzflag] 15blast007 pushed 8 new commits to 062.4: 02http://git.io/vOcsv |
| 15:45.59 | BZnotify | 13bzflag/062.4 1460d7e6b 15Scott Wichser: Unused values/variables. |
| 15:45.59 | BZnotify | 13bzflag/062.4 14ff9e58d 15Scott Wichser: Fix borked line break. |
| 15:45.59 | BZnotify | 13bzflag/062.4 14260df2c 15Scott Wichser: Null pointer dereference. |
| 15:45.59 | *** part/#bzflag BZnotify (~BZnotify@192.30.252.40) |
| 15:51.00 | blast007 | That push included a change to the OpenGL extensions detection code so that it should be only be checked each time the OpenGL context is initialized. I've tested it on Windows and also on Linux/SDL. Didn't test it on SDL2 or any other platforms. |
| 16:37.52 | Constitution | ~blast007++ |
| 16:42.06 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 16:42.06 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 16:45.38 | *** join/#bzflag DTRemenak (~DTRemenak@2605:e000:141b:412b:f938:acd6:7026:8eb2) |
| 16:45.38 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 16:45.38 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 16:51.00 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 16:51.00 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 17:38.32 | blast007 | https://github.com/BZFlag-Dev/bzflag/issues/11#issuecomment-127048661 So, should that be expected? |
| 17:43.16 | blast007 | Unrelated to that issue, but I noticed that CppUTest also has a HAVE_CONFIG_H define check in CppUTest/CppUTestConfig.h - don't quite know what effect that will have, but it's likely that when building our unit tests that it's including our config.h |
| 17:43.48 | blast007 | so... perhaps I should be looking into a different unit test library :) |
| 17:50.01 | blast007 | bleh.. seems it was just header ordering issues. Moved |
| 17:50.27 | blast007 | Moved #include "AccessControlList.h" above #include "CppUTest/TestHarness.h" and then it built |
| 17:54.15 | *** join/#bzflag BZnotify (~BZnotify@192.30.252.45) |
| 17:54.15 | BZnotify | [13bzflag] 15blast007 pushed 1 new commit to 062.4: 02http://git.io/vOc9R |
| 17:54.15 | BZnotify | 13bzflag/062.4 14b4674b4 15Scott Wichser: Fix the header ordering in our unit tests. Fixes #11 |
| 17:54.15 | *** part/#bzflag BZnotify (~BZnotify@192.30.252.45) |
| 18:31.09 | *** join/#bzflag echelon (~echelon@bzflag/player/echelon) |
| 18:33.14 | blast007 | The only other things I have planned to work on are the handful of HTTP plugins and maybe some further cppcheck cleanups. Anyone have anything else they feel should make it to 2.4.4? |
| 18:56.25 | *** join/#bzflag sam (~sam@poulet.zoy.org) |
| 18:56.32 | *** join/#bzflag Chestal (~thilo@vmax.unix-ag.uni-siegen.de) |
| 18:56.32 | *** mode/#bzflag [+o Chestal] by ChanServ |
| 18:56.48 | *** join/#bzflag dcat (~dcat@c-98-244-106-246.hsd1.va.comcast.net) |
| 19:10.56 | *** join/#bzflag khazhyk (~khazhyk@do-ny2-1.khaz.io) |
| 19:10.56 | *** join/#bzflag khazhyk (~khazhyk@unaffiliated/khazhyk) |
| 19:11.02 | *** join/#bzflag Schroeder (1000@charliebrown.outwardhosting.com) |
| 19:11.02 | *** join/#bzflag Schroeder (1000@unaffiliated/unclejimbob) |
| 19:11.06 | *** join/#bzflag catay (~smertens@valyria.catay.be) |
| 19:11.07 | *** join/#bzflag MonsieurApple (~MonsieurA@unaffiliated/mrapple) |
| 19:11.38 | *** join/#bzflag plastix- (~plastix@107.170.226.100) |
| 19:57.49 | blast007 | hmm, does anyone think it's a good idea to automatically generate the -publicaddr value when it's not specified? It currently does, but I don't that's very useful since we require public keys for hosting, and odds are it won't pick the right one matching the key. |
| 19:58.43 | blast007 | (plus, it was setting it to 0.0.0.0:5154 on my system, which is hardly useful) |
| 20:44.10 | blast007 | man, our HTTP plugin system really leaves a lot to be desired... as does bz_getReports() |
| 20:44.22 | blast007 | wonder if anyone actually uses bz_getReports() |
| 21:39.11 | *** join/#bzflag rodgort (~rodgort@2607:5300:100:200::160d) |
| 22:14.52 | blast007 | http://static.bzexcess.com/webReport.png |
| 22:23.22 | the_map | blast007: what do you think of making the blue tanks on the radar lighter so they can be seen more easily? |
| 22:24.01 | the_map | if you think that's a good idea, and tell me where to look/edit, I can see about doing the edit myself |
| 22:24.02 | blast007 | the_map: I had made such a change back in my old BZFlag XL fork |
| 22:24.25 | blast007 | (though, iirc, I did it by modifying the existing config file during the install process) |
| 22:24.39 | blast007 | *might* have changed the default too |
| 22:24.57 | the_map | I edited my conf file so that I can see blue tanks, but that only helps me |
| 22:25.18 | blast007 | what's the var name? |
| 22:25.34 | the_map | in the conf? blueradar |
| 22:25.42 | the_map | doesn't change the blue flag though |
| 22:25.49 | the_map | idk how to do that |
| 22:25.58 | *** join/#bzflag contempt (contempt@unaffiliated/contempt) |
| 22:25.59 | the_map | dunno if it changes the blue base |
| 22:26.22 | the_map | fwiw, "blueradar" also changes the color of sw's and L's |
| 22:26.36 | the_map | no clue why, but it does |
| 22:26.43 | blast007 | src/common/Team.cxx defines the default tank and radar colors |
| 22:28.12 | the_map | do you want me to try to change it? |
| 22:28.25 | the_map | or is that more for reference? |
| 22:28.48 | blast007 | you asked where it was - I was merely answering |
| 22:29.11 | the_map | <the_map> if you think that's a good idea, and tell me where to look/edit, I can see about doing the edit myself |
| 22:29.31 | the_map | if you thought it was a good idea to make the change |
| 22:29.35 | blast007 | if you find better colors, you could simply post them as an issue on the github repo |
| 22:30.34 | the_map | I was just thinking something lighter than the current blue, but I can (try to) post an issue on the github repo |
| 22:30.40 | the_map | not good with git |
| 22:30.45 | the_map | git/github |
| 22:48.21 | *** join/#bzflag BZnotify (~BZnotify@192.30.252.46) |
| 22:48.21 | BZnotify | [13bzflag] 15blast007 pushed 4 new commits to 062.4: 02http://git.io/vOCbP |
| 22:48.21 | BZnotify | 13bzflag/062.4 146041f57 15Scott Wichser: Only automatically generate a public address if the hostname is a FQDN or if the server address is not 0.0.0.0 or a private IP. |
| 22:48.21 | BZnotify | 13bzflag/062.4 148ff5b71 15Scott Wichser: Actually return data if we get something from bz_getPublicAddr(). |
| 22:48.21 | BZnotify | 13bzflag/062.4 14750ffe4 15Scott Wichser: Rename the template file to match what the plugin looks for. |
| 22:48.21 | *** part/#bzflag BZnotify (~BZnotify@192.30.252.46) |
