| 01:30.51 | *** join/#bzflag noyb (~noyb@pool-173-60-180-80.lsanca.dsl-w.verizon.net) |
| 01:50.48 | *** join/#bzflag GransRemedy (~john@121-79-204-29.sta.inspire.net.nz) |
| 01:56.30 | blast007 | hi GransRemedy :) |
| 02:02.18 | blast007 | mdskpr: I'm not really sure how much the current PHP site actually *does* for tracking stuff |
| 02:02.37 | blast007 | seems like the only database tables are for the current players/servers - no history data |
| 02:03.06 | blast007 | it's all in here http://bzflag.svn.sourceforge.net/viewvc/bzflag/trunk/web/bzfstats/ |
| 02:03.25 | blast007 | and I have an instance of it up at http://stats.bzexcess.com/track/ |
| 02:03.36 | blast007 | but the main page there just spits out "ok" when you go to it :) |
| 02:07.00 | mdskpr | well I couldn't test it anyways because all of my UDP ports are blocked so i couldn't make a public server |
| 02:07.06 | blast007 | hehe |
| 02:07.37 | mdskpr | are you too busy to test it? |
| 02:07.45 | mdskpr | i could make a patch |
| 02:08.07 | blast007 | I'm trying it here witha 2.99.x server to see what it actually does |
| 02:14.24 | mdskpr | well i'll see about it tomorrow |
| 02:26.06 | blast007 | man, there's no way this code every worked... |
| 02:26.12 | blast007 | ever* |
| 03:49.31 | *** join/#bzflag bier (~bier@p54A5A168.dip.t-dialin.net) |
| 04:00.35 | *** join/#bzflag delusional (~delusiona@unaffiliated/delusional) |
| 06:13.07 | *** join/#bzflag Marzipan- (~Marzipan@p5B223E8C.dip.t-dialin.net) |
| 06:14.41 | *** join/#bzflag Marzipan (~Marzipan@bzflag/player/Marzipan) |
| 06:18.09 | CIA-117 | BZFlag: 03bullet_catcher * r21727 10/trunk/bzflag/ (28 files in 28 dirs): Install plugins in libdir rather than pkglibdir for finer configure-time control. |
| 06:32.40 | *** join/#bzflag noyb (~noyb@pool-173-60-180-80.lsanca.dsl-w.verizon.net) |
| 07:59.17 | *** join/#bzflag Djpenguin (~David@c-98-207-67-102.hsd1.ca.comcast.net) |
| 09:11.50 | *** join/#bzflag Upsetter (~er@i59F6D443.versanet.de) |
| 12:38.33 | CIA-117 | BZFlag: 03trepan * r21728 10/branches/experimental/v2_99continuing/bzflag/ (5 files in 3 dirs): (log message trimmed) |
| 12:38.34 | CIA-117 | BZFlag: * split out a very simple "config.lua" for basic configuration options |
| 12:38.34 | CIA-117 | BZFlag: (eventually, this file will be used for all build systems to source |
| 12:38.34 | CIA-117 | BZFlag: the executable version, using prelinkcommands() to ensure consistency) |
| 12:38.34 | CIA-117 | BZFlag: * started to setup "packages", to ease the configuration of libraries for |
| 12:38.34 | CIA-117 | BZFlag: the different setups using the linkpkg() and includepkg() calls: |
| 12:38.34 | CIA-117 | BZFlag: linkpkg 'zlib' -- adds the required -L and -l flags (or equiv.) |
| 12:43.53 | Pimpinella | would the licence allow linking of non free plugins to bzfs' API ? |
| 12:45.09 | Cobra_Fast | if bzfs is gpl then yes. it would only forbit redistributing bzfs with the non-free plugin as long as no source code is attached. |
| 12:45.45 | trepan | the bz sources are LGPL |
| 12:45.57 | *** join/#bzflag mdskpr_ (~mdskpr@108.25.145.104) |
| 12:46.03 | Cobra_Fast | im not familiar with the differences there |
| 12:46.33 | Pimpinella | lgpl allows redistributing |
| 12:46.38 | trepan | http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License |
| 12:47.23 | trepan | see the "Differences from the GPL" section |
| 12:49.28 | Cobra_Fast | so using non-free plugins with bzfs would still be legal. |
| 12:57.50 | CIA-117 | BZFlag: 03trepan * r21729 10/branches/experimental/v2_99continuing/bzflag/ (3 files in 2 dirs): * fixed os.testcode() |
| 13:30.45 | CIA-117 | BZFlag: 03trepan * r21730 10/branches/experimental/v2_99continuing/bzflag/ (5 files in 5 dirs): |
| 13:30.45 | CIA-117 | BZFlag: * fixed the premake plugins configuration |
| 13:30.45 | CIA-117 | BZFlag: * added a little color to the premake gmake setup |
| 13:51.51 | blast007 | mdskpr_: looking at the PHP code for the push stats, I don't think it ever worked... so I'm not sure if we should really put the push stats stuff into 2.4 |
| 14:03.17 | CIA-117 | BZFlag: 03trepan * r21731 10/branches/experimental/v2_99continuing/bzflag/other_src/premake/src/ (actions/make/make_cpp.lua host/scripts.c): |
| 14:03.17 | CIA-117 | BZFlag: * show the link target name during gmake builds, ex: |
| 14:03.17 | CIA-117 | BZFlag: "<libMediaFile> Linking libMediaFile-debug.a" |
| 14:21.21 | *** join/#bzflag bier|tp (~bier@p57A66AA4.dip.t-dialin.net) |
| 15:04.58 | *** part/#bzflag Upsetter (~er@i59F6D443.versanet.de) |
| 15:24.51 | CIA-117 | BZFlag: 03bullet_catcher * r21732 10/trunk/bzflag/configure.ac: Use "test" rather than "[" for compatibility with m4. |
| 15:58.01 | trepan | from what I'm seeing, we don't build the glew, ftgl, or freetype libs for windows? (shipping .dll's instead?) |
| 16:00.33 | trepan | hm, or maybe we do: bzflag.sln: "glew_static", "..\..\other_src\glew\build\vc6\glew_static.vcproj" |
| 16:20.46 | blast007 | trepan: yeah, we build it all on Windows |
| 16:43.46 | BulletCatcher | In 2.3, it looks like we don't actually use GLEW on Windows and we don't ever build it on unix-like systems. |
| 16:43.47 | BulletCatcher | Is it really needed? |
| 16:44.21 | blast007 | we use it for anisotropic filtering |
| 16:45.42 | blast007 | or at least we had done so in 2.0.x |
| 16:47.16 | blast007 | we didn't build glew as part of the build process in 2.0.x, but it was needed when doing a release build (as was PDCurses) |
| 16:48.14 | BulletCatcher | I don't see any Windows support for GLEW in 2.0.17. |
| 16:49.48 | blast007 | https://bzflag.svn.sourceforge.net/svnroot/bzflag/branches/release_maint/v2_0/bzflag/win32/VC9/bzflag.vcproj search for "HAVE_GLEW" |
| 16:50.33 | BulletCatcher | Yeah. Gotta fix my "grep" script. |
| 16:51.00 | *** join/#bzflag Upsetter (~er@i59F6D443.versanet.de) |
| 16:59.13 | *** join/#bzflag Anxuiz (~Anxuiz@unaffiliated/anxuiz) |
| 17:04.55 | trepan | uses this: http://trepan.bzflag.bz/noshow/lgrep |
| 17:20.15 | BulletCatcher | Fixed. Instead of a file extension whitelist I now simply exclude .png, .psd, and .wav files, which are binary formats. |
| 17:20.41 | BulletCatcher | It is a simle one-line script: |
| 17:20.43 | BulletCatcher | grep $* `find ./.svn * -name \*.svn-base | sed -e 's=/.svn/[pt][re][ox][pt]-base/=/=' -e 's/\.svn-base$//' | egrep -v '\.(png|psd|wav)$' | sort -u` |
| 17:23.25 | BulletCatcher | And it looks like Windows doesn't use GLEW in 2.3. |
| 17:25.49 | *** join/#bzflag Djpenguin (~David@c-98-207-67-102.hsd1.ca.comcast.net) |
| 17:38.07 | blast007 | yeah, doesn't appear to be hooked in yet |
| 18:04.44 | *** join/#bzflag JeffM (~JeffM@adsl-76-204-47-237.dsl.lsan03.sbcglobal.net) |
| 18:04.44 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 18:04.44 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 18:14.36 | *** join/#bzflag fahadsadah (fahad@unaffiliated/fahadsadah) |
| 18:35.17 | JeffM | Pimpinella, did you want to add GM radar markers? |
| 18:35.44 | trepan | blast007: could you create a mercurial (hg) copy of branches/experimental/v2_99continuing/bzflag on sourceforge? |
| 18:35.50 | trepan | or bzr, or git |
| 18:36.16 | JeffM | will that keep them in sync? or just branch off a copy? |
| 18:36.34 | trepan | is stuck behind a crap net link, and a DVCS would be much nicer |
| 18:36.43 | trepan | JeffM: SVN would die for 2.99 |
| 18:36.51 | JeffM | why? |
| 18:37.22 | trepan | unless all you wanted to do was occasionally sync to hg |
| 18:37.30 | trepan | but commits go to 1 rev system |
| 18:37.47 | JeffM | I'm not a fan of big code drops and from what I've seen DVCS tends to encourage that |
| 18:38.04 | trepan | working with them is significantly faster |
| 18:38.11 | *** join/#bzflag sirquine (~quine@c-71-237-73-109.hsd1.co.comcast.net) |
| 18:38.17 | JeffM | I can see that for those that have network issues |
| 18:38.38 | JeffM | but I'm not sure that the problems that it makes are wrorth just that |
| 18:38.48 | blast007 | I think mercurial would be a cleaner way to handle our branches |
| 18:38.53 | trepan | and from what i've seen, bzflag has benefited from big code drops, it was the incremental ones that slowly killed it :) |
| 18:39.11 | JeffM | actualy 1.8 died cus of big code drops |
| 18:39.31 | JeffM | when people go off and do there own thing the others won't go into that code |
| 18:39.31 | trepan | 1.8 was before my time |
| 18:39.48 | JeffM | yes, but a lot of us won't go into your code in 2.99 cus it was just ploped in |
| 18:39.48 | trepan | (mostly, ansicodes iirc) |
| 18:40.08 | trepan | "won't go into" ? |
| 18:40.10 | blast007 | people can do that with any version control system, JeffM |
| 18:40.13 | JeffM | I'm not against moving to a DVCS but if we do we have to set up some rules |
| 18:40.16 | JeffM | blast007, I know |
| 18:40.23 | trepan | hg it is then :) |
| 18:40.30 | JeffM | good by disk space |
| 18:40.32 | blast007 | at least with a DVCS you'd have incremental commits that you can look at the progression |
| 18:40.44 | JeffM | yes and no |
| 18:40.50 | trepan | maybe folks would be more to test with a DVCS? |
| 18:40.53 | JeffM | you can only look at them if you have them :) |
| 18:41.00 | blast007 | JeffM: true |
| 18:41.17 | JeffM | with the central system you FORCE them to commit it to us |
| 18:41.35 | JeffM | the best uses of DVCSs are for projects that use a gatekeeper for patches |
| 18:41.38 | JeffM | and we don't do that |
| 18:41.46 | trepan | sourceforge? |
| 18:41.53 | JeffM | but we can set up a HG repo |
| 18:41.56 | blast007 | though I think something like bitbucket.org would be better than putting it on SF - easier for other people to publically fork instead of just hoarding it on their local machine |
| 18:42.08 | JeffM | nobody forks |
| 18:42.13 | JeffM | we've seen that |
| 18:42.14 | blast007 | we do ;) |
| 18:42.18 | trepan | blast007: that works for me too |
| 18:42.25 | JeffM | yeah but we never merge back |
| 18:42.26 | blast007 | all of our branches are a fork |
| 18:42.38 | JeffM | and they all fail ;) |
| 18:42.45 | JeffM | but yes non SF would be good :) |
| 18:42.48 | blast007 | and DVCS's are supposed to be better at merging changes |
| 18:42.54 | JeffM | they are |
| 18:43.00 | JeffM | if you have someone to manage that |
| 18:43.09 | JeffM | it's more pull for merging then it is pushing |
| 18:43.42 | JeffM | google code offers HG too |
| 18:44.19 | blast007 | how easy is it for users to fork the code though? do they have to create a new project? |
| 18:44.31 | JeffM | dunno |
| 18:44.41 | JeffM | bitbucket looks to dharge for more then 5 users |
| 18:44.44 | JeffM | charge |
| 18:45.02 | blast007 | that's for private repos |
| 18:45.10 | JeffM | and if people have to make another account to login for sourcecode stuff, they probalby already have a google account ;) |
| 18:45.13 | blast007 | public repos can have unlimited users |
| 18:45.16 | JeffM | ahh |
| 18:45.38 | trepan | google isn't a bad idea, pandering for future GSOC cash? :) |
| 18:45.55 | JeffM | pffft, bzflag should never enter that again |
| 18:46.14 | JeffM | with a DVCS those students would be hell to manage |
| 18:46.27 | JeffM | we had a hard enough time just keeping them on IRC talkin |
| 18:46.59 | JeffM | start a bitbucket, move the code over, let treapan do his stuff |
| 18:47.08 | JeffM | cus even in svn his 2.99 is a massive code drop |
| 18:47.15 | JeffM | because we arn't paying any attention to it |
| 18:47.58 | JeffM | does bitbucket have bug trackers? |
| 18:48.32 | trepan | bitbucket has issues |
| 18:48.53 | trepan | ex: https://bitbucket.org/rude/love/issues |
| 18:48.58 | JeffM | if you like do a quick compare between bitbucket and google and see who has better tools |
| 18:49.04 | JeffM | also does bitbucket do bin releases? |
| 18:49.06 | JeffM | cus google does |
| 18:49.28 | trepan | it has downloads, ex: https://bitbucket.org/rude/love/downloads |
| 18:49.40 | JeffM | k |
| 18:49.50 | JeffM | will it ever support multiple VCSs ? |
| 18:50.16 | trepan | my crystal ball is on the blink |
| 18:50.37 | JeffM | google supports 2 now, that tells me they are at least open to the idea |
| 18:51.00 | trepan | google uses hg for a number of its projects, iirc |
| 18:51.12 | trepan | definitely for the 'Go' lang |
| 18:51.23 | JeffM | yeah it has svn and hg |
| 18:51.54 | JeffM | trying to find a feature comparison between the services |
| 18:52.53 | blast007 | they're similar |
| 18:53.09 | JeffM | seems that bitbuckets big thing is offering private repos |
| 18:54.12 | JeffM | tho with a dvcs it's easy to move hosting, EVERYONE has the entire history on disk :) |
| 18:55.27 | JeffM | google has a page on the benifits of each vcs, http://code.google.com/p/support/wiki/ChoosingAVersionControlSystem |
| 18:56.01 | JeffM | personaly I think we fit more into the svn category |
| 18:56.19 | JeffM | I just don't see us branching much |
| 18:56.37 | JeffM | a few people try every so often but then they give up long before they get to the merge stage |
| 18:57.09 | blast007 | we branch all the time :) |
| 18:57.21 | JeffM | when was the last usefull branch? |
| 18:57.31 | blast007 | v2_0 is a branch, v2_4 will be another branch |
| 18:57.43 | JeffM | yeah but we only really work on one at a time |
| 18:57.55 | blast007 | two at a time, usually |
| 18:57.56 | JeffM | we don't have 4 branches from different devs going on |
| 18:58.05 | JeffM | one for real, and one for smallness :) |
| 18:58.13 | blast007 | still :) |
| 18:58.36 | JeffM | dosn't mean that moving to a system with simpler branch merges will help |
| 18:58.46 | JeffM | vcs is not bzflag's big problem |
| 18:59.15 | JeffM | but again, make one for trepan, see how it works |
| 18:59.26 | JeffM | functionaly it dosn't matter where he does his code |
| 18:59.34 | JeffM | since the rest of us are/should be working on 2.4 |
| 18:59.42 | JeffM | so it's a code drop no mater what |
| 19:06.06 | JeffM | enahanced hud markers were always on in 2.99 right? |
| 19:07.32 | trepan | you could see where "_forbidMarkers" was used |
| 19:08.59 | trepan | (one spot in HUDRenderer.cpp -- blocks drawMarkersInView()) |
| 19:20.24 | JeffM | hmm I was searching for markers and didn't see that |
| 19:22.02 | JeffM | ahh a I had crappy search settings, thanks |
| 19:41.14 | JeffM | blast007, so we arn't moving services till after release right? |
| 19:42.07 | JeffM | mdskpr_, did you finish the removal of /identify? |
| 19:43.37 | joevano | JeffM: branches in a dvcs are a totally different animal than in svn... not comparable imho |
| 19:43.49 | JeffM | yeah I know |
| 19:43.53 | JeffM | that's what I fear ;) |
| 19:43.59 | joevano | or at least they are used very differently |
| 19:44.05 | JeffM | they can be yes |
| 19:44.23 | JeffM | but they also can be used for the same thing in the cases where you need to do what you did in svn |
| 19:44.34 | blast007 | JeffM: I don't see it as critical to the release, so probably not |
| 19:44.35 | JeffM | i.e. multiple people on a branch doing maint |
| 19:44.51 | JeffM | blast007, ok, just trying to clean up the doc |
| 19:45.31 | joevano | at work nothing we do ever happens on the main line of code |
| 19:45.41 | JeffM | yeah that's one way to work |
| 19:45.51 | JeffM | who manages pulling all your stuff together for a release? |
| 19:46.20 | joevano | all work is done on a branch and merged back in by the dev working on it |
| 19:46.33 | joevano | once it is completed |
| 19:46.36 | JeffM | k |
| 19:46.46 | blast007 | JeffM: also, not sure if we want to bother with push stats yet |
| 19:46.47 | JeffM | how does that effect colaboration? |
| 19:46.54 | JeffM | blast007, why not? |
| 19:47.16 | blast007 | because the PHP-side needs work |
| 19:47.25 | blast007 | doesn't seem like the current code could have ever worked |
| 19:47.31 | JeffM | it dosn't |
| 19:47.35 | JeffM | I just wanted the server side in |
| 19:47.37 | joevano | JeffM: sharethe branch with someone else for colab |
| 19:47.51 | JeffM | so that we had people pushing the data for when it does work |
| 19:48.03 | JeffM | joevano, only those specific people |
| 19:48.23 | JeffM | you loose the ability for say bryjen to see my incremental commit and find a problem I missed |
| 19:48.29 | JeffM | he has to wait till I merge |
| 19:48.37 | JeffM | unless I go find him |
| 19:48.45 | joevano | keeps the main line very clean and *generally* working 100% |
| 19:49.04 | JeffM | in your system I'd still have broken the mainline just in the middle of a big commit |
| 19:49.13 | JeffM | we don't have devs that can do full unit testing |
| 19:49.22 | JeffM | but I understand your system |
| 19:49.32 | JeffM | I just don't feel it is a good fit for this project |
| 19:49.44 | joevano | JeffM: yes that can be true... but we also write tests to mitigate that but it would be different here |
| 19:50.04 | JeffM | yeah I'm just saying it's different here :) |
| 19:50.18 | joevano | yeah i guess it is |
| 19:50.19 | JeffM | the open source proejcts I've seen that use DVCS well have a gatekeeper |
| 19:50.28 | JeffM | or a structure like you have |
| 19:50.54 | JeffM | we have so little structure that I fear that any loss of the one that our tools impose on us will be for the worse |
| 19:51.10 | JeffM | I mean there is no way I can test my changes on a mac |
| 19:51.25 | JeffM | regardless of how many tests I write |
| 19:51.34 | JeffM | now a build farm would help that |
| 19:51.54 | JeffM | but thats a house of cards we haven't built yet :) |
| 19:52.04 | JeffM | but really it can all be discussed for 3.0 |
| 19:52.23 | JeffM | having trepan test it is not a bad idea, then we have a good test case to review |
| 19:52.55 | JeffM | and like i said, his work is not part of the release so we arn't realy paying attention to it now, so the benifits we get from SVN are lost |
| 19:53.11 | JeffM | in fact it can be a little distracting seeing the commits mixed in |
| 19:53.20 | JeffM | so he may be better off out on his own |
| 19:54.49 | JeffM | joevano, just out of curiosity how do you notify all your devs that they need to get, or do they just do so everyday automaticly? |
| 19:57.05 | *** join/#bzflag QuantumBeep (~quantumbe@cpe-76-186-97-233.tx.res.rr.com) |
| 19:58.11 | *** join/#bzflag Upsetter1 (~er@i59F6C0E0.versanet.de) |
| 20:00.26 | CIA-117 | BZFlag: 03JeffM2501 * r21733 10/trunk/bzflag/src/ (4 files in 2 dirs): |
| 20:00.26 | CIA-117 | BZFlag: draw lock-on markers |
| 20:00.26 | CIA-117 | BZFlag: remove points from corners of hud boxes, they don't draw right on all cards and it makes them look "rounded" |
| 20:02.55 | joevano | JeffM: generally the rule is to get as often as you want but ALWAYS before you merge a branch back in |
| 20:03.16 | JeffM | well yeah you'd have to :) |
| 20:04.43 | JeffM | should I bother with having bz check with more then one url for services? |
| 20:04.43 | *** join/#bzflag QuantumBeep (~quantumbe@cpe-76-186-97-233.tx.res.rr.com) |
| 20:05.43 | blast007 | I don't see a huge benefit to doing that yet |
| 20:06.02 | joevano | when will we have redundent servcies... probably good to plan for but not necessary at this time |
| 20:06.04 | JeffM | no benifit in having it there so when we do swap stuff it happens faster |
| 20:06.21 | JeffM | I mean we've seen what having the dns thing has caused |
| 20:06.44 | JeffM | we can't move services with out a software update |
| 20:07.07 | JeffM | but ok |
| 20:07.13 | mdskpr_ | JeffM: yes |
| 20:07.16 | blast007 | having multiple URLs in 2.4 won't help the 2.0.x servers migrate |
| 20:07.22 | JeffM | mdskpr_, mark it on the doc please |
| 20:07.26 | mdskpr_ | k |
| 20:08.01 | JeffM | blast007, yeah I know, but will it help the 2.4 servers deal with us moving stuff around, like /db to db.bz.o |
| 20:08.50 | JeffM | I don't know what other changes you may want to do after you get services moved that could benifit from having a second distinct URL in the code |
| 20:09.06 | blast007 | we'd still have to provide the old interface since 2.0.x clients would need it |
| 20:09.28 | JeffM | yes but after release they could have downtime when stuff moved :) |
| 20:09.35 | JeffM | but ok, I'll pull it from the list |
| 20:09.41 | JeffM | just trying to see where we are |
| 20:09.50 | JeffM | since we are 1/2 way thru our month |
| 20:10.06 | blast007 | the DNS TTLs are low enough that moving shouldn't cause much of a disruption for stuff that caches properly (which 2.4 will) |
| 20:10.17 | JeffM | k |
| 20:11.52 | JeffM | is the dns fix in 2.3 yet? |
| 20:16.45 | blast007 | not yet |
| 20:17.45 | blast007 | gonna look into that tonight or tomorrow |
| 20:23.26 | *** join/#bzflag QuantumBeep (~quantumbe@cpe-76-186-97-233.tx.res.rr.com) |
| 20:38.05 | blast007 | hah.... Bitbucket has an "Import from SVN" option .... |
| 20:40.43 | *** join/#bzflag QuantumBeep (~quantumbe@cpe-76-186-97-233.tx.res.rr.com) |
| 20:41.17 | *** join/#bzflag Djpenguin (~David@c-98-207-67-102.hsd1.ca.comcast.net) |
| 20:44.31 | CIA-117 | BZFlag: 03JeffM2501 * r21734 10/trunk/bzflag/src/bzflag/effectsRenderer.cxx: == != = |
| 20:45.19 | CIA-117 | BZFlag: 03JeffM2501 * r21735 10/trunk/bzflag/ (8 files in 3 dirs): draw ID markers with IFF for the closest player in _targetingDistance units. |
| 20:47.03 | JeffM | that should finish off hud markers |
| 20:47.09 | JeffM | 4 left :) |
| 20:50.11 | *** join/#bzflag QuantumBeep (~quantumbe@cpe-76-186-97-233.tx.res.rr.com) |
| 20:56.28 | blast007 | ah, the import option on the bitbucket site doesn't keep revision history |
| 20:57.43 | blast007 | trepan: https://bitbucket.org/blast007/bzflag-v2_99 note that it only has the revisions since the v2_99continuing branch was converted - not sure if there's a better way to do it that would keep more history |
| 20:57.57 | blast007 | was created* |
| 20:58.11 | Pimpinella | JeffM: what i suggested on forum today? |
| 20:58.29 | JeffM | Pimpinella, yes |
| 20:58.54 | Pimpinella | not sure, it was just a suggestion for now. when i'm done what i do now, lets see |
| 20:59.00 | JeffM | ok |
| 20:59.18 | JeffM | cus I made radar artwork to use for it if you want :) |
| 20:59.24 | Pimpinella | guess i have no idea at all how radar is made so far |
| 20:59.39 | JeffM | a dot a in't good enough but red brackets and red diamonds will work |
| 20:59.50 | JeffM | diamonds for shots, brackets for tank that is locked on |
| 21:00.43 | Pimpinella | ok |
| 21:04.00 | trepan | blast007: cool, thanks (and ya, we should take a look at getting the entire history) |
| 21:04.22 | blast007 | I'm converting the entire repo right now to see what that does |
| 21:04.36 | blast007 | think I might have to do some extra stuff since we now have branches under subdirs |
| 21:38.16 | Pimpinella | JeffM: well, that GM stuff might be something players would want. One more feature to make them upgrade version. I'll have a look at it. Artwork would be very welcome, it's something i hate to do ;) |
| 21:41.43 | *** join/#bzflag Djpenguin (~David@c-98-207-67-102.hsd1.ca.comcast.net) |
| 22:08.34 | JeffM | Pimpinella, I have it drawn, just let me know when you want it |
| 22:18.16 | mdskpr_ | JeffM: were you going to replace std_ground.png with the one from 2.99x? |
| 22:18.45 | JeffM | was it different? |
| 22:19.23 | mdskpr_ | yup |
| 22:19.32 | mdskpr_ | sandy gray iirc |
| 22:19.51 | mdskpr_ | 2.0.x std_ground.png was moved to grass.png |
| 22:20.04 | JeffM | yeah but it's the same image |
| 22:20.32 | JeffM | it draws the same |
| 22:20.54 | JeffM | I have no need to change it's name for the sake of chaning it's name :) |
| 22:21.19 | mdskpr_ | idt so...lemme see |
| 22:21.24 | JeffM | I'm not sure what "ground" is used for in 2.99 |
| 22:23.36 | mdskpr_ | ahh ground.png is the default ground texture |
| 22:23.39 | JeffM | why would we want to make the default ground be ash |
| 22:23.44 | JeffM | that's stupid |
| 22:23.47 | JeffM | and fugly |
| 22:24.52 | JeffM | why would we want to make the world look worse? |
| 22:25.05 | mdskpr_ | ok |
| 22:25.23 | JeffM | maybe someone didn't like how the green team blended int to it? |
| 22:25.46 | trepan | give the man a cookie :) |
| 22:26.06 | JeffM | if that's the problem then don't make the tank colors CAMOFLAGE.. that's what it does |
| 22:26.23 | JeffM | I'd get rid of the green team before I changed the grown to uggly mess |
| 22:27.25 | trepan | it's plain concrete, not that ugly |
| 22:27.26 | *** join/#bzflag Pimpi (~frank@gondolin.pimpi.org) |
| 22:27.51 | trepan | if the game were about sprites, fairies, and deer; then ya, grass might be more appropriate |
| 22:27.58 | trepan | but as it stands, it's about tanks |
| 22:28.06 | JeffM | then it should be sand ;) |
| 22:28.09 | JeffM | and no buildings |
| 22:28.24 | JeffM | and you wouldn't want the enemy to see your tank |
| 22:28.59 | trepan | tanks hit amongst the buildings, twas a common tactice |
| 22:29.05 | trepan | *tactic |
| 22:29.08 | JeffM | if the world was concete you'd use something other then a tank these days |
| 22:35.44 | *** join/#bzflag ibot (~ibot@rikers.org) |
| 22:35.44 | *** topic/#bzflag is http://my.bzflag.org/w/BZFlag_2.3 || http://my.BZFlag.org || http://cia.vc/stats/project/BZFlag || http://my.BZFlag.org/w/Getting_Help || Channel Logs: http://ibot.rikers.org/%23bzflag/ || 2.0.16 is the current release, use it wisely |
| 22:35.45 | *** mode/#bzflag [+o ibot] by ChanServ |
| 22:36.49 | JeffM | if you want gameplay pureism then take away the 3d view, most people play by radar only anyway |
| 22:36.58 | JeffM | turn it into a datastream |
| 22:40.45 | JeffM | how many games end up with 4 teams playing anyway? |
| 22:41.36 | CIA-117 | BZFlag: 03JeffM2501 * r21736 10/trunk/bzflag/data/green_tank.png: make the green tank stand out a bit more in the 3d view |
| 22:42.26 | JeffM | could convert the green to team to yellow and make rogues use white or gray shots |
| 22:49.07 | JeffM | if you want to set it in a city, then turn all the tanks into M38 wolfhounds and bump up the speed :) |
| 22:50.11 | JeffM | would make more sense, tanks are made to go up and over funky terrain, and ours cant |
| 22:51.28 | *** join/#bzflag noyb (~noyb@pool-173-60-180-80.lsanca.dsl-w.verizon.net) |
| 22:59.36 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 23:01.15 | *** join/#bzflag Pimpi (~frank@gondolin.pimpi.org) |
| 23:09.15 | *** join/#bzflag TD-Linux (~thomas@about/essy/indecisive/TD-Linux) |
| 23:46.05 | *** join/#bzflag Anxuiz_ (~Anxuiz@c-67-171-11-99.hsd1.wa.comcast.net) |