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

This is a difficult requirement since there's no telling beforehand where the user might want to place, or indeed whether they want to place one at all. Perhaps what we could do is, instead of upgrading L segments, make gate placement working by dragging a 'ghost' ghate along a wall, and realign the segments/towers upon placement to fit the gate in there. No idea how feasible this is btw, just brainstorming.

http://www.youtube.com/watch?v=f4Ed6SMa2vo

The current implementation of the wall system works with a system of towers and three wall segments of various size ("small" for 2x the width of a tower, "medium" for 4x, and "long" for 6x). It allows the player to place walls across any arbitrary distance by allowing the wall segments to partially protrude into towers, and the amount they protrude can vary between set limits. As such, the towers act a sort of buffer space for the contiguity in the distance across which the player drags the wall. This will probably illustrate more clearly: http://www.voetsjoeba.com/wfg/wall_placement_2.html (click and release and then drag to create a wall). There are some mathematical conditions about the lengths of the towers and the wall segments and the amount of protrusion into towers that need to be satisfied for this to work, but I'm still working on writing them down formally. Regardless though, I don't quite see how a wall made of houses would fit with this system. Your intent is to quickly place multiple buildings, presumably without regard for whether the 'wall' blocks unit movement across its entire distance (because I don't see what you'd use for 'filler space' if a user wants to drag a 'housewall' across a distance of 5 + 1/3 houses). This is an entirely different purpose than what the wall system was designed for, so you'll probably have to write your own implementation anyway.

^ Beta gameplay? Did I pass out and miss 5 alpha releases or something?

Coming back somewhat on my last comment, I think less effort to do something is a sensible reason, but the shift-clicking does have the advantage of having consistent semantics to those of creating units and regular buildings. I suppose it depends on how much you value consistency in the controls over speed of operation. I'll play around with a non-shift-clicked version locally and see if it makes a noticeable difference.

I understand that, but I mean, what kind of visual indicator would you suggest? Like a highlight, an outline, a glow, ...?

The shift-key is also used to give multiple commands, build multiple buildings, build multiple units, so it is entirely consistent for the shift key to also allow you to place multiple walls. I don't see the point in removing it. This is actually only the case for the palisades, which originally weren't intended to be included in the game. They will be updated soon. Do you have a screenshot illustrating the problem? It's not quite clear to me what the problem is exactly. What would you suggest as an indicator?

You can also make a makeshift gate by deleting a wall segment

The templates still need tweaking. I left that up to the people who are more knowledgeable about these things. Gates are not part of this commit. They will be added at a later time.

I've committed the wall patch in revision 11760. Feel free to playtest it and report any bugs you may find