| 00:01.14 | *** join/#bzflag Gilly (~btw@about/essy/ilkimys/gilly) |
| 00:11.37 | *** join/#bzflag ruskie (ruskie@sourcemage/mage/ruskie) |
| 00:19.10 | *** join/#bzflag GvzEvxre (timr@bzflag/projectlead/TimRiker) |
| 00:19.10 | *** mode/#bzflag [+o GvzEvxre] by ChanServ |
| 00:35.50 | TimRiker | ahh sudo apt-get install libc-ares-dev |
| 00:37.39 | *** join/#bzflag Anxuiz (~Anxuiz@50-46-121-138.evrt.wa.frontiernet.net) |
| 00:37.39 | *** join/#bzflag Anxuiz (~Anxuiz@unaffiliated/anxuiz) |
| 00:53.53 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
| 02:01.41 | *** join/#bzflag Foo_man_choo (~spldart2@c-98-198-227-61.hsd1.tx.comcast.net) |
| 02:28.03 | trepan | for post-2.4, http://trepan.bzflag.bz/noshow/phymats-2.4beta-20110621.diff |
| 02:28.13 | trepan | material with physics properties |
| 02:28.43 | trepan | effectively server-side only, no protocol change (2.4.2 candidate) |
| 02:33.01 | *** join/#bzflag Think_Differentl (~Think_Dif@213.152.174.186) |
| 02:33.01 | *** join/#bzflag Think_Differentl (~Think_Dif@bzflag/player/ThinkDifferent) |
| 02:37.35 | delusional | keep the good times rolling, trepan |
| 02:41.24 | CIA-5 | BZFlag: 03timriker * r21961 10/trunk/bzflag/debian/control: build depends |
| 02:42.07 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 02:42.07 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 02:45.56 | CIA-5 | BZFlag: 03timriker * r21962 10/trunk/bzflag/debian/rules: no more --host=i486-pc-linux-gnu |
| 02:51.05 | trepan | delusional: ? |
| 02:52.23 | delusional | whatever... maybe that didnt make sense.... just keep the good stuff comin |
| 02:53.19 | trepan | that patch is mostly useful for folks wanting to make maps using a modeller |
| 02:53.28 | delusional | i see that |
| 02:53.43 | trepan | much easier to assign a material in the modeller than to hand edit every resultant bzw object |
| 02:54.02 | delusional | much |
| 02:54.43 | trepan | didn't even realize i'd kept that patch around, but was chatting with ahs3 and ... |
| 03:05.25 | *** join/#bzflag yosef (~yoyo@70-138-149-250.lightspeed.hstntx.sbcglobal.net) |
| 03:06.54 | *** join/#bzflag yosefk (~yoyo@unaffiliated/yosefk) |
| 03:24.17 | *** join/#bzflag meem1029 (~meem1029@24-177-102-250.dhcp.roch.mn.charter.com) |
| 03:30.23 | *** join/#bzflag short_circuit (~spldart2@c-98-198-227-61.hsd1.tx.comcast.net) |
| 03:38.35 | *** join/#bzflag Packman2 (~a@115-188-244-191.jetstream.xtra.co.nz) |
| 03:39.21 | Packman2 | a bit obvious, but F5 is not working |
| 03:41.39 | Packman2 | (windows, 0621 build), the .png does not get closed until exiting bzflag; it keeps overwriting bzfi0001; and the image is distorted and B&W |
| 03:43.43 | blast007 | Packman2: verify the key mapping is set for that key |
| 03:43.48 | *** mode/#bzflag [-o blast007] by blast007 |
| 03:44.38 | blast007 | for that action* |
| 03:45.14 | Packman2 | confirmed; "bind F5 down screenshot" |
| 03:47.12 | Packman2 | it appears as though "lastScreenshot" isn't even used |
| 03:50.24 | TD-Linux | yeah that's not the key mapping bug |
| 03:50.39 | TD-Linux | maybe this is why the screenshot feature was disabled |
| 03:50.56 | TD-Linux | I can look at fixing it tomorrow |
| 03:52.03 | Packman2 | also, it could just be me, but -directory never seems to be about to find the fonts |
| 03:53.13 | TD-Linux | works for me on linux, the screenshot code is threaded now, probably some platform specific issues |
| 04:01.44 | *** join/#bzflag Flash (~jwmelto@c-75-70-62-116.hsd1.co.comcast.net) |
| 04:01.44 | *** join/#bzflag Flash (~jwmelto@bzflag/developer/Flash) |
| 04:02.36 | Packman2 | there are also the hitzone bugs that have been around for ages |
| 04:03.43 | Packman2 | as in http://my.bzflag.org/bb/viewtopic.php?f=32&t=13649 |
| 04:06.22 | TimRiker | configure: error: `CFLAGS' was not set in the previous run |
| 04:07.00 | TimRiker | ares build wants to set CFLAGS and other bits when I call it from the deb build, but works outside that. not sure why yet. |
| 04:07.18 | yosefk | I've noticed that my jitter increases annoyingly while playing the beta |
| 04:07.29 | yosefk | and yet it doesn't show up under lagstats |
| 04:08.59 | blast007 | TD-Linux: the screenshot feature wasn't disabled |
| 04:09.06 | blast007 | it was supposed to have been improved |
| 04:09.10 | blast007 | (threaded now) |
| 04:10.05 | blast007 | Packman2: we're not going to fix any hitzone bugs at this point |
| 04:10.18 | blast007 | not for 2.4 anyway |
| 04:10.58 | blast007 | yosefk: how do you know your jitter is increasing? |
| 04:11.57 | TD-Linux | blast007: yeah it was disabled sortof by removing the keymapping |
| 04:12.09 | blast007 | I doubt that was intentional though |
| 04:12.21 | blast007 | probably just something got screwed up when backporting it from 2.99.x |
| 04:12.47 | TD-Linux | yeah probably, missed the line to close the file on windows |
| 04:12.53 | TD-Linux | or some #ifdefs are placed wrong |
| 04:18.06 | TD-Linux | heh I didn't know bzflag embedded GL data in the screenshot |
| 04:23.06 | TD-Linux | ok it looks like the screenshot code use FILEMGR to get a std::ostream pointer |
| 04:23.43 | TD-Linux | because it's a pointer the stream is not deallocated at the end of the function... e.g. file is not closed |
| 04:24.00 | TD-Linux | opening the file seems to only be a test though, BzPNG takes filename |
| 04:27.42 | TD-Linux | why does FileManager::createDataOutStream return ostream* and not ofstream* ? |
| 04:28.40 | TD-Linux | also I think the windows directory iterating part of writeScreenshot leaks a handle by not calling CloseHandle (win32 person should check that) |
| 04:29.37 | blast007 | taking a screenshot on Windows worked fine |
| 04:30.03 | TD-Linux | can't reproduce Packman2's issue? |
| 04:30.19 | Packman2 | if it changes anything i'm 64-bit |
| 04:30.34 | Packman2 | blast you don't keep overwriting the same file? |
| 04:30.49 | blast007 | hahaha, guess I do |
| 04:31.01 | Packman2 | also identifier still gives you tip-offs when you drop it for as long as your lag |
| 04:31.13 | TD-Linux | I'm pretty sure bzflag leaves _a_lot_ of open file handles |
| 04:31.20 | TD-Linux | there is no way to close a file when using FILEMGR |
| 04:31.23 | blast007 | probably |
| 04:31.37 | TD-Linux | it passes a ostream* |
| 04:32.02 | TD-Linux | could be fixed by passing a ofstream* and using .close() and delete |
| 04:32.21 | TD-Linux | or std::auto_ptr |
| 04:32.43 | *** join/#bzflag bryjen (~bryjen@76.92.85.169) |
| 04:32.43 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 04:34.30 | Packman2 | identifier has some funny lag stuff, unless its just me dropping a packet and server thinks i went somewhere |
| 04:34.57 | TD-Linux | server doesn't track your motion |
| 04:35.35 | TD-Linux | may be best to file these as bugs on sf |
| 04:36.35 | Flash | TD-Linux: ostream is more generic |
| 04:37.43 | *** join/#bzflag tupone (~tupone@gentoo/developer/tupone) |
| 04:37.43 | *** mode/#bzflag [+v tupone] by ChanServ |
| 04:39.22 | CIA-5 | BZFlag: 03timriker * r21963 10/trunk/bzflag/debian/buildsnap: syntax |
| 04:39.42 | CIA-5 | BZFlag: 03timriker * r21964 10/trunk/bzflag/misc/tar: exclude more |
| 04:48.02 | TD-Linux | Flash: but it makes it not possible to close the file |
| 04:48.09 | TD-Linux | because it is passed as a pointer |
| 04:48.21 | Flash | is the pointer allocated memory? |
| 04:50.40 | TD-Linux | Flash: yes, it's a pointer to a dynamically allocated ifstream or ofstream |
| 04:50.45 | TD-Linux | cast as a istream* or ostream* |
| 04:51.14 | Flash | so you can just delete it, and the ofstream destructor will close the file |
| 04:52.07 | Flash | ostream is a base class of ofstream |
| 04:53.49 | Flash | the fact that it is a file-based stream vs a memory-based stream (std::ostringstream) or any other kind of stream is not important to the users. They use it as a stream |
| 04:53.50 | TD-Linux | I guess that works too... I was making it a bit complicated :P |
| 04:58.17 | yosefk | blast007: I just tested it with someone - it's a graphics issue |
| 04:58.27 | blast007 | with just you, or with them too? |
| 04:58.32 | yosefk | with me |
| 04:58.34 | blast007 | ok |
| 04:58.41 | CIA-5 | BZFlag: 03timriker * r21965 10/trunk/bzflag/src/date/buildDate.cxx: speeling |
| 04:58.43 | yosefk | anything higher than low setting makes it happen |
| 04:58.46 | blast007 | make sure you have the latest video driver |
| 04:59.00 | yosefk | I have a legacy version |
| 04:59.00 | blast007 | what video chipset/card do you have? |
| 04:59.17 | yosefk | nforce integrated GPU MX 4 |
| 04:59.23 | blast007 | ouch |
| 04:59.31 | blast007 | so basically a geforce 2, iirc ;) |
| 04:59.43 | blast007 | just a *bit* on the old side there |
| 04:59.45 | yosefk | basic stuff, yes |
| 04:59.55 | yosefk | it was hard enough getting zenwalk to run right |
| 05:00.07 | yosefk | but hey, I can play bzflag and the latest supertuxcart :) |
| 05:00.36 | blast007 | I haven't gotten my FX 5200 to work on Ubuntu 10.04 right, yet :P |
| 05:00.43 | yosefk | good luck |
| 05:00.44 | blast007 | can't imagine something even older |
| 05:01.01 | yosefk | Fedora doesn't cut it, only lighter distros |
| 05:01.09 | yosefk | at least, not since F11 |
| 05:01.16 | TD-Linux | yosefk: is this "frame jitter", like some frames take too long to render? |
| 05:01.30 | blast007 | probably his driver pooping itself |
| 05:01.38 | yosefk | blast007: yes |
| 05:01.40 | TD-Linux | also it looks like 2.0.x used "lastScreenshot" bzdb var |
| 05:01.45 | blast007 | or his IGP running out of memory |
| 05:02.03 | blast007 | yosefk: what resolution are you running it at? |
| 05:02.11 | TD-Linux | so the find-lowest-filename bit on windows is new |
| 05:02.24 | blast007 | TD-Linux: that's from 2.99.x |
| 05:02.40 | yosefk | 1024x768 |
| 05:02.41 | TD-Linux | and also the png writer is new |
| 05:02.55 | Packman2 | how come /localset fpsLimit 0 now sets it to 15 instead of (as one might expect) unlimited? |
| 05:03.22 | blast007 | we clamped it |
| 05:03.32 | blast007 | and one would not expect it to be unlimited |
| 05:03.38 | blast007 | if you want unlimited, turn off the energy saver |
| 05:03.45 | blast007 | (and vsync in your driver) |
| 05:03.52 | yosefk | JeffM: extended marker stays on in all settings |
| 05:04.23 | yosefk | there are problems with the autopilot and extended markers |
| 05:04.52 | yosefk | after turning roger off, the brackets around the other player (being targeted?) stay on |
| 05:05.57 | yosefk | also, if the other player has ST, and you turn the autopilot on twice, the second time the red brackets appear around the stealthed tank |
| 05:07.00 | blast007 | TD-Linux: r21440 was the new screenshot stuff |
| 05:08.35 | blast007 | yosefk: oooo, I could fix that! |
| 05:08.40 | blast007 | removes autopilot |
| 05:08.42 | blast007 | fixed! |
| 05:08.43 | blast007 | ;) |
| 05:09.00 | blast007 | we should probably just disable markers when in autopilot |
| 05:09.14 | yosefk | markers in general are hard to deal with |
| 05:09.24 | blast007 | how so? |
| 05:09.51 | yosefk | they turn on when a player is behind a wall, but turn off when the player is not moving |
| 05:10.12 | yosefk | I also don't understand the purpose of markers at all for marking other players |
| 05:10.19 | yosefk | is it a targeting feature? |
| 05:10.28 | blast007 | essentially, yeah |
| 05:11.00 | yosefk | I played with bots and the marker passed from one team player to the other completely randomly |
| 05:11.20 | yosefk | without gm, why is it needed? |
| 05:11.23 | blast007 | well, it's targeting and identification |
| 05:11.37 | yosefk | you see your target already! |
| 05:12.03 | *** join/#bzflag noyb (~noyb@pool-173-60-180-80.lsanca.dsl-w.verizon.net) |
| 05:12.28 | blast007 | shrugs |
| 05:13.07 | yosefk | I'm sure this conversation already went on somewhere |
| 05:13.20 | yosefk | or in someone's mind |
| 05:13.55 | yosefk | anyway, there's also a slight ID flag lag |
| 05:14.32 | yosefk | as in, after dropping the ID flag the identification of flags goes on for half a second or so |
| 05:15.15 | blast007 | that depends on your lag |
| 05:15.32 | blast007 | the server tells you the nearby flag |
| 05:15.37 | yosefk | all flags are server-side now? |
| 05:15.41 | Packman2 | but should you receive flag ID even after you dropped ID flag |
| 05:15.44 | blast007 | identification is server side |
| 05:15.51 | yosefk | that explains it |
| 05:15.58 | blast007 | Packman2: until the server knows that you dropped it, yeah |
| 05:16.27 | blast007 | so if you have 250ms of lag, the server won't know for 250ms, and you'll get updates 250ms after that (since they take 250ms to get to you) - of course assuming symetric lag |
| 05:17.26 | blast007 | we could make the server hide the identification message after it knows it dropped the flag |
| 05:18.31 | yosefk | please do |
| 05:19.26 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 05:19.37 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 05:20.00 | yosefk | blast007: does the new rico effect have to enabled by the map / server owner? |
| 05:20.02 | Packman2 | nah its fine i prefer to know :P |
| 05:22.28 | yosefk | it's not like it's that much better than before |
| 05:22.49 | yosefk | I mean, it's not showing up in tie-die colors |
| 05:25.16 | blast007 | yosefk: "rico effect" referring to per-object ricochet? if so, that's a map feature. |
| 05:25.50 | yosefk | adds a nice new level of complexity to maps |
| 05:25.56 | yosefk | whose idea was it? |
| 05:26.05 | blast007 | check the changelog |
| 05:26.11 | blast007 | it was backported from 2.99.x |
| 05:26.42 | blast007 | https://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/ChangeLog (in case you don't have the source tar/checkout) |
| 05:27.47 | blast007 | trepan had made the feature originally |
| 05:28.29 | Packman2 | not sure if intended, but self-linked teleporter behaviour has changed |
| 05:30.17 | blast007 | changed how? |
| 05:30.44 | Packman2 | bzflag3.norang.ca:10000 easiest way to prove |
| 05:52.45 | *** join/#bzflag bryjen (~bryjen@76.92.85.169) |
| 05:52.45 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 06:04.23 | *** join/#bzflag QBeep (~QuantumB@cpe-76-186-97-233.tx.res.rr.com) |
| 06:18.55 | CIA-5 | BZFlag: 03timriker * r21966 10/trunk/bzflag/ (README README.SDL debian/bzflag.docs): README.WIN32 |
| 06:42.13 | CIA-5 | BZFlag: 03timriker * r21967 10/trunk/bzflag/debian/ (buildsnap bzflag.docs rules): deb updates |
| 06:43.05 | TimRiker | what files are new that need to be added to the .deb builds? |
| 06:45.57 | blast007 | starting a list of the bugs found in the beta: http://static.bzexcess.com/bzflag23_bugs.txt |
| 06:46.52 | blast007 | TimRiker: well, if plugins are getting bundled, all of those (specifically the .so files, and maybe other types like .la and .a) |
| 06:47.21 | blast007 | if we're bundling any map files like hix, they're in misc/maps/ now |
| 06:49.57 | blast007 | beyond that, I'm not sure |
| 06:50.48 | TimRiker | I have /usr/share/doc/bzflag-server/hix.bzw.gz in there |
| 06:50.58 | *** join/#bzflag Marzipan- (~Marzipan@p5B223F9B.dip.t-dialin.net) |
| 06:51.36 | *** join/#bzflag Marzipan (~Marzipan@bzflag/player/Marzipan) |
| 06:51.53 | TimRiker | I don't have a misc/ in the bzflag-server package |
| 06:52.07 | blast007 | that's in the source tree |
| 06:58.33 | TimRiker | nods. for some reason hix gets compressed, but the other two do not. hmm. |
| 07:02.41 | CIA-5 | BZFlag: 03timriker * r21968 10/trunk/bzflag/plugins/ (fastmap/fastmap.cpp webReport/webReport.cpp): copyright |
| 07:05.31 | CIA-5 | BZFlag: 03timriker * r21969 10/trunk/bzflag/plugins/Makefile.am: sort |
| 07:06.44 | BulletCatcher | I think other plugins depend on plugin_utils being compiled first. |
| 07:11.03 | BulletCatcher | But I see that the ones that do so are sorted after plugin_utils itself. |
| 07:12.51 | *** join/#bzflag Packman2_ (~a@115-188-244-191.jetstream.xtra.co.nz) |
| 07:16.37 | TimRiker | BulletCatcher, k, might move that back to first then. |
| 07:17.12 | BulletCatcher | We'll have to do it eventually. |
| 07:17.13 | BulletCatcher | Might as well do it now and add a comment that it should be first. |
| 07:17.59 | CIA-5 | BZFlag: 03timriker * r21970 10/trunk/bzflag/ (88 files in 25 dirs): ws |
| 07:19.09 | CIA-5 | BZFlag: 03timriker * r21971 10/trunk/bzflag/plugins/Makefile.am: plugin_utils |
| 07:22.42 | TimRiker | where do other packages put plugins and readmes for them? |
| 07:24.15 | TimRiker | plugins/<name>/(README.txt,<name>.so) ? I'd prefer plugins/<name>.(txt,so) |
| 07:24.24 | BulletCatcher | Fedora includes only the plugin .so files, in the /usr/lib/bzflag (or lib64) directory. |
| 07:24.29 | TimRiker | perhaps even txt.gz |
| 07:24.58 | TimRiker | BulletCatcher, no README for them? that's less than useful, no? |
| 07:25.19 | BulletCatcher | I am not aware of any complaints. :-p |
| 07:25.58 | BulletCatcher | You could put the plugin README files the same place you put the top-level README, COPYING, etc. |
| 07:26.12 | BulletCatcher | Or maybe in a subdirectory of that. |
| 07:27.02 | BulletCatcher | On Fedora, that is /usr/share/doc/bzflag-2.0.16 . |
| 07:27.08 | TimRiker | /usr/share/doc/bzflag-server/ |
| 07:29.01 | TimRiker | build now mentions a "Configuration file" directory. do we look in /etc/* or someplace for configs now? or is that just a autoconf leftover? |
| 07:30.56 | BulletCatcher | That should be pulled out of configure.ac (which was backported from 2.99). |
| 07:31.07 | BulletCatcher | Whatever it is, we don't use it in 2.3. |
| 07:33.21 | *** join/#bzflag meeba (~lamer@c-71-196-238-53.hsd1.co.comcast.net) |
| 07:34.09 | *** join/#bzflag Foo_man_choo (~spldart2@c-98-198-227-61.hsd1.tx.comcast.net) |
| 07:34.23 | CIA-5 | BZFlag: 03bullet_catcher * r21972 10/trunk/bzflag/BUGS: Add new 2.3 bugs reported on first day of beta testing. |
| 07:35.06 | BulletCatcher | blast007, I included your bzflag23_bugs.txt contents in the BUGS file. |
| 07:36.26 | CIA-5 | BZFlag: 03timriker * r21973 10/trunk/bzflag/configure.ac: no sysconfdir here |
| 07:38.17 | *** join/#bzflag Packman2 (~a@115-188-244-191.jetstream.xtra.co.nz) |
| 07:38.50 | Packman2 | here is the screenshot bug i get: http://i54.tinypic.com/2zdzvi1.jpg |
| 07:39.30 | AAA_awright | That looks like a cool new bad flag |
| 07:40.32 | BulletCatcher | Is that just a single screenshot that wasn't mangled by being overwritten? |
| 07:41.45 | BulletCatcher | Were you traveling very close to the speed of light when the screenshot was taken? ;-) |
| 07:42.00 | TimRiker | wonders if it has something to do with 1366 not being a multiple of 8 |
| 07:47.04 | *** join/#bzflag Packman_ (~a@115-188-244-191.jetstream.xtra.co.nz) |
| 07:53.51 | CIA-5 | BZFlag: 03bullet_catcher * r21974 10/trunk/bzflag/src/bzflag/defaultBZDB.cxx: Remove the lastScreenshot BZDB variable, which is no longer used. |
| 07:57.05 | Packman_ | TimRiker: ah screenshot is fine with 1360 |
| 07:58.25 | *** join/#bzflag short_circuit (~spldart2@c-98-198-227-61.hsd1.tx.comcast.net) |
| 08:05.23 | CIA-5 | BZFlag: 03timriker * r21975 10/trunk/bzflag/misc/ws.sh: leave others alone |
| 08:05.57 | BulletCatcher | On my Linux system, F5 silently does nothing when I run "bzflag -window 1366x768". |
| 08:06.21 | TimRiker | Packman_, k. add that to the bug report. we apparently have issues with odd widths. perhaps heights too. |
| 08:06.30 | BulletCatcher | I get a normal screenshot when I use a regular 4x3 aspect ratio window. |
| 08:07.25 | TimRiker | I don't think it's the aspect ratio, I think it's the non-multiples-of-8 |
| 08:07.36 | BulletCatcher | Yeah. |
| 08:09.47 | CIA-5 | BZFlag: 03bullet_catcher * r21976 10/trunk/bzflag/BUGS: Add more information about screenshot bugs. |
| 08:10.47 | BulletCatcher | s/multipe/multiple/ in the BUGS file. |
| 08:12.56 | BulletCatcher | hits the hay to prevent committing more spelling crimes |
| 08:13.47 | *** join/#bzflag GransRemedy (~john@121-79-204-29.sta.inspire.net.nz) |
| 08:20.21 | *** join/#bzflag Pimpi (~frank@gondolin.pimpi.org) |
| 08:21.07 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 08:32.02 | *** join/#bzflag Foo_man_choo (~spldart2@c-98-198-227-61.hsd1.tx.comcast.net) |
| 08:32.42 | Packman_ | hmm someone suggested I should file bug reports on sourceforge; should I bother or not since they are recorded two other ways? |
| 08:41.42 | CIA-5 | BZFlag: 03timriker * r21977 10/trunk/bzflag/ (4 files in 2 dirs): plugins in deb |
| 08:55.32 | CIA-5 | BZFlag: 03timriker * r21978 10/trunk/bzflag/debian/control: libglew-dev too |
| 09:01.04 | TimRiker | would be nice if when there is a system glew (for example) configure would skip src/other/* entirely. |
| 09:02.31 | TimRiker | would also be nice if there was a --disable-all-builds, etc. such that build would fail if system lib was not there. |
| 09:05.12 | CIA-5 | BZFlag: 03timriker * r21979 10/trunk/bzflag/configure.ac: ws |
| 10:50.02 | CIA-5 | BZFlag: 03trepan * r21980 10/trunk/bzflag/ChangeLog: * mentioned -publickey and -publictitle in the Changelog |
| 11:36.28 | *** join/#bzflag kierra_away (~jolie@unaffiliated/kierra) |
| 12:12.05 | *** join/#bzflag mdskpr_ (~mdskpr@108.25.145.104) |
| 13:10.49 | *** join/#bzflag GvzEvxre (timr@bzflag/projectlead/TimRiker) |
| 13:10.49 | *** mode/#bzflag [+o GvzEvxre] by ChanServ |
| 14:01.18 | *** join/#bzflag PlasticT1nk (~plasticta@bzextreme.com) |
| 14:10.47 | CIA-5 | BZFlag: 03bthansen * r21981 10/trunk/bzflag/debian/README.Debian: Fix typo: enviornment -> environment |
| 14:23.41 | *** join/#bzflag [dmp] (~dennis@users.d75.net) |
| 14:23.41 | *** join/#bzflag [dmp] (~dennis@unaffiliated/dmp/x-546784) |
| 14:38.14 | *** join/#bzflag BulletCatcher (~bc@bzflag/developer/BulletCatcher) |
| 14:41.39 | *** join/#bzflag Admirarch (~Athelthra@mrush.mth.abdn.ac.uk) |
| 14:42.02 | *** join/#bzflag bier|tp (~bier@p54A59AD9.dip.t-dialin.net) |
| 14:42.04 | *** join/#bzflag bier (~bier@p54A59AD9.dip.t-dialin.net) |
| 14:46.54 | *** join/#bzflag meeba (~lamer@c-71-196-238-53.hsd1.co.comcast.net) |
| 15:03.30 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 15:03.30 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 15:06.12 | JeffM | anyone want to look at the screenshot bug that was reported? https://sourceforge.net/tracker/?func=detail&atid=103248&aid=3324412&group_id=3248 |
| 15:06.46 | brad | BC and Tim were looking last night |
| 15:06.57 | brad | or at least discussing it |
| 15:06.58 | BulletCatcher | Some of the problems are only on Windows. |
| 15:07.08 | BulletCatcher | See the current BUGS file for more info. |
| 15:07.08 | JeffM | interesting |
| 15:07.11 | JeffM | k |
| 15:08.30 | JeffM | can you add a note to the SF bug that it's been looked at? |
| 15:08.43 | JeffM | or at least that there is more info in the bugs file |
| 15:09.20 | BulletCatcher | will do |
| 15:09.24 | JeffM | thanks |
| 15:11.09 | JeffM | you will want DTRemenak to look at the odd size one |
| 15:11.37 | BulletCatcher | I am preparing to revert r21681, which is the most obvious culprit for the self-linked teleporter bug. |
| 15:11.38 | BulletCatcher | Must test first. |
| 15:12.06 | JeffM | what is the one about shot lenght setting? |
| 15:12.19 | blast007 | JeffM: it doesn't turn on the new shot style |
| 15:12.25 | JeffM | cus that changed a bit and I'm wondering what people exext to happen |
| 15:12.26 | JeffM | when? |
| 15:12.29 | blast007 | I always see the old shot graphic regardless of that setting |
| 15:12.44 | JeffM | in high or experimental? |
| 15:12.48 | blast007 | the normal bullets don't have the tail - it's just the <team>_shot.png graphic |
| 15:12.51 | blast007 | any of them |
| 15:12.54 | blast007 | I was on experimental |
| 15:12.54 | JeffM | hmmm |
| 15:12.59 | JeffM | it was working when I tested it |
| 15:13.04 | blast007 | in 2.0.16, I was thinking the tails worked in any quality setting |
| 15:13.05 | JeffM | I will look at it |
| 15:13.22 | JeffM | yes in 2.0.x but I tied it into exp for trunk |
| 15:13.27 | JeffM | I think |
| 15:13.44 | blast007 | maybe one too high and it's now under super-experimental? :) |
| 15:14.43 | blast007 | gonna see if I can get an automated build set up here so I can keep my servers updated while I'm gone |
| 15:17.29 | blast007 | when --PREFIX is used, shouldn't bzfs look in that lib directory instead of the system one? |
| 15:17.36 | blast007 | currently it's finding a 2.0.x one |
| 15:17.46 | blast007 | it's looking in these spots, in order: |
| 15:17.49 | blast007 | logDetail, logDetail.so, $HOME/.bzf/2.0/logDetail.so, /usr/local/lib/bzflag/logDetail.so |
| 15:17.59 | JeffM | blast007, you have texturing on or off? |
| 15:18.03 | blast007 | JeffM: it was on |
| 15:18.17 | JeffM | then yeah it should draw tails in any quality |
| 15:19.54 | JeffM | do you have the shot trail image in your data dir? |
| 15:19.56 | blast007 | BulletCatcher: any suggestions about --PREFIX and plugin loading? |
| 15:20.18 | blast007 | JeffM: yeah, I see shot_tail.png |
| 15:20.35 | JeffM | can you send me your config file please? |
| 15:23.11 | BulletCatcher | The obvious one is that it should look in ~/.bzf/2.4 instead of 2.0, blast007. Would that be enough? |
| 15:23.58 | blast007 | BulletCatcher: no. I'm installing to $HOME/bzflag-bin/ , so it should be searching in /home/bzflagdev/bzflag-bin/lib/bzflag/ instead of /usr/local/lib/bzflag/ |
| 15:24.19 | blast007 | since the prefix should alter the libdir (which it installs to properly, at least) |
| 15:25.01 | blast007 | and I thought bzfs was told where the lib dir was during the ./configure |
| 15:25.15 | BulletCatcher | A few days ago delusional reported: I'm getting "cannot load texture shot_tail" on every bullet. I think he is on a Mac. |
| 15:25.16 | *** join/#bzflag Upsetter (~er@i59F6B4D9.versanet.de) |
| 15:26.28 | blast007 | yeah, for that I was wondering if the .app didn't contain the file |
| 15:26.41 | blast007 | not sure how XCode knows what files to include |
| 15:28.22 | BulletCatcher | Me neither. BZFlag.xcodeproj/project.pbxproj does not contain the string "png". |
| 15:29.41 | blast007 | could also be a config file that points to a different data directory |
| 15:32.22 | BulletCatcher | delusional: When you have the shot_tail problem, do you see the old 2.0 mountains or the new 2.3 foothills on the horizon? |
| 15:32.52 | BulletCatcher | That should help answer the question about wrong data directory. |
| 15:33.26 | *** join/#bzflag bryjen (~bryjen@76.92.85.169) |
| 15:33.26 | *** mode/#bzflag [+v bryjen] by ChanServ |
| 15:34.04 | blast007 | probably not the issue, since 2.0.x (at least 2.0.16+) had the shot tail too |
| 15:36.43 | blast007 | BulletCatcher: hmm, somehow it's actually loading logDetail properly |
| 15:37.00 | blast007 | I was just looking at the strace output to get the informationa above |
| 15:37.55 | blast007 | is there some magic that linux bins can do that make it appear to be opening a system lib but actually redirect it to the prefix'ed path? |
| 15:37.59 | blast007 | open("/usr/local/lib/bzflag/logDetail.so", O_RDONLY) = 3 |
| 15:38.29 | JeffM | blast007, I see tails with your config ( on windows ) |
| 15:38.32 | BulletCatcher | trepan: Can you look at why the backport of r19681 done in r21681 causes the self-linked teleporter problem described in BUGS, or should I just revert? |
| 15:38.48 | JeffM | what card/driver are you using? |
| 15:39.03 | blast007 | JeffM: let me try again to make sure I'm not crazy |
| 15:39.16 | BulletCatcher | We know you're crazy. :-) |
| 15:39.18 | JeffM | now they do look different then V3 |
| 15:39.25 | JeffM | they are the same color as the shot and smaller |
| 15:39.54 | blast007 | yeah, I see them now too .... |
| 15:40.11 | blast007 | swear I was getting the old style yesterday :/ |
| 15:40.58 | JeffM | it could do that if it could not find the tail texture and I know at ont point there was an issue with installing that texture |
| 15:42.02 | blast007 | I was using the installed package |
| 15:42.07 | blast007 | can't get it to do it again though |
| 15:42.17 | blast007 | so.. one "bug" squashed ;) |
| 15:42.56 | blast007 | JeffM: maybe that's what I was seeing - I'm used to the 2.0.16 ones |
| 15:43.19 | JeffM | yeah there were complaints that the orange fire in the tail changed the color of blue shots to look purple |
| 15:43.27 | JeffM | so I went and made it more monochromatic |
| 15:44.21 | JeffM | if you want it the old way replace the shot tail image with the missile.png |
| 15:44.42 | blast007 | nah, that's fine ;) I like the new way |
| 15:44.48 | blast007 | just threw me off |
| 15:44.50 | JeffM | k |
| 15:45.05 | JeffM | the old ones tended to dominate the first person view too |
| 15:45.17 | JeffM | I'm wondering if geolaser is too big too |
| 15:45.51 | blast007 | BulletCatcher: oh blah, ignore me. I think I need more sleep. I was running 'bzfs' not '$HOME/bzflag-bin/bin/bzfs' ... so I'm loading 2.0.x ;) |
| 15:46.27 | BulletCatcher | Yay, problem solved. :-) |
| 15:46.41 | blast007 | two bugs squashed already! I'm on a roll!! |
| 15:47.59 | BulletCatcher | Give him space, everyone, blast007 has the steamroller flag! |
| 15:48.50 | blast007 | ~bzfrag BulletCatcher |
| 15:48.51 | ibot | ACTION destroys BulletCatcher with a guided missile |
| 15:49.08 | blast007 | ibot is such a camper |
| 15:50.17 | *** join/#bzflag temporalD (~a_temp_di@bzflag/serverop/TemporalDistraction) |
| 15:59.13 | JeffM | I see the proiblem with the screenshot numbers |
| 15:59.14 | JeffM | am fixing |
| 15:59.30 | DTRemenak | too late |
| 15:59.33 | CIA-5 | BZFlag: 03dtremenak * r21982 10/trunk/bzflag/ (BUGS src/bzflag/clientCommands.cxx): |
| 15:59.33 | CIA-5 | BZFlag: Don't skip the first file when looking for screenshots on windows. |
| 15:59.33 | CIA-5 | BZFlag: Tell the video driver to pack to 1-byte boundaries before calling glReadPixels (in case your w*h is not divisible by 4). |
| 15:59.35 | blast007 | lol |
| 15:59.37 | brad | lol |
| 16:01.41 | JeffM | DTRemenak, you bastard |
| 16:01.47 | DTRemenak | if svn was a bit quicker that would have been committed before you said that ;) |
| 16:01.57 | JeffM | taking... it's the new thing |
| 16:02.01 | JeffM | talking even |
| 16:02.08 | JeffM | you going to fix the file lock too? |
| 16:02.14 | DTRemenak | nope |
| 16:02.52 | JeffM | I see that the write function uses a file* but we also open a std::ostream* for it |
| 16:02.59 | JeffM | and I don't think we ever close it |
| 16:03.06 | DTRemenak | mostly wanted the glReadPixels fix, just saw the FindFile problem on the way |
| 16:03.50 | JeffM | in fact we never delete that stream |
| 16:03.55 | DTRemenak | why do we open it? |
| 16:04.00 | JeffM | not sure |
| 16:04.07 | JeffM | I think just to check if the file can be created |
| 16:04.13 | JeffM | it's only used in a null check |
| 16:04.44 | DTRemenak | ah, it's probably for the recursive directory creation in FILEMGR |
| 16:04.56 | DTRemenak | should be safe to close immediately |
| 16:04.59 | JeffM | k |
| 16:05.27 | JeffM | yeah that fixes it |
| 16:06.48 | BulletCatcher | grrr. On Linux I (still) get no screenshot file in windowed mode. It works fine fullscreen. |
| 16:07.08 | DTRemenak | BulletCatcher: turn off desktop composition |
| 16:07.37 | DTRemenak | it interferes with glReadPixels with some drivers iirc |
| 16:07.51 | CIA-5 | BZFlag: 03JeffM2501 * r21983 10/trunk/bzflag/ (BUGS src/bzflag/clientCommands.cxx): close the file stream we use to create the screenshot file and dir. |
| 16:08.01 | BulletCatcher | Yep. F5 is eaten by my window manager. Never mind. Thanks, DTRemenak. |
| 16:10.14 | DTRemenak | and fwiw, the alignment problems with odd pixel counts is NOT a new bug...we've never explicitly set byte alignment. |
| 16:14.13 | JeffM | so yorig's reports of shot bugs are not bugs, but similar things to what blast saw, just changes in expecations |
| 16:15.39 | BulletCatcher | Yay. |
| 16:16.03 | JeffM | end-on the laser is now round so it looks different |
| 16:16.10 | JeffM | better then a textured cross IMHO |
| 16:16.19 | BulletCatcher | The new tank markers seem to have many problems. Should we try to fix them or revert? |
| 16:16.30 | JeffM | depends on what the problems are |
| 16:16.40 | JeffM | we should at least eval bugs before we just pull things |
| 16:16.51 | BulletCatcher | See the BUGS file. |
| 16:16.52 | JeffM | otherwise you are going to end up with 2.4 being 2.0 :) |
| 16:17.26 | JeffM | hmm interesting |
| 16:17.36 | JeffM | the code does check for stuff behind a building |
| 16:17.39 | JeffM | it uses obstacle manager |
| 16:17.50 | JeffM | I don't mind adding an option to turn them off |
| 16:18.02 | JeffM | tho they are also tied to experimental IIRC |
| 16:18.13 | JeffM | those that don't like new things can go to high |
| 16:18.18 | JeffM | it's the old expiermental |
| 16:18.58 | JeffM | the question is does right click to identify in 2.0.x show people behind objets too? |
| 16:19.03 | JeffM | cus it uses that same code |
| 16:19.18 | BulletCatcher | I have my quality set to high, and I think I see them anyway. |
| 16:19.27 | blast007 | JeffM: yes, that does show people behind objects |
| 16:19.45 | JeffM | ok then the markers are just like holding that down |
| 16:19.52 | blast007 | (as does the hunt feature) |
| 16:20.01 | JeffM | so I don't see the problem then |
| 16:20.08 | joevano | sourceforge bzflag |
| 16:20.13 | JeffM | just a different display on the same info |
| 16:20.22 | JeffM | I'll add options to turn em off tho |
| 16:20.26 | JeffM | that I can understand |
| 16:20.53 | blast007 | only problem I see with it showing people behind objects is that it gives an exact location they are behind an object |
| 16:21.04 | blast007 | does jamming turn off markers? |
| 16:21.17 | JeffM | does jamming turn of ID? |
| 16:21.35 | JeffM | tell you what I'll remove the ID marker, but leave lockon and flag |
| 16:21.46 | JeffM | seems like we need to think about the gameplay implications |
| 16:22.07 | blast007 | ok |
| 16:22.56 | BulletCatcher | I definitely get markers with high quality. |
| 16:23.04 | JeffM | k |
| 16:23.11 | JeffM | I'll tie em to exp |
| 16:23.18 | JeffM | and remove the ID marker |
| 16:23.51 | JeffM | the server can turn off makers too |
| 16:23.56 | JeffM | _forbidMarkers |
| 16:27.39 | CIA-5 | BZFlag: 03JeffM2501 * r21984 10/trunk/bzflag/ (BUGS src/bzflag/HUDRenderer.cxx): |
| 16:27.39 | CIA-5 | BZFlag: disable look at makers. |
| 16:27.39 | CIA-5 | BZFlag: tie markers to experimental. |
| 16:27.39 | CIA-5 | BZFlag: shot length bugs are not bugs, the shot tail is now the same color as the shot to prevent blending from skewing the color to the orange side. |
| 16:28.00 | JeffM | that should help a bit |
| 16:28.25 | BulletCatcher | Reverting r21681 fixes the self-linked teleporter problem, but I'll give trepan a chance to look at it before committing. |
| 16:28.57 | JeffM | what did the change do? |
| 16:30.42 | BulletCatcher | I honestly don't know. r21681 is a backport of r19681, which has a commit message that is too concise. |
| 16:31.06 | JeffM | hmm we should not be backporting things that we don't understand |
| 16:31.09 | JeffM | who backported it? |
| 16:31.14 | BulletCatcher | bryjen did |
| 16:33.45 | bryjen | it fixed a problem with scaling the shot position for dissimilar sized teleporters that often meant the shot re-entered the "exiting" link and teleported twice |
| 16:34.33 | CIA-5 | BZFlag: 03dtremenak * r21985 10/trunk/bzflag/ (. src/bzflag/motd.cxx): backport regex new version notification parser from 2.99. trust me, we want it. revisions 16232, 16233, 16235, 16236, 16395. |
| 16:36.48 | BulletCatcher | bryjen, do we know if that bug occurs in 2.0? |
| 16:37.09 | bryjen | yes, it does |
| 16:42.48 | BulletCatcher | This situation exemplifies why the DEVINFO file recommends small, focused commits. |
| 16:42.50 | BulletCatcher | r19681 combines a lot of fvec changes (which are not expected to change functionality) with a functional change and it is hard to see what is what. |
| 16:43.15 | bryjen | it's noticeable as shooting into a 'porter before driving thru, and once on the other side, you see your shots didn't go where you did |
| 16:46.29 | bryjen | can be really annoying when hiding behind a 'porter that should block shots, but the bug makes it a pass-thru ;) |
| 16:52.55 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 16:52.55 | *** mode/#bzflag [+v spldart] by ChanServ |
| 16:57.00 | *** join/#bzflag Gabe_G23 (u557@gateway/web/irccloud.com/x-nyqyrwmsxnyzydiy) |
| 16:57.08 | blast007 | JeffM: this could be used for beta.bzflag.org until I get around to writing a nice PHP-based interface for it: http://httpd.apache.org/docs/2.0/mod/mod_autoindex.html#headername |
| 16:58.01 | blast007 | (and then just have it show the directory index) |
| 17:06.52 | blast007 | here's a script I wrote to automatically update a repo and rebuild the code (but only if changes have been put in) http://static.bzexcess.com/bzflagdev/update.txt |
| 17:07.31 | blast007 | it assumes that bzfs instances are run from a loop with a sleep between loops (say, 10 or 15 seconds) |
| 17:08.31 | blast007 | it will kill any bzfs instances in the current account when it finishes building, so it's intended to be used in an dedicated user account |
| 17:08.57 | blast007 | in a* |
| 17:11.31 | blast007 | added notes about that to the top of the file |
| 17:15.37 | blast007 | I should probably put some lock file in place so it doesn't run an update while it's building |
| 17:23.34 | *** join/#bzflag Erroneous (~DTRemenak@69.36.85.130) |
| 17:38.07 | blast007 | (there, now it has a lock file :) |
| 17:42.23 | delusional | BulletCatcher: I fixed my problem with shot tails by using -directory... I still don't understand why only one texture was missing, i thought that was an all or nothing option. |
| 17:42.42 | delusional | and my mountains appear correct, right now. |
| 17:47.54 | delusional | i'm pretty sure the mountains were correct before I set directory, i remember looking at them and thinking they were normal |
| 17:48.14 | delusional | at one point in the past, i had a mix of old and new mountains. |
| 17:49.20 | bryjen | fixing the shots-thru-reversing-teleporter is a behavior change that needs a protocol number bump, no? |
| 17:52.38 | BulletCatcher | Yes, but commit the change without the protocol bump for now. |
| 17:52.40 | BulletCatcher | We'll bump protocol before releasing the next beta. |
| 17:52.40 | blast007 | delusional: check your configuration file for 2.4 and remove any 'set directory' line |
| 17:53.18 | delusional | and then? |
| 17:53.21 | TD-Linux | BulletCatcher: what kind of window manager are you using that eats F5? |
| 17:53.29 | BulletCatcher | Motif |
| 17:53.39 | blast007 | delusional: and if you do, remove it and try the .app again |
| 17:53.45 | TD-Linux | I didn't know people still used that |
| 17:53.51 | blast007 | just remove that line, I mean |
| 17:53.55 | BulletCatcher | Just me, apparently. :-) |
| 17:54.02 | delusional | ok blast will do, after compile completes |
| 17:54.06 | blast007 | ok |
| 17:54.33 | blast007 | oh, and have you ever done a 'make install' on your mac for BZFlag? cuz I imagine that could screw stuff up |
| 17:55.02 | delusional | i will try... make install worked recently |
| 17:55.15 | blast007 | well, my point is, DON'T do a make install on OSX ;) |
| 17:55.24 | delusional | heh |
| 17:55.26 | blast007 | it will screw up your .app versions of BZFlag |
| 17:55.44 | blast007 | cuz it probably finds the 'make install'ed copy of the data files before it looks in the .app |
| 17:56.04 | blast007 | BulletCatcher: do you know if it searches the .app before system paths? |
| 17:56.25 | BulletCatcher | I don't. |
| 17:59.02 | BulletCatcher | TD-Linux: If I cared enough to do it, I could bind a different key to the function currently assigned to F5 in mwm and that would leave F5 free for applications like bzflag. |
| 17:59.20 | delusional | blast, with "set directory" removed, I get no shot tail texture, and mountains appear to be reversed "or whatever they are" |
| 17:59.24 | delusional | what next? |
| 18:00.50 | blast007 | do you have anything in /usr/local/share/bzflag ? |
| 18:03.02 | CIA-5 | BZFlag: 03bryjen * r21986 10/trunk/bzflag/src/obstacle/Teleporter.cxx: make shots through reversing telporters swap relative L-R position |
| 18:05.11 | delusional | blast, yes, it appears I have every texture except shot_tail |
| 18:06.10 | blast007 | yeah, that directory shouldn't exist on a mac ;) |
| 18:06.19 | blast007 | it's from the make install you did in the past |
| 18:06.26 | blast007 | so delete that directory and it should work |
| 18:06.37 | blast007 | (or rename if if you want to be careful) |
| 18:11.07 | BulletCatcher | bryjen has fixed the last of the "must fix" bugs listed in the BUGS file. |
| 18:11.08 | BulletCatcher | Are there any others we want to tackle before releasing today's beta? |
| 18:12.41 | BulletCatcher | Does anyone object to having the client suppress received flag identifications when ID is not carried? |
| 18:13.31 | delusional | yeah blast, after doing that, and now using -direvtory again.. all appears normal |
| 18:15.57 | delusional | what's for dinner? |
| 18:16.32 | delusional | err... it was fun to delete those tectures while the app was running. |
| 18:24.01 | blast007 | delusional: no, don't use -directory at all |
| 18:24.18 | blast007 | you're running from a .app, right? |
| 18:24.29 | blast007 | if so, it should already know to look inside the .app for the textures |
| 18:26.47 | delusional | i have to make install for an app |
| 18:26.54 | delusional | you got me confused |
| 18:28.00 | delusional | oh wait, i did that myself |
| 18:32.17 | blast007 | make install is the linux way |
| 18:32.26 | blast007 | on OSX you use XCode and it makes you a .app |
| 18:36.23 | delusional | make install will put executables in usr/local/bin.. bzadmin,bzflag,bzrobots.. etx |
| 18:36.36 | delusional | no .app though |
| 18:38.03 | delusional | the executable knows to look for the data in /usr/local/share/bzfag.. even without -directory |
| 18:38.14 | blast007 | you don't make install on OSX |
| 18:38.18 | blast007 | build with xcode |
| 18:38.20 | blast007 | it makes a .app |
| 18:39.01 | delusional | you want me to do that? |
| 18:39.13 | delusional | i wish you woulda told me that awhile ago |
| 18:40.37 | blast007 | I did ;) |
| 18:41.18 | blast007 | has likely mentioned it in the past as well |
| 18:41.36 | blast007 | though iirc brlcad has always countered that it didn't matter - well, it does :) |
| 18:46.44 | JBdiGriz | You could always use xcodebuild, if you really want to stick with the command line on a mac. |
| 18:47.27 | delusional | xcodebuild, and using XCode to build, are two different things |
| 18:47.39 | delusional | I'm using Xcode to build |
| 18:49.13 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 18:49.25 | brlcad | blast007: that what didn't matter? |
| 18:51.01 | brlcad | there used to be code that let bzflag know if it was running from .app or not, so it knew how to find the resources correctly -- unless you set the datadir at some point and it was written into your config |
| 18:52.56 | delusional | It's always SDL for me,,, here's the xcodebuild errrors... http://paste2.org/p/1483960 |
| 18:53.09 | delusional | i suppose I should upgrade SDL again. |
| 18:54.44 | blast007 | brlcad: doesn't seem like it's working, unless I'm confused as to how delusional is running it |
| 18:57.08 | delusional | at this point it seems I may have introduced other errors into the system, by compiling, this way.. that way... the other SDL.... who knows? I'm gonna trash the whole thing and start with a fresh download of source... see what happens |
| 18:57.47 | brlcad | ideally, you would know since you did it :) |
| 18:58.02 | blast007 | perhaps I should pick up an older intel mac mini at some point so I can test mac build stoo ;) |
| 18:58.07 | blast007 | builds too* |
| 18:58.19 | brlcad | delusional: be sure to delete your config file too |
| 18:58.40 | brlcad | having a datadir set in the config will screw with the searching logic -- once it's set, it will try to use that value |
| 18:58.55 | blast007 | and build it with xcode, and run bzflag from the resulting .app too |
| 18:59.19 | brlcad | so you can't really toggle back and forth from .app and command-line runs without the config setting getting in the way |
| 18:59.43 | delusional | ok, commands will be... autogen.... configure... xcodebuild what am I missing? I have SDL 1.2.10 |
| 19:00.04 | delusional | is that good? |
| 19:00.23 | delusional | vd bzflag |
| 19:01.22 | brlcad | bzflag is a vd? the n-disease is fair, but saying it's venereal is just unfair |
| 19:01.36 | delusional | cd cd cd |
| 19:01.47 | delusional | and put it in the write window |
| 19:01.51 | blast007 | hehee |
| 19:02.18 | brlcad | that's what he said! *ba-dum ching!* |
| 19:02.33 | brlcad | two writes make a read |
| 19:03.15 | JBdiGriz | three rights make a left |
| 19:03.48 | JeffM | so who's going to build us a mac .app? |
| 19:05.01 | brlcad | I hear delusional is working on it |
| 19:05.22 | JeffM | coleo |
| 19:05.25 | delusional | building now |
| 19:05.34 | blast007 | are we going to care about PPC for 2.4.0? |
| 19:05.38 | JeffM | don't bother making a DMG, just zip it |
| 19:05.40 | JeffM | oh god no |
| 19:05.56 | JeffM | make it intel only during beta and lets see who complains |
| 19:06.03 | JeffM | what is the last PPC OSX anyway? |
| 19:06.05 | JBdiGriz | My last ppc machine was retired a year ago. |
| 19:06.12 | blast007 | 10.5 I think? |
| 19:06.40 | JeffM | and what is current? |
| 19:06.40 | delusional | try temp_dist |
| 19:07.14 | JBdiGriz | Current is 10.6(SnowLeopard) with 10.7(Lion) due in July |
| 19:07.26 | delusional | 10.5 is last to use ppc.... and 10,6 killed rosetta too |
| 19:07.28 | bryjen | poor ppc cpus. stuck running AIX and OS400. all work and no play. |
| 19:07.42 | JBdiGriz | Linux works on the ppc as well. |
| 19:07.43 | JeffM | yeah do intel for now |
| 19:07.45 | blast007 | JBdiGriz: we mean PPC |
| 19:08.06 | blast007 | oh nvm |
| 19:08.08 | JBdiGriz | jeff was asking about current |
| 19:08.09 | blast007 | missed jeff's comment |
| 19:08.34 | JeffM | Target 10.5 if you have to |
| 19:08.39 | bryjen | JBdiGriz: well yeah ;) |
| 19:08.42 | JeffM | and then if we need to we can do a universal |
| 19:08.53 | JeffM | I don't think we need to worry about 10.4 or before |
| 19:09.44 | delusional | <built-in>:0: warning: Mac OS X version 10.5 or later is needed for use of the new objc abi |
| 19:09.45 | JBdiGriz | Rosetta is supposedly still supported, although scheduled to be dropped. |
| 19:10.14 | *** join/#bzflag kierra (~jolie@unaffiliated/kierra) |
| 19:10.15 | JeffM | delusional, what OS are you on? |
| 19:10.26 | delusional | latest 10.6.7 |
| 19:10.33 | JBdiGriz | and which XCode are you using? |
| 19:10.49 | JeffM | ok, and it's just warning you that the app will need 10.5 right? |
| 19:10.52 | JeffM | or later |
| 19:10.57 | delusional | yes |
| 19:10.59 | bryjen | smirks at the thought of a bzfs in a linux lpar on as400 hardware |
| 19:10.59 | JeffM | k |
| 19:13.32 | delusional | failed http://paste2.org/p/1483981 |
| 19:14.37 | McSpider | delusional, check if libcurl, libcrypto & the SDL framework are properly linked in the xcode project |
| 19:15.06 | delusional | uuuuuuummmmmmmmmmmmmmmmmmmmmmmm |
| 19:15.44 | delusional | McSpider, perhaps you are unaware that I am relatively stupid. |
| 19:16.06 | PlasticTank | I had that error before...I'm trying to remember how I fixed it |
| 19:16.59 | McSpider | red files are missing or not found: http://cl.ly/2k1m0X0x1q0e2F3q0U0I |
| 19:17.12 | McSpider | youll have to read them |
| 19:17.18 | McSpider | readd* |
| 19:17.33 | PlasticTank | eww Xcode 4 |
| 19:17.39 | delusional | It's always SDL for me |
| 19:18.20 | McSpider | when you open the xcodeproject are there any red files? |
| 19:19.11 | delusional | Yep, SDL framework, too |
| 19:19.26 | delusional | I probably have it installed in the wrong place for xcode |
| 19:19.34 | McSpider | maybe |
| 19:19.39 | delusional | seems fine if I make without xcode |
| 19:20.06 | delusional | proposed solution? |
| 19:20.21 | McSpider | you can rightclick and choose add existing files/smoething.. and readd them |
| 19:20.43 | McSpider | you using Xcode 3? |
| 19:20.58 | delusional | right now I dont want to do anything without secific instructions, for fear of making the problems worse |
| 19:21.03 | delusional | xcode 4 |
| 19:21.07 | McSpider | ok |
| 19:21.17 | delusional | errr. |
| 19:21.21 | delusional | 3.2.6 |
| 19:21.29 | delusional | 64 bit |
| 19:22.03 | McSpider | yeah :/ I'm using Xcode 4 and its alot different. |
| 19:22.32 | PlasticTank | I upgraded my libraries with macports and I think it fixed that |
| 19:22.45 | delusional | I can upgrade, xcode |
| 19:23.24 | McSpider | if you want, Xcode 4 is abit confusing though |
| 19:23.33 | McSpider | and it cant build for PPC |
| 19:23.43 | delusional | lets fix my sdl |
| 19:24.15 | delusional | it's in /Library/Frameworks/SDL.framework |
| 19:24.21 | delusional | that is correct? |
| 19:24.24 | McSpider | yes |
| 19:25.44 | McSpider | I could send you my xcodeproject wich I fixed (it works for me) and you could try that... |
| 19:26.23 | JeffM | so has the self linked porter bug been fixed? |
| 19:26.33 | blast007 | McSpider: if there's a problem with our xcode project, please submit a patch |
| 19:26.49 | bryjen | JeffM: i think so |
| 19:27.05 | JeffM | should I remove it from the bugs list? |
| 19:27.27 | CIA-5 | BZFlag: 03bullet_catcher * r21987 10/trunk/bzflag/src/bzflag/playing.cxx: Display info about nearby flags only while carrying the ID flag. |
| 19:27.32 | McSpider | blast007, dont really know if there is, it just dosn't work for me till I fix some linking |
| 19:27.53 | JeffM | BulletCatcher, and should I remove that? :) |
| 19:28.07 | BulletCatcher | If everyone is happy with that solution, then yes. |
| 19:28.20 | JeffM | all you did was ignore the message right? |
| 19:28.23 | BulletCatcher | right |
| 19:28.36 | JeffM | that's the best we can do |
| 19:28.40 | BulletCatcher | I agree. |
| 19:29.03 | JeffM | welll untill flag drop gets moved server side :) |
| 19:29.13 | CIA-5 | BZFlag: 03JeffM2501 * r21988 10/trunk/bzflag/BUGS: remove fixed bugs |
| 19:29.40 | JeffM | are we sure the zoomed radar bug is new? |
| 19:29.50 | JeffM | does it have to do with the treads change I made? |
| 19:30.03 | BulletCatcher | Yes. There is no tank image at all in 2.0. |
| 19:30.20 | JeffM | so 2.3 is better :) |
| 19:30.30 | bryjen | was there a decision about the HUD markers being visible for tanks behind obstacles? |
| 19:30.30 | BulletCatcher | It is prettier, sort of. |
| 19:30.38 | JeffM | bryjen, yes |
| 19:30.47 | JeffM | I removed the ID marker |
| 19:30.53 | JeffM | we'll just do flag and lockon markers |
| 19:31.06 | JeffM | and they can be turned off by going to "high" quality |
| 19:31.24 | JeffM | we have to examine what the ID marker means to gameplay, as well as how the normal right click to ID works |
| 19:31.34 | JeffM | so that's 2.6 |
| 19:32.51 | JeffM | BulletCatcher, does the tank render properly when not fully zoomed? |
| 19:33.15 | delusional | I seem to have fixed SDL with a re-install. |
| 19:33.25 | BulletCatcher | The texture is missing as soon as it changes from a white square to the tank. |
| 19:33.31 | JeffM | ahh ok |
| 19:33.46 | JeffM | so it's the drawing of the tank model, should be pretty easy to find then |
| 19:34.07 | delusional | now I need licrypto and libcurl |
| 19:34.21 | JeffM | why do you need crypto? |
| 19:34.24 | bryjen | heh. you can indeed right-click ID thru objects. that doesn't give you a nice visual indicator where to fire superbullets tho ;) |
| 19:34.29 | delusional | thats what it tells me |
| 19:34.35 | JeffM | bryjen, yeah |
| 19:34.44 | JeffM | we'll evaluate if thats what we want to happen later |
| 19:35.02 | BulletCatcher | delusional: try using --enable-curl-build |
| 19:35.03 | JeffM | delusional, are you using a libcurl that needs SSL? |
| 19:35.46 | JeffM | bryjen, ID may not do that but the radar does. All the info that the marker showed was on the hud already just shown in a different way |
| 19:36.00 | delusional | xcodebuild --enable-curl-build is unknown option |
| 19:36.18 | BulletCatcher | You'll have to make it pass that to configure. |
| 19:36.31 | delusional | ah right, shoulda known |
| 19:36.47 | bryjen | iirc, libcurl may require libcrypto |
| 19:37.16 | JeffM | I don't have any kind of crypto on windows when I build my own libcurl |
| 19:37.23 | JeffM | but then we build with out SSL |
| 19:37.30 | bryjen | JeffM: bingo |
| 19:37.33 | JeffM | for SSL I could understand that but we don't need SSL |
| 19:38.26 | JeffM | BulletCatcher, do you have animated treads on or off? |
| 19:39.11 | BulletCatcher | animated treads are on for me |
| 19:39.29 | JeffM | turn them off and see if that radar image changes |
| 19:39.36 | JeffM | if you can |
| 19:40.36 | JeffM | is at work and can't really bring up a game :) |
| 19:41.05 | BulletCatcher | Turning off animated treads fixes it. |
| 19:41.13 | JeffM | ok that's what I feared |
| 19:41.21 | JeffM | ok I can make a quick fix then |
| 19:41.30 | delusional | --enable-curl just might work |
| 19:41.37 | BulletCatcher | I see no need for animated treads on the radar tank. |
| 19:41.49 | JeffM | yeah |
| 19:42.30 | *** join/#bzflag spldart (~spldart2@c-98-201-137-215.hsd1.tx.comcast.net) |
| 19:42.30 | *** join/#bzflag spldart (~spldart2@bzflag/contributor/spldart) |
| 19:42.30 | *** mode/#bzflag [+v spldart] by ChanServ |
| 19:42.52 | CIA-5 | BZFlag: 03JeffM2501 * r21989 10/trunk/bzflag/src/geometry/TankSceneNode.cxx: don't use the tread material in radar mode. |
| 19:43.04 | JeffM | give that a whirl with treads on |
| 19:43.13 | JeffM | if that dosn't fix it I can do another thing it will just be deeper |
| 19:44.43 | BulletCatcher | The tank now has its texture, but the fenders are completely missing unless I turn off animated treads. |
| 19:45.30 | delusional | No build... If I could try to NOT build for 10.4... i'm pretty sure I'd have it. |
| 19:47.13 | JeffM | BulletCatcher, ok that was my fear |
| 19:47.15 | JeffM | fixes |
| 19:47.24 | BulletCatcher | What I'd *really* like to see at the center of the radar is an accurate representation of the hit zone. |
| 19:47.53 | BulletCatcher | delusional: Don't worry about 10.4 for this beta build. |
| 19:48.01 | delusional | how? |
| 19:48.20 | delusional | If i had the 10.4 SDK.. that would work too |
| 19:48.29 | BulletCatcher | I was under the impression that you knew how to do that. :-) |
| 19:49.16 | delusional | read what I said to mcspider, above |
| 19:49.27 | CIA-5 | BZFlag: 03JeffM2501 * r21990 10/trunk/bzflag/src/geometry/TankSceneNode.cxx: screw it, draw all tank parts in radar. |
| 19:49.36 | JeffM | that should be better |
| 19:51.00 | BulletCatcher | Still no fenders without animated treads. |
| 19:51.07 | JeffM | WTF! |
| 19:51.12 | Pimpinella | somebody already fixed the "brackets stay on after auto pilot" bug? |
| 19:51.29 | BulletCatcher | I dont' think so, Pimpinella. |
| 19:51.33 | JeffM | left and right casing are the first things drawn |
| 19:51.37 | Pimpinella | it's not in BUGS anymore |
| 19:52.07 | BulletCatcher | I see it as the 4th item. |
| 19:52.32 | BulletCatcher | (or close enough, anyway) |
| 19:52.37 | JeffM | ahh ok, I get it |
| 19:52.55 | JeffM | or maybe I don't |
| 19:53.21 | Pimpinella | BulletCatcher: yep, i see it too now, tnx :) |
| 19:53.44 | JeffM | how do you zoom the radar? |
| 19:53.47 | JeffM | risks it |
| 19:54.34 | BulletCatcher | hold down the 4 key, I think |
| 19:54.46 | PlasticTank | Oh Jeffm, when you turn 180 degrees to your team flag, the team flag marker goes into the top corner |
| 19:54.51 | PlasticTank | Is it supposed to do that? |
| 19:54.53 | BulletCatcher | That may be my own keybinding. |
| 19:55.29 | JeffM | PlasticTank, yeah one of the corners just means "behind you" |
| 19:55.40 | JeffM | we can probalby do better then that tho |
| 19:56.18 | PlasticTank | oh ok, it seemed a bit strange to me |
| 19:56.21 | blast007 | mechwarrior changes the square targeting reticle to an arrow at the edge of the screen when the target it out of view |
| 19:56.53 | JeffM | yeah we can work on that later |
| 19:57.00 | blast007 | yep |
| 19:57.04 | CIA-5 | BZFlag: 03pimpinella * r21991 10/trunk/bzflag/ (BUGS src/bzflag/LocalPlayer.cxx): fix "After turning roger off, the new brackets remain around the targeted player. Maybe just disable markers when in autopilot." bug |
| 19:57.05 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 19:58.06 | JeffM | I don't understand it is calling the code to draw the tread covers |
| 19:58.15 | randomparticle | decide where code should go - overall architecture - is hard |
| 19:58.24 | *** join/#bzflag Anxuiz (~Anxuiz@50-46-121-138.evrt.wa.frontiernet.net) |
| 19:58.24 | *** join/#bzflag Anxuiz (~Anxuiz@unaffiliated/anxuiz) |
| 19:58.25 | *** join/#bzflag Anxuiz_ (~Anxuiz@50-46-121-138.evrt.wa.frontiernet.net) |
| 19:58.36 | randomparticle | *deciding |
| 19:59.32 | blast007 | that fix could always wait until 2.4.2 |
| 19:59.38 | blast007 | I don't think most people zoom their radar in like that |
| 20:00.05 | JeffM | probably |
| 20:00.09 | JeffM | it just pisses me off :) |
| 20:00.21 | JeffM | I put code in there to make it work for radar |
| 20:00.28 | JeffM | and it's calling the right stuff but not drawing it |
| 20:00.44 | randomparticle | anyway, i've been restructuring my bzadminios code, so hopefully i move beyond this later today: |
| 20:00.46 | randomparticle | http://www.pixentral.com/show.php?picture=1tDpfe6LrcqJlACfJF0gBpNYnLTBw |
| 20:01.26 | JeffM | too bad we'll replace that with a web page in 2.4.4 :) |
| 20:02.07 | *** join/#bzflag Gabe_G23 (u557@bzflag/player/GabrielG) |
| 20:02.46 | randomparticle | that's ok. it's more of a learning app for me than anything else |
| 20:03.07 | randomparticle | one thing i've learnt - to my astonishment - is that the standard text views cannot have text of different styles |
| 20:03.32 | randomparticle | i.e., you can't italicize a single word, or show it in bold or a different colour |
| 20:04.14 | randomparticle | so i'm going to be forced to use UIWebViews which are, as the name suggests, views for displaying HTML documents |
| 20:04.33 | randomparticle | not very efficient at all, if you're adding a line at a time to your bzadmin console |
| 20:09.56 | JeffM | ahh ok I unerstand the tank issue now, we don't even build the cassing lists if we are doing full teads |
| 20:14.48 | BulletCatcher | Just a reminder: we need to bump to 2.3.16 (change 3 files) for r21986 and 21987 before releasing the next beta. |
| 20:14.53 | BulletCatcher | Delaying the bump for a few hours has smoothed the development process. |
| 20:14.55 | BulletCatcher | goes AFK for a long meeting |
| 20:14.57 | *** join/#bzflag DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 20:15.20 | *** part/#bzflag DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 20:27.28 | *** join/#bzflag Upsetter1 (~er@88.130.163.103) |
| 20:29.49 | delusional | I installed OSX 10.4 and 10.3.9 SDK's.... building |
| 20:30.18 | delusional | setenv VALID_ARCHS "i386 ppc ppc64 ppc7400 ppc970 x86_64" |
| 20:32.13 | *** part/#bzflag Upsetter1 (~er@88.130.163.103) |
| 21:02.55 | delusional | It is in this folder, try it. http://images.planet-mofo.com/A-Delusion/BZ_build/ |
| 21:03.45 | delusional | I simply commented out the offending dylibs from the xcodebuild file |
| 21:11.01 | PlasticTank | delusional: it runs mine on my itel iMac |
| 21:11.08 | PlasticTank | intel* |
| 21:16.32 | randomparticle | why are libcrypto and libcurl distributed with bz (mac version)? |
| 21:16.55 | randomparticle | they're standard libs that will exist on very recent mac |
| 21:17.11 | JeffM | always of the correct version? |
| 21:17.40 | randomparticle | you can link to particular versions |
| 21:17.47 | JeffM | only if that version exists |
| 21:17.58 | JeffM | older macs may not have the version we want as it may be newer |
| 21:18.15 | JeffM | there is a min version we need |
| 21:18.35 | randomparticle | if there's a security vulnerability in one of those libs, and the dylib is updated by apple, bz will still be using the insecure version |
| 21:18.53 | JeffM | tell apple to add a depencency system then |
| 21:19.05 | JeffM | that's what the linux packages use |
| 21:19.14 | JeffM | they know the minium version needed |
| 21:19.32 | JeffM | you are correct there could be issues, but it's the best we can to do make sure it works for as many people |
| 21:20.01 | JeffM | and I doubt any security issues in curl would effect BZ, we do very little with the results of curl |
| 21:20.26 | JeffM | non of the data returned is "executed" |
| 21:20.56 | JeffM | you are welcome to figure out a way to get to use the system one if it is newer |
| 21:21.07 | JeffM | possibly something in the .app can do that? |
| 21:25.01 | randomparticle | the version is specified in the link section of the executable |
| 21:25.11 | JeffM | then that isn't good enough |
| 21:25.33 | JeffM | what is the version included in 10.5? |
| 21:25.36 | JeffM | is that new enough for us? |
| 21:26.01 | randomparticle | yes, i think so |
| 21:26.09 | JeffM | think or know? |
| 21:26.25 | randomparticle | those versions predate SL |
| 21:26.34 | JeffM | SL? |
| 21:26.39 | randomparticle | snow leopard |
| 21:27.33 | randomparticle | 10.5 has libcur: 2, 3, 4 |
| 21:27.59 | randomparticle | and libcrypto: 0.9.7 |
| 21:28.16 | randomparticle | so they're both present |
| 21:30.52 | randomparticle | bear in mind, that you're going to be linking to several other dylibs that you don't distribute with bz |
| 21:31.09 | randomparticle | so perhaps you should distribute those too? :-) |
| 21:32.10 | *** join/#bzflag trepan_ (~trepan@204.237.8.232) |
| 21:34.13 | randomparticle | a bit of googling suggests those libraries also exist for OS X 10.4 |
| 21:35.59 | JeffM | then the question is why did delusional need to put them in, I belive he tried runnign with out them and it did not function |
| 21:36.27 | randomparticle | perhaps it is because they are there for other builds? |
| 21:36.54 | randomparticle | that is, for builds for other operating systems |
| 21:37.18 | JeffM | the makefile system has the option of using system curl or building curl |
| 21:37.35 | JeffM | I belive he tried using system curl and had issues |
| 21:38.32 | randomparticle | the xcode projects i've used recently all copy the library from the system |
| 21:38.54 | JeffM | have you tried building a bzflag.app that does not include curl? |
| 21:39.04 | JeffM | if so does it function on other machines? |
| 21:40.22 | randomparticle | here, you can see for yourself where the library comes from: |
| 21:40.23 | randomparticle | http://www.pixentral.com/show.php?picture=1WvUFGZ6SQnD7K3MoUSVJhpCzsH70 |
| 21:40.53 | randomparticle | that is the file that is copied into the bzflag app, and it's not a file built by bz's makefiles |
| 21:41.22 | JeffM | ok, but I thought the ENTIRE question to point out that we don't even need one in the .app |
| 21:41.32 | JeffM | if you take it out of the .app does it allwork fine? |
| 21:41.53 | randomparticle | i'll have a look at the link section. one second |
| 21:42.35 | JeffM | the xcode system was probably made when we had a newer curl then apple shipped in the min OS we wanted to run with |
| 21:42.38 | JeffM | that may be different now |
| 21:42.44 | JeffM | if it is then we need to not copy the lib |
| 21:42.56 | JeffM | it ain't rocket surgery ;) |
| 21:43.06 | randomparticle | i've trashed the dylibs and it still works |
| 21:43.18 | randomparticle | the app doesn't even use the files :-) |
| 21:43.23 | JeffM | then that should be pulled from the xcode build stepp |
| 21:44.13 | JeffM | I know delusional was working on the .app and was having some confusion as it is his first time doing such a thing |
| 21:44.23 | JeffM | usualy brlcad or Constitution build them |
| 21:44.52 | randomparticle | there was a problem i had |
| 21:45.07 | randomparticle | the xcode project was referencing files that no longer existed |
| 21:45.17 | JeffM | ok then that should be fixed |
| 21:45.18 | randomparticle | the files were still on my system, but in a diff place |
| 21:45.21 | JeffM | you submit a patch? |
| 21:45.54 | randomparticle | why is bzflag a script now? |
| 21:46.10 | JeffM | huh? |
| 21:46.27 | randomparticle | # bzflag - temporary wrapper script for .libs/bzflag |
| 21:46.28 | randomparticle | # Generated by ltmain.sh (GNU libtool) 2.2.4 |
| 21:46.36 | randomparticle | what's that for? |
| 21:47.05 | JeffM | looks like that's what libtool does on the mac |
| 21:47.18 | JeffM | that you'll have to ask BulletCatcher when he gets back |
| 21:47.34 | JeffM | he did the merge from the 2.99 build system |
| 21:47.38 | JeffM | brlcad may know as well |
| 21:47.52 | randomparticle | ok, i'm using otool -L to look at the link section of bzflag |
| 21:47.55 | randomparticle | and we have... |
| 21:47.57 | JeffM | but getting ahold of him here is a bit of a crapshoot |
| 21:48.02 | randomparticle | "/usr/lib/libcurl.4.dylib (compatibility version 6.0.0, current version 6.1.0)" |
| 21:48.43 | randomparticle | libcrypto isn't linked to in bzflag. i'll check bzfs |
| 21:49.03 | JeffM | it isn't |
| 21:49.15 | randomparticle | what's it used in? |
| 21:49.15 | JeffM | it is used by libcurl if it is built with ssl |
| 21:49.20 | randomparticle | ah, ok |
| 21:50.46 | JeffM | building the .app has always involved some mystic sorcery |
| 21:51.12 | randomparticle | apparently :--) |
| 21:51.30 | JeffM | most of it was to get a single bin that would work on multiple OSs |
| 21:51.37 | JeffM | appearantly that's hard |
| 21:52.18 | randomparticle | i'm guessing one could just delete the references to the dylibs in the xcode project, and no one would notice the difference |
| 21:52.24 | JeffM | probagbly |
| 21:52.25 | randomparticle | but, that is a guess |
| 21:52.33 | JeffM | make a patch and we can see |
| 22:11.58 | delusional | delete the references to the dylibs in the xcode project,.... thats exactly what I did |
| 22:12.10 | delusional | SDL i did get fixed, locally |
| 22:13.31 | delusional | first, I installed the osx 10.4 dylibs... and checked that they were in the place that BZ expects them to be... but that still didn't work, so I just modified the xcodebuild |
| 22:15.56 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 22:15.57 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 22:26.44 | randomparticle | it's a strange situation. i've just looked at the official 2.0.16 mac release |
| 22:26.58 | randomparticle | the dylibs are in there, but that aren't even used |
| 22:27.12 | randomparticle | *but they aren't even used |
| 22:28.15 | randomparticle | so basically, it's pointless them being in there |
| 22:29.21 | BulletCatcher | I saw the "temporary wrapper script for .libs/bzflag" thing on Linux at one point while backporting the build system, but it went away after awhile. |
| 22:29.23 | BulletCatcher | I don't really understand what triggers it, but it seems to have something to do with dynamic library references that are not fully resolved at link time. |
| 22:29.42 | randomparticle | btw: if you want to see what dynamic libs an executable links to, you can try this "otool -L bzflag" |
| 22:30.38 | BulletCatcher | Thanks, randomparticle. I have always wondered what the Mac OS X equivalent of "ldd" is. |
| 22:32.16 | BulletCatcher | adds an alias to his .cshrc file |
| 22:32.49 | randomparticle | i'm a bit bashful myself ;--) |
| 22:34.08 | BulletCatcher | I'm fairly sure I switched from sh to csh before bash was invented. I use tcsh now. |
| 22:34.49 | randomparticle | i started with sh circa 1987 |
| 22:35.39 | BulletCatcher | I was firmly entrenched with csh by then. |
| 22:35.41 | randomparticle | happy days. no gui nonsense then. proper, muscular, vt100s everywhere |
| 22:36.01 | BulletCatcher | yup |
| 22:36.29 | BulletCatcher | And instead of using bzflag to test the network, we used nethack to test the serial lines. :-) |
| 22:36.35 | randomparticle | hehe |
| 22:37.19 | randomparticle | i wrote this script so that would now and then, randomly, transpose two keystrokes on the terminal next to mine |
| 22:37.44 | BulletCatcher | nasty :-) |
| 22:37.58 | randomparticle | :--) |
| 22:39.54 | randomparticle | when i was doing my phd, it seemed like a good idea to make cow mooing sounds emerge from my supervisors sgi machine |
| 22:40.11 | randomparticle | it wasn't actually a good idea. he was furious! |
| 22:40.33 | randomparticle | i think he might have been having a meeting in his office at the time |
| 22:46.42 | randomparticle | i'm wondering what to do with my money if it looks like the banking system is going to collapse |
| 22:50.37 | CIA-5 | BZFlag: 03JeffM2501 * r21992 10/trunk/bzflag/BUGS: note that the zoomed radar tank rendering problem is only in one specific render mode. |
| 22:52.37 | CIA-5 | BZFlag: 03JeffM2501 * r21993 10/trunk/bzflag/BUGS: nobody cares about a card made in 1997 |
| 23:00.03 | JeffM | what OS was the -directory problem on? |
| 23:04.11 | JeffM | cus it's working fine for me |
| 23:12.58 | Thumper_ | s |
| 23:13.53 | delusional | the -directory problem was on delusionalOS.. it has been solved |
| 23:14.01 | *** part/#bzflag kierra_away (~jolie@unaffiliated/kierra) |
| 23:14.07 | JeffM | ok |
| 23:14.10 | Thumper_ | ie it was a Mac |
| 23:14.28 | JeffM | what about the ST double auto pilot thing? |
| 23:17.29 | TD-Linux | also "not drawing back to front when depth buffer is on:" I think was fixed a long time ago |
| 23:17.42 | TD-Linux | IIRC all transparent polygons are z sorted |
| 23:18.23 | CIA-5 | BZFlag: 03JeffM2501 * r21994 10/trunk/bzflag/BUGS: removed fixed items |
| 23:23.29 | BulletCatcher | The -directory problem in the BUGS file was for Windows, but we can ask for clarifcation when Packman returns. |
| 23:23.47 | JeffM | I just did it and it works fine |
| 23:23.56 | JeffM | he probably forgot to put quotes around it |
| 23:24.05 | JeffM | many paths in windows have spaces |
| 23:24.12 | BulletCatcher | got it |
| 23:24.14 | JeffM | even steped thru the code |
| 23:24.19 | JeffM | it's all called in the right order |
| 23:27.52 | delusional | thought you were talking about the problem i had yesterday |
| 23:45.07 | *** join/#bzflag joevano (~joevano@bzflag/developer/JoeVano) |
| 23:45.07 | *** mode/#bzflag [+v joevano] by ChanServ |
| 23:56.07 | *** join/#bzflag Anxuiz (~Anxuiz@unaffiliated/anxuiz) |
