| 00:00.21 | *** join/#bzflag Jefenry (n=Jefenry@pool-70-104-160-68.norf.east.verizon.net) |
| 00:00.28 | Erroneous | CBG: dunno how relevant that is |
| 00:00.29 | quine | why? |
| 00:00.58 | CBG | well, just that dt seemed obvious to me since I have studied A-leve Maths (ages 17-18) |
| 00:01.04 | Erroneous | CBG: I assume anyone connecting from an LBL address has at least a basic grasp of math too :) |
| 00:01.24 | quine | i just don't really associate dt with time in this context |
| 00:02.02 | CBG | ok, ok :) |
| 00:02.05 | quine | heh |
| 00:02.11 | CBG | Erroneous: didn't think to whois :P |
| 00:02.15 | Erroneous | heh |
| 00:02.18 | CBG | and dunno what LBL is anyway ;) |
| 00:02.44 | Erroneous | quine: our physics simulation steps use elapsed time, start pos, end pos, rather than a continuous path |
| 00:03.03 | Erroneous | so if you are taking a screenshot, we need to prevent dt from becoming "too big" thus allowing you to pass through objects |
| 00:03.15 | spldart | chiperoo on Hepcat is cheater... can't be killed |
| 00:03.16 | a_meteorite | Erroneous: which still works |
| 00:03.28 | spldart | lag and multiple players confirm |
| 00:03.39 | a_meteorite | people use it for other things as well :( |
| 00:03.41 | spldart | lag ruled out |
| 00:03.50 | a_meteorite | spldart: be right there |
| 00:03.54 | spldart | kew |
| 00:04.07 | a_meteorite | spldart: name of cheat? |
| 00:04.34 | spldart | He left... just as I did... chiparoo or something likee that |
| 00:04.41 | spldart | do you have access to logs? |
| 00:04.52 | a_meteorite | I banned a dexterity who was f5 cheating |
| 00:05.09 | quine | hi. |
| 00:06.22 | spldart | He was green team... Several of us reds were shooting through him repeatedly with low lag figures and he never blew. I imagine he has run to another server... ALL SERVER OPS lookout for him on the 'Chip***' name or e otherwise... I got a feeling he will be around this evening |
| 00:06.37 | CBG | chipperoo according to strayer's. |
| 00:06.46 | a_meteorite | got it |
| 00:06.48 | spldart | That sounds like him |
| 00:07.34 | CBG | watching strayer's to see if he moves someplace else. I can probably deal with him most other servers |
| 00:07.46 | spldart | I feel confident in stating that he is a cheater and a dev might want to IP global ban him.... JMHO |
| 00:07.47 | a_meteorite | CBG: I can probably on even more, except mofo ones :P |
| 00:07.48 | CBG | nope... vanished. musta quit |
| 00:08.04 | CBG | a_meteorite: dunno about that. and mofo counts for a lot anyway |
| 00:08.07 | quine | so the pause to the screenshot function was added in the v2.0 branch |
| 00:08.21 | blast007 | spldart: global ban is not a substitute for server administration |
| 00:08.36 | quine | before, the client's display would just blank out, right? |
| 00:08.40 | blast007 | master ban is for the worst of the worst |
| 00:08.46 | spldart | true that... just stating that I'm quite confident that this isn't lag.. that's all |
| 00:09.00 | spldart | sry |
| 00:09.02 | blast007 | quine: before it didn't even blank out |
| 00:09.16 | quine | oh wait |
| 00:09.22 | quine | like, the frame would freeze |
| 00:09.29 | blast007 | yup |
| 00:09.29 | a_meteorite | what else? |
| 00:09.30 | quine | i was using the wrong term :] |
| 00:09.47 | *** join/#bzflag Legoguy (n=Legoguy@adsl-71-143-227-181.dsl.emhril.sbcglobal.net) |
| 00:11.04 | quine | but what happens if the pausing is removed? the client would just freeze for a sec, but would it not have any effect on anything else? |
| 00:14.31 | quine | ahh...no, it still would have the same effects, except the client just wouldn't pause |
| 00:14.45 | blast007 | the way the physics system handles dt could be improved |
| 00:15.11 | blast007 | for instance, run multiple physics engine cycles vs 1 rendered frame, if the FPS is low |
| 00:15.25 | blast007 | physics could be run on a constant rate |
| 00:15.37 | blast007 | then just render what whatever FPS the client can handle |
| 00:15.43 | blast007 | render at* |
| 00:16.04 | quine | well, the only problem for screenshot is writing the png and writing it to disk |
| 00:16.17 | *** join/#bzflag RC_cola (i=88a0fafd@gateway/web/cgi-irc/zeebrothers.net/x-7cf5e40832a1b691) |
| 00:16.17 | blast007 | I'm not sure anyone has profiled that |
| 00:16.35 | blast007 | what someone was thinking is that grabbing the framebuffer image was the bottleneck |
| 00:16.42 | quine | hm |
| 00:16.55 | Erroneous | writing is not the slow part |
| 00:17.01 | Erroneous | reading from the fb is the slow part |
| 00:17.07 | blast007 | I'm sure that there are other ways to get the image into memory |
| 00:17.10 | Erroneous | glReadPixels is one of the slowest read operations known to man |
| 00:17.20 | blast007 | Erroneous: is there another way it can be done? |
| 00:17.21 | Erroneous | blast007: yeah, set up a separate rendering context in main memory |
| 00:17.27 | blast007 | k |
| 00:17.40 | Erroneous | unfortunately that goes completely against the way we have GL set up :) |
| 00:17.46 | blast007 | :) |
| 00:17.47 | quine | rrgh |
| 00:17.49 | quine | so frustrating |
| 00:17.52 | Erroneous | not impossible, just harder than it should be :) |
| 00:18.04 | blast007 | so in the end, fixing the physics system might be a better idea? |
| 00:18.08 | quine | :\ |
| 00:18.31 | blast007 | run physics in a thread, for instance, maybe even with network code in that same thread |
| 00:18.35 | quine | i got banned from hepcat today for "cheating" |
| 00:18.45 | RC_cola | au |
| 00:18.48 | quine | where "cheating" means "obsessively keeping records of everything" |
| 00:19.10 | RC_cola | nwhich admin banned u? do u know? |
| 00:19.15 | blast007 | quine: run two computers, one as observer, focus it on you and take screenies ;) |
| 00:19.18 | RC_cola | -n |
| 00:19.28 | quine | yeah, a meteorite |
| 00:19.35 | RC_cola | ah |
| 00:19.49 | quine | i'm pretty sure that my computer doesn't jitter the tank, though |
| 00:19.50 | a_meteorite | the problem is you taking screenshots while playing |
| 00:19.54 | a_meteorite | oh, it does |
| 00:19.55 | RC_cola | hmm |
| 00:19.56 | quine | i realize |
| 00:20.01 | a_meteorite | screenshots block the main thread |
| 00:20.07 | quine | i see that |
| 00:20.08 | a_meteorite | and I warned you NOT to do it |
| 00:20.24 | a_meteorite | and you're only banned 5 hours, just stick it out |
| 00:20.25 | RC_cola | isn't F5 key for taking screenies? |
| 00:20.30 | a_meteorite | RC_cola: and cheating |
| 00:20.32 | blast007 | quine: there are applications that record gameplay to video :) |
| 00:20.43 | blast007 | quine: or take images every X seconds |
| 00:20.47 | quine | i do it 90% of the time either after exploding or when stopped |
| 00:20.48 | AAA_awright | So, want to merge my list server interface into the list server frontend? |
| 00:21.02 | RC_cola | a_meteorite: ;) |
| 00:21.08 | AAA_awright | (in a desperate attempt to change the subject) |
| 00:21.12 | blast007 | AAA_awright: I have the start of a new listserver in PHP |
| 00:21.18 | blast007 | it's not complete by any means |
| 00:21.20 | AAA_awright | Class based? |
| 00:21.25 | blast007 | no |
| 00:21.27 | AAA_awright | ... |
| 00:21.37 | blast007 | but it looks less like someone threw up in a text editor |
| 00:21.50 | blast007 | I do have a class for the data interaction |
| 00:21.58 | a_meteorite | people throw up in classes during finals, does that count? |
| 00:22.05 | quine | haha :] |
| 00:22.12 | quine | i've luckily never witnessed such an incident |
| 00:22.25 | blast007 | I didn't have many "finals" |
| 00:22.25 | AAA_awright | I can help put with that much. (Since a_meteorite doesn't want to work on the plugin *nudge**nudge*) |
| 00:22.28 | a_meteorite | you don't want to |
| 00:22.30 | blast007 | it was more projects :) |
| 00:22.48 | a_meteorite | AAA_awright: well, I have to be going to night school like... now |
| 00:22.50 | blast007 | AAA_awright: help with what? |
| 00:22.52 | AAA_awright | blast007: any sources for me to see? |
| 00:22.57 | blast007 | AAA_awright: it's in SVN |
| 00:22.59 | a_meteorite | blast007: top secret |
| 00:23.01 | blast007 | under the db/ module |
| 00:23.18 | blast007 | think I named it bzfls2 or something... seperate folder in there |
| 00:23.20 | a_meteorite | AAA_awright: yeah, I plan on unthreading the plugin and getting somewhere with it |
| 00:23.33 | AAA_awright | unthreading? |
| 00:23.39 | AAA_awright | #bzstocks |
| 00:23.44 | blast007 | removing threads |
| 00:23.56 | a_meteorite | quine: apology accepted |
| 00:23.59 | AAA_awright | It is supposed to be threaded, that is the point |
| 00:24.06 | AAA_awright | *my point |
| 00:24.10 | blast007 | k |
| 00:24.24 | a_meteorite | AAA_awright: I can't access the data quite right once I put it in a deque, no idea why |
| 00:24.36 | AAA_awright | Hm. |
| 00:24.40 | blast007 | worst case, get it working without them, then do that later |
| 00:24.58 | AAA_awright | blast007: bzfls.php? |
| 00:25.00 | a_meteorite | yeah, I'll just send the data in another thread, AAA_awright |
| 00:25.17 | *** part/#bzflag RC_cola (i=88a0fafd@gateway/web/cgi-irc/zeebrothers.net/x-7cf5e40832a1b691) |
| 00:25.20 | a_meteorite | do the XML building in the main bzfs loop. that will prevent me having to use a deque to get the info to the thread easily. |
| 00:25.34 | a_meteorite | anyways, must go to night school now... laters all |
| 00:25.43 | AAA_awright | laters |
| 00:26.03 | AAA_awright | ...but it is still day where he is. Hm. |
| 00:26.30 | AAA_awright | Anyways: blast007: bzfls2/ |
| 00:28.29 | blast007 | k |
| 00:28.40 | blast007 | haven't touched it in a while |
| 00:29.03 | AAA_awright | what is the file with logic? |
| 00:29.31 | blast007 | bzfls.php probably |
| 00:29.36 | blast007 | if that's what I named it |
| 00:29.42 | AAA_awright | in bzfls2? |
| 00:29.58 | blast007 | yeah |
| 00:30.03 | blast007 | bzfls2/bzfls.php |
| 00:30.14 | AAA_awright | I also posted a new weblogin.php to the sf.net patches list, has anyone looked at that? |
| 00:30.21 | blast007 | nope |
| 00:30.25 | AAA_awright | That was a while ago. |
| 00:31.47 | quine | blargh |
| 00:31.53 | AAA_awright | The code you have already looks good, I will fork that into my BZFlag_Info project, so now I have a bzflag client and server, and bzfls client and server in PHP :) |
| 00:32.05 | quine | i have to test out this screenshot terribleness some more |
| 00:32.10 | quine | but now i leave for HOME |
| 00:32.21 | AAA_awright | blast007: Prehaps use ADODB? |
| 00:33.18 | blast007 | nah |
| 00:33.28 | blast007 | we're eventually going to use LDAP |
| 00:33.48 | blast007 | I haven't found database abstractions layers to be useful |
| 00:33.55 | blast007 | so I do data abstraction instead :) |
| 00:34.11 | AAA_awright | LDAP now? ... |
| 00:34.18 | AAA_awright | Keep it simple. |
| 00:34.31 | AAA_awright | I guess LDAP would mean that... |
| 00:34.39 | blast007 | we could do distributed nodes |
| 00:34.53 | blast007 | and easily tie all of the web services into one login system |
| 00:35.07 | blast007 | phpBB3, mediawiki, and drupal all support LDAP |
| 00:36.43 | blast007 | there was someone working on LDAP a while ago, but I haven't heard from them in a while |
| 00:36.59 | spldart | bye bye's |
| 00:37.03 | AAA_awright | As I can see it is a bit cumbersome. And it offers no solution for listing servers. |
| 00:37.15 | blast007 | sure it does |
| 00:37.17 | AAA_awright | Efficiently. |
| 00:37.32 | blast007 | we wouldn't have the client directly speak LDAP |
| 00:37.47 | blast007 | we'd have list nodes we would run |
| 00:37.59 | blast007 | each list node would connect to a local LDAP server |
| 00:38.01 | AAA_awright | I can prase the existing listserver list with JAVASCRIPT. That means it is a nice list server. I want to keep that simplicity. |
| 00:38.14 | JeffM | you just use ldap for the auth, the listing system would work similar |
| 00:38.30 | blast007 | LDAP would contain the servers, groups, and users |
| 00:38.35 | JeffM | it just be distributed |
| 00:38.47 | blast007 | our services would then use that data |
| 00:38.48 | JeffM | blast007, I assume your still thinking of ding the list->game interface via HTTP? |
| 00:38.58 | blast007 | JeffM: yeah |
| 00:39.16 | JeffM | AAA_awright, that means for the game part, it'd not change, and you'd still be able to scan the list |
| 00:39.23 | blast007 | would it be "evil" to make the list use XML? |
| 00:39.25 | JeffM | the guts would just change to something that can be distributed |
| 00:41.53 | blast007 | I say "XML" and the channel dies |
| 00:41.56 | blast007 | :) |
| 00:44.16 | blast007 | one reason behind why I would like that: easier to add new features (i.e. adding a <country>USA</country> tag) |
| 00:44.33 | AAA_awright | true |
| 00:44.55 | AAA_awright | It would double the amount of data you have to process. |
| 00:44.55 | blast007 | currently we're quite locked in the format |
| 00:45.00 | blast007 | right |
| 00:45.26 | blast007 | and the amount of data that is sent |
| 00:45.28 | AAA_awright | prehaps urlencode? country=us&server=bzfx.net%345154 |
| 00:45.45 | blast007 | yeah, quite a few ways we could do it |
| 00:47.51 | AAA_awright | Quick, someone think of the most inefficent method of encoding data there is |
| 00:48.25 | blast007 | base64 encoded binary notatation |
| 00:49.42 | AAA_awright | JSON+ROT-13 sent via postcard (idk) |
| 00:50.43 | AAA_awright | No, rot-13 transformed base64 encoded JSON. Sent via singing telegram. |
| 00:52.30 | *** join/#bzflag Constitution (n=Constitu@gateway.pct.civiltec.com) |
| 00:53.53 | Epyon | Pidgeon protocol. |
| 00:54.26 | Epyon | As a way of sending data that is ;] |
| 00:57.03 | AAA_awright | There has to be an answer that, when read, prompts an immediate ROFL from everyone who knows CTP/IP. .....Oh. Appletalk. |
| 01:50.06 | *** join/#bzflag L4m3r (i=l4m3r@s75-232.resnet.ucla.edu) |
| 01:50.08 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 02:25.17 | *** join/#bzflag a_temp_dist (n=a_temp_d@about/essy/alarming/a-temp-dist) |
| 02:28.44 | *** join/#bzflag the_j0k3r (n=pizza_ma@CPE-124-188-225-119.nsw.bigpond.net.au) |
| 02:39.01 | Winny | bleh, can't see text |
| 02:39.17 | *** join/#bzflag Winny (n=BZ_Win_@CPE0016b6de59f3-CM000f9fac8236.cpe.net.cable.rogers.com) |
| 02:39.28 | Winny | test |
| 02:39.30 | Winny | yay |
| 02:40.06 | *** join/#bzflag JeffM (n=JeffM@pool-71-109-219-226.lsanca.dsl-w.verizon.net) |
| 02:49.44 | *** join/#bzflag AAA_awright (n=chatzill@wsip-68-14-251-102.ph.ph.cox.net) |
| 02:53.32 | *** join/#bzflag TimRiker (n=timr@md18836d0.tmodns.net) |
| 02:53.32 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 02:54.56 | AAA_awright | Windows computer just crashed. After it restarts, windows shows me a link to get drivers from the dell website, and I see this link on there: http://www.dell.com/open/ |
| 02:55.57 | Winny | so? |
| 02:56.07 | Winny | they sell linux too... big whoop |
| 02:56.30 | JeffM | that's like old news man |
| 02:56.34 | JeffM | so last month |
| 02:58.08 | *** join/#bzflag L4m3r (i=l4m3r@about/essy/warning/L4m3r) |
| 02:58.08 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 03:02.36 | AAA_awright | *headdesk* It's the irony. |
| 03:03.17 | AAA_awright | Rephrase: Anyone who has been living in a cave for the last month, check this out!!!: |
| 03:04.29 | Winny | heh |
| 03:07.35 | AAA_awright | NEWSFLASH! DELL OFFERS LINUX JUST AS A WINDOWS COMPUTER CRASHES! (I should submit that to the Onion...) |
| 03:07.43 | L4m3r | there's a lot of BS with dellbuntu |
| 03:08.04 | L4m3r | usually you're better off buying the same box with windows and installing it yourself |
| 03:08.43 | L4m3r | but it's nice to know that they have some systems that are all but guaranteed to be compatible hardware-wise |
| 03:17.53 | *** join/#bzflag Quol (n=Quol@modemcable177.75-202-24.mc.videotron.ca) |
| 03:18.03 | a_temp_dist | and you might be able to negotiate a refund for the Windows license |
| 03:26.57 | AAA_awright | a_temp_dist: I have heard you can get your $100 back via small claims court. :p |
| 03:27.42 | a_temp_dist | nice, they probably wouldn't even show up, but then you have to enforce the judgement against them |
| 03:29.54 | a_temp_dist | I don't need it, but it'd be nice to know |
| 03:30.07 | AAA_awright | http://www.linuxjournal.com/article/7040 . Anyways... |
| 03:31.07 | AAA_awright | My list server actually is a list _server_ now, and can process LIST requests: http://labs.redjacket.ws/bzfls/?action=LIST . I just added text matches (like the / key in bzflag) |
| 03:31.56 | AAA_awright | I plan to have blast007 replace mine with the existing list server in a week (if lucky). Feedback, anyone? |
| 03:38.50 | blast007 | AAA_awright: you'll want to talk to brlcad, as he's the one that runs the server |
| 03:39.20 | AAA_awright | I plan to have brlcad replace mine with the existing list server in a week (if lucky). Feedback, anyone? |
| 03:39.30 | Winny | rofl |
| 03:39.41 | blast007 | not what I meant |
| 03:39.43 | Winny | no need to repeat yourself ;) |
| 03:40.53 | JeffM | what do you mean by "replace"? |
| 03:42.19 | blast007 | AAA_awright: is that using my new code? |
| 03:42.20 | AAA_awright | JeffM: cat 'bzfls.upgrade.php' > bzfls.php |
| 03:42.37 | AAA_awright | Mostly. I am moving it inside a class, though. |
| 03:42.45 | blast007 | ...why? |
| 03:43.01 | blast007 | what does moving it into a class gain us? |
| 03:43.14 | *** join/#bzflag Suspect (n=Suspect@68-113-164-151.dhcp.plt.ny.charter.com) |
| 03:44.18 | AAA_awright | blast007: readability. |
| 03:44.23 | JeffM | what do cats have to do? |
| 03:44.42 | JeffM | you are making a newer/better codebase for it? and geting brclad to upgrade the code on my.b.o? |
| 03:44.48 | AAA_awright | mv bzfls.upgrade.php bzfls.php |
| 03:44.53 | JeffM | dude |
| 03:44.54 | JeffM | comeone |
| 03:45.00 | JeffM | real convesation here man |
| 03:45.21 | AAA_awright | I didn't know how serious you were. Um... |
| 03:45.29 | JeffM | I asked you a question |
| 03:45.32 | JeffM | twicw |
| 03:45.35 | JeffM | twice |
| 03:46.01 | AAA_awright | Just a cleaned-up well-tested, very large patch? |
| 03:46.05 | JeffM | you are making a new one? using blast's new one to test? |
| 03:46.22 | JeffM | is that a statement or a question? |
| 03:46.24 | blast007 | he's basing it my new one (that isn't anywhere near finished yet) |
| 03:46.33 | JeffM | ok, so it's a new one |
| 03:46.43 | JeffM | what features does it offer over the existing one? |
| 03:46.54 | JeffM | any performance? or just cleaner code? |
| 03:47.06 | blast007 | mine already has cleaner code |
| 03:47.16 | blast007 | don't see a need to make it a class though |
| 03:47.24 | JeffM | any other advantages? |
| 03:47.30 | blast007 | his also has AJAX |
| 03:47.33 | AAA_awright | Shiny interface? |
| 03:47.38 | JeffM | no, nothing real then |
| 03:47.52 | Winny | AAA_awright: not really shiny... |
| 03:47.54 | AAA_awright | No 'features' that would possibly break bzflag |
| 03:47.54 | JeffM | it's not faster/easier for the server or clients. |
| 03:48.10 | JeffM | not breaking is a requirement |
| 03:48.21 | JeffM | are there any features that make it benfiical to use |
| 03:48.28 | AAA_awright | I have some optimizations done (which should save 1% of execution time :p) |
| 03:48.34 | JeffM | nearly no users use the list server interface raw |
| 03:48.42 | JeffM | so a "shiny" interface is basicly pointless |
| 03:48.46 | AAA_awright | Because it looks bad. |
| 03:48.52 | Winny | no.. |
| 03:48.55 | JeffM | no, because there is NO use for it |
| 03:49.00 | JeffM | users use the game |
| 03:49.04 | Winny | because there are other sites that do the same thing 1000x better |
| 03:49.17 | JeffM | you made the list server into a stats site? |
| 03:49.31 | AAA_awright | That is an interesting idea.. |
| 03:49.32 | blast007 | no, doesn't even do stats |
| 03:49.40 | AAA_awright | It does show player counts |
| 03:49.47 | blast007 | though that was already part of the plan for *my* rewrite |
| 03:49.53 | JeffM | then what does it do that we woudl benifit from? |
| 03:50.06 | JeffM | your not doing a very good job of describing your project |
| 03:50.22 | JeffM | I'd rather see stats moved seperate |
| 03:50.33 | JeffM | one stats site that just gets info as a node |
| 03:50.47 | blast007 | I was thinking the list server could query servers itself |
| 03:50.56 | JeffM | push is better |
| 03:50.56 | blast007 | since it already opens a socket to check if they are working |
| 03:51.02 | JeffM | yeah it oculd |
| 03:51.12 | JeffM | but they also send us player updates |
| 03:51.17 | blast007 | true |
| 03:51.18 | JeffM | so they can push the info to the network |
| 03:51.28 | JeffM | the inital check is only once |
| 03:51.42 | JeffM | may as well have one consistent way to do it, push on change. |
| 03:51.52 | blast007 | part of the reason I halted my progess is so I could take a step back and make a solid plan |
| 03:52.02 | blast007 | (the other part is just lack of time) ;) |
| 03:52.03 | JeffM | yeah it needs a VERY solid plan |
| 03:52.10 | AAA_awright | I have no true aim, I am only working on two things right now: unshiny interface if the client supports Javascript, and organizing the logical code of the list server. There. |
| 03:52.28 | AAA_awright | See http://labs.redjacket.ws/bzfls/ |
| 03:52.44 | blast007 | AAA_awright: I'm already reorganizing the code |
| 03:52.46 | JeffM | AAA_awright, I am VERY leery of changing list server code unless there is a big reason or features |
| 03:52.52 | AAA_awright | err... the js is broken. |
| 03:52.58 | JeffM | if that dosn't work, we are screwed |
| 03:53.14 | JeffM | I'd ratehr see the "flashy" interface be a seperate thing |
| 03:53.38 | JeffM | less complexity tied into the core |
| 03:53.42 | JeffM | easier to update the core, etc.. |
| 03:53.52 | JeffM | less load on the core servers |
| 03:53.57 | AAA_awright | It was a separate thing. I just added the feature that if(isset($action)) {include listserver.php;die;} |
| 03:54.10 | JeffM | we will never do registration using the list, that was a pipe dream before bzbb was used |
| 03:54.13 | AAA_awright | and listserver.php has all the logic, LIST, etc. |
| 03:54.23 | blast007 | JeffM: hmmm... |
| 03:54.35 | blast007 | that was my plan :) |
| 03:54.38 | JeffM | blast007, once we have ldap, maybe |
| 03:54.44 | JeffM | I mean using the current/old method |
| 03:54.50 | blast007 | k |
| 03:54.51 | AAA_awright | I just needed a list. List is the only option that actually does anything right now. |
| 03:55.22 | blast007 | that's part of my "overall plan" |
| 03:55.22 | blast007 | as soon as I can get OpenLDAP working, that is |
| 03:55.23 | JeffM | indeed |
| 03:55.26 | JeffM | during a refactor of the entire auth system, yes we should look at all actions |
| 03:55.37 | JeffM | I don't see any reason to swap to AAA_awright system |
| 03:55.56 | JeffM | in fact cus of the java and the flasy stuff, I'd say I'd try to prevent it |
| 03:56.16 | JeffM | it's unneded cruft right now when the real work shoudl be done in making the system better |
| 03:56.25 | JeffM | our turd needs no more pollish ;) |
| 03:56.31 | AAA_awright | ... |
| 03:56.53 | JeffM | I'm sure you've put work into it |
| 03:57.04 | AAA_awright | I'll writeup a detailed changelog. Not like there was anything I changed, it started from scratch. |
| 03:57.09 | JeffM | but for a core service, you have to be VERY carefull |
| 03:57.24 | AAA_awright | It uses all the same SQL. That isn't changed. |
| 03:57.43 | JeffM | I'm not doubting the code, I'm doubting the reasons for changing it |
| 03:58.00 | AAA_awright | I get that. |
| 03:58.03 | JeffM | I havent' seen you say you have fixed any of the things that are "broken" |
| 03:58.20 | JeffM | yet you've added other complexity that can get in the way of fixing the core problems with the systems |
| 03:58.38 | JeffM | and the features you've added are most likely not going to be used by anyone other then yourself |
| 03:59.16 | blast007 | AAA_awright: actually, it doesn't use the same SQL :) |
| 03:59.24 | blast007 | bzfls2 is a complete rewrite |
| 03:59.44 | AAA_awright | (sigh) |
| 03:59.47 | JeffM | the java script just adds more stuff the server has to send out to a client that will never use it |
| 03:59.58 | JeffM | 99.999% of list server connections are bzfs |
| 04:00.03 | JeffM | and the client |
| 04:00.28 | JeffM | now if you want to make a game finder site |
| 04:00.39 | JeffM | that used list data, but was a seperate site |
| 04:00.46 | JeffM | that would be awesome |
| 04:00.47 | JeffM | and usefull |
| 04:01.09 | JeffM | but I'd not put that as part of the list itself, since we plan on making the list distributed |
| 04:01.26 | JeffM | and the "offical" way to find games should be the client |
| 04:01.36 | JeffM | if the client features are weak, then we should enhance the client |
| 04:01.58 | JeffM | a site in addition to the client woudl be nice, but it should be in addition, not instead of. |
| 04:04.53 | JeffM | AAA_awright, does it not send the JS stuff to game clients? |
| 04:05.18 | blast007 | the game clients wouldn't read those |
| 04:05.31 | JeffM | woudlnt' read what? |
| 04:05.34 | blast007 | since they would be going directly to ?action=LIST |
| 04:05.40 | JeffM | ahh ok |
| 04:05.43 | blast007 | so they would just have text, not the HTML page |
| 04:05.46 | AAA_awright | Nope. It works exactly the same as the current list server, data if it is requested, interface if not. |
| 04:05.57 | JeffM | so it's just added complexity in the php |
| 04:06.10 | JeffM | does the php take longer to execute? |
| 04:06.54 | AAA_awright | No, it just includes the logic, and if it sees data is requested, it sends the data and dies. then it sends the interface. |
| 04:07.20 | JeffM | well it would take more memory to load |
| 04:07.31 | JeffM | and one more if test, but that'd be nothing realy |
| 04:07.56 | JeffM | what does the ajax add to the interface that could not be done in normal HTML? |
| 04:08.30 | blast007 | nothing :) |
| 04:08.37 | AAA_awright | Filtering and sorting is the big thing. |
| 04:08.42 | *** join/#bzflag a_meteorite (n=a_meteor@unaffiliated/ameteorite/x-000000001) |
| 04:08.47 | AAA_awright | It does it on the fly without reloading the data. |
| 04:08.54 | blast007 | that's not AJAX |
| 04:08.58 | blast007 | that's just DHTML |
| 04:09.02 | AAA_awright | Exactly. |
| 04:09.11 | blast007 | but you're using AJAX to fetch the list, right? |
| 04:09.18 | AAA_awright | It can reload the latest servers with AJAX, correct. |
| 04:09.18 | JeffM | can you get that on a browser that dosn't do java? |
| 04:09.33 | blast007 | JeffM: he was going to make it fall back to regular forms |
| 04:09.45 | blast007 | not sure if it would be as feature rich if that was the case |
| 04:09.46 | AAA_awright | Yes, it just submits the form the same way the current one does. |
| 04:09.49 | *** part/#bzflag a_temp_dist (n=a_temp_d@about/essy/alarming/a-temp-dist) |
| 04:10.03 | JeffM | still sounds liek that should be another site |
| 04:10.06 | JeffM | part of stats |
| 04:10.17 | JeffM | once you have the info, you can do little with it |
| 04:10.26 | JeffM | other then remember it, and type it into BZ |
| 04:10.30 | blast007 | AAA_awright: it currently doesn't |
| 04:10.36 | blast007 | the submit button isn't a real submit button |
| 04:10.46 | JeffM | be better if it was tied to stats, so once you get the info, you can go and get stats and further info |
| 04:10.58 | blast007 | we don't need a fancy web form for the list server |
| 04:10.59 | AAA_awright | It currently doesn't. I am figuring hot how right now though. |
| 04:11.06 | blast007 | that's only there for debugging, mainly |
| 04:11.07 | JeffM | I see no reason or advantage to it being part of the list |
| 04:11.27 | JeffM | all of what you are doing could be done on another site just using polled list data. |
| 04:12.13 | *** join/#bzflag TheFinalFarewell (n=TheFinal@c-75-65-81-245.hsd1.la.comcast.net) |
| 04:12.19 | L4m3r | yeah, we need an API for the list and stats |
| 04:12.31 | L4m3r | so people can do their own sites without spidering the servers |
| 04:13.01 | JeffM | a single site that did the poll, and then provided them to other sites, and also had it's own slick interface woudl be a good thing |
| 04:13.13 | JeffM | in the distributed model that site would be a read only node |
| 04:13.31 | JeffM | that'd be a good workload breakdown |
| 04:13.57 | L4m3r | yeah |
| 04:14.10 | L4m3r | we could have a nice, light, efficient system for data collection (and the list) also |
| 04:14.37 | L4m3r | and use a separate, more conventional web interface for reading the stats |
| 04:15.02 | L4m3r | so we have a nice site without the chunky list server script |
| 04:16.14 | JeffM | AAA_awright, did you discuss design with anyone? or just get the idea and start busting it out? |
| 04:16.51 | AAA_awright | I started the interface... a while ago. Then goe started on it again and polished it up, and added player counts and filtering. |
| 04:17.28 | AAA_awright | Constitution says he liked it, a_meteorite didn't care... |
| 04:17.40 | a_meteorite | Well, not exactly... |
| 04:17.52 | a_meteorite | Though I don't really see it's immediate purpose. :) |
| 04:18.00 | JeffM | I think the interface idea can work fine, just not as part of the list |
| 04:18.31 | JeffM | I'd take what you have, and instead of geting the data from the raw SQL, modify it to use a cahced list server poll that you update every so often |
| 04:18.40 | JeffM | and provide the info in both a slick user way |
| 04:18.55 | JeffM | and a "raw data dump" method that other sites can use |
| 04:18.55 | AAA_awright | It gets the data directly from the LIST command, not an SQL query. |
| 04:19.13 | JeffM | ahh, so it isn't a list server, it's a list server client? |
| 04:19.40 | AAA_awright | er... yah. |
| 04:20.00 | JeffM | so then your statement of it replacing the current list server has me confused |
| 04:20.01 | *** join/#bzflag jude- (n=jude@c-68-84-206-92.hsd1.ar.comcast.net) |
| 04:20.14 | Winny | hey jude- |
| 04:20.30 | TheFinalFarewell | going somewhere? |
| 04:20.51 | jude- | road trip! |
| 04:20.52 | AAA_awright | Er... well I was planning on cleaning up the logic. I guess others can do that though. It only replaces the interface you get when no command is specified. Yah. |
| 04:21.11 | JeffM | AAA_awright, so then it is part of the list? |
| 04:21.16 | blast007 | JeffM: no, it's still part of the list server |
| 04:21.20 | JeffM | ok |
| 04:21.24 | AAA_awright | It could be. It can be seperate too. |
| 04:21.29 | JeffM | then I don't see how it "uses the list command" |
| 04:21.43 | JeffM | if its part of the page, then it does the sql |
| 04:21.50 | AAA_awright | It makes an HTTP request just like bzflag does, and parses that. |
| 04:22.00 | blast007 | from the browser itself |
| 04:22.04 | JeffM | oh |
| 04:22.07 | JeffM | eww |
| 04:22.22 | JeffM | I see it uses java to implement a browser side list client |
| 04:22.29 | JeffM | I'd make it all part of another page |
| 04:22.30 | AAA_awright | ... . Have you even seen it? It does through no preprocessing |
| 04:22.33 | JeffM | and tie it into stats |
| 04:22.37 | AAA_awright | gah. |
| 04:22.42 | AAA_awright | http://labs.redjacket.ws/bzfls/ |
| 04:22.50 | JeffM | and instead of hiting the list server, hit a cached site |
| 04:23.00 | JeffM | then have that cached site update every so often |
| 04:23.08 | JeffM | that way you keep a "stats" snapshot |
| 04:23.19 | TheFinalFarewell | evry 5min? |
| 04:23.27 | JeffM | dunno, have to play and see |
| 04:23.41 | AAA_awright | done |
| 04:23.43 | a_meteorite | it'd be nice if the official list server was in real time |
| 04:23.44 | JeffM | what'd be realy cool is if the list could keep a checksum |
| 04:24.04 | TheFinalFarewell | like md5hash |
| 04:24.06 | JeffM | and then the stats site coudl just check it's checksum against that real checksum |
| 04:24.06 | TheFinalFarewell | ? |
| 04:24.07 | JeffM | yeah |
| 04:24.16 | JeffM | then if it's had an update, requrey |
| 04:25.20 | JeffM | then you have that chache site, handle all the data queries from the stats sites |
| 04:25.28 | JeffM | have it update per server stats every 10 min or so |
| 04:25.30 | TheFinalFarewell | list server sending hash takes less time than sending entire list, so it saves time/bandwith? |
| 04:25.33 | AAA_awright | JeffM: It still has to compile the list and make an md5sum of it |
| 04:25.48 | AAA_awright | that is even more processing then just sending the list. |
| 04:25.49 | JeffM | AAA_awright, the list server can do that on each update, and keep it in the database |
| 04:25.56 | JeffM | you'd not do it each time |
| 04:25.59 | JeffM | you'd make the list cache |
| 04:26.05 | JeffM | space for speed |
| 04:26.06 | blast007 | JeffM: there is no need for a checksum on the list server |
| 04:26.11 | blast007 | it constantly changes :) |
| 04:26.17 | JeffM | blast007, no it dosn't |
| 04:26.23 | AAA_awright | The list server changes every second, though. |
| 04:26.23 | JeffM | people dont' join every second |
| 04:26.27 | JeffM | I don't think so |
| 04:26.28 | AAA_awright | Yah, they do. |
| 04:26.30 | L4m3r | jude-: roadtrip to where? (yeah, a bit late) |
| 04:26.39 | a_meteorite | JeffM: Oh, you'd be surprised. |
| 04:26.40 | JeffM | then cache it every 5 min |
| 04:26.47 | blast007 | we aren't going to query it every second though |
| 04:26.50 | AAA_awright | There is about 1 join/leave every two seconds. |
| 04:26.59 | jude- | L4m3r: mid- and south-west US |
| 04:27.01 | JeffM | there are too many servers ;) |
| 04:27.05 | blast007 | if we cache it for 30 seconds, you're likely to have a new list every time |
| 04:27.13 | jude- | Nevada, Utah, Colorado, New Mexico |
| 04:27.29 | L4m3r | but not California? :P |
| 04:27.30 | JeffM | well it'd just be nice to have stats use a static snapshot |
| 04:27.32 | JeffM | and update it smart |
| 04:27.39 | TheFinalFarewell | what really matters is servers being added/reomved from list, that doesnt happen evrey 2 sec. |
| 04:27.51 | JeffM | yeah |
| 04:27.52 | jude- | L4m3r: not yet... |
| 04:28.02 | JeffM | but player counts do |
| 04:28.18 | blast007 | the client is still going to use the dynamic list, or are you meaning to cache that too? |
| 04:28.26 | JeffM | if stats is going to query servers for per player info, you'd not need to get player conts from the list |
| 04:28.34 | JeffM | no, client always uses list |
| 04:28.38 | TheFinalFarewell | player counts arent as important as having a valid list of servers running |
| 04:28.43 | L4m3r | Any stops worth noting, jude-? Grand Canyon? Vegas? |
| 04:28.45 | JeffM | I'm looking to get the stats querys out of the mix from clients |
| 04:28.52 | blast007 | so I'm unsure how cache helps |
| 04:29.10 | AAA_awright | Alternatively: blast007 is is possible to keep a listserver-level log of that data? |
| 04:29.13 | JeffM | true, stats queries are less then client queries |
| 04:29.37 | blast007 | AAA_awright: it's not worth my time |
| 04:29.39 | JeffM | what would be good woudl be a single server that polls all the game servers, and cahces that |
| 04:29.48 | JeffM | so that we don't have 30 stats sties walking the server list |
| 04:29.57 | blast007 | AAA_awright: .... |
| 04:29.59 | JeffM | that's what I'd like to see goten rid of mostly |
| 04:30.11 | blast007 | AAA_awright: you're going to write a bot that will run on every server...? |
| 04:30.14 | TheFinalFarewell | maybe have 2 updates? player count update evry 30s, server list update every 5m |
| 04:30.16 | JeffM | have one site that walks the servers, then publishes that collection of info |
| 04:30.20 | blast007 | or do you mean just monitor the list server counts? |
| 04:30.23 | AAA_awright | No. |
| 04:30.30 | JeffM | TheFinalFarewell, clients need player counts too |
| 04:30.33 | AAA_awright | Just monitor counts. |
| 04:30.34 | brlcad | /wc/sb goto -50 |
| 04:30.35 | blast007 | monitoring the list server counts will only give you a vague idea |
| 04:30.37 | brlcad | oop |
| 04:30.50 | AAA_awright | I only want a number, joins per minute. |
| 04:30.53 | JeffM | and the list has current player counts |
| 04:31.01 | JeffM | as it's updated in real time by server pushes |
| 04:31.34 | blast007 | is there a more efficient way for servers to push data to a central server? |
| 04:31.49 | JeffM | well they can push MORE info |
| 04:31.51 | L4m3r | IRC! |
| 04:31.55 | JeffM | like scores and stuff |
| 04:31.56 | blast007 | ~lart L4m3r |
| 04:31.56 | ibot | teaches L4m3r the basics, including how to RTM |
| 04:32.09 | JeffM | well no, that is a way to get more data |
| 04:32.14 | JeffM | leave a conenction open |
| 04:32.16 | JeffM | somehow |
| 04:32.19 | blast007 | JeffM: I mean, something other than HTTP :) |
| 04:32.23 | JeffM | it all depends what oyu mean by effiecent |
| 04:32.33 | JeffM | you think http is eating all the bandiwth? |
| 04:32.40 | JeffM | how much does HTTP add? |
| 04:32.46 | blast007 | something where we can sent a series of data at once, then close the connection until next time |
| 04:32.56 | JeffM | sure, bust it out in TCP |
| 04:33.09 | JeffM | at that point there is no need in using an existing protocoll |
| 04:33.19 | JeffM | you just have your list then convert and publish it as needed |
| 04:33.30 | JeffM | not sure that's a big issue tho |
| 04:33.33 | TheFinalFarewell | use proprietary prot. then? |
| 04:33.49 | JeffM | why not, there is no reason for it to be man readable |
| 04:33.58 | JeffM | noone monitors the trafic between server and list |
| 04:34.08 | brlcad | mm.. missed RC_cola |
| 04:34.11 | L4m3r | yeah, sending data in chunks seems to be the best thing |
| 04:34.11 | TheFinalFarewell | ...made exclusively for list server? |
| 04:34.18 | L4m3r | reduce header overhead :) |
| 04:34.20 | JeffM | if the list published the data to a web site, the effect would be done |
| 04:34.37 | JeffM | TheFinalFarewell, sure, why not? |
| 04:35.18 | JeffM | we have a "custom protocoll" now in the fieds we send via HTTP |
| 04:35.24 | JeffM | fields |
| 04:35.37 | JeffM | it's just wraped up an another proto |
| 04:35.40 | L4m3r | it's not like we're sending incredibly complex data either |
| 04:35.40 | JeffM | so it's save bandwith |
| 04:35.44 | JeffM | yeah |
| 04:35.58 | TheFinalFarewell | wrapped? kinda like tunneling? |
| 04:36.00 | JeffM | I mean if it 1/2s the bandwith, and cuts it down to a packet or 2 instead of 20-30 |
| 04:36.02 | JeffM | no |
| 04:36.03 | L4m3r | using an existing proto would just add overhead for stuff we don't need in the first place |
| 04:36.08 | JeffM | we pack our data in HTTP post |
| 04:36.19 | JeffM | L4m3r, depends how much it adds |
| 04:36.30 | L4m3r | of course |
| 04:36.32 | JeffM | if it takes us from 1000 bytes down to 750, not much is saved |
| 04:36.56 | TheFinalFarewell | thats better than nothing |
| 04:36.57 | JeffM | but if it custs it by a lot, and has less server overhead... then it may be worth it |
| 04:37.03 | L4m3r | but if we're sending tiny bits of data individually, the headers become significant |
| 04:37.04 | JeffM | IRC is about as wordy as HTTP |
| 04:37.13 | blast007 | we have zlib too already, so could we not compress stuff? |
| 04:37.14 | brlcad | AAA_awright: LDAP is pretty simple |
| 04:37.16 | JeffM | L4m3r, thats what I mean by packet count |
| 04:37.19 | L4m3r | yeah |
| 04:37.19 | blast007 | even if we stick with HTTP? |
| 04:37.23 | AAA_awright | ! |
| 04:37.30 | JeffM | I don't know how many packets HTTP uses |
| 04:37.31 | blast007 | bandwidth wasn't my main concern |
| 04:37.34 | blast007 | number of requests was |
| 04:37.52 | JeffM | HTTP should just pack up the entire query into how ever many packets it takes and fires it off |
| 04:37.56 | JeffM | with some extra text |
| 04:38.19 | JeffM | IIRC it dos't have any more send/ack then normal TCP at that point |
| 04:38.32 | JeffM | now it incrases the data size, so that may add packets |
| 04:38.40 | JeffM | but I think you can get a k or so in a packet |
| 04:39.06 | JeffM | so if we are in the 1 to 2 packet range now, cuting down to 1 dosn't save much header space |
| 04:39.21 | L4m3r | but we could still add more data without adding more packets |
| 04:39.21 | JeffM | if its' 20 to 30 down to 2 to 3, that's a biger savings |
| 04:39.28 | JeffM | if we need to |
| 04:39.44 | JeffM | like I say, you'd have to see how much HTTP realy adds |
| 04:39.48 | L4m3r | sending it in piles gives more headroom even if we're not yet using it |
| 04:40.04 | JeffM | we send in piles now |
| 04:40.07 | blast007 | bandwidth and packet count isn't a real problem |
| 04:40.11 | JeffM | it's all one big HTTP request |
| 04:40.20 | TheFinalFarewell | smaller packets...make some info bitlevel? |
| 04:40.27 | JeffM | most if it's text |
| 04:40.42 | JeffM | we use a bitmask allready for the server info |
| 04:40.42 | TheFinalFarewell | oh |
| 04:41.01 | JeffM | it's all username/password/address stuff for the most part |
| 04:41.14 | JeffM | now appache does take up a lot of server side resources |
| 04:41.28 | TheFinalFarewell | possible to compress text? |
| 04:41.31 | JeffM | so if the bandwith is the same, and the server side useage is a lot lower, that is probably just as good a reson |
| 04:41.34 | JeffM | sure you can compress it |
| 04:41.46 | TheFinalFarewell | ...but not much, huh |
| 04:41.47 | JeffM | but again, if your geting down from 2 packets to 1, not much reason to waste the CPU |
| 04:41.49 | blast007 | we have plenty of bandwidth |
| 04:41.52 | JeffM | yeah |
| 04:42.01 | JeffM | CPU and server load are the big reasons |
| 04:42.03 | blast007 | plus, compression would increase load, now that I think about it |
| 04:42.13 | JeffM | space for speed ;) |
| 04:42.43 | TheFinalFarewell | depends on how you go about compressing it |
| 04:43.03 | JeffM | any compression needs CPU |
| 04:43.09 | brlcad | jude-: why? |
| 04:43.13 | TheFinalFarewell | some need less than others |
| 04:43.16 | JeffM | yes |
| 04:43.21 | JeffM | but they all need more then none ;) |
| 04:43.24 | JeffM | our data isn't HUGE |
| 04:43.25 | TheFinalFarewell | heh |
| 04:43.33 | JeffM | not in the least |
| 04:43.44 | JeffM | someone has to do the research |
| 04:43.46 | JeffM | that's all |
| 04:43.54 | JeffM | it's all just guesses untill we get some hard info |
| 04:44.38 | brlcad | bandwidth isn't really an issue even with the current list server, though obviously the less going out the better |
| 04:44.48 | brlcad | the bigger pig is the server-side processing and chatter with mysql |
| 04:44.56 | JeffM | I think a compiled C++ app would be fastest for the server |
| 04:45.02 | brlcad | by far |
| 04:45.04 | JeffM | and just have it pack what it needs in TCP |
| 04:45.09 | brlcad | probably an order if not two |
| 04:45.30 | JeffM | yeah |
| 04:45.36 | TheFinalFarewell | app? entire server, or just certain parts? |
| 04:45.48 | JeffM | the list server is one thing |
| 04:45.50 | JeffM | a small thing |
| 04:46.04 | blast007 | one small ugly thing |
| 04:46.11 | JeffM | you'd replace the current apache/php/mysql system with a simple tpc deamon |
| 04:46.21 | blast007 | tcp* |
| 04:46.24 | TheFinalFarewell | possible to do in ASM |
| 04:46.25 | TheFinalFarewell | ? |
| 04:46.29 | JeffM | why? |
| 04:46.33 | TheFinalFarewell | faster |
| 04:46.35 | JeffM | to make it harder to port and maintain? |
| 04:46.35 | blast007 | no... since we have to maintain it |
| 04:46.37 | brlcad | right now, I'd estimate about 20 simultaneous client connections all hitting the list server to log in simultaneously will leave about half of them surpassing their wait window for a response (giving them no token to hand to the bzfs they attach to) |
| 04:46.40 | JeffM | the sped diff woudl be not worht it |
| 04:46.50 | JeffM | not for the maintainiability you'd loose |
| 04:46.52 | brlcad | 99% of the time we're of course far below that rate |
| 04:47.21 | JeffM | yeah a little compiled deamon could go and service those a lot faster then apache can |
| 04:47.35 | JeffM | apache wasn't made to be fast, it was made to be roubst and extendable |
| 04:47.55 | JeffM | http was made for sending larger documents and data then we use it for |
| 04:48.09 | TheFinalFarewell | mod apache then? remove uneeded stuff? |
| 04:48.14 | blast007 | ... |
| 04:48.22 | JeffM | all we need is the basic data |
| 04:48.23 | brlcad | that's nuts |
| 04:48.27 | JeffM | TCP can do that |
| 04:48.29 | brlcad | modding apache that is |
| 04:48.32 | JeffM | we don't NEED to use apche |
| 04:48.34 | JeffM | or even http |
| 04:48.39 | JeffM | we get no advantage out of it |
| 04:48.42 | blast007 | I'd rather write my own webserver than mod apache |
| 04:48.53 | JeffM | you'd have to figure out what HTTP gets you |
| 04:49.02 | *** join/#bzflag AAA_awright_ (n=AAA_Awri@wsip-68-14-251-102.ph.ph.cox.net) |
| 04:49.04 | JeffM | the only thing we get out of using php, is somewhat ultimate portability |
| 04:49.09 | brlcad | if we just wanted a faster web server, such beasts already exist to, but that's solving a different problem |
| 04:49.19 | jude- | brlcad: why what? |
| 04:49.29 | brlcad | why bigger patches? :) |
| 04:49.35 | jude- | two reasons: |
| 04:49.41 | AAA_awright_ | Program is running now, will be finished in about 2 mins. |
| 04:49.54 | jude- | 1. I'll be spending hours and hours in my seat in the car coding |
| 04:50.07 | jude- | 2. I'll be away from the internet until I reach the hotels |
| 04:50.30 | jude- | ...if that's agreeable, of course :) |
| 04:50.38 | AAA_awright_ | jude-: I hope you aren't driving ;) |
| 04:50.42 | blast007 | hehe |
| 04:50.44 | jude- | heh--nope |
| 04:50.44 | TheFinalFarewell | code and drive at same time? |
| 04:50.55 | jude- | sadly, they make laptop holders for steering wheels |
| 04:51.03 | blast007 | o.O |
| 04:51.05 | TheFinalFarewell | touch screen |
| 04:51.18 | jude- | I saw an ad for one a while back in Popular Science |
| 04:51.29 | JeffM | jude-, they arn't patches, they are just large commits |
| 04:51.44 | jude- | ...but aren't they sent as diffs? |
| 04:51.55 | JeffM | that is only how it's implemented |
| 04:52.02 | JeffM | patches are things people have to apply |
| 04:52.07 | JeffM | commits are you changing THE code |
| 04:52.11 | JeffM | and you are chaning THE code |
| 04:52.19 | jude- | I see |
| 04:52.27 | jude- | s/pathes/commits, then :) |
| 04:52.38 | jude- | I'm apologizing in advance for their size |
| 04:53.01 | JeffM | why? |
| 04:53.16 | JeffM | commits is commits ;) |
| 04:53.24 | brlcad | jude-: ahh |
| 04:53.24 | JeffM | it's not like it causes anyone more work them being big |
| 04:53.33 | jude- | they'll probably be bigger, because I'll be sitting with my laptop on the trip for about 6-10 hours per day |
| 04:53.36 | brlcad | that's all good then.. just wondering ;) |
| 04:53.51 | jude- | ...and they'll be further in between |
| 04:53.58 | JeffM | travel does that |
| 04:54.24 | brlcad | Epyon: you still haven't committed anything. |
| 04:54.24 | jude- | ...so I'm apologizing to brlcad, because he wants me to make smaller commits more frequently |
| 04:54.33 | brlcad | it's not a hard rule :) |
| 04:54.40 | jude- | ...and that won't be the case for the next 10 days : |
| 04:54.43 | brlcad | just something to strive for when it suits |
| 04:54.49 | JeffM | jude-, you do what you can |
| 04:54.55 | JeffM | if you can't you can't |
| 04:55.03 | AAA_awright_ | Right now, 11.38 players are joining per minute. |
| 04:55.05 | brlcad | better than not doing the work (in your case) |
| 04:55.11 | jude- | heh |
| 04:55.20 | AAA_awright_ | The data changes once every 3 seconds. |
| 04:55.43 | AAA_awright_ | On average. (because for every join there is two events, an enter and exit. Eventually.) |
| 04:55.44 | brlcad | AAA_awright_: per minute is fine, it's the per second penalty and simultaneous changes (which are quite higher on the whole) |
| 04:55.54 | brlcad | as entire groups of folks tend to change servers at the same time |
| 04:56.43 | brlcad | bursts of about 3/sec is fairly normal during busy times, with that jumping up much higher under some conditions |
| 04:56.54 | AAA_awright_ | I observed that more players are leaving then joining right now (for every join there is 1.06 parts) |
| 04:57.41 | JeffM | yeah a deamon would cut a lot of the http/php overhead I think |
| 04:57.48 | TheFinalFarewell | AAA_awright_: its always time to goto bed somewhere in the world :) |
| 04:58.15 | AAA_awright_ | It is always time to wake up and play bzflag others. |
| 04:58.59 | AAA_awright_ | No data on bursts of changes I recorded. |
| 04:59.00 | TheFinalFarewell | thats not evr the first thing i think of when i wake up |
| 04:59.57 | JeffM | woudl you use sql still? |
| 05:00.05 | TheFinalFarewell | i wonder if there have been any cases of sleepBZFlagging? |
| 05:00.11 | AAA_awright_ | And HTTP does not have too much overhead, the minimum request (which is all we need) only needs 5-20 characters of data overhead. |
| 05:00.20 | TheFinalFarewell | ...kinda like sleepwalking |
| 05:00.32 | AAA_awright_ | We are not dealing with proxys or caching (usually) or cookies. |
| 05:00.33 | brlcad | in the shorter term, AAA_awright_ you might want to see how you could collaborate with blast on what he's already got going to possibly replace the current server (anything tangibly better like performance) |
| 05:00.38 | JeffM | the only reason to use http would be for compatability with old stuff |
| 05:01.03 | blast007 | and we could just continue my HTTP version and get it working like the current system |
| 05:01.05 | brlcad | there could still be an http interface that talks to the daemon |
| 05:01.06 | blast007 | and run that as a "node" |
| 05:01.15 | blast007 | or that |
| 05:01.26 | AAA_awright_ | Even SOAP uses HTTP, it is a very flexible and small data layer. |
| 05:01.31 | brlcad | (ergo, relatively simple drupal module, since it'd already hook in) |
| 05:02.11 | AAA_awright_ | HTTP/1.0\r\nGET /\r\n\r\n <--- complete header |
| 05:02.22 | TheFinalFarewell | <PROTECTED> |
| 05:02.29 | blast007 | brlcad: drupal module for what? |
| 05:02.32 | JeffM | that's more then the one byte we'd need in binary TCP ;) |
| 05:03.04 | TheFinalFarewell | JeffM: chalk up another score for binary |
| 05:03.37 | brlcad | AAA_awright_: it's not that it's too much or too little, it's a lot of infrastructure that adds considerably more complexity with little benefit and outright limitations for some purposes (like client-to-list communications) |
| 05:03.39 | AAA_awright_ | It is reduce overhead by 10 bytes vs. offer better expandability (as unexpandable the listserver format is already...) |
| 05:04.10 | brlcad | blast007: wouldn't have to be a drupal module, could just be a snippet of php code |
| 05:04.11 | JeffM | we can expand using an HTTP node |
| 05:04.17 | AAA_awright_ | What is wrong with the existing client-to-list communications? |
| 05:04.23 | JeffM | there is NO reason to force everyone to use http |
| 05:04.35 | blast007 | brlcad: wasn't sure what you were referring to |
| 05:04.43 | JeffM | current stuff is slow and extra wordy |
| 05:04.45 | brlcad | blast007: in fact on second thought, there's probably even less reason to make it a module for maintainability, but it's a really minor point |
| 05:04.48 | JeffM | we also have to URL encode it all |
| 05:04.58 | JeffM | and it offers no advantages |
| 05:05.15 | blast007 | brlcad: are you talking about the HTTP part of the list server? |
| 05:05.18 | brlcad | AAA_awright_: there are several issues with the existing communications, and performance is one of them |
| 05:05.22 | AAA_awright_ | I don't get that. Just like there is NO reason to force everyone to use the (great, by the way) bzproto? |
| 05:05.43 | JeffM | AAA_awright if it's faster, there is reason |
| 05:05.43 | brlcad | blast007: yeah, i was referring to having some http-accessible interface that would talk to this "ldap-talking daemon" interface |
| 05:05.52 | blast007 | k |
| 05:05.52 | JeffM | I'd like to see the list split for the new proto |
| 05:05.59 | JeffM | no need make eveyrone use the same |
| 05:06.01 | blast007 | I got thrown off when you mentioned a drupal module |
| 05:06.11 | blast007 | since that wouldn't seem to fit at all |
| 05:06.18 | JeffM | just mod the exsting htp stuff to get it's users from the new system |
| 05:06.35 | AAA_awright_ | Faster. Coding the HTTP server in C will increace the speed ten times more then simply using something else. |
| 05:06.43 | blast007 | JeffM: my rewrite puts all the data functions into a class |
| 05:06.45 | brlcad | you could easily wrap that in some http interface to give something similar to what we already do, if that's the way folks want to connect -- which likely would be the main point of something like a stats site that organizes and indexes that content for external hosts to readily datamine |
| 05:06.48 | AAA_awright_ | I meant removing the 10-char header. |
| 05:06.51 | blast007 | so it would be easy to swap out for LDAP or any other interface |
| 05:07.28 | JeffM | AAA_awright it's more then that, it's text wording for each field, URL encode, it all adds up |
| 05:07.30 | AAA_awright_ | LDAP for user authentication, that is (sorta) fine with me. It is the server list server that concerns me. |
| 05:07.38 | JeffM | both bandwith and CPU to decode it |
| 05:07.44 | blast007 | AAA_awright_: if we just go away from using HTTP for 2.1/2.2, the HTTP stuff will slowly die |
| 05:07.53 | brlcad | blast007: i was more thinking that there's going to be a bit of code written for the drupal authentication module so that it hooks into the ldap directory that could be readily reused for exposing an http interface to the list, but it's not really using a "drupal module" like I phrased it .. just php code that talks to ldap |
| 05:08.18 | *** join/#bzflag Constitution (n=Constitu@72.24.124.7) |
| 05:09.06 | brlcad | AAA_awright_: in the new setup, there's less distinction between servers and clients, they're all service users with various permissions and capabilities |
| 05:09.37 | JeffM | they are all nodes in a distributed system, some store, some read, some write |
| 05:09.41 | AAA_awright_ | Problem is that bzfs and bzflag are very different. |
| 05:09.52 | brlcad | not from the list server's perspective |
| 05:09.54 | JeffM | AAA_awright not in the data they send and get |
| 05:09.56 | AAA_awright_ | That makes sense, JeffM |
| 05:10.16 | JeffM | they all deal with server data, users and tokens |
| 05:11.01 | AAA_awright_ | LDAP is going to be using tokens for authentication? ... |
| 05:11.32 | AAA_awright_ | If we move to a different protocol, I would want to see a different system. Not to say that tokens don't work. |
| 05:11.54 | TheFinalFarewell | what would you suggest using instead |
| 05:11.56 | blast007 | hmm, I would think those systems would not directly talk to LDAP |
| 05:12.07 | JeffM | we'd still need tokens |
| 05:12.12 | JeffM | so we dont' send passwords to game servers |
| 05:12.13 | blast007 | they would talk to a daemon running at each list node |
| 05:12.19 | blast007 | and that daemon would talk to ldap |
| 05:12.21 | AAA_awright_ | Doesn't LDAP have it's own authentication system? |
| 05:12.24 | JeffM | yes |
| 05:12.29 | JeffM | we'd use that on the backend |
| 05:12.38 | JeffM | so that if need be we coudl change it later |
| 05:12.45 | JeffM | abstraction is good ;) |
| 05:12.52 | AAA_awright_ | Backend. You imply the frontend clients and servers will still use tokens. |
| 05:13.18 | L4m3r | well, yeah |
| 05:13.38 | L4m3r | we don't want to be handing username and passwords to the server now, do we? :) |
| 05:13.42 | Constitution | hey, has everyone seen AAA_awright's slick new server list web interface? |
| 05:13.54 | L4m3r | ~lart Constitution |
| 05:13.54 | ibot | shoots Constitution in his sleep |
| 05:14.01 | Constitution | :-P |
| 05:14.13 | Constitution | it rocks, eh? |
| 05:14.22 | JeffM | yeah, we have to have a way to have the game server verify the auth of a user |
| 05:14.25 | AAA_awright_ | New topic! |
| 05:14.26 | blast007 | Constitution: not overly |
| 05:14.32 | AAA_awright_ | ... |
| 05:14.41 | AAA_awright_ | The animation is cool, at least? |
| 05:14.48 | AAA_awright_ | No? ... |
| 05:14.52 | brlcad | it doesn't have to be tokens, but that would be the natural migration as it's simple |
| 05:14.58 | JeffM | AAA_awright no |
| 05:15.00 | TheFinalFarewell | where is it? link? |
| 05:15.09 | AAA_awright_ | http://labs.redjacket.ws/bzfls/ |
| 05:15.09 | L4m3r | doesn't seem to work in Konq |
| 05:15.12 | brlcad | my original thoughts had involved pgp/ssh style keys |
| 05:15.14 | TheFinalFarewell | thx |
| 05:15.39 | JeffM | key, token, whatever |
| 05:15.43 | JeffM | same deal |
| 05:16.09 | AAA_awright_ | Try the filter part. That is what makes the program. |
| 05:16.10 | TheFinalFarewell | looks like bloodbath2 is a big hit |
| 05:16.18 | brlcad | similar to some ideas that trepan had way back when, just with a temp-key system and key-recovery mechanism so that the things I'd complained about aren't problems (ease of use, not requiring manual transport, etc) |
| 05:16.20 | AAA_awright_ | Yah. |
| 05:16.50 | AAA_awright_ | Though about 2/3 the players left for eight minutes, for no reason... |
| 05:17.01 | brlcad | AAA_awright_: you're talking past me |
| 05:17.10 | TheFinalFarewell | conspiracy? :) |
| 05:17.22 | brlcad | I'm not saying your http design is really good or bad, there could be that same http front-end interface over anything |
| 05:17.33 | brlcad | the back-end implementation is the difference |
| 05:18.33 | brlcad | btw, your interface has some nasty bugs in safari :) |
| 05:18.45 | brlcad | (w.r.t filtering) |
| 05:19.25 | brlcad | and it stopped responding |
| 05:20.40 | TheFinalFarewell | ...i think i might set up my server for one last time this weekend |
| 05:20.59 | brlcad | L4m3r: more commits tonight? :) |
| 05:21.13 | L4m3r | maybe :) |
| 05:21.14 | brlcad | mm.. Friday the 13th |
| 05:21.18 | TheFinalFarewell | ...after which i will fade forever |
| 05:21.36 | brlcad | you mean.. |
| 05:21.42 | brlcad | it'd be.. TheFinalFarewell ? |
| 05:22.05 | TheFinalFarewell | brlcad: yep. thats why im using this nick |
| 05:22.35 | brlcad | so to me it's your first and only |
| 05:22.58 | brlcad | either way, good times |
| 05:23.05 | TheFinalFarewell | yeah |
| 05:24.38 | TheFinalFarewell | it got quiet, i thought they were talking about the list server and such a minute ago |
| 05:25.15 | *** join/#bzflag AAA_awright__ (n=chatzill@wsip-68-14-251-102.ph.ph.cox.net) |
| 05:26.09 | TheFinalFarewell | AAA_awright_: welcome back |
| 05:27.09 | AAA_awright | What about weblogin.php? That greatly uses the http list server. That needs to be considered. |
| 05:27.41 | brlcad | TheFinalFarewell: they/we were |
| 05:28.15 | L4m3r | AAA_awright, it can be changed to use whatever auth we end up with |
| 05:28.18 | brlcad | AAA_awright_: that just means an http interface needs to be exposed on the surface IF we want to continue to support that |
| 05:28.43 | AAA_awright | images.bzflag.org . That is why you need to support it. |
| 05:28.46 | L4m3r | I see no reason not to support it |
| 05:29.25 | brlcad | the IF wasn't to imply that it wouldn't be or that it's even being considered to drop it, it's just a design consideration that can be accounted for or not |
| 05:30.01 | brlcad | some reasons come to mind, but they can generally be accounted for via other mechanisms |
| 05:30.53 | brlcad | one thing we could see a heck of a lot more could be more phishing attempts, and the interface is exceptionally prone as it currently stands |
| 05:31.22 | AAA_awright | any logon form is prone to phising attempts. weblogin.php... for some reason seems more so. |
| 05:32.56 | brlcad | hence part of the if consideration as many of the users of the web form could probably get that same functionality without that same limitation with a different design |
| 05:33.05 | AAA_awright | brlcad: I did send a patch that would have fixed that-- right now you can log in from a form that is not in my.bzflag.org. For example, by own server admin tool: http://newton.bzfx.net/bzfsadmin/ |
| 05:33.36 | brlcad | that was actually intentional from the original design to allow that |
| 05:34.04 | AAA_awright | All I have to do is change the form action from weblogin.php to badhost.com/logger.php |
| 05:34.13 | *** join/#bzflag AAA_awright_ (n=AAA_Awri@wsip-68-14-251-102.ph.ph.cox.net) |
| 05:34.15 | brlcad | yep |
| 05:34.20 | brlcad | not saying it's good |
| 05:34.24 | brlcad | just that it was intentional |
| 05:34.48 | AAA_awright | Also, the fact you GET the password is not a good idea either. |
| 05:34.51 | L4m3r | weblogin.php should also say "Make sure this page is on bzf.org before proceeding" |
| 05:35.20 | brlcad | even if it did, there are plenty of lemmings that wouldn't pay attention to that |
| 05:35.33 | L4m3r | of course |
| 05:35.33 | AAA_awright | the RFC's state that any action that changes information should be POST. Only GETting data should be a GET request. |
| 05:35.44 | L4m3r | but even the best of us are sometimes caught by a link URL spoof |
| 05:35.46 | TheFinalFarewell | l4m3r fears that molez's dark army would rise up and cause unforeseen havoc |
| 05:36.05 | AAA_awright | my.bzflag.org.weblogin.php.badhost.com |
| 05:36.20 | L4m3r | yeah |
| 05:36.40 | L4m3r | or my.bzflag.org/weblogin.php@badhost.com |
| 05:36.54 | L4m3r | or was that an IE-only trick? |
| 05:37.24 | AAA_awright | dunno. Firefox just gave me this phishing filter update: http://login.myspace.com.index.cfm.fuseaction.user.mytoken.u6jpnazd.mfz7td1.com/login.php |
| 05:37.35 | brlcad | you either do something similar to paypal web logins, or you change the interface entirely and do some form of key/token setup such that remote servers could never log a user in via proxy |
| 05:38.07 | AAA_awright | L4m3r: That works in IE7, but not in FF2 |
| 05:39.14 | *** join/#bzflag tupone (n=atupone@pdpc/supporter/active/Tupone) |
| 05:39.15 | *** mode/#bzflag [+v tupone] by ChanServ |
| 05:39.56 | brlcad | ciao signore |
| 05:40.35 | TheFinalFarewell | ? |
| 05:40.48 | TheFinalFarewell | person? |
| 05:41.30 | brlcad | the designated recipient knows |
| 05:42.12 | tupone | hola senor |
| 05:43.20 | eTangenT | bienvenidos, sr. tupone |
| 05:43.25 | eTangenT | como esta usted? |
| 05:43.28 | tupone | how is your race training? |
| 05:44.06 | tupone | bene, and sleeping , still |
| 05:47.47 | brlcad | tupone: mal e bene |
| 05:48.57 | tupone | why ? no time? |
| 05:49.12 | brlcad | hmm.. should the menu font sizes auto-fit to the number of menu items? (up to some limit) |
| 05:49.17 | brlcad | tupone: yeah :( |
| 05:49.42 | brlcad | work messing up my schedule with urgencies and shortages |
| 05:49.52 | tupone | you cannot do that :( you should prioritize what is important :) |
| 05:50.11 | brlcad | I have, unfortunately that's why it's mal e bene |
| 05:50.29 | brlcad | if it was more bene for crew, it'd be more mal for work |
| 05:50.41 | tupone | ahh :) good |
| 05:50.59 | brlcad | but I have been able to train some still, just not anywhere near the intensity I need |
| 05:52.15 | tupone | well, I got it. Hope you get the time needed |
| 07:27.28 | CIA-3 | BZFlag: 03brlcad * r14529 10/branches/ftgl/src/bzflag/ (24 files): (log message trimmed) |
| 07:27.28 | CIA-3 | BZFlag: tweak all of the various font sizes so that they correspond to ttf sizes and/or |
| 07:27.28 | CIA-3 | BZFlag: using sizes relevant to the relevant context resolution(s). changed the |
| 07:27.28 | CIA-3 | BZFlag: autosizing code for the control panel and scoreboard so that they adjust |
| 07:27.28 | CIA-3 | BZFlag: according to how many lines and columns are displayable with various (tested) |
| 07:27.30 | CIA-3 | BZFlag: font sizes. these tweaks makes the sizes match more closely with how things |
| 07:27.32 | CIA-3 | BZFlag: were beforehand, albeit not exactly. there's now more consistency in the menu |
| 07:29.57 | *** join/#bzflag lodxcol (n=lodxcol@unaffiliated/lodxcol) |
| 07:30.03 | a_meteorite | nice, big commit messages rule |
| 07:30.12 | a_meteorite | ~brlcad++ |
| 07:36.35 | brlcad | arrrgl .. the ansi code is _identical_ as far as I can tell .. but not working |
| 07:37.58 | brlcad | that's the only thing left with the new ftgl fonts too :( |
| 08:37.46 | *** join/#bzflag DavidHKMrPowers (n=chatzill@unaffiliated/davidhkmrpowers) |
| 08:42.28 | daxxar | Hey :-) |
| 08:50.28 | CBG | hola again :) |
| 08:50.48 | daxxar | Hay CBG. |
| 08:51.19 | daxxar | Currently, .so's do not work; stuff they refer to in the main binary gives an undefined symbol error. |
| 08:51.34 | CBG | :( |
| 08:58.56 | Constitution | daxxar: something is broken in v2_0branch |
| 08:59.04 | Constitution | something within the last three weeks |
| 09:15.09 | daxxar | Constitution: Hum? |
| 09:15.10 | CIA-3 | BZFlag: 03daxxar * r14530 10/trunk/bzflag/src/bzrobots/Makefile.am: added -rdynamic to bzrobots_LDFLAGS, so that the unresolved symbols go away ;-) |
| 09:26.43 | CIA-3 | BZFlag: 03daxxar * r14531 10/trunk/bzflag/src/bzrobots/ (. Makefile.am): now builds (not installs) TestRobot.so by default |
| 09:26.59 | daxxar | There, head out. |
| 09:29.12 | *** join/#bzflag Legoguy_ (n=Legoguy@adsl-71-143-234-103.dsl.emhril.sbcglobal.net) |
| 09:41.37 | Constitution | daxxar: yeah, just to say, I've experienced the problem too |
| 09:49.03 | *** join/#bzflag Suspect (n=Suspect@68-113-164-151.dhcp.plt.ny.charter.com) |
| 10:57.58 | *** join/#bzflag Pimpi (n=frank@gondolin.pimpi.org) |
| 11:11.09 | *** join/#bzflag Rawk (n=unknown@203.109.185.128) |
| 11:49.22 | *** join/#bzflag CppIsWeird (n=CppIsWei@unaffiliated/CppIsWeird) |
| 11:49.39 | CppIsWeird | is there a way to make the keyboard arrows work as fast as the mouse? |
| 11:51.09 | Birdie | keyboard works as fast as the mouse, you dont go faster with either |
| 11:53.03 | daxxar | Constitution: This problem is in my code, so I think you're referring to someting unknown to me. :-) |
| 11:53.20 | daxxar | But my code works now! \o/ |
| 11:55.32 | CppIsWeird | yes you do, the mouse moves faster on here |
| 12:00.57 | CBG | The keyboard has artificial "acceleration" build in, so to speak. |
| 12:01.43 | CBG | Contrary to popular belief, you do not accelerate infinitely, from being stationary, to travelling/turning at full speed in any direction instantly when using the arrow keys. |
| 12:02.11 | CBG | snick (randomparticle on IRC) has looked at this quit intensively and has recorded some figures to demonstrate it. |
| 12:02.58 | CBG | I had been using this acceleration to my advantage for some time, to make smaller jumps by pressing an arrow key and the jump key in rapid succession, without even realising it. |
| 12:03.24 | CBG | CppIsWeird: so, I would attempt to contact snick a.k.a randomparticle to speak about it further. |
| 12:03.25 | Constitution | daxxar: oh, oops :-) |
| 12:04.21 | *** join/#bzflag cods (n=cods@rsbac/developer/cods) |
| 12:10.34 | *** join/#bzflag LongDon (n=LongDon@host-091-097-021-042.ewe-ip-backbone.de) |
| 13:06.34 | *** join/#bzflag poolio (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) |
| 13:08.52 | *** join/#bzflag the_j0k3r (n=pizza_ma@CPE-124-188-227-139.nsw.bigpond.net.au) |
| 13:12.20 | *** join/#bzflag TheRedBaron (n=Kalen@fl-71-52-16-80.dhcp.embarqhsd.net) |
| 13:21.08 | *** join/#bzflag DavidHKMrPowers (n=chatzill@unaffiliated/davidhkmrpowers) |
| 13:42.43 | *** join/#bzflag Tedius (n=cmtadmin@cmtadmin.MUSC.CWRU.Edu) |
| 13:50.02 | *** part/#bzflag LongDon (n=LongDon@host-091-097-021-042.ewe-ip-backbone.de) |
| 13:56.19 | *** part/#bzflag Rawk (n=unknown@203.109.185.128) |
| 14:00.32 | *** join/#bzflag Tedius (n=Tedius@cmtadmin.MUSC.CWRU.Edu) |
| 14:15.29 | *** join/#bzflag LongDon (n=LongDon@host-091-097-021-042.ewe-ip-backbone.de) |
| 14:18.54 | *** join/#bzflag Winny (n=BZ_Win_@CPE0016b6de59f3-CM000f9fac8236.cpe.net.cable.rogers.com) |
| 14:28.28 | *** join/#bzflag Jwir3 (n=Jwir3@c-66-41-249-30.hsd1.mn.comcast.net) |
| 14:46.26 | *** join/#bzflag ep (n=mdr@about/essy/guynextdoor/ep) |
| 15:01.18 | *** join/#bzflag Pommes_ (n=Pommes@about/essy/frenchy/Pommes) |
| 15:23.53 | *** join/#bzflag Epyon (i=Epyon@host99.180.219.81.magma-net.pl) |
| 15:55.38 | *** join/#bzflag TimRiker (n=timr@rikers.org) |
| 15:55.38 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 16:00.34 | *** join/#bzflag LongDo1 (n=LongDon@host-091-097-018-193.ewe-ip-backbone.de) |
| 16:02.14 | *** join/#bzflag randomparticle (n=randompa@about/essy/snick/randomparticle) |
| 16:23.42 | *** join/#bzflag Erroneous (n=dtremena@67-131-219-2.dia.static.qwest.net) |
| 16:24.13 | *** mode/#bzflag [+v Erroneous] by ChanServ |
| 16:25.36 | *** part/#bzflag randomparticle (n=randompa@about/essy/snick/randomparticle) |
| 16:35.25 | *** join/#bzflag randomparticle (n=randompa@88-104-223-190.dynamic.dsl.as9105.com) |
| 17:06.35 | *** join/#bzflag TimRiker (n=timr@pdpc/supporter/bronze/TimRiker) |
| 17:06.35 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 17:12.06 | *** join/#bzflag JeffM (n=JeffM@unaffiliated/jeffm) |
| 17:12.06 | *** join/#bzflag bier_ (n=bier@p54A51367.dip0.t-ipconnect.de) |
| 17:24.21 | *** join/#bzflag tupone (n=atupone@pdpc/supporter/active/Tupone) |
| 17:24.21 | *** mode/#bzflag [+v tupone] by ChanServ |
| 17:35.27 | *** join/#bzflag JeffM (n=JeffM@unaffiliated/jeffm) |
| 17:37.13 | *** join/#bzflag RC_cola (i=88a0fafd@gateway/web/cgi-irc/zeebrothers.net/x-7dfc5f9c0c8e45da) |
| 17:52.58 | *** join/#bzflag TheRedBaron (n=Kalen@fl-71-52-16-80.dhcp.embarqhsd.net) |
| 18:01.06 | *** join/#bzflag delusional (n=delusion@pool-71-240-48-29.pitt.east.verizon.net) |
| 18:12.30 | *** join/#bzflag Constitution (n=Constitu@gateway.pct.civiltec.com) |
| 18:16.50 | *** join/#bzflag Jefenry (n=Jefenry@pool-71-241-44-139.nrflva.east.verizon.net) |
| 18:34.47 | *** join/#bzflag gsnedders (n=gsnedder@host81-132-88-104.range81-132.btcentralplus.com) |
| 18:36.11 | *** join/#bzflag JBdiGriz (n=jbdigriz@206-15-67-5.static.twtelecom.net) |
| 18:36.11 | *** mode/#bzflag [+o JBdiGriz] by ChanServ |
| 18:54.33 | Epyon | Hmm, are BZW files ordered? |
| 18:54.47 | Epyon | That is - can I use a material, and define it below? |
| 18:54.53 | *** join/#bzflag JBdiGriz (n=jbdigriz@206-15-67-5.static.twtelecom.net) |
| 18:54.53 | *** mode/#bzflag [+o JBdiGriz] by ChanServ |
| 18:55.02 | Erroneous | materials are parsed first, iirc |
| 18:56.18 | Winny | when I put a material below I usually have trouble... |
| 18:56.37 | Winny | and it is better organization wise to put them on the top, since everyone else does. |
| 18:56.49 | Epyon | hmm, okay |
| 18:57.15 | Winny | bbl, must go work |
| 18:58.42 | *** join/#bzflag TD-Linux (n=TD-Linux@24-159-200-217.dhcp.roch.mn.charter.com) |
| 19:02.00 | Epyon | Erroneous, should I use the header that all bz source files share? |
| 19:12.52 | quine | haha |
| 19:13.01 | quine | i took apart my dell laptop to fix a few things |
| 19:13.02 | quine | http://andrew.cmu.edu/user/djwang/dell/_IMG_0223_small.jpg |
| 19:18.10 | CBG | looks so much better like that :D |
| 20:05.49 | Erroneous | Epyon: depends how integrated you want it to be. if it's a plugin or standalone, it will use its own stuff. if it's built with bz's build system, you should include common.h everywhere. |
| 20:07.19 | brlcad | Epyon: I'm not sure I'd rely on that behavior, but yeah currently I think that'll work |
| 20:07.46 | brlcad | teleporters used to work that way where you could use them before they were defined, but then someone(t(i)m) changed it so that would be an error ;) |
| 20:25.52 | ep | I was told that a quick pause/unpause in console is an indication that a user is using the f5 cheat to cause intentional jitter. Is this accurate? If so, which client does this? |
| 20:26.08 | Winny | most 2.0.9 builds |
| 20:26.35 | Winny | most 2.0.9 builds will show the f5ing* |
| 20:27.04 | ep | will it show it if the user is on 2.0.8? |
| 20:29.25 | brad | it will if it's an unmodded client |
| 20:30.47 | ep | Does it give false positives? |
| 20:31.24 | brad | someone could actually be taking a screenshot :) |
| 20:31.50 | brad | (or pausing/unpausing very quickly - perhaps they hit p by accident) |
| 20:32.17 | ep | gotcha, it has to be put in context |
| 20:35.13 | *** join/#bzflag TheFinalFarewell (n=TheFinal@c-75-65-81-245.hsd1.la.comcast.net) |
| 20:39.32 | *** join/#bzflag zee765 (i=5868dfbe@gateway/web/cgi-irc/zeebrothers.net/x-1f405f064219951c) |
| 20:39.42 | zee765 | i've just installed bzflag on vista |
| 20:40.13 | zee765 | i'm getting reasonable frame rates - around 200fps |
| 20:40.25 | zee765 | yet when i play online the movement is not smooth at all |
| 20:40.37 | ep | an update will take care of that:) |
| 20:40.37 | tupone | dual core? |
| 20:40.41 | zee765 | yes, dual core |
| 20:41.02 | zee765 | is it the timing issue? |
| 20:41.03 | tupone | I think you should force to stay in one CPU |
| 20:41.08 | zee765 | ah, ok |
| 20:41.13 | blast007 | yeah, that would be one thing to try quick |
| 20:41.14 | zee765 | how can i do that please? |
| 20:41.19 | blast007 | task manager should allow that |
| 20:41.24 | zee765 | ok. one moment |
| 20:41.26 | blast007 | while the game is running |
| 20:42.14 | blast007 | should be "Set Affinity" (or at least that's what it is on XP) |
| 20:42.27 | zee765 | which tab please? |
| 20:42.38 | blast007 | processes |
| 20:42.46 | blast007 | right click on bzflag.exe, and there should be "Set Affinity" |
| 20:43.03 | zee765 | done |
| 20:43.13 | zee765 | quick test now |
| 20:43.58 | zee765 | hmm.. still jerky |
| 20:44.05 | zee765 | do i need to restart bzflag? |
| 20:44.59 | tupone | no, you should not |
| 20:45.17 | *** join/#bzflag bier_ (n=bier@p54A51367.dip0.t-ipconnect.de) |
| 20:45.40 | blast007 | by "jerky", what do you mean exactly? |
| 20:46.01 | tupone | what if you try to cap FPS to the screen refresh rate? |
| 20:46.40 | blast007 | yeah, that's what I'm thinking :) |
| 20:46.45 | blast007 | turning on vsync |
| 20:46.54 | blast007 | caping the FPS won't help, but vsync will |
| 20:47.09 | *** join/#bzflag Suspect (n=Suspect@68-114-71-106.dhcp.plt.ny.charter.com) |
| 20:47.17 | brlcad | ep: that's not entirely true necessarily |
| 20:47.30 | ep | that was my question |
| 20:47.37 | brlcad | just taking screenshots will cause the pause/unpause and there's absolutely nothing wrong with taking screenshots in general |
| 20:47.54 | ep | yes, i understand that |
| 20:48.06 | zee765 | is there something i could do in the catalyst control center? |
| 20:48.07 | blast007 | ep: bzadmin shows the pause/unpause messages as well |
| 20:48.08 | brlcad | it's whether, while directly observing them, you notice them doing pause/unpause to specifically get through walls |
| 20:48.12 | brlcad | more than once |
| 20:48.25 | blast007 | zee765: I'm sure there will be a "vsync" or "Vertical Sync" setting in there somewhere |
| 20:48.32 | zee765 | will check |
| 20:48.33 | brlcad | the server was modified to show/send the pause state iirc when this started |
| 20:48.34 | tupone | that is just an hack :( We should change the collision algo |
| 20:48.57 | brlcad | yes |
| 20:48.59 | Chestal | btw., what is the state of the high fps problem? |
| 20:49.12 | brlcad | you can still get through thin walls with the existing hack |
| 20:49.24 | brlcad | just not arbitrarily thick ones like originally :) |
| 20:49.30 | Chestal | I noticed that after my latest fglrx/kernel update my fps has increased, without throttling I experience fast tank syndrome |
| 20:49.42 | Chestal | I'm using vsync now |
| 20:50.09 | blast007 | I can't be sure if I've had "fast tank", but certainly had some issues with the physics |
| 20:50.16 | blast007 | bouncing off objects, mainly |
| 20:50.20 | ep | some people are using it too dodge. No walls in sight. |
| 20:51.52 | brlcad | ep: that's really hard to prove unless they do it for a really long time |
| 20:54.21 | ep | Seems like it would be suspicious if you starting seeing puase/unpause messages in the middle of a one on one battle. I'm still running 2.0.8 so I don't know. |
| 20:56.10 | TheFinalFarewell | Tedius: hungry for some brains? |
| 20:56.42 | Tedius | mmm |
| 20:56.59 | zee765 | well.. have experimented with vsync. seems to improve things without the energy saver running. with it running, it's almost unplayable |
| 20:57.11 | zee765 | i can't believe it's so much worse than under OS X |
| 20:57.45 | zee765 | surely i'm missing something here |
| 20:58.14 | tupone | energy saver and vsync? You need only one of them |
| 20:58.26 | tupone | and probably vsync is better |
| 20:58.33 | zee765 | uses more cpu though |
| 20:59.07 | tupone | why? isn't vsync calling for a wait? |
| 20:59.17 | tupone | maybe is driver dependent |
| 20:59.17 | zee765 | it's 60fps vs about 30fps |
| 20:59.33 | zee765 | i.e., about twice as much cpu. if you're on a laptop.. |
| 20:59.40 | tupone | ahh, you capped at 30 |
| 21:09.12 | brlcad | ep: unless they're actually trying to capture a cool in-game screenshot with some bullet/explosion action .. :) |
| 21:09.49 | brlcad | i've done that on several occasions, taking dozens of shots .. with the current mindset that would have looked like cheating when in fact I was just trying to get a cool screenshot |
| 21:11.10 | brlcad | zee765: bz's energysaver framerate is actually configurable too if 30 causes problems |
| 21:13.00 | tupone | we should multithread it, before using the energy saver reliably |
| 21:13.20 | tupone | energy saver and/or vsync |
| 21:14.28 | brlcad | energy saver really was just to keep the laptops cool, as they can burn hot |
| 21:14.29 | Winny | does anyone know if windows limits FPS? on any map, my FPS is always pegged at 59. |
| 21:14.35 | TheRedBaron | no |
| 21:14.40 | TheRedBaron | windows does not limit fps |
| 21:14.42 | brlcad | not a means to sync or even "directly" reduce cpu usage |
| 21:14.44 | Winny | weird |
| 21:14.50 | TheRedBaron | ATI and Nvidia |
| 21:14.58 | Chestal | 59 could be vsync |
| 21:15.02 | brlcad | it does if you turn on energy saver |
| 21:15.09 | brlcad | or vsync, yeah |
| 21:15.13 | TheRedBaron | correct |
| 21:15.29 | TheRedBaron | at high FPS, you do experience rubber walls |
| 21:15.39 | blast007 | yup |
| 21:15.41 | TheRedBaron | bouncing off of them |
| 21:15.45 | TheRedBaron | annoying for jumps |
| 21:15.55 | TheRedBaron | so i use vsync |
| 21:15.59 | blast007 | it's fun when there are two walls, and you can bounce between them :P |
| 21:17.07 | tupone | brlcad, vsync now delay the reception/processing of inputs so it is bad |
| 21:17.15 | Chestal | hmm, I think lots of places in the client use TimeKeeper:getCurrent() when they really should be using getTick() |
| 21:18.01 | blast007 | tupone: I think 60FPS is enough for input :) |
| 21:18.09 | tupone | from network I mean |
| 21:18.23 | blast007 | even for that |
| 21:18.23 | tupone | it is not constant |
| 21:18.25 | brlcad | tupone: yep, though that's a way bigger problem in itself -- input processing should probably have it's own "run loop" (whether threaded or not is an impl detail) so that it runs at a fixed N events per dt |
| 21:18.50 | brlcad | instead of being N events per frame, where the rate changes the behavior |
| 21:19.13 | tupone | It is adding jitter :/ |
| 21:19.17 | brlcad | that would fix the accellerated mice issue, aside from just normalizing all of the various possible inputs |
| 21:19.20 | Chestal | we have _much_ bigger issues with the timing |
| 21:19.26 | blast007 | it would almost have to be in a thread, right? |
| 21:19.26 | Chestal | especialyl at high frame rates |
| 21:19.39 | brlcad | blast007: not really |
| 21:19.49 | blast007 | I'm just thinking about stuff like screenshots |
| 21:19.53 | brlcad | you can do the same thing with selects and other mechanisms |
| 21:20.11 | blast007 | if they take two seconds to do, won't that tie up the other stuff for two seconds anyway? |
| 21:20.20 | blast007 | hmm |
| 21:20.22 | brlcad | screenshot would be an ideal one for threading since it's so intense, but even that could happen in another process |
| 21:20.28 | tupone | brlcad, hmm, switch of gl buffer cannot be put on a select |
| 21:20.42 | tupone | or maybe yes :/ |
| 21:21.13 | brlcad | i think it could be done, but it'd be kinda fugly |
| 21:21.30 | tupone | so vsync will jitter things a little |
| 21:22.02 | brlcad | better would probably be forking a process or threading out the main run-loops (graphics, game, net, chat/log, input) |
| 21:22.09 | tupone | yeah |
| 21:22.33 | Chestal | I don't see why a blockign wait liek vsync has to introduce jitter |
| 21:22.41 | Chestal | isn't it a question on how you order the processing? |
| 21:22.56 | brlcad | hm, that probably plays a big part |
| 21:22.59 | Chestal | if you calc new tank pos, send it, then do vsync wait in that order it shoudl be perfectly fine |
| 21:23.32 | Chestal | we have the tick time for each frame, that#s what everything relates to |
| 21:23.33 | brlcad | assuming vsync time is less than round trip net, yeah maybe (which it better be) |
| 21:23.38 | tupone | hmm, if the remote client has a different refresh ratge? |
| 21:23.59 | tupone | the message will be waiting on the queue |
| 21:24.04 | brlcad | Chestal: hm, I wouldn't say "everything" or ducati-style wouldn't have fallen apart.. |
| 21:24.34 | Chestal | ehm |
| 21:24.35 | tupone | sometime, and sometime not |
| 21:25.00 | Chestal | I think you are talkign about thigns that are onyl issues in extreme cases (like very low frame rate) |
| 21:25.08 | Chestal | the biggest problem I see right now are high frame rates |
| 21:25.20 | Chestal | where the pos calcualtion will give you wrong results |
| 21:25.40 | Chestal | looks like the same bug is still in 2.1, I haven't really been following things for a few months |
| 21:25.47 | Chestal | you get tanks which move and rotate too fast |
| 21:26.40 | tupone | yeah, physics is FPS dependent, mainly time of contact with the ground |
| 21:26.52 | Chestal | I fear that noone really understands how tank update, clock sync etc. is really done right now. Or am I mistaken? |
| 21:27.13 | tupone | clock sync? what is now ? |
| 21:27.19 | Chestal | tupone: the problem I am referring to is a if (dt < 0.001) dt = 0.001 |
| 21:28.02 | tupone | I removed my clock sync |
| 21:28.16 | Chestal | which makes everyone with very high fps do tiny teleports resulting in fast movement |
| 21:28.22 | tupone | that is another hack /me is innocent on that |
| 21:28.46 | Chestal | tupone: I refer to the global clock in 2.1 |
| 21:29.36 | Chestal | I suspect that there are lots of player whose tanks move too fast |
| 21:29.40 | Chestal | and they don't even know it |
| 21:29.41 | tupone | global clock is wrong to me. I removed it as physics was wrong with that |
| 21:29.57 | Chestal | at least on the simple maps |
| 21:30.27 | tupone | But someone readded on 2.1 |
| 21:30.40 | Chestal | for example then TRB plays with 1000fps his tan kwill misbehave :-) |
| 21:31.07 | Erroneous | we don't sleep out the rest of the time? |
| 21:31.14 | Erroneous | that's silly |
| 21:31.20 | Chestal | Erroneous: there is no compensation at all |
| 21:31.46 | Chestal | just one lien to ensure that dt for the movement calc is never below 0.001s (a symbolci constant in 2.1) |
| 21:32.04 | Chestal | I assume it was introducec because tiny dts messed up the calcs, don't know |
| 21:32.21 | Erroneous | nothing particularly wrong with making sure we have a decent dt, means we don't have to be as careful with math later on |
| 21:32.28 | Erroneous | but we should not lie about dt |
| 21:32.37 | brlcad | Chestal: the "dt" i referred to later, was some fixed dt that wasn't tied to display framerate at all (like 100ms) .. just fyi in case that was misleading |
| 21:32.49 | Erroneous | if we say dt=.001 then we should sleep until dt does =.001 |
| 21:33.37 | brlcad | which would really beg the need for processes/threading or some really creative select loops |
| 21:33.48 | Chestal | hard to sleep such a short time accurately |
| 21:33.58 | Erroneous | doesn't need to be accurate |
| 21:34.07 | Chestal | I guess it coudl easily lead to perceived jerkiness on the local side |
| 21:34.21 | Erroneous | as long as it's not way too far of (like < 1/100 s) |
| 21:34.21 | brlcad | just needs to be consistent and not readily influenced by other activity |
| 21:34.21 | Chestal | like the energy saver does now depending on the system |
| 21:34.32 | Chestal | well, right now it influences the drawing |
| 21:34.42 | Erroneous | yup |
| 21:34.56 | Chestal | still better than calcing wrong values |
| 21:35.02 | brlcad | right, it just slows everything way down by sleeping if not enough time has passed, which lets the cpu cool |
| 21:35.03 | Chestal | nothing is worse :-) |
| 21:35.08 | Erroneous | but again, if your dt < .001, your fps is way faster than you can see anyway :) |
| 21:37.43 | Chestal | lupi's pentagon server has a modified position update check which is based on the tiestamps the client sends |
| 21:38.01 | Chestal | so theoretically it should be 100% accurate (unless the client has some complex cheating scheme) |
| 21:38.25 | Chestal | but it still seems to kick me even when I use vsync, which is a bit strange. Havem't really found out what's going on |
| 21:40.12 | Chestal | the observer feature which also displays this apparent speed is worthless as it is I fear |
| 21:40.22 | TheRedBaron | lupi's pentagon server rocks :) |
| 21:40.51 | Chestal | because the position update will not always be too big, and at a rate of let's say 30 updates a second, you wouldn't even notice one wrong value |
| 21:41.11 | Chestal | TRB: do you usually use vsync or other means of fps throttling? |
| 21:43.43 | Chestal | fglrx finally stopped a busy wait for vsync, btw. |
| 21:44.02 | Chestal | in earlier versions, fps would be capped, but I woudl still have 100% CPU usage all the time |
| 21:44.39 | TheRedBaron | Chestal: vsync to throttle fps |
| 21:44.44 | *** join/#bzflag bier_ (n=bier@p54A51367.dip0.t-ipconnect.de) |
| 21:44.49 | tupone | That means that we have the possibility to do multithread with ATI |
| 21:44.50 | Chestal | if you play with very high fps (maybe > 500) chances are that pentagon will kick you |
| 21:45.35 | brlcad | Erroneous: on an entirely different note .. I have yet to sort out why the ansi string processing is whacked .. the code as far as I can tell is _identical_ |
| 21:45.50 | Erroneous | want me to look at it? |
| 21:46.02 | brlcad | gonna try some gdbage later tonight to hopefully get somewhere, but I might punt for a stripAnsiStrings for the time being :) |
| 21:46.13 | Erroneous | heh |
| 21:46.16 | brlcad | if you want, maybe something silly I missed |
| 21:47.03 | brlcad | but I went line by line through the render code .. assuming the find()'s are working, it shouldn't be different |
| 21:47.34 | brlcad | I did see your "there should be a faster way to do this" comment, funny |
| 21:49.09 | Erroneous | heh |
| 21:53.13 | *** part/#bzflag TheRedBaron (n=Kalen@fl-71-52-16-80.dhcp.embarqhsd.net) |
| 21:54.17 | brlcad | only thing that came to mind was to not keep running the repetitive finds, just iterate and keep pointers, the state, and act as codes are read in |
| 21:54.21 | *** join/#bzflag TheRedBaron (n=Kalen@fl-71-52-16-80.dhcp.embarqhsd.net) |
| 21:54.26 | brlcad | can't imagine that's that expensive though |
| 21:59.02 | Erroneous | it seemed pretty slow when I wrote it. I think there were a few optimizations made sense |
| 21:59.04 | Erroneous | since |
| 21:59.36 | Erroneous | I was mostly thinking of something fundamentally different though, just didn't have anything in particular in mind that would do the trick |
| 22:02.05 | brlcad | you mean other than ansi or some other way of processing the ansi codes? |
| 22:03.48 | brlcad | woot, got coverity to add brl-cad .. now just need to get them to add bzflag ... |
| 22:17.26 | *** part/#bzflag LongDo1 (n=LongDon@host-091-097-018-193.ewe-ip-backbone.de) |
| 22:38.21 | *** join/#bzflag AAA_awright (n=chatzill@wsip-68-14-251-102.ph.ph.cox.net) |
| 22:38.57 | *** join/#bzflag Erroneous (n=dtremena@67-131-219-2.dia.static.qwest.net) |
| 22:45.27 | Winny | god, does axl rose ever grow up? |
| 22:47.45 | Erroneous | iirc he's in his 20s |
| 22:48.03 | Erroneous | not that you'd know it from the way he acts |
| 22:56.03 | Winny | wow, I figured he was an angry 10 year old |
| 22:57.32 | gsnedders | while (act_like_child) age--; |
| 23:01.36 | donny_baker | ~DTRemenak++ |
| 23:01.50 | donny_baker | great explanation on the airspawn |
| 23:01.57 | Erroneous | thanks |
| 23:02.37 | Erroneous | just seemed like there's been a bunch of misinformation out there about spawning stuff recently |
| 23:04.36 | Erroneous | you had the right idea mostly, but there have been some pretty off the wall things said in other forums |
| 23:10.12 | *** join/#bzflag bier_ (n=bier@p54A51367.dip0.t-ipconnect.de) |
| 23:22.56 | blast007 | ~DTRemenak++ |
| 23:37.32 | ruskie | lol |
| 23:37.37 | ruskie | axl rose that guy is hilarious |
| 23:37.44 | ruskie | keeps trying to get own team flag |
| 23:52.56 | *** join/#bzflag bier_ (n=bier@p54A51367.dip0.t-ipconnect.de) |
| 23:57.08 | *** mode/#bzflag [+v Erroneous] by ChanServ |
