| 00:00.01 | spldart | Not much else causes that. No? |
| 00:00.08 | Constitution | then there shouldn't be texture flashes |
| 00:00.15 | lol_udied | fine I:ll check |
| 00:00.22 | lol_udied | again |
| 00:01.35 | lol_udied | theres only 2 boxes inside rotated for design only |
| 00:01.40 | lol_udied | are those boxs affecting it |
| 00:01.41 | lol_udied | ? |
| 00:01.57 | CBG | Remove them. |
| 00:02.01 | lol_udied | ok |
| 00:02.02 | CBG | See if it will work then. |
| 00:02.10 | spldart | comment out maybe |
| 00:02.33 | CBG | Well, he has them save din pastebin. ;) |
| 00:02.46 | spldart | You are right sir. |
| 00:03.10 | lol_udied | even the pyramids on top? |
| 00:03.16 | CBG | Indeed I am, as are you, Professor. |
| 00:03.16 | lol_udied | of the box? |
| 00:03.25 | spldart | Pardon my pleasant nature. I have a beer in front of me and pizza on order ;) |
| 00:03.51 | CBG | That is jolly good news indeed, old chap. |
| 00:03.59 | Constitution | lol_udied: no, just the box(es) |
| 00:04.08 | lol_udied | ok done |
| 00:04.11 | lol_udied | now what |
| 00:04.14 | lol_udied | blast isnt here |
| 00:04.16 | spldart | run it and test? |
| 00:04.24 | CBG | Test it locally. |
| 00:04.33 | lol_udied | kk hold on. switching to PC |
| 00:04.37 | CBG | There are instructions all over the forum, wiki, man pages... |
| 00:04.38 | Constitution | ? |
| 00:04.41 | spldart | I'm sure blast will be back some time or other |
| 00:04.58 | spldart | things happen in the channel on their own schedule.. It's not like #linux or something. |
| 00:10.17 | JeffM | things happen? |
| 00:10.34 | CBG | Nothing productive. Ever. |
| 00:11.20 | *** join/#bzflag nn64 (n=nn@74.94.43.196) |
| 00:12.03 | spldart | Doh! |
| 00:12.22 | Constitution | lol_udied: when the meshbox with the phydrv is commented out, there's still a box there... so you have two overlapping ones. |
| 00:12.47 | spldart | He's got a standard and a mesh overlapping... makes sense |
| 00:12.48 | Constitution | but I'm guessing iBZEdit can't read meshboxes or meshboxes with physics drivers or something, so it only displays the box |
| 00:13.47 | CBG | ~Constitution++ |
| 00:13.51 | lol_udied | so should I take out the standard? |
| 00:13.57 | CBG | Yes. |
| 00:13.58 | lol_udied | it didnt work by theway |
| 00:14.00 | lol_udied | ok |
| 00:15.10 | spldart | Agreed... |
| 00:15.11 | spldart | ~Constitution++ |
| 00:15.23 | *** join/#bzflag nn64 (n=nn@74.94.43.196) |
| 00:16.25 | Constitution | ~Constitution++ |
| 00:16.28 | Constitution | oh |
| 00:16.58 | CBG | :D |
| 00:18.25 | lol_udied | back |
| 00:18.28 | lol_udied | nope doesnt work |
| 00:18.39 | lol_udied | I even took EVERYTHING away from the middle still no meshbox |
| 00:19.42 | Constitution | you take everything out and THEN put your meshbox in |
| 00:20.10 | lol_udied | wait...... So I have to put the meshbox in THEN i put the physics? |
| 00:20.33 | lol_udied | God im stupid |
| 00:20.47 | spldart | You have tried just running a map with nothing but the one meshbox and one defined phys? |
| 00:20.52 | CBG | No. |
| 00:20.59 | CBG | GO back to the version you pasted in pastebin. |
| 00:21.00 | lol_udied | I didnt even make a meshbox |
| 00:21.12 | CBG | Then remove two boxes. One of them is: BZBox_38 |
| 00:21.18 | Constitution | then that is your problem |
| 00:21.33 | spldart | heh |
| 00:21.38 | lol_udied | darn. so I need to go to wings 3D or something and make a meshbox? |
| 00:21.46 | CBG | The other object to remove is BZPyramid_5_Copy_Copy_Copy_Copy |
| 00:22.04 | Constitution | the meshbox is the code you added at the end |
| 00:22.05 | CBG | No. Is this thing on?! |
| 00:22.06 | spldart | argblech.... meshbox will take a phydrv... |
| 00:22.09 | spldart | I've done it |
| 00:22.17 | CBG | Do you want us to do it for you? |
| 00:22.26 | spldart | meshbox isn't the best way to do things though sometimes... up to you |
| 00:22.26 | lol_udied | If you want. |
| 00:22.28 | Constitution | cause we won't ;) |
| 00:22.34 | spldart | w0rd |
| 00:22.38 | Constitution | I just did it and it worked |
| 00:22.46 | CBG | We don't want to, no. |
| 00:23.00 | lol_udied | So what do I do xD |
| 00:23.12 | JeffM | science! |
| 00:23.23 | lol_udied | lol |
| 00:23.29 | spldart | ...blinded him |
| 00:23.35 | CBG | Go back to the version you pasted in pastebin. Then remove two objects: BZBox_38 and BZPyramid_5_Copy_Copy_Copy_Copy. |
| 00:23.48 | lol_udied | I did |
| 00:23.58 | CBG | There you go then. |
| 00:24.03 | CBG | Run and Test. |
| 00:24.07 | lol_udied | I did |
| 00:24.08 | lol_udied | and nothing |
| 00:24.21 | CBG | Nothing what? |
| 00:24.25 | lol_udied | I think my computers are just mentaly retarded |
| 00:24.34 | spldart | I know I'm getting a headache |
| 00:24.52 | Constitution | lol_udied: if you removed them, there should be nothing there... very good |
| 00:24.52 | CBG | Usually, PEBKC. |
| 00:25.05 | Constitution | now uncomment your meshbox at the end of the file |
| 00:25.11 | CBG | The meshboxes should be there if he is working on the correct version of code. |
| 00:27.28 | lol_udied | Im going to paste bin my new bzw file |
| 00:28.16 | lol_udied | http://pastebin.com/f6388453c |
| 00:29.17 | CBG | Where did the meshboxes and physics go? |
| 00:29.25 | lol_udied | ??? |
| 00:29.28 | lol_udied | hold on |
| 00:29.34 | spldart | hehe |
| 00:30.54 | *** join/#bzflag bryjen (n=bryjen@CPE-76-182-130-120.natwky.res.rr.com) |
| 00:30.54 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 00:31.22 | lol_udied | ok gonna test again |
| 00:37.06 | lol_udied | IT WORKED! |
| 00:37.30 | CBG | So... wait. Let me make sure I understand this... |
| 00:37.37 | CBG | When yo did what we said.... it worked?!?! |
| 00:37.43 | CBG | Amazing. |
| 00:37.45 | lol_udied | heh |
| 00:37.46 | lol_udied | Now just to finalize everything. Why didnt it work at first? |
| 00:37.54 | lol_udied | So i:ll know next time |
| 00:37.54 | CBG | Maybe people should listen to us more often?! |
| 00:38.14 | CBG | You had objects doubled up. |
| 00:38.37 | lol_udied | So when I have physics like that. Nothing should touch the meshbox right? |
| 00:38.41 | CBG | Where you had the mesh objects with physics, you had old style objects too. |
| 00:38.44 | CBG | Right... |
| 00:39.00 | CBG | I suspect if the duplicates had been mesh objects too, it would have been ok. |
| 00:39.08 | lol_udied | So not even pyramids can touch them? |
| 00:39.24 | CBG | Well, touching is ok. |
| 00:39.33 | CBG | BUt full intercourse is not. |
| 00:39.59 | lol_udied | lol |
| 00:40.16 | lol_udied | but no seriously |
| 00:40.58 | CBG | When you have two objects he same size in the same place, strange things happen. |
| 00:41.02 | CBG | So, don't so that. |
| 00:41.09 | lol_udied | ok |
| 00:41.14 | lol_udied | Thanks for your help guys |
| 00:41.17 | lol_udied | later |
| 00:41.20 | CBG | No problem. |
| 00:41.25 | CBG | Come again. |
| 00:45.54 | lol_udied | Wow. I just remembered today is my birthdat |
| 00:45.55 | lol_udied | day |
| 00:46.11 | CBG | OH well, nevermind. |
| 00:46.16 | lol_udied | lol |
| 00:46.18 | lol_udied | rofl |
| 00:46.20 | CBG | It's not quite the end of the world, lol_udied. |
| 00:46.33 | CBG | That's not due until Wednesday. |
| 00:46.43 | lol_udied | ? |
| 00:46.53 | CBG | ... The end of the world... |
| 00:48.02 | CBG | Those crazy Swiss... Particle Accelerator? Whatever next!? |
| 00:48.21 | JeffM | KingofCamelot, commit your stuff to trunk! |
| 00:48.22 | JeffM | now |
| 00:48.50 | CBG | Yeah, don't you dare say "In a week.". That'll be too late! |
| 00:54.57 | *** join/#bzflag Admirarch (n=Athelthr@87.115.8.255) |
| 01:01.13 | KingofCamelot | JeffM, ping |
| 01:02.44 | JeffM | KingofCamelot, commit it :) |
| 01:03.17 | KingofCamelot | Sorry, been off visiting family for the last week, so I haven't been around. So commit the branch to trunk? |
| 01:03.26 | JeffM | yes |
| 01:03.26 | KingofCamelot | Do I need to do a merge first? Not really sure of the process |
| 01:03.39 | JeffM | yeah merge trunk inrto your stuff |
| 01:03.45 | JeffM | Erroneous, will be GLAD to help you :) |
| 01:03.47 | Flash | CBG: find / -name 'bzw*' -exec rm -rf {} \; |
| 01:03.51 | Erroneous | merge trunk to your branch, then your branch to trunk |
| 01:03.55 | Flash | (sorry it's an hour late) |
| 01:04.12 | *** join/#bzflag trepan (n=trepan@unaffiliated/trepan) |
| 01:04.12 | *** mode/#bzflag [+v trepan] by ChanServ |
| 01:04.16 | KingofCamelot | Ok, let's see if I remember how to do a merge. :P |
| 01:04.22 | Erroneous | you shouldn't have the same problems as last time, I figured out what caused those |
| 01:04.29 | KingofCamelot | What caused them? |
| 01:04.37 | JeffM | Science! |
| 01:04.47 | Erroneous | people changed some file modes without changing the contents, and svn barfed on them when trying to merge |
| 01:04.57 | KingofCamelot | Ah |
| 01:05.12 | Erroneous | and I don't think anyone's done that since |
| 01:05.39 | KingofCamelot | Ok, for merging trunk to my branch, which one goes in the from, and which one in the to? That always trips me up :P |
| 01:05.53 | Erroneous | so...first step is to merge trunk, from the last time you merged, to trunk, from today, into your branch, then commit it |
| 01:06.14 | Erroneous | from trunk as of rxxx (last time you merged) to trunk head |
| 01:06.20 | KingofCamelot | Ok, so from is the last time I merged, to is head revision |
| 01:06.29 | Erroneous | yeah |
| 01:06.47 | Erroneous | so that'll take the differences between your last merge and current head, and apply them to your working directory |
| 01:07.12 | Erroneous | then you commit that, and the only differences between your branch and trunk should be your changes |
| 01:08.01 | KingofCamelot | Ok, and so then the merge into truck will apply my changes to the working copy of trunk, and then I commit that |
| 01:08.28 | Erroneous | right...after that you'll do from your branch to trunk head, into a working copy of trunk |
| 01:08.40 | Erroneous | so you'll need to check out trunk if you haven't already |
| 01:11.22 | Flash | JeffM: I finally figured out the structures I'm concerned about are for server-side players, so I'm not going to bother with making classes like the event stuff |
| 01:11.40 | Flash | especially since server-side players are documented not to work |
| 01:11.55 | JeffM | ahh yeah |
| 01:11.58 | JeffM | they do |
| 01:11.58 | JeffM | ish |
| 01:11.59 | JeffM | ;) |
| 01:12.20 | Flash | point being, I'm not worried about potentially breaking a plugin |
| 01:12.28 | JeffM | but yeah, that's all in it's own class, and that itself will be versioned |
| 01:12.35 | JeffM | oh yeah never worry about breaking a plugin for trunk |
| 01:12.42 | JeffM | not untill we release 3.0 |
| 01:12.56 | JeffM | there are no 3rd party plugins for trunk |
| 01:16.16 | Erroneous | if you break plugins that we build, you need to fix them. don't worry about anything that we don't build though |
| 01:16.26 | CIA-49 | BZFlag: 03kingofcamelot * r18509 10/branches/gsoc_server_listing/ (51 files in 19 dirs): Merged branch with trunk revision 18508 |
| 01:16.44 | Flash | I would NEVER break anything ;-) |
| 01:17.11 | Erroneous | hah |
| 01:17.29 | Erroneous | breaks things all the time :) |
| 01:18.53 | delusional | >gates is <reply> WHY DOES BILL GATES WIGGLE HIS ASS? |
| 01:19.02 | delusional | woop wrong window |
| 01:19.08 | delusional | sorry |
| 01:19.09 | Flash | ~lart delusional |
| 01:19.09 | ibot | overclocks delusional until delusional burns out |
| 01:19.25 | delusional | http://gizmodo.com/5045703/the-first-bill-gates-%252B-jerry-seinfeld-microsoft-ad-makes-no-sense |
| 01:20.12 | KingofCamelot | Yea...that ad makes no sense |
| 01:21.47 | Flash | wishes for that 90seconds of his life back |
| 01:22.11 | KingofCamelot | long commercial too |
| 01:23.04 | Erroneous | woot, bzflag clean build in 1:54 |
| 01:25.05 | JeffM | if I Had a tree I'd try it |
| 01:25.27 | Erroneous | that was the server list branch too |
| 01:29.19 | KingofCamelot | Hmm, this merge into trunk is taking forever |
| 01:31.02 | *** join/#bzflag Quol (n=ian@modemcable163.24-131-66.mc.videotron.ca) |
| 01:31.16 | Erroneous | sf seems to be slow today |
| 01:35.42 | spldart | SF is often slow |
| 01:35.59 | spldart | back from pizza with the kids |
| 01:45.05 | *** join/#bzflag Shazzamy (n=evies980@unaffiliated/shazzamy) |
| 01:45.07 | Shazzamy | hey |
| 01:45.44 | spldart | Is for horses. |
| 01:46.13 | spldart | Have a query? |
| 01:47.08 | Shazzamy | http://www.ihateyoujulia.com/?id=98ffbd569d5dbc5acad93375b260499d |
| 01:47.09 | Shazzamy | idk |
| 01:47.32 | spldart | ban |
| 01:48.39 | *** part/#bzflag Shazzamy (n=evies980@unaffiliated/shazzamy) |
| 01:55.39 | *** mode/#bzflag [+o spldart] by ChanServ |
| 01:59.06 | Flash | pull the trigger |
| 01:59.28 | spldart | Was just waiting cocked and locked. |
| 02:00.32 | Flash | what are you waiting for? |
| 02:09.41 | spldart | Hope I got this right |
| 02:09.44 | *** mode/#bzflag [+b #channel!*@*] by spldart |
| 02:09.51 | Flash | ducks |
| 02:09.55 | *** mode/#bzflag [+b #bzflag!*@*] by spldart |
| 02:10.03 | spldart | grr |
| 02:10.09 | spldart | banlist |
| 02:10.31 | spldart | nope |
| 02:10.42 | spldart | didn't work.. I'm to used to using the auto script in xchat |
| 02:11.01 | *** mode/#bzflag [-bb #bzflag!*@* *!*n=evies9*@unaffiliated] by spldart |
| 02:11.09 | *** mode/#bzflag [-bb #channel!*@* *!*n=evies9*@unaffiliated] by spldart |
| 02:11.40 | *** mode/#bzflag [+b *!*n=evies9*@unaffiliated] by spldart |
| 02:12.26 | Flash | the @unafilliated part is a cloak |
| 02:12.58 | Flash | I'd try "*@unaffiliated/shazzamy" for a start |
| 02:13.40 | *** mode/#bzflag [+b *!*@unaffiliated/shazzamy] by spldart |
| 02:13.45 | spldart | Like that? |
| 02:13.52 | *** mode/#bzflag [-b *!*n=evies9*@unaffiliated] by spldart |
| 02:14.22 | *** join/#bzflag Abominable_ (n=chatzill@user-0ce2hv1.cable.mindspring.com) |
| 02:15.17 | spldart | Meh.. Hose it. I'll just go for the kick if he shows again heh. |
| 02:16.44 | Flash | looks fine |
| 02:16.52 | Flash | but what do I know? |
| 02:18.32 | spldart | More than I about IRC prolly... And writing code definitely. I'm only experience admin'ing BBs. not channels |
| 02:18.57 | Flash | code writing I'll accept. for IRC, I'm a noob |
| 02:19.30 | spldart | I've been on irc for years.. but the voiced stuff is new to me... |
| 02:27.02 | Flash | who knows anything about webstats plugin (trunk)? |
| 02:27.16 | Flash | I'm trying to figure out where the keyCallback is called |
| 02:27.35 | Flash | so I can figure out how the key value is assigned |
| 02:29.02 | spldart | For fear of the ping... IC the one who re-introduced me to IRC well over 3 years ago near the bottom of the list here ;) |
| 02:29.26 | spldart | Sry. delay messages.. watching the new episode of SGA |
| 02:29.33 | Flash | SGA? |
| 02:29.36 | Flash | oh |
| 02:29.42 | spldart | Atlantis ;) |
| 02:29.45 | Flash | I'm like 3 seasons behind, so I gave up |
| 02:29.58 | spldart | Ah.. sga has been pretty good imho |
| 02:30.35 | Flash | I lost the bubble right about the time the Wraith were about to attack |
| 02:30.42 | Flash | (end of some season) |
| 02:32.01 | spldart | ah |
| 02:40.48 | *** mode/#bzflag [-o spldart] by ChanServ |
| 02:49.55 | CIA-49 | BZFlag: 03jwmelto * r18510 10/trunk/bzflag/ (4 files in 3 dirs): |
| 02:49.55 | CIA-49 | BZFlag: Add rank to API player record. |
| 02:49.55 | CIA-49 | BZFlag: Change packetloss to packetLoss to be consistent |
| 02:49.55 | CIA-49 | BZFlag: Add rank to webstats plugin |
| 02:55.46 | jorgenpt | spldart: SGA > SG:1, or |
| 02:55.59 | jorgenpt | I'm watching SG1 atm, season 3 |
| 02:56.21 | jorgenpt | Do they officially "spin off" at some point during SG1? |
| 02:56.45 | Flash | yes |
| 02:56.51 | jorgenpt | When's that? |
| 02:57.07 | Flash | after the big attack on earth, they have the pre-pilot for SGA |
| 02:57.21 | Flash | O'Neil brings Sheppard in explicitly |
| 02:57.36 | jorgenpt | Season? |
| 02:57.42 | Flash | no clue |
| 02:59.02 | jorgenpt | k |
| 03:00.02 | spldart | I slightly prefer SG1 |
| 03:00.17 | spldart | and I've watched every episode avail on both sg1 and sga |
| 03:01.42 | *** join/#bzflag ViciousM (n=max@cpe-066-026-094-182.nc.res.rr.com) |
| 03:01.55 | spldart | In fact I'm rewatching all sg1 this and next week |
| 03:03.37 | spldart | Wait! which episode in Season 3 jorgenpt? |
| 03:03.56 | jorgenpt | Watching 20 atm |
| 03:04.43 | spldart | I'm on episode 11 of S3. I'm watching at work. |
| 03:04.54 | jorgenpt | Nice ;) |
| 03:05.16 | spldart | Nice.. use of the work pc |
| 03:05.59 | *** join/#bzflag BenUrban (n=benurban@c-68-49-10-243.hsd1.md.comcast.net) |
| 03:06.07 | spldart | ;).... |
| 03:08.14 | *** join/#bzflag ViciousM (n=max@cpe-066-026-094-182.nc.res.rr.com) |
| 03:08.21 | jorgenpt | :p |
| 03:10.25 | Flash | season 7 |
| 03:10.36 | Flash | http://en.wikipedia.org/wiki/Stargate_Atlantis |
| 03:11.14 | spldart | bookmarks |
| 03:18.08 | *** join/#bzflag QBeep (n=QB@cpe-72-190-32-30.tx.res.rr.com) |
| 03:34.06 | *** join/#bzflag Legoguy_ (n=Legoguy@adsl-71-143-230-94.dsl.emhril.sbcglobal.net) |
| 03:41.57 | Constitution | any forum admins in a good mood tonight? :) |
| 03:42.14 | Flash | spldart is always in a good mood |
| 03:42.27 | Constitution | *forum admins* |
| 03:42.39 | Flash | memory failure |
| 03:42.46 | Flash | who are the forum admins? |
| 03:43.18 | Constitution | JeffM DTRemenak|RDP brlcad menotume L4m3r donny_baker blast007 uuuhhhh... |
| 03:43.26 | Constitution | okay sorry guys :P |
| 03:50.02 | *** join/#bzflag Constitution (n=const@gateway.pct.civiltec.com) |
| 03:50.40 | *** join/#bzflag a_meteorite (n=a_meteor@adsl-75-15-139-207.dsl.snlo01.sbcglobal.net) |
| 03:50.56 | *** join/#bzflag JeffM (n=Jeff@unaffiliated/jeffm) |
| 03:55.08 | Constitution | hi JeffM |
| 03:58.50 | JeffM | hi |
| 03:59.03 | Flash | I may be reading it wrong, but I think the bad flag "shaking" logic is screwed up |
| 03:59.30 | Flash | it looks like it just happens to work because no one ever sets a number of wins to shake the flag > 1 |
| 03:59.55 | Flash | the good news is that I'm not going to make it any worse... |
| 04:00.16 | Flash | LocalPlayer.cxx:changeScore() for those playing at home |
| 04:01.36 | spldart | heh... was away... now goin sleepers. Yeah.. I'm NOT a bzbb admin :)... I did termpro and sounddomain for a while. Even some Phoenixgold forum work. but not bzbb. |
| 04:03.29 | Constitution | JeffM: may I have my old bzbb rank back? |
| 04:03.49 | Constitution | when you have a moment |
| 04:05.08 | *** join/#bzflag noyb (n=noyb@pool-71-108-97-231.lsanca.dsl-w.verizon.net) |
| 04:34.49 | *** join/#bzflag QuantumBeep (n=QB@cpe-72-190-32-30.tx.res.rr.com) |
| 04:35.49 | JeffM | Constitution: what was it |
| 04:38.24 | Constitution | JeffM: Dev Monkey |
| 04:42.30 | CIA-49 | BZFlag: 03jwmelto * r18511 10/trunk/bzflag/ (11 files in 7 dirs): |
| 04:42.30 | CIA-49 | BZFlag: PROTOCOL CHANGE |
| 04:42.30 | CIA-49 | BZFlag: Include the player's ranking (sometimes used to annoint rabbit) in scores. |
| 04:42.30 | CIA-49 | BZFlag: Remove local calculation of rank |
| 04:43.09 | Constitution | ~Flash++ |
| 04:43.19 | CIA-49 | BZFlag: 03jwmelto * r18512 10/trunk/bzflag/src/bzflag/Player.cxx: meant to include this comment |
| 04:43.36 | Flash | I don't know why I had such a hard time the first time I tried to do that, but it went pretty cleanly this time |
| 04:44.04 | Flash | thinks that assessment might need to wait until others enjoy the change |
| 04:46.33 | JeffM | did you bump the minor too? |
| 04:46.47 | JeffM | the rev I mean |
| 04:48.09 | BulletCatcher | He did. Welcome to 2.99.6. |
| 04:49.17 | JeffM | k |
| 04:49.33 | Flash | I even got your windows .nsi file |
| 04:57.00 | CIA-49 | BZFlag: 03jwmelto * r18513 10/branches/v2_99_net_branch/ (5 files in 3 dirs): stub client side support in NetHandler |
| 05:08.49 | BulletCatcher | ~Flash++ |
| 05:08.51 | BulletCatcher | No obvious new problems with r18512 beyond a couple of "converting to 'uint16_t' from 'double'" warnings in Score.cxx . |
| 05:10.06 | Flash | in pack()? |
| 05:10.29 | BulletCatcher | Yes. Lines 69 & 78. |
| 05:10.48 | Flash | those shouldn't be warnings.... oh well |
| 05:12.55 | Flash | I don't get the warnings... what compiler are you using? |
| 05:13.11 | BulletCatcher | gcc 4.1.2 |
| 05:14.51 | JeffM | why are you going from int to double? |
| 05:14.52 | Flash | do you always get signed->unsigned conversions? |
| 05:14.59 | Flash | no, double to int |
| 05:15.00 | JeffM | yeah why are you doing that? |
| 05:15.03 | JeffM | why? |
| 05:15.26 | Flash | because sending the rank 0-100 was easier than sending the rank 0-1 |
| 05:15.38 | JeffM | then store it as a double |
| 05:16.03 | Flash | it is; it's converted to uint16_t to go on the wire |
| 05:16.17 | JeffM | why not send it as a double then? |
| 05:16.40 | Flash | I suppose I could, just didn't seem necessary |
| 05:16.51 | Flash | it's only used to display 0-100% |
| 05:17.01 | JeffM | then don't store it as a double |
| 05:17.04 | JeffM | they should match |
| 05:17.12 | JeffM | otherwise it's harder to debug |
| 05:17.30 | BulletCatcher | This line is warning-free: uint16_t rank = (uint16_t)( ranking() * 100 + 0.5 ); |
| 05:17.36 | Flash | on the server side, it's a 0-1 computation; there may be value in the extra precision |
| 05:17.40 | JeffM | BulletCatcher: yeah but ugly as hell |
| 05:17.48 | JeffM | Flash: then send it as a double |
| 05:17.50 | JeffM | keep it the same |
| 05:17.56 | Flash | BulletCatcher: you can eliminate most warnings with a C-style cast |
| 05:18.08 | JeffM | tho I can't think that you'd NEED the friggin rank to be a doulb |
| 05:18.12 | JeffM | float is probably fine |
| 05:18.17 | JeffM | store and send as a float |
| 05:18.18 | Flash | ok, do you want me to bump the protocol again? |
| 05:18.20 | JeffM | yeah |
| 05:18.23 | JeffM | numbers are cheap |
| 05:19.00 | BulletCatcher | (It actually is a float, not a double.) |
| 05:19.05 | JeffM | every time you have to cast, you have to question it. many times it means you do something wrong |
| 05:19.11 | JeffM | ok good |
| 05:19.15 | JeffM | yeah send it as a float |
| 05:19.28 | JeffM | saving 2 bytes in a score update is pointless |
| 05:30.09 | BulletCatcher | Another option would be to use lrintf() to explicitly convert the float to an integer in a C99-compliant manner. |
| 05:30.31 | JeffM | no keep it as a float |
| 05:30.35 | JeffM | loosing data is bad |
| 05:30.40 | JeffM | the rank is used for a sort basicly |
| 05:30.47 | JeffM | so having more granularity in the sort is good |
| 05:30.57 | JeffM | we could use to to do any kind of sort we wanted on the client, etc.. |
| 05:31.49 | JeffM | there is no need to save data in this case, so for ease of readablity keep it a float |
| 05:31.58 | JeffM | unless it dosn't need to be a float, then change it everywhere |
| 05:38.52 | Flash | BulletCatcher: will your compiler warn on this: return short(rank*100 + 0.5); |
| 05:39.10 | JeffM | is that for packing? |
| 05:39.23 | Flash | no, the client uses a short to display |
| 05:39.28 | JeffM | why? |
| 05:39.32 | Flash | I don't know |
| 05:39.36 | JeffM | make it use a float |
| 05:39.59 | Flash | you still want to display "50%" not "50.0%" |
| 05:39.59 | JeffM | if you are going to do it right, do it right ;) |
| 05:40.05 | JeffM | then format it |
| 05:40.33 | Flash | it already did: format("%d%%", getRabbitScore() ); |
| 05:41.02 | JeffM | and that does it as 50.0? |
| 05:41.13 | Flash | no, but getRabbitScore() returns a short |
| 05:41.20 | JeffM | then make it reuturn a float |
| 05:41.33 | JeffM | so it can be 50.5% |
| 05:41.57 | Flash | there isn't space for that.... you like to make requirements creep, don't you :-| |
| 05:42.10 | JeffM | no I like to make code clean |
| 05:42.15 | JeffM | if you are going to fix it, fix it right |
| 05:42.35 | Flash | I'm just not convinced that particular change is "right" |
| 05:42.38 | JeffM | if you don't want to do it, don't do it and someone else will do the work |
| 05:42.48 | JeffM | casting to a short just for display seems like a hack to me |
| 05:42.57 | JeffM | if you have it as a float, use it as a float all the way thru |
| 05:43.00 | JeffM | how can that not be right? |
| 05:43.11 | JeffM | if it's never used as float then keep it as a short |
| 05:43.53 | JeffM | it's just good design IMHO |
| 05:44.04 | DTRemenak|RDP | what's wrong with, say, %f2.0%%? |
| 05:44.32 | JeffM | indeed |
| 05:44.59 | Flash | surrenders |
| 05:45.00 | JeffM | it should not be that hard to make it work |
| 05:45.10 | Flash | no, I'm sure it won't be |
| 05:45.26 | JeffM | and I thought you were all about the "prety" code? ;) |
| 05:45.36 | JeffM | casting is never prety |
| 05:45.39 | Flash | I am; that didn't offend me |
| 05:45.52 | JeffM | it's soving a square peg into a round hole |
| 05:45.53 | Flash | casting is evil. conversion is often valid |
| 05:46.11 | JeffM | in this case it's only valid because you didn't want to change the format output |
| 05:46.20 | JeffM | lazyness is not valid ;) |
| 05:46.27 | Flash | :-P |
| 05:46.47 | BulletCatcher | For the record, g++ 4.1.2 seems happy with that return line in a function that is defined to return a short. |
| 05:46.57 | Flash | OBE |
| 05:47.03 | nick125 | w/i15 |
| 05:47.04 | JeffM | it better be, as that's valid, it creates a new short |
| 05:47.06 | nick125 | er |
| 05:47.36 | JeffM | I like the concept of keeping it as a float the entire way, then it gives more flex in it's use with out changin the protocoll |
| 05:47.56 | JeffM | the cool thing that you've done Flash is basicly let us totaly redo the scoring system with out any more changes to the proto.. that's great |
| 05:48.03 | JeffM | so may as well make it as flexable as possible |
| 05:48.12 | Flash | it's the same construct that was warned before... I just didn't know if it was the signed->unsigned that bothered it, or the float->int |
| 05:48.19 | nick125 | I'm having a small issue with BZFlag here on Gentoo Linux. I'm getting really horrible performance...as in, keyboard input will really lag, even in the menus. I've tried turning the graphics settings down (and I made sure I'm using the latest nvidia drivers), but it still seems to do it. Any ideas? |
| 05:48.56 | BulletCatcher | My hacking showed the warning was due to float->int, not signed->unsigned. |
| 05:49.34 | Flash | DTRemenak: is that %f2.0 or %2.0f ?? |
| 05:49.44 | DTRemenak | are you sure it's actually using the nvidia drivers? what does the chat box say during startup? |
| 05:50.04 | Flash | BulletCatcher: then I wonder why it likes the return statment and not the constructor? |
| 05:50.10 | DTRemenak | %2.0f%%, sorry |
| 05:50.24 | Flash | is short(2.0) different than short s(2.0) ?? |
| 05:50.51 | BulletCatcher | Dunno. I still do most of my thinking in C, not C++. |
| 05:51.11 | DTRemenak | yes, the first creates two unnamed temporary variables (a double and a short), the second creates one unnamed temporary variable (a double) and one named variable (a short) |
| 05:51.49 | Flash | to be pedantic, it's an unnamed temporary and a constant vs a named variable and a constant |
| 05:51.55 | DTRemenak | right |
| 05:52.01 | DTRemenak | and that's pretty pedantic :) |
| 05:52.11 | Flash | but why would one warn and the other not? |
| 05:52.32 | DTRemenak | the first does an explicit conversion, the second does an implicit conversion |
| 05:53.02 | Flash | so short(2.0) is more akin to short s(short(2.0)) ? |
| 05:53.13 | DTRemenak | yes |
| 05:53.15 | DTRemenak | short(2.0) is the same as (short)2.0, just different notation |
| 05:53.16 | Flash | got it |
| 05:53.29 | Flash | I am not 100% sure that's right |
| 05:53.46 | Flash | I think short(2.0) invokes the defined conversion whereas (short)2.0 uses the sledghammer |
| 05:54.12 | DTRemenak | could be the case in c99/c++ |
| 05:54.26 | DTRemenak | i.e. short(2.0) may be the same as static_cast<short>(2.0) in c++ |
| 05:54.52 | Flash | I just banned the use of (short)2.0 at work, so I don't think about it much |
| 05:54.55 | JeffM | I thought short() made a new short and passed the value into the constructor |
| 05:55.03 | Flash | it does |
| 05:55.19 | Flash | but actually (short)2.0 does as well |
| 05:55.30 | Flash | either way you get a new short |
| 05:55.38 | DTRemenak | it's not really an object, no constructor |
| 05:55.44 | JeffM | dynamic cast would return null then, wheren a new short that failed it's constructor would return an uniitalised short |
| 05:55.47 | JeffM | ahh |
| 05:55.49 | Flash | PODs get constructed too |
| 05:56.02 | JeffM | it's not a pod, it's a type |
| 05:56.06 | JeffM | so it may have it's own rules |
| 05:56.09 | DTRemenak | they get constructed, sure |
| 05:56.12 | DTRemenak | but they aren't objects |
| 05:56.18 | Flash | plain-old-data |
| 05:56.26 | DTRemenak | there's no vtable pointing to the ctor, for instance |
| 05:56.55 | Flash | dynamic_cast only works if there *is* a vtable |
| 05:57.04 | *** join/#bzflag L4m3r (n=l4m3r@about/essy/warning/L4m3r) |
| 05:57.04 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 05:57.04 | Flash | at least, in some implementations |
| 05:57.21 | JeffM | well keeping it as a float will not have to worry about any of those problems :) |
| 05:57.26 | Flash | right |
| 05:57.28 | DTRemenak | so calling something that builds PODs a constructor can be misleading by implication |
| 05:57.56 | Flash | ok... (avoiding more pedantism) |
| 05:58.00 | DTRemenak | hehe |
| 05:58.23 | BulletCatcher | nick125: run the program "glxgears" if you have it. It will give a good indication of whether your hardware acceleration is working. |
| 05:58.47 | nick125 | hmm...only getting about 1500fps |
| 05:58.58 | DTRemenak | nick125: also check the chat box on startup, see if it says "indirect" somewhere |
| 05:59.02 | BulletCatcher | That is plenty. |
| 05:59.04 | Flash | JeffM: you were right about one thing: HUDRenderer::tankScoreCompare is currently returning and int; I'll have to change it to float and you will get more sorting fidelity |
| 05:59.20 | JeffM | mmmmm granularity |
| 05:59.22 | DTRemenak | woot, hi-fi score sorting |
| 05:59.36 | DTRemenak | thinks it should go in the changelog as that |
| 05:59.37 | JeffM | BulletCatcher: we show the GL renderer at startup |
| 05:59.51 | JeffM | it'll say direct or not |
| 06:00.07 | KingofCamelot | Hmmm...so my merge of my branch into trunk didn't go quite right |
| 06:00.17 | JeffM | so fix it |
| 06:00.23 | nick125 | I've also noticed that in game, it seems that I'm having keyboard troubles as well. Basically, I'll press a key, and about two seconds later, the tank will move...and it'll keep moving for 5-10 seconds in that direction. |
| 06:00.29 | Flash | KingofCamelot: I probably hurt you |
| 06:00.30 | DTRemenak | what went not-quite-right, KingofCamelot? |
| 06:00.54 | JeffM | nick125: what does it say in the chatbox on startup for your GL renderer string? |
| 06:01.07 | DTRemenak | nick125: same problem if you use the mouse to drive, or not? |
| 06:01.23 | DTRemenak | and when you're ingame, what's your fps (press T or Y, can't remember which) |
| 06:01.23 | KingofCamelot | Not sure what went wrong. I did the merge, and in the log it says 'Skipped missing target: HUDuiTabbedControl.cxx', etc, for all my files that are new in my branch. |
| 06:01.59 | DTRemenak | you merged from trunk to your branch, in trunk's working directory? |
| 06:02.15 | DTRemenak | not in your branch's working directory? |
| 06:02.23 | KingofCamelot | I thought you said from branch to trunk? And yea, trunk's working directory |
| 06:02.26 | nick125 | DTRemenak: nope, mouse works fine |
| 06:02.32 | DTRemenak | nick125: interesting |
| 06:02.39 | DTRemenak | no keyboard lag in other apps? |
| 06:02.39 | JeffM | what is your framerate? |
| 06:03.03 | nick125 | DTRemenak: Seems fine everywhere else |
| 06:03.07 | DTRemenak | KingofCamelot: if I said that, I disagree with myself. try from trunk to branch ;) |
| 06:03.28 | KingofCamelot | :P |
| 06:03.30 | KingofCamelot | <+Erroneous> right...after that you'll do from your branch to trunk head, into a working copy of trunk |
| 06:03.45 | DTRemenak | yeah, that Erroneous guy doesn't know what he's talking about :) |
| 06:03.49 | nick125 | It's about 105fps in game |
| 06:04.04 | JeffM | wierd |
| 06:04.08 | KingofCamelot | Do I need to clean the working copy of trunk first? Since the first merge was wrong |
| 06:04.26 | DTRemenak | it should have done no changes |
| 06:04.37 | DTRemenak | if it did, revert them |
| 06:04.50 | DTRemenak | and since Flash has committed to trunk, you have two options |
| 06:05.17 | DTRemenak | you can either not update your working copy, and merge from trunk (rxxx, where xxxx is the revision you have in your working copy) to your branch |
| 06:05.24 | DTRemenak | and then update after the merge |
| 06:05.42 | DTRemenak | or you can merge his changes from trunk into your branch, and update your working copy of trunk |
| 06:05.58 | KingofCamelot | First option sounds simpler |
| 06:06.11 | DTRemenak | yeah, if you haven't blown out your working copy of trunk |
| 06:06.27 | nick125 | tries downgrading xorg-server, just for fun |
| 06:06.50 | DTRemenak | or I guess another option is, you can just do changes to head, commit (thereby reverting all of flash's changes), and then merge flash's changes back into trunk ;) |
| 06:07.05 | DTRemenak | that's usually not considered very polite though |
| 06:07.11 | KingofCamelot | Indeed |
| 06:07.12 | DTRemenak | screws with svn blame |
| 06:08.05 | DTRemenak | but it shows that there's always a way back to the right repository state, even if you manage to clobber other people's changes |
| 06:08.41 | DTRemenak | there's no way to permanently screw up the repository without shell access |
| 06:14.11 | Flash | darn. HUDRenderer::tankScoreCompare isn't even used anywhere |
| 06:20.19 | Flash | hurts KingofCamelot even more |
| 06:20.43 | CIA-49 | BZFlag: 03jwmelto * r18514 10/trunk/bzflag/ (12 files in 5 dirs): PROTOCOL CHANGE: send sever rank as a float |
| 06:21.30 | DTRemenak | if he's merging to a specific revision it won't hurt him at all |
| 06:21.41 | DTRemenak | he'll just update right before he commits |
| 06:23.01 | KingofCamelot | The merge just failed anyways, heh |
| 06:23.14 | KingofCamelot | Said something about a read error on some file |
| 06:23.20 | DTRemenak | ah, that's sf being stupid |
| 06:23.28 | DTRemenak | revert and try the same merge again |
| 06:23.45 | DTRemenak | I've been having the same problem on and off with simple updates |
| 06:23.58 | BulletCatcher | 2.99.6, we hardly knew ye. |
| 06:24.01 | DTRemenak | takes forever then dies with a read error |
| 06:24.12 | Flash | KingofCamelot: are you using cmd-line svn? |
| 06:24.41 | KingofCamelot | BTW, I feel like something isn't going right from the beginning of the merge. It says updating AUTHORS, but there should be no changes to AUTHORS in my branch. |
| 06:24.46 | KingofCamelot | Flash: TortoiseSVN |
| 06:38.44 | DTRemenak | KingofCamelot: Interesting. I get the same thing - it says there are diffs in AUTHORS, but there are no lines changed. a few dozen other files are the same way. |
| 06:39.27 | Flash | me too. I think every single file is diffing |
| 06:39.39 | Flash | we didn't change curl in the past 6 months, did we? |
| 06:39.54 | DTRemenak | we did, but he synced to trunk first |
| 06:40.00 | DTRemenak | the only changes should be his |
| 06:40.19 | DTRemenak | and it's not every file, I don't think |
| 06:40.56 | DTRemenak | tools/tankview/tankview.rc is marked as different, for instance, but no other files in tools/tankview are |
| 06:41.26 | DTRemenak | and there are no actual differences, of course |
| 06:41.51 | DTRemenak | could be that every file that has changed in either trunk or his branch since the branch point shows up |
| 06:42.10 | Flash | well, there *is* a version created when you branch, so perhaps it makes sense? |
| 06:42.20 | DTRemenak | hm, possible, yeah |
| 06:42.45 | DTRemenak | they're essentially marked as changed in both branches...just that the changes are identical |
| 06:43.13 | KingofCamelot | Heh |
| 06:43.13 | Flash | for example, my branch created AUTHORS r 17225, but a diff to previous shows no diffs |
| 06:44.13 | DTRemenak | I wonder if the right way to go is not to sync branches then. just merge back to the branch point and fix any conflicts then. |
| 06:44.19 | Flash | BulletCatcher: you don't have a name in the AUTHORS file |
| 06:44.42 | DTRemenak | s/right way/easy way/ :) |
| 06:44.54 | Flash | what does that mean, exactly? |
| 06:45.07 | DTRemenak | what does what mean? |
| 06:45.20 | Flash | "merge back to the branch point" ?? |
| 06:45.30 | Flash | is still wrestling with how svn does merges |
| 06:45.40 | blast007 | the point where the branch was copied from |
| 06:45.58 | Flash | I've been using ClearCase for the past 15-20 years, so svn is all new to me |
| 06:46.08 | DTRemenak | svn does three-way merges. so you merge, for instance, from branch rX to head rY, into head rZ. |
| 06:46.30 | BulletCatcher | Flash: Yes. I am known here only by my pseudonym. |
| 06:46.31 | DTRemenak | effectively it takes the diffs from rX to rY, and applies them to rZ |
| 06:46.42 | blast007 | DTRemenak: does the merging stuff in SVN 1.5 be of better use in this kind of situation? I haven't tried anything like that, yet |
| 06:46.54 | DTRemenak | it's more complicated but far more powerful than simple promote/rebase merging |
| 06:48.04 | Flash | that sounds similar to ClearCase... except that it keeps track of what branches have been merged where when so it does a pretty good job of the 3-way merge |
| 06:48.22 | DTRemenak | yeah, svn has no natural markers for merges, unfortunately |
| 06:48.42 | DTRemenak | you have to either reconstruct them from revision graphs, or just remember |
| 06:54.56 | BulletCatcher | I changed the Subversion properties on many files in trunk over the last couple of months. That probably accounts for most of the "marked as changed, but no differences seen" files. |
| 06:55.52 | DTRemenak | the props should have been merged to branch also, when KingofCamelot did the sync merges |
| 06:57.13 | KingofCamelot | Weird stuff, heh |
| 06:58.00 | Flash | so, is it good or bad to merge from trunk down to branch? |
| 07:00.23 | BulletCatcher | Take tools/tankview/tankview.rc for example. It has two commits: the original one and my addition of the svn:eol-style=native property. Has the property change actually been merged into the branch? |
| 07:00.49 | DTRemenak | Flash: that's what I've been trying to figure out. I dunno. |
| 07:03.28 | Flash | I was contemplating syncing my branch, but now you have me thinking |
| 07:04.04 | *** join/#bzflag steamedfish (n=steamedf@221.225.140.148) |
| 07:06.21 | BulletCatcher | BTW, I see no new problems at all in 2.99.7 vs. 2.99.5. |
| 07:20.29 | Flash | thanks |
| 07:23.09 | DTRemenak | is amused by Flash's predilection to moving *'s around |
| 07:23.58 | DTRemenak | don't get me wrong, I like the direction you move them, I'm just amused by it :) |
| 07:32.32 | Constitution | laserball is out and about with his cheats again |
| 07:43.43 | *** join/#bzflag a_meteorite (n=a_meteor@adsl-75-15-139-207.dsl.snlo01.sbcglobal.net) |
| 07:45.03 | Constitution | DTRemenak: you still around? |
| 07:45.10 | DTRemenak | yup |
| 07:52.33 | CIA-49 | BZFlag: 03macsforme * r18515 10/trunk/admin/master-bans.txt: laserball2 masterban again |
| 07:57.47 | Flash | yes, he was on mofo too, but kitty banned him |
| 08:06.50 | Flash | DTRemenak: I do it for a very sound reason: the declaration should emphasize the "type" "name", even if the type is "Foo*" |
| 08:07.03 | DTRemenak | yup, I understand |
| 08:07.20 | DTRemenak | just amuses me that you change it in files you don't otherwise touch ;) |
| 08:07.36 | DTRemenak | tells me it's instinctive |
| 08:09.20 | Flash | not entirely true. I never modify a file just for the heck of it |
| 08:13.02 | Flash | so shall I merge trunk->branch or not? |
| 08:13.19 | DTRemenak | it's up to you. I don't know whether it will make merging later easier or harder |
| 08:13.27 | DTRemenak | if it will help you work on your branch, do it |
| 08:24.03 | *** join/#bzflag Admirarc1 (n=Athelthr@87.113.94.77.plusnet.pte-ag2.dyn.plus.net) |
| 08:35.25 | *** join/#bzflag laserball311 (n=djm@c-71-59-113-232.hsd1.pa.comcast.net) |
| 08:40.47 | *** join/#bzflag KingRobot (n=KingRobo@student4945.student.nau.edu) |
| 08:50.25 | *** part/#bzflag laserball311 (n=djm@c-71-59-113-232.hsd1.pa.comcast.net) |
| 08:50.31 | *** join/#bzflag delusional (n=delusion@pool-71-240-49-192.pitt.east.verizon.net) |
| 08:56.44 | Constitution | so there's a server out there that runs 2.0.2 (and is therefore vulnerable to a lot of known exploits), has no contact info, no help files, no -srvmsg or -admsg, no web site, no admin groups, no persistent banfile, and is a favorite hang-out spot for cheaters |
| 08:58.16 | Constitution | as far as the public list goes, is it our policy to just let it rot, or is there something we can do about it? |
| 08:58.52 | Constitution | I've got the WHOIS info on the domain... no useful information really |
| 08:59.28 | Manu | Constitution: if the admin doesn't upgrade his server, what can we do? it's his problem I guess |
| 09:01.30 | Constitution | the only thing we can really do is remove a server from the list... but obviously that's appropriate only for a limited number of offenses |
| 09:01.56 | Manu | BTW, I guess the masterban you did isn't a static IP |
| 09:02.17 | Constitution | yeah |
| 09:02.44 | Constitution | are we doing ranges now? I thought we didn't do those, but I saw some ranges for Sk3letr0n |
| 09:03.22 | Manu | Constitution: are you sure, is it an abandoned server? |
| 09:04.34 | Manu | what's the server? is it popular? |
| 09:04.59 | Constitution | I have no idea how long it's been around... but judging from the bzfs binary that's over four years old iirc, it's clearly either really old or really poorly run |
| 09:05.22 | Manu | or a cheater is running it :-p |
| 09:05.59 | Constitution | Sk3letr0n and laserball were both there tonight |
| 09:08.46 | *** join/#bzflag Admirarch (n=Athelthr@87.113.119.98) |
| 09:11.09 | *** join/#bzflag Tupone (n=Tupone@pdpc/supporter/active/Tupone) |
| 09:11.09 | *** mode/#bzflag [+v Tupone] by ChanServ |
| 09:12.27 | *** join/#bzflag PrezKennnedy (i=Matthew@whitecalf.net) |
| 09:13.43 | CIA-49 | BZFlag: 03macsforme * r18516 10/trunk/admin/master-bans.txt: Re-synced masterban list with live copy |
| 09:14.11 | *** join/#bzflag Admirarc1 (n=Athelthr@87.113.81.59.plusnet.pte-ag2.dyn.plus.net) |
| 09:14.57 | *** join/#bzflag KingRobot (n=KingRobo@student4945.student.nau.edu) |
| 09:20.13 | Manu | ~seen phoner |
| 09:20.15 | ibot | Manu: i haven't seen 'phoner' |
| 10:53.23 | *** join/#bzflag Tupone (n=Tupone@pdpc/supporter/active/Tupone) |
| 10:53.23 | *** mode/#bzflag [+v Tupone] by ChanServ |
| 10:58.32 | *** join/#bzflag Admirarch (n=Athelthr@87.112.34.55.plusnet.ptn-ag1.dyn.plus.net) |
| 11:18.15 | *** join/#bzflag Wits (n=Warinthe@212.119.33.65.cfl.res.rr.com) |
| 11:19.44 | *** join/#bzflag MPS (n=mathias@h34-101-116-82.dsl.netz-quadrat.de) |
| 11:20.38 | *** join/#bzflag prae (n=praetori@124-168-185-164.dyn.iinet.net.au) |
| 11:45.22 | donny_baker | blast007: protocol bump... need to get a new alpha build out for testing, since the one on the forums won't work anymore |
| 11:46.13 | donny_baker | i would do it, but I haven't built bzflag for releasing before, will give it a shot sometime this weekend |
| 12:23.53 | *** join/#bzflag Swigg (n=Default@98.105.154.176) |
| 12:31.10 | *** join/#bzflag ep (n=mdr@about/essy/guynextdoor/ep) |
| 13:45.39 | *** join/#bzflag Swigg (n=Default@98.105.154.176) |
| 13:56.48 | *** join/#bzflag nn64 (n=nn@74.94.43.196) |
| 13:58.13 | *** join/#bzflag nn64 (n=nn@74.94.43.196) |
| 13:58.13 | *** join/#bzflag me1 (n=me1@unaffiliated/me1) |
| 14:14.18 | *** join/#bzflag Wits (n=Warinthe@212.119.33.65.cfl.res.rr.com) |
| 14:15.09 | *** join/#bzflag spldart (n=short_ci@adsl-70-240-228-201.dsl.hstntx.swbell.net) |
| 14:15.09 | *** mode/#bzflag [+v spldart] by ChanServ |
| 14:23.03 | *** join/#bzflag __Lukstr (n=Lukstr@206-248-164-195.dsl.teksavvy.com) |
| 14:45.49 | *** join/#bzflag nn64 (n=nn@74.94.43.196) |
| 15:05.53 | *** join/#bzflag spldart_ (n=short_ci@adsl-70-240-252-139.dsl.hstntx.swbell.net) |
| 15:39.49 | *** join/#bzflag Abominable (n=chatzill@user-0ce2hv1.cable.mindspring.com) |
| 15:43.05 | *** join/#bzflag _Lukstr (n=Lukstr@206-248-164-195.dsl.teksavvy.com) |
| 15:43.44 | *** join/#bzflag spldart__ (n=short_ci@adsl-70-240-213-133.dsl.hstntx.swbell.net) |
| 15:56.03 | *** join/#bzflag JeffM (n=Jeff@unaffiliated/jeffm) |
| 16:01.55 | blast007 | donny_baker: works for now (my servers, at least, match up), but I can update later |
| 16:03.27 | *** join/#bzflag bier (n=bier@p54A56EE6.dip.t-dialin.net) |
| 16:03.52 | *** join/#bzflag dcat_ (n=dirtycat@pdpc/supporter/active/dcat) |
| 16:14.34 | *** join/#bzflag spldart_ (n=short_ci@adsl-70-240-194-0.dsl.hstntx.swbell.net) |
| 16:14.49 | *** join/#bzflag ViciousM (n=max@cpe-066-026-094-182.nc.res.rr.com) |
| 16:17.21 | *** join/#bzflag Admirarc1 (n=Athelthr@87.114.150.173.plusnet.thn-ag1.dyn.plus.net) |
| 16:17.32 | *** join/#bzflag temp_dist (n=temp_dis@about/essy/alarming/a-temp-dist) |
| 16:29.45 | *** join/#bzflag Lukstr (n=Lukstr@69-196-137-229.dsl.teksavvy.com) |
| 16:42.23 | *** join/#bzflag think_tank (n=think_ta@unaffiliated/thinktank/x-168245) |
| 16:53.21 | *** join/#bzflag KTL (n=KTL@213.219.163.16.adsl.dyn.edpnet.net) |
| 16:56.03 | *** join/#bzflag Think_Differentl (n=fatass__@unaffiliated/thinkdifferentl/x-838543) |
| 16:57.03 | *** join/#bzflag Lukstr (n=Lukstr@69-196-148-61.dsl.teksavvy.com) |
| 16:59.48 | *** join/#bzflag Lukstr (n=Lukstr@69-196-148-61.dsl.teksavvy.com) |
| 17:00.52 | *** join/#bzflag spldart__ (n=short_ci@adsl-70-240-225-227.dsl.hstntx.swbell.net) |
| 17:04.58 | *** join/#bzflag _Lukstr (n=Lukstr@69-196-148-61.dsl.teksavvy.com) |
| 17:09.44 | JeffM | DTRemenak: you awake? |
| 17:28.43 | *** join/#bzflag Lukstr (n=Lukstr@76-10-147-12.dsl.teksavvy.com) |
| 17:28.43 | *** join/#bzflag Swigg (n=Default@98.105.154.176) |
| 17:37.23 | *** join/#bzflag TD-Linux (n=wheeeeee@about/essy/indecisive/TD-Linux) |
| 17:44.55 | *** join/#bzflag spldart__ (n=short_ci@adsl-70-240-195-58.dsl.hstntx.swbell.net) |
| 17:55.47 | *** join/#bzflag Dont (n=hi@frnk-5d810823.pool.einsundeins.de) |
| 18:12.44 | *** join/#bzflag _anomaly_ (n=mike@h165.85.91.75.dynamic.ip.windstream.net) |
| 18:15.15 | *** join/#bzflag _Lukstr (n=Lukstr@206-248-158-10.dsl.teksavvy.com) |
| 18:15.32 | *** join/#bzflag SpazzyMcGee (n=SpazzyMc@unaffiliated/spazzymcgee) |
| 18:20.01 | *** join/#bzflag SpazzyMcGee (n=SpazzyMc@unaffiliated/spazzymcgee) |
| 18:20.25 | SpazzyMcGee | lol |
| 18:28.52 | *** join/#bzflag spldart (n=short_ci@adsl-70-241-2-39.dsl.hstntx.swbell.net) |
| 18:28.52 | *** mode/#bzflag [+v spldart] by ChanServ |
| 18:29.16 | *** join/#bzflag TJ13820_ (n=TJ13820@c-71-236-81-117.hsd1.pa.comcast.net) |
| 18:29.50 | *** part/#bzflag TJ13820_ (n=TJ13820@c-71-236-81-117.hsd1.pa.comcast.net) |
| 18:31.22 | spldart | Wow.. the office looks all wierd blacked out 8-0 |
| 18:31.27 | spldart | Lost power there. |
| 18:31.53 | TD-Linux | *me sneaks up behind spldart* |
| 18:34.53 | KTL | skeletron is active again |
| 18:35.12 | KTL | just saw him in tavern.rklubi.ee : 59151 |
| 18:40.03 | *** join/#bzflag TJ13820_ (n=TJ13820@c-71-236-81-117.hsd1.pa.comcast.net) |
| 18:42.22 | *** join/#bzflag Admirarch (n=Athelthr@87.112.78.25.plusnet.ptn-ag2.dyn.plus.net) |
| 18:47.19 | *** join/#bzflag Lukstr (n=Lukstr@76-10-170-245.dsl.teksavvy.com) |
| 18:49.22 | *** join/#bzflag __Lukstr (n=Lukstr@76-10-170-245.dsl.teksavvy.com) |
| 18:52.36 | *** join/#bzflag Pimpi (n=frank@gondolin.pimpi.org) |
| 18:55.24 | CIA-49 | BZFlag: 03kingofcamelot * r18517 10/trunk/bzflag/ (72 files in 32 dirs): Merging gsoc_server_listing into trunk. Hopefully did this right. |
| 18:56.08 | JeffM | WOOOOTT |
| 19:01.19 | *** join/#bzflag Admirarc1 (n=Athelthr@87.114.6.25.plusnet.thn-ag3.dyn.plus.net) |
| 19:06.36 | *** join/#bzflag spldart_ (n=short_ci@adsl-70-240-242-135.dsl.hstntx.swbell.net) |
| 19:06.41 | *** join/#bzflag Lukstr (n=Lukstr@206-248-163-58.dsl.teksavvy.com) |
| 19:10.02 | Flash | let's find out.... |
| 19:11.26 | Flash | KingofCamelot: I didn't really keep up on your project... what will I notice with this build? |
| 19:12.21 | JeffM | Flash: hah |
| 19:12.24 | JeffM | go to the server list |
| 19:12.32 | JeffM | it should be obvious |
| 19:12.49 | TD-Linux | oooh |
| 19:12.52 | TD-Linux | does svn up |
| 19:20.21 | delusional | wont build for me /include/ServerList.h:32: error: '>>' should be '> >' within a nested template argument list |
| 19:20.21 | CIA-49 | BZFlag: 03jwmelto * r18518 10/trunk/bzflag/ (include/ServerList.h src/game/ServerList.cxx): change >> to > > for nested templates |
| 19:20.32 | Flash | try that ;-) |
| 19:20.36 | delusional | hhehe that was a quick fix! |
| 19:21.48 | Flash | this is a little more pernicious: HUDuiScrollList.cxx:181: warning: comparison between signed and unsigned integer expressions |
| 19:24.44 | Flash | there are other >> I missed.... |
| 19:29.00 | KingofCamelot | So the merge seemed to go right, but some compilation errors? |
| 19:29.39 | Flash | yes, when you nest templates you have to close with > > not >> (that's an operator) |
| 19:29.40 | CIA-49 | BZFlag: 03jwmelto * r18519 10/trunk/bzflag/src/bzflag/ (7 files): got the last >> to > > change |
| 19:29.51 | Flash | there are tons of warnings too |
| 19:30.38 | Flash | my server list is empty... and it crashed :-( |
| 19:31.26 | Flash | but yes, JeffM I see what changed ;-) |
| 19:32.16 | KingofCamelot | Hmmm. What platform did you compile on Flash? |
| 19:32.23 | Flash | Mac OS 10.5 |
| 19:32.27 | TD-Linux | HUDuiServerList.cxx:24:25: error: OpenGlUtils.h: No such file or directory |
| 19:32.28 | TD-Linux | yeah |
| 19:32.34 | TD-Linux | that header doesn't exist on LInux |
| 19:32.51 | KingofCamelot | Heh |
| 19:32.58 | KingofCamelot | Was used in some other file... |
| 19:33.07 | Flash | TD-Linux: to quote JeffM: fix it |
| 19:33.45 | TD-Linux | oh whoops |
| 19:33.47 | TD-Linux | it's a bzflag file |
| 19:33.59 | Flash | KingofCamelot: you might want to try to resolve all the compile warnings... |
| 19:34.14 | *** join/#bzflag LongDon (n=LongDon@host-091-097-018-152.ewe-ip-backbone.de) |
| 19:34.14 | Flash | Otherwise, I'll play with it when I get back |
| 19:34.21 | TD-Linux | oh |
| 19:34.25 | TD-Linux | capitalization error |
| 19:34.26 | TD-Linux | :P |
| 19:34.31 | TD-Linux | OpenGLUtils.h |
| 19:34.35 | TD-Linux | not OpenGlUtils.h :P |
| 19:34.42 | TD-Linux | somoene with svn access fix it |
| 19:34.58 | KingofCamelot | Flash: Well that's the thing, alright got rid of the compile warnings on MSVC :P |
| 19:36.01 | TD-Linux | well |
| 19:36.04 | TD-Linux | it compiles now |
| 19:37.59 | TD-Linux | lots of warnings, but they look easy to fix |
| 19:39.17 | delusional | i got a full build on my OSX 10.4. |
| 19:40.03 | TD-Linux | OSX is case insensitive, so that makes sense |
| 19:40.23 | TD-Linux | s/OSX/HFS+ |
| 19:41.09 | TD-Linux | purty fonts |
| 19:41.11 | delusional | still that problem with function keys |
| 19:41.18 | delusional | and esc |
| 19:42.13 | TD-Linux | aieek |
| 19:42.13 | KingofCamelot | What's wrong with esc? |
| 19:42.26 | TD-Linux | it looked like bzflag was thrashing |
| 19:43.06 | temp_dist | I believe it's building fonts when the main menu is called |
| 19:43.20 | TD-Linux | oh okay that would explain it, it's okay now |
| 19:43.20 | delusional | it appears to me that OSX makes the "sosumi" sound for invalid key... and then bzflag performs the operation about 20 seconds later |
| 19:43.39 | TD-Linux | also might have been something else on my system |
| 19:43.43 | TD-Linux | server list looks nice :D |
| 19:43.48 | TD-Linux | someone host a server so we can test it |
| 19:44.57 | temp_dist | IIRC, both lamer and blast to an automatic daily build.. |
| 19:45.41 | delusional | this would have to be a half hourly build |
| 19:50.33 | *** join/#bzflag spldart_ (n=short_ci@adsl-70-240-179-115.dsl.hstntx.swbell.net) |
| 19:50.33 | temp_dist | built fine on OSX 10.5 - the serverlist type seems to run off the screen http://tinyurl.com/58slez |
| 19:50.47 | *** join/#bzflag _Lukstr (n=Lukstr@206-248-163-58.dsl.teksavvy.com) |
| 19:52.50 | TD-Linux | looks fine for me ... it's probably designed for widescreen |
| 19:53.35 | DTRemenak | looks like it picks the wrong fonts in the 1680x1050 case |
| 19:54.58 | KingofCamelot | BTW, the column headers still need some work, so they may look a little off at the moment |
| 19:58.20 | CIA-49 | BZFlag: 03dtremenak * r18520 10/trunk/bzflag/src/bzflag/HUDuiServerList.cxx: l->L for case-sensitive systems |
| 19:58.35 | temp_dist | the serverlist layout and options look amazing, great job! |
| 20:01.03 | *** join/#bzflag WWCD (n=WWCD@189.163.159.20) |
| 20:01.11 | KingofCamelot | Thanks. :) |
| 20:01.28 | DTRemenak | thanks for merging it, btw :) |
| 20:01.45 | DTRemenak | and you're welcome to continue to working on it and anything else you feel like in trunk |
| 20:02.26 | KingofCamelot | I'll keep working on it, some things aren't quite done. BTW, any of the hotkeys were all just randomly created by me, and quite a few of them aren't very logical. :P |
| 20:02.49 | KingofCamelot | Like d should probably be used, I just avoided it cause I was using it for some development code, etc |
| 20:04.07 | *** join/#bzflag __Lukstr (n=Lukstr@206-248-163-58.dsl.teksavvy.com) |
| 20:06.00 | *** part/#bzflag WWCD (n=WWCD@189.163.159.20) |
| 20:08.28 | CIA-49 | BZFlag: 03dtremenak * r18521 10/trunk/bzflag/plugins/ (27 files in 25 dirs): fix some bad merges inherited from the server list branch |
| 20:08.51 | DTRemenak | those were previously broken in branch, not new things from this merge. looks like this one went cleanly. |
| 20:19.06 | Flash | TD-Linux: I can't find an instance of OpenGlUtils (vs OpenGLUtils)... did someone fix it? |
| 20:19.12 | TD-Linux | yes |
| 20:19.18 | TD-Linux | r18520 |
| 20:24.49 | delusional | bzfs gives me this... doesn't stop the server though Setting process affinity to processor 0 |
| 20:24.49 | delusional | Unable to set processor affinity to 0 - function not implemented on this platform. |
| 20:24.52 | Flash | KingofCamelot: GCC likes for the constructor member initializer list to be in the order the members are declared |
| 20:26.05 | Flash | delusional: you can ignore that |
| 20:26.15 | delusional | i figured. |
| 20:26.20 | Flash | processor affinity is not implemented/required on macs |
| 20:27.00 | Flash | KingofCamelot: so in HUDuiServerList, you have two ctors, but not all the members are initialized in the second one |
| 20:27.14 | Flash | shall I just take a guess as to what the correct initial values should be? |
| 20:27.46 | Flash | also, I came across at least one unused member function. Any reason to retain something if it isn't used? |
| 20:29.56 | *** join/#bzflag Tupone (n=Tupone@pdpc/supporter/active/Tupone) |
| 20:29.56 | *** mode/#bzflag [+v Tupone] by ChanServ |
| 20:30.25 | Flash | wow... those two ctors were like 80% of the warnings |
| 20:33.21 | *** join/#bzflag Lukstr (n=Lukstr@206-248-163-58.dsl.teksavvy.com) |
| 20:34.02 | Flash | oh... that second ctor isn't used either |
| 20:36.02 | *** join/#bzflag spldart_ (n=short_ci@adsl-70-240-250-135.dsl.hstntx.swbell.net) |
| 20:37.03 | Flash | KingofCamelot: when you do come back, give me a shout |
| 20:41.23 | KingofCamelot | Flash: Shout :) |
| 20:41.41 | *** join/#bzflag MindstormsKid (n=chatzill@wikipedia/MindstormsKid) |
| 20:44.05 | Flash | two things I wonder about |
| 20:44.20 | Flash | first is in HUDuiServerList::filter::operator() |
| 20:44.50 | Flash | the warning is about signed/unsigned, the line is (filter & i) == i |
| 20:45.11 | Flash | so working through the logic, I wonder why you 'i' isn't unsigned |
| 20:45.33 | Flash | and also why you ++i instead of i =<< 1 |
| 20:45.46 | Flash | but also, is it really kosher to use an enum like that? |
| 20:45.51 | *** join/#bzflag _Lukstr (n=Lukstr@76-10-148-31.dsl.teksavvy.com) |
| 20:46.17 | Flash | (while you are thinking, is there any reason to keep code that isn't called?) |
| 20:46.43 | KingofCamelot | I think I just forgot that filter was unsigned, and that I should make i unsigned too |
| 20:46.52 | KingofCamelot | Depends on the code |
| 20:47.14 | Flash | first case in point HUDuiServerList(bool paged) ctor |
| 20:47.33 | Flash | doesn't look like you ever really wrote it anyway |
| 20:48.21 | KingofCamelot | Yea, that can go, I don |
| 20:48.24 | KingofCamelot | t use it |
| 20:49.02 | Flash | second thing that caught my eye was I was shocked to see HUDuiServerList::filter basically forward declared in the .h and defined in the .cxx |
| 20:49.14 | Flash | I wouldn't have thought that even legal, but it compiles file |
| 20:49.23 | Flash | so I just wonder about its "morality" |
| 20:50.07 | KingofCamelot | I don't know much about structs, etc, so any of that code I winged off of examples and with help from DTRemenak |
| 20:50.39 | Flash | a struct is a class where everything defaults to public |
| 20:50.42 | Flash | that's all |
| 20:52.10 | KingofCamelot | Ok. Not sure what you're getting at with the "morality". Would you rather see filter fully defined in .h? |
| 20:52.41 | Flash | it's probably more a question for DTRemenak I guess |
| 20:53.04 | Flash | I've never seen that kind of forward declaration, so I didn't know if it was considered good practice |
| 20:53.12 | brlcad | certainly peculiar, but (obviously) not invalid |
| 20:53.14 | DTRemenak | Flash: it's valid to declare nested classes in the class definition and define them elsewhere |
| 20:53.37 | Flash | that's the "legal" part |
| 20:53.58 | DTRemenak | if they're private, it can even make sense to do so sometimes |
| 20:54.17 | DTRemenak | keeps implementation details out of the header |
| 20:54.21 | Flash | like I said, I've just never seen it before, so it struck me as odd |
| 20:54.33 | Flash | I may have to adopt the practice ;-) |
| 20:54.48 | DTRemenak | it's unusual certainly, but has some definite advantages |
| 20:56.35 | Flash | KingofCamelot: do you agree with me about the loop increment? |
| 20:56.45 | Flash | 16 iterations vs 2^16 iterations? |
| 20:56.55 | KingofCamelot | I honestly have no idea what i =<< 1 means :) |
| 20:57.02 | brlcad | ~KingofCamelot++ |
| 20:57.08 | brlcad | (for merging the branch, nice work) |
| 20:57.21 | Flash | it means left bit-shift one position (and assign) |
| 20:57.29 | DTRemenak | KingofCamelot: bitshift i one position left, and assign to i |
| 20:57.31 | Flash | 2 << 1 == 4 |
| 20:57.32 | spldart_ | extreme delay Ah! cuz of TD-L |
| 20:57.52 | DTRemenak | since you're looping through a bitmask, it effectively sets it to the next bitmask position |
| 20:58.27 | DTRemenak | so your loop would do 0x001, 0x010, 0x100, instead of 0x001, 0x010, 0x011, 0x100, 0x101, 0x111 |
| 20:58.43 | DTRemenak | forgot an 0x110 in there too |
| 20:58.46 | KingofCamelot | Ah, ok, yea, that sounds much more logical, to do it i =<< 1 |
| 20:58.47 | Flash | well, that's binary not hex, but yes |
| 20:59.00 | DTRemenak | eh, you know what I mean |
| 20:59.27 | Flash | you know me, always pedantic |
| 20:59.38 | DTRemenak | had written it out as 1, 2, 4 the first time around, figured it'd be clearer in binary |
| 21:00.13 | CIA-49 | BZFlag: 03kingofcamelot * r18522 10/trunk/bzflag/src/bzflag/ (HUDuiServerList.cxx HUDuiServerList.h): Removed unused constructor from HUDuiServerList. |
| 21:00.54 | *** join/#bzflag Admirarch (n=Athelthr@87.114.26.129.plusnet.thn-ag3.dyn.plus.net) |
| 21:00.55 | DTRemenak | also, any particular reason you skipped 0x00001 in the filter constants? |
| 21:02.35 | DTRemenak | nothing wrong with it I suppose, just seems odd to start counting at 2 ;) |
| 21:03.06 | KingofCamelot | Heh, indeed :) |
| 21:03.20 | KingofCamelot | It's cause I copied the GameOptions enum from global.h for a start |
| 21:03.27 | KingofCamelot | since most of the filters are based on GameOptions |
| 21:03.40 | KingofCamelot | and, apparently GameOptions starts at 2 :P |
| 21:03.48 | KingofCamelot | and I just never noticed really |
| 21:03.52 | DTRemenak | it has several gaps iirc |
| 21:04.07 | brlcad | options that are gone, but held for compatibility |
| 21:04.34 | DTRemenak | hm, actually it looks like someone filled in the rest of the gaps |
| 21:04.49 | KingofCamelot | BTW, MSVC isn't liking i =<< 1 |
| 21:05.09 | Flash | no, gcc didn't either |
| 21:05.11 | DTRemenak | might need to write it as i = i << 1 |
| 21:05.12 | Flash | i = i<<2 |
| 21:05.12 | brlcad | shouldn't that be <<= 1 |
| 21:05.14 | Flash | i = i<<1 |
| 21:05.28 | DTRemenak | brlcad is probably right |
| 21:05.50 | Flash | I guess so... I thought there was a shift-assignment operator |
| 21:06.03 | KingofCamelot | It likes <<= 1 just fine :) |
| 21:06.05 | DTRemenak | as brlcad wrote, i <<= 1 |
| 21:06.12 | brlcad | i wouldn't use it myself .. just be explicit |
| 21:06.14 | DTRemenak | shift-assignment, not assignment-shift |
| 21:06.20 | brlcad | that's a pretty isoteric operator |
| 21:06.26 | DTRemenak | esoteric even |
| 21:06.33 | brlcad | yeah, that too |
| 21:07.22 | Flash | yeah, if my brain were engaged I would have realized that += -= and |= all have the = trailing |
| 21:08.20 | DTRemenak | isoteric makes me think of isosterism, which is not quite the same |
| 21:08.38 | brlcad | gin and isotonic |
| 21:09.14 | brlcad | here to pump*clap*you up in isometric ways |
| 21:09.35 | DTRemenak | heh |
| 21:09.36 | *** join/#bzflag Admirarc1 (n=Athelthr@87.113.23.111.plusnet.pte-ag1.dyn.plus.net) |
| 21:10.05 | *** join/#bzflag Constitution (n=const@67.61.221.222) |
| 21:10.06 | CIA-49 | BZFlag: 03kingofcamelot * r18523 10/trunk/bzflag/src/bzflag/ (HUDuiServerList.cxx HUDuiServerList.h): Fixed up filtering options. |
| 21:10.29 | Flash | personally, I wouldn't define a member variable named "index" |
| 21:11.55 | Flash | HUDuiScrollList::get()... in the body is "index" supposed to be the argument or the member? |
| 21:14.15 | CIA-49 | BZFlag: 03dtremenak * r18524 10/trunk/bzflag/include/global.h: at least mark 0x0001 as unused, so people don't get the impression it was skipped on accident |
| 21:14.40 | DTRemenak | s/on accident/by accident/. or accidentally. |
| 21:16.00 | KingofCamelot | Flash: Hmm? Index is passed to get(), which advances an iterator by index to grab the control at that position |
| 21:16.17 | Flash | yes, but that class has an index member too :-| |
| 21:16.45 | KingofCamelot | Good point |
| 21:18.27 | CIA-49 | BZFlag: 03kingofcamelot * r18525 10/trunk/bzflag/src/bzflag/HUDuiScrollList.cxx: Fixed argument naming convention in HUDuiScrollList::get(). |
| 21:18.31 | KingofCamelot | there :) |
| 21:18.36 | Flash | http://flash.pastebin.ca/1195899 |
| 21:19.51 | KingofCamelot | Crash? |
| 21:20.11 | Flash | yes |
| 21:20.29 | Flash | the serverKey object is invalid (seems odd) |
| 21:20.38 | KingofCamelot | When did the crash happen? |
| 21:20.49 | Flash | points to the stack trace |
| 21:21.02 | Flash | I see the display, but nothing is in |
| 21:21.42 | DTRemenak | is pretty sure he fixed a crash like that |
| 21:22.15 | KingofCamelot | I meant when as in when you first open the server list, or after moving tabs, etc |
| 21:22.43 | Flash | the server list page draws, then long wait, then crash |
| 21:22.50 | Flash | but the list is NOT populated |
| 21:23.39 | KingofCamelot | Ok, so it looks like it's crashing when it tries to add a server |
| 21:24.21 | KingofCamelot | BTW, is it valid to have one constructor for a class call another constructor for that class? |
| 21:24.28 | Flash | no |
| 21:27.49 | KingofCamelot | Hmm |
| 21:27.57 | Flash | in HUDuiServerListItem ctors you have some early returns (argument checks?). A constructor should leave the object "properly" initialized. What happens if you take these early returns? |
| 21:28.41 | KingofCamelot | The only variables after those checks which would otherwise be initialized are strings |
| 21:28.48 | KingofCamelot | which means they are already initialized to "" |
| 21:29.11 | Flash | just trying to figure out how serverKey can be invalid |
| 21:29.29 | KingofCamelot | Me too, considering it's just a string |
| 21:29.42 | *** join/#bzflag delusional (n=delusion@pool-71-253-8-88.pitbpa.east.verizon.net) |
| 21:31.00 | KingofCamelot | getServerKey should always return a string, at the very least "" if it's 'invalid' |
| 21:32.05 | *** join/#bzflag Think_Differentl (n=fatass__@unaffiliated/thinkdifferentl/x-838543) |
| 21:32.13 | KingofCamelot | the actual getServerKey code is in the header, before serverKey is declared in private. Could that be a problem? |
| 21:32.48 | Flash | no |
| 21:33.03 | Flash | there is exactly one server available (my local one) |
| 21:33.39 | Flash | HUDuiServerList::refreshNavQueue calls std::search_n |
| 21:33.53 | Flash | the list should be length 1 (don't know it's length right now) |
| 21:34.14 | Flash | it calls HUDuiServerList::equal, where first is my server and second is invalid |
| 21:34.32 | KingofCamelot | Ah |
| 21:34.32 | CIA-49 | BZFlag: 03dtremenak * r18526 10/trunk/bzflag/src/ (5 files in 2 dirs): quell a bunch of warnings, mostly int->float implicit cast warnings |
| 21:34.50 | KingofCamelot | and getting getServerKey on an invalid object |
| 21:35.41 | CIA-49 | BZFlag: 03dtremenak * r18527 10/trunk/bzflag/src/bzflag/HUDuiTypeIn.h: missed a file |
| 21:36.01 | KingofCamelot | So when the list is only 1 item long, will search_n be passing null as the second argument? |
| 21:36.14 | Flash | don't know, never used search_n |
| 21:36.21 | Flash | what are you trying to accomplish? |
| 21:37.58 | KingofCamelot | That particular code, in refreshNavQueue, is to ensure that if you're sorting or filtering the list, the focus stays with the server that is in focus in the list |
| 21:42.34 | Flash | did you really want search_n, or would find have worked? |
| 21:43.01 | Flash | or find_if, to supply your own predicate |
| 21:43.04 | KingofCamelot | find doesn't let you set a predicate for comparing the equality |
| 21:43.11 | KingofCamelot | Ah, didn't know about find_if |
| 21:43.37 | Flash | http://www.cplusplus.com/reference |
| 21:43.59 | Flash | Sun systems have man pages for the STL, but my Mac doesn't :-( |
| 21:44.11 | KingofCamelot | Although that doesn't work, can't use find_if |
| 21:44.43 | KingofCamelot | find_if uses a unary predicate, while search_n uses a binary predicate |
| 21:45.01 | Flash | so I still don't understand what you are doing |
| 21:45.48 | DTRemenak | you can likely bind your binary predicate into a unary predicate |
| 21:46.14 | KingofCamelot | I'm using search_n to try to find the item that was in focus pre-refresh in the new refreshed list |
| 21:46.45 | Flash | so search_n with equal looks for two entries in the range with the same value as you pass in? |
| 21:47.34 | KingofCamelot | I pass search_n the item that was in focus pre-refresh, and it tries to find it in the refreshed list, using equal to compare items |
| 21:47.42 | DTRemenak | so you know what was in focus, you can use bind_2nd to set the old focus in the predicate, then you have a unary predicate you can use for find_if. right? |
| 21:48.01 | Flash | gets fuzzy with bind_xxx |
| 21:48.27 | KingofCamelot | DTRemenak: Sure, but is there really a need to do that, instead of using search_n? |
| 21:48.38 | KingofCamelot | I mean, I guess Flash's crash is being caused by search_n |
| 21:48.39 | Flash | or construct your predicate with the value to match for, e.g. EqualPredicate equal(value) |
| 21:48.52 | DTRemenak | dunno. there's probably a special case being run into with n=1 and (first - last) == 1 |
| 21:49.25 | KingofCamelot | If search_n passes null for the second argument then we can just check for that |
| 21:49.48 | Flash | I think it's calling your predicate with end() as the second argument |
| 21:50.19 | Flash | the web page shows this line as part of the reference implementation: limit=first; advance(limit,distance(first,last)-count); |
| 21:50.27 | Flash | (limit is an iterator) |
| 21:50.39 | Flash | distance(first,last) should be 1 |
| 21:50.45 | Flash | count = 1 |
| 21:51.00 | Flash | so limit should advance 0 ? |
| 21:51.23 | Flash | then it skips the logic and returns last |
| 21:51.35 | Flash | but clearly that's not the case, since it called your predicate |
| 21:51.40 | Flash | let me debug further |
| 21:51.50 | DTRemenak | it should skip the predicate |
| 21:52.11 | KingofCamelot | Should, but nothing ever works out that easily. :) |
| 21:52.31 | KingofCamelot | I've got to go grab some food, haven't eaten all day. I'll be back in about 30 mins, and I'll hit you up when I get back Flash. |
| 22:00.19 | *** join/#bzflag ep_ (n=mdr@about/essy/guynextdoor/ep) |
| 22:03.27 | *** join/#bzflag __Lukstr (n=Lukstr@76-10-148-31.dsl.teksavvy.com) |
| 22:13.41 | Flash | I'm positive the problem is HUDuiControl* currentFocus = getNav().get(); |
| 22:13.55 | Flash | that's the argument (second) to the binary predicate |
| 22:14.57 | Flash | the predicate does a C-style cast from HUDuiControl* to HUDuiServerListItem* and I guess that currentFocus isn't of that type |
| 22:15.14 | Flash | OTOH, I change the c-style cast to dynamic_cast and no difference :-( |
| 22:17.19 | Flash | on entry to refreshNavQueue, getNav() list is length 2 ???? |
| 22:25.26 | *** join/#bzflag Lukstr (n=Lukstr@206-248-132-198.dsl.teksavvy.com) |
| 22:27.55 | *** join/#bzflag _Lukstr (n=Lukstr@206-248-160-52.dsl.teksavvy.com) |
| 22:33.56 | CIA-49 | BZFlag: 03jwmelto * r18528 10/trunk/bzflag/src/bzflag/ (HUDuiServerList.cxx HUDuiServerList.h): |
| 22:33.56 | CIA-49 | BZFlag: Fix member initializer order, add default cases to all switches |
| 22:33.56 | CIA-49 | BZFlag: lots of whitespace |
| 22:42.53 | *** join/#bzflag _Lukstr (n=Lukstr@206-248-160-52.dsl.teksavvy.com) |
| 22:53.26 | KingofCamelot | Flash: For HUDuiServerList, it adds itself to the nav list |
| 22:54.15 | Flash | HUDuiServerList is not of type HUDuiServerListItem, is it? |
| 22:56.24 | *** join/#bzflag JeffM (n=Jeff@unaffiliated/jeffm) |
| 22:58.21 | Flash | do you want to try to walk through it in the debugger with me? |
| 22:58.22 | CIA-49 | BZFlag: 03jwmelto * r18529 10/trunk/bzflag/src/bzflag/ (7 files): Fixed the last of the compilation warnings |
| 22:58.30 | KingofCamelot | No, it is not |
| 22:58.40 | Flash | so that's why it fails |
| 22:58.55 | Flash | it is the "currentlySelected" item that is compared to the list |
| 22:59.18 | Flash | brutally cast to an inappropriate type, and pointer savagery ensues |
| 22:59.40 | Flash | but I don't know why I didn't get an exception when I changed it to dynamic_cast.... |
| 22:59.49 | Flash | let me try again more carefully |
| 23:03.13 | Flash | DTRemenak: isn't dynamic_cast supposed to throw std::bad_cast ?? |
| 23:03.41 | DTRemenak | Flash: dynamic_cast returns NULL for invalid casts |
| 23:03.53 | Flash | which it does.... |
| 23:04.43 | DTRemenak | it only throws bad_cast if you're trying to cast a reference |
| 23:05.04 | DTRemenak | because it can't return NULL in that case |
| 23:05.12 | Flash | so, HUDuiServerList::equal blindly casts its arguments down the inheritence tree and dereferences them |
| 23:05.31 | Flash | I can put in dynamic cast and detect the error, but then what? |
| 23:05.37 | Flash | I guess just return false? |
| 23:05.47 | DTRemenak | shouldn't be attempting to downcast a member that it can't |
| 23:05.58 | Flash | really, the second argument should not have been supplied if it's an invalid type |
| 23:06.09 | DTRemenak | if the first member of the nav queue is not a valid item, then it should never be passed in |
| 23:06.16 | Flash | agreed |
| 23:06.24 | DTRemenak | better to just protect against that earlier on |
| 23:06.37 | Flash | more completely though, since equal is casting, what should it do in the event of an invalid cast? |
| 23:07.15 | DTRemenak | throw an exception, or crash |
| 23:07.29 | Flash | ok, it's crashing just fine ;-) |
| 23:07.35 | DTRemenak | we don't expect it to do that...if it does then it's an error on our part |
| 23:07.41 | DTRemenak | and we deserve whatever we get :) |
| 23:09.09 | Flash | KingofCamelot: I leave it to you to test and deal with that condition in refreshNavQueue |
| 23:09.10 | CIA-49 | BZFlag: 03jwmelto * r18530 10/trunk/bzflag/src/bzflag/HUDuiServerList.cxx: use dynamic_cast instead of C-style cast |
| 23:09.41 | Flash | I could test for it, but I'm not sure what to do if it happens |
| 23:11.27 | Flash | hopefully, that last change should make it crash for everyone ;-) |
| 23:11.47 | Flash | or at least, everyone with a server in the list |
| 23:12.01 | DTRemenak | well, if the goal is to keep the focus on the item it's on, then the right thing to do if the focus is not on an item, is not to change the focus |
| 23:12.06 | DTRemenak | sound reasonable? |
| 23:14.01 | *** join/#bzflag L4m3r_ (n=l4m3r@about/essy/warning/L4m3r) |
| 23:14.01 | *** mode/#bzflag [+v L4m3r_] by ChanServ |
| 23:17.09 | Flash | my first instinct was just to return, but I wasn't positive that would have the desired result |
| 23:17.34 | KingofCamelot | DTRemenak: Sounds reasonable. The self memeber in the navQueue is always at index 0, so if that's what's in focus, we can ignore the searching of the list |
| 23:19.51 | Flash | since your navQueue is not homogenous, I would expect an explicit test that the "in focus" item is of type HUDuiServerListItem before passing it to the search_n function |
| 23:20.04 | Flash | the same logic should apply |
| 23:20.18 | Flash | if what is "in focus" is not a server, then no action is required |
| 23:23.04 | KingofCamelot | The only time that will happen in a HUDuiServerList is if the 'in focus' is the first item in the NavQueue |
| 23:24.18 | Flash | but is it better (safer) to code for the positional case, or the type case? |
| 23:25.16 | KingofCamelot | Safer for the type case, but because of the way the items are added to the HUDuiServerList's navQueue you can assume that it will always be homogenous past position 0 |
| 23:33.53 | *** join/#bzflag whodaman- (n=whodaman@about/apple/macbook/whodaman-) |
| 23:37.48 | *** join/#bzflag Lukstr (n=Lukstr@76-10-154-61.dsl.teksavvy.com) |
| 23:41.22 | JeffM | DTRemenak: fry's dosn't seem to cary IR LEDs :( |
| 23:44.09 | Think_Differentl | JeffM, i think radioshack carries those, even if they are overpriced. |
| 23:44.20 | JeffM | ahh |
| 23:44.23 | JeffM | just need one |
| 23:44.33 | JeffM | so we can see if the cheap webcam we got is an IR cam |
| 23:45.46 | Think_Differentl | they have them in the parts drawers, individual or maybe 3 pack, iirc |
| 23:47.47 | AAA_awright | JeffM: I had gone to my local Fry's just for IR LEDs, they had some (4-5 different types iirc) |
| 23:48.19 | *** join/#bzflag __Lukstr (n=Lukstr@69-196-130-65.dsl.teksavvy.com) |
| 23:48.56 | JeffM | ours didn't |
| 23:48.57 | JeffM | :( |
| 23:58.14 | *** join/#bzflag bier (n=bier@pD9E2EF54.dip.t-dialin.net) |
| 23:59.16 | *** join/#bzflag bier|tp (n=bier@p54A5710D.dip.t-dialin.net) |