| 00:00.18 | *** join/#bzflag Manu (i=jujibo@freenode/staff/manu) |
| 00:12.02 | *** join/#bzflag trevor- (n=trevor_@c213-100-52-86.swipnet.se) |
| 00:12.37 | *** join/#bzflag Khezar (n=Greywhin@Jameson-90.resnet.brown.edu) |
| 00:20.07 | brlcad | traceroute indicates sago's uplink provider (pnap) is having issues between their backbone and sagos drop (thx erik) |
| 00:21.00 | JeffM | brlcad: yeah the internet is NOT happy |
| 00:21.08 | JeffM | http://www.internetpulse.com/ |
| 00:24.29 | JeffM | it's getting worse |
| 00:25.12 | brlcad | it's been fluctuating up and down for over an hour |
| 00:25.23 | JeffM | poor internet |
| 00:25.26 | JeffM | stupid april 1 |
| 00:25.27 | brlcad | three minutes shy of two hours |
| 00:27.41 | JeffM | all I want to do is edit a database :( |
| 00:31.34 | brlcad | hm, pnap is internap .. and they only list a "warning" level |
| 00:31.55 | brlcad | probably because it's not actual backbone, but some specific pnap-to-sago router |
| 00:32.19 | JeffM | the red one scares me :) |
| 00:35.34 | *** join/#bzflag bryjen (n=bryjen@cpe-75-81-243-228.we.res.rr.com) |
| 00:35.34 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 00:35.43 | brlcad | the NTT<->Sprint red is japan |
| 00:36.04 | JeffM | but... but that's where all the anime is.... |
| 00:36.06 | brlcad | might be the yellow internap<->gocogent link |
| 00:36.18 | JeffM | and the super freaky porn |
| 00:36.28 | brlcad | heh |
| 00:37.00 | JeffM | the UN should get a resolution together that just says "Dear Japan.. WTF!" |
| 00:38.19 | *** join/#bzflag SportChick (i=essy@freenode/staff/sportchick) |
| 00:38.20 | *** mode/#bzflag [+v SportChick] by ChanServ |
| 00:42.13 | JeffM | so, you go into a resturant with a big laptop and people think you are a workaholic, and look down on you. Go in with a 10 inch netbook, and every waitress tells you how cute your little laptop is ;) |
| 00:42.33 | blast007 | lol |
| 00:42.46 | spldart | Hehe... It's like a guy and a baby or a guy and his dog. heh |
| 00:44.42 | blast007 | spldart: or bk burger shots ;) (but that only works in the commercial...) |
| 00:45.09 | spldart | Yep... Like Catnip and Axe body spray |
| 00:47.01 | JeffM | so if I spray Axe on the laptop........... |
| 00:49.04 | JeffM | I did order a new skin for it tho, http://www.decalgirl.com/browse.cfm/4,5293.html |
| 00:54.12 | *** join/#bzflag SportChick (i=essy@freenode/staff/sportchick) |
| 00:54.13 | *** mode/#bzflag [+v SportChick] by ChanServ |
| 00:58.29 | brlcad | heh |
| 00:58.35 | brlcad | is reminded of http://www.metacafe.com/watch/1545816/family_guy_sick_cats/ |
| 01:07.02 | *** join/#bzflag Swigg (n=Default@bzflag/player/Swigg) |
| 01:07.42 | blast007 | brlcad: hehehe |
| 01:09.31 | brlcad | :) |
| 01:23.41 | me1 | ~bzflist |
| 01:26.40 | temp_dist | is it a DOS attack? |
| 01:26.48 | JeffM | no |
| 01:26.52 | temp_dist | ok |
| 01:26.54 | JeffM | tis just the internet |
| 01:27.02 | JeffM | it's nothing specifc to bzflag |
| 01:27.18 | temp_dist | fun |
| 01:35.58 | *** join/#bzflag steerpike (n=Unknown@unaffiliated/steerpike) |
| 01:36.10 | steerpike | authentication/server list doesn't work |
| 01:36.43 | *** join/#bzflag beanpole (n=Evan@ip68-99-22-196.om.om.cox.net) |
| 01:36.44 | me1 | yup |
| 01:36.50 | JeffM | yes it does |
| 01:36.55 | JeffM | you just can't connect to it ;) |
| 01:37.01 | steerpike | ^_^ |
| 01:38.21 | blast007 | hehe |
| 01:43.40 | JeffM | blast007: based on that description, I'd say no |
| 01:43.46 | JeffM | IM/EMAIL is best for them |
| 01:44.49 | blast007 | k |
| 01:46.31 | *** join/#bzflag sfgbwrth (n=sfgbwrth@pool-71-253-196-91.nrflva.east.verizon.net) |
| 01:49.04 | *** join/#bzflag ts (n=ts@bz.bzflag.bz) |
| 01:51.25 | JeffM | the criterea is basicly "antyhing we can do to NOT make them" :) |
| 01:52.14 | blast007 | ;) |
| 01:52.25 | JeffM | they are miniature drama factories |
| 02:00.55 | *** join/#bzflag spldart (n=spldart2@bzflag/contributor/spldart) |
| 02:00.56 | *** mode/#bzflag [+v spldart] by ChanServ |
| 02:04.28 | KTL | http://civilwarfortifications.com/dictionary/xgf-006.html <- page about types of firing, talks about ricochet fire |
| 02:06.03 | PositiveG | is it me or is the list server slow |
| 02:06.18 | JeffM | it's your internet |
| 02:06.24 | PositiveG | ok |
| 02:06.50 | PositiveG | when I was at work it took 5 min for the bzbb to load |
| 02:06.56 | JeffM | yep |
| 02:06.59 | PositiveG | and they have T1 |
| 02:07.10 | JeffM | most DSLs are faster then that ;) |
| 02:07.17 | JeffM | it's the internet in general |
| 02:07.17 | PositiveG | heh |
| 02:07.21 | Thumper_ | PositiveG: you shouldn't be doing that at work ;) |
| 02:07.28 | blast007 | hehe |
| 02:07.30 | PositiveG | I was on my break |
| 02:07.42 | JeffM | riiiiggghhhhhhttttttt |
| 02:07.45 | PositiveG | lol |
| 02:07.52 | PositiveG | I work at a hardware store |
| 02:07.53 | JeffM | what do you do for work? |
| 02:08.10 | JeffM | and browsing personal sites is allowed there? |
| 02:08.18 | blast007 | computer hardware! oh wait, hammers... |
| 02:08.27 | PositiveG | only on your break and lunch break |
| 02:08.33 | PositiveG | no pr0n sites |
| 02:08.34 | Thumper_ | he was looking for directions on how to build a tank |
| 02:08.53 | PositiveG | blast: yeppers |
| 02:09.08 | PositiveG | oh, blast007: yeppers |
| 02:09.18 | blast007 | either works |
| 02:09.24 | blast007 | has 'blast' on highlight |
| 02:09.30 | PositiveG | ah |
| 02:09.30 | JeffM | the interwebs look to be better now |
| 02:09.35 | PositiveG | ok |
| 02:18.49 | PositiveG | heh, someone is registering all the car manufacturers |
| 02:19.11 | PositiveG | toyota, mazda, lambrougini ( I think) |
| 02:19.18 | *** join/#bzflag a_meteor (n=a_meteor@unaffiliated/ameteorite/x-000000001) |
| 02:26.11 | *** join/#bzflag essy (i=essy@freenode/staff/sportchick) |
| 02:26.12 | *** mode/#bzflag [+v essy] by ChanServ |
| 03:03.14 | brlcad | "The network issue has been resolved. There was a major DDoS attack that flooded Sago's bandwidth. The IPs that were being attacked have been null routed which stopped the DDoS attack." |
| 03:03.30 | brlcad | ~bzflist |
| 03:03.44 | temp_dist | nice |
| 03:06.16 | *** join/#bzflag kumarabhi (n=chatzill@115.241.30.249) |
| 03:20.38 | *** join/#bzflag spldart (n=spldart2@bzflag/contributor/spldart) |
| 03:20.38 | *** mode/#bzflag [+v spldart] by ChanServ |
| 03:21.12 | *** join/#bzflag Epyon (n=epyon@static-78-8-146-214.ssp.dialog.net.pl) |
| 03:31.12 | *** join/#bzflag Swigg (n=Default@bzflag/player/Swigg) |
| 03:47.00 | *** join/#bzflag hwilde (n=hwilde@pool-68-162-148-126.pitt.east.verizon.net) |
| 03:47.05 | hwilde | 'morning bzflag |
| 03:47.11 | hwilde | odd question for you |
| 03:47.18 | a_meteorite | always up for oddness |
| 03:47.20 | hwilde | what is that little thing on top north of the radar |
| 03:47.30 | JeffM | the N? |
| 03:47.32 | hwilde | the like tick mark |
| 03:47.38 | hwilde | not north but straight up |
| 03:47.46 | JeffM | that's the way you are facing |
| 03:47.52 | hwilde | what's it called |
| 03:47.54 | hwilde | that little tick |
| 03:47.56 | hwilde | top center of the radar |
| 03:48.01 | JeffM | I don't think it has a name |
| 03:48.02 | PositiveG | I see it also... |
| 03:48.14 | JeffM | we shall call it "Steve" |
| 03:48.23 | PositiveG | Call it "That lil' Tick" |
| 03:48.38 | hwilde | hmm |
| 03:48.45 | PositiveG | Or Bob |
| 03:48.49 | PositiveG | whatever works |
| 03:49.04 | hwilde | find in files: // NOTE: before I (Steve Krenzel) made changes, minMark was always 0, which appears |
| 03:49.15 | hwilde | <PROTECTED> |
| 03:49.21 | hwilde | nope, I don't think it's called "steve" |
| 03:49.43 | JeffM | I doubt it has a name in code |
| 03:49.49 | JeffM | it's not really a "thing" |
| 03:49.55 | hwilde | well it's not drawn by whitespace |
| 03:50.03 | JeffM | no it's drawn by the radar renderer |
| 03:50.08 | hwilde | where |
| 03:50.10 | JeffM | but that dosn't mean we NAMED that code that draws |
| 03:50.19 | JeffM | one of the GLVertex calls |
| 03:50.40 | JeffM | look thru the code and see what coordinates it uses |
| 03:51.42 | hwilde | <PROTECTED> |
| 03:51.42 | hwilde | <PROTECTED> |
| 03:52.04 | JeffM | no, that's the N |
| 03:52.36 | hwilde | <PROTECTED> |
| 03:52.41 | JeffM | maybe |
| 03:52.55 | JeffM | change it and see if it moves that ;) |
| 03:52.59 | JeffM | use your noodle |
| 03:53.21 | hwilde | why when i can borrow yours |
| 03:53.26 | *** join/#bzflag short_circuit (n=james@c-98-197-19-35.hsd1.tx.comcast.net) |
| 03:53.31 | JeffM | because you have your own and you should use it |
| 03:53.35 | JeffM | it's good for it |
| 03:53.45 | JeffM | and I am using mine right now |
| 03:55.01 | hwilde | do you always respond to rhetorical questions |
| 03:55.05 | JeffM | yes |
| 03:55.27 | hwilde | oo that is it |
| 03:59.31 | hwilde | what is the color code for semi-transparent lines like glColor3f(1.0f, 1.0f, 1.0f); |
| 04:00.33 | JeffM | you use the alpha channel |
| 04:00.36 | JeffM | use 4f |
| 04:00.39 | JeffM | not 3f |
| 04:00.52 | JeffM | C++ is not HTML ;) |
| 04:01.14 | hwilde | which one is alpha channel :) |
| 04:01.20 | JeffM | RGBA |
| 04:01.50 | hwilde | ooo glColor4f(0.0f, 0.0f, 0.0f, 1.0f - dimming); |
| 04:02.19 | JeffM | yes.. we know how openGL works |
| 04:02.28 | blast007 | and how math works |
| 04:04.13 | hwilde | lol blast007 |
| 04:05.01 | JeffM | he wasn't joking |
| 04:06.09 | *** join/#bzflag kumarabhi (n=chatzill@115.241.30.249) |
| 04:15.04 | hwilde | JeffM, thx that is sweet |
| 04:19.19 | *** join/#bzflag nightstrike (n=nightstr@210.212.97.141) |
| 04:21.44 | nightstrike | hey all, need I make any more corrections to my proposal? |
| 04:25.35 | *** join/#bzflag hwilde (n=hwilde@pool-68-162-148-126.pitt.east.verizon.net) |
| 04:25.53 | hwilde | allright so I have a proposal for an anti-cheating system |
| 04:26.43 | JeffM | ok |
| 04:26.47 | PositiveG | go |
| 04:27.04 | hwilde | when you dl the src it comes with a little binary that gets run on compile time |
| 04:27.21 | PositiveG | remove it? |
| 04:27.21 | JeffM | a closed source binary? |
| 04:27.28 | PositiveG | won't happen |
| 04:27.37 | hwilde | but all it does it go to the system and run like "ls -l" |
| 04:27.47 | blast007 | :/ |
| 04:27.48 | hwilde | then when you connect to the server it sends up that info |
| 04:27.50 | JeffM | we can't have ANY cloused source stuff |
| 04:27.51 | hwilde | and you can see what is modified |
| 04:27.57 | hwilde | and include diffs |
| 04:28.05 | blast007 | hwilde: that will *not* work |
| 04:28.08 | JeffM | what prevents someone from making an app that just sends us what we want to see? |
| 04:28.17 | hwilde | obfuscate it real gud |
| 04:28.20 | blast007 | .... |
| 04:28.27 | JeffM | you can't obfuscate the net traffic |
| 04:28.32 | hwilde | the code i mean |
| 04:28.37 | JeffM | who cares what the code is |
| 04:28.38 | hwilde | it's just so easy for people to cheat :/ |
| 04:28.49 | JeffM | we can NOT have a closed source binary |
| 04:28.52 | hwilde | i swear they can see me |
| 04:28.54 | JeffM | also we can't ship a binary for every OS |
| 04:28.55 | hwilde | even if i have steal |
| 04:28.57 | hwilde | stealth |
| 04:29.06 | hwilde | they are waiting aimed right at me |
| 04:29.11 | JeffM | well then we should have the server NOT send updates for you ;) |
| 04:29.21 | JeffM | rather then use a complex method that breaks our license |
| 04:29.28 | hwilde | ok here is my other idea |
| 04:29.34 | hwilde | take a screenshot of them and store it on the server |
| 04:29.40 | blast007 | no |
| 04:29.42 | steerpike | there should be a "trap" flag, where if the tank holding the flag gets shot, the shooter is killed |
| 04:29.44 | hwilde | then compare to expected rendering and see if stealth is there |
| 04:29.44 | JeffM | what's to prevent them from sending a valid screenshot? |
| 04:29.56 | hwilde | i want the stealth cheaters dead ! |
| 04:30.00 | JeffM | steerpike: and that is fun how? |
| 04:30.08 | JeffM | hwilde: then help us make the game better so it can't happen ;) |
| 04:30.10 | PositiveG | and see cloak |
| 04:30.23 | JeffM | instead of sugesting things that are NOT based on any kind of research |
| 04:30.28 | JeffM | you can NEVER trust a client |
| 04:30.28 | JeffM | ever |
| 04:30.30 | steerpike | JeffM: adds an element of surprise |
| 04:30.36 | JeffM | steerpike: how is it fun? |
| 04:30.41 | JeffM | the game is suposed to be fun |
| 04:31.07 | JeffM | why would I have any fun by instantly blowing up when I try to shoot someone? |
| 04:31.07 | hwilde | i think a flag where the tank reflects bullets would be good :) |
| 04:31.09 | hwilde | especially for geno |
| 04:31.17 | JeffM | geno should be removed from the game |
| 04:31.24 | JeffM | you should never have unavoidable death |
| 04:31.25 | hwilde | yeah if you could reflect it back at them |
| 04:31.27 | JeffM | that is not fun |
| 04:31.41 | hwilde | ok let me ask this |
| 04:31.48 | JeffM | hwilde: if you knew how the network code worked, you'd know that we have a LONG way to go before that can happen |
| 04:31.55 | hwilde | why does geno give you so many points, but capping does not ? |
| 04:32.00 | hwilde | when you cap you kill the entire enemy team |
| 04:32.08 | hwilde | that is probably why people go for geno so much |
| 04:32.16 | hwilde | rewarding ctf with points might shift the game play |
| 04:32.30 | steerpike | hwilde: a ctf is counted to your profile |
| 04:32.31 | JeffM | because that's the way the author wrote it |
| 04:32.38 | hwilde | ctf is nowhere |
| 04:32.52 | hwilde | doesn't even show how many caps I have |
| 04:32.58 | steerpike | number of wins? |
| 04:33.05 | JeffM | CTF is about team score |
| 04:33.09 | JeffM | not personal glory |
| 04:33.24 | hwilde | but that would encourage people to ctf not constatntly hunt geno |
| 04:33.24 | JeffM | per user caps is an idea that should be done tho |
| 04:33.36 | JeffM | pfff, they will hunt geno just to be jerks ;) |
| 04:34.12 | hwilde | ok so my other idea specifically for missile wars map |
| 04:34.31 | hwilde | like poll kick or poll ban, a new one for poll rogue |
| 04:34.46 | hwilde | it turns people yellow and they spawn in the middle of the map defenseless and both teams get target practice |
| 04:35.04 | hwilde | for tkers and generally annoying people that we just want to torment until they sign off, not kick |
| 04:35.07 | JeffM | why would I want to leave MY team up to the other players? |
| 04:35.15 | JeffM | the server owner can turn off TKs in 3.0 |
| 04:35.38 | hwilde | sheesh imagine the laser spam |
| 04:35.44 | PositiveG | so your shots got through teammates? |
| 04:35.50 | steerpike | yeah |
| 04:35.50 | JeffM | yep |
| 04:35.53 | PositiveG | whoa |
| 04:35.56 | hwilde | sometimes tho I don't want to kick the annoying people |
| 04:35.59 | PositiveG | thats sweet! |
| 04:36.02 | hwilde | I want them to turn rogue so I can shoot them |
| 04:36.18 | JeffM | hwilde: and it's right to impose YOUR will on someone else's server? |
| 04:36.20 | PositiveG | *high fives the dev that coded that* |
| 04:36.27 | JeffM | PositiveG: it was a one line change |
| 04:36.31 | PositiveG | lol |
| 04:36.48 | JeffM | if (shotTeam == myTeam && noTeamKills) |
| 04:36.49 | PositiveG | well, still, it's smart |
| 04:37.00 | JeffM | no, it's just a lot more fun ;) |
| 04:37.02 | PositiveG | ah |
| 04:37.04 | PositiveG | hehe |
| 04:37.08 | JeffM | it's optional |
| 04:37.09 | steerpike | i might compile bzflag for my zipit2 wireless |
| 04:37.12 | PositiveG | yea |
| 04:37.16 | JeffM | some servers like the skill needed to not kill teamies |
| 04:38.12 | PositiveG | Yes |
| 04:38.32 | PositiveG | I could imagine MW2 w/o tks |
| 04:39.34 | a_meteorite | spray and pray^2. |
| 04:40.04 | blast007 | I don't even think they'd be praying.. |
| 04:40.08 | a_meteorite | heh |
| 04:40.12 | hwilde | it would just be laser spam all over home base |
| 04:40.17 | hwilde | you could never get the enemy flag |
| 04:40.33 | steerpike | ok.. flamethrower flag? |
| 04:40.54 | blast007 | steerpike: how would it be different than, say, MG? |
| 04:41.13 | steerpike | it would should out in multiple directions simultaneously |
| 04:41.33 | JeffM | that's called shockwave |
| 04:41.57 | steerpike | ok.. option to double up on flags |
| 04:42.01 | a_meteorite | :\ |
| 04:42.02 | JeffM | nope |
| 04:42.09 | steerpike | why not? |
| 04:42.16 | JeffM | because we said nope |
| 04:42.19 | a_meteorite | why are you suggesting a round of things without thought? |
| 04:42.21 | steerpike | lol |
| 04:42.22 | JeffM | it's a design choice |
| 04:42.31 | JeffM | just like no ramps |
| 04:42.54 | steerpike | things would need to be rewritten? |
| 04:42.58 | PositiveG | Oh, guided ShockWave! |
| 04:43.01 | PositiveG | :P |
| 04:43.02 | blast007 | design choice.. |
| 04:43.06 | PositiveG | joking |
| 04:43.09 | blast007 | as in, it's something we *chose* |
| 04:43.09 | a_meteorite | PositiveG: that was done in 1.x by cheaters |
| 04:43.13 | JeffM | steerpike: we CHOISE to not do it |
| 04:43.13 | a_meteorite | believe me, wasn't very fun. |
| 04:43.20 | PositiveG | a_meteorite: still is |
| 04:43.23 | a_meteorite | heh.. |
| 04:43.26 | steerpike | alright |
| 04:43.39 | PositiveG | a_meteorite: Sk3 pulled that on me |
| 04:44.16 | JeffM | shot branch was designed to make that impossible |
| 04:44.32 | PositiveG | remote SW? |
| 04:44.46 | JeffM | any kind of shot modification by the client |
| 04:44.54 | JeffM | all the client did was say "shoot now" |
| 04:44.57 | steerpike | PositiveG: how would you detonate it? |
| 04:44.58 | JeffM | and the server did the rest |
| 04:45.24 | JeffM | the shot info was created on the server, based on current tank stats |
| 04:45.27 | steerpike | set mines? |
| 04:45.31 | JeffM | no |
| 04:45.35 | JeffM | no mines |
| 04:45.39 | JeffM | they are not fun |
| 04:45.41 | PositiveG | steerpike: erm, I don't cheat, I would have no idea |
| 04:45.54 | JeffM | if you can see them, you drive around. if you can't then you die with out any ability to defend yourself |
| 04:45.59 | steerpike | i was replying to PositiveG's idea of a remote sw |
| 04:46.06 | JeffM | that wasn't an idea |
| 04:46.10 | JeffM | he was talking about a cheat |
| 04:46.16 | JeffM | read ALL the words of a sentace |
| 04:46.17 | steerpike | oh, ok |
| 04:46.18 | PositiveG | yup |
| 04:47.37 | steerpike | timed invincibility? |
| 04:47.49 | PositiveG | no way |
| 04:48.03 | PositiveG | get Shield and dodge |
| 04:48.16 | *** join/#bzflag KingRobot (n=mathew@unaffiliated/kingrobot) |
| 04:48.21 | a_meteorite | I have come to the conclusion that steerpike is putting no thought into his suggestions and thusly just doing more and more |
| 04:48.43 | PositiveG | a_meteorite: I agree with you fully |
| 04:48.45 | JeffM | probably true, but be nice |
| 04:48.49 | blast007 | I have an idea! |
| 04:48.49 | steerpike | ok, i'll stop and continue tomorrow |
| 04:48.51 | blast007 | cow launcher |
| 04:48.55 | PositiveG | YES! |
| 04:48.56 | KingRobot | ping brlcad |
| 04:49.00 | a_meteorite | blast007: lots of blood please |
| 04:49.00 | JeffM | piche la vash! |
| 04:49.23 | JeffM | steerpike: you don't have to stop, just please read the fourms and wiki on idea submissions first, there are thigns we just don't do |
| 04:49.29 | *** join/#bzflag kumarabhi (n=chatzill@115.241.43.229) |
| 04:49.34 | JeffM | all new things must be fun, that is the primary goal |
| 04:49.37 | PositiveG | like flag combos to save you time |
| 04:49.47 | blast007 | JeffM: what does that mean? ('piche la vash') |
| 04:49.56 | PositiveG | I could imagine St'ed CL |
| 04:50.08 | JeffM | blast007: it was said in holy grail before they hucked thec ow |
| 04:50.10 | JeffM | PositiveG: no |
| 04:50.15 | JeffM | that is just mean |
| 04:50.16 | blast007 | heh |
| 04:50.17 | blast007 | k |
| 04:50.22 | JeffM | that flag is NOT fun for those you fight |
| 04:50.31 | PositiveG | JeffM: I know, just making a few jokes |
| 04:50.33 | JeffM | one or the other is a challenge and adds fun |
| 04:50.35 | JeffM | ahh |
| 04:50.40 | blast007 | they had a flag like that in BZFlag X... but you also had SW >.< |
| 04:50.54 | blast007 | now THAT was mean |
| 04:51.01 | blast007 | all of a sudden a shockwave hits you.. |
| 04:51.10 | PositiveG | lol |
| 04:51.47 | Bulldozer | brlcad: I've got a good valgrind log; getting corruption from the freetype font textures among other things. |
| 04:52.20 | blast007 | Bulldozer: pastebin it and post the link. Then he can read it when he comes back. |
| 04:55.54 | Bulldozer | brlcad: valgrind log: http://bzflag.pastebin.ca/1375436 |
| 04:58.01 | Bulldozer | JeffM: How's the updated app look? |
| 04:58.08 | JeffM | didn't read it |
| 04:58.25 | JeffM | got sucked into some php, and some more work on my short story |
| 04:58.33 | Bulldozer | er, ok :) |
| 04:58.51 | JeffM | has made himself an exceptionaly cheezy CMS for some reason |
| 05:00.16 | Bulldozer | Wordpress :) |
| 05:00.37 | blast007 | wordpress is a blog, not really a CMS ;) |
| 05:00.37 | JeffM | naw, it had to work with my own experimental game login/user system |
| 05:00.44 | JeffM | so I just threw something together |
| 05:01.12 | JeffM | is not a very good web developer |
| 05:01.38 | Bulldozer | Ah nice |
| 05:08.50 | Bulldozer | JeffM: By the way, thanks for the radeonHD tip... |
| 05:08.57 | JeffM | it work better? |
| 05:09.18 | Bulldozer | JeffM: Was quite a bit harder to get working than fglrx, but once it's working, yes. |
| 05:12.07 | a_meteorite | isn't fglrx the proprietary drivers? |
| 05:12.16 | a_meteorite | I'd imagine those would yield better results... |
| 05:12.17 | Bulldozer | a_meteroite: yep |
| 05:12.35 | JeffM | a_meteorite: nope |
| 05:12.38 | JeffM | they are being desuported |
| 05:12.45 | JeffM | ATI release all there crap |
| 05:12.46 | a_meteorite | at last read the open source drivers were leagues behind the proprietary |
| 05:12.50 | a_meteorite | oh wow |
| 05:12.50 | Bulldozer | yep meaning they're proprietary :) |
| 05:12.52 | JeffM | that was DRI |
| 05:12.54 | nightstrike | ATI sucks... and I'm stuck with it |
| 05:12.56 | JeffM | you are like a year old man |
| 05:13.09 | JeffM | nightstrike: my 4850 works just fine |
| 05:13.11 | a_meteorite | does the open source ones do 3d accel? |
| 05:13.14 | JeffM | yes |
| 05:13.19 | a_meteorite | oh nice |
| 05:13.19 | nightstrike | I hav an X1270 radeon :( |
| 05:13.24 | JeffM | like I said, ATI release all there stuff |
| 05:13.32 | Bulldozer | a_meteorite: yeah, I just got it running with full 3d |
| 05:13.35 | JeffM | and is now working with the community on the drivers |
| 05:13.42 | JeffM | radeonHD is the new ONE driver |
| 05:14.00 | a_meteorite | awesome, the amount of drivers for ati was getting overwhelming :) |
| 05:14.06 | JeffM | it was 2 |
| 05:14.08 | a_meteorite | well maybe when I build my rig getting an ati wouldn't be such a bad choice |
| 05:14.15 | a_meteorite | I think there was a 3rd one related to radeonhd |
| 05:14.16 | JeffM | dri and fglrx |
| 05:14.22 | JeffM | yeah that's the new one |
| 05:14.29 | JeffM | that's the one driver that rules them all |
| 05:14.31 | a_meteorite | ah |
| 05:14.50 | nightstrike | and one more thing JeffM, is my application more or less ready? |
| 05:15.08 | JeffM | nightstrike: the otehrs will read it and comment I'm sure |
| 05:15.14 | JeffM | but I personaly have no other changes for you to make |
| 05:15.15 | nightstrike | okies |
| 05:15.21 | nightstrike | ok thanks |
| 05:15.34 | nightstrike | and is the patch I submitted fine enough? |
| 05:15.43 | JeffM | didn't look at it |
| 05:15.48 | nightstrike | ok |
| 05:15.57 | JeffM | is wracking his brain with CSS |
| 05:16.43 | a_meteorite | what are ya working on? |
| 05:16.54 | JeffM | a crapy CMS |
| 05:16.57 | a_meteorite | hheh |
| 05:17.26 | JeffM | all I want to do is make the friggin links not purple :( |
| 05:21.34 | a_meteorite | JeffM: a:visited { color: #xxx; } |
| 05:21.40 | *** join/#bzflag L4m3r (n=l4m3r@bzflag/developer/L4m3r) |
| 05:21.40 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 05:21.45 | JeffM | yeah I got it thanks |
| 05:21.50 | JeffM | I was just doing something stupid |
| 05:21.54 | a_meteorite | heh |
| 05:22.06 | a_meteorite | there's a certain order you should do the different selectors on a tags, but I forget |
| 05:22.15 | JeffM | my problem was more simple |
| 05:22.17 | a_meteorite | (otherwise you may see weirdness if you use :hover and stuff too) |
| 05:22.19 | a_meteorite | ah |
| 05:22.19 | JeffM | upload the right file |
| 05:22.35 | JeffM | I think that's enough of that for one day |
| 05:22.35 | a_meteorite | well that usually helps |
| 05:22.46 | JeffM | it's all working with the login system so that's good |
| 05:23.02 | a_meteorite | is it php based? |
| 05:23.06 | JeffM | yeah |
| 05:23.53 | JeffM | http://www.awesomelaser.com/3dspeeders/ |
| 05:24.44 | a_meteorite | sharks with friggin' awesome lasers? |
| 05:24.51 | a_meteorite | :) |
| 05:25.38 | a_meteorite | interesting project |
| 05:25.45 | JeffM | experiment |
| 05:57.56 | *** join/#bzflag Hideaki (n=chatzill@c-98-203-254-15.hsd1.wa.comcast.net) |
| 05:58.00 | Wyk3d1 | blast007: http://www.rexconsulting.net/ldap-protocol-uidNumber.html |
| 05:58.43 | Wyk3d1 | pretty hackish but apparently the only way .. |
| 06:00.02 | blast007 | hmm |
| 06:08.18 | Wyk3d1 | .. but you need to get phpbb to do it that way too :( |
| 06:09.53 | blast007 | yup, thus the fun part of this project ;) |
| 06:13.05 | Wyk3d1 | do websites that use bzids assume they are numbers or strings ? |
| 06:13.27 | blast007 | I assume they assume numbers ;) |
| 06:36.03 | Not_Gabe_G23 | Hello all, is the config.cfg file documented? |
| 06:36.09 | Not_Gabe_G23 | Like in the wiki? |
| 06:36.26 | JeffM | what are you looking for? |
| 06:36.46 | Not_Gabe_G23 | Everything that can be done |
| 06:36.51 | Not_Gabe_G23 | So I can see what I can do :) |
| 06:36.57 | Not_Gabe_G23 | And I don't have to keep asking you guys |
| 06:37.02 | Not_Gabe_G23 | I could document if you'd like me to |
| 06:37.07 | JeffM | it is different from version to version |
| 06:37.19 | JeffM | you are more then welcome to make a wiki page |
| 06:37.28 | JeffM | but you'll have to clearly say what each version does |
| 06:37.36 | Not_Gabe_G23 | Okay, I could do that.. |
| 06:37.57 | Not_Gabe_G23 | However, is there a kind-of list? |
| 06:38.01 | JeffM | nope |
| 06:38.03 | JeffM | there is the code |
| 06:38.11 | Not_Gabe_G23 | It's all commented then I presume? |
| 06:38.17 | JeffM | oh god no |
| 06:38.33 | JeffM | the list in the code has the same contents as the file we make by default |
| 06:38.46 | JeffM | the optional ones are scattered around the rest of the code |
| 06:39.06 | JeffM | so if you just open your config, it'll contain all non optional items, with there defaults |
| 06:39.43 | Not_Gabe_G23 | Ahh |
| 06:39.53 | Not_Gabe_G23 | and all the optional ones are scattered throughout the code |
| 06:40.13 | JeffM | that would be what I said |
| 06:40.18 | JeffM | there arn't that many IIRC |
| 06:40.22 | Not_Gabe_G23 | How many optional ones would you say there are? |
| 06:40.31 | Not_Gabe_G23 | Answering my quuestion before I ask :D I like |
| 06:41.15 | Not_Gabe_G23 | Thanks :) |
| 06:56.40 | *** join/#bzflag nightstrike (n=nightstr@mnit.ac.in) |
| 07:08.02 | *** part/#bzflag Bulldozer (n=mathew@unaffiliated/kingrobot) |
| 07:12.06 | *** join/#bzflag KingRobot (n=mathew@unaffiliated/kingrobot) |
| 07:12.37 | *** join/#bzflag Upsetter (n=Ups@i577B4882.versanet.de) |
| 08:31.22 | *** join/#bzflag roboter5a (n=rob5a@dslb-092-078-035-167.pools.arcor-ip.net) |
| 08:58.05 | *** join/#bzflag Constitution (n=const@bzflag/developer/Constitution) |
| 09:14.04 | *** join/#bzflag Manu (i=jujibo@freenode/staff/manu) |
| 09:14.16 | *** mode/#bzflag [+v Manu] by ChanServ |
| 09:15.06 | *** join/#bzflag roboter5a2 (n=rob5a@dslb-092-078-035-167.pools.arcor-ip.net) |
| 09:19.28 | *** join/#bzflag roboter5a2 (n=rob5a@dslb-092-078-035-167.pools.arcor-ip.net) |
| 09:20.18 | *** join/#bzflag ruskie (i=ruskie@sourcemage/mage/ruskie) |
| 09:59.51 | *** join/#bzflag MPS_ (n=mathias@p3EE0F67C.dip.t-dialin.net) |
| 10:00.49 | *** join/#bzflag roboter5a (n=rob5a@dslb-092-078-035-167.pools.arcor-ip.net) |
| 10:15.29 | *** join/#bzflag MPS_ (n=mathias@p3EE0F67C.dip.t-dialin.net) |
| 10:24.52 | *** join/#bzflag KingRobot (n=mathew@unaffiliated/kingrobot) |
| 10:38.39 | KingRobot | brlcad: the freetype crash is due to reading memory after it's been free'd |
| 10:40.32 | KingRobot | brlcad: the freetype library gets shut down, freeing all memory related to itslelf |
| 10:41.24 | KingRobot | brlcad: shortly thereafter, a texturefont is checked to be cleaned up |
| 10:41.40 | KingRobot | brlcad: that memory was already freed, probably causing the crash |
| 10:42.29 | KingRobot | brlcad: both frees are called by the destructors on exit, so I think some font/texture isn't getting cleaned up right. |
| 10:43.08 | *** join/#bzflag dexter- (n=whodaman@bzflag/player/Dexter) |
| 10:44.52 | KingRobot | brlcad: trying to track down where it's getting allocated, then i should be able to make a patch |
| 10:44.56 | *** part/#bzflag KingRobot (n=mathew@unaffiliated/kingrobot) |
| 10:55.10 | brlcad | smiles, notes that much had already been determined, wonders if progress has been made .. certainly if there's a patch that results! :) |
| 11:12.22 | Wyk3d1 | blast007: you were quite right about LDAP auth, if you add a user to LDAP, on first login to PHPBB it is added to the database, the problems is that if you register a user in PHPBB it does NOT get added to ldap |
| 11:15.50 | Wyk3d1 | blast007: so registration needs to be added phpbb anyway and ofcourse the atomic nextid method should be used |
| 11:20.54 | brlcad | Wyk3d1: we can shut off / redirect phpbb logins through our own authentication module if needed |
| 11:21.15 | Wyk3d1 | logins work quite fine |
| 11:21.20 | brlcad | even if it's simply to hook through to do our ldap lookup, then pass back to phpbb login |
| 11:21.21 | Wyk3d1 | registration is totally missing |
| 11:22.12 | brlcad | er, that's what I meant, s/logins/registration/ |
| 11:22.38 | Wyk3d1 | how would the redirection be done ? |
| 11:22.48 | Wyk3d1 | by modifying the phpbb code ? |
| 11:23.07 | brlcad | someone clicks on "create a new account", it could simply kick to our own page that does the ldap lookup/add |
| 11:23.22 | brlcad | then just turn off the phpbb add |
| 11:24.26 | brlcad | so there's no way to make a phpbb db account without an ldap one |
| 11:25.29 | Wyk3d1 | you'd still be calling phpbb functions to add the user to its db .. |
| 11:26.01 | brlcad | similarly, that is sort of how the client will need to deal with it as well, needing to talk to either the bzauthd daemon to create the account or (similar to what we do now) talk to said same web page to create an account for in-game registration |
| 11:26.23 | brlcad | you said those get added by phpbb during first login, so let it do its thing |
| 11:27.01 | Wyk3d1 | yes well, it would work that way too just look somewhat weird |
| 11:27.43 | Wyk3d1 | instead of registering at the forum, going to a separate site to do it i mean .. |
| 11:30.01 | Wyk3d1 | i don't know your policy on modifying third party code, but technicly you could just call a function from another file so the the phpbb file only needs one or two extra lines |
| 11:30.01 | brlcad | it wouldn't have to be a separate "site" |
| 11:30.03 | brlcad | just a page |
| 11:30.45 | brlcad | and could be "integrated" into phpbb's appearance or even be a mod to phpbb, it's just hooking into what we need account registration to do |
| 11:31.07 | brlcad | if there's a way to make a phpbb plugin out of it that does it more cleanly, whatever -- same end result |
| 11:31.10 | Wyk3d1 | if you hook into phpbb anyway why not add that one line ? :) |
| 11:31.20 | brlcad | the stand-alone page has other benefits similar to global auth |
| 11:31.22 | Wyk3d1 | and let the normal registration do it.. |
| 11:31.57 | brlcad | if it was just in that one place and could be easily identified, documented, and maintained sure |
| 11:32.17 | brlcad | problem usually is that is lost as soon as the person that did the change stops doing it |
| 11:32.26 | brlcad | which is usually the next upgrade |
| 11:33.20 | brlcad | pita to maintain without being "a proper plugin" that is just dropped in place |
| 11:33.45 | brlcad | same can be said for shutting their normal page off though too, so it still becomes a matter of documenting what needs to be done very clearly |
| 11:35.09 | Wyk3d1 | well what needs to be done is quite clear, you have a username and a password, obtained in some way depending on the phpbb version, and you call that function to send that off to ldap |
| 11:37.10 | brlcad | it has very little to do with what needs to be done, it's how that change (to phpbb) is maintained and managed |
| 11:38.20 | brlcad | given one of the intents of bzauthd is to centralize account registration/lookups/management, that change (even if it's just "add this one-liner to this phpbb file") could be documented there as well as in a readme in a site readme file or something too |
| 11:39.31 | brlcad | the way we leverage phpbb's tables for account data and getting tokens is technically "quite clear" too, but a royal pita to maintain and change, especially across upgrades of phpbb |
| 11:40.50 | brlcad | so much of a pain that it's almost the main point of changing over to an authentication daemon over an ldap directory |
| 11:43.12 | Wyk3d1 | doing the registration on a separate page could be harder to maintain i think |
| 11:43.15 | brlcad | on that note.. this would be an interesting tie-in: http://217.160.138.71/michael/wiki/images/a/aa/Auth_phpBB.txt |
| 11:43.25 | *** join/#bzflag black_pearl (i=xyq@h1342075.stratoserver.net) |
| 11:44.02 | Wyk3d1 | i.e adding a call in a phpbb function seems harder than making a call to some phpbb function |
| 11:44.15 | Wyk3d1 | *seems easier |
| 11:45.41 | Wyk3d1 | the arguments could change to some specific form as processed internally, while inside a php function it will always boil down to having easy access to user/pass .. i think |
| 11:46.01 | black_pearl | what exactly is required to be done in the "modularization of openGL logic" |
| 11:46.59 | brlcad | Wyk3d1: eh, "adding a call in a phpbb function" is the same as "making a call to some phpbb function" (which has to be added somewhere) |
| 11:47.31 | brlcad | I was thinking more like just commenting out that feature on phpbb, or adding a simple redirect on a url |
| 11:47.33 | Wyk3d1 | i don't know .. that phpbb function could have arguments you don't care about |
| 11:47.54 | brlcad | likewise, the phpbb account creation page may very well be insufficient |
| 11:47.58 | Wyk3d1 | while inside the function, you can choose to only touch things you need |
| 11:48.26 | brlcad | you seem to be fixed on being in a function or not... |
| 11:48.34 | Wyk3d1 | a simple redirect is not so simple |
| 11:48.49 | Wyk3d1 | you redirect to something that needs to know php internals to add the user to the php db |
| 11:49.07 | brlcad | no, you already said that happens automatically |
| 11:49.13 | brlcad | so let it happen automatically on login |
| 11:50.16 | brlcad | not shutting off phpbb logins, just registration .. and I wouldn't go that route if it's easy enough to make a phpbb module that does our registration |
| 11:52.54 | black_pearl | what exactly is required to be done in the "modularization of openGL logic" |
| 11:53.05 | brlcad | the point is really just to separate our change from phpbb as much as possible -- phpbb plugin that talks to ldap or bzauthd directly being top-pick, followed by redirect (e.g. url rewrite on "ucp.php?mode=register"), followed by separate page or phpbb mod (similar maintenance burdens) |
| 11:53.16 | brlcad | black_pearl: you have to be more patient than that |
| 11:53.21 | black_pearl | sorry |
| 11:56.35 | brlcad | black_pearl: you're supposed to determine what is "exactly" required actually -- that's the work :) the basic idea, though, is to refactor the codebase so that there's not opengl calls spread throughout the code |
| 11:57.32 | brlcad | so that they are happening in just a handful of places like our external dependencies (ftgl), src/3D, and src/ogl |
| 11:58.25 | black_pearl | so instead of opengl calls we need to make calls to these dependencies which do the rest.... |
| 11:58.34 | brlcad | one way to achieve that, for example, could be to make a class or set of classes that take instructions on what needs to be drawn |
| 11:58.52 | black_pearl | i am getting it |
| 11:59.04 | brlcad | like "display this mesh", then that class would formulate a display list and display it or whatever |
| 12:00.13 | black_pearl | would the following process be right.....1)make the required class calling opengl functions 2) |
| 12:00.16 | brlcad | things get a little more tricky with refactoring state management to be efficient, but same basic idea is to get most of the opengl state management into one place or just a few places as well |
| 12:00.30 | black_pearl | add header to required places |
| 12:00.48 | brlcad | right now some random piece of code might glDisable some feature that is later required by some other feature, but only when certain options are set, etc |
| 12:00.49 | black_pearl | 3) and finally alter the current opengl calls |
| 12:01.10 | brlcad | eh, you'll have to do it a lot more incrementally than that |
| 12:01.16 | brlcad | not big chunk phases |
| 12:01.22 | brlcad | very very little iterative steps |
| 12:01.31 | brlcad | refactor all of the opengl in this file |
| 12:01.38 | brlcad | then move on to the next file |
| 12:01.41 | brlcad | etc |
| 12:01.51 | black_pearl | ok |
| 12:02.32 | black_pearl | but the should the process remains same ,(on a smaller phase) |
| 12:03.02 | brlcad | sure |
| 12:03.14 | brlcad | just that smaller phase is really critical for review and testing purposes |
| 12:03.43 | brlcad | this can't disrupt day-to-day development of anyone else, and there needs to be high confidence that bugs aren't being introduced during the refactoring |
| 12:03.57 | brlcad | especially with all of the state management changes |
| 12:04.19 | brlcad | what you should eventually find out is that there are classes of gl operations that get performed |
| 12:04.22 | brlcad | display this mesh |
| 12:04.24 | brlcad | draw this texture |
| 12:04.35 | brlcad | write this text |
| 12:04.51 | black_pearl | right |
| 12:05.01 | black_pearl | can u please suggest a starting point |
| 12:05.20 | brlcad | those will get refactored piece by piece into logical groups (perhaps those are your classes, or help drive your classes) |
| 12:05.21 | black_pearl | i could then make a patch and send for review |
| 12:05.25 | brlcad | http://trepan.bzflag.bz/gl-files.txt |
| 12:05.43 | brlcad | that's every place an opengl call is being made .. |
| 12:06.00 | brlcad | your patch doesn't have to relate to your project |
| 12:06.14 | black_pearl | ok |
| 12:06.47 | brlcad | in fact, it'd probably be desirable to do something "similar" but not for your project, like refactor something else in the code that simplifies or organizes something |
| 12:07.09 | black_pearl | like |
| 12:07.16 | brlcad | bug fixes are always good though as they tend to show more how capable one is at understanding code |
| 12:07.51 | black_pearl | ok |
| 12:08.25 | brlcad | wanders off |
| 12:10.13 | *** join/#bzflag epyon (n=epyon@static-78-8-146-214.ssp.dialog.net.pl) |
| 12:11.14 | *** join/#bzflag roboter5a (n=rob5a@dslb-092-078-035-167.pools.arcor-ip.net) |
| 12:17.47 | *** join/#bzflag meglo (n=meglo@unaffiliated/meglo) |
| 12:26.13 | *** join/#bzflag Upsetter (n=Ups@i577B56F0.versanet.de) |
| 12:31.57 | *** join/#bzflag black_pearl (i=kijt@h1342075.stratoserver.net) |
| 12:33.16 | *** join/#bzflag dexter- (n=whodaman@bzflag/player/Dexter) |
| 12:42.22 | *** join/#bzflag Abominable__ (n=Abominab@cpe-071-077-060-196.nc.res.rr.com) |
| 12:58.50 | *** join/#bzflag destiny_sh (i=ullhiuk@h1457496.stratoserver.net) |
| 12:59.56 | destiny_sh | do we have to submit the patch file regarding the proposals or the bugs listed in your web page??? |
| 13:02.47 | *** part/#bzflag destiny_sh (i=ullhiuk@h1457496.stratoserver.net) |
| 13:03.04 | *** join/#bzflag destiny_sh (i=ullhiuk@h1457496.stratoserver.net) |
| 13:04.17 | destiny_sh | i have read the proposals and the bug list on the wiki page .....so do we have to submit the patch file regarding the proposals or the bugs |
| 13:04.19 | destiny_sh | ? |
| 13:05.59 | *** join/#bzflag kumarabhi (n=chatzill@115.241.119.74) |
| 13:17.30 | *** join/#bzflag destiny_sh (i=grxngpd@h1457496.stratoserver.net) |
| 13:19.37 | *** join/#bzflag SpazzyMcGee (n=SpazzyMc@bzflag/contributor/SpazzyMcGee) |
| 13:24.23 | *** join/#bzflag Swigg (n=Default@bzflag/player/Swigg) |
| 13:36.11 | *** join/#bzflag black_pearl (i=mbgkx@h1342075.stratoserver.net) |
| 14:16.35 | *** join/#bzflag MPS_ (n=mathias@p57B2179E.dip0.t-ipconnect.de) |
| 14:28.15 | *** join/#bzflag TD-Linux (n=wheeeeee@about/essy/indecisive/TD-Linux) |
| 14:33.38 | *** join/#bzflag alexbanceanu (n=alexbanc@p5.eregie.pub.ro) |
| 14:33.59 | alexbanceanu | hey |
| 15:06.13 | alexbanceanu | i wanted to let you know i added an application for gsoc in the network testing project and updated the opengl modularization one. Also i've been away this weekend, has anything else happened around here gsoc-whise? |
| 15:09.15 | *** join/#bzflag black_pearl (i=fzej@h1342075.stratoserver.net) |
| 15:22.22 | *** join/#bzflag spldart (n=spldart2@bzflag/contributor/spldart) |
| 15:22.23 | *** mode/#bzflag [+v spldart] by ChanServ |
| 15:23.32 | *** join/#bzflag LongDon (n=LongDon@host-091-097-002-144.ewe-ip-backbone.de) |
| 15:24.20 | *** part/#bzflag LongDon (n=LongDon@host-091-097-002-144.ewe-ip-backbone.de) |
| 16:13.46 | brlcad | alexbanceanu: thanks and no |
| 16:18.46 | *** join/#bzflag roboter5a (n=rob5a@dslb-092-078-182-083.pools.arcor-ip.net) |
| 16:23.26 | *** join/#bzflag JeffM (n=Jeff@bzflag/projectadmin/JeffM) |
| 16:23.27 | *** mode/#bzflag [+o JeffM] by ChanServ |
| 16:39.13 | *** join/#bzflag black_pearl (i=mom@h1342075.stratoserver.net) |
| 16:40.40 | *** join/#bzflag Pimpi_ (n=frank@gondolin.pimpi.org) |
| 16:47.12 | *** join/#bzflag Will07c5 (n=William@c-67-173-127-196.hsd1.il.comcast.net) |
| 16:50.44 | CIA-11 | BZFlag: 03Mirtti 07http://my.bzflag.org * r5627 10/w/Box: moikka |
| 16:52.16 | CIA-11 | BZFlag: 03JeffM2501 07http://my.bzflag.org * r5628 10/w/Box: Undo revision 5627 by [[Special:Contributions/Mirtti|Mirtti]] ([[User talk:Mirtti|Talk]]) |
| 17:05.28 | JeffM | reads more student applications |
| 17:09.30 | Winny | id lyke 2 b a studant 4 gs0c b/c i cn rite in vb |
| 17:10.07 | JeffM | you can be |
| 17:10.09 | JeffM | just not here ;) |
| 17:11.27 | Winny | hehe |
| 17:18.46 | *** join/#bzflag nightstrike (n=nightstr@mnit.ac.in) |
| 17:20.00 | steerpike | ok.. high jump flag? |
| 17:21.29 | JeffM | low gravity, allready in 3.0 |
| 17:22.13 | steerpike | but a specific flag just for it? |
| 17:22.17 | JeffM | yeah |
| 17:22.18 | JeffM | LG |
| 17:22.20 | JeffM | it's a flag |
| 17:22.30 | steerpike | i see |
| 17:22.55 | steerpike | d'oh, i'm still on 2.0.8 |
| 17:23.09 | JeffM | that'd be an old release version |
| 17:23.14 | JeffM | in the dead branch |
| 17:36.23 | alexbanceanu | hey, i wanted to let you know i added an application for gsoc in the network testing project and updated the opengl modularization one. Also i've been away this weekend, has anything else happened around here gsoc-whise? (like that gaming sesion) |
| 17:37.05 | blast007 | hasn't been a gaming session yet |
| 17:37.53 | JeffM | most of the apps have comments now |
| 17:37.57 | JeffM | all but one I think |
| 17:38.44 | *** join/#bzflag L4m3r (n=l4m3r@bzflag/developer/L4m3r) |
| 17:38.44 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 17:39.04 | JeffM | the one I don't want to look at :) |
| 17:39.25 | alexbanceanu | so u don't want to look at my network testing enviornment? |
| 17:39.29 | JeffM | nope |
| 17:39.33 | alexbanceanu | why not? |
| 17:39.50 | JeffM | I don't know much on the subject and personaly I don't see why we need a project like that |
| 17:40.06 | JeffM | so I'd rather not review it in case I get any accedental negitives in it for those reasons |
| 17:40.09 | JeffM | not fair to you, etc.. |
| 17:40.37 | JeffM | so I'll be abstaining from that one |
| 17:40.40 | alexbanceanu | ok. well u all said to apply for things i find interesting, so i did :) |
| 17:40.47 | JeffM | true |
| 17:40.58 | JeffM | I'm not the only mentor, or even the only org admin |
| 17:41.02 | JeffM | so it'll be fine |
| 17:41.07 | JeffM | I just don't want to taint it |
| 17:41.58 | alexbanceanu | lol |
| 17:43.12 | JeffM | if you wanted to add something about what the advantages and common uses of that tool would be, that would help |
| 17:43.33 | JeffM | basicly what it will do for the community, specificly |
| 17:44.29 | alexbanceanu | the lol was for the 'taint' bit. yeah, i think i'll add those to my app |
| 17:45.01 | JeffM | is the tool mostly a developer app? or is it something users will run too? |
| 17:45.05 | JeffM | if so, why? |
| 17:45.34 | alexbanceanu | want me to answer here or on my application? |
| 17:45.46 | JeffM | up to you |
| 17:45.59 | JeffM | I'm mostly just curious about what the thing is suposed to do |
| 17:46.02 | JeffM | I jsut don't "get" it |
| 17:46.02 | alexbanceanu | i pick both |
| 17:46.19 | alexbanceanu | i think of it as both for users and for developers |
| 17:46.43 | alexbanceanu | users can use it to see theyr network status |
| 17:46.43 | JeffM | and what info does it give us? |
| 17:47.11 | alexbanceanu | and developers can use it to see those, and also to configure a network with lag and loss and see ho the game behaves |
| 17:47.21 | JeffM | why does it have to be a seperate proxy? |
| 17:47.26 | JeffM | why not build it into the base networking lib |
| 17:47.30 | alexbanceanu | it can give whatever info you want. i was thinking of packets sent, packets lost and lag |
| 17:47.35 | JeffM | and then for users, give them display stats |
| 17:47.50 | JeffM | and for devs, let them enable the lag options |
| 17:48.02 | JeffM | the game does, packetloss and lag now |
| 17:48.05 | alexbanceanu | if you [make it separate you can buiold it separate and then integrate it into the app if the need arises |
| 17:48.24 | JeffM | what advantage does it have beening a seperate app? |
| 17:48.28 | JeffM | are there ANY? |
| 17:48.43 | alexbanceanu | its easyer to develop |
| 17:48.46 | alexbanceanu | and then integrate |
| 17:48.51 | alexbanceanu | easier* |
| 17:48.53 | JeffM | how? you have to dupe the code that we have in the server and client? |
| 17:49.20 | JeffM | you'll also have to make it build on all the existing clients |
| 17:49.25 | alexbanceanu | i was thinking of a separate proxy, that doesnt need to actually touch the server or client |
| 17:49.40 | JeffM | so you want to reimplemente all our protcooll parsers? |
| 17:49.45 | alexbanceanu | i was thinking of using something like squid |
| 17:49.48 | JeffM | and a network stack |
| 17:49.51 | alexbanceanu | nope |
| 17:50.13 | alexbanceanu | a simple proxy server, unrelated to the game, that does a client-server relationship |
| 17:50.14 | blast007 | it wouldn't need to know the protocol. it's just going to handle the packets. |
| 17:50.19 | alexbanceanu | yes |
| 17:50.25 | JeffM | then why would you EVER integrate that into the game? |
| 17:50.33 | JeffM | since it'd a proxy |
| 17:50.43 | JeffM | it'd be stupid to have the game open 2 sockets |
| 17:50.44 | alexbanceanu | i dont know. i didn't think you should, but i mentioned that it's possible |
| 17:50.45 | JeffM | one to itself |
| 17:51.03 | JeffM | from a usability standpoint I see no advantage to a sepeprate app |
| 17:51.06 | JeffM | but that's me |
| 17:51.17 | JeffM | the features you are describin are partaly implemented in the game |
| 17:51.18 | alexbanceanu | i was planning to develop it as a separate app |
| 17:51.24 | JeffM | so why not just extend them? |
| 17:51.35 | alexbanceanu | oppening 2 sockets is not that big a problem |
| 17:51.48 | JeffM | no, but it's stupid just to play a game and get packetloss ;) |
| 17:52.00 | JeffM | it dosn't make our code any cleaner or saner |
| 17:52.08 | alexbanceanu | because i think it's easyer to use the linux routing to sqitch to the proxyy. also, the proxy will add some lag, mayybe a user will not want to activate it |
| 17:52.17 | blast007 | I'd just think that would lead to more problems later |
| 17:52.29 | JeffM | so what do windows users use? |
| 17:52.35 | alexbanceanu | windows routing |
| 17:52.42 | alexbanceanu | a bit harder to script but still works |
| 17:52.43 | JeffM | so to use your tool I have to set a route on my machine? |
| 17:52.47 | JeffM | no user will EVER do that |
| 17:52.55 | JeffM | I'll never do that |
| 17:52.56 | alexbanceanu | i can make it automatically |
| 17:53.09 | blast007 | I think you're missing the point ;) |
| 17:53.20 | JeffM | if it was built into our networking system it woudl always be automatic ;) |
| 17:53.30 | JeffM | but I see you are going to stick to your guns |
| 17:53.40 | JeffM | thanks for giving me some overview of it |
| 17:53.42 | alexbanceanu | the connection of the proxy to the game is not essential. it can be through routing, or direct memory if it's built into the game |
| 17:53.46 | JeffM | I think I can review it now |
| 17:54.44 | alexbanceanu | plus, i dind't think it was intended for user-use, but for testing the functionality of the game in various network conditions |
| 17:55.03 | JeffM | then again, why not build it in as compile options that the devs can turn on? ;) |
| 17:55.23 | JeffM | if the only thing having a proxy does is make your job simpler, that's not a good enough reason |
| 17:55.36 | JeffM | lazy dev should not make it harder for all other devs ;) |
| 17:55.36 | Not_Gabe_G23 | Another question - is it possible to remove the text at the top when someone says something in bzflag? |
| 17:55.54 | blast007 | Not_Gabe_G23: sure, it's open-source :) |
| 17:55.54 | JeffM | Not_Gabe_G23: anything is possible, you just have to write the code for it |
| 17:55.58 | alexbanceanu | i did say that the option for the server controling the losss/lag that the proxy can induce should be made a compile option so the release code cant be controlled by a server |
| 17:56.05 | Not_Gabe_G23 | Meh |
| 17:59.20 | JeffM | alexbanceanu: I've added a comment to your proposal, that should let you edit it if you want. |
| 17:59.30 | JeffM | I still don't see the point, but maybe I'm missing something |
| 17:59.39 | JeffM | I don't think I am, but hey maybe I am :) |
| 18:00.16 | alexbanceanu | a scenario which i see as one where having a controlable testing enviornment is important is seeing how syncronization occurs between clients and server when the loss/lag is high or has high spikes; |
| 18:00.27 | JeffM | alexbanceanu: that I understand |
| 18:00.38 | JeffM | I simply don't see WHY it needs to be a seperate tool |
| 18:00.51 | JeffM | if I can do that testing using the client and the server network code, GREAT |
| 18:01.24 | JeffM | and if it's integrated, I do not see why the baseline code needs to do a proxy step, that just seems very stupid from a design standpoint |
| 18:01.40 | JeffM | it makes the bzflag network code much harder to follow |
| 18:01.51 | JeffM | and it's already rather ugly |
| 18:02.48 | alexbanceanu | ah, i read your comment. what i see as a benefit in using this as an outside app is that it totally neglects the current networking scenario. this would be completely separated; and that's how i'd do it even if it were integratedd inside bzflag. the only reason i'd change or use the network code is if i were doing tracking of data sent over the wire, which i didn't really think was neccesary (is it?) |
| 18:03.22 | JeffM | well I'll tell you this, I'll fight you building a proxy server into the code |
| 18:03.28 | JeffM | but we'll see what others say |
| 18:03.47 | JeffM | I don't want a proxy mechanism in the baseline design |
| 18:03.52 | alexbanceanu | but what do you see as the big disadvantage of a proxy-like approach to this problem? |
| 18:04.09 | JeffM | it is not easy to use |
| 18:04.15 | JeffM | and I can't see it offering any advantage |
| 18:04.30 | alexbanceanu | plus, if you want to be able to induce lagg/loss, wouldnt a proxy be the easyest and less intrusive to network ocde way of doing it? |
| 18:04.35 | JeffM | no |
| 18:04.50 | JeffM | thrad the networking system ( something we have to do anyway) and delay the packets in game |
| 18:04.53 | JeffM | it's trivial |
| 18:05.02 | JeffM | most other real network libs do it already |
| 18:05.13 | alexbanceanu | thrad =? |
| 18:05.15 | JeffM | thread |
| 18:06.13 | alexbanceanu | but what you're saying is more of a conceptual difference, the actual code might look the same in both implementations |
| 18:06.29 | JeffM | there would be similar aspects yes |
| 18:06.36 | JeffM | but it would be a cleaner design |
| 18:06.46 | JeffM | yes I agree there are multiple ways to get the same results |
| 18:06.53 | JeffM | we want the one that is most maintainable |
| 18:07.05 | JeffM | and since we have to thread the networking system anyway, why not make it all use one system |
| 18:07.19 | JeffM | I'd hate to have to wade though a treaded network system, then a proxy |
| 18:07.20 | alexbanceanu | oh i'd love to thread the networking system |
| 18:07.38 | alexbanceanu | but that might be too much for one summer |
| 18:07.39 | JeffM | some of the work has already been done to get it ready for threading |
| 18:07.42 | *** join/#bzflag epyon|afk (n=epyon@static-78-8-146-214.ssp.dialog.net.pl) |
| 18:07.57 | JeffM | outbound server messages are allready qued out |
| 18:07.58 | alexbanceanu | openMP/mpi or pthreads? |
| 18:08.03 | JeffM | no threads yet |
| 18:08.16 | alexbanceanu | but which were you thinking of going for |
| 18:08.20 | JeffM | just getting the rest of the code not to care if the message goes out now or later |
| 18:08.34 | JeffM | whatever the rest of the code uses for threads |
| 18:08.47 | JeffM | the threading implementation is so minor in the entire design |
| 18:08.53 | alexbanceanu | and yes, i agree, in the case you thread the network lib, and it's all async, then the things the proxy has to add would be easy to implement in this case |
| 18:08.57 | JeffM | the big part is getting the code ready |
| 18:09.37 | JeffM | alexbanceanu: that's my point, I'm trying to say that there are other designs that would make the code better ;) but you focused on the proxy so much that it seems to have blinded you to others |
| 18:09.56 | JeffM | it dosn't sound like the proxy tool will do much other then add lag, and track packet status |
| 18:10.05 | JeffM | that sounds like a one week project in C# to me |
| 18:10.16 | JeffM | so I dont' think it would be too hard to thread the networking system in that timeframe |
| 18:10.48 | JeffM | you save the time of having to work in other tools, and do all this automatic routing |
| 18:11.04 | JeffM | and the guts of just getting a build system that works on all our OSs |
| 18:11.05 | alexbanceanu | yes but then there'd be no proxy involved at all, we'd just put the threads to spinwait a bit before sending the data, along with the network statistics |
| 18:11.14 | JeffM | EXACTLY |
| 18:11.43 | JeffM | no proxy == good IMHO |
| 18:11.54 | JeffM | then we simply have a decent networking system that can just DO all this |
| 18:12.00 | JeffM | with no extra layer of code |
| 18:12.05 | JeffM | much more maintainable |
| 18:12.13 | alexbanceanu | yeah, i understand what you're saying |
| 18:12.16 | JeffM | and we get the advantages of a threaded networking system |
| 18:12.20 | JeffM | WIN WIN |
| 18:12.45 | JeffM | that has a much more direct impact on the quality of the software even if people arn't doing induced lag |
| 18:12.53 | alexbanceanu | i'll review my proposal a bit, though i don't know how deep in the project explanation i can go with a threaded ideea as i don't really know that much about your networking code |
| 18:13.34 | JeffM | well it kinda bothers me that you were talking about a tool to test our network code, and you don't know much about the networking code ;) |
| 18:14.02 | JeffM | my other big thing against your current design is, that I belive there are combinations of third party tools out there that will do this now |
| 18:14.16 | JeffM | so all you are doing, it sounds like, is reinventing the wheel for us |
| 18:14.17 | alexbanceanu | i wasnt talking about thesting your code, but thesting how it works in a network. at least that was my perception about waht you wantedd out of it. |
| 18:14.19 | JeffM | to me at least |
| 18:14.45 | JeffM | yeah that's the kicker, there are generic network testing tools out there |
| 18:14.59 | JeffM | the only avantage for a tool made just for us, would be if it did things JUST for us that no other tool can do |
| 18:15.11 | *** join/#bzflag kumarabhi_ (n=chatzill@115.241.119.74) |
| 18:15.16 | JeffM | and to me that means stuff like packet inspection |
| 18:15.24 | alexbanceanu | yeah |
| 18:15.27 | JeffM | see how many update packets are lost, compared to shot packets etc... |
| 18:15.31 | alexbanceanu | that was what i was typing now |
| 18:15.34 | JeffM | see how far your DR is off |
| 18:15.42 | JeffM | and all that is done better in game :) |
| 18:16.16 | L4m3r | ingame lag troubleshooter... I like it :P |
| 18:16.30 | alexbanceanu | i dont think we're there yet |
| 18:16.43 | alexbanceanu | more like ingame lag maker :P |
| 18:16.58 | JeffM | well I think you undestand my points now. Thanks for discussing it. I understand it a bit better now. |
| 18:17.21 | alexbanceanu | btw, do you remember my other proposal? about splitting the opengl part? |
| 18:17.26 | JeffM | yeah |
| 18:17.32 | JeffM | I commented on that one |
| 18:17.47 | CBG | ~alexbanceanu++ |
| 18:17.54 | JeffM | IIRC the API needed a bit more fleshing out, just in an overview sense |
| 18:18.13 | alexbanceanu | you ask me to detail the API. i did add a region to explain it better, but i think talking about it live is a bit more usefull |
| 18:18.15 | JeffM | just somthing like how you'd expect the breakdown to go in a very high level picture |
| 18:18.53 | alexbanceanu | i wanted to have like 2 major bits : methods to create the scene, and methods to alter it |
| 18:19.01 | JeffM | why alter it? |
| 18:19.07 | JeffM | isn't that what the game is for? |
| 18:19.29 | alexbanceanu | i meant when the logic decides that the tank goes forward, you call a "go forward" opengl method |
| 18:19.34 | JeffM | or do you just mean methods that are called to update the state in the sceene? |
| 18:19.38 | alexbanceanu | instead of redrawing the whole scene urself |
| 18:19.39 | JeffM | ok |
| 18:19.46 | JeffM | yeah basic accessors |
| 18:19.59 | alexbanceanu | also i wanted to apply this for effects and such |
| 18:20.07 | JeffM | that's sort of what we do now |
| 18:20.27 | JeffM | there is a scene class it just sets everyones postion each frame |
| 18:20.34 | JeffM | and draws what is vissable |
| 18:20.52 | JeffM | then the rendernodes are called |
| 18:21.03 | alexbanceanu | but i understand that the drawing is not done centralized |
| 18:21.06 | JeffM | the problem is those rendernodes are ALL over the place |
| 18:21.06 | JeffM | yeah |
| 18:21.16 | alexbanceanu | also i wanted to make these calls opengl-unspeciffic |
| 18:21.18 | trepan | rendernodes aren't the main problem |
| 18:21.21 | JeffM | but there is a somehwat of a standardised way that we access them |
| 18:21.25 | trepan | they're almost all in geometry/ |
| 18:21.38 | JeffM | the problem is they are tied into obstacles |
| 18:21.45 | alexbanceanu | to make them swapable with some other technology should you ever chose to do so |
| 18:21.49 | trepan | JeffM: how so? |
| 18:22.01 | JeffM | trepan: no I'm mistaken |
| 18:22.08 | JeffM | they are tied into scneenenodes |
| 18:22.15 | trepan | as it should be |
| 18:22.15 | JeffM | is not fully awake |
| 18:22.18 | JeffM | yeah |
| 18:22.39 | JeffM | IIRC obstacle still needed GL for something, but I can't remember what it was |
| 18:22.49 | alexbanceanu | oh, btw a question i should have asked earlier; what countries are you guys from? |
| 18:23.02 | trepan | JeffM: could be, didn't think so (as they can be used be the server) |
| 18:23.13 | JeffM | trepan: yeah but the server links to GL cus of it |
| 18:23.16 | trepan | s/used be/used by/ |
| 18:23.16 | JeffM | unless it was fixed |
| 18:23.26 | JeffM | it was a linking/include thing |
| 18:23.36 | JeffM | I think the code was never called on the server, but it was still built in |
| 18:23.47 | trepan | ldd bzfs | grep -i gl => '' (must have been fixed) |
| 18:23.51 | JeffM | there was a big discussion about it with the makefile people |
| 18:23.54 | JeffM | cool |
| 18:23.59 | JeffM | then that should make it simpler |
| 18:24.35 | trepan | the scenenode/rendernode system isn't great, but it is encapsulated |
| 18:24.45 | JeffM | alexbanceanu: one thing you should know is that, we will maitain a version of the world with all tanks and shots for collsion detection no mater what |
| 18:24.47 | trepan | it's the rest of it that's "strewn about" |
| 18:24.59 | JeffM | it woudl make sense that you be able to fill in your drawing sceene from that system |
| 18:25.12 | JeffM | then do the backgound and hud etc.. |
| 18:25.14 | trepan | mostly the gui and environment, iirc |
| 18:25.18 | JeffM | yeah |
| 18:25.29 | JeffM | the guts of drawing tanks and shots and buildings shouldn't be too bad |
| 18:25.30 | trepan | and a lot of that just needs to be moved |
| 18:25.40 | trepan | ex: move the HUD* files ;-) |
| 18:26.06 | JeffM | tying the hud drawing to bzdb cache could be cool |
| 18:26.15 | JeffM | then it would not need any player or client code :) |
| 18:27.16 | JeffM | you'd still need scoreboard info |
| 18:27.23 | trepan | lua can do it ;-) |
| 18:27.30 | JeffM | that's true |
| 18:27.37 | JeffM | perhaps we should just redo the hud in lua |
| 18:27.44 | JeffM | and provide a default script |
| 18:27.52 | JeffM | then it'd be customsizable |
| 18:28.00 | trepan | it's just missing the server list call-in/outs, and some other minor stuff |
| 18:28.06 | JeffM | it would make the GL split simpler |
| 18:28.25 | JeffM | as long as we provide some kind of API to lua to draw hud elements |
| 18:28.39 | trepan | have LuaServerList started, got sidetracked on to something cooler :) |
| 18:29.04 | JeffM | heh |
| 18:29.08 | trepan | JeffM: i would suggest not having engine hud elements |
| 18:29.11 | trepan | one sec |
| 18:29.31 | JeffM | ok, well even lua code to draw the widgets |
| 18:29.33 | JeffM | that's fine |
| 18:29.41 | JeffM | just some way to easaly draw "standard" looking things |
| 18:29.46 | JeffM | who cares where it's implemented |
| 18:30.02 | trepan | JeffM: was looking for some SpringRTS screenshots ... |
| 18:30.23 | JeffM | I'd just not want the hud drawing code strewn with GLVErtex calls |
| 18:30.38 | JeffM | like guiDrawBox(x,y,h,v) etc.. |
| 18:30.41 | JeffM | thatd be cleaner |
| 18:30.48 | JeffM | you could overide it of course |
| 18:30.51 | trepan | easily done in lua |
| 18:30.54 | JeffM | cool |
| 18:31.26 | trepan | (and gl has glRect()) :) |
| 18:31.30 | JeffM | that's all I'd want just some set of common calls that can draw elements 'our way' so that when people mod the UI they can still make it look like our stuff |
| 18:31.47 | JeffM | and then if they want to theme it, they just change those element calls to draw differently |
| 18:31.53 | trepan | also added gl.TexRect(), sets up the texcoords as well |
| 18:32.28 | JeffM | needs to look at TaoLua soon, after he gets his models read in |
| 18:34.52 | trepan | continues to treat bz as a bloated platform for writing a lua modeller ;-) |
| 18:35.53 | JeffM | hmm I wonder if OpenTK has model loaders allready |
| 18:36.12 | trepan | (tbh, i don't want to have the same limitations as wings3d fellas, more will be done in c++) |
| 18:36.12 | JeffM | Axiom did, but it was such a pain to get running on non-windows platforms |
| 18:50.18 | *** join/#bzflag Cygal (n=cygal@zancdar.eu) |
| 18:51.43 | *** join/#bzflag kumarabhi_ (n=chatzill@115.241.234.181) |
| 19:03.30 | *** join/#bzflag KingRobot (n=mathew@unaffiliated/kingrobot) |
| 19:16.02 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |
| 19:26.04 | *** join/#bzflag kumarabhi (n=chatzill@115.241.106.80) |
| 19:39.11 | *** join/#bzflag KingRobot (n=mathew@unaffiliated/kingrobot) |
| 19:40.31 | joevano | ~bzflist |
| 19:44.33 | blast007 | hmm.. the list in game was/is showing 16/15 players for red on MW2 ;) |
| 19:45.11 | blast007 | guess it's only 15 now |
| 19:46.56 | *** join/#bzflag me1 (n=ausom@bzflag/player/Me1) |
| 19:49.17 | *** join/#bzflag bier (n=bier@p54A54370.dip.t-dialin.net) |
| 19:55.28 | *** join/#bzflag Think_Differentl (n=fatass@bzflag/player/ThinkDifferent) |
| 20:03.23 | *** join/#bzflag hobbsc (n=hobbsc@li25-128.members.linode.com) [NETSPLIT VICTIM] |
| 20:06.21 | *** join/#bzflag Abominable____ (n=Abominab@cpe-071-077-060-196.nc.res.rr.com) |
| 20:08.59 | *** join/#bzflag KingRobot (n=mathew@unaffiliated/kingrobot) |
| 20:21.00 | Cygal | hi |
| 20:21.05 | Cygal | I'm working on the "Client is disconnected with no message when the -botsPerIP parameter is exceeded" bug |
| 20:21.22 | Cygal | In fact, a message *is* sent, but to the bot, no to the player who asked for it, so it gets lost |
| 20:22.08 | Cygal | The fix is simple : send to playerData->botHost instead of playerData (playerData referring to the bot, in bzfs.cxx:2577) |
| 20:22.19 | Cygal | But the message will be sent one time per bot. Is this acceptable or should I change the protocol to change that? |
| 20:22.23 | Cygal | (for exa |
| 20:22.23 | Cygal | mple, tell "I'm sending 10 bots" before, or saying to the client "one bot was refused, no need to send anything more", or even asking before |
| 20:22.26 | Cygal | hand the number of allowed bots) |
| 20:24.29 | Wyk3d1 | brlcad: based on the source code, what i've heard from others and read on the net so far there doesn't seem to be an easily pluggable way to do custom registration in phpbb .. making an apache-based redirection on the registration page then redirecting to the auth page of the forum seems to be the least phpbb dependent method .. if you upgrade the forum software, assuming it will work in the same way with the tables being generated on first login, only |
| 20:28.06 | KingRobot | pings brlcad |
| 20:32.20 | *** join/#bzflag Abominable_____ (n=Abominab@cpe-071-077-060-196.nc.res.rr.com) |
| 20:33.11 | *** join/#bzflag dexter- (n=whodaman@bzflag/player/Dexter) |
| 20:34.16 | dexter- | what's been up with the list server lately? |
| 20:34.23 | dexter- | something at sagonet's end? |
| 20:34.41 | me1 | yup |
| 20:34.51 | me1 | "The network issue has been resolved. There was a major DDoS attack that flooded Sago's bandwidth. The IPs that were being attacked have been null routed which stopped the DDoS attack." |
| 20:35.05 | dexter- | ya.. |
| 20:35.41 | dexter- | guess there's another one.. |
| 20:36.22 | me1 | oh, i thought you were talking about yesterday? |
| 20:37.05 | KingRobot | Any devs on that are familiar with the current state implementation and the use of singletons? |
| 20:37.27 | brlcad | KingRobot: several are, question? |
| 20:37.51 | Bulldozer | brlcad - I think I've found the freetype crash problem. |
| 20:38.01 | brlcad | do tell |
| 20:38.06 | dexter- | me1, it's happening again |
| 20:38.22 | brlcad | dexter-: that was yesterday, it's been fine today |
| 20:38.38 | me1 | I can connect to the forums fine, but i also do not see the list |
| 20:38.44 | me1 | ~bzflist |
| 20:38.54 | dexter- | brlcad, as far as I know, it's been down for about last 20 minutes |
| 20:38.54 | dexter- | or so |
| 20:38.56 | Bulldozer | as near as I can tell, the singletons deallocate memory upon exit via the destructors; i.e. for the most part there isn't any formal cleanup code for most of them - right? |
| 20:39.07 | brlcad | huh, that's odd -- web list shows it just fine |
| 20:39.24 | Bulldozer | brlcad: including, specifically, the FontManager |
| 20:39.42 | Bulldozer | brlcad: am I correct so far? |
| 20:39.54 | brlcad | Bulldozer: hold on, have to kick the list server first |
| 20:40.05 | Bulldozer | waits |
| 20:40.14 | dexter- | definitely down |
| 20:40.16 | brlcad | oh my, yes.. apache is getting hit up hard |
| 20:40.25 | dexter- | Bulldozer, sorry :P |
| 20:40.34 | Bulldozer | np dex |
| 20:40.50 | brlcad | mysql is to blame |
| 20:41.50 | brlcad | slowly coming back to life |
| 20:41.53 | brlcad | ~bzflist |
| 20:42.22 | brlcad | ~bzflist |
| 20:42.39 | brlcad | it's catching up now |
| 20:43.46 | dexter- | ~brlcad+= |
| 20:43.49 | dexter- | gah! |
| 20:43.51 | dexter- | ~brlcad++ |
| 20:47.37 | Bulldozer | ... and I almost had the answer about the singletons :) |
| 20:47.39 | brlcad | Bulldozer: right, singletons clean up with an atexit hook that deletes themselves |
| 20:47.49 | Bulldozer | okay |
| 20:47.54 | brlcad | that is their "formal cleanup" |
| 20:47.54 | Bulldozer | so here's the problem |
| 20:48.07 | Cygal | what are those ~nickname+? |
| 20:48.12 | Bulldozer | freetype also has it's own cleanup |
| 20:48.31 | Bulldozer | apparently, freetype's cleanup is happening first |
| 20:48.33 | dexter- | Cygal, huh? |
| 20:49.05 | Bulldozer | so then when the FontManager cleanup runs... |
| 20:49.27 | Bulldozer | it's dereferencing already freed memory |
| 20:49.42 | Wyk3d1 | suggests unloading everything explictly in a given order at shutdown, meaning no globals and no auto destroying singletons |
| 20:50.20 | brlcad | Bulldozer: evidence of this? |
| 20:50.30 | brlcad | other than it crashing in freetype? |
| 20:50.37 | Bulldozer | I can show you a valgrind trace |
| 20:50.43 | brlcad | could also just as well be a problem with ftgl's memory management |
| 20:51.04 | Bulldozer | apparently more than 10,000,000 frees happen, so valgrind with default settings doesn't detect it properly. |
| 20:51.06 | Bulldozer | Also |
| 20:51.08 | brlcad | we just delete the ftgl things that we created, like we would expect |
| 20:51.10 | Cygal | who sould I ping for my question on bots? |
| 20:51.14 | Bulldozer | I verified the problem and fix, by making FontManager's "clear" function public, then calling it in cleanupClient |
| 20:51.14 | Cygal | s/sould/should/ |
| 20:51.26 | Bulldozer | The problem no longer occured |
| 20:51.48 | dexter- | Cygal, just ask, if somebody who knows stuff about it is here, they'll answer :) |
| 20:51.51 | Thumper_ | Cygal: ask ibot in private (help karma) |
| 20:51.56 | Cygal | it's already asked dexter- |
| 20:52.54 | Cygal | Thumper_: thanks |
| 20:52.55 | dexter- | Cygal, oh. you give other people good or bad karma, using ~name++ or ~name-- |
| 20:53.17 | Cygal | nah, I meant the other question, before you joined :) |
| 20:53.40 | dexter- | right..I'm just gonna be quiet. |
| 20:54.07 | brlcad | Bulldozer: hm, I think I see what you mean though rather curious that freetype has it's own deregistration |
| 20:54.15 | brlcad | still makes me think something is awry in ftgl |
| 20:54.54 | brlcad | adding the explicit cleanup just hides the issue by making it clean up before atexit()/~destructors are called |
| 20:55.30 | Bulldozer | brlcad: let me post the valgrind trace... |
| 20:56.14 | brlcad | Wyk3d1: that is generally ideal -- not clear why fontmanager's a singleton in the first place other than maybe as a means to eliminate a global |
| 20:57.23 | brlcad | singletons should always autodestroy themselves though -- if you have to manually create and destroy them, you open up the possibility of other problems across library boundaries, potential for multiple 'singletons', and a few other issues |
| 20:58.06 | brlcad | now allowing a singleton to be destroyed early is another matter -- that should work too |
| 20:58.10 | Bulldozer | brlcad: http://bzflag.pastebin.ca/1376148 |
| 20:58.32 | brlcad | as it'll just get created on the next call reference |
| 20:58.33 | brlcad | thx Bulldozer |
| 20:59.00 | Bulldozer | brlcad: I'm looking at the last three "Invalid read of size 4" |
| 20:59.14 | brlcad | jeez, that's bad -- we used to have a completely clean report just last year |
| 20:59.47 | Bulldozer | most of it's from asound... |
| 21:00.32 | dexter- | brlcad, Is being a college student a premise for participating in the GSoC? |
| 21:00.33 | brlcad | Bulldozer: note that the ftgl and freetype symbol names are deceivingly similar |
| 21:00.50 | brlcad | most of the lowercase named files are freetype, most that start with FT*.cpp are FTGL |
| 21:01.09 | Bulldozer | brlcad: noted |
| 21:01.28 | brlcad | if the symbol name has an underscore, it's usually freetype |
| 21:02.03 | Bulldozer | dexter-: yes, although anything counts, PhD, masters, bachelors, etc. |
| 21:02.21 | Bulldozer | brlcad: FT_Done_Face is being called on the same face |
| 21:02.22 | *** join/#bzflag TD-Linux (n=wheeeeee@12.20.36.15) |
| 21:02.34 | Bulldozer | brlcad: Once by the freetype cleanup, and once by bzflag |
| 21:02.40 | Bulldozer | brlcad: I traced the pointers |
| 21:02.55 | dexter- | aww |
| 21:04.09 | Bulldozer | brlcad: Technically I would call it a freetype bug, as it seems to me that it should detect that. |
| 21:04.35 | brlcad | Bulldozer: yeah, sounds like it |
| 21:04.49 | brlcad | if they're deleting their stuff, they have the ability to track their pointers and null them out |
| 21:05.20 | brlcad | dexter-: even part time at the local community college counts as well as high school iirc |
| 21:05.44 | dexter- | yay high school |
| 21:05.59 | dexter- | although I really would be of no use at all, just wonderin' |
| 21:06.24 | brlcad | Bulldozer: though if I'm reading that trace correctly, FTLibrary() is what's getting called |
| 21:06.33 | brlcad | some automatic ftgl cleanup somewhere |
| 21:06.43 | Bulldozer | brlcad: No |
| 21:06.48 | brlcad | that shouldn't be happening or we're using ftgl wrong |
| 21:07.16 | Bulldozer | brlcad: it's getting called by the destructor... |
| 21:07.39 | *** join/#bzflag Chestal (i=thilo@vmax.unix-ag.uni-siegen.de) |
| 21:07.39 | *** join/#bzflag pacman87 (n=pacman87@resnet-46-40.dorm.utexas.edu) |
| 21:07.39 | *** join/#bzflag CBG (n=CBG@about/essy/fan/CBG) |
| 21:07.39 | *** join/#bzflag jmunro[a] (i=james@unaffiliated/jmunro) |
| 21:07.39 | *** mode/#bzflag [+o Chestal] by irc.freenode.net |
| 21:07.39 | brlcad | line 413 |
| 21:07.39 | brlcad | it was called during exit() .. that's not right |
| 21:07.58 | brlcad | so when our singleton went to clean up, it was already gone |
| 21:08.00 | brlcad | and crashes |
| 21:08.07 | Bulldozer | brlcad: exactly |
| 21:08.34 | Bulldozer | brlcad: but that's the ~FTLibrary destructor |
| 21:08.50 | Bulldozer | brlcad: so there might not be any code to it. |
| 21:09.39 | brlcad | have to look, but I think the FTLibrary destructor shouldn't be deleting those resources -- have to see how it's documented |
| 21:11.14 | Bulldozer | note that if we do the cleanup first, it doesn't happen. |
| 21:11.31 | Bulldozer | (it meaning the dual cleanup) |
| 21:14.11 | brlcad | yeah, but that just obscures the problem |
| 21:14.21 | Bulldozer | brlcad: From freetype.h |
| 21:14.31 | brlcad | checking on FTLibrary |
| 21:14.46 | Bulldozer | FT_Done_FreeType - Destroy a given FreeType library object and all of its children including resources, drivers, faces, sizes, etc |
| 21:17.13 | *** join/#bzflag destiny_sh (i=vrn@h1457496.stratoserver.net) |
| 21:17.17 | *** join/#bzflag TD-Linux (n=wheeeeee@12.20.36.15) |
| 21:22.21 | *** join/#bzflag dexter- (n=whodaman@bzflag/player/Dexter) |
| 21:23.11 | destiny_sh | while playing bzflag.....i found out that it was difficult to control the tank movements with a mouse ......but after disconnecting the mouse ........and playing with arrow keys .....the problem remained as if the mouse is still connected |
| 21:23.42 | destiny_sh | is this a bug?? |
| 21:25.51 | Bulldozer | brlcad: an FT_Face is a ptr... freetype does it's own cleanup and frees the object (and it's children) and zeros out the ptr, but we keep a copy of the ptr ourselves. |
| 21:26.10 | Bulldozer | brlcad: freetype has no way of zeroing out our pointer or checking it it's valid. |
| 21:27.56 | brlcad | destiny_sh: possibly, but sounds kind of specious |
| 21:28.05 | blast007 | destiny_sh: difficult to control, meaning what exactly? |
| 21:28.26 | Bulldozer | because we're passing around a ptrptr in FTFace |
| 21:29.23 | Bulldozer | in our FTFace destructor we call FT_Done_Face(*ftFace); |
| 21:29.42 | *** join/#bzflag jmunro[a] (i=james@217.112.83.12) |
| 21:29.54 | *** join/#bzflag KTL (n=KTL@213.219.164.119.adsl.dyn.edpnet.net) |
| 21:29.59 | Bulldozer | so there's no way of checking if that dereferenced memory we're passing in was already free'd or not |
| 21:30.19 | *** join/#bzflag pacman871 (n=pacman87@resnet-46-40.dorm.utexas.edu) |
| 21:31.07 | brlcad | Bulldozer: right, but I was referring to ftgl deleting those faces in the first place automatically |
| 21:31.19 | brlcad | I see the issue now |
| 21:31.48 | Bulldozer | as you pointed out, ftgl has FTFace, freetype has FT_Face :) |
| 21:31.55 | Bulldozer | makes for good confusion :) |
| 21:32.08 | brlcad | yeah |
| 21:32.24 | Bulldozer | FTFace has a var that's a ptr to a FT_Face |
| 21:32.27 | brlcad | should all be FTGL prefixed, but wasn't going to break the API for this release :) |
| 21:32.51 | Bulldozer | freetypes frees up the FT_Face, but the ptr in FTFace stays |
| 21:33.05 | *** join/#bzflag dexter- (n=whodaman@bzflag/player/Dexter) |
| 21:33.13 | Bulldozer | then we pass freetype the same pointer, for FT_Done_Face |
| 21:33.43 | brlcad | their FTLibrary singleton is a static, they rely on static destruction on exit which is where they destruct the freetype resources |
| 21:33.59 | destiny_sh | difficult to controll means that if i move my mouse forward to make the tank move dorward.....then it will move forward even if i had stopped moving my mouse |
| 21:34.12 | Bulldozer | if we do the cleanup first, freetype removes it automagically from it's lists, so it's not done later by freetype |
| 21:34.16 | brlcad | the freetype library it's using certainly has valid handles, but then we have our own handles on the ftfaces we created and double-delete |
| 21:34.24 | Bulldozer | yeah, exactly |
| 21:34.43 | Bulldozer | it's worse, since it's not just a double delete, because of the way freetype cleans up the faces. |
| 21:34.45 | blast007 | destiny_sh: that's how the controls work |
| 21:34.59 | blast007 | destiny_sh: if you want to stop, you have to move the mouse back to the center |
| 21:35.49 | blast007 | center of the screen* |
| 21:35.49 | blast007 | there's that little box in the middle that will zero out your speed and turning velocity |
| 21:36.08 | destiny_sh | moving mouse left ....makes the tank always take the left turn even when mo input is given from the keyboard or mouse |
| 21:36.27 | blast007 | did you leave the mouse on the left side of the screen? |
| 21:36.28 | brlcad | wonders whytf freetype indents their functions 2-chars |
| 21:36.51 | destiny_sh | exactly not |
| 21:37.05 | brlcad | destiny_sh: they're not people, they can't straffe :) |
| 21:37.21 | blast007 | destiny_sh: so you moved the mouse back to the center of the screen but your tank kept turning? |
| 21:37.27 | brlcad | think of it like an airplane throttle |
| 21:38.07 | brlcad | destiny_sh: when you were using the keys, though -- was the tank moving with no keys pressed? (it shouldn't) |
| 21:38.16 | brlcad | (after the mouse is unplugged) |
| 21:38.25 | CIA-11 | BZFlag: 03LeGeeko 07http://my.bzflag.org * r5629 10/w/BZFS_API: Corrected spelling error "documnetation". |
| 21:38.27 | dexter- | I've had that problem |
| 21:38.55 | dexter- | Sometimes the tank just keeps on turning in one direction, even though one isn't pressing any keys |
| 21:38.59 | brlcad | Bulldozer: still think there's something more intelligent that either freetype or ftgl should be doing |
| 21:39.10 | brlcad | you may have keys just getting stuck |
| 21:39.20 | brlcad | some keyboards do that, keep sending events |
| 21:39.33 | blast007 | or not sending the key-up signal? |
| 21:39.35 | dexter- | uh |
| 21:39.37 | brlcad | too many cheetos |
| 21:39.44 | dexter- | lol |
| 21:39.51 | dexter- | Never eat at the computer :o) |
| 21:39.59 | Bulldozer | brlcad: if there's no control over which order the destructors are called... |
| 21:40.07 | brlcad | not going to say what else might cause keys to *stick* |
| 21:40.15 | me1 | oh, that reminds me, if you hold a key, like left or up, and press 'n' or anything else to chat, it keeps going forward/left/direction until that key is pressed and unpressed again - would that be a bzflag prob? |
| 21:40.27 | brlcad | me1: yeah, that would be |
| 21:40.41 | brlcad | there are a few bindings that will cause the up-event to get lost |
| 21:40.54 | Bulldozer | brlcad: as an aside, i was getting keys to "stick" in 2.99, 'tho i'm assuming that's not the version he's using. |
| 21:41.11 | *** join/#bzflag jcp (n=jw@unaffiliated/javawizard2539) |
| 21:41.18 | brlcad | Bulldozer: not ordering, better means to validate what we're deleting before deleting |
| 21:41.50 | brlcad | i mean we can do the order fix, but looking if there's something more intelligent that can be put into FTFaces |
| 21:41.53 | destiny_sh | one more thing i want to ask.........how can we see the replays of the game? |
| 21:42.02 | brlcad | an FTFace with a zero'd FT_Face for example |
| 21:42.25 | Bulldozer | brlcad: the immediate deferenced ptr is invalid; there's nothing we can check for. |
| 21:42.35 | blast007 | destiny_sh: the way I already told you |
| 21:42.39 | Bulldozer | brlcad: since we're keeping a reference to free'd memory... the only way I can think of is to check the freetype state and not call FT_Done_Face it if the library state is X |
| 21:43.16 | blast007 | destiny_sh: you have to have the right permission to save a replay from a server (and it won't save to YOUR computer, but to that server's hard drive) |
| 21:43.32 | blast007 | so what exactly are you trying to do? |
| 21:43.34 | dexter- | brlcad, me1: that's the problem i'm talking about |
| 21:45.59 | Bulldozer | brlcad: when i was tracing the pointers, everything within a valid range was still valid (ie nothing had changed within ftgl at valid memory locations after the freetype destructor ran) |
| 21:46.25 | Bulldozer | the only additional places to check were at invalid memory locations |
| 21:47.41 | destiny_sh | on your website on bugs related to bzflag .....there was a bug under regressions .....saying that bullets no longer bounce off even in replays ....so i wanted to check it out ......but couldnot find a replay mechanism |
| 21:48.54 | blast007 | run one server with a -recdir set and a -recbuf 2 (2MB buffer, should be more than enough for just one player) |
| 21:49.11 | blast007 | join that server, play for a while, then do /record save MyReplay |
| 21:49.24 | blast007 | that will save a replay named MyReplay in the recording directory |
| 21:49.41 | blast007 | then start up a server with that same -recdir and -replay |
| 21:50.04 | blast007 | join, send /replay load MyReplay, then rejoin, and do /replay play |
| 21:50.37 | Bulldozer | brlcad: what if we keep a hash of all the current FTFace's in FTLibrary, then when the FTLibrary destructor is called, delete all the FTFace's first? |
| 21:51.18 | Bulldozer | brlcad: it should be a very low overhead; only about a dozen faces are created/destroyed during the startup and shutdown of bzflag. |
| 21:52.52 | Bulldozer | ... and we already assume that there is a valid instance of FTLibrary accessible from FTFace. |
| 21:54.30 | Bulldozer | that should work... is it a good enough solution? |
| 21:54.44 | brlcad | Bulldozer: actually that's exactly what I was thinking |
| 21:54.51 | *** join/#bzflag kumarabhi (n=chatzill@115.241.227.196) |
| 21:55.01 | Bulldozer | brlcad: let me make the patch, then ;) |
| 21:55.13 | Bulldozer | but food first :) be back in a bit |
| 21:55.24 | brlcad | different book-keeping in ftgl for the faces, so it's more safe if you ask to have a particular ftface individually be removed |
| 21:55.40 | brlcad | nice find on the bug either way |
| 21:55.47 | brlcad | that's lingered for months |
| 21:56.02 | dexter- | ~Bulldozer++ |
| 21:56.37 | brlcad | was so easy to just ignore the problem by not freeing the memory (which actually humorously 'okay' :) |
| 21:57.46 | brlcad | debugging sessions were mostly useless as it was just memory corruption (couldn't run valgrind to see the double-free) |
| 21:58.41 | destiny_sh | in the rendering section of bugs on the wiki page.....i couldnot understand the meaning of .......burrowed tank shadows should be ground clipped |
| 21:59.07 | brlcad | destiny_sh: please try for a few less periods...... |
| 21:59.22 | brlcad | probably a good sign of where you should just press enter and start another line |
| 22:00.07 | blast007 | or in this case, a comma and a colon |
| 22:00.37 | brlcad | yeah, they're not complete thoughts in that one :) |
| 22:00.46 | destiny_sh | i will do this |
| 22:01.00 | destiny_sh | sorry for the inconvenience |
| 22:01.05 | brlcad | no big deal |
| 22:02.44 | destiny_sh | i couldnot understand the term ground clipped an clip plan |
| 22:02.49 | destiny_sh | plane |
| 22:03.34 | destiny_sh | "ground clipped" and "clip plane" |
| 22:04.23 | blast007 | then don't worry about that one :) |
| 22:05.20 | *** join/#bzflag sniper15_ (n=sniper15@S0106000d88e222e1.gv.shawcable.net) |
| 22:08.06 | *** join/#bzflag s15 (n=sniper15@S0106002191dd19a8.gv.shawcable.net) |
| 22:11.55 | brlcad | mmm. Bulldozer, looks like you can hook into FTFace's constructor to tell the library that a face was created |
| 22:24.21 | CIA-11 | BZFlag: 03brlcad * r19547 10/trunk/bzflag/src/other/ftgl/src/FTLibrary.cpp: remove dead code, manual deletion of the freetype memory manager isn't necessary |
| 22:32.55 | Cygal | https://sourceforge.net/tracker/?func=detail&aid=2721389&group_id=3248&atid=303248 - can anyone give me feedback on this? |
| 22:33.15 | Cygal | leaves |
| 22:38.49 | CIA-11 | BZFlag: 03brlcad * r19548 10/trunk/bzflag/ (4 files in 4 dirs): (log message trimmed) |
| 22:38.49 | CIA-11 | BZFlag: Fix a crash-on-exit bug that has been around for quite some time now, thanks to |
| 22:38.49 | CIA-11 | BZFlag: the efforts of Mathew Eis (Bulldozer) for tracking down the problem. The |
| 22:38.49 | CIA-11 | BZFlag: problem was a deletion order issue where our FontManager singleton was getting |
| 22:38.49 | CIA-11 | BZFlag: destructed _after_ a FTGL FTLibrary static destructor, the latter of which would |
| 22:38.52 | CIA-11 | BZFlag: destroy the freetype library and invalidate our references. this fix avoids the |
| 22:38.54 | CIA-11 | BZFlag: problem by explicitly deleting our FontManager before shutdown so we delete our |
| 22:41.12 | a_meteorite | er, haven't read all the backlog, but about what destiny_sh and dexter said about the tank keeps moving even after ending keyboard input.. happens to me too |
| 22:41.41 | a_meteorite | for instance, the tank may keep driving forward and pressing back will only pause it, you have to press forward again to get it to stop (iirc) |
| 22:42.12 | a_meteorite | haven't seen anything obvious that causes it to happen |
| 22:45.06 | brlcad | see if you can find some reproducible steps |
| 22:45.23 | a_meteorite | k |
| 22:45.27 | brlcad | BulletCatcher: ping |
| 22:45.28 | a_meteorite | (bbl) |
| 22:46.15 | *** join/#bzflag hwilde (n=hwilde@pool-68-162-148-126.pitt.east.verizon.net) |
| 22:46.37 | hwilde | JeffM, what is the hud display nickname label called in observer mode? |
| 22:46.59 | temp_dist | Label |
| 22:47.03 | temp_dist | L |
| 22:47.46 | hwilde | there are like 860 references of Label |
| 22:50.51 | Winny | sorry for interrupting, but are there any cocoa/obj-c people in here? I'm at my wits end |
| 22:51.12 | hwilde | pastebinit |
| 22:52.12 | Winny | hwilde: who, me? |
| 22:52.29 | CIA-11 | BZFlag: 03brlcad * r19549 10/trunk/bzflag/AUTHORS: |
| 22:52.29 | CIA-11 | BZFlag: significant thanks and appreciation deserved to BulletCatcher for his sustained |
| 22:52.29 | CIA-11 | BZFlag: efforts, move him up into the developer section. he's had nearly 200 commits |
| 22:52.29 | CIA-11 | BZFlag: consistently for nearly a year (first commit on 16 May 2008). thank you, |
| 22:52.29 | CIA-11 | BZFlag: catcher of the bullets. |
| 22:54.09 | *** join/#bzflag scott__ (n=mindnull@24-247-249-58.dhcp.aldl.mi.charter.com) |
| 22:54.11 | brlcad | Winny: have to be more specific than that |
| 22:55.25 | Winny | brlcad: don't really want to hijack the chat |
| 22:55.36 | TyroneFHornigh | Winny: This isn' a forum for coco/obj-c. I'm not sure I would trust most of the people around here with a question about it. |
| 22:55.49 | CBG | a_meteorite: for instance, the tank may keep driving forward and pressing back will only pause it, you have to press forward again to get it to stop (iirc) --- and this is while the mouse cursor is centred? |
| 22:55.57 | CBG | TyroneFHornigh: "trust"? :P |
| 22:56.20 | TyroneFHornigh | Don't believe everything you read on the internet. |
| 22:56.44 | CBG | True... so why trust anyone else? |
| 22:57.29 | CIA-11 | BZFlag: 03brlcad * r19550 10/trunk/bzflag/AUTHORS: stub in the 2009 gsoc section, add the overlooked returning student to the 2008 section. |
| 22:57.32 | TyroneFHornigh | Asking about cocoa/obj-c in a forum where they actually use the language would likely get you an answer that could be used to find a real answer. |
| 22:58.02 | CBG | You assume nobody here is capable of answering? |
| 22:58.44 | TyroneFHornigh | I assume the answers would be in need of a higher level of verification around here. :D |
| 22:59.24 | brlcad | Winny: don't want you to hijack it either and it is offtopic, but if you're going to drop a question like that -- helps to not ask if there's someone that can help you with an unspecified problem, you could state the problem concisely asking for help |
| 22:59.39 | brlcad | and then subsequently still probably get told that it's off-topic ;) |
| 23:00.25 | brlcad | asking for help without saying the problem is mostly a pointless question (no pun intended) |
| 23:01.25 | brlcad | is feelin' like a gangsta, yo. |
| 23:01.52 | Winny | Ok, well basically I can't figure out if an NSThread's NSAutoreleasePool releases everything that's been accessed while the thread is running, or if it only deallocates stuff that's been created inside the thread |
| 23:02.30 | hwilde | guesses whichever is worst |
| 23:02.46 | Winny | hehe |
| 23:06.13 | *** join/#bzflag pacman87 (i=500@resnet-46-40.dorm.utexas.edu) |
| 23:06.15 | brlcad | Winny: yeah, way way off-topic, but I'll pretend you're writing a bzflag client in obj-c -- when the thread terminates, it flushes out its pool and will remove only items it allocated |
| 23:06.40 | Winny | brlcad: ah, ok, thanks |
| 23:06.44 | brlcad | i.e. things it retains (and it should only be retaining things it makes) |
| 23:07.11 | brlcad | there's a pool per thread |
| 23:08.08 | brlcad | notes that there are several code contributions not attributed in AUTHORS |
| 23:37.02 | *** join/#bzflag Dexter- (n=Dexter-@p579AC779.dip.t-dialin.net) |
| 23:41.47 | *** part/#bzflag Dexter- (n=Dexter-@bzflag/player/Dexter) |
| 23:54.42 | *** join/#bzflag Dexter- (n=Dexter-@p579AC779.dip.t-dialin.net) |
| 23:55.33 | *** part/#bzflag Dexter- (n=Dexter-@bzflag/player/Dexter) |