2020-10-19 12:57 EDT


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002048FSSCPSEXPspublic2020-07-08 00:58
ReporterFUBAR-BDHR 
Assigned Tokarajorma 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version3.6.11 
Target Version3.7.0Fixed in Version 
Summary0002048: Several sexps involving setting flags for wings that haven't arrived yet do not work
DescriptionDiscovered this while working on a new sexp. I used change-iff as a reference on how to set up the handling of a wing but my sexp was not working. Finally after a few hours of beating my head against the desk I tried stepping though change-iff only to find out it didn't work either.

Problem is actually in void sexp_get_object_ship_wing_point_team. This returns oswpt->type of OSWPT_TYPE_NONE for wings that have not arrived yet not OSWPT_TYPE_WING. Thus the process of future arrivals in about 6 differen sexps never happen as the loop to set them is in the case statement for OSWPT_TYPE_WING.



Additional InformationI have a fix for this that should not interfere with other sexps. I defined OSWPT_TYPE_FUTURE_WING and had sexp_get_object_ship_wing_point_team return that if the wing had not arrived yet. Simply adding this case to the sexps that are supposed to process future wing arrivals seems to work. I'll attach the patch in a bit. Right in the middle of testing new sexp feature that uses this as well. I'll make sure it works as designed first.
TagsNo tags attached.
Attached Files
  • patch file icon Future_wings.patch (5,788 bytes) 2009-11-24 05:13 -
    Index: parse/sexp.cpp
    ===================================================================
    --- parse/sexp.cpp	(revision 5681)
    +++ parse/sexp.cpp	(working copy)
    @@ -3730,6 +3730,7 @@
     #define OSWPT_TYPE_TEAM			4
     #define OSWPT_TYPE_PARSE_OBJECT	5
     #define OSWPT_TYPE_EXITED		6
    +#define OSWPT_TYPE_FUTURE_WING	7
     
     // Goober5000
     typedef struct object_ship_wing_point_team
    @@ -3838,22 +3839,21 @@
     
     
     	// at this point, we must have a wing or point for a target
    -	wing_num = wing_name_lookup(object_name);
    +	wing_num = wing_name_lookup(object_name, 1);
     	if (wing_num >= 0)
     	{
     		wing *wingp = &Wings[wing_num];
     
     		// make sure that at least one ship exists and that the wing leader is valid
     		if ( (wingp->current_count >= 0) && (wingp->ship_index[wingp->special_ship] >= 0) )
    -		{
     			oswpt->type = OSWPT_TYPE_WING;
    -
    -			// point to wing leader
    -			oswpt->wingp = wingp;
    -			oswpt->shipp = &Ships[wingp->ship_index[wingp->special_ship]];
    -			oswpt->objp = &Objects[oswpt->shipp->objnum];
    -		}
    -
    +		else 
    +			oswpt->type = OSWPT_TYPE_FUTURE_WING;  
    +		// point to wing leader
    +		oswpt->wingp = wingp;
    +		oswpt->shipp = &Ships[wingp->ship_index[wingp->special_ship]];
    +		oswpt->objp = &Objects[oswpt->shipp->objnum];
    +		
     		return;
     	}
     
    @@ -7602,6 +7602,7 @@
     
     			// change wing (we must set the flags for all ships present as well as all ships yet to arrive)
     			case OSWPT_TYPE_WING:
    +			case OSWPT_TYPE_FUTURE_WING:
     			{
     				// current ships
     				for (int i = 0; i < oswpt.wingp->current_count; i++)
    @@ -7699,6 +7700,7 @@
     
     			// change wing (we must set the flags for all ships present as well as all ships yet to arrive)
     			case OSWPT_TYPE_WING:
    +			case OSWPT_TYPE_FUTURE_WING:
     			{
     				// current ships
     				for (i = 0; i < oswpt.wingp->current_count; i++)
    @@ -11436,6 +11438,7 @@
     
     			// change wing (we must set the flags for all ships present as well as all ships yet to arrive)
     			case OSWPT_TYPE_WING:
    +			case OSWPT_TYPE_FUTURE_WING:
     			{
     				// current ships
     				for (int i = 0; i < oswpt.wingp->current_count; i++)
    @@ -11518,6 +11521,7 @@
     
     			// change wing (we must set the flags for all ships present as well as all ships yet to arrive)
     			case OSWPT_TYPE_WING:
    +			case OSWPT_TYPE_FUTURE_WING:
     			{		
     				// current ships
     				for (int i = 0; i < oswpt.wingp->current_count; i++)
    @@ -22037,6 +22041,9 @@
     	// Goober5000 - added wing capability
     	{ OP_CHANGE_IFF, "Change IFF (Action operator)\r\n"
     		"\tSets the specified ship(s) or wing(s) to the specified team.\r\n"
    +		"\tFor wings:  If wing names are supplied current and future waves are changed.\r\n"
    +		"\tFor wings:  If ship names are supplied and wing has not arrive yet all waves are chagned.\r\n"
    +		"\tFor wings:  If ship names are supplied and wing has arrive only the current ships are changed.\r\n"
     		"Takes 2 or more arguments...\r\n"
     		"\t1:\tTeam to change to (\"friendly\", \"hostile\" or \"unknown\").\r\n"
     		"\tRest:\tName of ship or wing to change team status of." },
    @@ -22044,6 +22051,9 @@
     	// Wanderer
     	{ OP_CHANGE_IFF_COLOR, "Change IFF Color (Action operator)\r\n"
     		"\tSets the specified ship(s) or wing(s) apparent color.\r\n"
    +		"\tFor wings:  If wing names are supplied current and future waves are changed.\r\n"
    +		"\tFor wings:  If ship names are supplied and wing has not arrive yet all waves are chagned.\r\n"
    +		"\tFor wings:  If ship names are supplied and wing has arrive only the current ships are changed.\r\n"
     		"Takes 6 or more arguments...\r\n"
     		"\t1:\tName of the team from which target is observed from.\r\n"
     		"\t2:\tName of the team of the observed target to receive the alternate color.\r\n"
    @@ -22923,8 +22933,11 @@
     	// Goober5000
     	{ OP_SHIP_CHANGE_ALT_NAME, "ship-change-alt-name\r\n"
     		"\tChanges the alternate ship class name displayed in the HUD target window.  Takes 2 or more arguments...\r\n"
    +		"\tFor wings:  If wing names are supplied current and future waves are changed.\r\n"
    +		"\tFor wings:  If ship names are supplied and wing has not arrive yet all waves are chagned.\r\n"
    +		"\tFor wings:  If ship names are supplied and wing has arrive only the current ships are changed.\r\n"
     		"\t1:\tThe ship class name to display\r\n"
    -		"\tRest:\tThe ships to display the new class name" },
    +		"\tRest:\tThe ships or wings to display the new class name" },
     
     	// Goober5000
     	{ OP_SET_DEATH_MESSAGE, "set-death-message\r\n"
    @@ -23486,15 +23499,21 @@
     
     	//-Sesquipedalian
     	{ OP_KAMIKAZE, "kamikaze\r\n"
    -		"\tTells ships to perform a kamikaze on its current target. Takes 2 or more arguments...\r\n"
    +		"\tTells ships or wings to perform a kamikaze on its current target. Takes 2 or more arguments...\r\n"
    +		"\tFor wings:  If wing names are supplied current and future waves are changed.\r\n"
    +		"\tFor wings:  If ship names are supplied and wing has not arrive yet all waves are chagned.\r\n"
    +		"\tFor wings:  If ship names are supplied and wing has arrive only the current ships are changed.\r\n"
     		"\t1: Damage dealt when kamikaze is done\r\n"
    -		"\tRest: Names of ships to perform kamikaze\r\n"
    +		"\tRest: Names of ships or wings to perform kamikaze\r\n"
     	},
     	
     	//-Sesquipedalian
     	{ OP_NOT_KAMIKAZE, "not-kamikaze\r\n"
    -		"\tTells ships abort a kamikaze run  Takes 1 or more arguments....\r\n"
    -		"\tAll: Names of ships to abort kamikaze\r\n"
    +		"\tTells ships or wings to abort a kamikaze run  Takes 1 or more arguments....\r\n"
    +		"\tFor wings:  If wing names are supplied current and future waves are changed.\r\n"
    +		"\tFor wings:  If ship names are supplied and wing has not arrive yet all waves are chagned.\r\n"
    +		"\tFor wings:  If ship names are supplied and wing has arrive only the current ships are changed.\r\n"
    +		"\tAll: Names of ships or wings to abort kamikaze\r\n"
     	},
     
     	//phreak
    
    patch file icon Future_wings.patch (5,788 bytes) 2009-11-24 05:13 +
  • txt file icon IFF_Test.txt (1,709 bytes) 2009-11-24 05:14 -
    IFF test results (all similar sexps were changed the same way).  
    
    All ships started as freindly.  Test with event set to 5 second delay or just true results the same. 
    
    
    Ship	Arrival time:	Change type:	45 seconds	Change	65 seconds	At Respawn
    ------------------------------------------------------------------------------------------
    A1	Start		Each ship	Friendly	A2	Friendly	Friendly
    A2					Hostile		to 	Neutral		Friendly
    A3					Hostile	      Neutral	Hostile		Friendly
    
    B1	10 seconds	Wing then	Friendly	Wing	Neutral		Neutral	
    B2			first ship	Hostile		to	Neutral		Neutral
    B3			changed back	Hostile	      Neutral	Neutral		Neutral
    
    C1	Start		Wing then	Friendly	Wing	Neutral		Neutral
    C2			frist ship	Hostile		to	Neutral		Neutral
    C3			changed back	Hostile	      Neutral	Neutral		Neutral
    
    D1	30 seconds	Each ship	Friendly	D3	Friendly	Freindly
    D2					Hostile		to	Hostile		Hostile
    D3					Hostile	      Neutral	Neutral		Hostile
    
    
    So changes to wing change all waves if the wing has arrived or not.
    Changes to ships depend on if the ship is in mission or not.  
    If in mission only the current ships are changed not the ship in the following waves
    If wing hasn't arrived yet all wave are set.
    
    Now before the bug fix the only thing that should be different are are wings that has not
    arrived yet.  In this test that would have resulted in B wing being all Friendly
    at 45 seconds.  Rest of the items would have been processed the same way.  
    
    Other sexps using OSWPT_TYPE_WING: should not be effected as the wings that have not arrived 
    yet are processed based on new OSWPT_TYPE_FUTURE_WING:  
    
    Sexps effected:
    
    change-iff
    change-iff-color
    ship-kamikazie
    ship-change-ship-alt-name
    txt file icon IFF_Test.txt (1,709 bytes) 2009-11-24 05:14 +

-Relationships
+Relationships

-Notes

~0011337

FUBAR-BDHR (developer)

Patch and results of behavior with the patch uploaded.

~0012145

Goober5000 (administrator)

Karajorma and I have discussed an alternate solution to this issue. He should get back to you about it shortly.

~0014067

Goober5000 (administrator)

This is accommodated with Karajorma's new sexp code for ship/wing flags.

~0014073

FUBAR-BDHR (developer)

There are still some sexps his solution did not cover. I know Kamikaze is one.

~0014075

MjnMixael (manager)

List the flags in question so that the coders don't have to go in search? That way it can be resolved quickly.

~0014076

Goober5000 (administrator)

Last edited: 2012-11-19 10:15

View 2 revisions

Can you make a list of all such sexps? Kamikaze may be one, but that's a special case because it requires an additional argument. In general, his new sexp should cover all ship flags, wing flags, and parse object flags.

EDIT: ninja'd by MjnMixael

~0014080

Goober5000 (administrator)

According to discussion in IRC, the main remaining sexp is in fact the kamikaze sexp. So I'm re-resolving this because the general problem is fixed by karajorma's new sexp for ship flags. The specific issue with this particular sexp is a feature request, and one that karajorma has already stated he is working on.

~0014081

Goober5000 (administrator)

Actually, much as I hate to leave the bug open, the decision should be left to karajorma in this case.

~0014120

karajorma (administrator)

Well if nothing other than Kamikaze is affected, it's probably best to make a new version of that particular SEXP.

Is anything else affected?

~0014126

FUBAR-BDHR (developer)

I'm pretty positive there are other sexps affected but they might not be flags. I need to go back through my old patch and check then check all sexps added since.

From the conversation we had on Kamikaze I though you were going to add a similar sexp to handle all AI flags instead of just fixing the one.

~0014129

FUBAR-BDHR (developer)

These are the other 3 from the original patch. Still need to check all new sexp since r6563

Change-IFF
Change-IFF-Color
Ship-Change-Alt-Name (was updated to support wings in patch)

~0014134

FUBAR-BDHR (developer)

Last edited: 2012-11-20 17:37

View 2 revisions

Ship-Change-Callsign needs updated to handle wings and may have the same issues

These all have the potential to have the issue but unconfirmed.
get-object-pitch
get-object-bank
get-object-heading
set-object-orientation
get-object-speed-x
get-object-speed-y
get-object-speed-z
set-arrival-info
set-departure-info



These should be handled by the new sexp. Listing for confirmation.
turret-protect-ship
turret-unprotect-ship
set-mobile
set-immobile
set-subspace-drive

~0014138

Goober5000 (administrator)

All of these sexps listed here...

get-object-pitch
get-object-bank
get-object-heading
set-object-orientation
get-object-speed-x
get-object-speed-y
get-object-speed-z
set-arrival-info
set-departure-info

...are instantaneous sexps, affecting only the ship or wing on which they are called. They affect immediate attributes of the ships, not the ships' flags. Having a version of these sexps that affects ships in future wings makes no sense, nor is it needed.

~0014139

Goober5000 (administrator)

And these sexps...

turret-protect-ship
turret-unprotect-ship
set-mobile
set-immobile
set-subspace-drive

...all deal with flags, so they should indeed be covered.

~0014140

FUBAR-BDHR (developer)

So what you are saying is if you have a wing of ships with multiple waves launching from a ship, you jump that ship out, jump a new ship in, and use set-arrival-info on that wing to change it to the new ship the only ships that should be changed are the ones already in the mission. That makes no sense.

What if you want to point a ship that hasn't arrived yet to always jump in facing toward the player?

I will admit that the get-object sexps seem kind of useless for parse objects but just because I can't think of a use for it right now doesn't mean someone won't think of one.

~0014141

MjnMixael (manager)

I dunno. That seems like over extended use of specific SEXPs that might be better served by simply setting up wings like Beta#1 Beta#2.. but I guess there's downsides to that as well. But let's be honest, we are talking about exceedingly rare circumstances here.

~0014142

Goober5000 (administrator)

"So what you are saying is if you have a wing of ships with multiple waves launching from a ship, you jump that ship out, jump a new ship in, and use set-arrival-info on that wing to change it to the new ship the only ships that should be changed are the ones already in the mission. That makes no sense."

If you use set-arrival-info on the wing, the wing's departure is changed. If you use set-arrival-info on the ship, the ship's departure is changed. These are two different things, as opposed to changing wing flags which is just the same as changing ship flags for every ship in the wing.

Furthermore, only affecting ships that are already in the mission (or more accurately, only affecting ships that have a particular ship name) should be the default case. The only reason we have this weird situation with ship flags affecting ships in future waves is because Volition adopted a policy of generating new waves of ships by cloning previous waves.

Plus, this is all hypothetical. There have been scenarios where mission designers have needed to specify ship flags as affecting or not affecting future waves. There have not, so far, been situations where they have needed to use ship-arrival-info.

I say this bug should be resolved after Karajorma codes the new kamikaze sexp. Any other problems can be tackled as they arise.

~0014145

karajorma (administrator)

"These should be handled by the new sexp. Listing for confirmation.
turret-protect-ship
turret-unprotect-ship
set-mobile
set-immobile
set-subspace-drive"

They are indeed covered.

As for the IFF SEXPs, are they currently broken? Cause someone does seem to have patched them to use OSWPT_TYPE_WING_NOT_PRESENT at some point.

~0014146

FUBAR-BDHR (developer)

That wouldn't fix the issue. If passed a ship that is in a wing it will still exhibit 2 different behaviors depending on if that ship has arrived or not. It will hit the case OSWPT_TYPE_SHIP, break, and not get to case OSWPT_TYPE_PARSE_OBJECT: See the attached iff_test.txt for a description of the original issue with ships in a wing when the ship is in mission.

~0014147

karajorma (administrator)

And it's only those 3 SEXPs (+kamikaze) which display this behaviour?

~0014149

FUBAR-BDHR (developer)

Basically any sexp that calls sexp_get_object_ship_wing_point_team() has the potential to have the problem unless that sexp doesn't work on ships or only works on ships currently in game.

For example sexp_num_ships_in_battle() does not have the issue because checking parse which haven't arrived yet to see if they have arrived would just be dumb.

Then you have something like sexp_is_iff() which doesn't set anything (so wasn't part of this bug) but would need changed. It does check parse objects and does check wings but doesn't check wings that haven't arrived. As you are checking a specific ship and not setting any values I don't see the second part of dealing with ships in wings as applying here.

Then you have the change_iff() sexp which at the time didn't handle wings that haven't arrived and still has different behavior when passed a ship that is in a wing depending on if that ship is in mission or not. Also looking at this further the fix for wings not in mission is not consistent with retail behavior of the other change sexps. This is why it needs to be optional on changing parse objects or not. While this sexp did not handle wings in retail it's been taking them since something like r250 and the fix applied for wings that haven't arrive has the potential to break any mission written since then.

So add is-iff to that list and I'll tripple check all other sexps using sexp_get_object_ship_wing_point_team() although some I have no idea what they should do.

~0014150

FUBAR-BDHR (developer)

That is the only other one I found although I can't figure out what the heck add-nav-waypoint is trying to do with an undocumented 4th argument (which I'm filing as a new bug) so that one will need looked at.

So it's

Kamikaze
change-iff
change-iff-color
ship-change-alt-name
ship-change-callsign

and I'm still going to argue that

set-arrival-info
set-departure-info
set-object-orientation

should be made constant and with the others and that all those get ones listed above should be looked at. Actually you should do a search on sexp.cpp for sexp_get_object_ship_wing_point_team and double check my triple check.

~0014158

karajorma (administrator)

Is there currently a system for upgrading SEXPs in place?

If I add a Ship-Kamikaze SEXP I'd rather it automatically upgraded the current Kamikaze SEXP rather than having two very similar SEXPs available in FRED.

~0014162

FUBAR-BDHR (developer)

Well that was what the #define SEXP_SHIP_WING_ADV_STRING "<ship wave carry>" was for. It allowed upgrading those sexps without making new ones but that never happened.

~0014163

Goober5000 (administrator)

FUBAR: It would have taken quite a bit more work than just defining "<ship wave carry>" to upgrade those sexps.

Karajorma: Unless you're thinking of the sexp deprecation mechanism (e.g. replacing set-ship-position with set-object-position) there isn't. Technically you could signal applying to all future wings by specifying a negative damage, but that's a terrible hack.

I don't like the idea of making a special sexp any more than you do, and frankly, I'd rather just call this a special case and use when-argument to set the kamikaze on ships in future waves.

~0014164

Goober5000 (administrator)

Actually, wait. The OSWPT_TYPE_FUTURE_WING that FUBAR mentioned sounds very similar to the OSWPT_TYPE_WING_NOT_PRESENT that was actually added. Has the kamikaze sexp actually been tested with the new code?

~0014166

FUBAR-BDHR (developer)

Yes and I did all the work required to upgrade them YEARS ago. It was shelved. I can tell you by just looking at your changes that there is no way it can work as it should and like I said above breaks compatibility with builds since around r250.

~0014168

karajorma (administrator)

What I'll do is upgrade those SEXPs then. I'll make a new sexp similar to the existing ones and add an argument before the ship list that says whether or not to apply it to future wings. I'll add a third legacy argument which makes the SEXP act just like it did before.

Then I'll simply hide the old version of the SEXP and have the parser automatically upgrade to the new version internally.

Doing that for every single SEXP that had this issue was a pretty large fix and that's why we kept trying to think of a better one. But doing it for a small number of SEXPs is possible.

~0014170

Goober5000 (administrator)

"I can tell you by just looking at your changes that there is no way it can work as it should and like I said above breaks compatibility with builds since around r250."

Explain, please. Because I tested this extensively in cooperation with MjnMixael a few months ago and it works for set-arrival-info and set-departure info. It should therefore work with kamikaze.

~0014172

FUBAR-BDHR (developer)

Last edited: 2012-11-23 22:52

View 2 revisions

Very simple. What happens if you supply a ship that's part of a wing as an argument and that ship is in the game and what happens if it's not. 2 different behaviors because if it's in the game it will never process parse objects because case OSWPT_TYPE_SHIP: will be hit for the ship that is in the game, a break will occur before case OSWPT_TYPE_PARSE_OBJECT:. If it's not in the game then OSWPT_TYPE_SHIP: will be skipped and all versions of that ship will be processed in OSWPT_TYPE_PARSE_OBJECT:.

Check your fix and check mine for change IFF. Here's that patch in case the SCP lost it when I gave it to them 2 years ago when I got tired of dealing with this crap. http://fubar5.fubar.org/fs2netd/future_wings_final.patch

~0014176

karajorma (administrator)

I'm wondering if we shouldn't move the Future Wings / No Future Wings stuff into OSWPT itself by adding a final parameter stating whether this involves future wings or not.

That way we avoid this nonsense in the future as the existence of this parameter will warn coders that they must consider this issue and will give them a simple on/off for it.

~0014178

Goober5000 (administrator)

I think that's just propagating a bad design decision. Really, the sexps should be applicable only for the ships on which they're called. Relying on future waves cloning existing ships is going to be problematic and brittle any way you code it. (Also, remember that Volition's own developers warn that certain ships may be cloned more frequently than other ships due to wave thresholds.)

The correct way to fix this issue is not by adding another layer of hacks but by providing a well-designed way to access future waves of ships. So this discussion should really be about the best way to do that.

One possibility could be adding a WING_OF handler for any-argument that would generate all ship names for a given wave or waves of a wing. You could specify the "current" wave, a particular wave number, or a wave number range.

~0014241

karajorma (administrator)

To be honest, I'm not at all fond of that solution as it still leaves the original bug there to trip up any FREDder who doesn't know about its existence (which quite frankly is almost all of them).

The best solution is to move the code into OSWPT and then redesign the current SEXPs to use it. This ensures that future coders don't add new SEXPs with this design flaw in them.

Adding a special handler simply means that we have a way to get the expected behaviour in all the future SEXPs we add. The fact that even after FUBAR reported this bug you still managed to code in a SEXP with this design flaw shows that we're just going to keep adding broken SEXPs if we don't make it obvious whether a SEXP affects future waves or not.

~0014252

Goober5000 (administrator)

As I said before, sexps should only be applicable for the ships on which they're called. Suppose you have Iota wing, consisting of 4 ships with 2 waves. If the sexp sets the ship flag on Iota 3 and *also* Iota 3's parse object, then Iota 7 will have the same flag setting.

Therefore, modifying the OSWPT code violates expectations for the sake of handling a special-case situation. I don't see how that makes it the best solution.

~0014253

FUBAR-BDHR (developer)

Except that is RETAIL BEHAVIOR for a ship in a wing that hasn't arrived.

~0014254

Goober5000 (administrator)

But it is NOT retail behavior for a ship that has already arrived. Modifying the OSWPT code would change this.

~0014255

karajorma (administrator)

So we make sure the code has three modes, On, off and legacy. And we make sure that no new SEXPs set it to legacy mode.

Not fixing this in the OSWPT code merely invites other coders to keep on screwing up.

~0014496

MjnMixael (manager)

Setting to 3.7 as remaining steps are not priority for 3.6.16.

~0017004

Goober5000 (administrator)

Karajorma and I think all issues here have been addressed.
+Notes

-Issue History
Date Modified Username Field Change
2009-11-23 17:08 FUBAR-BDHR New Issue
2009-11-24 05:13 FUBAR-BDHR File Added: Future_wings.patch
2009-11-24 05:14 FUBAR-BDHR File Added: IFF_Test.txt
2009-11-24 05:15 FUBAR-BDHR Note Added: 0011337
2010-04-21 02:32 FUBAR-BDHR Status new => assigned
2010-04-21 02:32 FUBAR-BDHR Assigned To => FUBAR-BDHR
2010-06-27 03:02 Goober5000 Note Added: 0012145
2012-11-19 02:32 Goober5000 Note Added: 0014067
2012-11-19 02:32 Goober5000 Assigned To FUBAR-BDHR => karajorma
2012-11-19 02:32 Goober5000 Status assigned => resolved
2012-11-19 02:32 Goober5000 Resolution open => fixed
2012-11-19 10:07 FUBAR-BDHR Note Added: 0014073
2012-11-19 10:07 FUBAR-BDHR Status resolved => feedback
2012-11-19 10:07 FUBAR-BDHR Resolution fixed => reopened
2012-11-19 10:13 MjnMixael Note Added: 0014075
2012-11-19 10:14 Goober5000 Note Added: 0014076
2012-11-19 10:15 Goober5000 Note Edited: 0014076 View Revisions
2012-11-19 11:12 Goober5000 Note Added: 0014080
2012-11-19 11:12 Goober5000 Status feedback => resolved
2012-11-19 11:12 Goober5000 Resolution reopened => fixed
2012-11-19 11:18 Goober5000 Note Added: 0014081
2012-11-19 11:18 Goober5000 Status resolved => assigned
2012-11-19 11:18 Goober5000 Resolution fixed => open
2012-11-20 04:53 karajorma Note Added: 0014120
2012-11-20 11:05 FUBAR-BDHR Note Added: 0014126
2012-11-20 12:50 FUBAR-BDHR Note Added: 0014129
2012-11-20 16:41 FUBAR-BDHR Note Added: 0014134
2012-11-20 17:37 FUBAR-BDHR Note Edited: 0014134 View Revisions
2012-11-20 22:39 Goober5000 Note Added: 0014138
2012-11-20 22:40 Goober5000 Note Added: 0014139
2012-11-20 23:27 FUBAR-BDHR Note Added: 0014140
2012-11-20 23:32 MjnMixael Note Added: 0014141
2012-11-21 01:13 Goober5000 Note Added: 0014142
2012-11-21 23:45 karajorma Note Added: 0014145
2012-11-22 01:39 FUBAR-BDHR Note Added: 0014146
2012-11-22 06:42 karajorma Note Added: 0014147
2012-11-22 13:42 FUBAR-BDHR Note Added: 0014149
2012-11-22 14:41 FUBAR-BDHR Note Added: 0014150
2012-11-23 01:55 karajorma Note Added: 0014158
2012-11-23 12:23 FUBAR-BDHR Note Added: 0014162
2012-11-23 12:35 Goober5000 Note Added: 0014163
2012-11-23 12:38 Goober5000 Note Added: 0014164
2012-11-23 13:15 FUBAR-BDHR Note Added: 0014166
2012-11-23 20:35 karajorma Note Added: 0014168
2012-11-23 21:42 Goober5000 Note Added: 0014170
2012-11-23 22:45 FUBAR-BDHR Note Added: 0014172
2012-11-23 22:52 FUBAR-BDHR Note Edited: 0014172 View Revisions
2012-11-24 03:21 karajorma Note Added: 0014176
2012-11-24 22:24 Goober5000 Note Added: 0014178
2012-12-01 02:25 karajorma Note Added: 0014241
2012-12-02 01:29 Goober5000 Note Added: 0014252
2012-12-02 01:36 FUBAR-BDHR Note Added: 0014253
2012-12-02 01:54 Goober5000 Note Added: 0014254
2012-12-02 02:03 karajorma Note Added: 0014255
2012-12-17 00:22 Goober5000 Changeset attached => fs2open trunk r9443
2012-12-17 00:29 Goober5000 Changeset removed fs2open trunk r9443 =>
2012-12-17 00:44 MjnMixael Note Added: 0014496
2012-12-17 00:44 MjnMixael Target Version => 3.7.0
2020-07-08 00:58 Goober5000 Status assigned => resolved
2020-07-08 00:58 Goober5000 Resolution open => fixed
2020-07-08 00:58 Goober5000 Note Added: 0017004
+Issue History