Build animations

[Mr War]

Hi, I have a mothership unit in my Martian mod which instead of building in the normal way, I want it to look like a space ship is landing by legs coming out the bottom etc. I have built a 30frame animation in blender which itself works fine in the game.

However, the animation loops during building.

HP =8000

Is there a way of either:
A) ensuring the animation takes the same time to run as the build does
B) setting the animation go only run once

?

Thanks in advance

[TotalNoob]

I think the easiest way would be to make every next frame to be displayed for every (since there are 30 frames overall) 3,33% of HP gained during building process. No idea if it is possible to do right now.

[Omega]

But timing that would be impossible. If multiple workers construct, the animation speed is unchanged, yet will be done faster.

[Gabbe]

Titi did something with the egypts pyramid if i recall correctly..

[ElimiNator]

The Egypt's pyramid building anim is the tech barrack's textured yellow...

[will]

ok, so how would this ideally work?

Then we fix the engine to support this...

[Psychedelic_hands]

Possible Work around 1:
Make your workers build something like a Landing zone first, then have that "morph " into the Mothership. That way you an time the Morph animation of the landing perfect.

Work around 2:
Make your Mothership have a Ship unit form, and get you workers/a building to produce the flying unit form of the ship and then you morph that down to where you would like.

 I am unsure of how the AI would like these, but they should work fine.
I would recommend number 1, as you seem to already have a sort of landing thing underneath 

[Omega]

Possible Work around 1:
Make your workers build something like a Landing zone first, then have that "morph " into the Mothership. That way you an time the Morph animation of the landing perfect.

Work around 2:
Make your Mothership have a Ship unit form, and get you workers/a building to produce the flying unit form of the ship and then you morph that down to where you would like.

The AI could handle #1 perfectly fine, as the Behemoth and Thor units already are built as a building, then morphed into a unit. I don't see how #2 is any different from #1 though (or do I misunderstand?).

If you wanted to build something so the animation would span over the entire build period, you'd probably need a feature request for sure, because as I mentioned, variable building speeds, such as that from having multiple workers repair, would ruin the animation otherwise. This was a feature request in the past, presumably lost in the sands of time.

Worth noting that the elves faction did this with their tree-like buildings. Though, in that case, the trees built almost instantly, so there was no reason to use multiple workers. Still, it does illustrate how it can work.

[will]

both approaches sound excellent!

You could imagine being given a landing-pad and workers, and the first thing is to morph the landing pad.  Or maybe as a strategy you decide to *immediately* at the start of the game move your workers elsewhere and get them to build a landing-pad, so that the enemy doesn't find you in a known position...

[Psychedelic_hands]

They're the same Engine-wise, but different Gameplay-wise. Though I think the AI will handle number 1 better.

[silnarm]

I don't think stretching one animation out is the ideal solution, Omega has pointed out why already...

The work-around solutions, while novel, are ugly and again Omega has pointed out likely AI issues.

Multiple animations per skill has been discussed time and time again... for various purposes. Someone should actually do it someday I guess... (GAE can actually load multiple animations, but it only ever uses the first... not so useful).

The way I would do it if it were to be done now,

Code: [Select]

  <animations>
<animation condition="hp < 2000" path="construction_models/castle_construction_stage1.g3d" />
<animation condition="hp < 5000" path="construction_models/castle_construction_stage2.g3d" />
<animation condition="hp < 8000" path="construction_models/castle_construction_stage3.g3d" />
<animation condition="hp < 9000" path="construction_models/castle_construction_stage4.g3d" />
  </animations>

But I don't think this should be done now, or like that...

It should be done like this,

Code: [Select]

  <animations>
<animation name="build_stage1" path="construction_models/castle_construction_stage1.g3d" />
<animation name="build_stage2" path="construction_models/castle_construction_stage2.g3d" />
<animation name="build_stage3" path="construction_models/castle_construction_stage3.g3d" />
<animation name="build_stage4" path="construction_models/castle_construction_stage4.g3d" />
<select-anim-script>
<![CDATA[
if unit:hp < 2000 then
return "build_stage1";
elseif unit:hp < 5000 then
return "build_stage2";
elseif unit:hp < 8000 then
return "build_stage3";
end
return "build_stage4";
]]>
</select-anim-script>
  </animations>


[will]

By making the choice of animation based on hp, and several workers means the building builds faster, will it abruptly switch animations without finishing them smoothly?

[silnarm]

By making the choice of animation based on hp, and several workers means the building builds faster, will it abruptly switch animations without finishing them smoothly?

Yeah, this solution is fundamentally different from how the OP wanted this done... and not particularly compatible, you would need fairly static models (or 'fully' static) that could play looping until replaced by the next stage.

To do what the OP wanted, or similar with multiple g3d anims, would be something completely different to how it is done now... it could be done, but I'd prefer a solution not so wildly different to how anims currently play (and not needing lots of 'special case' code).

[Mr War]

Build animations loop but die animations do not. By default that's good. But couldn't there just be an XML tag to set a build ( or move or attack) animation to not loop?

[-Archmage-]

@Silnarm: If you make a complex animation and use enough frames, drawing it out is no problem. The engine just needs to calculate the animation speed to match the building speed.

[silnarm]

Upon further review this actually seems a good idea (also, I was tinkering, and found a clean(ish) way to do it), the same sort of thing could be done with produce/upgrade skills and some nice animations using this method would be cool (probably more so be-built, but it could be added for produce/etc easily if anyone wants it).

Done in GAE, beta1 will be released shortly.
It's just 'straight' tied to the hp atm, so if the under construction building gets attacked, the animation will go backwards! will fix this before 0.4 proper.

in the be-built (or build-self) skill node,

Code: [Select]

    <anim-stretch value="true" />


[-Archmage-]

Upon further review this actually seems a good idea (also, I was tinkering, and found a clean(ish) way to do it), the same sort of thing could be done with produce/upgrade skills and some nice animations using this method would be cool (probably more so be-built, but it could be added for produce/etc easily if anyone wants it).

Done in GAE, beta1 will be released shortly.
It's just 'straight' tied to the hp atm, so if the under construction building gets attacked, the animation will go backwards! will fix this before 0.4 proper.

in the be-built (or build-self) skill node,

Code: [Select]

    <anim-stretch value="true" />


YEA!
I think a good fixing rule is that no building animation may play backwards.

[will]

Brilliant!

I guess Mr War doesn't build from git - how far away is a release with this in?

And can we get this into MG before the merge too?  Or is the merge so close as to not slow the active modders down?

I think a good fixing rule is that no building animation may play backwards.

I think that going backwards or otherwise ought to be specified in the xml

[-Archmage-]

Quote from: -Archmage- on April 29, 2011, 22:02:31
I think a good fixing rule is that no building animation may play backwards.

I think that going backwards or otherwise ought to be specified in the xml

Yea why not!

[tomreyn]

Just a quick reminder, this is the MegaGlest related part of the forums.

[titi]

@tomreyn:  true but interisting nevertheless

About the problem itself, what about an animation progress based on the construction progress? I don't think this is too hard to do.
Problems that you might face:

When a building which is in state of building is attacked by another unit its animation might plyed back reversed . How to handle this?

[will]

Imagine a build animation of a balloon or airship - it migbt be showing inflation, and going backwards if hp is falling would be a good thing.

So make it go backwards if hp drops is good, and perhaps in other circumstances it sohuld freeze until hp recovers.  Settable in ini

Bug I can't think that a looping animation is ever preferable, but sametime maybe that is a safe default for compatibility.

We want MG to do hp-related build animation speed so Mr War can use it immediately there is a release supporting it!

[Omega]

So make it go backwards if hp drops is good, and perhaps in other circumstances it sohuld freeze until hp recovers.  Settable in ini

I assume you mean the XML, not the INI?

Bug I can't think that a looping animation is ever preferable, but sametime maybe that is a safe default for compatibility.

An example that requires looping: UNATF's Heli's animation, naturally, is spinning very fast, and in order to do this without making the unit itself hyper fast, it goes through multiple animation cycles in the time it takes to perform one action, despite the animation itself being only one full spin of the blade.

We want MG to do hp-related build animation speed so Mr War can use it immediately there is a release supporting it!

Bearing in mind we should be preparing for the merger. If we keep adding features, we'll never get anything done.

[silnarm]

When a building which is in state of building is attacked by another unit its animation might plyed back reversed . How to handle this?

I was thinking use Unit::progress2, 'sync' with hp in Unit::repair() if hp > progress2.
Then animProgress is just progress2 / max_hp for the "stall instead of go backwards" version, and hp / max_hp for the version that will back up.

Bearing in mind we should be preparing for the merger. If we keep adding features, we'll never get anything done.

True, but this was very easy to add in the end, I'll hook it up in MG too.