| 01:00.13 | *** join/#bzflag ashvala (~ashvala@unaffiliated/ashvala) |
| 01:03.57 | drizzo4shizzo | joevano++ |
| 01:04.02 | drizzo4shizzo | cloned repo in <1 minute :) |
| 01:07.43 | drizzo4shizzo | no tags yet? |
| 01:07.53 | JeffM2501 | why would we need tags? |
| 01:07.57 | drizzo4shizzo | we probably dont |
| 01:08.16 | JeffM2501 | we'll make new ones if we release anything |
| 01:08.24 | JeffM2501 | there isn't any real need to port over the old ones |
| 01:08.24 | drizzo4shizzo | worksforme |
| 01:10.17 | drizzo4shizzo | can we repeat what branch is what? master is 2.5? 2.4 is release_maint? |
| 01:10.52 | JeffM2501 | 2.4 is 2.4.0, we don't have a branch for 2.4.3, that development will still go on in svn |
| 01:11.07 | drizzo4shizzo | oh yeah sorry |
| 01:11.14 | JeffM2501 | master is 2.5.x to be released as 2.6 |
| 01:11.32 | drizzo4shizzo | hmm so any fixes in 2.4 have to happn in SVN and also in git |
| 01:11.37 | JeffM2501 | yup |
| 01:11.40 | JeffM2501 | double stitch |
| 01:11.47 | JeffM2501 | I don't expect there to be many if any |
| 01:11.54 | drizzo4shizzo | alright |
| 01:11.59 | drizzo4shizzo | you can always make a patch |
| 01:12.13 | JeffM2501 | techincaly the git repo is an experiment, it may fail and we go back to SVN |
| 01:12.30 | JeffM2501 | so we can not count on it to be the end all-be all of repositories |
| 01:13.03 | drizzo4shizzo | supposing it succeeds, at some point in the future 2.4 can get folded into git |
| 01:13.40 | JeffM2501 | there will never be a future 2.4 |
| 01:13.50 | drizzo4shizzo | got it |
| 01:14.06 | JeffM2501 | that's the entire point, we are working on the breaking release |
| 01:14.09 | drizzo4shizzo | I meant for historical "correctness" but if we are merging the patches over it doesnt matter |
| 01:14.14 | JeffM2501 | meh |
| 01:14.36 | JeffM2501 | we pondered removing all history so 'correctness' isn't that high on the list |
| 01:14.43 | drizzo4shizzo | hah glad u didn't do that |
| 01:14.58 | drizzo4shizzo | u can easily remove "history before X" too |
| 01:15.10 | drizzo4shizzo | but it changes all the subsequent commit hashes of course |
| 01:45.39 | *** join/#bzflag swigg__ (~swigg@68-119-228-196.dhcp.ahvl.nc.charter.com) |
| 02:08.55 | *** join/#bzflag swigg__ (~swigg@68-119-228-196.dhcp.ahvl.nc.charter.com) |
| 02:16.03 | *** join/#bzflag JeffM__ (~JeffM@cpe-76-167-236-199.socal.res.rr.com) |
| 02:53.59 | TkTech | JeffM2501: All of the documentation is being reworked and the github integration is getting simplified (just an on/off toggle, like travis.ci). Sorry it sucks, haven't had any time to work on it. |
| 03:14.04 | allejo | JeffM2501, joevano, blast007, is there going to be a bot for github notifications? |
| 03:15.07 | BulletCatcher | There notifications a few hours ago. |
| 03:15.14 | BulletCatcher | were |
| 03:15.27 | allejo | oh awesome, hadn't scrolled up |
| 03:16.11 | allejo | oh cool, just saw them |
| 03:16.19 | JeffM | TkTech, huh? |
| 03:16.38 | TkTech | JeffM: Your comments earlier on Not-001. |
| 03:16.51 | JeffM | ahh |
| 03:18.07 | JeffM | it just would have been nice for there to be some kind of note that I had to click the link thingy |
| 03:18.38 | JeffM | the link to githup for "webhooks" was a bit confusing. |
| 03:18.51 | TkTech | Yeah, that's all being redone. Most people use the github integration instead of manually copying it anyways, and that will set the hooks for you. |
| 03:19.14 | JeffM | I did all the steps and told github to allow the app, it didn't do anything |
| 03:19.50 | TkTech | Did you check the "Set Hooks" box? |
| 03:19.56 | JeffM | probalby not |
| 03:20.26 | TkTech | Yeah, see it's too confusing. Removing *all* the import options and just providing an on/off toggle would be much cleaner. |
| 03:20.39 | JeffM | or some docs would work too |
| 03:20.51 | *** join/#bzflag khonkhortisan (~kyle@c-50-132-92-113.hsd1.wa.comcast.net) |
| 03:20.53 | TkTech | If you haven't sync'd with github (so it has no auth) the link would be a popover with instructions |
| 03:20.53 | JeffM | more options tends to be better then less, as long as we know how to use em |
| 03:21.09 | JeffM | I also got a little confused as there is a similary named hook in github that I thought controld it |
| 03:21.16 | TkTech | Really? |
| 03:21.20 | JeffM | yeah |
| 03:22.24 | JeffM | Notifo |
| 03:24.08 | TkTech | Ah, I should send a pull request to remove it, that product has been dead for two years |
| 04:03.20 | *** join/#bzflag swigg__ (~swigg@68-119-228-196.dhcp.ahvl.nc.charter.com) |
| 04:32.13 | apeman_ | I just looked at ServerSidePlayer in trunk, and it looks like it cant move or shoot |
| 04:32.41 | apeman_ | cant as in the logic isnt there |
| 04:33.07 | JeffM | not yet |
| 04:33.56 | apeman_ | where would the networking code go? Would have to make some new base class for "players"? |
| 04:34.20 | JeffM | why would there be networking code? |
| 04:34.32 | JeffM | who would the server network to? |
| 04:34.46 | apeman_ | server sending messages to the real players |
| 04:34.53 | JeffM | it already does that |
| 04:35.29 | JeffM | it sends messages to all the players already |
| 04:35.37 | JeffM | it's how you actualy play a network game |
| 04:36.22 | JeffM | I think what you mean is the code that does the movment and keeps the server state up to date as the bots move around |
| 04:36.27 | JeffM | that has nothing to do with networking |
| 04:36.28 | apeman_ | well since it cant shoot or move the only messages it sends are addplayer, removeplayer |
| 04:36.43 | JeffM | yeah I never hooked up the rest of the state |
| 04:37.39 | JeffM | the client movement code needs to be put over and then we can have the server pack up messages for them like it does everyone else |
| 04:38.37 | JeffM | for shots the server needs to be able to track the shot paths |
| 04:39.35 | JeffM | then it can send the shot messages jut like everyone else |
| 04:40.58 | apeman_ | by networking code i mean stuff like { broadcastMessage(MsgShotBegin, (char *)buf - (char *)bufStart, bufStart); } |
| 04:41.05 | apeman_ | which the client does |
| 04:41.21 | apeman_ | which a bot would do... either as a client or |
| 04:41.23 | JeffM | sure the server has code other places to deal with the messages, so we can just leverage that |
| 04:41.34 | JeffM | ithe bot isn't a client, the bot is the server |
| 04:41.40 | JeffM | so it will use the server state networking code |
| 04:41.53 | JeffM | the bot dosn't open any new networking connections |
| 04:42.23 | apeman_ | ok, you are using a strict definition |
| 04:42.23 | JeffM | in the end the server has to be able to send out message for any player, real or bot |
| 04:42.26 | JeffM | yes |
| 04:42.55 | JeffM | because I don't want anyone hacking up the server and adding new connections, or duplicating client code for stuff the server should have |
| 04:43.48 | apeman_ | duplication as in behaviour, or as in code? |
| 04:43.54 | JeffM | code |
| 04:44.27 | JeffM | optimaly we'd have a lib for the logic that both the client and the server can use |
| 04:44.37 | JeffM | then there would be no duplication |
| 04:45.54 | apeman_ | i still struggle to imagine how one would refactor that much while keeping trunk in a working state |
| 04:46.22 | JeffM | you do it in little bits |
| 04:46.31 | JeffM | you make the lib and have bot things use it but leave it empty |
| 04:46.41 | JeffM | then move one bit into it, then another |
| 04:46.42 | JeffM | etc... |
| 04:47.11 | apeman_ | the intermediate would at times be described as messier than the original, no? |
| 04:47.17 | JeffM | sure |
| 04:47.24 | JeffM | eyes on the prize :) |
| 04:47.45 | JeffM | making things better takes work |
| 04:47.51 | apeman_ | ok. I used to feel like there is something wrong with that but i guess its the lesser of two evils :P |
| 04:47.51 | JeffM | you can't just wish for a refactoring |
| 04:48.02 | JeffM | there isn't another evil |
| 04:48.07 | JeffM | what other choice do you have? |
| 04:48.17 | apeman_ | the evil is the current structure |
| 04:48.35 | JeffM | it won't magically become better |
| 04:48.39 | apeman_ | the evil you choose is to make it "worse" and eventually better |
| 04:48.51 | JeffM | it dosn't actualy get bad |
| 04:49.13 | JeffM | it just gets slightly more confusing as you have to look in 2 places for a thing instead of one |
| 04:49.46 | JeffM | but usualy it's nicer that you have the nee clean codebase |
| 04:50.08 | JeffM | even if it's only for part of it |
| 04:50.37 | JeffM | and if you get a bunch of people to work on it in parts it goes pretty fast |
| 04:52.07 | apeman_ | nee? |
| 04:52.13 | JeffM | new |
| 04:53.35 | apeman_ | how does one sign up? |
| 04:54.09 | JeffM | sign up? |
| 04:55.35 | apeman_ | to get svn commit permissions |
| 04:55.47 | JeffM | you don't |
| 04:55.51 | JeffM | you are asked |
| 04:56.07 | JeffM | and we arnt'really doing dev work in svn anymore |
| 04:59.00 | JeffM | the general procedure is to submit some patches/pull requests |
| 05:01.53 | JeffM | we are also pondering a developer agreement for pushes to the githup |
| 05:03.28 | apeman_ | whats the developer agreement |
| 05:04.30 | JeffM | bassicly you agreeing that you grant the project an unrevocable license to all submitions and that nothing you do is patented |
| 05:05.04 | JeffM | it prevents developers from causing problems to the project later down the road |
| 05:06.23 | JeffM | this is the one we are pondering, https://docs.google.com/document/d/1B-kj3BeFhFghYjIQ6dC81tfLf-ldUYQHOhMPv16Ykmw/edit |
| 05:19.47 | *** join/#bzflag randomparticle (~random.pa@109.144.133.235) |
| 05:20.29 | randomparticle | #jo |
| 05:21.05 | *** join/#bzflag randomparticle (~random.pa@about/essy/snick/randomparticle) |
| 05:27.14 | randomparticle | *whistles* |
| 05:27.48 | JeffM | crickets |
| 05:39.00 | *** join/#bzflag Gnurdux (~gnurdux@c-67-186-57-145.hsd1.pa.comcast.net) |
| 06:26.25 | *** join/#bzflag TD-Linux (~TD-Linux@about/essy/indecisive/TD-Linux) |
| 06:29.27 | alezakos | drizzo4shizzo: SVN tags are fully integrated into the github repo |
| 06:37.28 | *** join/#bzflag jcp (~quassel@bzflag/contributor/javawizard2539) |
| 06:45.20 | *** join/#bzflag Marzipan (~Marzipan@sign-4db603eb.pool.mediaWays.net) |
| 06:45.23 | *** join/#bzflag mdskpr (~quassel@li59-174.members.linode.com) |
| 06:45.23 | *** join/#bzflag allejo (~allejo@li59-174.members.linode.com) |
| 06:45.23 | *** join/#bzflag allejo (~allejo@unaffiliated/allejo) |
| 06:50.40 | *** join/#bzflag dcat (~dcat@c-98-244-106-246.hsd1.va.comcast.net) |
| 06:50.58 | *** join/#bzflag short_circuit (~james@c-76-30-94-74.hsd1.tx.comcast.net) |
| 07:20.26 | *** join/#bzflag JeffM__ (~JeffM@cpe-76-167-236-199.socal.res.rr.com) |
| 07:43.29 | blast007 | found one possible import glitch: https://github.com/bzflag-dev/bzflag/tree/experimental |
| 07:46.54 | blast007 | same with these: https://github.com/bzflag-dev/bzflag/tree/release_maint https://github.com/bzflag-dev/bzflag/tree/summer_of_code |
| 07:47.26 | blast007 | and then several of the branches don't show any files (some of which are the summer_of_code ones that had been moved to a subdirectory) |
| 08:29.32 | blast007 | and does it matter that we have some things that show up as both a tag and a branch? v1_8 for example. |
| 10:05.42 | *** join/#bzflag swigg__ (~swigg@68-119-228-196.dhcp.ahvl.nc.charter.com) |
| 11:20.50 | joevano | blast007: they are both tags and branches in the SVN, we can remove one or the other easily |
| 11:26.35 | joevano | as for experimental... I see code even on github in that branch, could you explain what you mean? |
| 11:27.15 | joevano | saame with GSOC |
| 11:29.13 | blast007 | joevano: each of the things under experimental should be their own branch |
| 11:29.29 | blast007 | and the same with the other two I listed |
| 11:32.53 | blast007 | there were all once located within SVN's /branches/ directory, but then we reorganized /branches/ to have subdirectories like experimental, release_maint, and summer_of_code and moved stuff that was in /branches/ to one of those subdirectories. |
| 11:33.14 | blast007 | additionally, the gamestats_live stuff is not BZFlag game code. It's a stats website. |
| 11:36.01 | blast007 | s/stuff/branch/ |
| 11:46.50 | *** part/#bzflag Rounin (17572@rubin.ifi.uio.no) |
| 12:36.59 | *** join/#bzflag Rob5a (~Rob5a@cable-95-168-156-46.cust.telecolumbus.net) |
| 12:42.20 | *** join/#bzflag Pimpinella (~frank@gondolin.pimpi.org) |
| 12:48.18 | joevano | ah.. ok I understand.. I *think* I can make that happen |
| 13:47.36 | *** join/#bzflag JeffM (~JeffM@cpe-76-167-236-199.socal.res.rr.com) |
| 13:47.37 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 13:47.37 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 14:37.49 | *** join/#bzflag RAThomas (~chatzilla@r74-195-235-60.stl1cmta01.stwrok.ok.dh.suddenlink.net) |
| 14:38.18 | RAThomas | Riot FFA map bug - minor: |
| 14:38.20 | RAThomas | http://imagebin.org/263673 |
| 14:39.11 | RAThomas | ahs3-: ping ^ msg ^ |
| 14:41.13 | blast007 | RAThomas: referring to the ground showing through just to the upper right of the radar? |
| 14:42.56 | blast007 | heh, I see it as well |
| 14:43.55 | blast007 | seems to be some box positioned there with some wacky options |
| 14:45.38 | ahs3- | RAThomas: its a hidden box to cover a tele |
| 14:46.03 | ahs3- | which blocks all render behind it |
| 14:47.55 | ahs3- | well render of objects anyway |
| 14:48.01 | ahs3- | such as the tele inside |
| 14:49.03 | ahs3- | Done like this: http://pastebin.com/1MPCvKVP |
| 15:26.11 | *** join/#bzflag blast (~blast@bzflag/developer/Blast) |
| 15:26.11 | *** mode/#bzflag [+v blast] by ChanServ |
| 15:39.02 | *** join/#bzflag ashvala (~ashvala@unaffiliated/ashvala) |
| 16:41.59 | RAThomas | ahs3-: so it's on purpose? |
| 16:46.10 | *** join/#bzflag JeffM (~JeffM@cpe-76-167-236-199.socal.res.rr.com) |
| 16:46.10 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 16:46.10 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 17:06.15 | ahs3- | yes |
| 17:38.54 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 17:53.14 | *** join/#bzflag ashvala (~ashvala@unaffiliated/ashvala) |
| 18:19.32 | *** join/#bzflag swigg (~swigg@bzflag/player/Swigg) |
| 18:23.23 | *** join/#bzflag randomparticle (~randompar@cpc3-wilm2-2-0-cust630.1-4.cable.virginmedia.com) |
| 18:23.23 | *** join/#bzflag randomparticle (~randompar@about/essy/snick/randomparticle) |
| 18:30.24 | *** join/#bzflag JeffM (~JeffM@cpe-76-167-236-199.socal.res.rr.com) |
| 18:30.24 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 18:30.24 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 20:25.51 | *** join/#bzflag JeffM (~JeffM@cpe-76-167-236-199.socal.res.rr.com) |
| 20:25.52 | *** join/#bzflag JeffM (~JeffM@unaffiliated/jeffm2501) |
| 20:25.52 | *** mode/#bzflag [+v JeffM] by ChanServ |
| 21:13.16 | allejo | any thoughts as to why autogen.sh would fail with autoheader exiting with status 1? http://pastebin.com/v9qqw7wu |
| 21:31.02 | *** join/#bzflag dcat (~dcat@c-98-244-106-246.hsd1.va.comcast.net) |
| 21:35.15 | blast007 | allejo: does autogen.sh work with a clean checkout? |
| 21:42.18 | allejo | nope |
| 21:43.44 | allejo | well err. not on mofo. on other servers the clean checkout works fine |
| 21:43.52 | allejo | the trunk isn't borken |
| 21:43.57 | allejo | broken* |
| 21:44.26 | blast007 | probably some older tools on that red hat system |
| 21:45.27 | allejo | that's what i figured, did seem like yum had any updates though |
| 21:45.41 | blast007 | here's what I have: Found GNU Autoconf version 2.68, Found GNU Automake version 1.11.3, Found GNU Libtool version 2.4.2 |
| 21:46.40 | allejo | ah yea, red hat tools are a few versions behind |
| 21:53.12 | blast007 | I dunno why that is the only instance of AC_DEFINE that has two sets of brackets around the variable and value... |
| 21:53.19 | blast007 | BulletCatcher: any thoughts? |
| 21:57.21 | blast007 | seems that is called double quoting, and I do see it mentioned in the 2.63 autoconf documentation |
| 21:58.47 | blast007 | allejo: did you sacrifice the goat before running it? |
| 22:01.19 | allejo | err.... I sacraficed a sheep instead, couldn't get my hands on a goat :-/ |
| 22:01.33 | allejo | sacrificed& |
| 22:01.35 | allejo | * |
| 22:03.20 | blast007 | ah, well there's your problem. |
| 22:04.05 | allejo | I didn't think that'd be an issue :( Where can I get a goat? |
| 22:06.49 | blast007 | local zoo |
| 22:07.14 | JeffM | I sell good goat, very cheap, very clean, 100$! |
| 22:07.46 | JeffM | Give me money now, meet cousin out back later |
| 22:08.08 | allejo | lol |
| 22:20.10 | blast007 | anyone know a good method to take a text file (in this case, HTML and maybe JavaScript) with special syntax and a set of language files and spit out localized copies of the file? |
| 22:20.57 | blast007 | wanting something I could essentially use as a build system to "compile" the final HTML files |
| 22:21.31 | blast007 | finding lots of ways to localize strings from within an application, but not exactly what I'm looking for |
| 22:22.11 | blast007 | I could actually do it with PHP, I suppose. |
| 22:24.04 | *** join/#bzflag swigg_ (~swigg@68-119-228-196.dhcp.ahvl.nc.charter.com) |
| 22:26.24 | blast007 | or, maybe someone could just tell me that my design idea is bad. ;) Looking at making the new services UI a set of static HTML files, and then using JavaScript and XMLHttpRequests to pull/push any dynamic data. |
| 22:26.59 | blast007 | I would make POST/GET requests via XMLHttpRequest to a PHP backend script |
| 22:29.35 | allejo | blast007, why not ask nn for help? :p |
| 22:29.47 | blast007 | And I want to have the UI support multiple languages through translation files. Maybe it'd just be better/easier to have the pages be dynamic and do all the localization in PHP. |
| 22:29.58 | blast007 | ~cluebat allejo |
| 22:29.58 | infobot | ACTION pulls out a ClueBat (tm) and thwaps allejo. |
| 22:30.27 | allejo | hehe |
| 22:33.46 | blast007 | Dunno if Google would rank us lower if we had the same pages in multiple languages on different URLs. |
| 22:39.26 | *** join/#bzflag brad (~brad@78.129.242.122) |
| 22:40.30 | BulletCatcher | allejo: I have a RHEL6 system I can test on when I get some time. |
| 22:40.32 | BulletCatcher | Meanwhile, changing it from double to single square bracket quotes ought to fix it. |
| 23:01.08 | allejo | BulletCatcher, wait changing which double square brackets to single brackets? the linces specified in the errors? |
| 23:01.47 | blast007 | assuming the AC_DEFINE line that would define USE_TR1 |
| 23:06.33 | allejo | the single brackets did it :D |
| 23:06.37 | allejo | thanks blast007 and BulletCatcher |
| 23:52.13 | *** join/#bzflag brad (~brad@78.129.242.122) |