Opened 13 years ago
Closed 12 years ago
#619 closed enhancement (fixed)
Improve Gate and Wall System
Reported by: | Kieran P | Owned by: | |
---|---|---|---|
Priority: | Must Have | Milestone: | Alpha 11 |
Component: | Core engine | Keywords: | gate animation sound |
Cc: | Patch: |
Description (last modified by )
Gates that have animation to open and close, along with sounds to accompany it
Gates that have obstruction zones over the towers only, not the gate part
Gates that can be locked, so nothing gets in or out
- Allow Walls, Gates, and Towers to overlap, so that complex wall systems, that link together, are able to be built.
Attachments (1)
Change History (21)
comment:1 by , 13 years ago
Description: | modified (diff) |
---|---|
Summary: | Improve Gate System → Improve Gate and Wall System |
comment:2 by , 13 years ago
Milestone: | Alpha 3 → Alpha 4 |
---|
comment:3 by , 13 years ago
Owner: | removed |
---|
comment:4 by , 13 years ago
Milestone: | Alpha 4 → Alpha 5 |
---|
comment:5 by , 13 years ago
Milestone: | Alpha 5 → Alpha 6 |
---|
comment:6 by , 13 years ago
Milestone: | Alpha 6 → Alpha 7 |
---|
comment:7 by , 13 years ago
Milestone: | Alpha 7 → Backlog |
---|
comment:8 by , 12 years ago
comment:10 by , 12 years ago
Milestone: | Backlog → Alpha 11 |
---|
follow-up: 12 comment:11 by , 12 years ago
Few comments on r12081, trying not to duplicate what's been said already in IRC:
- I notice that locking the gate instantly adds the obstruction, even if a unit is directly under the gate. So I think locking should only take effect on the next gate close, after all units have left the
Radius
(I think it must be all units instead of just allies, or else an enemy unit passing the gate while it was opened, will be magically trapped inside the gate when it closes). - Change of ownership might have similar problems since it forces the gate closed, not sure if changing ownership (aka capturing) of gates during the game will ever occur in practice, so we may not have to worry about that. But if it's easy to fix, why not? :)
- A related point: it seems gates will instantly open or close, so we should add timing variables in the template (when the animations are added). We could have gates that work at different rates, maybe a tech that makes them work faster, or upgrades to more HP but slower working, etc. :)
GuiInterface
test is broken, usually a trivial fix
Minor aesthetic / cleanup issues:
Radius
is kind of a confusing term for the gate's range, radius of what? :) Any better names, maybePassRange
?- The behavior of
SetDisableBlockMovementPathfinding()
is confusing now. It seems rather than setting flags directly, it toggles them, which doesn't match up with the name of the function or its parameters. At a minimum it needs a comment inICmpObstruction.h
to explain what it does, but is the toggling the best design? (I haven't looked into it enough to argue one way or another) I wouldn't mind the JS call sites including comments as well ;)
comment:12 by , 12 years ago
Replying to historic_bruno:
- A related point: it seems gates will instantly open or close, so we should add timing variables in the template (when the animations are added). We could have gates that work at different rates, maybe a tech that makes them work faster, or upgrades to more HP but slower working, etc. :)
I'm not sure this is feasible. There are some pathfinding issues when there's a delay between opening and closing, a unit approaching the gate will not wait of course but will recalculate its path to go around a gate if it's blocking them.
For now we could have instant open/close logic, no reason to add so much complication.
comment:13 by , 12 years ago
I've been looking into adding animations, I already scrapped the idea of delayed opening/closing.
Now I'm finding a problem with using the gate transition animations. It's possible using CCmpVisualActor::SelectAnimation to play an animation once, and it conveniently stops on the last frame. While we serialize some animation-related state (see r10453), they will be replayed after deserialization, which has an adverse affect for single play animations. All gates would appear to fully open or close after loading a saved game (their actual state is unchanged) :(
Possible solution is to make single play animations skip directly to the last frame when deserializing. I think this would be least disruptive in most cases (it seems like what should be happening anyway?) The transitions look so good, it would be a shame not to use them.
comment:15 by , 12 years ago
Description: | modified (diff) |
---|
OK animation and sound support is added. I haven't made the above changes to CmpVisualActor
yet, pending discussion, that leaves a few animation bugs.
I found another case that needs a different solution anyway: if units are right on the edge of the gate's range, they might walk in and out of range quickly, causing the animations to start and stop abruptly which looks ugly. In this case, it would be useful to "reverse" the direction of the animation instead of starting a new one.
Related issue: Pureon mentioned it would be helpful for ship sails to have finer control of animations (particularly direction and speed). The whole system has other shortcomings, so it needs further discussion.
comment:17 by , 12 years ago
Going to re-use this ticket for some related fixes:
Each unique type of wall that's selected gets its own 'convert to gate' button. The 'convert to gate' icon is now the gate's, if it has one. Hopefully an artist can make a wooden gate icon so stone vs wood gate icons are distinct. gate_closed.png is still used as a fallback.
I didn't want to put the ugly template string hack into the simulation code, so input.js now filters the selection and will only send a wall-to-gate command if the selected wall's gate template matches the one we're trying to convert to.
Lastly, I've explicitly tracked whether the GUI's right panel has been filled, so that buildables/trainables are shown if possible, but never over top a 'dominant' type (e.g. trainables, trading, gate).
by , 12 years ago
Attachment: | gate-multiselect.patch added |
---|
comment:19 by , 12 years ago
comment:20 by , 12 years ago
Priority: | Should Have → Must Have |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Plz see Ticket #1288 that includes (for example) overlapping point to point wall placement for random maps.