vts
-
Posts
110 -
Joined
-
Last visited
-
Days Won
2
Posts posted by vts
-
-
I'll finish off the models and create the animations if some are needed, but first I need to clarify how gates function. Specifically, when the gate is opening the doors are going to swing out into the open - if something is in the way do the doors just go straight through the object, or do you need to move the object out of the way first.
I believe we may have opted for the doors to become passable (units can walk through the door models) as soon as the doors begin to open. This will help with pathfinding (units won't get stuck behind open doors when trying to walk through the gate) and make gates quicker to implement. Other more complicated functionality can be added afterwards if needed.
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.
-
1
-
-
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.
-
1
-
-
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)
-
-
Isn't that what's described here under "Keeping a Branch in Sync Without Merge Tracking".
Indeed, that's exactly it.
That shouldn't be a problem anymore since subversion 1.5 because it has merge tracking.
Huh, look at that. I've never heard of that feature before
Still, I much prefer the cheap, local git branches. -
What's the important difference compared to commiting a local working-copy and compared to how git does it?
Basically you always have to keep in sync with the changes in trunk.
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.
-
Are braches on the serverside supported for our repository? Wouldn't that solve the problem?
As far as I know it would, but I didn't yet use braches much, so I'm not sure if it works in practice.
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.
You missed one. Use git svn (needs both installed) and you can work with git locally and commit to the svn repo with git svn dcommit.
Apart from that I believe we should just integrate a git sync with trac's post-commit-hook and be done with it.
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)
- commit your half-finished code to the live repo (not an option)
-
-
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
-
On the gates, when setting up a connection between two tower points, could it be set up to favor S>T>M/L>T>S as opposed to what I usually get which is something like M/L>T>M/L? This would make it easier to set up nicely placed gates where we actually want them. Presently I'm just trying to create my mandatory openings right in the center of paths instead of to either side of the path.
@Lion Actually we have gates now, they're just not very gatey. More like a gate shaped wall.
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.
-
-
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?
-
The thing is that it's redundant. You could just build walls in different directions using left-clicks - then cancel with a right-click, as always. Less effort than holding Shift throughout the process. Less effort > redundancy, so these guys do have a point. We should not stick to the Age conventions like glue if they don't really make sense
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.
-
he means the units dont pass between Canyon, cliff, montain etc and a wall structure, the wall must close or blend with a clift.
I understand that, but I mean, what kind of visual indicator would you suggest? Like a highlight, an outline, a glow, ...?
-
100% agree to remove the SHIFT key for continuing walls. With the left/right click it requires no instructions and everyone can find it;
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.
I noticed that foundations are larger than the actual wall (continuing over the limiting towers);
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.
I like the "snap" to connect a wall to another with a tower. However, also due to previous issue, I was able to create a wall with two tower very near one to the other. Interestingly, the space between them was to low to let units pass through, but, funnily, my units and enemy units could fight in between
! Maybe it just would better to use a higher "snap" distance to avoid these "holes";Do you have a screenshot illustrating the problem? It's not quite clear to me what the problem is exactly.
it would be nice to have an indicator somewhat that let you know if the wall are "connected" (either with walls only or also with mountains).
What would you suggest as an indicator?
-
You can also make a makeshift gate by deleting a wall segment
-
2
-
-
why palisade costs stone? costs 30 stone and 30 wood
The templates still need tweaking. I left that up to the people who are more knowledgeable about these things.
where are gates into palisade?
why are hard to close
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
-
1
-
Mythos_Ruler's Playlist
in Introductions & Off-Topic Discussion
Posted
Saw these guys at a festival. Bit of a particular style, but I like it.