| 00:01.28 | *** join/#bzflag ahs3- (~ahs3-@adsl-065-005-193-158.sip.rdu.bellsouth.net) |
| 00:40.27 | *** join/#bzflag spldart (~spldart2@c-98-198-227-61.hsd1.tx.comcast.net) |
| 00:40.27 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 00:40.27 | *** mode/#bzflag [+v spldart] by ChanServ |
| 00:43.50 | *** join/#bzflag mdskpr_ (~mdskpr@108.25.145.104) |
| 00:52.39 | *** join/#bzflag Marzipan (~Marzipan@bzflag/player/Marzipan) |
| 01:27.36 | *** join/#bzflag mdskpr_ (~mdskpr@108.25.145.104) |
| 01:52.22 | mdskpr_ | blast007: did you test it yet? |
| 02:08.16 | CIA-117 | BZFlag: 03173.234.122.130 07http://my.bzflag.org * r7709 10/w/To_the_beat_of_Novacane_A_cigarette_would_be_L_o_v_eeee_60: New page: [[Image:electronic_cigarette_1992.jpg|thumb|]] ? Sometimes you just absolutely need any smoke, and of course, you don't have matches or some lighter; just enjoy Murphy's Law , it usually... |
| 02:08.36 | CIA-117 | BZFlag: 03WongBass2 07http://my.bzflag.org * r0 10/w/Special:Log/upload: uploaded "[[Image:Electronic cigarette 1992.jpg]]" |
| 02:09.48 | CIA-117 | BZFlag: 03Mdskpr 07http://my.bzflag.org * r7711 10/w/To_the_beat_of_Novacane_A_cigarette_would_be_L_o_v_eeee_60: Removing all content from page |
| 02:10.12 | mdskpr_ | oh...that doesnt remove it >.< |
| 02:10.24 | delusional | i found that out awhile ago |
| 02:10.27 | blast007 | mdskpr_: I'll probably have time this weekend |
| 02:10.37 | mdskpr_ | ok blast |
| 02:10.44 | blast007 | also will be planning what data should actually get passed around and how |
| 02:11.05 | blast007 | I'm thinking that the current stuff isn't enough information |
| 02:12.18 | blast007 | my thought is to keep essentially a timeline of events (player score changes/leaving/joining, team score changes, etc) and push that raw data to the central server |
| 02:12.33 | CIA-117 | BZFlag: 03DTRemenak 07http://my.bzflag.org * r0 10/w/Special:Log/block: blocked [[User:WongBass2]] with an expiry time of infinite (account creation disabled): Spamming links to external sites |
| 02:13.00 | CIA-117 | BZFlag: 03DTRemenak 07http://my.bzflag.org * r0 10/w/Special:Log/delete: deleted "[[Image:Electronic cigarette 1992.jpg]]": spamtastic |
| 02:13.02 | blast007 | all the events would have a UTC timestamp (and the current UTC time would be sent when the update goes out) |
| 02:13.25 | mdskpr_ | could this also log chats? |
| 02:13.31 | mdskpr_ | or would that be too much |
| 02:13.35 | blast007 | don't want that |
| 02:13.45 | blast007 | it's stats, not facebook ;) |
| 02:13.48 | CIA-117 | BZFlag: 03DTRemenak 07http://my.bzflag.org * r0 10/w/Special:Log/delete: |
| 02:13.48 | CIA-117 | BZFlag: deleted "[[To the beat of Novacane A cigarette would be L o v eeee 60]]": |
| 02:13.48 | CIA-117 | BZFlag: content before blanking was: |
| 02:13.48 | CIA-117 | BZFlag: '[[Image:electronic_cigarette_1992.jpg|thumb|]]?Sometimes you just absolutely |
| 02:13.48 | CIA-117 | BZFlag: need any smoke, and of course, you don't have matches or some lighter...' |
| 02:14.24 | DTRemenak | sometimes the banhammer just feels so right |
| 02:17.18 | CIA-117 | BZFlag: 03DTRemenak 07http://my.bzflag.org * r0 10/w/Special:Log/block: blocked [[User:173.234.0.0/16]] with an expiry time of 6 months (anonymous users only, account creation disabled): Spamming links to external sites: block troublesome subnet |
| 02:18.24 | DTRemenak | hopes we have range blocks enabled |
| 02:18.41 | blast007 | no idea |
| 02:19.01 | blast007 | if it's not default, probably not |
| 02:19.14 | blast007 | and if it's a feature that was implemented in the last 5 years, probably not |
| 02:19.47 | DTRemenak | I believe both apply here :) |
| 02:30.13 | *** join/#bzflag blast007 (~blast007@bzflag/developer/Blast) |
| 02:30.13 | *** mode/#bzflag [+v blast007] by ChanServ |
| 02:36.29 | *** join/#bzflag ahs3- (~ahs3-@adsl-065-005-193-158.sip.rdu.bellsouth.net) |
| 02:40.53 | *** join/#bzflag JeffM (~Jeff@unaffiliated/jeffm2501) |
| 02:40.53 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 03:26.30 | *** join/#bzflag CIA-95 (cia@cia.atheme.org) |
| 04:57.56 | *** join/#bzflag yosefk (~John@70-138-149-250.lightspeed.hstntx.sbcglobal.net) |
| 04:59.56 | yosefk | where are the explode1 and explode2 png files used in the code? searching for explode or explosion isn't getting farther than glstates and singleton.h |
| 05:23.43 | *** join/#bzflag sirquine (~quine@c-71-237-73-109.hsd1.co.comcast.net) |
| 05:24.49 | BulletCatcher | yosefk: Search for "explode%d" in playing.cxx . |
| 05:43.41 | *** join/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 06:06.20 | CIA-95 | BZFlag: 03bullet_catcher * r21796 10/trunk/bzflag/src/bzflag/defaultBZDB.cxx: Spell "shotLength" correctly. |
| 06:15.39 | *** join/#bzflag Marzipan- (~Marzipan@p5B226A43.dip.t-dialin.net) |
| 06:17.20 | *** join/#bzflag Marzipan (~Marzipan@bzflag/player/Marzipan) |
| 06:19.47 | CIA-95 | BZFlag: 03bullet_catcher * r21797 10/trunk/bzflag/ (3 files in 2 dirs): |
| 06:19.47 | CIA-95 | BZFlag: Make the client email string empty by default. |
| 06:19.47 | CIA-95 | BZFlag: Remove the now-useless -anonymous command-line parameter to bzflag. |
| 06:56.07 | *** join/#bzflag jcp (alex@bzflag/contributor/javawizard2539) |
| 07:01.59 | CIA-95 | BZFlag: 03bullet_catcher * r21798 10/trunk/bzflag/src/bzflag/bzflag.cxx: Use the saved email string, if any. Otherwise leave it empty. |
| 07:15.09 | *** join/#bzflag Pimpi (~frank@gondolin.pimpi.org) |
| 08:17.50 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 08:24.51 | *** join/#bzflag Scrumpy (~Scrumpy@smurfnet.xs4all.nl) |
| 08:31.05 | *** join/#bzflag Scrumpy (~Scrumpy@smurfnet.xs4all.nl) |
| 11:29.11 | *** join/#bzflag tupone (~tupone@gentoo/developer/tupone) |
| 11:29.11 | *** mode/#bzflag [+v tupone] by ChanServ |
| 12:31.18 | *** join/#bzflag mdskpr_ (~mdskpr@108.25.145.104) |
| 12:55.59 | blast007 | BulletCatcher: think it would make sense for our config upgrade code to clear the email if it contains an @ symbol? |
| 13:47.57 | *** join/#bzflag yosef (468a95fa@gateway/web/freenode/ip.70.138.149.250) |
| 14:12.43 | *** join/#bzflag Pimpi (~frank@gondolin.pimpi.org) |
| 14:19.24 | BulletCatcher | blast007: Yes, based on a survey of email strings seen on my server. |
| 14:19.25 | BulletCatcher | To make it a one-time change I think it means we will have to increment config_version from 3 to 4. |
| 14:26.04 | *** join/#bzflag bier (~bier@p54A5AC18.dip.t-dialin.net) |
| 14:26.06 | *** join/#bzflag bier|tp (~bier@p54A5AC18.dip.t-dialin.net) |
| 14:27.32 | *** join/#bzflag bier (~bier@p54A5AC18.dip.t-dialin.net) |
| 14:30.38 | *** join/#bzflag fahadsadah (fahad@unaffiliated/fahadsadah) |
| 14:31.25 | blast007 | BulletCatcher: specifically I mean for the 2.0.x -> 2.4.x upgrade, if that matters |
| 14:36.41 | blast007 | I'll check on that later (iirc, the Windows configuration file is in a different spot now, so it might be a bit wacky for Windows now) |
| 14:51.15 | BulletCatcher | The updateConfigFile() function in src/bzflag/clientConfig.cxx seems to be the place for one-time config file changes. |
| 15:02.05 | blast007 | ok |
| 15:02.24 | *** join/#bzflag Zac124254 (ca59b013@gateway/web/freenode/ip.202.89.176.19) |
| 15:06.50 | *** join/#bzflag spldart (~spldart2@c-98-198-227-61.hsd1.tx.comcast.net) |
| 15:06.50 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 15:06.50 | *** mode/#bzflag [+v spldart] by ChanServ |
| 15:15.38 | *** join/#bzflag blast007 (~blast007@bzflag/developer/Blast) |
| 15:15.38 | *** mode/#bzflag [+v blast007] by ChanServ |
| 15:45.50 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 15:45.50 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 16:04.38 | *** join/#bzflag fahadsadah (fahad@unaffiliated/fahadsadah) |
| 16:15.55 | *** join/#bzflag jh` (~jh_@212-149-234-105.bb.dnainternet.fi) |
| 16:17.12 | *** join/#bzflag catay (~smertens@kaiya.catay.be) |
| 16:54.50 | *** join/#bzflag temporalD (~a_temp_di@bzflag/serverop/TemporalDistraction) |
| 16:56.07 | *** join/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 17:02.08 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 17:02.08 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 17:08.42 | *** join/#bzflag Scrumpy (~Scrumpy@smurfnet.xs4all.nl) |
| 17:13.21 | CIA-95 | BZFlag: 03bullet_catcher * r21799 10/trunk/bzflag/ (47 files in 12 dirs): |
| 17:13.21 | CIA-95 | BZFlag: Relabel the player "email" string as "motto". |
| 17:13.21 | CIA-95 | BZFlag: Ignore any preexisting email string with an "@" character in it. |
| 17:17.59 | *** join/#bzflag tupone (~tupone@host83-224-dynamic.47-79-r.retail.telecomitalia.it) |
| 17:17.59 | *** join/#bzflag tupone (~tupone@gentoo/developer/tupone) |
| 17:17.59 | *** mode/#bzflag [+v tupone] by ChanServ |
| 17:21.31 | *** join/#bzflag Erroneous (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 17:21.31 | *** mode/#bzflag [+v Erroneous] by ChanServ |
| 17:36.32 | Cobra_Fast | OMG the bzbb will die soon: "Our newest member Cancer" |
| 17:37.27 | BulletCatcher | It's just a crab, so no worries. |
| 17:42.24 | *** join/#bzflag Scrumpy (~Scrumpy@smurfnet.xs4all.nl) |
| 17:44.46 | JeffM | what kinda circles does bzbb hang around in if it gets crabs? |
| 17:51.08 | blast007 | it's more like ovals |
| 17:56.01 | Cobra_Fast | guys, what a crab? |
| 17:56.06 | Cobra_Fast | *whats |
| 17:56.26 | BulletCatcher | Something very off-topic for this channel. |
| 17:57.01 | Cobra_Fast | google insists in telling me that its a waterborn animal |
| 17:57.11 | Cobra_Fast | but that wont make much sense in context ... |
| 17:59.16 | blast007 | Cobra_Fast: google cancer crab |
| 17:59.33 | Cobra_Fast | still animals. |
| 17:59.44 | blast007 | constellation |
| 17:59.58 | blast007 | astrology |
| 18:00.00 | blast007 | etc |
| 18:00.51 | Cobra_Fast | oh its that sort of thing ... okay |
| 18:01.49 | Cobra_Fast | thanks |
| 18:09.47 | *** join/#bzflag trepan (~trepan@unaffiliated/trepan) |
| 18:09.47 | *** mode/#bzflag [+v trepan] by ChanServ |
| 18:12.33 | blast007 | does this seems like a reasonable set of data for the push stats stuff? http://static.bzexcess.com/push_stats.xml (though I'd have the timeline reversed to the oldest was at the top..) |
| 18:12.50 | blast007 | note that I wouldn't necessarily have it in XML format - was just easier to mock up that way |
| 18:13.34 | blast007 | that's also only player info. There's maybe need to be stuff for adding/removing servers |
| 18:14.09 | CIA-95 | BZFlag: 03trepan * r21800 10/branches/experimental/v2_99continuing/bzflag/ (3 files in 3 dirs): |
| 18:14.09 | CIA-95 | BZFlag: * use 'env echo -e' instead of 'echo -e' to avoid shell 'echo' implementations |
| 18:14.09 | CIA-95 | BZFlag: (not a great solution, but it's a start) |
| 18:14.20 | blast007 | and maybe passing the -advertise values and only showing hidden servers if people are authenticated to the stats site and are in that group? |
| 18:14.33 | Cobra_Fast | I like it being XML. And it looks good to me so far. But I dont quite understand it being sorted in a timeline!? |
| 18:15.02 | trepan | prefers json or lua, less wordy :) |
| 18:15.17 | trepan | and json have obvious benefits for webbery |
| 18:15.19 | blast007 | yeah, I like JSON too |
| 18:15.33 | *** join/#bzflag Scrumpy (~Scrumpy@smurfnet.xs4all.nl) |
| 18:15.33 | blast007 | easier to parse in PHP :) $array = json_decode($json); |
| 18:15.47 | Cobra_Fast | harder to parse in .NET/Mono |
| 18:16.08 | trepan | pff ;) |
| 18:16.28 | blast007 | Cobra_Fast: so the 11 parses listed on json.org are all hard to use? |
| 18:16.46 | blast007 | parsers* |
| 18:17.03 | Cobra_Fast | well .net doesnt ship with a json parser like php does. that what i ment to point out. |
| 18:17.03 | trepan | blast007: beat me to it |
| 18:17.34 | blast007 | .net also doesn't ship with lots of stuff, but it's trivial to add extra libs to your project |
| 18:17.56 | Cobra_Fast | it ships with some sophisticated xml classes |
| 18:18.17 | blast007 | luckily, we're using PHP for the stats site ;) so the point is moot. |
| 18:19.05 | blast007 | also, the point of it being sorted in a timeline is so that we can reprocess data later if we need to |
| 18:19.08 | Cobra_Fast | well right, output format should be lower priority. |
| 18:19.17 | blast007 | and the central server will determine what is important |
| 18:19.38 | Cobra_Fast | oh so the stats output collects data over the entire uptime? |
| 18:19.47 | blast007 | yeah |
| 18:19.55 | blast007 | well, it *will* |
| 18:19.55 | Cobra_Fast | wouldnt that blow up the output file/streamsize? |
| 18:19.59 | trepan | epoch times? |
| 18:20.20 | blast007 | trepan: UTC unix timestamps |
| 18:20.41 | blast007 | it would periodically send the current timeline to the central server (say, every 5 or 10 minutes) |
| 18:21.31 | trepan | could also add eventids for loopy event situations |
| 18:21.35 | blast007 | it would slap the current local UTC timestamp into the update, and the central server would compare that to it's own idea of the UTC time and compute time offsets for all of the events, so that it's based on the time of the central stats server |
| 18:22.03 | blast007 | trepan: probably not too critical if there are duplicate timestamps, if that's what you mean |
| 18:22.14 | blast007 | it would process the events in order |
| 18:22.44 | trepan | and update ids |
| 18:23.11 | blast007 | would that be necessary? |
| 18:23.20 | trepan | might help find missing msgs, debugging, etc... |
| 18:23.29 | trepan | doesn't cost you much |
| 18:23.40 | *** join/#bzflag djlawler (~LD003@lma625.siteprotect.com) |
| 18:23.44 | *** part/#bzflag djlawler (~LD003@lma625.siteprotect.com) |
| 18:23.45 | blast007 | "missing messages" meaning what? |
| 18:23.45 | trepan | start at 1 when bzfs starts, and keep on inc'ing |
| 18:24.05 | trepan | server was disconnected for a while, spinning out, whatever |
| 18:24.40 | blast007 | still not clear. do you mean if the server was unable to push stats to the central server for whatever reason? |
| 18:25.46 | trepan | sure |
| 18:26.05 | trepan | it's low cost, and it might make things a little easier to debug/track |
| 18:26.18 | blast007 | k |
| 18:29.00 | BulletCatcher | I would like to see the server owner in there somewhere, but I'm not sure whether it should be pushed (not trustworthy) or determined by the stats server. |
| 18:30.06 | blast007 | it could pass the public key |
| 18:30.11 | blast007 | public server key* |
| 18:30.34 | trepan | sounds like a good idea |
| 18:30.38 | BulletCatcher | That ought to be sufficient, as long as the stats server is trusted to keep it secret. |
| 18:31.06 | blast007 | as trusted as the server key page itself :P |
| 18:31.15 | BulletCatcher | Good enough. :-) |
| 18:31.27 | blast007 | unless someone uses a third party stats site |
| 18:31.44 | BulletCatcher | That's the kind of situation I was concerned about. |
| 18:31.52 | trepan | the <event> have to be ordered chronologically? (ie: if two happened at timestep 1307122246 the first listed had to have happened first?) |
| 18:32.06 | blast007 | shrugs |
| 18:32.11 | trepan | another reason for event_ids, to simplify |
| 18:32.42 | BulletCatcher | Yup. Sequence numbers would solve that problem nicely. |
| 18:32.44 | trepan | if you get a join and a leave in the same second, is the player still connected? (without knowing pre or post state...) |
| 18:32.53 | *** join/#bzflag TASAIRES (~TASAIRES@20.Red-88-20-133.staticIP.rima-tde.net) |
| 18:32.55 | *** join/#bzflag TASAIRES_ (~TASAIRES@20.Red-88-20-133.staticIP.rima-tde.net) |
| 18:34.55 | BulletCatcher | trepan: "/bin/echo -e" is a GNU coreutils feature. Mac OS X & Solaris don't support -e natively. |
| 18:35.20 | trepan | BulletCatcher: I know |
| 18:35.39 | trepan | apparently, cmake solves the issues by echo'ing through the cmake exec :) |
| 18:35.56 | BulletCatcher | k |
| 18:35.58 | trepan | might build his own echo exec and run it through that |
| 18:36.12 | trepan | such a silly thing to have to piss about with |
| 18:38.11 | trepan | if I write my own echo, it'll have escape codes like \R=red \G=green, etc... :) |
| 18:38.24 | BulletCatcher | POSIX has invaded most operating systems well enough that most of that type of implementation difference is gone. |
| 18:38.26 | BulletCatcher | But some things (like this one) remain. |
| 18:39.34 | trepan | yup, minor pitas |
| 18:40.04 | trepan | remembers his bzmapper code having lots of extra color escape codes, cleans things up |
| 18:41.13 | trepan | heh, could just use the ones from bzw.5 (3.0) Text object |
| 18:43.35 | *** join/#bzflag Pimpi (~frank@gondolin.pimpi.org) |
| 18:59.01 | *** join/#bzflag Scrumpy (~Scrumpy@smurfnet.xs4all.nl) |
| 19:06.46 | *** join/#bzflag Scrumpy (~Scrumpy@smurfnet.xs4all.nl) |
| 19:19.07 | *** join/#bzflag sigonasr2 (~sigonasr2@ip68-0-162-159.tc.ph.cox.net) |
| 19:20.59 | sigonasr2 | Greetings, I have a plugin issue if someone has some time to look at it real quick. The rest of the plugin works correctly except for this part. I am a C programmer, not C++ so most of the code is tied to my C knowledge. There must be something I am clearly missing here if someone could look at lines 220-242 specifically. Client crashes server upon certain deaths. Must be one of the cases. |
| 19:20.59 | sigonasr2 | http://pastebin.com/V3LYVkMN |
| 19:23.38 | blast007 | you need to be checking for NULL's |
| 19:24.19 | sigonasr2 | For playerID I would assume? |
| 19:25.11 | blast007 | no, don't assume that bz_getPlayerByIndex will return a valid player record. |
| 19:26.11 | blast007 | so in other words, don't do bz_getPlayerByIndex(index)->callsign |
| 19:26.43 | blast007 | trying to access member data on a null pointer == crashy |
| 19:27.19 | blast007 | so what you should be doing is: player = bz_getPlayerByIndex(index); if (player != NULL) { do stuff with player here } |
| 19:28.31 | blast007 | you could cut down on your code in a lot of places too |
| 19:28.37 | sigonasr2 | Alright, that helps blast. But now I am confused a bit more. The lines that crash the server actually do not use bz_getPlayerByIndex, only my Part Event does yet nothing there has crashed the server? |
| 19:28.55 | blast007 | what line did it crash on in your plugin? |
| 19:29.14 | sigonasr2 | Lines 220-242. I ran debug messages, and the plugin outputted to this point, in the DieEvent. |
| 19:29.21 | blast007 | which one specifically |
| 19:29.35 | sigonasr2 | The value was different each time. |
| 19:29.47 | blast007 | well give me an example of an exact line that it crashed on |
| 19:30.03 | blast007 | oh I see |
| 19:30.05 | sigonasr2 | Line 236 is one I know for sure. |
| 19:32.24 | blast007 | perhaps racetime[playerID] doesn't exist. Are you loading this plugin while a server is running? |
| 19:32.47 | blast007 | hmm, nvm, it's a fixed sized array |
| 19:33.16 | blast007 | do you have a backtrace from your debugger? |
| 19:33.43 | sigonasr2 | No. The only way I know how to debug, is through bzfs debug messages. |
| 19:33.51 | blast007 | that's not really debugging |
| 19:33.56 | blast007 | what OS are you working with? |
| 19:34.08 | sigonasr2 | Ubuntu |
| 19:34.12 | blast007 | okay, then learn to use gdb |
| 19:34.31 | blast007 | and make sure you build bzfs in debug mode (passing --enable-debug to configure) |
| 19:35.10 | blast007 | and then essentially you just have to do 'gdb /path/to/your/bzfs' |
| 19:35.46 | blast007 | and then 'run -conf blah' (or whatever config you need), then you make it crash, and it will pick up the segfault in gdb |
| 19:36.19 | blast007 | and then you can do 'bt' to get a backtrace, as well as use the 'print' command followed by a variable to print out the value (iirc) |
| 19:36.41 | blast007 | scared him off, I guess |
| 19:37.06 | *** join/#bzflag sigonasr2 (~sigonasr2@ip68-0-162-159.tc.ph.cox.net) |
| 19:37.35 | sigonasr2 | Alright, sounds good. Thanks for the help. I'll try it out and come back if I still cannot figure it out. I'm learning... |
| 19:37.35 | blast007 | did you lose all of what I said? |
| 19:37.40 | sigonasr2 | Nah, got it. |
| 19:37.42 | blast007 | okay |
| 19:38.30 | blast007 | you can also set breakpoints and step through the code, but I haven't really done a whole lot of that in gdb |
| 19:39.40 | sigonasr2 | So, for the lines where I have used 'bz_getPlayerByIndex(playerID)->callsign.c_str()' should I check for a null like you suggested, even if it has not brought up any obvious problems? |
| 19:41.27 | blast007 | you should have the result being assigned to a variable |
| 19:41.38 | blast007 | don't do bz_getPlayerByIndex(playerID)->anything at all |
| 19:42.08 | blast007 | do somevariable = bz_getPlayerByIndex(playerID), THEN do a null check on somevariable, and do stuff only when you're sure it's not null |
| 19:42.30 | blast007 | that's also easier to debug, since you can 'print somevariable' at a breakpoint and see for yourself |
| 19:42.51 | sigonasr2 | Alright, sounds good. |
| 19:43.00 | blast007 | and you'll have less code ;) |
| 20:07.00 | JeffM | many of the events that use players in 2.3 automatlcy return a player record in the event to make it simpler |
| 20:07.10 | JeffM | if there are others that could use them let me know so we can add them |
| 20:11.10 | trepan | in a lot of case, it's also easier to wrap bz_getPlayerByIndex in a C++ class that will delete the pointer when it goes out of scope |
| 20:11.47 | trepan | you'll still need a isValid() method or something to check if the returned pointer was NULL |
| 20:12.32 | JeffM | if you do that then it won't work on windows |
| 20:12.40 | JeffM | the plugin can't delete the memory allocated by bzfs |
| 20:13.09 | trepan | bz_freePlayerRecord() can't be used on windows? |
| 20:30.54 | JeffM | ahh I see |
| 20:30.58 | JeffM | yes that would work |
| 20:31.01 | JeffM | I misunderstood |
| 20:31.51 | JeffM | probably should see about putting a class like that in the header or plugin-utils |
| 20:32.31 | JeffM | bzSmartPointer :) |
| 20:33.25 | trepan | another good candidate are the player lists |
| 20:33.38 | JeffM | yeah I'm not happy with those |
| 20:33.54 | JeffM | pondered a function that woudl take a functor and apply it to every player in the list |
| 20:34.01 | JeffM | would make a lot of common tasks simple |
| 20:36.02 | trepan | could set it up iterator style: for (BzIntList::iterator it = BzPlayerList.begin(); it != BzPlayerList.end(); ++it) { int team = it->getTeam(); } |
| 20:36.10 | trepan | would then work with 'foreach' setups |
| 20:36.19 | JeffM | yeah |
| 20:36.25 | trepan | tends to use foreach setups, much cleaner to look at :) |
| 20:36.44 | trepan | foreach (it, BzPlayerList) { ... } |
| 20:37.50 | JeffM | foreach is part of C++? |
| 20:38.10 | JeffM | I thought it was a QT and C++CLI extension |
| 20:38.13 | trepan | not yet, although c++0x has better support for it |
| 20:38.23 | trepan | and Boost has a decent implementation |
| 20:38.36 | trepan | tends to use his own version, but it doesn't support arrays |
| 20:39.27 | trepan | foreach, foreach_const, foreach_reverse, foreach_const_reverse, and foreach_safe (pattern allows for erase it's) |
| 20:39.35 | trepan | *erasing |
| 20:39.36 | JeffM | fun |
| 20:40.23 | trepan | don't know about 'fun', but it works |
| 20:41.57 | BulletCatcher | Is ::strncpy() just the C++ library implementation of the C library's strncpy() ? |
| 20:42.34 | Erroneous | :: just says "in the root namespace" |
| 20:42.47 | JeffM | where the C stuff lives |
| 20:43.03 | Erroneous | so ::strncpy and strncpy are the same, if you have no using statements and are not in a namespace |
| 20:43.38 | trepan | and no clashing class members |
| 20:43.50 | BulletCatcher | Okay. Player.cxx has a couple of instances of ::strncpy(). I will change them to just strncpy() for consistency with the rest of the code. |
| 20:44.09 | JeffM | probably just someone's habit |
| 21:02.31 | BulletCatcher | I have implemented the requirement for TALK permission to have one's motto broadcast. |
| 21:02.35 | BulletCatcher | The over-the-wire protocol has not changed, but only an updated client will hide its own motto when necessary. |
| 21:02.36 | BulletCatcher | Is this sufficient reason to increment BZ_PROTO_VERSION, et al.?. |
| 21:03.16 | JeffM | who decides to show the motto the server or the client? |
| 21:03.42 | BulletCatcher | The server decides. Updated clients respect what the server says. |
| 21:03.53 | JeffM | how does it hide it? |
| 21:04.08 | JeffM | does the server just set it to blank on the message that is sent out to everyone? |
| 21:04.16 | BulletCatcher | Yup. |
| 21:04.30 | BulletCatcher | It is that simple. |
| 21:04.32 | JeffM | then why does it need an updated client? |
| 21:04.48 | JeffM | for your own motto? |
| 21:04.51 | BulletCatcher | Yes. |
| 21:05.11 | JeffM | are we sure that authentication is complete at the time we send out the message to the other players? |
| 21:06.07 | BulletCatcher | It seems so. Global permissions are already available. |
| 21:06.14 | JeffM | cool |
| 21:06.38 | JeffM | then techincaly you can probably get away with out a proto update, but I'd do one anyway just so everyone has the same behavor |
| 21:06.47 | JeffM | numbers is cheap |
| 21:06.51 | BulletCatcher | That's what I had in mind. |
| 21:07.30 | BulletCatcher | I have implemented a new setMotto() method for the server. |
| 21:07.31 | BulletCatcher | This hook can be used in the future for arbitrary motto adjustments. |
| 21:07.33 | JeffM | I don't think that anyone minds of extra bumps to be safe, its' when you don't and it is needed is when we have a problem. |
| 21:07.53 | JeffM | will clients update to that if they are already joined? |
| 21:08.20 | BulletCatcher | Not at this time. It only works for newly joining clients. |
| 21:08.51 | BulletCatcher | We'll need an over-the-wire protocol change (probably a new message) for on-the-fly motto changes. |
| 21:09.09 | JeffM | k |
| 21:09.47 | JeffM | may be nice to have an API event that lets a plugin set the moto before its' sent |
| 21:10.06 | JeffM | then leauge servers could use it to set the official team name from a db or something |
| 21:10.28 | BulletCatcher | That should be easy to add when the time comes. |
| 21:10.55 | JeffM | I'll add it later tonight, be prepared and all that ;) |
| 21:11.01 | BulletCatcher | :-p |
| 21:11.11 | BulletCatcher | Stay tuned for 2.3.12. |
| 21:11.33 | JeffM | I'd rather them have the tools and see what awesome things they do with it rather then wait for them to ask for features :) |
| 21:16.32 | CIA-95 | BZFlag: 03bullet_catcher * r21801 10/trunk/bzflag/ (8 files in 6 dirs): |
| 21:16.32 | CIA-95 | BZFlag: Require TALK privilege for player motto to be broadcast. |
| 21:16.32 | CIA-95 | BZFlag: Add new setMotto() methods to Player and PlayerInfo classes. |
| 21:20.04 | CIA-95 | BZFlag: 03bullet_catcher * r21802 10/trunk/bzflag/ChangeLog: Add entry to ChangeLog for TALK privilege vs. motto. |
| 21:46.58 | BulletCatcher | The (presumably unnecessary) use of ::function() is much more widespread than I thought. |
| 21:47.00 | BulletCatcher | Cleaning that up can wait until after 2.4 is released. |
| 21:48.37 | BulletCatcher | I don't want to let 2.3 get bogged down in cosmetic code changes. |
| 21:54.27 | *** join/#bzflag Pimpi (~frank@gondolin.pimpi.org) |
| 22:07.18 | trepan | BulletCatcher: i count 213 in 3.0 |
| 22:08.17 | trepan | (some of them are necessary, ex: the ::tostring() calls in vectors.h) |
| 22:08.54 | *** part/#bzflag kierra_away (~jolie@unaffiliated/kierra) |
| 22:10.13 | trepan | which for some odd reason reminds, I might replace std::string/TextUtils with xstr's |
| 22:10.48 | trepan | (don't have to prepend with std:: to make everyone happy, and much cleaner to look at) |
| 22:28.55 | BulletCatcher | If we press on with 2.5 after 2.4 is done I assume we will want to do some of the refactoring and style changes that 2.99 already has. |
| 22:28.58 | BulletCatcher | But this isn't the time to be making that kind of decision. |
| 22:44.54 | *** join/#bzflag bryjen (~bryjen@76.92.85.169) |
| 22:44.54 | *** mode/#bzflag [+v bryjen] by ChanServ |