| 00:20.32 | *** join/#bzflag infobot (ibot@rikers.org) |
| 00:20.32 | *** topic/#bzflag is https://BZFlag.org || http://ohloh.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || 2.4.12 released! https://forums.bzflag.org/viewtopic.php?f=62&t=19720 |
| 00:20.33 | *** mode/#bzflag [+v infobot] by ChanServ |
| 00:31.00 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-pepyxmwtktiiqfvl) |
| 01:27.16 | *** join/#bzflag galileo_ (~QUJAAAAAA@d216-108-171-73.nt.northwestel.net) |
| 04:33.41 | macsforme | one more thing to fix before 2.4.14: https://github.com/BZFlag-Dev/bzflag/issues/104 |
| 05:06.46 | RoscoePColtrane | @JeffM of course there is a big difference between atomic clock resolutions and atomic clock accuracy... |
| 05:07.10 | RoscoePColtrane | std::chrono supports arbitrary resolutions :) |
| 05:27.50 | JeffM | System.Diagnostics.Stopwatch uses the highest resolution the running device can do |
| 05:28.03 | JeffM | so it's as good as you are going to get for practical purposes |
| 05:36.28 | allejo | 2.4.14 milestone on gh, https://github.com/BZFlag-Dev/bzflag/milestone/7 |
| 05:36.43 | allejo | should add anything else that needs to be done there so we don't forget anything :) |
| 07:51.08 | *** join/#bzflag zuii (~cauchy@BC9C5B1F.mobile.pool.telekom.hu) |
| 10:08.43 | *** join/#bzflag zuii (~cauchy@BC9C5B1F.mobile.pool.telekom.hu) |
| 15:58.40 | *** join/#bzflag EvilJStoker (jstoker@unaffiliated/jstoker) |
| 16:08.05 | *** join/#bzflag brad (~brad@stupid.h-o-s-t.name) |
| 16:08.06 | *** join/#bzflag brad (~brad@unaffiliated/brad) |
| 16:13.44 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-pmxjdxtxuolsxgfo) |
| 20:28.11 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 21:55.43 | Zehra | I might be a little slow and this probably isn't the direction the project is headed, but I thought of this idea. |
| 21:56.09 | Zehra | Like since there is variables for laser, mg..etc, why not having a few of them for geno? |
| 21:57.31 | Zehra | Maybe like _rogueGeno, _genoShield, and maybe _protectTeammates |
| 21:57.57 | blast007 | or _removeGenoFromGame |
| 21:58.24 | blast007 | I think the general consensus is that geno should be removed from the game |
| 21:58.32 | allejo | /set _removeGenoFromGame 0.3 |
| 21:59.00 | blast007 | allejo: setting it to 2.0 is the same as the string literal VeryYes |
| 21:59.49 | allejo | it would genuinely not surprise me if there was a condition for matching "VeryYes" in our BZDB booleans |
| 21:59.59 | blast007 | heh |
| 22:31.32 | JeffM | removing geno an pushing it to a plugin will be the first pull request I do when you are ready for active 2.5 development. |
| 22:32.11 | JeffM | then the core bzfs will be in sync with my bzfs codebase :) |
| 22:39.23 | allejo | https://github.com/BZFlag-Dev/bzflag/issues/106 ref: https://flatpak.org/ |
| 23:10.44 | macsforme | not too familiar with flatpak, but I'd be interested in looking into doing a snap |
| 23:13.36 | allejo | canonical's thing? |
| 23:17.37 | macsforme | yeah |
| 23:18.39 | allejo | do you know how it handles linking to things? think that was a concern/question brought up before with snaps |
| 23:19.22 | macsforme | I think everything a snap links to is included in the package |
| 23:21.49 | macsforme | I haven't actually tried them out yet, though |
| 23:23.42 | macsforme | I do think we need to move away from being stuck on one protocol version for long durations of time... it holds back a lot of improvements we could be making |
| 23:24.28 | macsforme | and linux packaging seems to be the main obstacle for that |
| 23:25.08 | allejo | http://infobot.rikers.org/%23bzflag/20170129.html.gz think snaps/flatpak can be revisited nowadays |