| 00:00.41 | BulletCatcher | Sigh. Even in 2.99 we never actually built GLEW on *nix systems. |
| 00:00.46 | BulletCatcher | At the moment bzflag will build only when the system provides GLEW. |
| 00:00.47 | BulletCatcher | I can fix it, but not before tomorrow. |
| 00:01.08 | JeffM | just throw the C file into bzflag ;) |
| 00:01.16 | BulletCatcher | That's one of the options. |
| 00:01.45 | JeffM | when was the last time glew was even updated? |
| 00:02.14 | BulletCatcher | GLEW 1.6.0 was released on April 27. |
| 00:02.29 | JeffM | when was the last one before that? |
| 00:03.30 | BulletCatcher | The history is on http://glew.sourceforge.net/ . They seem to be keeping busy. |
| 00:03.38 | JeffM | that's cool |
| 00:03.52 | JeffM | tho if we go to GL2 we may not need it |
| 00:04.09 | JeffM | we'll need something else but only on windows |
| 00:04.10 | Thumper_ | dtr updated it last in r21116 (sync glew with upstream (1.5.4), 2010-05-10) |
| 00:04.14 | JeffM | glee |
| 00:06.00 | trepan | are you happy, or making a library suggestion? |
| 00:06.07 | JeffM | heh |
| 00:06.25 | JeffM | windows only has headers for GL 1.2 and won't ship newer |
| 00:06.46 | trepan | iirc, glee does an am-i-inited-yet check for every call |
| 00:06.58 | trepan | one of the non-glew libs did that, pissed me off |
| 00:07.01 | JeffM | you can init it |
| 00:07.10 | trepan | check is still there, iirc |
| 00:07.13 | JeffM | ahh |
| 00:07.25 | JeffM | I used it on Constitution's thing and it seemed to work ok |
| 00:07.45 | JeffM | even then glew is pretty lightweight |
| 00:08.38 | JeffM | could all be moot if we used a third party engine |
| 00:13.38 | trepan | limited to GLSL - keep that one in mind if you plan on allowed user create shaders for materials |
| 00:13.45 | trepan | *allowing |
| 00:16.03 | trepan | tbh, for bz, it's unlikely that the community would produce many shaders; so just setting them up with material properties would probably suffice |
| 00:23.02 | *** join/#bzflag Ebert (~EbErT@99-98-153-115.lightspeed.tukrga.sbcglobal.net) |
| 00:23.40 | JeffM | yeah that's what makes me think aboug ogre |
| 00:23.47 | JeffM | it has a decent material spec |
| 00:25.02 | JeffM | and a decent lighting/shadow system |
| 00:27.08 | trepan | irrlicht might be worth looking at too, a little lighter, and still does GL & D3D |
| 00:27.41 | JeffM | yeah, there is is also lightfeather, it was a fork of irrlicht |
| 00:27.46 | *** join/#bzflag spldart (~spldart2@c-98-198-227-61.hsd1.tx.comcast.net) |
| 00:27.46 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 00:27.46 | *** mode/#bzflag [+v spldart] by ChanServ |
| 00:29.33 | mdskpr_ | irrlicht is really nice, supertuxkart uses it |
| 00:31.50 | blast007 | JeffM: and I was thinking at one point that I had tweaked the windows command line parsing code to handle quotes - just not sure what version I was working with |
| 00:32.09 | trepan | for debian (and derivatives) users, irrlicht is the only one of the 3 mentioned in the apt repos |
| 00:32.25 | blast007 | (or at least trying to fix it so it worked) |
| 00:32.36 | trepan | hm, i lie, ogre is there too; so only lightfeather is out |
| 00:38.35 | blast007 | JeffM / trepan: and I'm pretty sure there is symlinks in Vista onward - and there was hard links in XP and probably 2000, if not earlier |
| 00:40.36 | trepan | http://msdn.microsoft.com/en-us/library/aa365006(v=vs.85).aspx |
| 01:04.34 | Erroneous | has hardlinks all over his drive; drives the IT guys nuts |
| 01:07.45 | blast007 | hehe |
| 01:16.34 | *** join/#bzflag bryjen (~bryjen@76.92.85.169) |
| 01:16.34 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 01:19.22 | *** join/#bzflag RatOmeter (~chatzilla@r74-195-225-238.stl1cmta01.stwrok.ok.dh.suddenlink.net) |
| 01:26.01 | *** join/#bzflag JeffM (~Jeff@unaffiliated/jeffm2501) |
| 01:26.01 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 02:14.25 | TD-Linux | ogre is a lot more than irrlicht though |
| 02:23.29 | TD-Linux | err maybe not.. I always saw ogre as more heavyweight, it has its own material formats and stuff, but actually looks rather similar to irrlicht |
| 02:25.20 | TD-Linux | JeffM: you mean the IDE's I was whining about on windows? |
| 02:25.30 | TD-Linux | I've had issues both with Codewarrior and Xilinx ISE |
| 02:25.52 | TD-Linux | Xilinx ISE is fixed now, but they've been busy adding bugs to Codewarrior |
| 02:29.08 | *** join/#bzflag noyb (~noyb@pool-173-60-180-80.lsanca.dsl-w.verizon.net) |
| 02:30.55 | JeffM | codewarrior still exists? |
| 02:31.34 | JeffM | irrlicht is lighterweight then ogre |
| 02:31.44 | JeffM | ogre is very mature and has a lot of third party support |
| 02:31.49 | JeffM | it's devs are cool |
| 02:34.16 | TD-Linux | yeah I looked into ogre and played with it a lot a while ago... its material scripts are pretty neat |
| 02:34.36 | TD-Linux | and yeah, codewarrior is still alive, and worse than ever... I have to use it for coldfire |
| 02:36.21 | TD-Linux | it's hard to debug your code when the linker crashes, the IDE freezes and takes 10 minutes to load, and the compiler randomly chokes on valid C code for no reason |
| 02:37.23 | TD-Linux | I also like how ogre has pluggable scene graphs - would you dump bzflag's scene graph for one of Ogre's? |
| 02:39.09 | JeffM | why would we keep anything from bz? |
| 02:39.15 | JeffM | it's just an octree |
| 02:42.43 | TD-Linux | yeah I didn't think it did anything fancy |
| 02:44.40 | *** join/#bzflag bryjen (~bryjen@76.92.85.169) |
| 02:44.40 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 02:51.55 | delusional | looking in my browser history, i see pastes from 6 different people attempting mac compiles... everybody is getting different and unrelated errors.... two of them even get what appears to be a fully-built app... this leads me to believe that alejo is correct that the problem is zero-link. |
| 02:52.40 | *** join/#bzflag JeffM (~JeffM@adsl-76-204-47-237.dsl.lsan03.sbcglobal.net) |
| 02:52.41 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 02:52.41 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 02:53.56 | JeffM | both engines are good, the irrlicht devs were kinda dicks, that's what got me onto lightfeather |
| 02:54.08 | delusional | the problems I see fit the symptoms described on the zeroLink page that alejo linked to. |
| 02:55.09 | JeffM | didn't it used to work yesterday? |
| 02:57.39 | delusional | I get waht appears to be a complete app, but it will not move to another machine. One of the symptoms described here http://meandmarkpublishing.blogspot.com/2007/01/zerolink.html |
| 03:00.33 | JeffM | did you turn off zerolink in the build options? |
| 03:01.38 | delusional | attempting.... i may need an earlier version of xcode to do that. |
| 03:01.59 | JeffM | the article states there are 2 ways to do it |
| 03:02.09 | JeffM | per project and for all of xcode |
| 03:04.32 | delusional | yeah, but that is nearing five years old |
| 03:05.01 | delusional | alejo knows more than I http://sourceforge.net/tracker/?func=detail&atid=103248&aid=3329389&group_id=3248 |
| 03:05.03 | JeffM | if you build from the command line and shove the executables into the .app does it work? |
| 03:05.23 | JeffM | I find it hard to belive apple would make an option that screws you over cus they removed it |
| 03:05.42 | JeffM | also most of the compiliation stuff is NOT handled by xcode, it's just a wraper over the makefile |
| 03:06.23 | delusional | that may actually work since i fixed my SDL for the ninety-ninth time... yesterday they were insisting I use the xcodeproj, I'll give it a whirl |
| 03:07.21 | JeffM | also the xcode project is just a file, you can edit it to turn options off |
| 03:07.55 | delusional | I did that, to disable the OSX 10.4 build options |
| 03:09.23 | JeffM | BulletCatcher uses a mac and I know he builds so I find it hard to belive that he was unable to do so. |
| 03:09.42 | JeffM | it's possible he busted it trying to make non sdl mac work |
| 03:09.51 | JeffM | if so we pull that crap cus who cares about non sdl |
| 03:09.57 | delusional | he built... did he try to give the app to anyone else? |
| 03:10.00 | JeffM | we pulled the native mac code in 2.99 |
| 03:10.02 | JeffM | I don't know |
| 03:10.16 | delusional | I'll bet he cant pass it on. |
| 03:10.24 | JeffM | thats sad |
| 03:10.36 | JeffM | makes mac dev worse then linux dev for runtime compatability |
| 03:12.11 | delusional | make |
| 03:12.13 | delusional | err |
| 03:19.16 | JeffM | if the makefile build has the same problem then it has nothing to do with xcode and is something in make or configure |
| 03:19.23 | JeffM | if it works, GREAT, ship it |
| 03:22.33 | delusional | this is the pastebin that allejo posted earlier.... I get the same error http://pastebin.com/rDtQS6vX |
| 03:22.43 | delusional | anisotropic |
| 03:23.19 | JeffM | if you open your config.h do you find a define for _HAVE_GLEW ? |
| 03:24.03 | BulletCatcher | That failure to link is a known problem right now. Sorry about that. |
| 03:24.05 | BulletCatcher | Roll back to r22006 as the temporary workaround. |
| 03:24.15 | JeffM | or just take out the #def :) |
| 03:24.33 | JeffM | I'm just trying to see where this incremental link issue is |
| 03:24.41 | JeffM | BulletCatcher, you ever give your bins to anyone else? |
| 03:24.45 | BulletCatcher | Nope. |
| 03:27.42 | delusional | is this correct? svn merge -r 22005:22006 https://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/ |
| 03:27.55 | *** join/#bzflag short_circuit (~spldart2@c-98-198-227-61.hsd1.tx.comcast.net) |
| 03:27.57 | BulletCatcher | No, just do "svn up -r 22006" |
| 03:28.08 | delusional | tanx |
| 03:28.21 | BulletCatcher | Then "make maintainer-clean" and start over with autogen.sh . |
| 03:28.36 | JeffM | or comment out one line in one file ;) |
| 03:28.42 | BulletCatcher | Or that. |
| 03:31.12 | delusional | i can't even find the file config.h |
| 03:31.36 | BulletCatcher | It would be in the include/ directory. |
| 03:31.36 | JeffM | it's generated by config but it should be somewhere |
| 03:33.56 | delusional | "GLEW" is not in config.h |
| 03:34.40 | BulletCatcher | Then it should not try to use GLEW when compiling bzflag. |
| 03:36.23 | BulletCatcher | Let's get your source tree into a clean state, delusional. |
| 03:36.37 | delusional | I'm up for that |
| 03:36.46 | JeffM | first get chicken |
| 03:36.54 | delusional | choking |
| 03:37.03 | BulletCatcher | In a terminal window, cd to the directory containing the file configure.ac . |
| 03:37.04 | JeffM | no no, burn it |
| 03:37.25 | BulletCatcher | Then run the command "make maintainer-clean" . |
| 03:37.43 | trepan | svn-clean, accept no substitutes :) |
| 03:37.51 | delusional | let's wait till the current compile fails |
| 03:38.07 | BulletCatcher | That's a good idea. |
| 03:38.45 | JeffM | install windows, press F5, get installer ;) |
| 03:39.18 | BulletCatcher | I recommend quiting the Xcode app while doing this cleanup procedure. |
| 03:39.41 | delusional | quit xcode over an hour ago |
| 03:40.12 | BulletCatcher | Then you could just type ctrl/c to make the compilation stop. |
| 03:40.22 | BulletCatcher | We're going to delete the results anyway. |
| 03:41.06 | delusional | alright... cd'd to configure.ac |
| 03:41.34 | trepan | JeffM: windows come with MSVC now? |
| 03:41.50 | JeffM | OSX come with xcode now? |
| 03:42.04 | trepan | he's already got thaty |
| 03:42.09 | BulletCatcher | The "make maintainer-clean" command will delete lots of files. |
| 03:42.10 | JeffM | but it don't work ;) |
| 03:42.19 | trepan | your plan's missing a few steps :) |
| 03:42.20 | delusional | ok, whats next |
| 03:42.23 | JeffM | but yes, install windows, download some stuff, press f5, get installer |
| 03:42.33 | BulletCatcher | "svn stat --no-ignore" |
| 03:42.51 | delusional | done |
| 03:42.59 | BulletCatcher | No output? |
| 03:43.13 | delusional | 2 lines |
| 03:43.15 | delusional | I .DS_Store |
| 03:43.15 | delusional | I src/.DS_Store |
| 03:43.41 | BulletCatcher | For completeness, delete those two files. |
| 03:43.52 | delusional | manually |
| 03:43.55 | BulletCatcher | (They will probably reappear at some point.) |
| 03:43.58 | BulletCatcher | Yes. |
| 03:44.10 | BulletCatcher | rm .DS_Store src/.DS_Store |
| 03:44.26 | trepan | and will likely get packaged into a .zip file by a Macster who doesn't know any better |
| 03:44.37 | JeffM | heh |
| 03:44.47 | delusional | .done |
| 03:45.02 | JeffM | better then that guy that packed all his obj files into his windows install |
| 03:45.04 | BulletCatcher | "svn stat --no-ignore" should now give no output. |
| 03:45.24 | delusional | correct |
| 03:45.28 | Flash | too many cooks. |
| 03:45.40 | BulletCatcher | Yay, you have a clean source tree. |
| 03:46.09 | delusional | now autogen, etc.. |
| 03:46.12 | delusional | ? |
| 03:46.19 | BulletCatcher | Now: "svn up -r 22006" to get back to this morning's state. |
| 03:46.32 | BulletCatcher | Before I made it try to use GLEW. |
| 03:46.45 | delusional | At revision 22006. |
| 03:46.57 | BulletCatcher | Welcome to 12 hours ago. |
| 03:47.08 | BulletCatcher | Now autogen.sh, configure, etc. as usual. |
| 03:49.10 | BulletCatcher | r22006 should compile and run successfully. |
| 03:50.11 | BulletCatcher | The Anisotropic option will be disabled, but that's okay for your purposes. |
| 03:53.59 | delusional | but it is going to build glew? |
| 03:54.10 | JeffM | no |
| 03:54.16 | BulletCatcher | It will neither build nor try to use GLEW. |
| 03:54.34 | delusional | that's not what it says Build glew ........: yes |
| 03:54.51 | BulletCatcher | Don't believe everything you read. :-) |
| 03:55.41 | BulletCatcher | It turns out that BZFlag has *never* (even in 2.99) built GLEW even though it said it wanted to. |
| 03:56.07 | delusional | i get a lot like this... |
| 03:56.13 | delusional | <PROTECTED> |
| 03:56.38 | JeffM | nothing should include it so it should be fine |
| 03:56.45 | BulletCatcher | Those are normal. Please remain in your seat and keep your hands and arms inside the window. |
| 03:58.20 | Flash | do not try this at home.... oh wait... |
| 03:59.32 | delusional | ... so i torrented the LulzSec file on the arizona police... there's a series of 40 photos labeled NARCOTRAFICANTES COLOMBIANOS Somebody (already dead) gets fed to the buzzards. |
| 04:01.46 | delusional | So now it's MAKE INSTALL? |
| 04:01.54 | JeffM | nope |
| 04:02.08 | JeffM | did it make a bzflag file in the src/bzflag? |
| 04:02.25 | BulletCatcher | Just run "src/bzflag/bzflag" from the current directory to test. |
| 04:02.25 | delusional | yes |
| 04:02.47 | JeffM | ether test it that way or shove it into the .app replacing the old one and test it |
| 04:03.04 | BulletCatcher | First things first, JeffM. |
| 04:03.14 | delusional | weeeeee! |
| 04:03.15 | JeffM | both are valid tests |
| 04:05.38 | JeffM | did it run from the command line? |
| 04:05.53 | delusional | yes |
| 04:05.58 | JeffM | ok good |
| 04:06.12 | JeffM | now do you have the .app somewhere? |
| 04:07.02 | delusional | there is no build directory, like when i run xcode |
| 04:07.18 | JeffM | I mean the one you built before |
| 04:07.25 | JeffM | or did you get rid of that? |
| 04:07.33 | delusional | it's in the trash |
| 04:07.36 | JeffM | get it out |
| 04:07.45 | delusional | get that and shove the new one in? |
| 04:07.46 | JeffM | then right click on it and there should be a way to expolore or open it |
| 04:07.48 | JeffM | yeah |
| 04:07.55 | JeffM | replace the old bzflag file in it with this new one |
| 04:08.01 | JeffM | then run the .app and make sure it works |
| 04:08.01 | delusional | BulletCatcher: agree? |
| 04:08.18 | BulletCatcher | You're moving beyond my experience now. |
| 04:08.36 | JeffM | the .app is just a folder with some magic files in it |
| 04:08.47 | BulletCatcher | But it is a plausible thing to try. |
| 04:08.57 | delusional | ok |
| 04:09.14 | JeffM | I'm just trying to narrow down where your zero link thing is coming from |
| 04:09.20 | JeffM | since the xcode project isn't a real project |
| 04:09.29 | JeffM | it just calls the command line script |
| 04:11.06 | delusional | seems to work |
| 04:11.17 | JeffM | ok now take that .app to another machine |
| 04:11.21 | JeffM | see if it works there |
| 04:11.30 | JeffM | or has the same issue your origonal .app had |
| 04:11.45 | delusional | nothing with bzadmin, etc..... yet |
| 04:11.54 | JeffM | just want to try the client |
| 04:14.47 | delusional | http://images.planet-mofo.com/A-Delusion/BZ_build/ |
| 04:14.54 | delusional | try it somebody |
| 04:25.11 | Flash | delusional: an .app is just a directory. From the command line, you can move into it and explore. |
| 04:25.23 | JeffM | he's already done with that |
| 04:25.24 | Flash | You will see that both bzflag and bzfs are in the .app |
| 04:25.47 | delusional | i was just being sure that that was what he wanted me to do |
| 04:26.10 | BulletCatcher | It didn't actually launch for me. |
| 04:26.42 | JeffM | that's what I figured woudl happen |
| 04:26.56 | JeffM | unless you turned that "zero link" think on with the makefiles then it has nothing to do with xcode |
| 04:27.10 | JeffM | so poking at options in its dialogs won't do nothin |
| 04:27.25 | JeffM | and that explains why it was all grayed out, cus xcode didn't know what it was building |
| 04:28.22 | BulletCatcher | Oh. It is a 64-bit file, and my machine is 32-bit. |
| 04:28.37 | JeffM | ok then nevermind :) |
| 04:28.58 | BulletCatcher | No conclusive results to see here, folks. Move along! |
| 04:29.07 | JeffM | you should build bins for distrobution as 32 bit unless you know how to make the .app package both |
| 04:29.26 | JeffM | it can handle both but I don't think our plist is setup for that |
| 04:29.50 | JeffM | that's how it does universal too, just packs more bins in there |
| 04:33.47 | delusional | I think i'm gonna keep to myself from now on. |
| 04:34.48 | JeffM | you cant buld 32bit? |
| 04:35.03 | JeffM | tho you'd have to build all the platforms too |
| 04:35.09 | JeffM | so that could be a pain |
| 04:38.52 | CIA-5 | BZFlag: 03JeffM2501 07http://my.bzflag.org * r7768 10/w/Development_RoadMap: more notes |
| 04:51.43 | *** join/#bzflag noyb (~noyb@pool-173-60-180-80.lsanca.dsl-w.verizon.net) |
| 05:51.46 | CIA-5 | BZFlag: 03bullet_catcher * r22012 10/trunk/bzflag/configure.ac: Replace the --enable-glew-build option with --with-included-glew to allow --with-included-glew=no to unconditionally disable the use of the embedded GLEW library. |
| 05:53.09 | BulletCatcher | On the Mac, configuring with --with-included-glew=no will now allow a successful build (without GLEW). |
| 05:58.43 | CIA-5 | BZFlag: 03bullet_catcher * r22013 10/trunk/bzflag/src/platform/MacOSX/MacWindow.cxx: Backport r19705 for Mac OS X 10.4 support. |
| 06:01.58 | BulletCatcher | We still can't build *with* src/other/glew on the Mac, but --with-included-glew=no gets us back to where we were at r22006. |
| 06:47.24 | *** join/#bzflag Marzipan- (~Marzipan@p5B223FFB.dip.t-dialin.net) |
| 06:48.16 | *** join/#bzflag Marzipan (~Marzipan@bzflag/player/Marzipan) |
| 07:22.15 | *** join/#bzflag AAA_awright_ (~a3@ip24-251-157-63.ph.ph.cox.net) |
| 08:02.07 | *** join/#bzflag bryjen (~bryjen@76.92.85.169) |
| 08:02.07 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 08:20.49 | *** join/#bzflag Pimpi (~frank@gondolin.pimpi.org) |
| 08:21.19 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 08:24.45 | *** join/#bzflag Upsetter (~er@i59F6D173.versanet.de) |
| 09:23.09 | *** join/#bzflag bryjen (~bryjen@76.92.85.169) |
| 09:23.09 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 11:30.20 | *** join/#bzflag mdskpr_ (~mdskpr@108.25.145.104) |
| 11:59.49 | joevano | delusional: doesn't run at all on my 10.6 64-bit MBP |
| 12:20.31 | delusional | what's the error... any? |
| 12:56.11 | blast007 | maybe we could just support Windows, Linux, Bootcamp, and Darwine ;) |
| 12:56.18 | blast007 | seems like it would be easier |
| 13:21.28 | joevano | delusional: BZFlag connot open because of a problem. Check with the developer to make sure it works with this version of the OS. |
| 13:22.05 | delusional | thats what I thought |
| 13:22.36 | joevano | the app size is only 32Mb compared to 178Mb for 2.0.16 |
| 13:23.16 | delusional | it works fine on my machine |
| 13:24.58 | blast007 | joevano: it's not a debug build now |
| 13:25.09 | blast007 | (nor is it a universal bin) |
| 13:45.29 | joevano | blast007: that makes sense |
| 14:21.22 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 14:28.24 | *** join/#bzflag mdskpr_ (~mdskpr@108.25.145.104) |
| 14:44.33 | *** join/#bzflag bier (~bier@p54A5B383.dip.t-dialin.net) |
| 14:44.37 | *** join/#bzflag bier|tp (~bier@p54A5B383.dip.t-dialin.net) |
| 15:52.05 | *** join/#bzflag Anxuiz (~Anxuiz@unaffiliated/anxuiz) |
| 15:52.26 | *** join/#bzflag Anxuiz_ (~Anxuiz@c-76-22-102-23.hsd1.wa.comcast.net) |
| 16:17.26 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 16:17.26 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 16:30.24 | mdskpr_ | JeffM: the bots bullet's come out lower than regular tank's bullets |
| 16:30.45 | JeffM | that makes no sense, they use the same code |
| 16:30.58 | JeffM | and is it a new issue for 2.4? |
| 16:31.08 | mdskpr_ | lemme see |
| 16:32.13 | mdskpr_ | yeah they are normal in 2.0.16 |
| 16:32.39 | JeffM | is this -solo bots or autopilot? |
| 16:32.45 | mdskpr_ | -solo |
| 16:32.53 | JeffM | wierd |
| 16:33.02 | JeffM | I didn't think anyone changed that code |
| 16:33.06 | JeffM | noting was on the list for that |
| 16:35.35 | mdskpr_ | the bots are not following reload time either |
| 16:35.51 | JeffM | check history and see who changed that stuff |
| 16:35.55 | JeffM | then we can kill them |
| 16:36.28 | *** join/#bzflag meeba (~lamer@c-71-196-238-53.hsd1.co.comcast.net) |
| 16:43.51 | mdskpr_ | also, with fog on, an OOized tank inside a building has no darkness |
| 16:47.46 | mdskpr_ | in robotplayer.cxx the only change is the moving of handicap to the server |
| 16:48.32 | JeffM | put a break point where the shot is created and see what sets its inital value |
| 16:52.18 | mdskpr_ | do robots and reg clients use the same shot creation function? |
| 16:54.49 | JeffM | yeah |
| 17:02.31 | mdskpr_ | reload time is working now, or i cant reproduce it |
| 17:03.05 | *** join/#bzflag Upsetter1 (~er@i59F6BFF1.versanet.de) |
| 17:17.54 | mdskpr_ | JeffM: nvm the reloadtime stuff |
| 17:26.16 | *** join/#bzflag noyb (~noyb@pool-173-60-180-80.lsanca.dsl-w.verizon.net) |
| 17:31.38 | trepan | mdskpr_: i'm seeing -solo robot shots at the normal height |
| 17:32.02 | mdskpr_ | you sure? try making the bullets really slow |
| 17:33.38 | trepan | i'm sure that they look normal |
| 17:33.51 | trepan | how much offset are you talking about? |
| 17:33.58 | mdskpr_ | .25? |
| 17:37.45 | trepan | http://trepan.bzflag.bz/noshow/robotShot.jpg -- .025, maybe :) |
| 17:37.56 | JeffM | that's not really realistic |
| 17:38.29 | mdskpr_ | nah because you are directly behind it, try from a 90 degree angle |
| 17:38.46 | JeffM | the Z should not change based on viewing angle |
| 17:39.04 | trepan | mdskpr_: it looks the same when I'm driving the tank |
| 17:40.22 | trepan | mdskpr_: you could setup a special map with drivethrough objects that are slighty lower than the muzzle height, see if robot shots clear them |
| 17:41.02 | mdskpr_ | ahh smart |
| 17:43.56 | mdskpr_ | they cleared it :/ |
| 17:44.49 | mdskpr_ | trepan: look at the OO+fog bug too<---thats definite : ) |
| 17:45.03 | trepan | you can look at it :) |
| 17:45.16 | trepan | as for the shots, have you had your eyes checked lately |
| 17:45.33 | trepan | regular visits can help early detection :) |
| 17:45.41 | mdskpr_ | well, to be fair, mcspider saw the same thing |
| 17:45.41 | McSpider | I saw it to :P |
| 17:45.46 | McSpider | must have been an optical illusion |
| 17:46.00 | trepan | or a glitch |
| 17:46.10 | trepan | what kind of was it on? |
| 17:46.19 | trepan | *of map |
| 17:46.21 | mdskpr_ | hix |
| 17:46.36 | trepan | bots were all on the ground? |
| 17:47.08 | mdskpr_ | yes |
| 18:02.34 | blast007 | were there flags? |
| 18:02.51 | mdskpr_ | yes |
| 18:04.22 | blast007 | had anyone grabbed burrow? wondering if the bots thought they had it.. |
| 18:05.22 | mdskpr_ | it wasnt that low |
| 18:09.55 | blast007 | maybe the bots were just a bit tired and were holding the muzzle too low |
| 18:10.05 | blast007 | try recharging their batteries |
| 18:19.00 | McSpider | http://cl.ly/7tzY |
| 18:26.19 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 18:27.16 | randomparticle | the guardian has just published the lulzsec irc logs. i guess ordinary people get to know what irc is now :--) |
| 18:27.17 | randomparticle | http://www.guardian.co.uk/technology/2011/jun/24/lulzsec-irc-leak-the-full-record |
| 18:34.18 | *** join/#bzflag bryjen (~bryjen@76.92.85.169) |
| 18:34.18 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 18:52.09 | Pimpinella | do bots still grab flags? |
| 18:52.56 | Pimpinella | i think that was pulled with server side flaqs |
| 18:54.55 | *** join/#bzflag randomparticle (~randompar@cpc3-wilm2-2-0-cust912.1-4.cable.virginmedia.com) |
| 18:54.55 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 19:05.57 | BulletCatcher | Solo bots drove right over flags without picking them up in a recent 2.3 test of mine. |
| 19:08.18 | randomparticle | they really don't care, do they? |
| 19:08.25 | BulletCatcher | The same thing happens in 2.0.16. |
| 19:09.12 | BulletCatcher | Yeah, those bots have no respect. |
| 19:11.48 | PlasticTank | They also shoot regular bullets regardless of the flag they are holding |
| 19:12.03 | PlasticTank | ex: SW, L, TH, SB |
| 19:12.31 | BulletCatcher | How do you get them to pick up those flags? |
| 19:14.13 | PlasticTank | "/flag give #" |
| 19:15.00 | BulletCatcher | (That was my best guess.) |
| 19:15.18 | Pimpinella | 22013, is that up to date? |
| 19:16.04 | BulletCatcher | Yes, 22013 is the latest revision. |
| 19:16.11 | Pimpinella | fails to build here |
| 19:16.17 | Pimpinella | in glew |
| 19:16.23 | BulletCatcher | On a Mac? |
| 19:16.34 | Pimpinella | debian unstable |
| 19:16.47 | Pimpinella | /home/frank/kdevelop/projects/bzflag/bzflag/src/bzflag/DisplayMenu.cxx:117: undefined reference to `__GLEW_EXT_texture_filter_anisotropic' |
| 19:17.07 | BulletCatcher | You don't have the system GLEW package installed. |
| 19:17.32 | BulletCatcher | To build successfully without it you need to configure with --with-included-glew=no . |
| 19:17.36 | Pimpinella | iirc configure told me it'll use building glew |
| 19:17.55 | Pimpinella | buildin |
| 19:18.22 | BulletCatcher | Building glew doesn't work right now. |
| 19:18.57 | BulletCatcher | I hope to get that fixed today. |
| 19:19.03 | Pimpinella | ok |
| 19:19.12 | Pimpinella | Build glew ........: yes |
| 19:19.49 | BulletCatcher | As you saw, it doesn't really work. |
| 19:19.55 | Pimpinella | yep |
| 19:52.25 | trepan | "bzfs -f xxx" -- ~WorldEventManager is causing another crash on exit |
| 19:55.58 | trepan | my original suggestion to check (*itr)->plugin would probably fix this, and any similar exit-crash situations |
| 19:56.07 | trepan | s/probably/fixes/ :) |
| 20:13.15 | blast007 | trepan: is that fixing the problem or just concealing it? |
| 20:14.32 | JeffM | what is the core problem? are the events killed before the plugins or something? |
| 20:14.55 | blast007 | well, it's trying to delete a bz_EventHandler that has a null pointer to a plugin |
| 20:15.34 | trepan | the core problem is the bzfsHTTP is treated as a special case |
| 20:16.33 | trepan | but not fully, checking the ->plugin value before trying to delete it rounds out the special case |
| 20:18.57 | JeffM | ahh ok, yeah not all events have plugins |
| 20:19.02 | JeffM | so yes checking fixes the problem |
| 20:19.51 | JeffM | tho all the destructor does is delete the EventList item, not the plugin |
| 20:19.56 | JeffM | so I don't see where the check would go |
| 20:20.21 | trepan | take a look at ConnectionEvent |
| 20:20.23 | *** join/#bzflag randomparticle (~randompar@cpc3-wilm2-2-0-cust912.1-4.cable.virginmedia.com) |
| 20:20.23 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 20:21.12 | JeffM | yes I understand that is an event handler with out a plugin |
| 20:21.26 | JeffM | but where does the WorldEventManager use the plugin pointer in it's destructor |
| 20:22.05 | blast007 | ~bz_EventHandler ? |
| 20:22.21 | JeffM | no, all that does is set the pointer to null |
| 20:23.04 | blast007 | it's crashing there though |
| 20:23.23 | trepan | it's trying to free ConnectionEvent |
| 20:23.30 | blast007 | http://pastebin.com/gWvKNdnS |
| 20:23.35 | JeffM | ahh ok, |
| 20:23.40 | JeffM | and that wasn't allocated dynamicly |
| 20:23.43 | JeffM | ok I understand |
| 20:23.46 | trepan | bingo |
| 20:25.10 | JeffM | I'm not sure if I like assuming that all ones with out plugins are static |
| 20:25.18 | trepan | i guess one of the questions is whether or not a bz_EventHandler with plugin==NULL should actually be freed at that location |
| 20:26.05 | JeffM | ponders |
| 20:26.54 | trepan | you might want to add a 'virtual bool iNeedMeSomeKillin() const { return true; }' to the bz_EventHandler class |
| 20:27.06 | JeffM | or make the connection handler dynamic |
| 20:27.28 | trepan | the latter is probably better, could even make bzfsHTTP dynamic |
| 20:27.44 | JeffM | that's what I'm pondering |
| 20:31.43 | JeffM | hmm the events should be deregistered and removed from the event itr when plugins are unloaded |
| 20:31.56 | JeffM | so even if it's static it should not be in that list to be deleted |
| 20:32.27 | trepan | maybe it's not being unloaded |
| 20:32.51 | *** join/#bzflag randomparticle (~randompar@cpc3-wilm2-2-0-cust912.1-4.cable.virginmedia.com) |
| 20:32.51 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 20:32.52 | JeffM | yeah that's probalby it |
| 20:33.07 | JeffM | bet unload isn't called when the app is killed |
| 20:33.25 | JeffM | only when it's shut down from a command |
| 20:33.33 | trepan | that was the fix that was slapped on last time this happened, a call to unload bzfsHTTP |
| 20:34.03 | JeffM | HTTP is inited and killed when we try to load plugins and free them |
| 20:34.23 | trepan | killed in at least 2 spots in bzfs.cxx now |
| 20:34.26 | JeffM | isn't there a section of code that is called when CTL+ C is hit ? |
| 20:34.53 | JeffM | well I can make it dynamic then anyone can free it :) |
| 20:35.07 | trepan | ya, that sounds less kludgy |
| 20:36.59 | trepan | mispelled that, apparently :) (From the old Scots "kludgie" meaning an outside toilet) |
| 20:37.37 | CIA-5 | BZFlag: 03JeffM2501 * r22014 10/trunk/bzflag/src/bzfs/bzfsHTTPAPI.cxx: dynamicly allocate the ConnectionEvent handler so the event manager can delete it in the case where the app is just killed |
| 20:39.38 | trepan | still SEGV's on exit, but it's a little different |
| 20:41.03 | *** join/#bzflag sirquine (~quine@212.31.54.80) |
| 20:55.29 | *** join/#bzflag Marzipan (~Marzipan@bzflag/player/Marzipan) |
| 20:56.38 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 21:18.50 | blast007 | there's two bz_EventHandler handlers that are being deleted by ~WorldEventManager. The first one goes fine, but the second one crashes. |
| 21:19.05 | blast007 | (this is with bzfs -f xxx) |
| 21:22.04 | JeffM | world wepons |
| 21:22.44 | blast007 | bz_eNewNonPlayerConnection is the event type of the one crashing |
| 21:22.53 | JeffM | hmmm |
| 21:22.54 | blast007 | bz_eTickEvent is the one that is working |
| 21:23.02 | blast007 | both have a null plugin |
| 21:23.20 | JeffM | both are the SAME |
| 21:23.25 | JeffM | that's why |
| 21:23.28 | JeffM | hmmm |
| 21:26.30 | CIA-5 | BZFlag: 03JeffM2501 * r22015 10/trunk/bzflag/src/bzfs/bzfsHTTPAPI.cxx: split con and tick so they can be killed separately. |
| 21:45.29 | blast007 | JeffM: that worked |
| 21:46.52 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 21:46.52 | *** mode/#bzflag [+v spldart] by ChanServ |
| 23:24.37 | *** join/#bzflag meeba (~lamer@c-71-196-238-53.hsd1.co.comcast.net) |
| 23:30.05 | *** join/#bzflag TD-Linux (~thomas@68-115-86-128.dhcp.roch.mn.charter.com) |
| 23:30.05 | *** join/#bzflag TD-Linux (~thomas@about/essy/indecisive/TD-Linux) |
| 23:38.39 | *** join/#bzflag JeffM1 (~Jeff@adsl-76-204-47-237.dsl.lsan03.sbcglobal.net) |
