vts

Saw these guys at a festival. Bit of a particular style, but I like it.

I'm not aware whether any consensus has already been reached about this, but it seems to me like the way you propose is the better alternative, for one because making units move out of the way first creates pathfinding hazards/nightmares. I also don't think players would particularly mind to have the occasional unit walk "through" a wall gate that's swinging open, but they might mind the opposite: e.g. if at some point they need to retreat quickly but can't open their gates because they have 200 units in the way queueing up in front of the gate.

Indeed, I believe they were discussed on IRC, but I think they should definitely be moved somewhere more prominently visible/available. Helps ensure that everyone has the same understanding of what needs to be done. For the walls implementation, this was a thread in the staff forums, so perhaps we could create a similar public one for the wall gates with any decisions made on how the team envisions for them to work.

Cool, thanks for reporting

Should be fixed as of r11979. HalcyonXIII, can you confirm the fix?

Which revision of the game did/does this happen on, and on which map? When it happens, does it happen straight away after loading a game or only after playing for a little while (even if just a second or so)? Can we have the savegame and the system_info.txt file (see here for where to find it)?

(Now tracking this bug at http://trac.wildfiregames.com/ticket/1495)

Indeed, that's exactly it. Huh, look at that. I've never heard of that feature before Still, I much prefer the cheap, local git branches.

The way merging branches works in SVN is by taking a diff between a starting and ending revision of your branch X, and applying it to your working copy that has a certain revision of the branch T checked out that you want to merge it into (for our purposes the head of the trunk). The tricky thing is that this diff must not include any changes that you have already previously merged back from the trunk into your branch. This effectively means that you need to keep track of the revision where you last did an intermediate merge from the trunk into your branch, or failing that, where you branched off from the trunk. SVN is not really helpful with helping you select the revision range to diff between, and if you select the wrong revision range, your merge has a non-zero chance of failing spectacularly. You're sort of on your own to come up with some scheme to create meaningful markers in your commit messages so you can easily find them. This requires discipline, which I suspect to become increasingly prone to forgetfulness/mistakes as a function of the amount of branches and developers. Git explicitly tracks the parents of each commit, and hence doesn't have this problem. Every time you merge two branches in git, the resulting commit has the tips of both branches at that time set as its parents. When you merge a branch that has been intermediately synced with the trunk ("master") back into the trunk, it needs only trace the parent pointers backwards in time to find the "most recent" common ancestor, and take it from there.

We don't currently have branches on the SVN repository (at least not that I'm aware of). It would somewhat solve the problem, in that you could save your unfinished work to a new branch that you first create, 'svn switch' to, and commit. The problem with that approach, however, is that you now face the problem of sanely merging SVN branches that have had intermediate updates from trunk back into the trunk (which in practice is not quite as easy as it should be). Also, although more minor; we'd end up with a boatload of WIP branches, and you'd be required to have internet connectivity to save your local work in progress. Agreed.

Keeping the C++ away from non-programmers does not sound like it's worth the trouble of splitting the codebase into two separate repositories running two different SCM systems. Couldn't artists just ignore the code if they so please and keep using SVN happily ever after? Your proposal implicitly assumes that the C++ codebase and the binaries are not correlated and can be developed independently, which is most certainly not the case. Javascript code routinely calls C++ code and vice-versa. In your proposed scheme, changes that simultaneously need to modify e.g. both javascript and C++ components would be split out over different commits to different repositories, with no link between them. If something breaks, you then have to search and manually cross-reference two code repositories, and manually combine two diffs to get a global overview of co-dependent changes that were made. This sounds like a nightmare. Also, we would no longer be able to use Trac in the way we use it now, where a single commit can be flagged as solving a ticket (because you might now need two separate commits to fix one issue). The barrier to entry for new developers would also be heightened considerably, which is most certainly not what we want. There are more reasons, but I think you can see where I'm going with this

One major disadvantage of SVN for developers is that it does not allow you to switch between multiple branches locally. I.e., when you've made some changes and midway through you want to work on something else for a while, you have the following options commit your half-finished code to the live repo (not an option) revert your changes and lose them (also not an option) (edit for completeness) create a new remote branch, switch to it and commit them there (also not an option, we don't have branches at the moment) extract your changes into a diff and reapply them when you're done with the other stuff check out an additional working copy to work on the other stuff Neither one is desirable. You either end up with a ton of different working copies (and used disk space), or tending to an entire garden of different patches that you need to version manually as your work progresses. Git is much more flexible in this regard, in that you can safely commit or stash your changes locally to be picked up again where you left off when you're done with the other stuff. It has other advantages and disadvantages, but this alone is sufficient reason for me to prefer it over SVN. I am, however, sympathetic with the need for easy-to-update binaries for artists who don't wish to spend their time rebuilding the game all the time nor have to learn a new, arguably more complicated SCM tool. SVN works well for this, so perhaps we're already doing it in the best way: keep SVN as the official repository, but offer Git as an additional option for those developers who desire it. The only thing that's perhaps missing is automatic synchronization between SVN commits and the Git repo (poke k776)

Some ambient: http://www.youtube.com/watch?v=Qgi5sPB8oik http://www.youtube.com/watch?v=Ld4ucvd2Eo0

There's an issue where the quicksearch field on the top of the page will not search through the staff forums. I created a ticket for it here: http://trac.wildfiregames.com/ticket/1423