| 02:29.46 | khonkhortisan | "My, how full-width your numerals are!" "All the better to break things with!" |
| 02:54.53 | khonkhortisan | 12345ï¼ï¼ï¼ï¼ï¼ |
| 03:10.03 | *** join/#bzflag JeffM (~JeffM@2605:e000:7d02:c700:b59a:75b4:8530:bb4b) |
| 03:52.06 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 03:56.03 | *** join/#bzflag JeffM (~JeffM@2605:e000:7d02:c700:8982:8aba:612c:6365) |
| 04:32.17 | *** join/#bzflag Snake12534 (635cd32e@gateway/web/freenode/ip.99.92.211.46) |
| 04:32.40 | *** join/#bzflag Lep (46b583ce@gateway/web/freenode/ip.70.181.131.206) |
| 04:34.52 | Snake12534 | hi Lep |
| 05:02.04 | TD-Linux | is there anything in bzfs that scales with map complexity? |
| 05:02.22 | TD-Linux | other than initial RAM usage |
| 05:10.28 | allejo | I'd assume the amount of vertices and possibly calculating ricos off of all the faces in complex meshes? |
| 05:18.27 | JeffM | the spawn code |
| 05:18.34 | JeffM | the server dosn't do any collisions |
| 05:18.41 | JeffM | so it doesn't do ricos |
| 05:18.42 | *** part/#bzflag Snake12534 (635cd32e@gateway/web/freenode/ip.99.92.211.46) |
| 05:19.09 | JeffM | the spawn code has to use the octree to compute a valid spawn location |
| 05:19.16 | JeffM | the more complex that tree, the longer it takes |
| 05:19.18 | Flash | why would the spawn code scale with map complexity? |
| 05:19.26 | Flash | I type too slowly |
| 05:19.30 | JeffM | more objects to put a tank between :) |
| 05:19.53 | JeffM | finding a gap between 3 objects is faster then beween 3000 |
| 05:21.08 | JeffM | the octree helps it scale well for most maps |
| 05:21.15 | JeffM | it spreads the load out logically |
| 05:21.25 | JeffM | but it still takes time with more objects |
| 05:24.51 | JeffM | THere is actualy a timer on the spawn code, if it takes too long we just pick a random place |
| 05:25.11 | JeffM | thats why some maps that are covered or have very little open area sometimes have spawn bugs |
| 05:25.24 | JeffM | it took too long to figure out a good location |
| 05:33.50 | Flash | would it be worthwhile to cache spawn locations and pick a valid one if we can't compute one fast enough? |
| 05:35.34 | JeffM | can't |
| 05:35.43 | JeffM | the system uses the locaton of other tanks |
| 05:35.48 | JeffM | they change over time :) |
| 05:36.40 | JeffM | you'd have to cache off a large number of them, then test them to see if they were near players |
| 05:36.48 | JeffM | better would be to spawn a spawn thread |
| 05:36.59 | JeffM | and let it compute them as long as it takes |
| 05:38.22 | Flash | right, but if you run out of time trying to compute a "random" spawn location, then trying a finite list of known ones to see if they are near other tanks would seem to be a reasonable fallback |
| 05:38.40 | Flash | It should only be an issue for a very dense map with few spawn locations, right? |
| 05:38.50 | JeffM | we only "run out of time" now because it's done in the main thread |
| 05:38.58 | JeffM | eveyrone goes NR if it takes too long |
| 05:39.07 | JeffM | so let it run longer, the player waiting is not playing anyway |
| 05:39.25 | Flash | ok. You are right then, spawning a thread (or better, a thread pool) would be the way to go |
| 05:39.47 | JeffM | we have this timeout problem for a lot of things |
| 05:39.52 | JeffM | bad plugins can add lag |
| 05:39.59 | JeffM | since it all runs in the same thread |
| 05:40.15 | JeffM | networking should be in a thread, sim in a thread, and then gamelogic in a thread |
| 05:40.25 | Flash | the question just came up in mofo about where scaling would work better threaded |
| 05:40.53 | JeffM | yeah tht's how you scale well, do more stuff at a time |
| 05:46.09 | *** join/#bzflag mdskpr (~quassel@li59-174.members.linode.com) |
| 05:49.21 | JeffM | the gameplay itself won't scale much more |
| 05:49.44 | JeffM | but we could make a single "server" that can host a large nubmer of games |
| 05:57.48 | khonkhortisan | or previously-separate maps in the same supermap with people spawning on their own side of the fence |
| 06:04.49 | *** join/#bzflag JeffM (~JeffM@2605:e000:7d02:c700:8148:b41c:c166:6b00) |
| 06:24.06 | Not-9d73 | [02bzflag-import-3] 07jwmelto pushed 031 commit to 03v2_4_x [+0/-0/±1] 13http://git.io/GIU4Ng |
| 06:24.07 | Not-9d73 | [02bzflag-import-3] 07Jim Melton 03df6db83 - Remove superfluous memory allocation. Valgrind complains (not sure why) |
| 06:33.22 | TD-Linux | also wow running a bzflag server is kind of annoying |
| 06:34.50 | TD-Linux | the problem I was seeing is at loads above about 10 tanks, tanks going NR occasionally (well the actual server owner is, I'm running the vm that it's on) |
| 06:35.10 | TD-Linux | now someone is DoSing the bzfs server |
| 07:09.11 | allejo | thanks flash for that commit |
| 07:09.29 | allejo | TD-Linux, DoSing as in multiple players from a single IP? |
| 07:10.23 | allejo | "iptables -I INPUT -p tcp -m tcp --dport 5150:5160 -m connlimit --connlimit-above 5 -j REJECT" should suffice to prevent that from happening |
| 07:10.24 | TD-Linux | allejo, yes as far as I can tell it's one player with many connections who keeps on changing IP. I can sorta fix it with a firewall rule |
| 07:10.30 | TD-Linux | yes |
| 07:11.14 | allejo | yea, the firewall rule is the only way atm unless you have a better idea |
| 07:17.19 | Not-9d73 | [02bzflag-import-3] 07allejo pushed 032 commits to 03v2_4_x [+0/-0/±3] 13http://git.io/7_iM_Q |
| 07:17.21 | Not-9d73 | [02bzflag-import-3] 07allejo 03c6ee832 - kick the player when they try grabbing a distant flag instead of just logging |
| 07:17.22 | Not-9d73 | [02bzflag-import-3] 07allejo 0390aed65 - Merge branch 'v2_4_x' of github.com:BZFlag-Dev/bzflag-import-3 into v2_4_x |
| 07:27.36 | Not-9d73 | [02bzflag-import-3] 07allejo pushed 031 commit to 03v2_4_x [+0/-0/±1] 13http://git.io/bF9oLw |
| 07:27.37 | Not-9d73 | [02bzflag-import-3] 07allejo 03bb6d4a5 - Automatically remove trailing slash when using autocomplete for directory names |
| 08:04.30 | *** join/#bzflag thrakattak (cz3141@gateway/shell/devio.us/x-evifsehqgdkuolxb) |
| 10:25.05 | blast007 | allejo: what is that "merge 2_4_x with 2_4_x" for? Are you not rebasing when pulling new upstream changes? |
| 11:11.50 | blast007 | or is that not what rebasing would fix? don't think I've ever commit/pushed something before having pull in new changes |
| 11:11.59 | blast007 | pulled* |
| 11:18.50 | blast007 | (specifically talking about 'git pull --rebase' not 'git rebase' in this instance.. thinking that 'git pull --rebase' would pull in upstream changes, and alter your local commits to be based on the latest upstream) |
| 11:43.57 | quentinp | bzflag-import-3 is not a great name by the way, I now understand that it's the third import of the SVN repository, but I initially thought it was importing something, maybe from bzflag 3 |
| 11:44.07 | quentinp | it would also be nice to change the default branch on github |
| 11:50.36 | Not-9d73 | [02bzflag-import-3] 07kongr45gpen pushed 031 commit to 03v2_4_x [+0/-0/±1] 13http://git.io/B1_VbA |
| 11:50.38 | Not-9d73 | [02bzflag-import-3] 07kongr45gpen 03958ba12 - Don't allow muted players with ADMINMESSAGESEND to send PMs to hidden admins This prevents players who can't talk from trying to /msg everyone to identify hidden admins |
| 11:53.02 | quentinp | also, the wiki doesn't mention github, only svn |
| 12:32.18 | *** join/#bzflag kongr45gpen (~kongr45gp@unaffiliated/alezakos) |
| 12:38.30 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 12:56.54 | blast007 | quentinp: we're going to redo it at some point so that the svn-to-git script isn't in the repo at all, and then the v2_6_x would just be master |
| 14:27.55 | *** join/#bzflag Lep_ (~lep@ip70-181-131-206.sd.sd.cox.net) |
| 14:29.22 | *** join/#bzflag Lep_ (46b583ce@gateway/web/freenode/ip.70.181.131.206) |
| 15:27.47 | allejo | blast007, I had accidentally done a commit before I had done a git pull, that's why that commit occurred :x |
| 15:28.46 | allejo | .isOperator() is for players with an @? |
| 15:30.48 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 15:30.49 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 15:31.20 | allejo | kongr45gpen, isOperator() only returns true when someone has authenticated with /password |
| 15:33.21 | Not-9d73 | [02bzflag-import-3] 07allejo pushed 031 commit to 03v2_4_x [+0/-0/±1] 13http://git.io/8n4fMg |
| 15:33.22 | Not-9d73 | [02bzflag-import-3] 07allejo 039cfdfb5 - Allow players to send pms to admins that aren't hidden |
| 15:45.31 | kongr45gpen | allejo, really? |
| 15:45.47 | kongr45gpen | I just took it from the code that was there some time ago |
| 15:49.11 | allejo | https://github.com/BZFlag-Dev/bzflag-import-3/blob/v2_4_x/src/bzfs/Permissions.h#L182 |
| 15:49.29 | allejo | I guess before you could only PM people who had used /password? |
| 15:52.51 | kongr45gpen | Yeah, seems like that |
| 15:52.54 | kongr45gpen | Thanks for noticing! |
| 15:56.15 | allejo | :) |
| 16:34.02 | *** join/#bzflag khonkhortisan (~Khonkhort@2601:8:8600:97f:4a5b:39ff:fe94:be23) |
| 16:41.33 | *** join/#bzflag Leppp (46b583ce@gateway/web/freenode/ip.70.181.131.206) |
| 16:53.14 | *** join/#bzflag JeffM (~JeffM@107-209-61-105.lightspeed.irvnca.sbcglobal.net) |
| 17:45.31 | blast007 | allejo: right, but my understanding is that if you do 'git pull --rebase' then the upstream commits get put in before your local commits and your local commits get altered to be based on the newest upstream codebase |
| 17:55.32 | *** join/#bzflag sirquine (~quine@c-67-162-133-17.hsd1.co.comcast.net) |
| 18:16.21 | *** join/#bzflag khonkhortisan (~Khonkhort@2601:8:8600:97f:4a5b:39ff:fe94:be23) |
| 18:32.10 | *** join/#bzflag alpha1-2 (~alpha1-2@host90.190-137-10.telecom.net.ar) |
| 18:35.30 | alpha1-2 | blast007: it seems the hacker is doing his things again on your server (Missile War 2.3). His name is/was "flagresetmachine". He is constantly reseting the flags and gets/drops the team flags. According to a player on there. |
| 18:44.54 | alpha1-2 | oh I checked, his name was "Flag Reset Machine" (http://bzstats.strayer.de/players/stats/?name=Flag+Reset+Machine&lang=en) |
| 19:08.30 | *** join/#bzflag sirquine (~quine@c-67-162-133-17.hsd1.co.comcast.net) |
| 19:29.28 | JeffM | does he know all he's doing is helping get bugs fixed? |
| 19:35.26 | khonkhortisan | a good spy stays under the radar |
| 21:05.16 | *** join/#bzflag cods (~fred@tuxee.net) |
| 21:19.35 | BulletCatcher | allejo, if you rebase your own commit(s) before pushing to GitHub then a merge isn't necessary. |
| 22:14.55 | *** join/#bzflag Snake12534 (635cd32e@gateway/web/freenode/ip.99.92.211.46) |
| 22:42.51 | allejo | Ahhhh I didn't know that. Thanks BulletCatcher and blast007 |
| 23:02.46 | allejo | So I'm under the impression that fastmap is unstable though I think Flash may have fixed the memory leak that caused bzfs to hang |
| 23:04.42 | JeffM | haven't heard of any complaints about it |
| 23:10.10 | allejo | Until now :p |
| 23:11.16 | allejo | I loaded fastmap on apocalypse and bzfs kept hanging. Animal lover ran it also and her server started hanging or crashing as well. I've unloaded fastmap on apocalypse and it hasn't hung this far |
| 23:11.37 | allejo | So I'm just basing this on an assumption though it could just a coincidence |
| 23:21.34 | JeffM | soooo you had an issue on the server that runs a bunch of plugins that exploit bugs as features and it had a problem? |
| 23:21.38 | JeffM | ;) |
| 23:21.54 | JeffM | I know it's been used before |
| 23:21.59 | JeffM | by a number of servers |
| 23:22.22 | JeffM | maybe it has an odd iterraction with other plugins, but I don't know if I'd call it unstable |
| 23:22.28 | JeffM | it's not like it's untested |
| 23:22.42 | JeffM | it's been in use for several years now |
| 23:23.28 | blast007 | I've used it on all my servers for quite some time |
| 23:24.52 | JeffM | the HTTPS system is pretty solid, worst thing it does is drop HTTP connections when it gets confused |
| 23:24.58 | JeffM | HTTPD sorry |
| 23:25.02 | JeffM | it dosn't support SSL |
| 23:26.10 | JeffM | if it fails to complete a fastmap connection the client just asks for the map old school |
| 23:29.29 | blast007 | mofo could definitely make use of *some* sort of HTTP map cache file delivery.. the compressed map there is a bit over 700KB.. |
| 23:30.14 | JeffM | throw it on a webhost |
| 23:30.18 | JeffM | that's better then fastmap |
| 23:30.35 | JeffM | fastmap is just easy, and works for people who don't have access to a web server |
| 23:30.48 | JeffM | if you have a webserver then just hosting the cache file is best |
| 23:31.02 | JeffM | then it doesn't use any BZFS cycles or connections |
| 23:31.04 | blast007 | I use it even though I have a web server.. don't have to worry about updating the file |
| 23:31.14 | JeffM | yeah there is bookkeeping |
| 23:31.47 | blast007 | granted, I could just update my start script to do that automatically.. |
| 23:32.04 | JeffM | but that's work :) |
| 23:32.16 | JeffM | you are constantly regression testing fastmap :) |
| 23:32.21 | blast007 | hehe |