|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002057||FSSCP||SEXPs||public||2009-11-29 20:50||2012-01-23 17:59|
|Target Version||Fixed in Version||3.6.14|
|Summary||0002057: Using ship-invisible on a list of ships results in the highest priority ship flag to be removed twice|
|Description||Noticed this while trying to update this sexp to take wings as arguments. Couldn't figure out why it wasn't working right so I tried a Knigntly build and it has the exact same issue. Basically I have a test mission (will attach) where every ship except the player is an escort ship (modified hud gauges .tbm to see them). One or 2 are not visible at mission start and the first event turns one on and it shows on the escort list. 15 seconds later every ship is set invisible. 15 seconds after that select ships are set visible again. If one of those is the highest priority ship or the one at the top of the list if they are all the same priority it does not show back up. Doesn't matter if it's friendly, hostile, in a wing, etc.|
Did a lot of tracing last night and it seems the escort flag is getting removed twice. 3 identical ships in a wing D 1 2 and 3. All start with flags 16809988. 15 seconds in and at the start of processing of the ship-invisible they are all still 16809988. At the end of the ship-invisible call they are all 16826372. Now somewhere between that point and the start of the ship-visible event D 1 gets changed to 16826368 while the other 2 are still 16826372. So at the end of the ship-visible event D 1 is 16809984 and D 2 and 3 are 16809988.
Now D 1 is the only ship that hits the following line in void hud_remove_ship_from_escort_index(int dead_index, int objnum):
Ships[Objects[objnum].instance].flags &= ~SF_ESCORT
That call is made from hud_escort_cull_list()
Why it's doing this and is the only ship out of the list that is I have no idea. It is always the ship at the top of the escort list.
I have that gut feeling this might be an issue with other flags as well especially ship-stealthy/unstealthy and their friendly counterparts.
|Tags||No tags attached.|
|After looking at the code it seems to me more like the code was supposed to remove escort flags from the ships that are invisible to sensors but it fails to do that.|
This seems to be caused by two conflicting policies for hidden from sensors ships:
hud_escort_cull_list looks for hidden from sensors and calls hud_remove_ship_from_escort_index which removes the escort flag and then calls hud_create_complete_escort_list which applies the second policy of omitting hidden (and stealth) ships from the list but leaving the escort flag. Thus, by the time hud_escort_cull_list moves on there are no more ships in the escort list to deflag.
The action to be taken depends on which policy is considered correct. Either way, the strategy for dealing with hidden escort ships should be consolidated in one place.
Yeah, the policy should be that culled ships don't have their escort flags removed.
Fixed in revision 8300.
|Fix committed to fs2_open_3_6_14@8353.|
fs2open: fs2_open_3_6_14 r8353
Timestamp: 2012-01-23 17:59:19
|Backport: Trunk 8300; don't remove the escort flag from invisible ships that aren't on the escort list (fixes Mantis 0002057). also, don't remove dead or dying ships from the escort list, because due to the design of the culling function, they were never removed previously|
|mod - /branches/fs2_open_3_6_14/code/hud/hudescort.cpp|
|2009-11-29 20:50||FUBAR-BDHR||New Issue|
|2009-11-29 20:50||FUBAR-BDHR||File Added: 11sexptest_nowing.fs2|
|2009-12-05 07:49||Wanderer||Note Added: 0011378|
|2010-03-19 08:26||Spicious||Note Added: 0011798|
|2012-01-22 01:41||Goober5000||Note Added: 0013103|
|2012-01-22 01:41||Goober5000||Assigned To||=> Goober5000|
|2012-01-22 01:41||Goober5000||Status||new => resolved|
|2012-01-22 01:41||Goober5000||Resolution||open => fixed|
|2012-01-22 01:41||Goober5000||Fixed in Version||=> 3.6.14|
|2012-01-23 17:59||chief1983||Changeset attached||=> fs2open fs2_open_3_6_14 r8353|
|2012-01-23 17:59||chief1983||Note Added: 0013134|