| 00:05.05 | macsforme | the reason for a breaking branch is that we already have some gameplay-altering stuff in 2.5 that needs a place to live |
| 00:06.30 | macsforme | plus, when we think of something that needs to be changed in the next protocol break, it would be able to just do it and stick it somewhere, so when the next protocol break comes we're not scratching our heads trying to remember what we wanted to do |
| 00:09.28 | *** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net) |
| 00:12.47 | JeffM | a grabbag of features you may pick up and eventualy do integration testing on? |
| 00:14.16 | blast007 | macsforme: and why is 'master' not a proper place for breaking changes? |
| 00:14.21 | macsforme | is that any different from any of the rest of our contributions? :P |
| 00:18.15 | macsforme | tha names don't really matter (okay, so maybe "master" should be where most of the new development goes, which isn't the case) |
| 00:19.20 | macsforme | what I want is a place to work on deep refactoring and improvements while keeping compatibility with 2.4 so I can test my stuff |
| 00:22.16 | blast007 | sounds like a good use for a fork with branches |
| 00:27.03 | macsforme | that's fine, but the main repository still has nowhere for the new code to go, once it is ready to merge in |
| 00:28.19 | macsforme | you've already said you don't want certain deep changes made to 2.4, and if we put it into 2.5 then who knows if it will ever be used, and we have 2.99 all over again |
| 00:32.20 | macsforme | allejo: hmm, I don't get that warning on 10.10 |
| 00:34.00 | blast007 | 2.99 stalled because there were bad changes put in that were not caught or tested enough after they were put in, which made it completely unplayable |
| 00:34.27 | blast007 | had it not been for it being unplayable, 2.99 probably would have been release worthy |
| 00:36.56 | macsforme | well said :P |
| 00:37.03 | macsforme | we should put that as a quote in the topic |
| 00:37.43 | macsforme | being "unplayable" is kind of a big (and complex, in this case) problem |
| 00:38.25 | BulletCatcher | I have no objection to "deep" changes to the 2.4 branch as long as they don't change the protocol or gameplay. |
| 00:38.28 | blast007 | but it's something that should have been caught in testing |
| 00:42.38 | macsforme | so if we have to push out another release, we would branch off from the 2.4.8 tag into a 2.4.10_release (or similar) branch, and apply the limited changes to that? |
| 00:43.23 | macsforme | then tag it, bump the version again, and then we can merge that back into 2.4? |
| 00:43.46 | blast007 | I don't follow. why would we branch from a tag? |
| 00:44.19 | macsforme | because 2.4 will be unstable |
| 00:44.32 | blast007 | why would 2.4 be unstable? |
| 00:44.33 | macsforme | I'm presuming any further 2.4 releases will have minor fixes only |
| 00:44.50 | BulletCatcher | http://nvie.com/posts/a-successful-git-branching-model/ has a well thought out methodology that we could consider. |
| 00:44.51 | BulletCatcher | I don't necessarily endorse it for BZFlag. |
| 00:44.54 | macsforme | if we made "deep" changes to it |
| 00:45.25 | blast007 | you're not making "deep changes" to the 2.4 branch, you're making them to a feature branch |
| 00:45.48 | blast007 | a feature branch that is forked (or whatever the term is) from the 2.4 branch |
| 00:46.08 | macsforme | I was following up on BulletCatcher's statement |
| 00:46.44 | blast007 | well you wouldn't put large breaking changes directly into 2.4 |
| 00:46.50 | blast007 | that should always be in a buildable state |
| 00:47.26 | macsforme | BulletCatcher: yeah, I've seen that... it was a good inspiration |
| 00:47.36 | blast007 | that's why you do feature branches. to keep half-done features out of your normal branches, so that if you have an immediate need to do a release, you can. |
| 00:49.26 | blast007 | I don't believe we've done anything big enough to warrant a feature branch since we moved to git, but if we're going to do major refactoring it'd be a good idea to start |
| 00:52.36 | macsforme | SDL2 was in a feature branch, although it was just a local one |
| 00:56.54 | macsforme | Tim said once that the major/minor version number is not just tied to a protocol version... so if we made a bunch of big changes, including visual ones, and the game then looks nothing like it does now, we wouldn't release that as a point release, would we? |
| 00:57.31 | macsforme | that would be at least a new minor version release |
| 01:03.47 | BulletCatcher | If the visual changes don't affect gameplay then I wouldn't necessarily see a need for a new minor version number, but we could make that decision when we have a non-hypothetical situation. |
| 01:05.58 | blast007 | well, if we're doing something like changing from requiring OpenGL 1.2/1.3 to 3.0, then that might be a thing to wait for a major release ;) |
| 01:06.59 | macsforme | so where would that code go? |
| 01:07.32 | blast007 | a feature branch based on master |
| 01:07.41 | JeffM | do you expect that change to be done by one person or multiple? |
| 01:09.03 | macsforme | based on master... so we are back to the original problem, where nobody wants to develop for a branch that may never see the light of day |
| 01:10.29 | macsforme | JeffM: it depends... probably each big change would be primarily the work of one person, but others would collaborate by building, testing, making suggestions, etc. |
| 01:10.45 | blast007 | then that just means there isn't enough interest to continue development |
| 01:11.14 | JeffM | I'd expect a person to work in a local fork attached to there account then merge in when it was tested. |
| 01:11.50 | macsforme | merge it in where? that's the issue |
| 01:11.52 | JeffM | the sugestions I've seen are "fork, make a feature branch in your fork, do work, test, then do a pull request against your forked brancH" |
| 01:12.20 | JeffM | then if you are a project dev, you merge your own pull request into whatever version line it will be released in |
| 01:12.25 | macsforme | I 100% agree on using a branch in your personal fork for big changes (we have had several of these already) |
| 01:13.17 | macsforme | but I don't think we have an appropriate branch in our main repository for these kinds of changes to be merged |
| 01:13.24 | JeffM | I think the big thing you are sugesting is that there will still be two "active" codebases for new non maintennace changes, a current release compatible and an incompatible one, right? |
| 01:14.06 | macsforme | yes |
| 01:14.08 | JeffM | and then a critial bug fix section for "oh noes there is a vulerabiity in curl again" |
| 01:14.50 | JeffM | if someone puts something into the rellease compatible codebase, are they also responsible for merging it into the incompatiable one? |
| 01:15.51 | macsforme | the incompatible branch doesn't have to be touched, except with changes that specifically require a protocol break |
| 01:16.14 | JeffM | so when the time comes to publish that incompatible branch, how do you merge it all? |
| 01:17.05 | macsforme | you would rebase the incompatible branch onto the compatible branch, and we have our next major version |
| 01:17.15 | JeffM | with a ton of untested code |
| 01:17.20 | JeffM | and code interactions |
| 01:17.29 | JeffM | and who does that merge? |
| 01:18.54 | macsforme | most of the changes requiring a protocol break so far are very minor... I'm looking for an example |
| 01:18.56 | JeffM | at work, we maintain 2 main codelines like you talk about. Once a month we go and do bug fixes and small enhancments to our current shippint versions. then for the other 3 weeks we work on new stuff. But when we make changes to the shipping branch, we also dupe the changes in the development branch, so the dev branch is never "behind" the release one. |
| 01:19.10 | JeffM | so it's always testable |
| 01:19.24 | JeffM | it may have bugs in new code, but it isn't missing features that the shipping one has. |
| 01:20.07 | JeffM | I understand paid development is different, but it doesn't seem right to have a branch that has "new stuff" but is missing what would feel ike "old stuff" that the shipping version has. |
| 01:20.40 | JeffM | just my opinion |
| 01:21.12 | BulletCatcher | Another approach, which would make JeffM happier, is to merge the compatible branch onto incompatible as often as desired (we already do this). |
| 01:21.13 | BulletCatcher | That way the incompatible branch can get more realistic testing before we decide to release it. |
| 01:21.16 | macsforme | sure, but we are kind of doing that already... we only merge 2.4 into master when someone feels like it |
| 01:21.19 | JeffM | I just know from experience that the rebase is going to be hell, and the people that worked on those features will be gone, and you won't be able to ask "how was that supposed to work again?" |
| 01:21.34 | JeffM | BulletCatcher: yes that was going to be my next sugestion |
| 01:21.47 | JeffM | and you don't have to make me happy, I'm just poiting out things I've experienced. |
| 01:22.14 | JeffM | macsforme: so you are really just sugesting that the senses of what is "master" change? |
| 01:25.16 | macsforme | merging the protocol-breaking stuff into the protocol-compatible stuff is going to be a mess, regardless of how that is done... whether merging one outdated branch into another, or trying to accept a bunch of pull requests that now have conflicts with your code because stuff has changed |
| 01:26.06 | blast007 | feature branches should have a narrow focus and a short lifespan |
| 01:26.06 | JeffM | yes all of those care crappy ways of doing it, merging with each commit is way cleaner, then you don't get the "old" part in there. |
| 01:26.14 | blast007 | get the work done, test, merge, done |
| 01:26.33 | JeffM | goes git have a "duplicate changes" function? |
| 01:26.58 | JeffM | we use that in our VCS, when I check in a change to the shipping stuff, I can tell it to try an automatic merge into our dev |
| 01:27.04 | JeffM | if there is no confilct it just happens. |
| 01:27.05 | macsforme | JeffM: I suppose... I was suggesting that master be reset to the current 2.4, and that breaking changes be preserved somehow (I don't really care how)... but it sounds now like people might be okay with significant changes being made in 2.4 |
| 01:27.26 | blast007 | why would we reset master to the current 2.4? |
| 01:27.30 | macsforme | I was going off of comments like this: https://github.com/BZFlag-Dev/bzflag/issues/5#issuecomment-112992332 |
| 01:27.54 | blast007 | you realize there are barely any changes in master |
| 01:28.11 | JeffM | if you had a good update system you could do rolling releases :) |
| 01:30.12 | macsforme | blast007: because you said you didn't want major changes done in 2.4, and I am unmotivated to work in the current master because you can't test your work on the current protocol |
| 01:30.33 | blast007 | macsforme: that's not the point I was making |
| 01:30.45 | blast007 | resetting master to 2.4 is silly because it's not that much different |
| 01:31.07 | JeffM | he wants master to be proto compatible |
| 01:31.19 | blast007 | that's silly |
| 01:31.29 | JeffM | that is his entire point |
| 01:31.43 | JeffM | keep banging away on a compatible update |
| 01:33.13 | JeffM | does anyone ever use the "SHEAR" transform? |
| 01:35.33 | macsforme | blast007: that's not a constructive retort... perhaps you could explain why you think so |
| 01:36.13 | macsforme | I'm trying to give people (primarily myself) a place to do the major work that this game needs so badly, while still being able to actually see them and use them |
| 01:37.00 | blast007 | you know how we used to do stuff in the old days? we ran bleeding edge development servers had had people play on them |
| 01:37.14 | blast007 | a Friday game of Decks |
| 01:37.44 | blast007 | release a client build, get people to install it, play together, report issues |
| 01:38.22 | macsforme | the old days are no more |
| 01:38.57 | macsforme | we can't even get some people to update to the latest official release, much less help us test development builds |
| 01:39.23 | *** join/#bzflag spldart (~spldart@bzflag/contributor/spldart) |
| 01:39.23 | *** mode/#bzflag [+v spldart] by ChanServ |
| 01:39.33 | blast007 | how do you know? we haven't had development builds of a new incompatible build because we haven't put anything into an incompatible build |
| 01:39.45 | blast007 | they certainly test the RC builds |
| 01:40.54 | blast007 | we don't need 100 people on the dev versions to test. 5 to 10 is enough for testing. |
| 01:41.21 | blast007 | if you don't think we can muster up 10 players, then just call it. |
| 01:41.33 | allejo | I'm with macsforme on this on wanting a place to be able to work on and have the ability to test things. the things I want to test/work on aren't visual or directly affect the players so RCs of dev builds wouldn't give the features the exposure/testing it needs. for example, my things are API/server relating; one thing that not many people do anymore |
| 01:41.37 | macsforme | because I have been on servers, asking people to test RC builds, and it is rare that they do (at least in the league sphere, where the last skilled players congregate) |
| 01:44.11 | macsforme | yeah, allejo summed it up well... although I would personally focus on different priorities than his |
| 01:46.37 | allejo | well duh, i have my own interests :) |
| 01:46.57 | blast007 | allejo: I don't see how that prevents testing it on an incompatible release |
| 01:47.26 | blast007 | you'd be running the server with the server/API changes, and you get some people to play on it to test |
| 01:52.00 | allejo | i don't know. the motivation for 2.6 is hardly there so i doubt it'll see a release. i wouldn't really want to work on something that wouldn't even see a release |
| 01:52.27 | macsforme | because it is far easier to test when you have a large pool of regular players to test on |
| 01:52.37 | macsforme | for science! |
| 01:52.42 | JeffM | so just a few more 2.4.x thigns before bzflag dies? or do you think focusing on compaibility will bring people back so that 2.6 can evetualy be released? |
| 01:52.53 | allejo | there were more players when the 2.0 to 2.4 transition happened and that took a while. i'm just worried about how long it'll take for another protobreak to happen and how that'd split the current small player base |
| 01:53.39 | spldart | I don't think releases has anything to do with the wane of popularity. |
| 01:53.39 | blast007 | just block 2.4 servers from listing |
| 01:53.44 | macsforme | JeffM: we just want to do the majority of the work within the current protocol |
| 01:53.45 | blast007 | forced migration |
| 01:54.12 | JeffM | macsforme: so 2.4 is the protocol forever or just until the project gets back on it's feet? |
| 01:54.32 | macsforme | the latter |
| 01:54.51 | JeffM | so really you just want to shelve incompatible development |
| 01:55.12 | spldart | looks for some really good shoes for the project. |
| 01:55.29 | JeffM | and you feel that requires renaming branches |
| 01:56.06 | allejo | i think it requires being able to pull in large changes without a protobreak |
| 01:56.10 | JeffM | renam master to "we'll get back to you" and rename 2.4.x as master and snap off a critical update branch |
| 01:56.59 | macsforme | JeffM: what I care about is having a place where I can do major refactoring work while keeping compatibility with 2.4... I don't really care about incompatible development, except that those few changes that affect gameplay are stashed somewhere for later |
| 01:57.10 | macsforme | yes, what allejo said |
| 01:57.41 | JeffM | sure, and you want that place to be in some kind of "master" repository not a local fork |
| 01:57.55 | macsforme | yes |
| 01:58.09 | blast007 | so make it a public fork on github |
| 01:58.14 | JeffM | and you don't want to push that refactoring work into another branch |
| 01:58.37 | JeffM | so that effectvly forces everyone else to do compatible work, or create a huge mess, or contually merge your changes |
| 01:59.01 | macsforme | you mean pushing my changes into the incompatible branch too? |
| 01:59.19 | JeffM | any other branch other than the one you are working on |
| 01:59.37 | JeffM | lets say blast is working in the incompatible one |
| 01:59.51 | JeffM | you won't make sure your changes work in the incompatible one |
| 02:00.00 | JeffM | so the onus would be oh him to rebase |
| 02:00.22 | JeffM | so I could see how you'd be forcing him to not want to do any imcompatible work and only work in your branch |
| 02:01.11 | JeffM | it may be better as a project to just tell EVERYONE to shelve incompatible work |
| 02:01.19 | JeffM | so efforts arn't being divided |
| 02:02.16 | macsforme | I would rebase breaking onto my stuff if someone wanted me to... if there was significant work being done in breaking as well, and it would benefit from a rebase so stuff doesn't get out of sync, I would have no problem doing that |
| 02:02.45 | JeffM | that's why at work, we force people to push to both branches if you start in the lower one |
| 02:02.49 | macsforme | but nobody is working on the incompatible branch, other than a few changes here and there that actually require a protocol break (and occasionally someone merges 2.4 into master) |
| 02:03.29 | JeffM | you are making the 2.99 argument for 2.5 |
| 02:04.39 | macsforme | that's because blast007 is suggesting that my work should go into 2.5, which then (to me) would seem like a repeat of 2.99 |
| 02:05.06 | blast007 | no, it would be like a repeat of 1.9 or 1.11 |
| 02:05.13 | JeffM | sure this is how the @#!&Can dev discussions always start |
| 02:05.37 | JeffM | 2,99 was a bit too much, but it's not the first time a branch has been abandoned |
| 02:05.51 | JeffM | 1.8, etc.. |
| 02:07.01 | macsforme | I don't think I came along until 2.0-ish |
| 02:07.55 | JeffM | yeah you are not the first person to sugest abandoning a branch because it's imcompatbile, nobody's working in it, how do we test? we don't have enough players etc.... |
| 02:08.42 | JeffM | at some point you'l mention that "we can just pull the things that are ready from 2.5 into 2.4" |
| 02:08.47 | JeffM | that's how BZDB got made |
| 02:09.21 | JeffM | it is a rather traditional BZFLag response to stagnating development |
| 02:09.49 | macsforme | perhaps I am not explaining myself clearly... I don't really care about "abandoning" the incompatible branch (all I was asking is that we rename it) |
| 02:09.59 | JeffM | sure I know |
| 02:10.12 | blast007 | why rename it though? it's not like we're doing anything with it anyway |
| 02:10.15 | JeffM | but if you start refactoring another branch, then that code will basicly GET abandoned |
| 02:10.24 | JeffM | it'll get too out of sync |
| 02:10.31 | blast007 | so sync it |
| 02:10.36 | blast007 | it's not hard |
| 02:10.43 | JeffM | it isn't if you do it as you work |
| 02:11.02 | blast007 | no, it's still not that bad, because there are barely any changes in master |
| 02:11.14 | JeffM | there is nothing saying you guys can't refactor in the current 2.4 branch |
| 02:11.35 | JeffM | I'd just say merge it up with each commit too |
| 02:11.38 | macsforme | yes, there is... I linked to one comment already |
| 02:12.06 | JeffM | ok so you need people to accept the big changes |
| 02:12.19 | macsforme | https://github.com/BZFlag-Dev/bzflag/issues/5#issuecomment-112992332 |
| 02:12.20 | JeffM | renaming the branches won't change that policy |
| 02:12.35 | macsforme | right |
| 02:12.49 | JeffM | the idea of a risky commit and wanting to put it in a breaking release is still valid if the compatible release is named master or not |
| 02:12.50 | blast007 | "This branch is 65 commits ahead, 60 commits behind 2.4." |
| 02:13.13 | JeffM | blasts statement would still be valid "I don't want this in this protocoll" |
| 02:13.26 | JeffM | that statment is independent of branch names |
| 02:13.45 | macsforme | major refactoring will require many "risky commits" |
| 02:13.55 | blast007 | feature branch. |
| 02:14.08 | JeffM | so this is why I say what you REALY want is a loosening of those restrictions, and to basicly shelve 2.5 in order to focus on risky but compatible things |
| 02:14.32 | JeffM | you want to PLAN on more 2.4.x releases with more features |
| 02:14.40 | JeffM | not just security patches |
| 02:15.40 | macsforme | yeah, basically... the eventual release could be a 2.4.x, or we could decide it was time for a new number, but it would stay 2.4 until that decision is made |
| 02:16.52 | JeffM | large scale refactorings in a feature fork can suck too, because at some point you are going to have a massive code drop that people won't follow |
| 02:16.56 | JeffM | and you end up with 2.99 |
| 02:17.20 | JeffM | you don't have a lot of developers, you need all of them to kinda be working tward the same goal. |
| 02:19.51 | macsforme | the commit history in master is going to be messy if every other commit is a merge :P unless most of them can be done as fast-forwards |
| 02:20.29 | JeffM | it'd be more granular than a code dump |
| 02:22.05 | macsforme | blast007: I think you and I agree that the major work would be done in feature branches, until tested and determined to be semi-stable... I think where we disagree is where it would be merged in after that (I want it in 2.4, and you want it to go into master)... is that accurate? |
| 02:24.31 | BulletCatcher | I am not concerned about "code dumps" and messy commit histories if allowing those things will make developers feel free to do good work. |
| 02:25.13 | BulletCatcher | What is clearly important is ongoing testing as changes are made. |
| 02:25.29 | spldart | :) |
| 02:26.16 | BulletCatcher | If we get to the point where we think we want to do an incompatible release, we focus on getting more testers and iron out the bugs. |
| 02:27.51 | BulletCatcher | It has been over 5 years since our last incompatible release, so it isn't too soon for another one provided that players will see a real benefit. |
| 02:30.15 | BulletCatcher | If someone has a workable idea for a nice incompatible change, we ought to be able to promise a release with it when it is done. |
| 02:38.41 | JeffM | allejo: https://github.com/JeffM2501/UnityBZWTools/releases/tag/alpha_0.0.05.110416 it has the teleporter side glyphs you asked for |
| 02:38.54 | allejo | yay! |
| 02:39.47 | JeffM | gotta think about how to represent mesh transforms now |
| 02:43.45 | *** mode/#bzflag [-v short_circuit] by ChanServ |
| 09:05.12 | *** join/#bzflag margaux (uid194008@gateway/web/irccloud.com/x-spnvskcutbtvzsse) |
| 11:43.41 | *** join/#bzflag margaux (uid194008@gateway/web/irccloud.com/x-nobselfsbpeexqnc) |
| 11:51.48 | *** join/#bzflag rhubalacapricato (uid195193@gateway/web/irccloud.com/x-nkmauuwuafwndnwi) |
| 12:11.18 | blast007 | macsforme: I want incompatible changes to go into master |
| 12:11.51 | blast007 | if you're doing something that is compatible with 2.4, it could go into 2.4 |
| 12:12.20 | blast007 | but you were making it sound like you wanted to develop incompatible changes against 2.4 so you could test them with 2.4's playerbase |
| 12:23.30 | *** mode/#bzflag [+v spldart] by ChanServ |
| 15:05.11 | macsforme | sigh |
| 15:53.43 | *** join/#bzflag spldart (~spldart@bzflag/contributor/spldart) |
| 15:53.43 | *** mode/#bzflag [+v spldart] by ChanServ |
| 16:02.13 | macsforme | JeffM: are those soft shadows in your editor? |
| 16:02.19 | JeffM | yes |
| 16:02.24 | JeffM | volumetric too |
| 16:02.49 | macsforme | nice |
| 16:02.57 | JeffM | yeah they look pretty good |
| 16:11.30 | JeffM | I tried to do global illumination and ambient occlusion but it takes a very long time to bake in |
| 16:11.51 | JeffM | the algorighms arn't a fan of all the overlaping geometry of a bzflag map |
| 16:13.48 | macsforme | it would be cool just to see it once :) |
| 16:14.04 | macsforme | for the potential |
| 16:14.20 | JeffM | I'd need a map simpler than hix, something with less overlaping geometry. |
| 17:05.35 | JeffM | you'd need a lot more data in the map format to do baked GI in bzflag, and you'd probalby loose the ability to do dyanmic sky |
| 18:30.46 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 18:35.27 | *** mode/#bzflag [-v short_circuit] by ChanServ |
| 19:18.42 | macsforme | does windows use the resource.h in include/ or in MSVC/ ? |
| 19:31.22 | JeffM | the one in MSVC is a VC generated regular native resource header |
| 19:31.41 | JeffM | the one in include looks to be hand made and just has the icon #def |
| 19:31.58 | JeffM | does anything in the code call IDI_BZICON ? |
| 19:33.13 | macsforme | there are a few calls to LoadIcon(hInstance, MAKEINTRESOURCE(IDI_BZICON)) in WinDisplay.cxx |
| 19:33.20 | macsforme | that's it |
| 19:33.34 | JeffM | ahh pobably for the window caption bar |
| 19:33.40 | JeffM | you could probalby combine them |
| 19:33.58 | JeffM | is IDI_BZICON also in msvc/resource.h ? |
| 19:34.01 | macsforme | the one in MSVC already contains that definition |
| 19:34.21 | macsforme | yes |
| 19:34.32 | JeffM | yeah, then it's just making sure that MSVC is in the include paths for the windows build, then you can delete the one in inclue |
| 19:34.51 | macsforme | k, thanks |
| 19:35.02 | JeffM | I live to serve |
| 19:35.28 | macsforme | :) |
| 19:35.42 | JeffM | it's better than serving to live |
| 20:23.49 | *** join/#bzflag spldart (~spldart@bzflag/contributor/spldart) |
| 20:23.49 | *** mode/#bzflag [+v spldart] by ChanServ |
| 20:40.15 | *** part/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 20:41.00 | *** join/#bzflag Zehra (~Zehra@unaffiliated/zehra) |
| 20:54.03 | *** join/#bzflag alt1 (~Thunderbi@5-49-223-62.hfc.dyn.abo.bbox.fr) |
| 21:29.11 | *** join/#bzflag [Gort] (~gort@82-69-126-225.dsl.in-addr.zen.co.uk) |
| 21:29.11 | *** join/#bzflag [Gort] (~gort@unaffiliated/gort/x-9231432) |
| 21:51.35 | *** part/#bzflag alt1 (~Thunderbi@5-49-223-62.hfc.dyn.abo.bbox.fr) |
| 22:08.01 | *** join/#bzflag EJnzrVfSXBCrI (~EJnzrVfSX@189.54.225.54) |
| 22:08.10 | *** part/#bzflag EJnzrVfSXBCrI (~EJnzrVfSX@189.54.225.54) |
| 23:40.41 | macsforme | the buildVC2010 script in bzflag-dependencies seems to fail if there are spaces in your path |
| 23:41.20 | macsforme | putting some quotes in seemed to help, but I just ended up moving the directory to the drive root and it built fine from there |
| 23:43.01 | macsforme | I'll open an issue |
| 23:49.02 | JeffM | yeah, msbuild doesn't like paths with spaces unless they are quoted |
| 23:51.30 | macsforme | neither does mkdir or copy |
| 23:51.41 | JeffM | yeah, all the windows command line stuff is like that |
| 23:51.51 | JeffM | quotes around the path is the right thing to do |