| 00:17.59 | *** join/#bzflag infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
| 00:17.59 | *** topic/#bzflag is https://BZFlag.org || https://www.openhub.net/p/bzflag || https://bzflag.org/help || Channel Logs: http://infobot.rikers.org/%23bzflag/ || Current version: 2.4.18 || New shiny website! https://forums.bzflag.org/viewtopic.php?f=8&t=20201 |
| 00:18.00 | *** mode/#bzflag [+v infobot] by ChanServ |
| 00:19.11 | Zehra | On the death event, does "flagHeldWhenKilled" have any delays with the data updating? |
| 00:19.48 | Zehra | In the sense of where player drops the flag before death, but it still reported as having held it on death. |
| 00:21.11 | Zehra | Currently the data is being handled by a few functions, so minimum delay might happen there, but since the data being grabbed is the latest, I'm unsure what might be causing it. |
| 00:24.24 | Delusional | can you get the flagDropped event seperately? â¦. if that even exists |
| 00:24.58 | Zehra | We can. |
| 01:09.40 | *** join/#bzflag Sgeo__ (~Sgeo@ool-18b98995.dyn.optonline.net) |
| 02:23.47 | allejo | the death event does not report what flag a player was carrying. nor does the flag drop event specify why a flag was dropped. `flagHeldWhenKilled` is an approximation |
| 04:00.49 | BZNotify | 02master @ bzflag.org: 03allejo pushed 1 commit (06https://git.io/Jengx): |
| 04:00.50 | BZNotify | 02master @ bzflag.org: 03allejo 149bb82a: fix Sass compiler warning in newer versions of stakx (06https://git.io/Jengp) |
| 04:09.45 | BZNotify | 02feature/flag-list-table @ bzflag.org: 03allejo 05force pushed 1 commit (06https://git.io/Jen2T): |
| 04:09.46 | BZNotify | 02feature/flag-list-table @ bzflag.org: 03allejo 144ff6a2: Render flag list as table with abbrs (06https://git.io/Jen2k) |
| 04:46.24 | *** join/#bzflag Sgeo (~Sgeo@ool-18b98995.dyn.optonline.net) |
| 12:34.11 | *** mode/#bzflag [-bbbb *!*Flak18@2001 558:6030:27:cdbc:d363:dd9e:* *!*alpha1@*.cust.tzulo.com *!*@*89.102.81.95 *!*@190.167.0.0/16] by blast007 |
| 12:37.07 | *** mode/#bzflag [-bbbb *!*@gateway/web/freenode/ip.190.167* *!*jh@*.bb.dnainternet.fi *!*@91.210.100.0/22 *!*hw3*@*] by blast007 |
| 12:41.41 | *** mode/#bzflag [-bbbb *!*@pool-74-109-249-118.pitbpa.fios.verizon.net *!*self@unaffiliated/remote *!*@64.55.14*.* jacko*!*@*] by blast007 |
| 12:43.16 | *** mode/#bzflag [-bbbb *!*@*.nessus.at *!*ALLEJO@*.rev.nessus.at *!*HAHAHAHA@82.102.20.* *!*HAHAHA@185.156.174.*] by blast007 |
| 12:43.20 | *** mode/#bzflag [-b *!*Blast@89.249.73.*] by blast007 |
| 12:44.24 | *** mode/#bzflag [-bbbb *!*i.resurre@46.165.243.* *!*@*.sl-reverse.com *!*Blast@*.4b.01a8.ip4.static.sl-reverse.com *!*@72.8e.39a9.ip4.static.sl-reverse.com] by blast007 |
| 12:44.27 | *** mode/#bzflag [-b *!*Blast@*.4b.01a8.ip4.static.sl-reverse.com] by blast007 |
| 12:45.24 | *** mode/#bzflag [-bbb *!*@91.109.20.* *!*androirc@173.209.57.* *!*@*/91.109.20.218] by blast007 |
| 12:47.55 | *** mode/#bzflag [-bbbb *!*WeAreLegi@gateway/tor-sasl/* *!*WeAreLegi@gateway/tor-sasl/* *!*@cpe-142-129-187-83.socal.res.rr.com *!*@gateway/web/freenode/ip.188.21.3.113] by blast007 |
| 12:59.45 | *** mode/#bzflag [-bbbb *!*@188.21.3.113 chatter*!*@* *!*@*95.85.57.60 gk_*!*@*] by blast007 |
| 13:00.14 | *** mode/#bzflag [-bbbb IRCFrEAK*!*@* gk*!*su@* *!*gk.1wm.su@* *!*@67.215.7.105] by blast007 |
| 13:49.22 | *** join/#bzflag alfa1 (~alfa1@181.95.189.93) |
| 13:53.22 | *** mode/#bzflag [+v alfa1] by blast007 |
| 13:55.14 | alfa1 | Hi. I think server variables are not documented still. Are they meant to be? (Since Wiki is somewhat off.) |
| 13:55.16 | alfa1 | Good work documenting things on the page, BTW. |
| 14:07.28 | alfa1 | Then Wiki will be definitively out of the project? Seems like not a good idea. |
| 14:13.21 | blast007 | yes, the wiki will get phased out sooner than later |
| 14:13.35 | blast007 | we want to have all the documentation on our main website |
| 14:14.33 | blast007 | we could look at documenting variables for the 2.6 release |
| 14:16.59 | alfa1 | Not sure but maybe Wiki could help for documenting secondary things like a guide to make maps (since this is not good for forums also). |
| 14:18.07 | blast007 | why couldn't that be on the main website? |
| 14:19.18 | blast007 | one big reason I want the wiki gone is so that I don't have to maintain yet another web application, and another is so that we have a more organizaed set of information |
| 14:19.31 | blast007 | we had redundant information on the wiki |
| 14:26.03 | allejo | any sort of documentation should belong on the website. that includes BZDB variables and map making |
| 14:26.36 | alfa1 | Remember an important thing in internet is anonymity; then, on Wiki, anybody could contribute. I remember, though, that it was needed some kind of control on Wiki to avoid abuse. Wikis in Free software world is an option. |
| 14:26.38 | alfa1 | Regarding web app maintenance, is it so hard to make for a Wiki? |
| 14:26.39 | alfa1 | Apart, if you start putting lot of info on the page, it possibly will become overloaded. This is why I said "secondary info" vs "primary" one. |
| 14:27.26 | allejo | anonymity on the internet is open to abuse and headaches |
| 14:28.02 | allejo | if you want to contribute to documentation, follow the standard practice amongst thousands of sites nowadays. submit a PR on github :) |
| 14:28.59 | alfa1 | (Another option, possibly, would be letting users put secondary info in forums and then you move it to the web page.) |
| 14:29.32 | allejo | no. that's more work us (a team with already limited resources) |
| 14:30.45 | allejo | go try contributing to the Microsoft documentation site without submitting a PR on github |
| 14:32.17 | alfa1 | I am not saying people can't nowadays put info on forums; just I am saying that, after eventually people do it, admins could get info from there and making a doc. As an option to a wiki. |
| 14:33.06 | allejo | then that'd be plagiarizing |
| 14:34.17 | allejo | my statement still stands. it's more work for us to copy things over. where if we got a PR, we just have to read through it and make suggestions and then click a button that says "merge" |
| 14:34.22 | allejo | and voila! |
| 14:34.56 | allejo | we also have a record of who wrote the documentation and when all in one place, instead of looking in several places |
| 14:35.41 | allejo | "did alpha write these docs? where was it on the forums? did we have to rewrite any of it? were there grammar mistakes?" etc. |
| 14:36.09 | alfa1 | Ah well... good point about copyright I guess... Then Wiki would remain as a good option, in my point of view. |
| 14:37.00 | allejo | what part of "that's another service we have to maintain" and "a team with limited resources" do you not comprehend? |
| 14:37.15 | allejo | not only that, that's another place for _players_ to look |
| 14:37.27 | allejo | "oh is that info on the main website? or on the wiki?" |
| 14:40.16 | alfa1 | what about manuals documentation? How would them relate to web one? |
| 14:41.18 | allejo | manual documentation? like how to play the game? we take screenshots and put them on the site under a section called "how to play" |
| 14:41.26 | allejo | heck we can even have videos too! |
| 14:41.46 | alfa1 | bzfs, bzflag, bzw and bzadmin apps ones |
| 14:42.06 | alfa1 | (bzw is not an app) |
| 14:42.31 | blast007 | the man pages |
| 14:42.35 | alfa1 | (manual pages I meant) |
| 14:42.40 | blast007 | but what about them? |
| 14:42.44 | allejo | they exist as man files in the main repo. we could write a parser and then load them into the website if wanted to |
| 14:43.21 | allejo | if you wanna contribute to those man pages, guess what? send a PR! :) |
| 14:43.45 | alfa1 | ah, good, just wondering, since deleting them is not good |
| 14:44.12 | blast007 | they'lll continue to be maintained for offline documentation |
| 14:44.31 | alfa1 | nice, thanks for the time |
| 14:45.21 | alfa1 | I contribute about playing, advertising, hosting and such; but thanks for your work, BTW :) |
| 14:54.23 | *** join/#bzflag Sgeo_ (~Sgeo@ool-18b98995.dyn.optonline.net) |
| 15:01.12 | *** join/#bzflag Sgeo (~Sgeo@ool-18b98995.dyn.optonline.net) |
| 16:54.44 | *** join/#bzflag Sgeo_ (~Sgeo@ool-18b98995.dyn.optonline.net) |
| 17:19.24 | *** join/#bzflag Juesto (~LimeC@unaffiliated/juest) |
| 18:09.25 | *** join/#bzflag Sgeo__ (~Sgeo@ool-18b98995.dyn.optonline.net) |
| 18:11.55 | *** join/#bzflag Sgeo (~Sgeo@ool-18b98995.dyn.optonline.net) |
| 18:13.26 | *** join/#bzflag Sgeo_ (~Sgeo@ool-18b98995.dyn.optonline.net) |
| 18:16.17 | *** join/#bzflag Sgeo__ (~Sgeo@ool-18b98995.dyn.optonline.net) |
| 18:18.38 | *** join/#bzflag Sgeo (~Sgeo@ool-18b98995.dyn.optonline.net) |
| 18:22.51 | *** join/#bzflag Sgeo_ (~Sgeo@ool-18b98995.dyn.optonline.net) |
| 18:24.07 | *** join/#bzflag Sgeo__ (~Sgeo@ool-18b98995.dyn.optonline.net) |
| 19:06.46 | *** join/#bzflag Sgeo (~Sgeo@ool-18b98995.dyn.optonline.net) |
| 21:43.25 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 22:19.47 | *** join/#bzflag spldart (~james@bzflag/contributor/spldart) |
| 22:19.48 | *** mode/#bzflag [+v spldart] by ChanServ |
| 22:50.02 | BZNotify | bzflag: 03Zehra 03opened issue #219 "BZFS vulnerable to exponential entity expansion attack" (06https://git.io/Jen5b) |
| 22:52.59 | blast007 | *pinky to mouth* One BIIIILLLION boxes! |
| 22:53.51 | blast007 | Zehra: where is it crashing? |
| 22:54.12 | blast007 | it is possibly just exhausting the RAM on your computer? |
| 22:56.46 | Zehra | blast007: It crashes roughly about 1 minute into the map generation. It exhausts the RAM in my computer as well. |
| 22:57.09 | blast007 | how much RAM do you have? |
| 22:57.38 | Zehra | 2GB on netbook. |
| 22:58.33 | blast007 | oh, okay.. so a strong breeze could exhaust that :) |
| 22:58.43 | blast007 | tries with 32GB |
| 23:00.44 | blast007 | though I guess with a Windows build that much RAM doesn't matter, since the binary is still 32-bit |
| 23:04.18 | Zehra | Makes sense, but BZFS still shouldn't try to successfully generate maps with over a million objects in them. |
| 23:04.36 | Zehra | Or at least require an additional option for "forcing" it to occur. |
| 23:04.52 | blast007 | why? |
| 23:07.34 | Zehra | I think it would offer a minor bit of protection, for instance if a public map hosting service is made and maps like the one above are provided. |
| 23:09.14 | Zehra | Maybe a better idea is being able to determine how many triangles will be rendered within the map and providing an optional limit. |
| 23:09.16 | blast007 | if you're hosting a public service, you should be implementing some of that protection yourself |
| 23:13.30 | Zehra | I agree. |
| 23:14.09 | Zehra | Forgive me for asking, but what is the design plans for the project, in regards to the server? |
| 23:14.39 | blast007 | curious to see if the OOM killer will do anything on linux :) |
| 23:14.56 | blast007 | bzfs is hovering around 14GB usage |
| 23:15.29 | blast007 | haha, "Killed" |
| 23:15.44 | blast007 | wonder how much RAM this would need to actually run |
| 23:18.18 | blast007 | Zehra: do you know about 'ulimit'? |
| 23:18.57 | Zehra | Nope, it would be the first time hearing of it. |
| 23:19.32 | blast007 | lets you set various limits on Linux, such as memory limits, open file limits |
| 23:21.15 | Zehra | Ah, so my concern would be irrelevant, due to the protections within the system. |
| 23:21.57 | blast007 | default, at least on Debian, is 'unlimited' memory usage |
| 23:22.10 | blast007 | but if you're running a public service like that, you need to tweak things |
| 23:24.16 | Zehra | Makes sense. |
| 23:29.36 | Zehra | I guess I'll close the issue, it might be good to add a side note or something about ulimit, but looks like my concerns are addressed. |
| 23:32.38 | BZNotify | bzflag: 03Zehra commented on issue #219 "BZFS vulnerable to exponential entity expansion attack" (06https://git.io/JendC): Issue addressed by "ulimit" to prevent abuse. |
| 23:32.39 | BZNotify | bzflag: 03Zehra 04closed issue #219 |
| 23:36.10 | *** join/#bzflag Foo_man_choo (~spldart@c-73-155-11-165.hsd1.tx.comcast.net) |