2019-03-21 19:10 EDT

View Issue Details Jump to Notes ] Related Changesets ]
IDProjectCategoryView StatusLast Update
0002655FSSCPHUDpublic2012-07-01 21:03
Assigned Toniffiwan 
PlatformLinuxOSUbuntuOS Version12.04
Product Version3.6.14 RC5 
Target VersionFixed in Version 
Summary0002655: Messages without audio play too quickly
DescriptionMessages don't check if the head ani is complete. They only check if the audio is complete and the message expiry (which is relatively new), therefore in certain cases the messages play too fast. See Axem's test mission for one example:

TagsNo tags attached.
Attached Files

related to 0002411resolvedniffiwan Repeated messages don't show the head ani 
related to 0002588resolvedValathil No Grey Brackets Around Ships Sending Messages 



niffiwan (developer)

Fix committed to trunk@8802.


niffiwan (developer)

note: commit 8802 depends on 8801 - it'll break messages without Playing_messages[x].play_anim being set to false when a head anis aren't playing


Goober5000 (administrator)

Hold on. The hud ani is subordinate to the message, not vice versa. If there is a wav file provided for the message, the message should end immediately upon the completion of the wav file. Some voice acted campaigns depend on this.

If this is referring to a message *without* a wav file, though, then that's different. Clarification is needed.


niffiwan (developer)

I made a poor choice of commit title :) This is for messages without a wav file so they play at least as long as the head ani runs - this was the behaviour in 3.6.12 (tested with Axem's mission). There's other code (that I haven't changed) to deal with a message with ani & wav, and will abort the ani when the wav ends.


            // AL 1-20-98: If voice message is done, kill the animation early
            if ( (Playing_messages[i].wave != -1) && wave_done ) {
                /*if ( !ani_done ) {
                    anim_stop_playing( Playing_messages[i].anim );
                Playing_messages[i].play_anim = false;


Goober5000 (administrator)

Okay. What changed between 3.6.12 and 3.6.14 to alter the behavior?


niffiwan (developer)

In r6833 some code was commented out:

In mission/missionmessage.cpp

@@ -1182,8 +1186,8 @@ void message_queue_process()
                        int ani_done, wave_done, j;
                        ani_done = 1;
- if ( (Playing_messages[i].anim != NULL) && anim_playing(Playing_messages[i].anim) )
- ani_done = 0;
+ //if ( (Playing_messages[i].anim != NULL) && anim_playing(Playing_messages[i].anim) )
+ // ani_done = 0;
                        wave_done = 1;

I believe this was done because Playing_messages (array of struct pmessage) changed to remove the .anim pointer, however it also meant that ani_done was always 1 and therefore the check to see if messages should end always assumed that the head ani had finished.

This situation probably doesn't come up very often, i.e. where the length of the head ani is the deciding factor in whether a message ends or not. You need a message without a wav and one that is repeated at a short interval. I think the only place I saw something like this (outside of Axem's test mission) was in JAD - Burn baby burn, Burn! Burn! Burn! :-) (although maybe that was where I saw the head ani not being repeated properly... i.e. mantis 2411...)


Goober5000 (administrator)

Okay. And presumably your commit takes this into account?

If everything is kosher, then we can go ahead and mark this resolved again. :)


niffiwan (developer)

yeah - I essentially re-instated the commented out code, except using the new variable which records if an ani is playing or not (bool Playing_message[].play_anim). It does require r8801 to work properly though, as that commit correctly sets .play_anim to false when an ani ends ;)


Zacam (administrator)

Fix committed to fs2_open_3_6_14@8938.

+Related Changesets

-Issue History
Date Modified Username Field Change
2012-05-20 01:36 niffiwan New Issue
2012-05-20 01:36 niffiwan Status new => assigned
2012-05-20 01:36 niffiwan Assigned To => niffiwan
2012-05-20 01:36 niffiwan Relationship added related to 0002411
2012-05-20 01:38 niffiwan Relationship added related to 0002588
2012-05-20 02:01 niffiwan Changeset attached => fs2open trunk r8802
2012-05-20 02:01 niffiwan Note Added: 0013572
2012-05-20 02:01 niffiwan Status assigned => resolved
2012-05-20 02:01 niffiwan Resolution open => fixed
2012-05-20 02:04 niffiwan Note Added: 0013573
2012-05-20 02:04 niffiwan Status resolved => feedback
2012-05-20 02:04 niffiwan Resolution fixed => reopened
2012-05-20 02:04 niffiwan Status feedback => resolved
2012-05-20 02:04 niffiwan Resolution reopened => fixed
2012-05-20 15:45 Goober5000 Note Added: 0013579
2012-05-20 15:45 Goober5000 Status resolved => code review
2012-05-20 17:39 niffiwan Note Added: 0013585
2012-05-21 00:54 Goober5000 Note Added: 0013589
2012-05-21 03:02 niffiwan Note Added: 0013590
2012-05-21 04:24 Goober5000 Note Added: 0013595
2012-05-21 05:16 niffiwan Note Added: 0013596
2012-05-21 05:16 niffiwan Status code review => resolved
2012-07-01 21:03 Zacam Changeset attached => fs2open fs2_open_3_6_14 r8938
2012-07-01 21:03 Zacam Note Added: 0013762
+Issue History