| 00:00.06 | JeffM | why NOT |
| 00:00.12 | L4m3r | seeing Roger tweak on the teles would be fun |
| 00:00.14 | JeffM | I mean how can you even ask that question ;) |
| 00:00.23 | JeffM | I mean as a character |
| 00:00.27 | JeffM | not our tank bots |
| 00:00.28 | L4m3r | ah |
| 00:00.34 | JeffM | it shoudl sing a song |
| 00:00.42 | JeffM | except for the ones who are dead |
| 00:00.51 | JeffM | it woudl just keep on trying |
| 00:00.55 | JeffM | untill it ran out of cake |
| 00:01.00 | JeffM | it's not even angy |
| 00:01.07 | JeffM | it's beeing so sinceere right now |
| 00:01.11 | L4m3r | goes to work |
| 00:01.14 | JeffM | even tho you broke it's hart |
| 00:01.15 | JeffM | and killed it |
| 00:01.20 | JeffM | and tore it to peices |
| 00:01.24 | JeffM | and threw every peice into a fire |
| 00:10.46 | spldart | aaaAAAAAaaaahhhh :) |
| 00:11.07 | spldart | "Time to play" /pinhead |
| 00:11.55 | *** join/#bzflag BenUrban (n=benurban@unaffiliated/benurban) |
| 00:19.51 | Lukstr | oh dear |
| 00:24.29 | *** join/#bzflag Gnurdux (n=gnurdux@c-69-251-255-231.hsd1.md.comcast.net) |
| 00:30.49 | TD-Linux | my teleporter dream is to see through it like a window, to the place it teleports to :) |
| 00:31.08 | TD-Linux | it could be possible with stenciling, too big a performance impact though :( |
| 00:34.08 | Lukstr | the general trick to making portals |
| 00:34.42 | Lukstr | is to duplicate everything the player can see through it |
| 00:34.51 | Lukstr | so rather than *real* portals |
| 00:34.59 | Lukstr | just duplicating a chunk of the map |
| 00:36.51 | spldart | ooOOOOOOOoooooo.. that's a sweet idea |
| 00:37.54 | Lukstr | That's how they did it in Portal :P |
| 00:38.02 | Lukstr | still not easy |
| 00:38.13 | Lukstr | and I don't think very easy to implement in the engine's current state |
| 00:38.23 | blast007 | TD-Linux: that's not how they work! don't you watch StarGate? |
| 00:38.32 | spldart | Well. I'm referring to the concept |
| 00:38.52 | Lukstr | blast007: There's differences between Portals and Teleporters :) |
| 00:40.21 | spldart | But but... STOS City of the Edge of Forever!!! |
| 00:40.22 | spldart | ? |
| 00:40.43 | spldart | s/on/of |
| 00:42.59 | *** join/#bzflag bier (n=bier@p54A567D4.dip.t-dialin.net) |
| 00:57.06 | *** join/#bzflag mcintyem (n=mcintyem@smct42-235-dhcp.resnet.colorado.edu) |
| 00:57.23 | mcintyem | Hello. |
| 00:58.14 | mcintyem | I have submitted an application for SoC and would like to introduce myself to any devs here. |
| 00:58.22 | *** join/#bzflag Lukstr (n=Lukstr@206-248-161-221.dsl.teksavvy.com) |
| 01:00.20 | mcintyem | My google id is eric.m.mcintyre. So far I've heard from Scott Johnson and Jeffrey Myers on the SoC comments. |
| 01:01.35 | mcintyem | The project I'm proposing is to improve the BZFlag server menu for searching by various additional parameters-- like ping time to servers, or searching for what servers other players are on. |
| 01:02.13 | mcintyem | Does anyone here have any input on these sorts of additions? |
| 01:02.47 | mcintyem | Or is anyone working on patches related to this idea? |
| 01:06.47 | CBG | mcintyem: Jeff Myers == JeffM. I think Scott Johnson == brlcad bt apologies to both if I'm wrong there. |
| 01:07.21 | *** join/#bzflag TD--Linux (n=wheeeeee@66-188-204-109.dhcp.roch.mn.charter.com) |
| 01:08.08 | mcintyem | CBG: Thanks! Who are you? |
| 01:08.26 | CBG | A PITA. |
| 01:08.37 | CBG | Being unusually helpful. |
| 01:10.05 | mcintyem | Well, don't be modest or anything. Are you a regular developer? |
| 01:10.30 | CBG | giggles. |
| 01:10.36 | CBG | No, really. I'm just an ass that hangs out here to annoy people. |
| 01:10.51 | Lukstr | yeah |
| 01:10.54 | Lukstr | ~karma CBG |
| 01:10.54 | ibot | cbg has karma of -522 |
| 01:10.55 | Lukstr | see? |
| 01:10.57 | Lukstr | runs |
| 01:11.05 | CBG | heh |
| 01:11.40 | CBG | The negative karma is actually because I literally asked to receive it rather than positive... |
| 01:11.57 | CBG | I'm studying Games Dev. but have never worked on BZ and probably never will, mcintyem. |
| 01:11.57 | mcintyem | hasn't been on IRC in about 6 years |
| 01:12.22 | CBG | Could be worse. Most guys on my Games Dev. course have no clue what IRC is. |
| 01:12.45 | mcintyem | Are you a CS student? |
| 01:13.21 | CBG | My course is titled "Games Development & Artificial Intelligence" so I am literally studying game development. |
| 01:13.37 | CBG | Or rather, I thought I would be... |
| 01:13.45 | mcintyem | ? |
| 01:13.47 | JBdiGriz | mcintyem: It's good to see you on IRC. We are currently evaluating the proposals, and part of the evaluation is participation in this channel. Another part is submitting a small patch to the source repository. |
| 01:14.17 | CBG | We've got as far (since September) as creating our own data types in C++. :| |
| 01:15.48 | CBG | I can imagine creating incredible games, better than Crysis, with such vast knowledge... ;) |
| 01:17.58 | mcintyem | JBdiGriz: I'm a little uncertian on how to proceed with submitting a patch. I've set up the patch request on SF, and I promised Jeff and Scott a detailed description of how I intend to implement at least one of my proposed improvements by Sunday (by adding a comment to the SoC application) |
| 01:18.14 | *** join/#bzflag JeffM_ (n=JeffM@adsl-75-16-90-222.dsl.irvnca.sbcglobal.net) |
| 01:18.22 | CBG | Talk of the devil... |
| 01:20.31 | mcintyem | That is, I said I would do so by Sunday, because I'll need a few days to review the existing BZFlag code and set up a development machine to dedicate to the effort this summer. To submit my example patch should I try to pick a bug or other small patch request and fulfill it this weekend? (I would suppose the intent would be to get an example of my coding style/ability to create |
| 01:20.36 | mcintyem | ...maintainable complete code) |
| 01:21.26 | JeffM_ | mcintyem, bugs are always nice, but mostly it's just to make sure you can build and stuff |
| 01:21.29 | JeffM_ | and can use svn |
| 01:24.58 | mcintyem | Sounds great. I'll post the patch # to SoC when I have created something (few days). |
| 01:28.00 | *** join/#bzflag whodaman (n=whodaman@pdpc/supporter/student/whodaman-) |
| 01:28.04 | brlcad | CBG: i'm not scott johnson |
| 01:28.31 | JeffM_ | He's steve bigootay |
| 01:31.18 | brlcad | mcintyem: welcome |
| 01:33.55 | spldart | Gotta reboot.. I Bug nailed my windows |
| 01:34.04 | mcintyem | blrcad: Thanks Steve. |
| 01:34.06 | spldart | s/i/a |
| 01:34.59 | JeffM_ | hah |
| 01:35.43 | CBG | brlcad: then i apologise |
| 01:35.54 | *** join/#bzflag spldart (n=vircuser@c-98-197-19-35.hsd1.tx.comcast.net) |
| 01:36.11 | mcintyem | is on standby and will check back later |
| 01:37.50 | *** join/#bzflag AAA_awright (n=AAA_awri@wsip-68-14-251-102.ph.ph.cox.net) |
| 01:45.00 | brlcad | CBG: no need, name at least starts with the same first letter ;) |
| 01:45.13 | brlcad | points to his /whois |
| 01:46.16 | *** join/#bzflag Think_Differentl (n=shedelj@unaffiliated/thinkdifferentl/x-838543) |
| 02:01.23 | CBG | I just remembered who you are without /whoising, Sean Morisson, right? :) |
| 02:01.33 | spldart | just got off the phone with his ex-wife. CBG! Point @ me and laugh. :-( |
| 02:01.43 | CBG | Well, Sean at east. |
| 02:01.56 | brlcad | close enough ;) |
| 02:01.58 | CBG | points and laughs at spldar |
| 02:02.02 | CBG | points and laughs at spldart* |
| 02:02.14 | spldart | ~CBG-- |
| 02:02.17 | spldart | :-) |
| 02:02.21 | CBG | Ta. |
| 02:03.59 | spldart | When I'm on your wavelength your pretty cool. When I'm on the other wavelength for me your the aformentioned PITA ;-) |
| 02:04.08 | spldart | hehe |
| 02:05.32 | CBG | I'm always pretty cool. Just not to everyone at the same time. |
| 02:15.22 | spldart | Ah |
| 02:19.21 | mcintyem | Anybody know a good IRC client for Linux (Fedora RPM prefer) console (ncurses prefer)? |
| 02:19.55 | eTangenT | mcintyem: irssi? |
| 02:20.13 | spldart | irssi pwnz for non X linux |
| 02:20.33 | mcintyem | eTangenT: spldart: irssi... excellent. will check it out. |
| 02:21.54 | eTangenT | spldart: even in X, I still use irssi in a terminal window |
| 02:21.56 | eTangenT | speaking of which |
| 02:22.05 | eTangenT | I should finally reinstall the nvidia drivers in SuSE |
| 02:22.07 | eTangenT | and boot to linux again |
| 02:22.12 | eTangenT | Windows is starting to really annoy me |
| 02:22.18 | spldart | hehehe |
| 02:23.57 | *** join/#bzflag FalseProphet (n=Gigi@unaffiliated/emonemo) |
| 02:30.34 | *** join/#bzflag TD--Linux (n=wheeeeee@66-188-204-109.dhcp.roch.mn.charter.com) |
| 02:47.52 | *** join/#bzflag KingofCamelot (n=davidsan@SCTN-12-153.resnet.ucsb.edu) |
| 02:49.21 | *** join/#bzflag mcintyem_ (n=mcintyem@emm1.info) |
| 02:50.45 | *** join/#bzflag mcintyem (n=mcintyem@emm1.info) |
| 02:59.52 | *** join/#bzflag mcintyem (n=mcintyem@emm1.info) |
| 03:00.04 | *** join/#bzflag daniel_jackson (n=bsanford@cpe-76-88-96-237.san.res.rr.com) |
| 03:00.53 | mcintyem | Thanks for the suggestion. |
| 03:00.59 | mcintyem | is now running irssi |
| 03:02.53 | spldart | :) |
| 03:08.16 | *** join/#bzflag mayB (n=mayur@c-67-191-238-17.hsd1.ga.comcast.net) |
| 03:11.17 | Winny | BZBB admins, delete last post here: http://my.bzflag.org/bb/viewtopic.php?t=12439 |
| 03:16.09 | Winny | rolls into bed |
| 03:22.13 | spldart | terrible TERRIBLE |
| 03:23.28 | *** part/#bzflag daniel_jackson (n=bsanford@cpe-76-88-96-237.san.res.rr.com) |
| 03:24.55 | mcintyem | where is http://bzflag.org/developers/compiling.php |
| 03:25.07 | mcintyem | or rather where has it gone? wiki? |
| 03:25.40 | *** join/#bzflag short_circuit (n=short_ci@c-98-197-19-35.hsd1.tx.comcast.net) |
| 03:31.05 | JeffM_ | mcintyem, the wiki has info |
| 03:31.05 | JeffM_ | but also so does the readme file for your platform |
| 03:31.09 | JeffM_ | what OS/compiler are you using? |
| 03:34.57 | mcintyem | Fedora 8 and gcc 4.1.2 -- says I'm missing OpenGL, I have Mesa* (inc. devel rpms installed) as well as glew. Just getting started though. I'll check out the readme and look on the wiki. |
| 03:35.01 | mcintyem | Thanks, Jeff. |
| 03:36.32 | *** join/#bzflag AAA_awright (n=AAA_awri@wsip-68-14-251-102.ph.ph.cox.net) |
| 03:52.19 | JeffM_ | do you have C++ installed? |
| 03:57.55 | mcintyem | $ rpm -qa | grep gcc |
| 03:57.55 | mcintyem | gcc-gfortran-4.1.2-33 |
| 03:57.55 | mcintyem | gcc-c++-4.1.2-33 |
| 03:57.55 | mcintyem | libgcc-4.1.2-33 |
| 03:57.55 | mcintyem | gcc-4.1.2-33 |
| 03:59.17 | *** join/#bzflag ViciousM (n=max@cpe-024-211-248-161.nc.res.rr.com) |
| 04:00.34 | mcintyem | mesa-libGL / -libGLw /-libGLU and all devels from those libs are also installed |
| 04:02.36 | mcintyem | what other open GL development libs does BZFLag expect? Compiler wiki says version 1.1, mesa libs are version 7... is it referencing a different opengl lib? |
| 04:03.53 | JBdiGriz | You also need SDL |
| 04:07.41 | mcintyem | $ rpm -qa | grep SDL |
| 04:07.41 | mcintyem | SDL-devel-1.2.13-2.fc8 |
| 04:07.41 | mcintyem | SDL_image-1.2.6-5.fc8 |
| 04:07.41 | mcintyem | SDL-1.2.13-2.fc8 |
| 04:12.26 | Lukstr | probably dev packages |
| 04:12.35 | mcintyem | ? |
| 04:12.44 | Lukstr | SDL-devel |
| 04:13.07 | mcintyem | SDL-devel-1.2.13-2.fc8? |
| 04:13.16 | Lukstr | yes |
| 04:13.29 | Lukstr | mcintyem: are you sure gcc came with standard c libraries and such? |
| 04:15.12 | mcintyem | Yes, I've used this machine to build a number of other projects I've been involved in, but little of it uses X or graphics. |
| 04:15.29 | Lukstr | eh, `rpm -qa` lists installed packages? |
| 04:15.37 | Lukstr | (I don't recognize the command, not a fedora user) |
| 04:15.52 | mcintyem | Yeah, it is "query all" |
| 04:16.01 | Lukstr | ah, okay, I misunderstood |
| 04:16.16 | Lukstr | ignore all I have said :D |
| 04:16.45 | mcintyem | :D thanks anyhow. |
| 04:18.35 | mcintyem | went into the config and pulled out the test-- here's my problem-- i'll work on it tomorrow evening. |
| 04:18.51 | mcintyem | test.c:2:24: error: OpenGL/glu.h: No such file or directory |
| 04:19.18 | mcintyem | I'll have to figure out how mesa-*-devel can be installed and not include glu.h |
| 04:19.34 | brlcad | OpenGL/glu.h would be for Mac |
| 04:19.44 | mcintyem | Ah, okay, wrong test. |
| 04:20.04 | Lukstr | should be something like "GL/glu.h" |
| 04:20.07 | Lukstr | iirc |
| 04:21.48 | mcintyem | /usr/include/GL/glu.h:37:19: error: GL/gl.h: No such file or directory |
| 04:21.52 | mcintyem | Getting closer... |
| 04:21.54 | mcintyem | :D |
| 04:21.58 | Lukstr | heh |
| 04:22.09 | mcintyem | That explains it. |
| 04:23.11 | mcintyem | Now, what provides gl.h on this system if not mesa-libGL-devel-7.0.2-3.fc8....... |
| 04:23.34 | Lukstr | libGLU? |
| 04:23.51 | mcintyem | Got it and its devel. |
| 04:24.16 | mcintyem | (that is libGL libGLU and libGLw and all devles) |
| 04:24.20 | mcintyem | *devels |
| 04:24.26 | mcintyem | Googling... |
| 04:24.34 | Lukstr | hm |
| 04:26.08 | mcintyem | rpm -ql mesa-libGL-devel | grep gl.h |
| 04:26.08 | mcintyem | /usr/include/GL/gl.h |
| 04:26.17 | mcintyem | Hm. Says its there. |
| 04:26.44 | Lukstr | xorg-x11-devl ? |
| 04:26.51 | Lukstr | devel rather |
| 04:27.23 | Lukstr | see if you have that one |
| 04:28.45 | blast007 | find / -name gl.h |
| 04:28.47 | blast007 | :) |
| 04:29.45 | mcintyem | Interesting.... so, the package manager says mesa-libGL-devel is installed, the rpm for that reports that the fiel /usr/include/GL/gl.h is in the rpm |
| 04:29.48 | mcintyem | but... |
| 04:30.01 | Lukstr | heh |
| 04:30.05 | mcintyem | no file. |
| 04:30.15 | Lukstr | plugs a better OS |
| 04:30.16 | Lukstr | runs |
| 04:30.22 | mcintyem | Awesome job RH. |
| 04:30.32 | mcintyem | Yeah, yeah yeah. |
| 04:30.35 | Lukstr | ;) |
| 04:30.39 | mcintyem | :_) |
| 04:33.19 | blast007 | install Windows. |
| 04:33.21 | blast007 | ducks |
| 04:33.44 | mcintyem | fires. |
| 04:34.16 | mcintyem | package reinstalled, file magically is now there, rerunning config... |
| 04:34.21 | Lukstr | yay |
| 04:34.28 | mcintyem | BZFlag client .....: yes (with SDL) |
| 04:34.34 | mcintyem | Jesus! |
| 04:34.40 | blast007 | all of my experiences with RPM based distros ended in 4 letter words and/or uninstalling yum before just to see "bash: yum: command not found" |
| 04:34.54 | blast007 | s/before // |
| 04:35.07 | Lukstr | blast007: you're not alone :) |
| 04:35.24 | Lukstr | apt is your friend. |
| 04:35.28 | mcintyem | What the heck kind of package manager reports a package installed *$##@&*( .... trailing off. |
| 04:35.35 | blast007 | it was great when yum uninstalled itself |
| 04:35.46 | blast007 | I wasn't sure if that would work |
| 04:35.48 | Lukstr | sort of like HAL kicking the bucket? |
| 04:35.49 | mcintyem | There used to be a "smart" which I liked. |
| 04:35.53 | Lukstr | "daaiseeeyss..." |
| 04:35.55 | JeffM | well... It looks like epyon ain't gonna make that patch today :( |
| 04:36.36 | mcintyem | Thanks all for the consolance. |
| 04:36.41 | brlcad | if it's got a bug, just reject it |
| 04:37.03 | brlcad | even if trivial to fix, the point is making the patch |
| 04:37.05 | CIA-32 | BZFlag: 03JeffM2501 * r16940 10/trunk/bzflag/src/bzfs/bzfs.cxx: |
| 04:37.05 | CIA-32 | BZFlag: when testing to see if an item is not null, be sure to use the not. |
| 04:37.05 | CIA-32 | BZFlag: This fixes bzdb to actually work. |
| 04:37.16 | Lukstr | haha |
| 04:37.17 | Lukstr | nice |
| 04:38.35 | JeffM | whats why I laughed so hard when I found out what the actual problem he was trying to fix was :) |
| 04:39.11 | Lukstr | JeffM: a few weeks ago I was pulling my hair, debugging this assignment |
| 04:39.19 | Lukstr | I was running it through GDB, and then I was valgrinding it |
| 04:39.29 | Lukstr | I couldn't figure out why it was just crashing and burning |
| 04:39.55 | Lukstr | then I realized I forgot to initialize a counter to zero before the while loop it was used in. |
| 04:40.00 | Lukstr | Then I went to sleep :) |
| 04:40.46 | Lukstr | JeffM: Also, that would've been the greatest patch ever |
| 04:40.57 | Lukstr | poor Epyon |
| 04:41.00 | JeffM | for him I have plenty of examples of his code |
| 04:41.06 | JeffM | so that is not in question |
| 04:41.17 | JeffM | it was more for his ability to debug it, and do what he said he was going to do |
| 04:41.21 | JeffM | he did SoC last year |
| 04:41.28 | Lukstr | aye |
| 04:41.52 | Lukstr | bzwg or whatever its called |
| 04:41.54 | JeffM | yeah |
| 04:42.00 | blast007 | bzwgen |
| 04:42.06 | Lukstr | so close |
| 04:42.09 | blast007 | bzwb was jude-'s project |
| 04:42.12 | JeffM | I told him if he didn't do it I'd fix it cus I needed it fixed |
| 04:42.23 | mcintyem | Speaking of sleep I'll let this PIII build all night, so I'm off; Exam tomorrow -- I am a student after all. But hopefully I'll have my first patch by tis weekend... with a greater fate than that one. |
| 04:42.26 | JeffM | that was 3 days ago |
| 04:42.38 | JeffM | mcintyem, fair nuf, have fun :) |
| 04:42.55 | mcintyem | What in need of fixing? I'll take a shot at it. Is there a bug report#? |
| 04:43.15 | JeffM | I just fixed it |
| 04:43.23 | mcintyem | Foiled. |
| 04:43.26 | JeffM | there are lots of bugs in the bugs file |
| 04:43.27 | mcintyem | All right. Later. |
| 04:43.41 | JeffM | brlcad, what be your thoughts of moving all bugs to the bug tracker? more people are using it now? |
| 04:43.44 | mcintyem | I'm sure I'll find one that's quick enough. |
| 04:43.47 | mcintyem | :( |
| 04:44.04 | mcintyem | I mean :). Stupid emoticons. |
| 04:44.10 | mcintyem | 'Night. |
| 04:44.12 | Lukstr | night |
| 04:44.14 | JeffM | see ya |
| 04:44.36 | Lukstr | I would like to see bugs in the bug tracker, if my word counts for anything :) |
| 04:45.12 | JeffM | it does |
| 04:45.16 | JeffM | I don't mind moving them all |
| 04:45.27 | JeffM | I just want various ways to sort them |
| 04:45.35 | Lukstr | aye |
| 04:45.50 | Lukstr | It's kind of nice having a "bugs" and "bugs that the developers care about" |
| 04:45.51 | JeffM | I'll start moving them when I get home |
| 04:46.12 | Lukstr | but I guess that's what the priorities are for |
| 04:46.19 | JeffM | and classes :) |
| 04:46.37 | Lukstr | heh aye |
| 04:48.31 | brlcad | bleh, the BUGS file is still just supposed to be a quick scratch pad -- nothing prevents folks from using the bug tracker if they want to already |
| 04:48.45 | brlcad | just a bigger overhead burden |
| 04:49.28 | Lukstr | (he'll be back) |
| 04:53.09 | brlcad | never speculated he wouldn't return |
| 04:54.10 | javawizard2539 | So has anyone ever heard of lasers not going an infinite length? |
| 04:54.38 | javawizard2539 | I'm running a server and the lasers only go for a fixed range |
| 04:54.52 | brlcad | that's the default |
| 04:55.04 | javawizard2539 | Is it in a server variable? |
| 04:55.12 | brlcad | it's configurable iirc |
| 04:55.38 | javawizard2539 | I'll look through the code and see if I can figure out where it is |
| 04:59.17 | pacman87 | javawizard2539: playing with the server settings, you can get a laser that stops 2 tank lengths in front of you |
| 04:59.32 | pacman87 | i forget exactly how i did it, though |
| 04:59.53 | blast007 | *cough*theif*cought* ;) (jk, I know there are some settings like _laserAdLife and whatnot) |
| 05:00.12 | pacman87 | it make for some interestign lightsaber battles |
| 05:00.24 | pacman87 | short laser + quick reload |
| 05:02.37 | *** join/#bzflag ducktapebz (n=chatzill@71.92.113.45) |
| 05:09.20 | *** join/#bzflag JeffM (n=Jeff@pool-71-109-218-124.lsanca.dsl-w.verizon.net) |
| 05:17.57 | JeffM | anyone against using the SF bug tracker for all bugs? |
| 05:19.23 | brlcad | raises his hand once again :) |
| 05:19.32 | brlcad | 00:48 <@brlcad> bleh, the BUGS file is still just supposed to be a quick scratch pad -- nothing prevents folks from using the bug tracker if they want to already |
| 05:19.34 | *** join/#bzflag bugQ (n=bugQ@c-24-10-254-155.hsd1.ut.comcast.net) |
| 05:19.35 | brlcad | 00:48 <@brlcad> just a bigger overhead burden |
| 05:19.49 | brlcad | there's nothing stopping nobody from using the tracker |
| 05:20.02 | JeffM | I'm looking at moving what we have into the tracker |
| 05:20.09 | JeffM | leaving bugs with just a link to it |
| 05:20.22 | brlcad | people use the BUGS file because it's simple and low-overhead |
| 05:20.30 | brlcad | i'm all for low-overhead |
| 05:20.53 | JeffM | but if I do the work of moving them to the tracker after a bit, you don't care? |
| 05:20.55 | brlcad | i know i wouldn't likely record bugs if I had to go through the tracker each time .. |
| 05:21.06 | L4m3r | just move anything that's been there more than 3 months or so into the tracker |
| 05:21.15 | JeffM | ok, so we keep the file and those that feel like it migrate it :) |
| 05:21.40 | JeffM | are you less likely to fix or close bugs that are in the tracker? or less likely to look at bugs because they are in the tracker? |
| 05:21.49 | javawizard2539 | pacman87, it's _laserAdVel |
| 05:21.54 | javawizard2539 | finally figured that out |
| 05:22.15 | brlcad | I got no problem with you syncing it or moving your bugs to it -- but as a scratchpad for devs to keep track of bugs they notice (as opposed to bugs users report), it's really a big win to have that file handy |
| 05:22.28 | javawizard2539 | I'm going to make a note of that in the wiki, the description was less than helpful |
| 05:22.28 | JeffM | k |
| 05:22.52 | JeffM | brlcad: do you prefer sorted by category or by date in the file? |
| 05:23.13 | JeffM | and would you be adverse to a bugs file that could be read by say a spreadsheet and then sorted? |
| 05:24.07 | brlcad | it really doesn't/shouldn't matter how they're sorted to me -- but given a choice I'd probably pick by date so that it's clear which bugs are recent, which are old |
| 05:24.28 | JeffM | then I need to revert it and put it back by date |
| 05:24.45 | Lukstr | JeffM: Rather than a spreadsheet it's probably best if they're sortable by something like cut |
| 05:24.55 | Lukstr | (unix tool) |
| 05:25.02 | JeffM | cut? |
| 05:25.29 | Lukstr | so the file would still be readable (nothing fancy) but organized in such a way it could be easily shred for data |
| 05:25.45 | Lukstr | also could be parsed as a spreadsheet by excel or something |
| 05:25.51 | JeffM | I don't run unix so having it sortable by a tool I don't use is somewhat pointless |
| 05:26.01 | JeffM | since I think I'm the only one that wants them sortable |
| 05:26.10 | Lukstr | as long as everythings seperated by the same thing |
| 05:26.11 | Lukstr | like a tab |
| 05:26.17 | Lukstr | so you could do (for example) |
| 05:26.24 | JeffM | thats what I was thining of tab delimited |
| 05:26.25 | brlcad | the fact that you even need some higher level management really just begs that we really should stop adding new features and only fix bugs for a long while .. instead of mostly ignoring them as they come up while new features keep getting injected that add even more bugs |
| 05:26.45 | Lukstr | username\tdate-bug-added\tdescription |
| 05:26.46 | JeffM | brlcad: I'm trying to sort them to fix them :) |
| 05:26.48 | brlcad | JeffM: i don't mind by category, there is use in that |
| 05:27.02 | JeffM | but yes, we need to fix bugs |
| 05:27.11 | JeffM | I'm trying to fix a big bug |
| 05:27.16 | brlcad | just said if i had to pick, i'd pick date, but it really doesn't matter -- it's supposed to be dev notes |
| 05:27.55 | JeffM | we also have a number of new people looking for stuff to fix, so I'm trying to think of ways to help make that less daunting |
| 05:27.56 | brlcad | just like TODO isn't really a formalized release plan beyond our notions of what is left for this current release |
| 05:28.24 | brlcad | there's more than enough bugs in the tracker already for them to pick from no? :) |
| 05:28.26 | JeffM | well I'll leave it like is now and we can see how it goes |
| 05:28.40 | JeffM | brlcad: yes and no |
| 05:28.53 | brlcad | if they actually ever emptied out that list, I'd gladly fill in more ;) |
| 05:28.56 | JeffM | I was just trying to see if we could consoldate and manage a little more |
| 05:29.26 | JeffM | I've noticed that the 2 weeks I buged people to fix bugs, more use of the tracker and bugs list was had |
| 05:29.27 | JeffM | a lot more |
| 05:29.32 | JeffM | and a number of bugs got fixes |
| 05:29.34 | JeffM | that's good |
| 05:29.37 | brlcad | that's great |
| 05:29.40 | JeffM | that tells me that some light pressure does help |
| 05:29.48 | JeffM | so some light management should help as well |
| 05:31.06 | brlcad | that's still not what the BUGS file is supposed to be for, at least historically -- it's not really supposed to be user-reported bugs, should be dev-to-dev chatter and notes for relatively current issues we notice |
| 05:32.37 | JeffM | what I don't like about bugs is it's harder to find out more info about the issue |
| 05:33.01 | brlcad | like I said, I've got no problem with folks using the tracker .. it's requiring commit-capable devs to fill out tracker items for the short-lived or minor bugs |
| 05:33.14 | JeffM | no I wasn't thining about requiring |
| 05:33.29 | JeffM | but more of a movement of larger items from the bugs list to the tracker |
| 05:33.37 | JeffM | having that be chatter, that makes ense |
| 05:33.47 | JeffM | notice something.. throw it in bugs |
| 05:33.47 | brlcad | it's "harder", but not hard -- you see who added the line and ask them |
| 05:33.59 | JeffM | yeah it's not imposible |
| 05:34.16 | brlcad | it's easier for them to report -- the point is that they *won't* report it if the reporting is not instant |
| 05:34.34 | JeffM | makes sens |
| 05:34.52 | brlcad | process for the sake of those processing doesn't benefit them -- just adds to their burden |
| 05:35.11 | JeffM | soo.. who's gonna fix solo bots? |
| 05:35.20 | brlcad | if the item requires discussion or ages, I could see removing it and adding a tracker for it |
| 05:35.41 | JeffM | solo bots have been broken for 2 years |
| 05:35.50 | brlcad | exactly! .. the features should have probably halted when it was noticed they weren't working to figure it out |
| 05:36.06 | JeffM | it was noticed |
| 05:36.13 | JeffM | 2 months after they broke |
| 05:36.19 | brlcad | and then duely ignored :) |
| 05:36.27 | brlcad | by everyone |
| 05:36.29 | JeffM | pointed out to the dev to the very commit |
| 05:36.34 | JeffM | indeed |
| 05:37.05 | JeffM | I didn't fix it cus I was blamed for making it break when it was that what blamed me that broke it. |
| 05:37.24 | JeffM | and I ain't touchin networking for a while, every time I do I break the code for a month :) |
| 05:37.29 | JeffM | shots is gonna be hard enough |
| 05:38.11 | JeffM | all this work just to fix a number of shot bugs and cheats :( |
| 05:38.22 | brlcad | sees that as new development/feature anyways.. |
| 05:38.35 | JeffM | well I'm fixing the bugs by adding the features |
| 05:38.52 | JeffM | since the "bugs" are more problems with our core protocoll |
| 05:39.02 | JeffM | last shot of a limted shot, etc.. |
| 05:39.32 | JeffM | yeah I could probalby cheeze out the fix some other way, but it'd just make the code worse |
| 05:40.28 | brlcad | and adding a "fix" that injects some unknown other issue is better? kinda self-defeating :) |
| 05:40.41 | brlcad | at least injects with some non-zero likelihood |
| 05:41.09 | brlcad | the latter never ends, viscious cycle |
| 05:41.11 | JeffM | the cheeze fix would have it's own unknowns |
| 05:41.22 | JeffM | what would you have me do? just ignore the bug? |
| 05:41.27 | JeffM | or make the code more cluttered? |
| 05:41.43 | brlcad | depends on the effort involved for each :) |
| 05:42.04 | JeffM | my choices were back update the shot from the server state |
| 05:42.27 | JeffM | or hack in something where the client does logic to track shot limits |
| 05:42.31 | brlcad | cluttered and ready tomorrow would be better over "right" that takes two+ weeks |
| 05:42.53 | brlcad | as there's dozens of those issues |
| 05:42.55 | JeffM | for all the shot bugs I have to fix, the cluttered fixes would probalby take me over a couple weeks |
| 05:43.05 | JeffM | fine, no server shots then |
| 05:43.10 | JeffM | I'll move on to something else |
| 05:43.34 | JeffM | hope lag dosn't break it |
| 05:44.44 | brlcad | i mean do you really think it can be completed before summer? I think at some point we really have to get back to more frequent compatible release iterations |
| 05:44.55 | L4m3r | I'm actually having a similar issue like that |
| 05:45.06 | L4m3r | my map runs a plugin that assigns flags on spawn |
| 05:45.10 | JeffM | brlcad: think what can be? 3.0? |
| 05:45.14 | JeffM | no it can't be |
| 05:45.20 | L4m3r | geno is an exception... it can only be used once, then another flag is given |
| 05:45.22 | JeffM | we knew it was a long shot |
| 05:45.35 | JeffM | but I was trying to fix things the "right" way |
| 05:45.42 | L4m3r | and once in a while someone kills with geno, and keeps shooting, and gets kicked :( |
| 05:45.52 | JeffM | if we want to be slopy we may be able to make something by mid summer |
| 05:46.05 | JeffM | then blow a couple months after cleaing up the mess we made |
| 05:46.07 | JeffM | IMHO |
| 05:46.37 | JeffM | L4m3r: there are lots of issues with shots that I was trying to fix with the big change |
| 05:46.56 | L4m3r | I don't think a "sloppy" release would be a good idea for a new, non-compatible version |
| 05:47.01 | blast007 | JeffM: is the "cannot distribute binaries" thing for all of the Express Edition tools, or just for VC++ EE? |
| 05:47.16 | brlcad | the problem I see is that is pretty much *exactly* what we said this time last year, just with a different set of bugs -- and features continued and we're now no closer to a release than we were a year ago (in fact we're probably father away) |
| 05:47.21 | JeffM | blast007: I belive al EE |
| 05:47.25 | blast007 | k |
| 05:47.49 | JeffM | brlcad: then my recomendation is to branch trunk as a 3.0 branch and start rolling things out of it |
| 05:47.53 | JeffM | seriously |
| 05:48.35 | brlcad | I think way too much has changed to merge piecemeal ala 1.8 |
| 05:48.47 | JeffM | pull the tank model, pull the shot stuff, pull the bot changes, hell pull lag comp |
| 05:49.15 | L4m3r | why the model? |
| 05:49.22 | JeffM | I don't wnat to loose that code, but I can understand if it dosnt' need to go into 3.0 |
| 05:49.22 | L4m3r | is it that huge of a change, in the technical sense? |
| 05:49.30 | JeffM | L4m3r: yes |
| 05:49.33 | JeffM | and it's not done |
| 05:49.42 | brlcad | massive set of changes |
| 05:49.44 | JeffM | basicly we can pull/revert the 1/2 ass crap |
| 05:50.01 | JeffM | I don't mind, I just don't want to loose that code in trunk, as it CAN be finished |
| 05:50.24 | L4m3r | there's also the protocol to consider |
| 05:50.28 | JeffM | and I think it SHOULD be finished as part of a future trunk |
| 05:50.42 | brlcad | L4m3r: we've been "considering the protocol" for 2 years now |
| 05:50.46 | JeffM | so I don't want to shuck it over to a branch that will be forgoten |
| 05:50.59 | brlcad | we're talking about moving the whole logic to the server, the protocol gets turned inside out |
| 05:51.04 | L4m3r | releasing 3.0 that way could result in immediate starting of 4.0, with so many half-done features :) |
| 05:51.08 | JeffM | L4m3r: we ain't going to get server side stuff for 3.0 that's prety much a given at this point in the converattion |
| 05:51.16 | JeffM | L4m3r: so? |
| 05:51.31 | JeffM | that was brlcad's point more releases more often |
| 05:51.54 | L4m3r | "compatible releases" :P |
| 05:52.04 | JeffM | brlcad: if the 3.0 branch idea is valid to you, I'll start yankin, I don't mind |
| 05:52.34 | brlcad | i mean 3.0 can't just be released for the sake of releasing it, certainly has to be production stable .. if we're months away then so-be-it but part of me says that if we can get away with bandaids that we know *will* hold through a 3.0 then we should |
| 05:52.37 | *** join/#bzflag KTL (n=KTL@213.219.152.239.adsl.dyn.edpnet.net) |
| 05:52.56 | JeffM | brlcad: I don't think we can bandaid with out pulling some features |
| 05:52.59 | brlcad | the 3.0 branch doesn't save us any more/less work -- there's too many changes that are intermingled |
| 05:53.09 | JeffM | so how do you want to handle the pulls? |
| 05:53.32 | JeffM | brlcad: so what do you want to do? |
| 05:54.19 | BulletCatcher | If we pull too many features, won't that just leave us with something that really only deserves to be called 2.1 or 2.2? |
| 05:54.20 | brlcad | it's like you mentioned, even branching back, there's no guanteed that pulling over feature X isn't going to also have an entirely different set of bugs (especially given all the changes are usually intermingled) |
| 05:54.47 | JeffM | brlcad: so we finish off what we have started? |
| 05:54.53 | brlcad | so I really don't see that as a useful option, we keep going forward |
| 05:55.15 | JeffM | so we accept that we won't hit summer? |
| 05:55.33 | brlcad | if that's how it goes, I suppose so |
| 05:55.36 | DTRemenak | what bugs do we have remaining? |
| 05:56.05 | brlcad | the problem will be what to do about the work happening over the summer, particularly new features that will just as likely be introducing yet another set of new bugs that will hold things back or simply be untested |
| 05:56.14 | JeffM | kicking dosn't work, mesh collsions, tank models are 1/3 ass. |
| 05:56.31 | DTRemenak | are any of those actual regressions from 2? |
| 05:56.39 | JeffM | kicking is |
| 05:56.40 | DTRemenak | aside from kicking, which I don't see in bugs? |
| 05:56.54 | JeffM | it's in there somewhere as "communication error" |
| 05:57.04 | JeffM | the client dosn't know it got kicked |
| 05:57.24 | JeffM | if we want to just go with regressions, then there is less, and some half done features |
| 05:57.24 | brlcad | tank models aren't a show-stopper -- that was never expected, just very cool -- and it's a new feature so as long as they don't know about it, there's no difference to them and it can get finished for 4 |
| 05:57.37 | JeffM | brlcad: then it needs to be pulled |
| 05:57.44 | JeffM | cus it's currently breaking stuff |
| 05:57.49 | brlcad | how so? |
| 05:57.49 | JeffM | treads, etc.. |
| 05:57.56 | JeffM | a lot of stuff is disabled |
| 05:58.01 | JeffM | covers, treads and the like |
| 05:58.15 | brlcad | that's not a protocol breaker or major feature, could still be fixed on the 3 line |
| 05:58.18 | JeffM | so if we want it to work like 2.0 I have to turn it off and put some code back |
| 05:58.28 | JeffM | I mean if we just want it to WORK like 2.0 |
| 05:58.41 | JeffM | right now 3.0 does not look the same as 2.0 re. tanks |
| 05:58.47 | JeffM | not for all config modes |
| 05:59.07 | JeffM | so I have to ether pull parts of it, or finish it |
| 05:59.21 | JeffM | I took out the spinning wheels for example |
| 05:59.24 | brlcad | I'd vie to keep the models stubbed in like they are without treads -- treads are a pretty minor "feature" and lets us move forward |
| 05:59.37 | JeffM | brlcad: no I mean for ALL tanks |
| 05:59.42 | brlcad | iirc, those features were originally added on a minor anyways |
| 05:59.51 | JeffM | I broke drawing of legacy tanks, not loaded models |
| 06:00.22 | JeffM | I broke them TO add loaded models |
| 06:00.23 | brlcad | yea, I get it -- they still look like tanks though, and you made a snazzy new model |
| 06:00.30 | JeffM | no I don't |
| 06:00.35 | JeffM | we don't use the snazzy new model |
| 06:00.52 | JeffM | we have the start of the technology to use the new model but more work as to be done to get it all working |
| 06:00.53 | brlcad | that's just loading a diff model though |
| 06:01.02 | JeffM | it's more then that |
| 06:01.10 | JeffM | we currently arn't drawing all the tank from the model |
| 06:01.16 | JeffM | even if you load it |
| 06:01.20 | JeffM | it'll screw up some parts |
| 06:01.20 | brlcad | okay, but still .. so it looks like the old tank minus the animation foo |
| 06:01.34 | JeffM | yes, that is a regression from 2.0 |
| 06:01.44 | JeffM | if you turn on open treads, you don't get them |
| 06:01.48 | JeffM | you get covers |
| 06:01.52 | brlcad | petty to me, especially since its' something we could fix with 3.1 |
| 06:02.14 | brlcad | they have new shots and textures to gawk at |
| 06:02.43 | JeffM | peronaly I'd go and just disable the model loads and move the code back to the old legacy stuff |
| 06:02.47 | JeffM | it's like an hours work |
| 06:02.59 | JeffM | then finish it right for 3.2 |
| 06:03.08 | brlcad | so non issue either way, all client-side :) |
| 06:03.18 | JeffM | it's never been server side |
| 06:03.20 | JeffM | ever |
| 06:03.39 | JeffM | do we intend to fix the mesh->box bug in 3.0? |
| 06:03.43 | brlcad | could be left at a penalty of the animation features, or ripped back temporarily |
| 06:03.56 | JeffM | penalty of the animation features? |
| 06:04.00 | JeffM | what does that mean? |
| 06:05.17 | brlcad | er, I mean we could leave them and take the penalty (of animations not working) or rip them out temporarily and fix later -- that's not a critical release issue then |
| 06:06.33 | brlcad | if the mesh-box bug is in 2.0, then also don't see that as critical |
| 06:06.35 | DTRemenak | so what exactly is the rush to release rather than fix things? |
| 06:06.50 | JeffM | brlcad: then if you are in a rush, fix bots and ship it |
| 06:07.03 | JeffM | and I'll be working on 3.2 / 4.0 |
| 06:07.43 | brlcad | it's not a "rush", it's not doing the status quo for yet another year with regard to new features |
| 06:08.28 | JeffM | but it's also not fixing things in a long term maintainable way |
| 06:08.36 | JeffM | it's doing quick hacks |
| 06:08.39 | JeffM | like the shot thing |
| 06:08.52 | JeffM | personaly I'd rather have right then fast |
| 06:09.01 | Manu | yawns |
| 06:09.05 | DTRemenak | brlcad: so I'm curious, what features in the last 3 months have been checked in that shouldn't have? |
| 06:09.05 | brlcad | the problem I see brewing is that some progress will get made on fixing a lot of things by this summer and then we have the surge of manpower and changes moving code all the heck over the place (causing more/new bugs, fixing some old, but more likely injecting new) |
| 06:09.09 | JeffM | I see your point that we don't want to get into the trap that we get into all the time |
| 06:09.46 | brlcad | that is my only point |
| 06:09.49 | Manu | JeffM: no response from bugQ, but I see he joined here |
| 06:10.02 | DTRemenak | as I see it, we're already working primarily on bugfixes (and there've been a lot of them) |
| 06:10.07 | JeffM | ok, so given that a bunch of stuff is going to move around, what do you think the likely hood of that SoC/dev work breaking protocll? |
| 06:10.19 | JeffM | I see 3 of them that can do so |
| 06:10.20 | brlcad | and just temperature of the development path looks like we're heading down that path again |
| 06:10.46 | JeffM | that means that all the SoC work is done on 4.0 if we want to get 3.0 out before summer |
| 06:11.01 | JeffM | or branches that will become 4.0 |
| 06:11.06 | brlcad | DTRemenak: we have been better on bugs (and I don't have a specific feature in mind, at least for 3 month timeframe) |
| 06:11.50 | DTRemenak | ok, so if you think things will be getting too warm, branch for 4.0. let the shot stuff be the last major change to 3.0, test it, fix it, ship it |
| 06:11.50 | JeffM | if we seriously want to ship before summer, we need a list of critical fixes now, so we can start mass testing as soon as possible |
| 06:12.30 | JeffM | we can't even verify that lag comp works, I'd move shots to 4.0 for that |
| 06:12.45 | JeffM | I mean if we are talking about "if it was busted in 2.0 leave it" |
| 06:12.53 | JeffM | all the shot bugs are in all old versions |
| 06:13.04 | DTRemenak | shots in general are broken as they stand (not to mention flawed by design) |
| 06:13.13 | JeffM | GM needs to be fixed |
| 06:13.16 | DTRemenak | I'd rather have them fixed right before release |
| 06:13.17 | JeffM | I can fix that the legacy way |
| 06:13.35 | DTRemenak | especially since we gain an aweful lot in terms of preventing cheats from the shot work |
| 06:13.36 | JeffM | but for stuff like the box/mesh problem |
| 06:13.43 | JeffM | the moment we fix that, we have to break protocoll |
| 06:13.50 | JeffM | so there is another 4.0 fix right there |
| 06:14.04 | brlcad | so fixing shots being the "last feature" however long it takes |
| 06:14.24 | JeffM | I'd be against that given our inability to test new features |
| 06:14.38 | brlcad | and branch off 3 to try and stabilize in parallel |
| 06:14.55 | DTRemenak | ok, so box/mesh becomes the first change in the 4.0 line. and I don't think that's bad particularly if one particular soc proposal gets done |
| 06:15.00 | JeffM | if you are leaving other items busted just cus they are busted in 2, then shots can do the same. |
| 06:15.14 | JeffM | DTRemenak: why can't shots be the first in 4.0 then? |
| 06:15.26 | DTRemenak | 'cause it's broken now, primarily |
| 06:15.31 | brlcad | heh |
| 06:15.35 | JeffM | what is broken? |
| 06:15.44 | DTRemenak | do you REALLY want to spend time fixing GM, when you could be fixing the whole thing, right? |
| 06:15.45 | JeffM | as compared to 2.0? |
| 06:16.01 | think_tank | s/could/should |
| 06:16.02 | DTRemenak | and GM is not our only problem, just the most significant regression |
| 06:16.07 | JeffM | DTRemenak: the time to fix GM the legacy way will be less then the time for me to finish the shot overhual |
| 06:16.20 | DTRemenak | but it's time that DOES NOT have to be spent at all |
| 06:16.26 | JeffM | what else with shots is broken that wasn't broken in 2.0? |
| 06:16.44 | brlcad | what's the difference in level of effort -- how much effort is wasted? |
| 06:16.59 | JeffM | that's why I want to know what else |
| 06:17.06 | JeffM | the GM thing is some small problem I fear |
| 06:17.09 | JeffM | nothing major |
| 06:17.22 | JeffM | its' basicly find what moved and make it work like it used to in 2.0 |
| 06:17.33 | JeffM | rather then imlement a complete server side shot tracking solution |
| 06:17.43 | DTRemenak | "what moved" was another major change iirc |
| 06:17.45 | brlcad | probably just another pack problem ;) |
| 06:17.48 | JeffM | and it wont' be wasted work cus I have to dig thru the client side code to understand it |
| 06:17.49 | DTRemenak | no, it's not |
| 06:17.52 | DTRemenak | it's predating that |
| 06:17.54 | brlcad | is kidding |
| 06:18.14 | JeffM | DTRemenak: what broke it then? care to give me what you think it is? |
| 06:18.31 | JeffM | I haven't dug into the GM tracking code yet at all |
| 06:18.33 | DTRemenak | I don't remember. Debugged it a while back, had it pinned to like a 2-week "crazy dev" period |
| 06:18.56 | JeffM | well no mater what, I have to understand that logic |
| 06:18.57 | brlcad | not nice to talk about lan56 like that |
| 06:19.03 | DTRemenak | hah |
| 06:19.18 | JeffM | what other shot issues do you know about? |
| 06:19.20 | DTRemenak | the period was one of crazy development, not the developer was crazy :) |
| 06:19.25 | JeffM | so I can evaluate what would take more time. |
| 06:19.37 | DTRemenak | shots in replays are completely busted |
| 06:19.54 | JeffM | that's probably just packing options |
| 06:20.02 | JeffM | what else? |
| 06:20.15 | JeffM | cus I mean my shot change, won't change replays |
| 06:20.23 | JeffM | so that's a seperate thing that would need it's own time anyway |
| 06:20.45 | DTRemenak | pretty sure there were some other things, but I didn't care because you were redoing it all anyway |
| 06:21.00 | JeffM | well I need to make sure that my redo will actualy get them all |
| 06:21.08 | DTRemenak | and that's my point...we've been operating on the assumption that someone was going to "do shots" for like the last year and a half |
| 06:21.09 | JeffM | replay is a good example of something I woudl not touch |
| 06:21.19 | DTRemenak | so we better damn do it, otherwise we break all our assumptions |
| 06:22.13 | JeffM | so what's the verdict then? |
| 06:22.13 | brlcad | JeffM: wouldnt' think it's a matter of which is more -- it's absolute time -- if you'd be wasting more than a couple days time, it's probably just best to move forward |
| 06:22.32 | JeffM | brlcad: I'm more worried about our abillity to test |
| 06:22.47 | DTRemenak | 2.0 showed us that testing goes fine when we build public betas |
| 06:22.49 | JeffM | the shot thing.. will be nasty |
| 06:22.53 | JeffM | that I can be sure of |
| 06:22.55 | DTRemenak | we just have to get it to a point where we can do it |
| 06:22.58 | JeffM | it WILL make more bugs |
| 06:23.23 | DTRemenak | sure |
| 06:23.26 | JeffM | even right now it's starting to get daunting for me |
| 06:23.32 | DTRemenak | but fixing those bugs is right from a long term perspective |
| 06:23.35 | JeffM | I do not look forward to working on it each night |
| 06:23.38 | DTRemenak | then check it in to a branch and let someone help |
| 06:24.02 | JeffM | I'm not suposed to check in things that don't compile |
| 06:24.08 | DTRemenak | ...to a branch... |
| 06:24.16 | JeffM | then it WILL be forgoten |
| 06:24.20 | JeffM | that is certan |
| 06:24.21 | brlcad | or get one of the refactoring students to work on it :) |
| 06:24.28 | DTRemenak | no more forgotten than if you just leave it on your machine |
| 06:24.29 | JeffM | brlcad: HAH |
| 06:24.55 | JeffM | DTRemenak: nether of those options affect what we do for 3.0 |
| 06:24.56 | brlcad | lost his culled timestamps mods that way |
| 06:24.58 | JeffM | and that was the discussion |
| 06:25.12 | JeffM | brlcad: have you looked at the refector proposals |
| 06:25.17 | JeffM | not a single one has submited a patch |
| 06:25.19 | brlcad | yeah.. |
| 06:25.26 | JeffM | or even responded |
| 06:25.36 | DTRemenak | sure. it'll make more bugs. so we get to fix more bugs. big deal, it'll let us get familiar with the new code. |
| 06:25.37 | JeffM | at this point they all are invalid |
| 06:25.42 | brlcad | then there is no refactor proposals |
| 06:25.46 | JeffM | indeed |
| 06:25.50 | JeffM | I mean I'll do it |
| 06:25.59 | JeffM | I"ll trudge thru this and finish it |
| 06:26.00 | DTRemenak | there are two that are narrowed down more than the general ones, which are valid |
| 06:26.04 | JeffM | to the point where it'll compile |
| 06:26.30 | JeffM | if I finish this then that does help one of the SoC proejcts imenesly |
| 06:26.46 | JeffM | so I have to finish it at some point even if it's just as his mentor |
| 06:26.54 | JeffM | so I'm not worried about it being lost |
| 06:27.05 | JeffM | my point of contention here is what to do for 3.0 |
| 06:27.39 | JeffM | I mean I don't feel that my time spent on shots was wasted |
| 06:27.45 | Lukstr | hey, if I got libbzw done early... |
| 06:27.47 | JeffM | I know a LOT more about how they work now |
| 06:27.48 | DTRemenak | if it's anything but trivial to get all varieties of shots working in all conditions on 2.99, we should not bother, imho |
| 06:27.59 | DTRemenak | Lukstr: ohh, I have plans for if you get done early <evil grin> |
| 06:28.04 | Lukstr | runs |
| 06:28.11 | JeffM | yeah your his meat :) |
| 06:28.19 | brlcad | where trivial is how many days/weeks? |
| 06:28.36 | JeffM | and not bother with what? the big change? or the micro changes? |
| 06:29.02 | DTRemenak | not bother with fixing the existing bugs, especially those that we know will change significantly with the shot work |
| 06:29.09 | DTRemenak | 'cause it's a waste of time |
| 06:29.21 | JeffM | I think the thing I should do is look into why GM dosn't work on trunk as is. then I can 1) know how they work for my big change, and 2) better know how long it will take to fix |
| 06:29.28 | DTRemenak | if they're trivial, then sure. but I think they're not. |
| 06:29.32 | JeffM | the replay thing I know I will NOT be fixing ith my shot change |
| 06:29.40 | JeffM | I would need to know what the other shot bugs are. |
| 06:29.51 | DTRemenak | yeah, replay will need some reworking anyway |
| 06:30.44 | brlcad | the replay servers in use can probably be counted on one hand |
| 06:31.00 | DTRemenak | several of them are rather important to their users, though |
| 06:31.05 | DTRemenak | gu, for instance |
| 06:31.41 | BulletCatcher | If replays regress, league players may choose to stay with 2.0. |
| 06:31.43 | brlcad | feeling as to whether it's protocol or just the (bastardized) way reply writes out its data? |
| 06:31.52 | JeffM | will agree to which ever party's proposal involves swaping to BSD style brackets :) |
| 06:31.54 | DTRemenak | and hey, I'm not necessarily opposed to telling the people who care that we're not making it a priority for 3.0, so if they want it fixed they should do it themselves |
| 06:32.01 | brlcad | if it's not protocol, it's server side and could also be a 3.1 promise |
| 06:32.21 | DTRemenak | doesn't matter where the problem came up, replay needs to adapt to the protocol, not the other way around |
| 06:32.48 | brlcad | replay broke in the first place because it was totally hacked in |
| 06:32.50 | DTRemenak | so yeah, it could be later than 3.0. but BulletCatcher is right. |
| 06:32.52 | JeffM | my guess is that replay isn't packing the game mode correctly cus I changed it |
| 06:33.03 | JeffM | and it dosn't set servers are having rico to true |
| 06:33.06 | JeffM | it should be easy to track down |
| 06:33.26 | JeffM | rico is controlled by the mode, not per shot, so it has to be somethign like that |
| 06:33.38 | JeffM | cus the client dosnt' see any diff from a replay message or a real message |
| 06:34.06 | JeffM | so blowing it off with out even doing a cursory eval is stupid |
| 06:35.18 | DTRemenak | and I don't buy that we haven't made any progress. six months ago we couldn't even connect to a server. |
| 06:35.43 | JeffM | yeah I do belive we are a lot more playable |
| 06:36.25 | brlcad | statement was progress towards being closer to a release compared to this time last year |
| 06:36.28 | JeffM | god I miss increedbuild |
| 06:36.55 | DTRemenak | doesn't remember much about this time last year, but certainly recalls that it wasn't playable :) |
| 06:36.57 | brlcad | otherwise, of course, there are a ton of features and fixes |
| 06:37.23 | brlcad | remembers going on a similar rant for a few days |
| 06:37.31 | DTRemenak | too |
| 06:37.36 | JeffM | it must be spring :) |
| 06:37.38 | brlcad | because we missed the winter release |
| 06:38.15 | JeffM | see I started the shot thing when I was trying to fix bugs in the bugs list |
| 06:38.26 | brlcad | it was the first time (ever) that we "missed" that release line we tend to draw in (quick)sand |
| 06:38.30 | JeffM | and in discussion the best way to fix it was this way |
| 06:38.39 | JeffM | but those bugs were legacy bugs |
| 06:38.50 | DTRemenak | we missed it because we chose not to release 2.0 again, if you want to look at it that way |
| 06:38.51 | brlcad | spring cleaning :) |
| 06:38.57 | DTRemenak | branch was already a year old plus |
| 06:39.06 | JeffM | who's got a trunk client that can help me test? |
| 06:39.11 | DTRemenak | mine's building |
| 06:39.17 | BulletCatcher | I just built one an hour ago. |
| 06:39.17 | DTRemenak | has been since we started this thing :) |
| 06:39.30 | JeffM | DTRemenak: your server have GM? |
| 06:39.39 | DTRemenak | server's still building too |
| 06:39.46 | DTRemenak | and my current test server is noflags |
| 06:39.49 | JeffM | I can start one on mirkwood |
| 06:39.51 | JeffM | one sec |
| 06:39.54 | DTRemenak | I can pull another one up if you want |
| 06:39.57 | JeffM | 5156 is free I think |
| 06:40.11 | JeffM | there is a current build in my home dir |
| 06:40.11 | DTRemenak | yeah, I think mine is on 5150 |
| 06:40.14 | JeffM | dev/bz3 |
| 06:40.26 | JeffM | fire one off random map 3 shot, assloads of GM |
| 06:41.39 | JeffM | if you have a terminal open to it |
| 06:41.40 | JeffM | I don't |
| 06:42.02 | DTRemenak | k, running |
| 06:42.09 | DTRemenak | hm, probably ought to list it huh |
| 06:42.10 | JeffM | done got breakpoints set :) |
| 06:42.18 | JeffM | probably |
| 06:42.21 | JeffM | it can be ip |
| 06:42.46 | DTRemenak | k, should be running |
| 06:43.31 | DTRemenak | and my client finished |
| 06:43.36 | DTRemenak | joins |
| 06:54.46 | JeffM | I need to compare something |
| 06:54.51 | JeffM | the target ID is invalid |
| 06:55.46 | *** part/#bzflag mayB (n=mayur@c-67-191-238-17.hsd1.ga.comcast.net) |
| 06:57.41 | JeffM | I think I know what it is |
| 07:00.43 | CIA-32 | BZFlag: 03JeffM2501 * r16941 10/trunk/bzflag/src/bzfs/ (bzfsClientMessages.cxx bzfsMessages.cxx bzfsMessages.h): unpack and pack the target player with the GM updates so the client dosen't read garbage |
| 07:01.57 | JeffM | server is rebuilding now |
| 07:03.04 | DTRemenak | something is junk in the lag comp or something too. lots of nr going on, people popping around on the map, etc |
| 07:03.23 | JeffM | would not suprise me |
| 07:03.34 | JeffM | hence my statement that I doubt what we can test |
| 07:03.48 | JeffM | but maybe we can get people to bang on it and actualy debug it |
| 07:03.52 | BulletCatcher | Other than the lag problem, shooting regular bullets was quite playable. |
| 07:05.38 | JeffM | I"m betting this is the GM bug |
| 07:08.10 | *** join/#bzflag Gilly (n=btw@83.146.211.140) |
| 07:08.41 | JeffM | server build... so.... slow.... |
| 07:08.58 | BulletCatcher | just press the turbo button :-) |
| 07:09.14 | JeffM | like I have physical access to the machine |
| 07:09.17 | JeffM | it's in florida |
| 07:09.30 | JeffM | my local build finished Long long long ago |
| 07:09.31 | DTRemenak | mine finished |
| 07:09.39 | DTRemenak | with your updates even |
| 07:09.39 | BulletCatcher | There is never a robotic arm available when you need one. |
| 07:09.44 | DTRemenak | want me to start it? |
| 07:09.46 | *** join/#bzflag bier (n=bier@p54A57A8E.dip.t-dialin.net) |
| 07:09.52 | JeffM | well maybe that's why it' slow, we are doing 2 builds on the same machine :) |
| 07:09.54 | JeffM | DTRemenak: yeah |
| 07:09.58 | BulletCatcher | lol |
| 07:10.43 | DTRemenak | k, running |
| 07:15.30 | JeffM | it's the shot ID |
| 07:15.35 | JeffM | the fix I did would just do the horn |
| 07:15.54 | JeffM | it's the salt I fear |
| 07:24.30 | JeffM | I'm getting shot IDs way out of range, and the salt calc isn't working right |
| 07:26.10 | DTRemenak | another thing that'd be fixed by your stuff |
| 07:27.11 | JeffM | yeah |
| 07:27.16 | JeffM | but this should be working |
| 07:27.32 | JeffM | I mean it's code I was just going to copy and paste that isn't working |
| 07:27.42 | DTRemenak | I thought you were killing the salt? |
| 07:27.56 | JeffM | as far as I can tell now the SALT is fine |
| 07:28.00 | JeffM | it's something in the pack or unpack |
| 07:28.06 | JeffM | my salt is increasing as it should |
| 07:28.09 | JeffM | YOURS is not |
| 07:29.05 | BulletCatcher | whacks DTRemenak for not passing the salt |
| 07:29.35 | DTRemenak | peppers BulletCatcher with salt |
| 07:30.11 | BulletCatcher | sneezes |
| 07:30.18 | JeffM | I'm going to have to 3 way debug this |
| 07:30.30 | JeffM | my local salts are coming back fine |
| 07:31.08 | JeffM | DTRemenak: you on linux right now? |
| 07:31.08 | DTRemenak | no |
| 07:31.08 | JeffM | hmm |
| 07:31.20 | JeffM | the salt value is suposed to start at 256, then 512, 1024, etc.. |
| 07:31.28 | JeffM | then the shot is added to that |
| 07:31.34 | JeffM | mylocal salt is fine |
| 07:31.57 | JeffM | your guys's salts were coming in at like 519, 520, 521, 519 |
| 07:32.04 | JeffM | well your shot IDs |
| 07:32.22 | JeffM | so we'd blow off the hibyte and get ids like 7, 8, and 9 |
| 07:32.31 | JeffM | all out of range |
| 07:34.45 | BulletCatcher | JeffM: When you say yours is correct, is that from the server's view or the clients? |
| 07:34.57 | JeffM | that's what I'm trying to see |
| 07:35.15 | JeffM | I'm debuging a server now to see what I see |
| 07:35.19 | BulletCatcher | k |
| 07:35.22 | DTRemenak | -ddd logs from that server are in /home/danielr/test.out if they help |
| 07:35.47 | JeffM | naw I see another oddity |
| 07:38.17 | CIA-32 | BZFlag: 03JeffM2501 * r16942 10/trunk/bzflag/src/bzfs/bzfsMessages.cxx: when packing a shot update for GM from the server, don't pack the player in seperately, the shot pack will pack the shooter in. |
| 07:38.26 | JeffM | update to that if you can |
| 07:39.33 | DTRemenak | k, updated |
| 07:40.02 | DTRemenak | and running |
| 07:40.33 | BulletCatcher | Should I recompile the client? |
| 07:40.40 | DTRemenak | no need |
| 07:41.49 | JeffM | I'm in I need a victim :) |
| 07:42.05 | BulletCatcher | I'll be there in a moment... |
| 07:43.51 | DTRemenak | is trying to fix bzadmin |
| 07:45.07 | JeffM | I see them track now, so we get a valid shot path but they don't track right |
| 07:45.11 | JeffM | getting closer |
| 07:45.16 | JeffM | I'll do the rest tomorow |
| 07:45.18 | JeffM | I'm pooped |
| 07:45.25 | BulletCatcher | sleep time. |
| 07:45.30 | BulletCatcher | good work so fare |
| 07:45.33 | BulletCatcher | *far |
| 07:47.43 | CIA-32 | BZFlag: 03dtremenak * r16943 10/trunk/bzflag/src/bzadmin/BZAdminClient.cxx: don't crash upon receiving an unrecognized message type |
| 07:48.37 | *** join/#bzflag JeffMMain (n=Jeff@pool-71-109-218-124.lsanca.dsl-w.verizon.net) |
| 08:07.04 | *** join/#bzflag LongDon (n=LongDon@vpn199-062.hrz.uni-oldenburg.de) |
| 08:08.12 | *** part/#bzflag LongDon (n=LongDon@vpn199-062.hrz.uni-oldenburg.de) |
| 08:09.08 | *** join/#bzflag Dessy (n=Dessy@88-134-204-43-dynip.superkabel.de) |
| 08:16.21 | *** join/#bzflag Pimpi (n=frank@gondolin.pimpi.org) |
| 08:20.45 | Constitution | ~dtremenak++ |
| 08:20.48 | Constitution | ~jeffm2501++ |
| 08:21.36 | *** join/#bzflag bier (n=bier@p54A56401.dip.t-dialin.net) |
| 08:23.44 | *** join/#bzflag Saturos (n=Saturos@p57A0E607.dip.t-dialin.net) |
| 08:28.14 | *** join/#bzflag CBG (n=CBG@cpc2-stme1-0-0-cust307.cdif.cable.ntl.com) |
| 09:23.24 | *** join/#bzflag bier (n=bier@p54A55705.dip.t-dialin.net) |
| 10:00.50 | *** join/#bzflag Chestal (i=thilo@pdpc/supporter/active/Chestal) |
| 10:00.50 | *** join/#bzflag Pimpi (n=frank@gondolin.pimpi.org) |
| 10:00.50 | *** join/#bzflag Dessy (n=Dessy@88-134-204-43-dynip.superkabel.de) |
| 10:00.50 | *** join/#bzflag Gilly (n=btw@about/essy/ilkimys/gilly) |
| 10:00.50 | *** join/#bzflag hobbsc (n=hobbsc@ip70-178-55-100.ks.ks.cox.net) [NETSPLIT VICTIM] |
| 10:00.50 | *** join/#bzflag AHA (n=aha@unaffiliated/aha) |
| 10:00.50 | *** join/#bzflag Wyk3d (n=Wyk3d@lns-bzn-47f-81-56-254-111.adsl.proxad.net) [NETSPLIT VICTIM] |
| 10:00.50 | *** join/#bzflag QuantumTim (n=tim@62-249-230-206.no-dns-yet.enta.net) |
| 10:00.50 | *** join/#bzflag ElectricElf (n=dbharris@bas1-toronto48-1242461309.dsl.bell.ca) [NETSPLIT VICTIM] |
| 10:00.51 | *** join/#bzflag chaoscon (n=jeremy@smartserv/ceo/chaoscon) [NETSPLIT VICTIM] |
| 10:00.51 | *** join/#bzflag pacman87 (i=127@resnet-45-192.dorm.utexas.edu) |
| 10:00.51 | *** join/#bzflag Winny (n=KyleVE@unaffiliated/winny) |
| 10:00.51 | *** join/#bzflag CIA-32 (n=CIA@208.69.182.149) [NETSPLIT VICTIM] |
| 10:00.51 | *** join/#bzflag catay (n=smertens@kaiya.catay.be) |
| 10:00.51 | *** join/#bzflag overcool (n=overcool@pdpc/supporter/student/whodaman-) [NETSPLIT VICTIM] |
| 10:00.51 | *** join/#bzflag donny_baker (n=joevano@about/essy/vvvvv/donnybaker) [NETSPLIT VICTIM] |
| 10:00.51 | *** join/#bzflag uso (n=uso@84-72-8-253.dclient.hispeed.ch) |
| 10:00.51 | *** join/#bzflag Admirarch (i=mwr25@about/essy/AdmiralofBzInc/Admirarch) |
| 10:00.51 | *** join/#bzflag brad (n=brad@moooo.org) |
| 10:00.51 | *** join/#bzflag ts (n=ts@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 10:00.51 | *** join/#bzflag Birdie (n=Birdie@unaffiliated/birdie) |
| 10:00.52 | *** join/#bzflag jorgenpt (n=jorgenpt@wacky.idi.ntnu.no) [NETSPLIT VICTIM] |
| 10:00.52 | *** join/#bzflag dcat (n=dirtycat@pdpc/supporter/active/dcat) [NETSPLIT VICTIM] |
| 10:00.52 | *** join/#bzflag retro (n=ksumrall@wall.danger.com) |
| 10:00.52 | *** join/#bzflag Manu (n=jujibo@about/essy/JujiboHunter/Manu) |
| 10:00.52 | *** join/#bzflag Deepa|AFK (i=deepa@abused.armchairs.be) [NETSPLIT VICTIM] |
| 10:00.52 | *** mode/#bzflag [+ov Chestal Manu] by irc.freenode.net |
| 10:01.32 | *** join/#bzflag ViciousM (n=max@cpe-024-211-248-161.nc.res.rr.com) |
| 11:45.49 | *** join/#bzflag Daveman (n=dave@pool-141-150-16-73.mad.east.verizon.net) |
| 13:00.51 | spldart | Just attempted a buid at 16943 in linux, no time to do windows too. server and both clients failed to build in debug: http://pastebin.bzflag.bz/m67ee7a6a |
| 13:04.11 | *** join/#bzflag Suspect (n=Suspect@68-113-163-117.dhcp.plt.ny.charter.com) |
| 13:37.56 | *** join/#bzflag spldart (n=short_ci@adsl-70-240-241-158.dsl.hstntx.swbell.net) |
| 13:50.22 | blast007 | spldart: k, I see it too. I'll look at when I get back. |
| 13:50.42 | spldart | k |
| 13:50.59 | *** join/#bzflag Dessy (n=Dessy@88-134-204-43-dynip.superkabel.de) |
| 13:51.30 | spldart | One of these days I'm going to tinker with one of these warnings and try to fix it myself ;) One of these days when I have time again hehe |
| 13:57.22 | *** join/#bzflag Dessy2 (n=Dessy@88-134-204-43-dynip.superkabel.de) |
| 14:03.58 | *** join/#bzflag Epyon (n=Epyon@90-156-93-82.magma-net.pl) |
| 14:16.37 | *** join/#bzflag Dessy (n=Dessy@88-134-204-43-dynip.superkabel.de) |
| 14:19.27 | *** join/#bzflag Epyon_ (n=Epyon@90-156-93-82.magma-net.pl) |
| 14:21.33 | spldart | Gah.. I tried. |
| 14:22.58 | Epyon_ | DTRemenak, dammit, someone fixed my target bug D: |
| 14:24.36 | BulletCatcher | JeffM couldn't wait any longer for you to do it, Epyon_ |
| 14:25.00 | Epyon_ | I guess so, I had some problems yesterday, and I wasn't at home at all :/ |
| 14:25.12 | Epyon_ | But what the heck am I going to do now -_- |
| 14:25.28 | BulletCatcher | There are plenty of other bugs waiting. |
| 14:26.11 | Epyon_ | yeah, so cool. |
| 14:26.31 | Epyon_ | I barely had the time to track that one down. |
| 14:32.12 | *** join/#bzflag Upsetter (n=Ups@i577B7C5C.versanet.de) |
| 14:42.12 | spldart | makes note... barely has time ;-) hehehe |
| 14:43.45 | Epyon_ | spldart, it's not summer yet :/ |
| 14:44.05 | spldart | I'm just verbally jabbing you in the ribs guy |
| 14:44.13 | spldart | ;-) |
| 14:44.13 | Epyon_ | ouch |
| 14:48.46 | blast007 | spldart: the current warning is about an unused variable |
| 14:49.02 | blast007 | unused paramater, actually |
| 14:49.06 | blast007 | bzfsMessages.cxx: In function `void sendMsgGMUpdate(int, ShotUpdate*, int)': |
| 14:49.06 | blast007 | bzfsMessages.cxx:913: warning: unused parameter `int player' |
| 14:49.10 | spldart | I know.. I was goin through the cxx invovled |
| 14:49.22 | spldart | still have it open in fact |
| 14:49.32 | blast007 | void sendMsgGMUpdate ( int player, ShotUpdate *shot, int target ) |
| 14:49.58 | spldart | yep... @ that line |
| 14:50.12 | spldart | What do you use for editing in linux? or are you windows? |
| 14:50.23 | blast007 | I use 'vi' |
| 14:50.48 | spldart | I'll have to install that... simple stuff I do in nano but I have that cxx open in gedit right now |
| 14:51.31 | blast007 | easy fix it to change "int player" to "int /*player*/" |
| 14:52.07 | *** join/#bzflag JBdiGriz (n=JBdiGriz@adsl-75-36-38-29.dsl.sndg02.sbcglobal.net) |
| 14:52.07 | *** mode/#bzflag [+o JBdiGriz] by ChanServ |
| 14:52.20 | blast007 | do you want to commit that one spldart? |
| 14:52.32 | spldart | all occurrences or just that one |
| 14:53.12 | spldart | just that one |
| 14:54.01 | blast007 | yup, just that one |
| 14:54.02 | spldart | I'll just let you do it :) |
| 14:54.06 | spldart | oh |
| 14:54.18 | spldart | to /*player*/ |
| 14:54.22 | blast007 | line 912 of src/bzfs/bzfsMessage.cxx |
| 14:54.33 | blast007 | void sendMsgGMUpdate ( int /*player*/, ShotUpdate *shot, int target ) |
| 14:55.29 | blast007 | that'll fix the build for now. I'd rather not go and remove the whole "int player" in case that is going to be needed later, since the packing of the player is just commented out right now, not removed |
| 14:57.22 | CIA-32 | BZFlag: 03bzspldart * r16944 10/trunk/bzflag/src/bzfs/bzfsMessages.cxx: |
| 14:57.23 | *** join/#bzflag TimRiker (n=timr@68.27.25.129) |
| 14:57.23 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 14:57.43 | spldart | First commit in linux |
| 14:58.14 | Manu | :) |
| 14:58.21 | spldart | and I was right there @ the line but couldn't see the deal. Thanks blast |
| 15:03.15 | *** join/#bzflag Upsette1 (n=Ups@i577B5AAD.versanet.de) |
| 15:11.12 | spldart | never got built tools setup on his work machine so just now started make to test with debug |
| 15:21.40 | *** join/#bzflag Dessy2 (n=Dessy@88-134-204-43-dynip.superkabel.de) |
| 15:23.49 | spldart | Yay... debug build of bzfs successful :) |
| 15:26.39 | *** join/#bzflag Upsetter (n=Ups@i577B5909.versanet.de) |
| 15:39.13 | *** join/#bzflag Tedius (n=Tedius@musictech.MUSC.CWRU.Edu) |
| 15:53.03 | blast007 | spldart: hehe, no commit message? ;) |
| 15:53.45 | blast007 | by default, it launches an editor so you can write a message, iirc |
| 15:54.12 | blast007 | (then you'd save/exit and it would continue) |
| 15:55.15 | spldart | sry.. first time in linux... Last time I tried it kept erroring out. |
| 15:56.24 | spldart | I'll get the linux commit right next time... |
| 15:57.04 | spldart | heh.. or just stick to windows... tort is so stinking easy |
| 16:00.12 | Constitution | ew windoze |
| 16:02.31 | JBdiGriz | It is sticky |
| 16:02.44 | spldart | And smells funny? |
| 16:02.54 | Constitution | tort is nice, though |
| 16:07.24 | *** join/#bzflag think_tank (n=think_ta@unaffiliated/thinktank/x-168245) |
| 16:16.05 | *** join/#bzflag JeffM (n=JeffM@unaffiliated/jeffm) |
| 16:16.10 | spldart | I'll assume that since noone suggested it that it's not possible to retroactively add a message. |
| 16:17.42 | Wyk3d | afaik SVN allows it, but sourceforge doesn't |
| 16:18.25 | think_tank | FWIW to whoever may care, might I suggest that 3.0 /reports indicate the auth status of the reporter to prevent spoofs |
| 16:18.36 | Wyk3d | tort has an interface for doing that, but it fails if you try |
| 16:18.52 | Wyk3d | on sf |
| 16:19.02 | spldart | ic |
| 16:19.05 | Wyk3d | well last time i checked anyway |
| 16:19.20 | spldart | Well... I don't think I'll make that mistake a second time... on linux hehe |
| 16:19.55 | spldart | first time I tried that it couldn't find an editor @ all and failed straight away heh |
| 16:20.00 | *** join/#bzflag L4m3r (i=l4m3r@about/essy/warning/L4m3r) |
| 16:20.10 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 16:20.41 | JeffM | spldart, there are ways to edit the history but it's a huge pain |
| 16:20.44 | JeffM | what did you do? |
| 16:21.18 | spldart | Line 912 of the bzfsMessages.cxx |
| 16:21.31 | Epyon_ | JeffM, you blew my patch -_- |
| 16:21.32 | spldart | I was there but couldn't figure what I needed to do but blast told me how to fix it |
| 16:21.33 | JeffM | just fix it and commit it again |
| 16:21.36 | JeffM | Epyon_, yep |
| 16:21.42 | Epyon_ | darn it |
| 16:21.43 | JeffM | I said I would if you didn't get it done soon |
| 16:21.48 | Epyon_ | I couldn't |
| 16:21.57 | JeffM | I wated the entirty of yesterday |
| 16:22.01 | JeffM | I need /set to work |
| 16:22.10 | Epyon_ | I know, I wasn't home yesterday : |
| 16:22.14 | Epyon_ | :/ |
| 16:22.17 | JeffM | such is life |
| 16:22.21 | JeffM | I'm sure you can find something else |
| 16:22.27 | JeffM | there are a number of small ones |
| 16:22.38 | Epyon_ | May proove difficult, time is cutting real short on me |
| 16:22.46 | JeffM | yes.. yes it is |
| 16:23.13 | JeffM | this would be the third week |
| 16:23.47 | JeffM | mostly for you, since you are a special case I'm just looking for you to show that you can dig around and change other people's code |
| 16:23.52 | JeffM | cus I know you can write |
| 16:24.05 | JeffM | I mean I have PLENTY of examples of your coding, etc.. :) |
| 16:25.53 | JeffM | cus I think for the cleanup project that's what I need to see, your process of looking, digging, and fixing, etc.. |
| 16:26.16 | JeffM | sadly I'm not evaluating the BZWgen one, as I do not understand it enough :( |
| 16:27.02 | JeffM | so if you want to do a patch in that code, that will help the mentors evaulating that just fine |
| 16:27.40 | JeffM | or if you'd like I can look at the list and sugest a small change for you. |
| 16:32.28 | CIA-32 | BZFlag: 03JeffM2501 * r16945 10/branches/v2_99_shot_branch/: start a branch for the shot re-write |
| 16:35.17 | JeffM | lets see what we can find |
| 16:35.24 | JeffM | any other students need patch ideas? |
| 16:35.38 | JeffM | I'll do asignments if that's what it takes :) |
| 16:36.44 | JeffM | Epyon_, got a simple one for ya if you want it |
| 16:36.53 | JeffM | should be very straight forward |
| 16:37.14 | JeffM | https://sourceforge.net/tracker/index.php?func=detail&aid=1210029&group_id=3248&atid=103248 |
| 16:41.53 | *** join/#bzflag Dessy (n=Dessy@88-134-204-43-dynip.superkabel.de) |
| 16:42.01 | JeffM | or .... not... |
| 16:44.17 | CIA-32 | BZFlag: 03JeffM2501 * r16946 10/branches/v2_99_shot_branch/ (40 files in 15 dirs): kerbranch! |
| 16:55.08 | *** join/#bzflag Erroneous (n=dtremena@67-131-219-2.dia.static.qwest.net) |
| 16:55.29 | JeffM | oh goodie.. he's just in time |
| 16:55.54 | JeffM | bets this breaks CIA |
| 16:56.08 | donny_baker | oh, i long for the jos that i can start at 1PM... or 10 AM for that matter ;) |
| 16:56.23 | donny_baker | s/jos/job/ |
| 16:56.23 | CIA-32 | BZFlag: 03JeffM2501 * r16947 10/branches/v2_99_shot_branch/ (41 files in 6 dirs): (log message trimmed) |
| 16:56.23 | CIA-32 | BZFlag: remove per player shot lists. |
| 16:56.23 | CIA-32 | BZFlag: add per player "Charge Hole" type shot slots that track reloads. |
| 16:56.23 | CIA-32 | BZFlag: allow for per player shot slot limits. |
| 16:56.23 | CIA-32 | BZFlag: add a global shot management system and global shot IDs. |
| 16:56.25 | CIA-32 | BZFlag: have the server keep track of shots in a shot manager. |
| 16:56.29 | CIA-32 | BZFlag: remove GM updates from the client. |
| 16:56.35 | brlcad | donny_baker: heh |
| 16:56.42 | JeffM | aww.... stupid CIA limit |
| 16:57.29 | JeffM | that's the full message http://pastebin.bzflag.bz/m1fff57b9 |
| 16:57.51 | blast007 | hehe |
| 16:57.59 | Wyk3d | number 13 is particularly unlucky =D |
| 16:58.11 | JeffM | heh |
| 16:58.13 | JeffM | didn't notice that |
| 16:58.20 | JeffM | but that's why it's a branch |
| 17:03.02 | Erroneous | woot, yay for bugs :) |
| 17:06.36 | BulletCatcher | Timestamps sent over the wire in float format (in sendMsgWhatTimeIsIt, e.g.) will be limited to 1/10 second precision after 20 days of server uptime. |
| 17:07.41 | L4m3r | shouldn't timestamps be double precision? |
| 17:07.41 | BulletCatcher | Because floats have only 24 bits for the mantissa. |
| 17:07.43 | brlcad | heh, fun |
| 17:08.01 | Erroneous | yeah, times should be stored and sent as doubles. patches welcome. |
| 17:08.03 | brlcad | lucky lucky 13 |
| 17:08.58 | brlcad | a bz server with 20 days uptime .. wonder what after actively used server uptimes are now |
| 17:09.35 | BulletCatcher | Timestamps are double inside TimeKeeper, but often converted to float in other code. |
| 17:10.22 | brlcad | i started updates to propagate doubles, but stopped before I saw they made it into the protocol |
| 17:10.30 | JeffM | BulletCatcher, so fix it |
| 17:10.30 | brlcad | s/before/when/ |
| 17:12.09 | JeffM | we don't have a packDouble IIRC |
| 17:12.31 | BulletCatcher | I think I can provide patches, but not soon. Should I put this in the SF tracker, or does someone simply want to add it to the BUGS file for now? |
| 17:12.50 | JeffM | BulletCatcher, fix it and I'll apply it |
| 17:13.06 | JeffM | it's a user bug so throw it in SF |
| 17:13.11 | BulletCatcher | will do |
| 17:13.24 | JeffM | how would we do a packdouble? |
| 17:19.56 | BulletCatcher | It will require testing to confirm that the double format is the same across supported platforms. |
| 17:20.09 | BulletCatcher | If it isn't, we'll have to invent/steal something. |
| 17:21.06 | JeffM | that's why I packed it as a float, cus we didn't have a pack double |
| 17:27.06 | BulletCatcher | "struct timespec" as used by nanosleep() and defined in time.h on modern systems is close but it uses time_t which is not portable. |
| 17:30.28 | JeffM | no mater what we need a double pack, since we need to use those for possibly other thigns |
| 17:31.11 | BulletCatcher | for example? |
| 17:34.03 | *** join/#bzflag javawizard2539 (n=javawiza@c-24-10-227-207.hsd1.co.comcast.net) |
| 17:35.08 | JeffM | anything I want more accuracy on |
| 17:35.11 | JeffM | vectors |
| 17:35.15 | JeffM | postions |
| 17:35.18 | JeffM | etc... |
| 17:35.27 | JeffM | it's a good thing to have in general |
| 17:44.30 | brlcad | has a double packer |
| 17:45.26 | JeffM | check it in :) |
| 17:47.05 | brlcad | working on it, have to rework it for bz |
| 17:47.20 | JeffM | give it to BulletCatcher to rework :) |
| 17:48.19 | brlcad | do we care about being able to support 20 year old machines? I can leave the code in or rip it out to just what all modern systems use |
| 17:49.04 | JeffM | example systems would be? |
| 17:50.02 | BulletCatcher | Modern hardware allegedly is IEEE 754 compliant. We ought to be able to get by supporting just that. I will have some test results in about 1/2 hour. |
| 17:52.19 | brlcad | like an old gould, or a cray 1/2, or a vax, a convex, etc .. really old stuff |
| 17:52.25 | brlcad | old ibm format |
| 17:52.32 | JeffM | screwem |
| 17:52.32 | brlcad | sgi/mips format |
| 17:52.38 | JeffM | hmmmm |
| 17:52.45 | JeffM | that may be the iffy one |
| 17:52.48 | JeffM | no old irx |
| 17:52.53 | brlcad | basically everything that came before 754 :) |
| 17:53.09 | brlcad | that's *really* old sgi -- like irix 4 |
| 17:53.20 | JeffM | like my O2? |
| 17:53.22 | JBdiGriz | An octane should be okay |
| 17:53.27 | brlcad | like 5 years before your O2 |
| 17:53.32 | JeffM | I'm ok wiht it |
| 17:53.44 | JeffM | but I don't know how many old SGIs we still hang with |
| 17:53.46 | BulletCatcher | My tests will include an SGI O2. |
| 17:54.12 | brlcad | BulletCatcher: and your sgi probably runs irix6 I bet, it's 754 compliant |
| 17:54.22 | JeffM | ahh so it's an OS thing? |
| 17:54.24 | JeffM | not a CPU thing? |
| 17:54.25 | brlcad | right |
| 17:54.29 | JeffM | then screwem |
| 17:54.31 | JeffM | big time |
| 17:54.46 | brlcad | k |
| 17:54.52 | BulletCatcher | the O2 runs IRIX 6.5.3m |
| 17:56.14 | brlcad | yep, even irix5 was mostly compliant iirc |
| 17:57.21 | brlcad | BulletCatcher: it you're an irix logo fan, http://brlcad.org/wiki/SGI_Cube :-) |
| 17:58.02 | *** join/#bzflag Kanelbullen (n=5ae67af8@bz.bzflag.bz) |
| 17:58.04 | brlcad | makes for a great display background rendered at high-res |
| 17:58.11 | BulletCatcher | very nice |
| 17:58.27 | Kanelbullen | Hi |
| 17:58.33 | blast007 | hello Kanelbullen |
| 17:59.52 | Kanelbullen | brb I need a cola |
| 18:02.21 | *** join/#bzflag Saturos (n=Saturos@p57A0C242.dip.t-dialin.net) |
| 18:12.04 | *** join/#bzflag Wits (n=Warinthe@75.84.188.72.cfl.res.rr.com) |
| 18:23.42 | BulletCatcher | See http://pastebin.bzflag.bz/m6882f4af for the happy results. For now we can just send doubles over the wire. |
| 18:25.13 | BulletCatcher | I always used gcc, but I suspect that each system had a different gcc version. |
| 18:27.40 | brlcad | BulletCatcher: I'm almost done |
| 18:31.58 | BulletCatcher | The quote at the bottom the brlcad SGI_Cube page is relevant: "For software, a major upgrade takes it from Working to Not-Working." - Dave Florek |
| 18:41.43 | brlcad | :-) |
| 18:42.04 | BulletCatcher | If only it weren't true. |
| 18:44.07 | JBdiGriz | BulletCatcher: gcc -v or gcc --version |
| 18:45.32 | BulletCatcher | Yes. The gcc versions range from 2.8.1 on the SGI to 4.1.2 on my Fedora 8 system. |
| 18:46.41 | *** join/#bzflag L4m3r (i=l4m3r@about/essy/warning/L4m3r) |
| 18:46.41 | *** mode/#bzflag [+v L4m3r] by ChanServ |
| 18:48.19 | BulletCatcher | the timestamp bug is now reported at https://sourceforge.net/tracker/index.php?func=detail&aid=1940403&group_id=3248&atid=103248 |
| 19:11.20 | CIA-32 | BZFlag: 03brlcad * r16948 10/trunk/bzflag/ (6 files in 4 dirs): |
| 19:11.20 | CIA-32 | BZFlag: implement nboPackDouble and nboUnpackDouble using a simplified implementation of |
| 19:11.20 | CIA-32 | BZFlag: htond() and ntohd() -- these mimic existing code and allows for simple |
| 19:11.20 | CIA-32 | BZFlag: conversion for arrays of values too. this can be used to fix sf bug 1940403 |
| 19:11.20 | CIA-32 | BZFlag: (timestamps need more precision). |
| 19:12.40 | BulletCatcher | Thanks, brlcad. |
| 19:12.45 | BulletCatcher | The Two Tanks server at 01.bztank.net claims 55 days of uptime. |
| 19:32.54 | *** join/#bzflag kirun (n=kirun@10.126.gr5.adsl.brightview.com) |
| 19:39.10 | blast007 | should DownloadAccess.txt for 3.0 be inside the 3.0/ directory instead of the directory above that? Main reason for asking is that 3.0 has a more restrictive list, so if people run 2.0 and then 3.0, they will have the old *.bzflag.org and *.bzflag.bz stuff, which is fine |
| 19:39.54 | blast007 | but if they go the other way around (run 3.0 and then 2.0) that will break a great deal of maps on 2.0.x servers that use textures from other hosts. Or do we not care about that? |
| 19:42.23 | *** join/#bzflag Daveman (n=dave@pool-141-150-16-73.mad.east.verizon.net) |
| 19:44.28 | *** join/#bzflag Think_Differentl (n=shedelj@unaffiliated/thinkdifferentl/x-838543) |
| 19:45.43 | CIA-32 | BZFlag: 03brlcad * r16949 10/trunk/bzflag/src/bzfs/bzfsPlugins.cxx: make sure INSTALL_LIB_DIR is defined, bad am-refresh |
| 19:56.07 | *** join/#bzflag LongDon (n=LongDon@dyndsl-091-096-002-140.ewe-ip-backbone.de) |
| 19:58.53 | *** join/#bzflag lol (n=4c5d8bae@bz.bzflag.bz) |
| 19:59.04 | lol | Hello everyone! |
| 19:59.27 | Winny | hi |
| 19:59.42 | lol | Hey Winny can you help me out on something please? |
| 19:59.49 | Winny | depends what the something is |
| 20:00.23 | Winny | haha |
| 20:00.49 | *** join/#bzflag lol (n=4c5d8bae@bz.bzflag.bz) |
| 20:00.54 | lol | the problem that I have is |
| 20:01.14 | lol | Bzflag doesnt run on my mac |
| 20:01.17 | lol | desktop |
| 20:01.23 | lol | but it works on my laptop mac |
| 20:01.32 | lol | and they are the same OS:s |
| 20:01.47 | Winny | delete your config file |
| 20:02.00 | lol | I dont have a config file on this +0 |
| 20:02.29 | lol | I just installed bzflag on this |
| 20:02.40 | Winny | What is "this" the desktop? |
| 20:02.41 | lol | and im running Tiger by the way |
| 20:02.47 | lol | oh sorry |
| 20:02.55 | lol | "this" means the computer |
| 20:03.01 | Winny | and does BZFlag run at all? |
| 20:03.14 | lol | Nope |
| 20:03.20 | lol | It just freezes |
| 20:03.21 | Winny | hmm |
| 20:03.27 | lol | and i tried installing again |
| 20:03.31 | lol | Nonthing |
| 20:03.35 | lol | Nothing* |
| 20:03.36 | Winny | odd |
| 20:03.39 | lol | yeah |
| 20:03.43 | Winny | hmm |
| 20:03.48 | Winny | try running it in windowed mode |
| 20:03.52 | lol | and im running the same OS on my mac laptop and that always works |
| 20:03.53 | lol | ok |
| 20:04.14 | lol | lol i thought Macs always work :) |
| 20:04.19 | lol | and never freeze |
| 20:04.27 | Winny | It's an operating system |
| 20:04.36 | Winny | it freezes like everything else |
| 20:05.32 | lol | I dont have a window mode |
| 20:05.47 | lol | it seems full sceen for mac only |
| 20:06.07 | lol | WOAH |
| 20:06.11 | Winny | start it from the command line |
| 20:06.18 | lol | Bzflag came up for a minute and stopped |
| 20:06.20 | lol | ok |
| 20:06.32 | lol | what should I type in the terminal? |
| 20:06.32 | Winny | /path/to/BZFlag.app -window 800x600 |
| 20:06.34 | Winny | or something like that |
| 20:06.35 | lol | ok |
| 20:07.49 | lol | the terminal says file doesnt excist |
| 20:08.52 | lol | any other suggestions? |
| 20:10.47 | Winny | oh. forgot a part: /Applications/BZFlag-2.0.11.app/Contents/MacOS/bzflag -window 800x600 |
| 20:10.48 | lol | Winny it seems I have fixed it |
| 20:10.59 | Winny | that's my path... your's is probably different |
| 20:11.04 | lol | yeah |
| 20:11.09 | lol | but it seems i fixed it |
| 20:11.15 | lol | you just need to give it a minute |
| 20:11.28 | lol | But its wierd |
| 20:11.34 | lol | its supposed to run fast |
| 20:11.43 | lol | I mean i barely have anything on this computer |
| 20:11.47 | lol | I just bought it |
| 20:12.16 | lol | and I only installed 3 apps.....Microsoft Office, bzflag, and adobe |
| 20:12.18 | Wyk3d | @16949 trunk: e:\BZFlag\trunk\bzflag\src\net\Pack.cxx(127) : error C2065: 'uint64_t' : undeclared identifier |
| 20:12.29 | lol | ? |
| 20:13.11 | lol | Winny thanks for your time really |
| 20:13.39 | Winny | np.. would have been sitting here twiddling my thumbs otherwise :) |
| 20:13.55 | lol | hahahaha |
| 20:13.58 | Wyk3d | htond.cxx(80) : error C2065: 'BZ_LITTLE_ENDIAN' : undeclared identifier |
| 20:13.58 | lol | nice :) |
| 20:14.07 | lol | See you people later! |
| 20:14.16 | BulletCatcher | brlcad: In htond.cxx the three BZ_*_ENDIAN symbols are not defined. |
| 20:16.38 | Wyk3d | brlcad: forgot to commit header changes ? :) |
| 20:17.52 | CIA-32 | BZFlag: 03brlcad * r16950 10/trunk/bzflag/src/net/htond.cxx: BZ prefix |
| 20:18.47 | brlcad | BulletCatcher: yeah, automake wierdness here .. it somehow passed compilation test |
| 20:19.07 | BulletCatcher | htond.cxx comiles now :-) |
| 20:19.33 | Wyk3d | Pack.cxx still doesn't though |
| 20:19.39 | Wyk3d | VS2k3 |
| 20:19.44 | brlcad | i'm reautogen'ing, it'll take a bit |
| 20:19.57 | brlcad | this machine is so damn slow compiling |
| 20:20.31 | JBdiGriz | spends the time compiling looking at faster machines |
| 20:22.03 | BulletCatcher | Pack.cxx compiles on Linux |
| 20:22.34 | brlcad | continues to wait for autogen.sh |
| 20:23.19 | JeffM | epyon never came back? |
| 20:23.49 | JBdiGriz | goes to look at SCons |
| 20:24.25 | *** join/#bzflag east (n=c696c3a8@bz.bzflag.bz) |
| 20:25.20 | Winny | JeffM, his connection was reset by beer |
| 20:25.29 | JeffM | that's his standard message |
| 20:25.41 | JeffM | hw was on earlyish so I wondered if he has come back |
| 20:25.59 | JeffM | I have a couple simple things he can do for a patch |
| 20:26.00 | Winny | Maybe it's always a true quit message :) |
| 20:26.08 | JeffM | doubtfull |
| 20:27.41 | JeffM | brlcad, c:\documents and settings\jeffm.gibbs\desktop\bzflag 3.0\src\net\pack.cxx(127) : error C2065: 'uint64_t' : undeclared identifier |
| 20:27.47 | Wyk3d | BulletCatcher: VS doesn't have an uint64_t (it's __int64) |
| 20:27.50 | JeffM | is there somethign I have to do in config? |
| 20:27.57 | JeffM | Wyk3d, ok, i"ll fix that |
| 20:28.02 | JeffM | that's what I wanted to know |
| 20:28.07 | Wyk3d | #ifndef uint32_t |
| 20:28.08 | Wyk3d | typedef unsigned intuint32_t; |
| 20:28.08 | Wyk3d | #endif |
| 20:28.09 | JeffM | linux and mac build that maping in the config |
| 20:28.11 | Wyk3d | is already in win32.h |
| 20:28.14 | Wyk3d | but not uint64_t |
| 20:28.25 | JeffM | then we have to do define it in the config.h we use for windows |
| 20:28.30 | JeffM | I'll fix that now |
| 20:28.32 | Erroneous | no, win32.h |
| 20:28.38 | Erroneous | I've already done it here, still building |
| 20:28.42 | JeffM | ok |
| 20:28.52 | JeffM | as long as it's getin done :) |
| 20:28.53 | brlcad | probably something missing from config |
| 20:29.00 | brlcad | yeah, win32.h |
| 20:29.04 | JeffM | how long can it take to build for you? |
| 20:29.04 | JeffM | incredibuild! |
| 20:29.22 | Erroneous | I am incredibuilding |
| 20:29.33 | Erroneous | 'tis almost done |
| 20:29.38 | JeffM | it's all about the incredi! |
| 20:29.39 | Erroneous | just had to look up what type to use |
| 20:29.39 | brlcad | i just happened to make the edits on a checkout on .bz |
| 20:30.04 | brlcad | which sucks planters peanuts when it comes to compiling |
| 20:30.28 | *** join/#bzflag KingofCamelot (n=davidsan@SCTN-12-153.resnet.ucsb.edu) |
| 20:32.49 | CIA-32 | BZFlag: 03dtremenak * r16951 10/trunk/bzflag/include/win32.h: [u]int64_t for windows too. typedef'd to LONGLONG/ULONGLONG, so mingw shouldn't break either. |
| 20:32.54 | JeffM | hey KingofCamelot are you taking history 4C this quarter? |
| 20:34.29 | JeffM | bad warnings! |
| 20:35.19 | CIA-32 | BZFlag: 03JeffM2501 * r16952 10/trunk/bzflag/src/net/Pack.cxx: quell warnings |
| 20:35.46 | *** join/#bzflag FalseProphet (n=Gigi@unaffiliated/emonemo) |
| 20:36.23 | Erroneous | doesn't think that'll work :) |
| 20:36.38 | JeffM | then quell it some other way |
| 20:36.56 | Erroneous | something about (*NULL)++ doesn't look good ;) |
| 20:37.16 | KingofCamelot | History 4C? Nope, heh, I don't even know what that is :P |
| 20:37.19 | JeffM | and doing that to garbage? |
| 20:37.19 | Erroneous | or even *(NULL++) |
| 20:37.36 | Erroneous | hey, I didn't say it was right before either :) |
| 20:37.46 | JeffM | Erroneous, dosnt' htond copy it? |
| 20:38.03 | Erroneous | htond(register unsigned char *out, register const unsigned char *in, int count) |
| 20:38.17 | Erroneous | out needs to be an allocated buffer |
| 20:38.18 | JeffM | so that needs to be a valid 8 byte buffer |
| 20:38.21 | JeffM | k |
| 20:38.40 | KingofCamelot | @JeffM, why do you ask? |
| 20:38.59 | JeffM | KingofCamelot, friend of mine is TAing it |
| 20:39.09 | JeffM | Erroneous, better? |
| 20:39.10 | JeffM | <PROTECTED> |
| 20:39.10 | JeffM | <PROTECTED> |
| 20:39.11 | brlcad | jeez, about half-compiled now |
| 20:39.13 | Erroneous | actually not sure why we do that. could just write it into b directly, I think |
| 20:39.49 | Erroneous | yeah, that'd work (or unsigned char* dptr = new char[8];, which is what I have) |
| 20:40.02 | JeffM | how would it get freed? |
| 20:40.03 | Erroneous | just not sure why we do the extra copy |
| 20:40.11 | Erroneous | before return |
| 20:40.19 | JeffM | one line vs 2 :) |
| 20:41.12 | Erroneous | naw, yours is two lines, mine is two lines, just in different places :) |
| 20:41.24 | JeffM | I only added one line |
| 20:41.32 | Erroneous | I only added one line too |
| 20:41.32 | JeffM | yeah you added one too |
| 20:41.33 | JeffM | I get it |
| 20:41.35 | JeffM | yeah yeah |
| 20:41.57 | JeffM | do it oo style |
| 20:42.01 | JeffM | make a new buffer class |
| 20:42.12 | JeffM | then have dptr be that ;) |
| 20:42.26 | CIA-32 | BZFlag: 03dtremenak * r16953 10/trunk/bzflag/src/net/Pack.cxx: but I think this will work too...have htond copy directly into b. |
| 20:43.04 | Erroneous | there, three lines less :) |
| 20:45.06 | CIA-32 | BZFlag: 03dtremenak * r16954 10/trunk/bzflag/src/net/Pack.cxx: best to build too |
| 20:46.37 | CIA-32 | BZFlag: 03JeffM2501 * r16955 10/trunk/bzflag/ (2 files in 2 dirs): add pack and unpack of doubles for BufferedNetworkMessages |
| 20:47.59 | JeffM | brlcad, thanks for that nice new feature you added ;) |
| 20:48.19 | Erroneous | pretty sure that was a bug fix :) |
| 20:48.31 | JeffM | acording to you, so is shots ;) |
| 20:48.48 | Erroneous | true that |
| 20:49.11 | BulletCatcher | brlcad's new feature will support a future bugfix |
| 20:49.17 | BulletCatcher | ~brlcad++ |
| 20:49.19 | Erroneous | so will shots :) |
| 20:49.48 | JeffM | Erroneous, it's in a branch now |
| 20:49.53 | JeffM | long forgoten |
| 20:49.59 | JeffM | breaks protocoll |
| 20:50.03 | blast007 | what shot code? |
| 20:50.17 | JeffM | all of it |
| 20:50.29 | Erroneous | better not be forgotten :) |
| 20:50.30 | JeffM | the grand shot unifiction theory |
| 20:50.41 | JeffM | GSUT! |
| 20:51.43 | JeffM | digs the fact that now some functions say ( double time); |
| 20:51.52 | BulletCatcher | lol |
| 20:52.00 | Winny | but not ( hammer time): ? |
| 20:52.17 | Winny | err, ;* |
| 20:52.32 | JeffM | because hammer is not a valid C++ type |
| 20:52.46 | JBdiGriz | #define hammer double |
| 20:52.48 | CIA-32 | BZFlag: 03JeffM2501 * r16956 10/trunk/bzflag/src/ (7 files in 3 dirs): |
| 20:52.48 | CIA-32 | BZFlag: proto break 0060 ( 2.99.2) |
| 20:52.48 | CIA-32 | BZFlag: send times for lag comp as doubles cus doubles ROCK. |
| 20:52.50 | Erroneous | struct hammer { ... } |
| 20:53.01 | blast007 | JeffM: guess you missed my sarcasm ;) |
| 20:53.04 | JeffM | can't touch this! |
| 20:53.13 | JeffM | blast007, heh |
| 20:53.20 | JeffM | it's all in a branch now.. .we can see it |
| 20:53.25 | JeffM | it's in the code zoo |
| 20:53.26 | JBdiGriz | Erroneous: typedef struct {} hammer; // ;) |
| 20:53.29 | JeffM | never to breed again |
| 20:53.39 | Erroneous | oh fine :P |
| 20:54.07 | JeffM | someone should test that ;) |
| 20:54.19 | JeffM | prety sure I got all the places |
| 20:54.23 | Erroneous | JeffM: at least it's easier to take code home with a branch than a usb drive :) |
| 20:54.31 | JeffM | I was using patches |
| 20:54.35 | JeffM | but yes |
| 20:54.38 | JeffM | it's simpler |
| 20:54.51 | blast007 | rebuilds his server |
| 20:54.58 | Erroneous | and now you can bug people to help you with it :) |
| 20:55.13 | JeffM | yeah cus THAT has worked so well in the past ;) |
| 20:55.19 | Erroneous | heh |
| 20:55.25 | JeffM | goes back to fixing CRC |
| 20:55.33 | Erroneous | is an eternal optimist |
| 20:55.43 | Erroneous | hey, I thought you fixed that already! :0 |
| 20:55.45 | JeffM | the regressions today were slightly less then small |
| 20:55.48 | JeffM | I have to make a change |
| 20:55.51 | Erroneous | ahh |
| 20:56.05 | JeffM | compatability in how we handle a specific invalid case |
| 20:56.14 | JeffM | techincaly my code is just as "right" as the old code |
| 20:56.17 | Erroneous | heh |
| 20:56.26 | JBdiGriz | Someone has been doing a good job of keeping warnings down. We should appreciate that, and try to avoid new ones. TimeKeeper.cxx:340: warning: unused parameter 'processor' |
| 20:56.51 | JeffM | JBdiGriz, I know Erroneous and myself try to fix them when we see em |
| 20:57.04 | JeffM | processor is used by us tho |
| 20:57.22 | JeffM | what's the accepted way to handle a param that is only used in a #def? |
| 20:57.28 | JeffM | just use it for something stupid? |
| 20:57.29 | Erroneous | JBdiGriz: your platform probably does not have an implementation for that function |
| 20:57.30 | brlcad | what's funny is that brl-cad version of htond is about 10x in size |
| 20:57.36 | brlcad | to support the other types |
| 20:57.39 | Erroneous | you should consider implementing it :) |
| 20:58.07 | JBdiGriz | Erroneous probably has the right answer. |
| 20:58.25 | JeffM | well that is a given |
| 20:58.48 | Erroneous | I think it's done for linux 2.4+ and windows right now, so bsd's, solaris, mac, etc all need their own |
| 21:00.31 | BulletCatcher | It'll be a challenge to find a PDP-11 for testing the BZ_PDP_ENDIAN case in htond. :-) |
| 21:01.36 | JBdiGriz | Looking at the comments, it's pretty clear that it's only done for Linux and Windows. Is this more appropriate in Platform? |
| 21:02.54 | JeffM | timekeepers always had platforms specfici stuff |
| 21:03.14 | JeffM | if you want to move timekeeper to platform and have difrent implemetnations per, that's fine by me |
| 21:03.18 | JeffM | but a lot of work |
| 21:03.25 | JeffM | since it's used on the server |
| 21:03.28 | JeffM | and server don't use platform |
| 21:03.58 | JeffM | so I belive that is why it is not in platform now |
| 21:04.30 | brlcad | BulletCatcher: simh ;) |
| 21:05.09 | BulletCatcher | That would be be good enough. |
| 21:05.23 | blast007 | is bzflag's -config paramater supposed to just change the filename of the config, or should it be accepting a full path? |
| 21:05.47 | JeffM | blast007, are you trying to do a flashdrive system? |
| 21:06.02 | blast007 | I'm trying to fix -configdir and -config |
| 21:06.05 | JeffM | ahh |
| 21:06.13 | JeffM | I'd think config woudl take a full path |
| 21:06.18 | JeffM | I belive that's it's intent |
| 21:06.23 | blast007 | ok |
| 21:06.41 | blast007 | current it first tacks on getConfigDirName(); and then whatever was placed after -config |
| 21:06.44 | JeffM | -config woudl cause it to load the specified config instead of the default |
| 21:06.46 | blast007 | and it doesn't support spaces |
| 21:06.50 | JeffM | but use the dir for all other things |
| 21:07.00 | JeffM | yeah that'd be not right |
| 21:07.05 | blast007 | how do I make it take a quoted string for a value? |
| 21:07.13 | JeffM | don't remember |
| 21:07.22 | JeffM | look at of the others that do |
| 21:08.14 | blast007 | I don't think any of them do for the bzflag binary |
| 21:08.31 | JeffM | not even configdir? |
| 21:08.35 | blast007 | nope |
| 21:08.38 | JeffM | if not you'll have to move that code over from the server |
| 21:08.57 | *** join/#bzflag KingofCamelot (n=davidsan@SCTN-12-153.resnet.ucsb.edu) |
| 21:11.25 | blast007 | hi KingofCamelot |
| 21:13.12 | KingofCamelot | Hey |
| 21:13.24 | KingofCamelot | This channel is so friendly towards me now whenever I log in :) |
| 21:13.36 | Manu | heh |
| 21:14.00 | Winny | KingofCamelot, go away |
| 21:14.04 | KingofCamelot | :) |
| 21:14.05 | Winny | we don't like you ;) |
| 21:14.20 | KingofCamelot | Alright Whinny...I mean Winny ;) |
| 21:15.58 | KingofCamelot | JeffM, is the weather down in TO as nice right now as it is up here in SB? |
| 21:16.36 | BulletCatcher | I see no new problems with r16956 on a private server, but I have no one else to play against. |
| 21:17.24 | JeffM | it's windy |
| 21:17.59 | *** join/#bzflag me1 (n=me1@pool-72-93-105-64.bstnma.fios.verizon.net) |
| 21:20.02 | KingofCamelot | D'oh. It's calm and sunny up here, with a hundred chicks by the dorm pool. :) |
| 21:20.24 | Winny | debates linking to a picture on digg |
| 21:21.17 | Winny | naa, better not |
| 21:22.42 | Erroneous | actually it may be worthwhile to move to pthread_setaffinity even for linux. we'd get all the other unices that way too. |
| 21:22.54 | Erroneous | in the HAVE_PTHREAD case at least |
| 21:29.01 | blast007 | JeffM: apparently our WinMain function does stuff differently than how the usual 'main' works |
| 21:29.19 | blast007 | 'main' automatically handles quotes around strings |
| 21:43.36 | *** join/#bzflag Tupone (n=Tupone@pdpc/supporter/active/Tupone) |
| 21:43.36 | *** mode/#bzflag [+v Tupone] by ChanServ |
| 21:47.08 | *** join/#bzflag _Rakf (n=569d3205@bz.bzflag.bz) |
| 21:47.48 | Ralf_ | hi |
| 21:48.10 | CIA-32 | BZFlag: 03brlcad * r16957 10/trunk/bzflag/ (30 files in 8 dirs): rename nboPackVector to nboPackFloatVector |
| 21:53.48 | JBdiGriz | Erroneous: It appears that the mac doesn't have pthread_setaffinity (at least on tiger, the affinity API is Leopard) |
| 21:58.47 | *** join/#bzflag Ride (n=18b397fe@bz.bzflag.bz) |
| 22:00.05 | JeffM | blast007, ahh |
| 22:00.20 | JeffM | winmain builds argc and argv out of a single stiring |
| 22:00.24 | blast007 | yeah |
| 22:00.28 | blast007 | split across spaces |
| 22:00.33 | JeffM | JBdiGriz, he's in a meeting |
| 22:00.34 | blast007 | really basic |
| 22:00.43 | JeffM | looks like you get somethign fun to do then :) |
| 22:00.56 | blast007 | getopt could do it ;) |
| 22:01.45 | blast007 | http://www.pwilson.net/getopt.html#c |
| 22:02.24 | JeffM | then there ya go |
| 22:05.02 | blast007 | JeffM: where should those files go? (getopt.c and getopt.h) |
| 22:05.08 | blast007 | in src/bzflag/ ? |
| 22:05.16 | JeffM | common |
| 22:05.23 | JeffM | so they could be used by anyone |
| 22:05.29 | blast007 | ok |
| 22:05.30 | *** join/#bzflag javawizard2539 (n=javawiza@c-24-10-227-207.hsd1.co.comcast.net) |
| 22:11.54 | *** join/#bzflag QuantumT1m (n=tim@62-249-230-206.no-dns-yet.enta.net) |
| 22:14.52 | blast007 | JeffM: nevermind, guess getopt can't... |
| 22:15.14 | blast007 | it only does single letter arguments :/ |
| 22:15.29 | blast007 | (and still needs an argc/argv first) |
| 22:17.17 | blast007 | oh well, time to code it myself then ;) |
| 22:19.41 | *** join/#bzflag Ride- (n=Ride-@24-197-250-9.dhcp.stpt.wi.charter.com) |
| 22:22.44 | BulletCatcher | getopt_long() accepts long arguments |
| 22:22.53 | brlcad | wonders if this branch is really just an excuse for trying to sneak in bsd style formatting |
| 22:24.59 | *** join/#bzflag Ride288 (n=Ride-@24-197-250-9.dhcp.stpt.wi.charter.com) |
| 22:25.43 | blast007 | blast007: apparently with -- only? |
| 22:26.02 | blast007 | BulletCatcher* |
| 22:26.11 | blast007 | (I need to stop talking to myself) |
| 22:26.39 | KingofCamelot | Hah |
| 22:28.20 | AAA_awright | blast007: How does the IP checking work on the list server? |
| 22:28.49 | blast007 | probably a REMOTE_ADDR comparision |
| 22:29.14 | AAA_awright | So that means I need to figure it out myself. |
| 22:29.50 | CIA-32 | BZFlag: 03brlcad * r16958 10/trunk/bzflag/include/win32.h: signed int64_t |
| 22:34.39 | *** join/#bzflag Think_Differentl (n=shedelj@unaffiliated/thinkdifferentl/x-838543) |
| 22:35.05 | blast007 | AAA_awright: hmm? |
| 22:35.42 | AAA_awright | I am trying to make my server create a token on the real list server, for the time being |
| 22:36.07 | AAA_awright | The IP's must match though.. |
| 22:36.09 | blast007 | yeah, that won't work ;) |
| 22:36.38 | AAA_awright | If it is from the same IP, yeah. Which the server is. |
| 22:38.58 | BulletCatcher | blast007: getopt_long_only() allows just "-" to begin a long option |
| 22:39.24 | blast007 | BulletCatcher: okay |
| 22:42.04 | CIA-32 | BZFlag: 03brlcad * r16959 10/trunk/bzflag/ (6 files in 3 dirs): rename BufferedNetworkMessage's packVector to packFloatVector to match Pack (why are there two?) |
| 22:43.32 | *** join/#bzflag trovao (n=trovao@201.78.77.150) |
| 22:49.14 | BulletCatcher | None of the getopt variants will really help, as they assume that the command line has already been tokenized properly. |
| 22:49.52 | blast007 | BulletCatcher: yeah, which is what I found out ;) |
| 22:50.13 | BulletCatcher | What you need is a better tokenizer, and then parse() in src/bzfs/CmdLineOptions.cxx will do the rest of the work. |
| 22:55.06 | blast007 | yeah, I'm working on making a better parser inside the WinMain |
| 22:56.41 | blast007 | got it to almost work. Just need to trim the quotes from the ends of the argument now |
| 22:57.26 | *** join/#bzflag spldart (n=vircuser@c-98-197-19-35.hsd1.tx.comcast.net) |
| 23:05.21 | *** part/#bzflag LongDon (n=LongDon@dyndsl-091-096-002-140.ewe-ip-backbone.de) |
| 23:38.04 | *** join/#bzflag JBdiGriz (n=JBdiGriz@adsl-75-36-38-29.dsl.sndg02.sbcglobal.net) |
| 23:38.05 | *** mode/#bzflag [+o JBdiGriz] by ChanServ |
| 23:41.01 | spldart | Ok.. tell me where I went wrong. I svn up my trunk code and do a build from .autogen on up cuz one of the files was a .am . Everything is fine.. I got to another directory and checkout v2_0branch and go to do a build cuz I overwrote my bzfs for stable by accident.. I know it's the right code cuz the readme says 2.0.11. I goto run autogen.sh and it comes back with bad interpreter: Permission denied |
| 23:41.39 | blast007 | was it a clean checkout directory? |
| 23:41.43 | spldart | yes |
| 23:41.46 | JBdiGriz | Which OS? |
| 23:41.51 | spldart | Linux |
| 23:41.53 | spldart | debian etch |
| 23:42.02 | spldart | and Just finished a succesful build of trunk |
| 23:42.10 | JBdiGriz | Did you do any of the downloads as root? |
| 23:42.14 | spldart | No |
| 23:42.18 | spldart | and just checked permissions |
| 23:42.23 | spldart | they are all user |
| 23:42.52 | mcintyem | Can you run sh? |
| 23:43.10 | spldart | yes |
| 23:43.33 | mcintyem | Does autogen.sh have an exec bit for your user? |
| 23:43.34 | JBdiGriz | You are doing a sh autogen.sh or a ./autogen.sh |
| 23:43.48 | spldart | the latter |
| 23:43.51 | spldart | ./au* |
| 23:43.59 | spldart | without the * hehe |
| 23:44.17 | JBdiGriz | Try an sh autogen.sh and tell us what the response is |
| 23:44.26 | spldart | k |
| 23:44.43 | spldart | response looks normal so far |
| 23:45.29 | spldart | It behaved like it normall does with ./autogen.sh |
| 23:45.36 | JBdiGriz | Did it look like this when you had the problem, or did it return immediately? |
| 23:45.53 | spldart | I'm moving on to configure |
| 23:46.00 | spldart | I don't understand the query |
| 23:46.17 | mcintyem | Did you see different behavior this time? |
| 23:46.20 | JBdiGriz | I read that you had a problem with running autogen.sh |
| 23:46.20 | spldart | It just acted like it normally does when things are fine by running it they way you recommened |
| 23:46.36 | blast007 | did it instantly report "bad interpreter: Permission denied" when just ran ./autogen.sh ? |
| 23:46.40 | JBdiGriz | I was wondering if it is now working |
| 23:46.45 | blast007 | or did it do *some* stuff, and then fail with that error |
| 23:47.04 | spldart | sh autogen.sh produced the completely standard result I expect from ./autogen.sh |
| 23:47.13 | spldart | And it was instant with the error with ./autogen.sh |
| 23:47.23 | JBdiGriz | Check /bin/sh |
| 23:47.50 | brlcad | spldart: permisions on autogen.sh ? |
| 23:48.06 | JBdiGriz | It sounds more like a problem with /bin/sh |
| 23:48.19 | spldart | -rwxr -xr -x 1 user user |
| 23:48.32 | spldart | How do I check /bin/sh |
| 23:48.33 | brlcad | and /etc/shells has /bin/sh ? |
| 23:48.37 | QuantumT1m | is there any way to make bzflag switch to my secondary monitor under XP? |
| 23:48.48 | spldart | this was just working a few minutes ago :/ |
| 23:48.55 | JBdiGriz | What's the response to the command "which sh" |
| 23:49.02 | brlcad | you've been h4x0r3d |
| 23:49.19 | spldart | response is /bin/sh |
| 23:49.23 | JBdiGriz | brlcad: You're going to worry him |
| 23:49.27 | mcintyem | cat /etc/shells |
| 23:49.28 | mcintyem | ? |
| 23:49.39 | brlcad | JBdiGriz: *grin* |
| 23:49.48 | brlcad | the dust bunnies have gone rogue |
| 23:50.07 | spldart | have lots of entries under /etc/shells |
| 23:50.14 | JBdiGriz | the dust bunnies often hang my machine. I have to clean them out and cool things off occasionally. |
| 23:50.18 | mcintyem | cat /etc/shells | grep sh |
| 23:50.27 | mcintyem | cat /etc/shells | grep /sh |
| 23:50.42 | mcintyem | Or, in other words, is one of them /bin/sh |
| 23:50.43 | mcintyem | ? |
| 23:50.55 | spldart | result /etc/shells: valid login shells |
| 23:51.01 | spldart | */bin/sh |
| 23:51.09 | spldart | so yes |
| 23:51.31 | JBdiGriz | I'm guessing that ./autogen.sh would work again as well. It sounds like a glitch. |
| 23:52.21 | spldart | I just tried.. it's still not working |
| 23:52.23 | mcintyem | Was the file ever edited on windows? Could there be a CRLF problem? |
| 23:52.25 | spldart | I'm goin to reboot |
| 23:52.30 | spldart | Oh no |
| 23:52.35 | spldart | fresh checkout |
| 23:52.39 | spldart | subversion |
| 23:52.40 | spldart | on debian |
| 23:52.54 | spldart | rebooting that machine |
| 23:53.06 | spldart | I did an aptitude update this morning on that machine |
| 23:53.08 | spldart | one file |
| 23:53.15 | JBdiGriz | The CRLF should behave the same whether it's ./autogen.sh or sh autogen.sh |
| 23:53.27 | JBdiGriz | Especially if the path is pointing to /bin/sh |
| 23:53.44 | JBdiGriz | You could try /bin/sh autogen.sh, but that should be the same command |
| 23:53.48 | spldart | I'm proceding under glitch at the moment |
| 23:54.15 | mcintyem | Probably, unless the shell executing the script is looking for "/bin/sh^M" as the interpreter, so it never gets started. |
| 23:54.19 | JBdiGriz | I dislike glitches. Keep good backups. |
| 23:54.47 | spldart | grrrrr |
| 23:54.51 | JBdiGriz | mcintyem: That's a possibility. It's worthwhile to look for the CRLF |
| 23:55.06 | spldart | Ok! Check this |
| 23:55.26 | spldart | I can go back to my trunk checkout on a different drive on the same machine and ./autogen.sh works fine |
| 23:55.53 | mcintyem | Run dos2unix autogen.sh on the non-working file. |
| 23:55.56 | JBdiGriz | Do you have an alias for cd? |
| 23:56.30 | spldart | Really mcintyem? Like I said.. this checkout has NEVAR seen a windows boxen |
| 23:56.41 | JBdiGriz | It's worthwhile trying. |
| 23:57.24 | JBdiGriz | It's probably worthwhile editing autogen.sh and letting us know what that first line is. |
| 23:57.41 | spldart | is installing tofrodos now |
| 23:57.56 | mcintyem | JBdiGris: Could a tagged release have possibly included a CRLF'd file? |
| 23:58.03 | mcintyem | *z |
| 23:58.17 | spldart | No fix |
| 23:58.25 | JBdiGriz | Anything is possible, but it shouldn't have. |
| 23:58.41 | spldart | I've checked out branch before and had no issue |
| 23:58.41 | JBdiGriz | I thought svn would take care of problems like that for text files as well. |
| 23:58.53 | mcintyem | Ahhp, doesn't sound like it. Oh-- yes, that's true about SVN as well. |
| 23:58.56 | JBdiGriz | What's the first line of autogen.sh |
| 23:59.21 | spldart | #!/bin/sh |
| 23:59.30 | spldart | looks fine |
| 23:59.49 | JBdiGriz | And if you type /bin/sh, it gives you a nice new shell prompt, right? |
| 23:59.56 | spldart | yes |