[mjn.mixael]

Here is a thought I had, hopefully it won't be too difficult.

This will apply to the misc animations for the mainhalls mostly. I'm going to use the Bastion mainhall as an example for this.

Currently the mainhall code plays a single looping animation for background animations. Think of the crane in the Bastion mainhall. It comes in, grabs a crate then goes off screen. Then it returns and repeats the process. I was thinking that it would interesting if the code randomly selected from a set of animations for the same area. If each animation had the same start and end point, it would look seamless. This way the crane could grab the crate, then the next time maybe it could grab a fighter or something.

Essentially this is all to add further immersion into the mainhalls.

This came to me when I was watching the stars in Bastion. Consistently a couple Hercs fly by. Makes me wonder just how many Hercs are out there! But with this system, one time it could be Hercs, another time could be just stars, and the next could be a fenris or something!

Now, this CAN currently be done by making one HUGE ANI file. However, with a randomly selecting system, it will break the monotony even further by sometimes doing the same ANI twice in a row, or leaving one out for a while.

It would probably require a file naming system where it plays the ANI with the name selected, then (similar to the texture naming system) it selects the next ANI based on that. So you would have Crane.ani, Crane-a.ani, Crane-b.ani... etc.

I hope that was clear. Thoughts? Opinions?

[pecenipicek]

*supports*




also finally add keyframing support to eff's (or get MNG in engine) so the ani format can be purgified from that part permanently.

[CommanderDJ]

This definitely sounds like an awesome idea. I have no idea as to the feasibility/difficulty of implementing it though. You have my support anyway.

[Colonol Dekker]

It'd work in some cases. But not every. The crane wouldn't be doable without some sort of associated table entries. You'd end up with scenes of crates and fighters blinking in and out of existance without otherwise established guidance.
 
 
But I fully support the endeavour.

[mjn.mixael]

It'd work in some cases. But not every. The crane wouldn't be doable without some sort of associated table entries. You'd end up with scenes of crates and fighters blinking in and out of existance without otherwise established guidance.
 
 
But I fully support the endeavour.

If each animation had the same start and end point, it would look seamless.

[Kolgena]

Right, but I think he means that it's going to be difficult to show a crane removing a fighter without changing the number of visible fighters. It's doable if the crane moves a hidden fighter, but it might not work for all the current anis. It seems like it's possible to work around it, so you also have my support.

[Galemp]

ANIs loop. You'd make one that unload the fighter, then loads it back in place again.

[mjn.mixael]

people, people, people.... you underestimate my awesomeness!

remove the fighter, then...   ...  bring it back! (in a single ANI)

That's just the simplest workaround.. I have thought of a lot of possible combos using various transparencies and whatnot.

[CommanderDJ]

people, people, people.... you underestimate my awesomeness!

Truth.

[newman]

remove the fighter, then...   ...  bring it back! (in a single ANI)

Well, if the point is to increase immersion, then it should make sense too. Removing a fighter by crane only to return it a few seconds later doesn't qualify as making sense to me.

[mjn.mixael]

 

Well, it doesn't matter if you guys understand WHAT or HOW I'm going to make the crane work.

How's about you just trust me to do what I do best and instead let's talk about how this would work in the code because that is something I don't do very well.

[Spicious]

Doing this nicely seems possible by using finite state machines with animations played during transitions between states.

[Trivial Psychic]

I say, screw the ani and image-based mainhall and replace it with a fully-rendered on-the-fly mainhall!!!!!


 



... OK, well, maybe in ten years or so.

[DaBrain]

In my eyes this is something that shouldn't be hardcoded, but scripted.

I don't know if this is already possible somehow though.

[Goober5000]

This can be done... and pretty simply too.  It just requires changing a few lines of code in main_hall_render_misc_anims.  Now I just need to think of the right algorithm with which to do it.

[The E]

Shouldn't this start out somewhere in mainhall.tbl? something like

Code: [Select]

$Misc anim X: ani_1, ani_2, ani_3, .... , ani_N
+Sequential ;; Plays anis in order
+Random ;; Chooses a random one


[Goober5000]

That's what I originally thought, but then I realized that I could simply add a check to randomly select from all misc animations with the same coordinates.  No table format changes needed.

EDIT: But that only works if you want to pick a random animation equally out of the ones provided.  More complicated stuff, like sequential play or weighted randomness, would need a format change.

[mjn.mixael]

I'd be interested in sequential stuff and whatnot too, but I'm also all about simplicity. I would be happy with just the random selection.

[Cobra]

also finally add keyframing support to eff's (or get MNG in engine) so the ani format can be purgified from that part permanently.

NO.

Granted, .eff's are better-looking and all, but they're horribly inefficient, making hundreds of new fles when an .ani is just one file.

[The E]

You're outvoted, Cobra.

Also, we have keyframing support for effs.