[Valathil]

So i herd u liek .eff Head.ani's?

There you go: http://www.mediafire.com/download.php?cc5l6bh5520nhpt

Few Notes: I changed the head animation system to use generic_anim's instead of the anim_play framework so this could possibly fix the head.ani stuttering please check that.
Also new Mod Table entry "$Override Head.ani color to white:" which surprisingly overrides the head.ani color to white so you can have full color eff animations.
I also patched FRED so you can select *.eff in the browse dialog of the event editor but i cant compile FRED so you have to wait on a kind soul to provide one OR you edit the mission file yourself OR you just name you eff the same as your ani, it takes precedence. With that have fun and please report bugs.

EDIT: I should probably clarify the mod.tbl settings its in #OTHER SETTINGS after "$Default weapon select effect:" so basically for now the last parameter

[Rodo]

My antivirus is saying that the file is infected with something like..NewHeur_PE.

I'll test this at home when I get back tonight.

[The E]

Your antivirus is confused.

[Droid803]

YES FINALLY.
Much <3's.

[mjn.mixael]

This is awesome.. Can I just say though, that the mod.tbl should probably be the other way around? White has always been default.. the override should allow color? Maybe? I dunno... does it really matter?

Nao. Valathil, you will be my personal hero if you make an .eff container... >_>

[headdie]

My antivirus is saying that the file is infected with something like..NewHeur_PE.

I'll test this at home when I get back tonight.

"NewHeur" as in New Heuristic?

[The E]

EFFing FRED builds:

http://blueplanet.fsmods.net/E/EFFHeads.7z

[Valathil]

This is awesome.. Can I just say though, that the mod.tbl should probably be the other way around? White has always been default.. the override should allow color? Maybe? I dunno... does it really matter?

Nao. Valathil, you will be my personal hero if you make an .eff container... >_>

You can set the color of the head.ani in your hud settings. So if you have color effs they would get tinted by that user setting therefore override to white.

What the EFF is a .eff container? you mean like compile it into a single file? why the EFF would you wanna do that?

[Dragon]

For the ease of handling and renaming, presumably. 

[mjn.mixael]

Well, .effs don't stream like .anis do, which as caused a bit of an issue for me with my mainhalls.

EDIT: Ala, this ticket.

[Swifty]

Can we rename that parameter to "Full Color Talking Head" so we can just describe function and not implementation?

And also, since we're no longer relying on the anim_play func to hack in the talking head animation in the gauge for us and using generic_anim_render within the actual Talking Head gauge, could you use setColorGauge() instead of gr_set_color_fast(&HUD_config.clr[HUD_TALKING_HEAD])? I really disliked having to reference HUD_config in the head animation code back then when I was rewriting the entire HUD system. gr_set_color_fast should just be used when we want to set the color context to white for getting full color animations.

[Valathil]

Well, .effs don't stream like .anis do, which as caused a bit of an issue for me with my mainhalls.

EDIT: Ala, this ticket.

This ticket only describes the format not the problems you having. Cause i dont want to overwhelm the thread here with our discussion i suggest you find me on IRC and we can talk.

[AndrewofDoom]

If you want something to test this on, go play Dimensional Eclipse, which has all the headanis as anis as well as effs. Droid kept holding on for the day eff support would come and looks like he got it.

[Valathil]

Concerning hitting the bmpman limit 5 possible solutions:

• Unload the eff everytime the animation finishes (Bad for cases where theres much reuse)
• Write a separate handler with dynamic limits (lots of work)
• Same as 2 but push everything into gl textures and dont keep the data in memory (high vram usage)
• Load every frame individually and unload it everytime the next frame is displayed (isnt this what causes the .ani stuttering?)
• Sort of a hybrid of 2 and 4 and the old bmpman where you load some frames ahead of time render them while loading more and killing old unused ones

DISCUSS!!!

[Kobrar44]

Someone talked a while ago something about some kind of texture arrays. That wouldn't cut it?

[Valathil]

Someone talked a while ago something about some kind of texture arrays. That wouldn't cut it?

that's number 3 or a way to do 3 not a solution by itself

[Dragon]

5 sounds like a good compromise, but I'm afraid it could be a bit overengineered and difficult to implement. 2 could be the best solution for the end user, but I know such things need a lot of work from the devs and a lot of testing afterwards.

[CommanderDJ]

5 sounds kind of... ugly. 2 sounds like it'd be the "cleanest" solution but it might have to go through antipodes, which could take a while depending on how much longer this RC phase lasts etc.

That's just my opinion though.

[Cyborg17]

I'm just curious, what's wrong with option #1?

[niffiwan]

what about increasing the BMPMAN limit by approx 500 (for example - to allow 10x head ani/EFF per mission @ ~50 frames each ) until 2 (or 3) is completed?  Otherwise 1) doesn't sound like too much work - it could be tried to see if unloading/reloading causes issues? (e.g. FSO pauses while the ani/eff is removed from memory)