View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002048 | FSSCP | SEXPs | public | 2009-11-23 22:08 | 2020-07-08 04:58 |
Reporter | FUBAR-BDHR | Assigned To | karajorma | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Product Version | 3.6.11 | ||||
Target Version | 3.7.0 | ||||
Summary | 0002048: Several sexps involving setting flags for wings that haven't arrived yet do not work | ||||
Description | Discovered 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 Information | I 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. | ||||
Tags | No tags attached. | ||||
2009-11-24 10:13
|
Future_wings.patch (5,788 bytes)
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 |
2009-11-24 10:14
|
IFF_Test.txt (1,709 bytes)
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 |
|
Patch and results of behavior with the patch uploaded. |
|
Karajorma and I have discussed an alternate solution to this issue. He should get back to you about it shortly. |
|
This is accommodated with Karajorma's new sexp code for ship/wing flags. |
|
There are still some sexps his solution did not cover. I know Kamikaze is one. |
|
List the flags in question so that the coders don't have to go in search? That way it can be resolved quickly. |
|
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 |
|
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. |
|
Actually, much as I hate to leave the bug open, the decision should be left to karajorma in this case. |
|
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? |
|
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. |
|
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) |
|
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 |
|
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. |
|
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. |
|
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. |
|
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. |
|
"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. |
|
"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. |
|
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. |
|
And it's only those 3 SEXPs (+kamikaze) which display this behaviour? |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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? |
|
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. |
|
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. |
|
"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. |
|
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 |
|
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. |
|
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. |
|
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. |
|
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. |
|
Except that is RETAIL BEHAVIOR for a ship in a wing that hasn't arrived. |
|
But it is NOT retail behavior for a ship that has already arrived. Modifying the OSWPT code would change this. |
|
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. |
|
Setting to 3.7 as remaining steps are not priority for 3.6.16. |
|
Karajorma and I think all issues here have been addressed. |
Date Modified | Username | Field | Change |
---|---|---|---|
2009-11-23 22:08 | FUBAR-BDHR | New Issue | |
2009-11-24 10:13 | FUBAR-BDHR | File Added: Future_wings.patch | |
2009-11-24 10:14 | FUBAR-BDHR | File Added: IFF_Test.txt | |
2009-11-24 10:15 | FUBAR-BDHR | Note Added: 0011337 | |
2010-04-21 06:32 | FUBAR-BDHR | Status | new => assigned |
2010-04-21 06:32 | FUBAR-BDHR | Assigned To | => FUBAR-BDHR |
2010-06-27 07:02 | Goober5000 | Note Added: 0012145 | |
2012-11-19 07:32 | Goober5000 | Note Added: 0014067 | |
2012-11-19 07:32 | Goober5000 | Assigned To | FUBAR-BDHR => karajorma |
2012-11-19 07:32 | Goober5000 | Status | assigned => resolved |
2012-11-19 07:32 | Goober5000 | Resolution | open => fixed |
2012-11-19 15:07 | FUBAR-BDHR | Note Added: 0014073 | |
2012-11-19 15:07 | FUBAR-BDHR | Status | resolved => feedback |
2012-11-19 15:07 | FUBAR-BDHR | Resolution | fixed => reopened |
2012-11-19 15:13 | MjnMixael | Note Added: 0014075 | |
2012-11-19 15:14 | Goober5000 | Note Added: 0014076 | |
2012-11-19 15:15 | Goober5000 | Note Edited: 0014076 | |
2012-11-19 16:12 | Goober5000 | Note Added: 0014080 | |
2012-11-19 16:12 | Goober5000 | Status | feedback => resolved |
2012-11-19 16:12 | Goober5000 | Resolution | reopened => fixed |
2012-11-19 16:18 | Goober5000 | Note Added: 0014081 | |
2012-11-19 16:18 | Goober5000 | Status | resolved => assigned |
2012-11-19 16:18 | Goober5000 | Resolution | fixed => open |
2012-11-20 09:53 | karajorma | Note Added: 0014120 | |
2012-11-20 16:05 | FUBAR-BDHR | Note Added: 0014126 | |
2012-11-20 17:50 | FUBAR-BDHR | Note Added: 0014129 | |
2012-11-20 21:41 | FUBAR-BDHR | Note Added: 0014134 | |
2012-11-20 22:37 | FUBAR-BDHR | Note Edited: 0014134 | |
2012-11-21 03:39 | Goober5000 | Note Added: 0014138 | |
2012-11-21 03:40 | Goober5000 | Note Added: 0014139 | |
2012-11-21 04:27 | FUBAR-BDHR | Note Added: 0014140 | |
2012-11-21 04:32 | MjnMixael | Note Added: 0014141 | |
2012-11-21 06:13 | Goober5000 | Note Added: 0014142 | |
2012-11-22 04:45 | karajorma | Note Added: 0014145 | |
2012-11-22 06:39 | FUBAR-BDHR | Note Added: 0014146 | |
2012-11-22 11:42 | karajorma | Note Added: 0014147 | |
2012-11-22 18:42 | FUBAR-BDHR | Note Added: 0014149 | |
2012-11-22 19:41 | FUBAR-BDHR | Note Added: 0014150 | |
2012-11-23 06:55 | karajorma | Note Added: 0014158 | |
2012-11-23 17:23 | FUBAR-BDHR | Note Added: 0014162 | |
2012-11-23 17:35 | Goober5000 | Note Added: 0014163 | |
2012-11-23 17:38 | Goober5000 | Note Added: 0014164 | |
2012-11-23 18:15 | FUBAR-BDHR | Note Added: 0014166 | |
2012-11-24 01:35 | karajorma | Note Added: 0014168 | |
2012-11-24 02:42 | Goober5000 | Note Added: 0014170 | |
2012-11-24 03:45 | FUBAR-BDHR | Note Added: 0014172 | |
2012-11-24 03:52 | FUBAR-BDHR | Note Edited: 0014172 | |
2012-11-24 08:21 | karajorma | Note Added: 0014176 | |
2012-11-25 03:24 | Goober5000 | Note Added: 0014178 | |
2012-12-01 07:25 | karajorma | Note Added: 0014241 | |
2012-12-02 06:29 | Goober5000 | Note Added: 0014252 | |
2012-12-02 06:36 | FUBAR-BDHR | Note Added: 0014253 | |
2012-12-02 06:54 | Goober5000 | Note Added: 0014254 | |
2012-12-02 07:03 | karajorma | Note Added: 0014255 | |
2012-12-17 05:22 | Goober5000 | Changeset attached | => fs2open trunk r9443 |
2012-12-17 05:29 | Goober5000 | Changeset removed | fs2open trunk r9443 => |
2012-12-17 05:44 | MjnMixael | Note Added: 0014496 | |
2012-12-17 05:44 | MjnMixael | Target Version | => 3.7.0 |
2020-07-08 04:58 | Goober5000 | Status | assigned => resolved |
2020-07-08 04:58 | Goober5000 | Resolution | open => fixed |
2020-07-08 04:58 | Goober5000 | Note Added: 0017004 |