| 00:07.41 | delusional | did you see our 2.99 statsboard? we had it actually working. http://images.planet-mofo.com/A-Delusion/mofo4/statsboard.png |
| 00:08.30 | blast007 | yeah, I had an article about it on my blog ;) |
| 00:08.33 | delusional | blast... if we could do it without restarting the gameserver.... we could do current stats, at least up to the player's last join |
| 00:08.49 | blast007 | well, you wouldn't want to change it too often |
| 00:08.57 | delusional | why not? |
| 00:09.22 | delusional | I was thinking daily.. until you said that |
| 00:09.25 | blast007 | because users don't need 50 different images a day stored to their cache |
| 00:09.47 | delusional | they'd have to join 50 times for that |
| 00:09.52 | blast007 | right |
| 00:10.04 | delusional | and each tie after an image update |
| 00:10.08 | delusional | time |
| 00:10.31 | blast007 | assuming my idea even works ;) |
| 00:10.39 | delusional | how would this work with an http redirect? |
| 00:11.06 | blast007 | I'd have to try it |
| 00:11.10 | delusional | OO I C |
| 00:11.11 | blast007 | it might not |
| 00:11.32 | delusional | no it would not work |
| 00:11.41 | blast007 | curl (what was use for HTTP) should support redirects |
| 00:11.56 | blast007 | it just depends how our code picks up the final URL |
| 00:12.03 | blast007 | what we* |
| 00:12.05 | delusional | their cache would not detect the change, unless the server was restarted |
| 00:12.26 | blast007 | depends |
| 00:12.31 | delusional | they wouldnt know to get a new image |
| 00:12.49 | blast007 | if it stores the file as the redirected URL (which would be unique to each update) then it might work |
| 00:12.58 | blast007 | if it stores it as the script URL, then it won't |
| 00:13.03 | delusional | the client stores it? |
| 00:13.14 | blast007 | the directory structure is based in the URL |
| 00:13.24 | blast007 | and there's an index file as well too, I think |
| 00:14.06 | blast007 | example from my CacheIndex.txt: |
| 00:14.08 | blast007 | http://images.bzflag.org/bbentz/blue_weave.png |
| 00:14.09 | blast007 | 105791 1225631920 0 8808b9931af482a9eb8c3d3319412df0 |
| 00:14.32 | blast007 | <filesize> <filetime> <lastused> <md5check> <--- that's what those fields are on the second line |
| 00:15.42 | delusional | hmm... maybe.. |
| 00:21.44 | *** join/#bzflag short_circuit (~spldart2@c-98-197-20-61.hsd1.tx.comcast.net) |
| 00:40.30 | delusional | did the simplestats plugin ever work right? |
| 00:41.34 | KTL | euh i belief it works |
| 00:41.40 | KTL | believe |
| 00:42.04 | KTL | but the argument is the plugin configuration file |
| 00:42.23 | KTL | and that file should say to where it has to output |
| 00:46.14 | delusional | I don't know KTL... I've tried it several times, and have always had bad experiences with simplestats.... half complete stats... out of memory errors... Maybe it conflicts with other plugins or something. |
| 00:46.32 | delusional | maybe i was using an early version of source. |
| 00:46.46 | delusional | idunno |
| 00:46.53 | KTL | maybe i will get errors soon :) |
| 00:47.04 | KTL | but in that case, i can debug |
| 00:57.44 | trepan | it's too bad that the 'updateDownloads' bzdb var defaults to '0' |
| 00:57.59 | trepan | you wouldn't even need to rename the textures ... |
| 01:00.42 | trepan | you'll just be updating your map with a new texture name when you restart? (probably based on the date if it's daily) |
| 01:04.21 | *** join/#bzflag AAA_awright_ (~a3@ip24-251-157-63.ph.ph.cox.net) |
| 01:07.48 | blast007 | trepan: was wondering if as restart wouldn't be necessary if HTTP redirects were used |
| 01:07.54 | blast007 | s/as/a/* |
| 01:08.53 | trepan | why would the client update? |
| 01:11.28 | trepan | look in Downloads.cxx updateDownloads becomes checkForCache ... |
| 01:11.49 | trepan | s/cxx/cxx,/ |
| 01:32.12 | delusional | tat's what I said.. the client won't update |
| 01:45.19 | blast007 | like I was saying though, the URL would be different each time |
| 01:45.23 | blast007 | but it doesn't seem like that works |
| 01:45.40 | blast007 | client doesn't seem to follow the redirect |
| 01:54.01 | trepan | the original URL would be the same, which is all that code is looking for |
| 01:54.42 | blast007 | yeah |
| 02:00.41 | *** join/#bzflag soxs (~Adium@pool-72-74-214-104.bstnma.east.verizon.net) |
| 02:09.58 | delusional | it seems to pick up the new image for me.. as long as I quit the client |
| 02:11.10 | delusional | and I'm not using a redirect.... just changing the image |
| 02:11.54 | delusional | map is nchanged |
| 02:11.58 | delusional | un |
| 02:12.00 | blast007 | delusional: do you have "Connection Updates" turned on or off in your Cache Settings? |
| 02:12.26 | delusional | ON |
| 02:12.33 | blast007 | it defaults to Off |
| 02:12.44 | *** join/#bzflag allejo (~allejo@cpe-76-95-144-121.socal.res.rr.com) |
| 02:13.12 | blast007 | turn it off, and it probably won't work anymore |
| 02:13.39 | delusional | w're gonna go with a new image every day |
| 02:46.01 | *** join/#bzflag spldart (~spldart2@c-98-197-20-61.hsd1.tx.comcast.net) |
| 02:46.01 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 02:46.01 | *** mode/#bzflag [+v spldart] by ChanServ |
| 02:59.13 | *** join/#bzflag ts_ (~ts@BZ.BZFLAG.BZ) |
| 03:11.05 | *** join/#bzflag CIA-33 (~CIA@208.69.182.149) |
| 03:14.29 | *** join/#bzflag NitroxisFreenode (~nitroxis@static.80.181.47.78.clients.your-server.de) |
| 03:14.30 | *** join/#bzflag bier (~bier@p54A5B231.dip.t-dialin.net) |
| 03:14.30 | *** join/#bzflag ruskie (ruskie@sourcemage/mage/ruskie) |
| 03:14.30 | *** join/#bzflag McSpider (~McSpider@bzextreme.com) |
| 03:14.30 | *** join/#bzflag Bambino (~bambino@unaffiliated/sniper15) |
| 03:14.30 | *** join/#bzflag Gilly (~btw@about/essy/ilkimys/gilly) |
| 03:18.22 | *** join/#bzflag AAA_awright (~a3@ip24-251-157-63.ph.ph.cox.net) |
| 03:18.22 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 03:18.49 | *** join/#bzflag Thumper_ (~Thumper@about/essy/coffeeAddict/Thumper) |
| 03:18.49 | *** join/#bzflag Chestal (thilo@141.99.42.43) |
| 03:18.49 | *** mode/#bzflag [+vo Thumper_ Chestal] by anthony.freenode.net |
| 03:19.15 | *** join/#bzflag ahs3- (~ahs3@adsl-065-005-193-158.sip.rdu.bellsouth.net) |
| 03:19.15 | *** join/#bzflag mrapple (~mrapple@bzflag/player/MrAppleComputer) |
| 03:19.16 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 03:19.16 | *** join/#bzflag McYukon (~McYukon@bzextreme.com) |
| 03:19.16 | *** join/#bzflag bier|tp (~bier@p54A5B231.dip.t-dialin.net) |
| 03:19.16 | *** join/#bzflag brad` (~brad@uk.moooo.org) |
| 03:19.16 | *** join/#bzflag TyroneFHornigh (~dbw@adsl-71-137-4-81.dsl.sndg02.pacbell.net) |
| 03:19.16 | *** join/#bzflag FastLizard4|zZzZ (fastlizard@wikipedia/pdpc.active.FastLizard4) |
| 03:19.16 | *** mode/#bzflag [+vo spldart TyroneFHornigh] by anthony.freenode.net |
| 03:19.35 | *** join/#bzflag sirquine (~quine@c-67-186-15-145.hsd1.pa.comcast.net) |
| 03:19.35 | *** join/#bzflag L4m3r (~l4m3r@bzflag/developer/L4m3r) |
| 03:19.35 | *** join/#bzflag Gnurdux (~gnurdux@EASTCAMPUS-FORTY-SEVEN.MIT.EDU) |
| 03:19.35 | *** join/#bzflag trepan (~trepan@unaffiliated/trepan) |
| 03:19.35 | *** join/#bzflag blast007 (~blast007@bzflag/developer/Blast) |
| 03:19.36 | *** mode/#bzflag [+vvv L4m3r trepan blast007] by anthony.freenode.net |
| 03:20.11 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 03:20.11 | *** join/#bzflag jcp (alex@bzflag/contributor/javawizard2539) |
| 03:20.11 | *** join/#bzflag PrezKennedy (MK@whitecalf.net) |
| 03:20.11 | *** join/#bzflag GvzEvxre (timr@bzflag/projectlead/TimRiker) |
| 03:20.11 | *** join/#bzflag brad (~brad@moooo.org) |
| 03:20.11 | *** join/#bzflag cods (~cods@rsbac/developer/cods) |
| 03:20.11 | *** join/#bzflag fahadsadah (fahad@unaffiliated/fahadsadah) |
| 03:20.11 | *** join/#bzflag mac-mini (~mac-mini@unaffiliated/macmini/x-648924) |
| 03:20.11 | *** join/#bzflag Admirarc1 (~Athelthra@mrush.mth.abdn.ac.uk) |
| 03:20.11 | *** mode/#bzflag [+o GvzEvxre] by anthony.freenode.net |
| 03:20.34 | *** join/#bzflag eTangenT (~lamer@c-98-245-170-238.hsd1.co.comcast.net) |
| 03:20.34 | *** join/#bzflag catay (~smertens@kaiya.catay.be) |
| 03:20.35 | *** join/#bzflag me1 (~tony@bzflag/player/Me1) |
| 03:20.35 | *** join/#bzflag sam (sam@poulet.zoy.org) |
| 03:28.14 | *** join/#bzflag Marzipan (~Marzipan@bzflag/player/Marzipan) |
| 04:35.52 | *** join/#bzflag KTL (~KTL@213.219.154.177.adsl.dyn.edpnet.net) |
| 04:50.10 | *** part/#bzflag soxs (~Adium@pool-72-74-214-104.bstnma.east.verizon.net) |
| 05:43.57 | *** join/#bzflag noyb (~noyb@pool-108-23-105-197.lsanca.dsl-w.verizon.net) |
| 06:02.48 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 06:02.48 | *** mode/#bzflag [+v spldart] by ChanServ |
| 06:06.31 | *** join/#bzflag noyb (~noyb@pool-108-23-105-197.lsanca.dsl-w.verizon.net) |
| 06:47.01 | *** join/#bzflag noyb (~noyb@pool-108-23-105-197.lsanca.dsl-w.verizon.net) |
| 06:51.06 | *** join/#bzflag noyb (~noyb@pool-108-23-105-197.lsanca.dsl-w.verizon.net) |
| 06:59.44 | *** join/#bzflag Marzipan- (~Marzipan@p5B225663.dip.t-dialin.net) |
| 07:01.01 | *** join/#bzflag Marzipan (~Marzipan@bzflag/player/Marzipan) |
| 07:20.49 | *** join/#bzflag bier|tp (~bier@p54A5B231.dip.t-dialin.net) |
| 07:41.40 | *** join/#bzflag bier|tp (~bier@p54A5B231.dip.t-dialin.net) |
| 09:27.38 | *** join/#bzflag ts (~ts@bzflag/developer/ts) |
| 09:28.07 | CIA-33 | BZFlag: 0380.14.209.85 07http://my.bzflag.org * r7428 10/w/Other_Links: /* Other BZFlag-related sites */ |
| 13:09.11 | *** join/#bzflag Gnurdux (~gnurdux@EASTCAMPUS-FORTY-SEVEN.MIT.EDU) |
| 13:22.10 | *** join/#bzflag kierra (~jolie@unaffiliated/kierra) |
| 14:25.20 | *** join/#bzflag spldart (~spldart2@c-98-201-129-128.hsd1.tx.comcast.net) |
| 14:25.20 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 14:25.20 | *** mode/#bzflag [+v spldart] by ChanServ |
| 14:25.40 | *** join/#bzflag Upsetter (~Ups@i59F6D919.versanet.de) |
| 15:00.41 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 15:00.41 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 15:01.48 | *** join/#bzflag JeffM2501 (~JeffM@adsl-76-195-158-71.dsl.lsan03.sbcglobal.net) |
| 15:01.48 | *** join/#bzflag JeffM2501 (~JeffM@unaffiliated/jeffm2501) |
| 15:01.48 | *** mode/#bzflag [+v JeffM2501] by ChanServ |
| 15:43.15 | *** part/#bzflag Upsetter (~Ups@i59F6D919.versanet.de) |
| 15:48.36 | *** join/#bzflag sirquine (~quine@GARKBIT.WV.CC.CMU.EDU) |
| 15:54.12 | *** join/#bzflag kierra (~jolie@unaffiliated/kierra) |
| 15:57.22 | *** join/#bzflag temporalD_ (~a_temp_di@bzflag/serverop/TemporalDistraction) |
| 16:19.32 | *** join/#bzflag temporalD (~a_temp_di@bzflag/serverop/TemporalDistraction) |
| 16:53.30 | *** join/#bzflag bier|tp (~bier@p57A66AEF.dip.t-dialin.net) |
| 16:54.53 | *** join/#bzflag bier (~bier@p57A66AEF.dip.t-dialin.net) |
| 17:18.26 | *** join/#bzflag soxs (~Adium@pool-72-74-214-104.bstnma.east.verizon.net) |
| 17:18.36 | soxs | spawns are server side correct? |
| 17:32.37 | BulletCatcher | Yes, the server tells the client where to spawn. |
| 17:33.25 | Cobra_Fast | so the client could decide to spawn somewhere else though, right? |
| 17:33.57 | BulletCatcher | I'm not sure what would happen if it did that. |
| 17:34.21 | *** join/#bzflag me1 (~tony@bzextreme.com) |
| 17:37.09 | spldart | Seems if you spawned somewhere different than the server told you then at the first update by the client of your position you'd get kicked for excess speed or whatever that check is. |
| 17:40.42 | soxs | so if 1 particular server keeps giving horrible spawns, what can be done? |
| 17:41.53 | blast007 | soxs: depends |
| 17:42.00 | temporalD | they must have a spawnzone setup in the map. You could leave feedback for the owner/mapmaker to change the design and/or settings on the map file. |
| 17:42.19 | blast007 | "horrible spawns" is kinda vague |
| 17:42.24 | soxs | they are random spawns but they just don't seem so based on other servers playing the same map. |
| 17:42.57 | blast007 | then don't play on that server |
| 17:43.02 | soxs | for example, i jump, before i land there is somebody who just spawned on me and kills me. |
| 17:43.15 | soxs | well what can be done to fix it? |
| 17:43.27 | blast007 | well, is it your server? |
| 17:43.48 | soxs | no, but i can suggest it to be fixed if i can find a solution :) |
| 17:43.58 | blast007 | if it is, make sure you're using the right map file and not one modified to include spawn zones |
| 17:44.15 | blast007 | which server is this? |
| 17:44.22 | soxs | ah ok |
| 17:44.42 | soxs | so perhaps the saved map might have had some extra data in it, if that doesn't work then what? |
| 17:44.53 | blast007 | well, it really depends |
| 17:45.10 | blast007 | even with spawn zones (at least, SANE spawn zones), the server should try to pick a safe location |
| 17:45.24 | soxs | understood. |
| 17:45.52 | blast007 | so it could be the server is modified, but unlikely |
| 17:48.30 | brlcad | soxs: in addition to spawn zones, a server can specify a spawn policy -- three are provided including 'default', 'random', and 'dangerous' |
| 17:49.27 | blast007 | is there a command line option for that in 2.0.x? |
| 17:49.29 | brlcad | default attempts a safe spawn, random is truely random (meaning sometimes they're horrible), and dangerous tries to put the spawner in harms way |
| 17:49.37 | brlcad | mm, not sure about 2.0 |
| 17:49.48 | blast007 | -spawnPolicy only shows up in the help text for 2.99.x |
| 17:50.07 | soxs | interesting, never heard of this before. |
| 17:50.37 | brlcad | yeah, looks like 2.0 is just using 'default' even though the core policy infrastructure was in place |
| 17:52.22 | blast007 | so yeah, unless the server was modified, shouldn't be using the random policy |
| 17:52.37 | blast007 | and there doesn't appear (at a quick glance) to be a dangerous policy in 2.0.x |
| 17:52.42 | brlcad | probably just "bad luck" |
| 17:52.49 | soxs | yah, perhaps the "random" would actually be better for "default" |
| 17:53.07 | brlcad | if the server is a little overloaded, it will spend much less time looking for a safe place to spawn |
| 17:53.08 | blast007 | soxs: for a server without superflags, maybe |
| 17:53.16 | soxs | brlcad: possible, just seems to happen often, not just me, but others as well. |
| 17:53.24 | brlcad | soxs: you would probably not like random |
| 17:53.26 | soxs | yes this server doesn't have superflags |
| 17:53.30 | blast007 | otherwise random might spawn you near a SW user too often |
| 17:53.58 | brlcad | most people don't understand what real random really means ... |
| 17:54.02 | blast007 | soxs: well, if it happens often, start questioning the server owner |
| 17:54.10 | soxs | i've tried, they are stumped. |
| 17:54.49 | brlcad | it could be indicative of their map |
| 17:54.58 | BulletCatcher | As I understand it, the safety feature of the default spawn algorithm is for the benefit of the spawning tank, not for the other live tanks. |
| 17:55.13 | brlcad | the way the spawn algorithm tries to spawn on "ground" first, might find habitually unsafe locations that merely seem safe |
| 17:55.28 | soxs | BulletCatcher: that could be why. |
| 17:56.31 | BulletCatcher | A tank in the air might not be seen as a threat to a spawn position on the ground. |
| 17:56.42 | soxs | makes sense. |
| 17:57.46 | soxs | so it seems the spawn algorithm needs to take the live tanks into consideration ^^ |
| 17:59.25 | BulletCatcher | On Purple Panzer's FFA sniper map it is not unusual to spawn on the ground very close to an enemy tank that is up on a building. |
| 18:00.48 | blast007 | the server in question is also run off a VM - could that be affecting the "randomness" of the spawns? |
| 18:01.22 | blast007 | since he said it was happening more in THIS server compared to other servers with the same map |
| 18:03.12 | blast007 | (info: http://otrs.menandmice.com/otrs/public.pl?Action=PublicFAQ&CategoryID=22&ItemID=122 ) |
| 18:07.17 | BulletCatcher | BZFlag random numbers come from the standard rand(3) function, which doesn't have a lot of state but should work the same on all types of servers. |
| 18:10.21 | trepan | or close to the same; implementations may vary some, iirc |
| 18:13.08 | *** join/#bzflag cods (~cods@tuxee.net) |
| 18:13.59 | BulletCatcher | True, but I would expect the algorithm to be identical for a given operating system whether or not it is running in a VM. |
| 18:15.41 | BulletCatcher | Both client and server call bzfsrand(time(0)) once to set the seed. |
| 18:31.24 | *** join/#bzflag Anxuiz (~Anxuiz@50-46-121-138.evrt.wa.frontiernet.net) |
| 18:31.24 | *** join/#bzflag Anxuiz (~Anxuiz@unaffiliated/anxuiz) |
| 18:35.16 | *** join/#bzflag sirquine (~quine@GARKBIT.WV.CC.CMU.EDU) |
| 19:56.50 | *** join/#bzflag [dmp] (~dennis@users.d75.net) |
| 19:56.50 | *** join/#bzflag [dmp] (~dennis@unaffiliated/dmp/x-546784) |
| 20:12.40 | *** join/#bzflag KTL (~KTL@213.219.154.71.adsl.dyn.edpnet.net) |
| 20:20.59 | *** join/#bzflag TASAIRES (~TASAIRES@84.121.178.221.dyn.user.ono.com) |
| 20:26.07 | TASAIRES | alguien ha visto esta promocion del ABC??? http://www.abc.es/servicios/promociones/tablet-abc/index.html |
| 20:26.30 | TASAIRES | hola a todos |
| 20:29.40 | *** join/#bzflag KTL (~KTL@213.219.154.71.adsl.dyn.edpnet.net) |
| 20:36.01 | kierra_away | hola TASAIRES |
| 20:36.42 | TASAIRES | kierra_away: Hola |
| 21:01.28 | *** join/#bzflag sirquine (~quine@GARKBIT.WV.CC.CMU.EDU) |
| 21:48.17 | *** join/#bzflag cods (~cods@rsbac/developer/cods) |
| 22:48.30 | *** join/#bzflag sirquine (~quine@c-67-186-15-145.hsd1.pa.comcast.net) |
| 23:19.45 | delusional | I'm getting the new image without changing the bzw... Don't even have to restart the server...... Same bzw... Same URL... All i do is change the image's color table, and upload it over the existing image.... the client picks it up on rejoin. |
| 23:20.06 | delusional | changing the image's size works too |
| 23:21.19 | trepan | updateDownloads = 1 ? |
| 23:21.34 | delusional | Must have the "update downloads" setting tuerned on... it appears that's all you need. |
| 23:23.31 | delusional | I thought you might have to quit the client as well, but that appears to NOT be the case. |
| 23:23.59 | trepan | hm, I wonder if setting that BZDB var on the server would work |
| 23:24.14 | delusional | force set? |
| 23:24.28 | trepan | ya, that sort of thing still works in 2.0.x |
| 23:24.46 | trepan | (server setting client vars) |
| 23:25.23 | delusional | HEH, this is better than I had hoped. |
| 23:25.31 | trepan | if it doesn't work, then it would probably be an easy server hack to make it work, just send out some early BZDB msgs |
| 23:27.04 | delusional | i thought if you had to change the URL every time the image changed.. that would force the client to re-download the entire map at every join. But it appears that this is not necessary. |
| 23:27.28 | trepan | not if you use the 'hack' that i've mentionned |
| 23:27.36 | trepan | (assuming it works ;) |
| 23:28.12 | trepan | also note that it working may depend on how you have your server configured for authorization |
| 23:28.31 | delusional | I've already gotten all my players to change their downloadaccess files... I can get them to change this setting |
| 23:28.54 | delusional | ??? authorization?? |
| 23:28.57 | trepan | the vars seem to be emitted in bzfs.cxx/addPlayer() - run after authorization |
| 23:46.05 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
