As we all (should) know, combo cycling lets us do a lot of stuff, however, lets say we have combos A B and C, where A cycles to B and B to C, while each animates for equal frames @ equal speed. What irks me is that the combos animate "in the background" if you will, so that there is virtually no guarantee that by the time combo A finishes it's 10 frame 5 speed animation, it will cycle to B and B will be on frame 1 (of 10, at a speed of 5).
Suggestion: In the combo editor box, add a check box that says "Animate from begging when cycled to" so that everything works smoothly and won't look choppy due to the fact that combo cycling lands on a random frame of animation per combo.
It's supposed to do that anyway. This is a bug.
I agree especially if you want to have Zelda 2 breakable blocks and when hit, it cycles through cracking and shattering animation and sometimes you hit blocks and instantly disappears and sometimes it goes through cycles of cracks, so I want them to all cycle through cracks all the time rather than randomly instantly disappear
Dark Nation wrote:It's supposed to do that anyway.
I'm not so sure it is... from looking at the code, it's my understanding that all combos animate in parallel - that is, after every frame, the entire combo page advances a frame, regardless of which combos are actually present on the current screen. Thus if you have two combos start animating at the same speed at the same time, one has 3 frames, the other 10 frames, and the former cycles into the latter, after the first combo is done animating it will cycle to the second's fourth frame.
If two combos with the same speed and number of frames is not cycling properly, however, there's no question that that's a bug.
Well, if everything animates parallel, then I guess yea.... the check box that says "Reset animation when Cycled to" (or similar) should be added to the combo editor.
Dark, I don't think he's really phrasing his question properly.
If you place an animating combo on the screen and ensure all of the linked combos have identical animation frame and speed, they will animate properly. No question.
However, if you are changing combos in the sequence based on player input, then you introduce an unknown into the equation. Say you have a closed door combo on the screen. The opening sequence combo-animates and will look perfectly fine if you placed the initial combo in that sequence on the screen. The trouble is when you DON'T place the initial combo in the sequence on the screen. Instead, you place a "closed door" combo. The combo cycling sequence starts whenever link triggers the secrets and changes the "closed door" combo to an "open door combo." If this occurs at the instant the linked combos are starting their animation, great. But more likely that not it will occur sometime in the middle of the animation, with the result that the animation for at least one (perhaps more) of the cycling combos will look odd.
This impacts people who just want one animation the most severely. If the animation started from frame 1, no matter when the secret was triggered, you could put the whole opening-door animation on one combo. As it is, you need to make a whole series of 2-frame cycled combos with one frame of animation each to make it look right. Makes it more work than it's worth.
Not sure if this is an easy thing to fix, and I'm not necessarily suggesting the devs spend time on it, but I thought I'd clarify what the issue is.
Yeah, I get what you're saying; I investigated combo cycling a while ago when somebody reported this behavior as a bug.
The last person to heavily rewrite the combo animation system (jman?) very deliberately set up the combo hash tables so that combos would animate in parallel; changing them to animate on a per-tile-on-the-screen basis would take a bit of work but I'm happy to do it if DN says they were always suppose to act this way.
Is there a chance any published quests are relying on the current behavior?
I'm actually fine with the current behavior. Predictable. But I don't see a problem changing it.
Yeah, same thing here. It's certainly possible that some creative genius out there has used this to their advantage, but I'm pretty sure more people would prefer a fully functional arm than using their own detached arm as a billy club. Creative, but it's just not right, son.
Very well. As it'll be a fairly major code change I'll defer it to after the current round of bug fixing.
Fixed by a flag in the combo dialog in the next build.