Jump to content


WFG Retired
  • Content Count

  • Joined

  • Last visited

  • Days Won


vts last won the day on June 21 2012

vts had the most liked content!

Community Reputation

4 Neutral

About vts

  • Rank

Profile Information

  • Gender
  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Saw these guys at a festival. Bit of a particular style, but I like it.
  2. 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.
  3. 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.
  4. Should be fixed as of r11979. HalcyonXIII, can you confirm the fix?
  5. 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)?
  6. (Now tracking this bug at http://trac.wildfiregames.com/ticket/1495)
  7. 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.
  8. 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
  9. 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 y
  10. 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++ componen
  11. 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
  12. Some ambient: http://www.youtube.com/watch?v=Qgi5sPB8oik http://www.youtube.com/watch?v=Ld4ucvd2Eo0
  13. 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
  • Create New...