[ssmit132]

On the wiki page for Messages.tbl, there's an entry for the tag $Append Suffix, which supposedly allows you to toggle whether you need "A", "B" or "C" for the headanis for that message.

I'd like to use this tag to reduce the amount of files needed for new personas, but in both 3.7.2 and the latest 3.7.4 Release Candidate, I keep getting errors from the parser. This happens both when I put it in the order shown on the wiki page:

Code: [Select]

$Name: All Clear
$Message: XSTR("It seems that the operation has completed.", -1)
+Persona: Kancolle_Fubuki
+Avi Name: Kancolle_Fubuki
+Wave Name: Fubuki-RFS.ogg
$Append Suffix: no

And if I put it here:

Code: [Select]

$Name: All Clear
$Message: XSTR("It seems that the operation has completed.", -1)
$Append Suffix: no
+Persona: Kancolle_Fubuki
+Avi Name: Kancolle_Fubuki
+Wave Name: Fubuki-RFS.ogg

Is this tag actually implemented, and if so, where does it go?

[Yarn]

$Append Suffix was implemented at one point before 3.7.2 was released, but it was removed only a few days later because the way it was implemented turned out to be problematic. Some time later (still before 3.7.2), a different version of this feature was implemented that automatically detects whether the suffix is needed.

So, you should be able to leave out $Append Suffix and still have the correct ANI appear.

[ssmit132]

I tried moving the "A", "B" and "C" versions of the headanis out of the hud folder, but the remaining non-suffix ones didn't appear when I tried a mission.

However, this was only for the persona messages. Mission messages still appeared with the headani. This is probably because there was still an exact match for the file it was asking for.

Might that be because they are EFFs, rather than ANIs? (e.g. "Kancolle_Fubuki.eff")

[AdmiralRalwood]

I tried moving the "A", "B" and "C" versions of the headanis out of the hud folder, but the remaining non-suffix ones didn't appear when I tried a mission.

However, this was only for the persona messages. Mission messages still appeared with the headani. This is probably because there was still an exact match for the file it was asking for.

Might that be because they are EFFs, rather than ANIs? (e.g. "Kancolle_Fubuki.eff")

Being EFFs shouldn't make a difference; persona messages and mission messages should behave identically in this regard, but the code is a bit complicated (and does check whether it's a builtin message or not), so it's hard to tell:

Code: [Select]

if ( (anim_info->anim_data.first_frame < 0) && // note, first_frame will be >= 0 when ani is an existing file, and will be < 0 when the file does not exist and needs a, b, or c appended
((q->message_num < Num_builtin_messages) || !(_strnicmp(HEAD_PREFIX_STRING, ani_name, strlen(HEAD_PREFIX_STRING)-1))) ) {

For reference, the related Mantis issue is #2888 and the last commit can be found here (and the version incorporated into 3.7.2 can be found here, although be warned that, as an SVN trunk sync, that page is quite full and can take a while to load).

The "HEAD_PREFIX_STRING" thing has to do with whether or not the filename starts with "head", but the important bit should be the "(anim_info->anim_data.first_frame < 0)" part; the game should've already attempted to load the animation--oh.

Oh.

Oh.

I'm just going to make a wild guess that this commit might have ****ed up the assumptions this code was relying on.

[Yarn]

I'm just going to make a wild guess that this commit might have ****ed up the assumptions this code was relying on.

The added call to generic_anim_unload in that commit is only one of three culprits. The second culprit is a call to that same function in messages_init. Removing these two lines is sufficient only for the first mission played, however; to fix all other missions, you need to remove the call to message_mission_free_avi (which has a call to, you guessed it, generic_anim_unload) in message_mission_shutdown.

I'm not sure that this is a good solution, though.

[AdmiralRalwood]

I'm just going to make a wild guess that this commit might have ****ed up the assumptions this code was relying on.

The added call to generic_anim_unload in that commit is only one of three culprits. The second culprit is a call to that same function in messages_init. Removing these two lines is sufficient only for the first mission played, however; to fix all other missions, you need to remove the call to message_mission_free_avi (which has a call to, you guessed it, generic_anim_unload) in message_mission_shutdown.

I'm not sure that this is a good solution, though.

It's not; not unloading was a BMPMAN slot leak. The "(anim_info->anim_data.first_frame < 0)" part is the part that needs changing; my first thought would be to set some sort of flag on the message after the initial load attempt, before unloading it, and then checking that when it comes time to add a suffix.

[niffiwan]

Oops, I recognise that commit 

Adding the flag based on load success/failure in add_avi() sounds good.

[ssmit132]

So, the gist of it is that this feature (automatic or manual) doesn't work at the moment.

That's fine, as it wasn't an incredibly big issue to begin with - it would have just saved me having superfluous animations. I'm happy to see it might be fixed in a future FSO version though.

[Yarn]

Here's a PR that fixes this problem: https://github.com/scp-fs2open/fs2open.github.com/pull/612

[Yarn]

Ssmit132, can you test the build below and see whether it fixes this issue? It works for me, but I want to make sure it works for you too. Make sure you do not add the $Message Suffix line.

https://dl.dropboxusercontent.com/u/89353583/FreeSpace/Patches/messages_suffix_fix_build.zip

[ssmit132]

Just tried it, and yes, it does work - I'm getting the EFF animations for my custom wingmen even with the ones with suffixes removed.

(It does break Axem's BP message box that I was using, though, but that's out of the scope of this thread.)

[Yarn]

(It does break Axem's BP message box that I was using, though, but that's out of the scope of this thread.)

If my change breaks something, then I need to know why before the change is committed. Can you provide a link to that message box so I can check it out?

[ssmit132]

I'll check it again tonight, but I realised I probably just jumped the gun again and instead it's just because I forgot to copy the .png for the actual message box when I copied my non-suffixed files over.

EDIT: Yep, it was just because I forgot to copy that file. Sorry to worry you, Yarn.