| *** infobot <infobot!ibot@c-174-52-60-165.hsd1.ut.comcast.net> has quit IRC (Remote host closed the connection) | 00:17 | |
| *** infobot <infobot!ibot@c-174-52-60-165.hsd1.ut.comcast.net> has joined #bzflag | 00:17 | |
| *** ChanServ sets mode: +v infobot | 00:17 | |
| Zehra | On the death event, does "flagHeldWhenKilled" have any delays with the data updating? | 00:19 |
|---|---|---|
| Zehra | In the sense of where player drops the flag before death, but it still reported as having held it on death. | 00:19 |
| 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:21 |
| Delusional | can you get the flagDropped event seperately? …. if that even exists | 00:24 |
| Zehra | We can. | 00:24 |
| *** Sgeo__ <Sgeo__!~Sgeo@ool-18b98995.dyn.optonline.net> has joined #bzflag | 01:09 | |
| *** Sgeo_ <Sgeo_!~Sgeo@ool-18b98995.dyn.optonline.net> has quit IRC (Ping timeout: 240 seconds) | 01:12 | |
| *** Zehra <Zehra!~Zehra@unaffiliated/zehra> has quit IRC (Quit: Gone for now.) | 01:56 | |
| 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 | 02:23 |
| BZNotify | master @ bzflag.org: allejo pushed 1 commit (https://git.io/Jengx): | 04:00 |
| BZNotify | master @ bzflag.org: allejo 9bb82a: fix Sass compiler warning in newer versions of stakx (https://git.io/Jengp) | 04:00 |
| BZNotify | feature/flag-list-table @ bzflag.org: allejo force pushed 1 commit (https://git.io/Jen2T): | 04:09 |
| BZNotify | feature/flag-list-table @ bzflag.org: allejo 4ff6a2: Render flag list as table with abbrs (https://git.io/Jen2k) | 04:09 |
| *** Sgeo__ <Sgeo__!~Sgeo@ool-18b98995.dyn.optonline.net> has quit IRC (Read error: Connection reset by peer) | 04:42 | |
| *** Sgeo <Sgeo!~Sgeo@ool-18b98995.dyn.optonline.net> has joined #bzflag | 04:46 | |
| *** blast007 sets mode: -bbbb *!*Flak18@2001:558:6030:27:cdbc:d363:dd9e:* *!*alpha1@*.cust.tzulo.com *!*@*89.102.81.95 *!*@190.167.0.0/16 | 12:34 | |
| *** blast007 sets mode: -bbbb *!*@gateway/web/freenode/ip.190.167* *!*jh@*.bb.dnainternet.fi *!*@91.210.100.0/22 *!*hw3*@* | 12:37 | |
| *** blast007 sets mode: -bbbb *!*@pool-74-109-249-118.pitbpa.fios.verizon.net *!*self@unaffiliated/remote *!*@64.55.14*.* jacko*!*@* | 12:41 | |
| *** blast007 sets mode: -bbbb *!*@*.nessus.at *!*ALLEJO@*.rev.nessus.at *!*HAHAHAHA@82.102.20.* *!*HAHAHA@185.156.174.* | 12:43 | |
| *** blast007 sets mode: -b *!*Blast@89.249.73.* | 12:43 | |
| *** blast007 sets mode: -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 | 12:44 | |
| *** blast007 sets mode: -b *!*Blast@*.4b.01a8.ip4.static.sl-reverse.com | 12:44 | |
| *** blast007 sets mode: -bbb *!*@91.109.20.* *!*androirc@173.209.57.* *!*@*/91.109.20.218 | 12:45 | |
| *** blast007 sets mode: -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 | 12:47 | |
| *** blast007 sets mode: -bbbb *!*@188.21.3.113 chatter*!*@* *!*@*95.85.57.60 gk_*!*@* | 12:59 | |
| *** blast007 sets mode: -bbbb IRCFrEAK*!*@* gk*!*su@* *!*gk.1wm.su@* *!*@67.215.7.105 | 13:00 | |
| *** alfa1 <alfa1!~alfa1@181.95.189.93> has joined #bzflag | 13:49 | |
| *** blast007 sets mode: +v alfa1 | 13:53 | |
| alfa1 | Hi. I think server variables are not documented still. Are they meant to be? (Since Wiki is somewhat off.) | 13:55 |
| alfa1 | Good work documenting things on the page, BTW. | 13:55 |
| alfa1 | Then Wiki will be definitively out of the project? Seems like not a good idea. | 14:07 |
| blast007 | yes, the wiki will get phased out sooner than later | 14:13 |
| blast007 | we want to have all the documentation on our main website | 14:13 |
| blast007 | we could look at documenting variables for the 2.6 release | 14:14 |
| 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:16 |
| blast007 | why couldn't that be on the main website? | 14: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 |
| blast007 | we had redundant information on the wiki | 14:19 |
| allejo | any sort of documentation should belong on the website. that includes BZDB variables and map making | 14:26 |
| 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 |
| alfa1 | Regarding web app maintenance, is it so hard to make for a Wiki? | 14:26 |
| 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:26 |
| allejo | anonymity on the internet is open to abuse and headaches | 14:27 |
| allejo | if you want to contribute to documentation, follow the standard practice amongst thousands of sites nowadays. submit a PR on github :) | 14:28 |
| alfa1 | (Another option, possibly, would be letting users put secondary info in forums and then you move it to the web page.) | 14:28 |
| allejo | no. that's more work us (a team with already limited resources) | 14:29 |
| allejo | go try contributing to the Microsoft documentation site without submitting a PR on github | 14:30 |
| 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:32 |
| allejo | then that'd be plagiarizing | 14:33 |
| 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 |
| allejo | and voila! | 14:34 |
| allejo | we also have a record of who wrote the documentation and when all in one place, instead of looking in several places | 14:34 |
| 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:35 |
| alfa1 | Ah well... good point about copyright I guess... Then Wiki would remain as a good option, in my point of view. | 14:36 |
| allejo | what part of "that's another service we have to maintain" and "a team with limited resources" do you not comprehend? | 14:37 |
| allejo | not only that, that's another place for _players_ to look | 14:37 |
| allejo | "oh is that info on the main website? or on the wiki?" | 14:37 |
| alfa1 | what about manuals documentation? How would them relate to web one? | 14:40 |
| 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 |
| allejo | heck we can even have videos too! | 14:41 |
| alfa1 | bzfs, bzflag, bzw and bzadmin apps ones | 14:41 |
| alfa1 | (bzw is not an app) | 14:42 |
| blast007 | the man pages | 14:42 |
| alfa1 | (manual pages I meant) | 14:42 |
| blast007 | but what about them? | 14:42 |
| 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:42 |
| allejo | if you wanna contribute to those man pages, guess what? send a PR! :) | 14:43 |
| alfa1 | ah, good, just wondering, since deleting them is not good | 14:43 |
| blast007 | they'lll continue to be maintained for offline documentation | 14:44 |
| alfa1 | nice, thanks for the time | 14:44 |
| alfa1 | I contribute about playing, advertising, hosting and such; but thanks for your work, BTW :) | 14:45 |
| *** alfa1 <alfa1!~alfa1@181.95.189.93> has quit IRC (Remote host closed the connection) | 14:52 | |
| *** Sgeo_ <Sgeo_!~Sgeo@ool-18b98995.dyn.optonline.net> has joined #bzflag | 14:54 | |
| *** Sgeo <Sgeo!~Sgeo@ool-18b98995.dyn.optonline.net> has quit IRC (Ping timeout: 265 seconds) | 14:57 | |
| *** Sgeo <Sgeo!~Sgeo@ool-18b98995.dyn.optonline.net> has joined #bzflag | 15:01 | |
| *** Sgeo_ <Sgeo_!~Sgeo@ool-18b98995.dyn.optonline.net> has quit IRC (Ping timeout: 268 seconds) | 15:04 | |
| *** Sgeo_ <Sgeo_!~Sgeo@ool-18b98995.dyn.optonline.net> has joined #bzflag | 16:54 | |
| *** Sgeo <Sgeo!~Sgeo@ool-18b98995.dyn.optonline.net> has quit IRC (Ping timeout: 268 seconds) | 16:57 | |
| *** Juesto <Juesto!~LimeC@unaffiliated/juest> has joined #bzflag | 17:19 | |
| *** Sgeo__ <Sgeo__!~Sgeo@ool-18b98995.dyn.optonline.net> has joined #bzflag | 18:09 | |
| *** Sgeo <Sgeo!~Sgeo@ool-18b98995.dyn.optonline.net> has joined #bzflag | 18:11 | |
| *** Sgeo_ <Sgeo_!~Sgeo@ool-18b98995.dyn.optonline.net> has quit IRC (Ping timeout: 245 seconds) | 18:12 | |
| *** Sgeo_ <Sgeo_!~Sgeo@ool-18b98995.dyn.optonline.net> has joined #bzflag | 18:13 | |
| *** Sgeo__ <Sgeo__!~Sgeo@ool-18b98995.dyn.optonline.net> has quit IRC (Ping timeout: 240 seconds) | 18:13 | |
| *** Sgeo__ <Sgeo__!~Sgeo@ool-18b98995.dyn.optonline.net> has joined #bzflag | 18:16 | |
| *** Sgeo <Sgeo!~Sgeo@ool-18b98995.dyn.optonline.net> has quit IRC (Ping timeout: 265 seconds) | 18:17 | |
| *** Sgeo <Sgeo!~Sgeo@ool-18b98995.dyn.optonline.net> has joined #bzflag | 18:18 | |
| *** Sgeo_ <Sgeo_!~Sgeo@ool-18b98995.dyn.optonline.net> has quit IRC (Ping timeout: 265 seconds) | 18:20 | |
| *** Sgeo__ <Sgeo__!~Sgeo@ool-18b98995.dyn.optonline.net> has quit IRC (Ping timeout: 265 seconds) | 18:21 | |
| *** Sgeo_ <Sgeo_!~Sgeo@ool-18b98995.dyn.optonline.net> has joined #bzflag | 18:22 | |
| *** Sgeo <Sgeo!~Sgeo@ool-18b98995.dyn.optonline.net> has quit IRC (Ping timeout: 240 seconds) | 18:23 | |
| *** Sgeo__ <Sgeo__!~Sgeo@ool-18b98995.dyn.optonline.net> has joined #bzflag | 18:24 | |
| *** Sgeo_ <Sgeo_!~Sgeo@ool-18b98995.dyn.optonline.net> has quit IRC (Ping timeout: 245 seconds) | 18:27 | |
| *** Sgeo <Sgeo!~Sgeo@ool-18b98995.dyn.optonline.net> has joined #bzflag | 19:06 | |
| *** Sgeo__ <Sgeo__!~Sgeo@ool-18b98995.dyn.optonline.net> has quit IRC (Ping timeout: 245 seconds) | 19:09 | |
| *** Zehra <Zehra!~Zehra@unaffiliated/zehra> has joined #bzflag | 21:43 | |
| *** spldart <spldart!~james@bzflag/contributor/spldart> has joined #bzflag | 22:19 | |
| *** ChanServ sets mode: +v spldart | 22:19 | |
| BZNotify | bzflag: Zehra opened issue #219 "BZFS vulnerable to exponential entity expansion attack" (https://git.io/Jen5b) | 22:50 |
| blast007 | *pinky to mouth* One BIIIILLLION boxes! | 22:52 |
| blast007 | Zehra: where is it crashing? | 22:53 |
| blast007 | it is possibly just exhausting the RAM on your computer? | 22:54 |
| Zehra | blast007: It crashes roughly about 1 minute into the map generation. It exhausts the RAM in my computer as well. | 22:56 |
| blast007 | how much RAM do you have? | 22:57 |
| Zehra | 2GB on netbook. | 22:57 |
| blast007 | oh, okay.. so a strong breeze could exhaust that :) | 22:58 |
| * blast007 tries with 32GB | 22:58 | |
| blast007 | though I guess with a Windows build that much RAM doesn't matter, since the binary is still 32-bit | 23:00 |
| Zehra | Makes sense, but BZFS still shouldn't try to successfully generate maps with over a million objects in them. | 23:04 |
| Zehra | Or at least require an additional option for "forcing" it to occur. | 23:04 |
| blast007 | why? | 23:04 |
| 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:07 |
| 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 |
| blast007 | if you're hosting a public service, you should be implementing some of that protection yourself | 23:09 |
| Zehra | I agree. | 23:13 |
| Zehra | Forgive me for asking, but what is the design plans for the project, in regards to the server? | 23:14 |
| blast007 | curious to see if the OOM killer will do anything on linux :) | 23:14 |
| blast007 | bzfs is hovering around 14GB usage | 23:14 |
| blast007 | haha, "Killed" | 23:15 |
| blast007 | wonder how much RAM this would need to actually run | 23:15 |
| blast007 | Zehra: do you know about 'ulimit'? | 23:18 |
| Zehra | Nope, it would be the first time hearing of it. | 23:18 |
| blast007 | lets you set various limits on Linux, such as memory limits, open file limits | 23:19 |
| Zehra | Ah, so my concern would be irrelevant, due to the protections within the system. | 23:21 |
| blast007 | default, at least on Debian, is 'unlimited' memory usage | 23:21 |
| blast007 | but if you're running a public service like that, you need to tweak things | 23:22 |
| Zehra | Makes sense. | 23:24 |
| 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:29 |
| BZNotify | bzflag: Zehra commented on issue #219 "BZFS vulnerable to exponential entity expansion attack" (https://git.io/JendC): Issue addressed by "ulimit" to prevent abuse. | 23:32 |
| BZNotify | bzflag: Zehra closed issue #219 | 23:32 |
| *** Foo_man_choo <Foo_man_choo!~spldart@c-73-155-11-165.hsd1.tx.comcast.net> has joined #bzflag | 23:36 | |
| *** Juesto <Juesto!~LimeC@unaffiliated/juest> has quit IRC (Ping timeout: 245 seconds) | 23:48 | |
Generated by irclog2html.py 2.17.3.dev0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!