Source Code Project Mantis - FSSCP
View Issue Details
0002097FSSCPgameplaypublic2010-01-19 04:082013-01-13 03:54
ReporterFUBAR-BDHR 
Assigned ToGoober5000 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version3.6.11 
Target VersionFixed in Version 
Summary0002097: Ships in wings with departure via docking bay warp when orderd to leave instead of using the bay
DescriptionIf you set a wing to depart via docking bay but use the comm menu to order them out the ships will warp instead of leaving by the bay. Individual ships ordered to leave do use the docking bay. It doesn't matter if you use order a ship, wing, or all ships.

Additional Information3.6.11 r5828

Changing the ships in the wings departure from hyperspace to docking bay in notepad results in them departing via docking bay. So it seems the orders are being given to the individual ships not the wings. Since the ships themselves can't be set to depart via docking bay in FRED text editor is the only way to make it work currently.
TagsNo tags attached.
Attached Files? DockingBayDepartA.fs2 (6,342) 2012-11-19 09:50
http://scp.indiegames.us/mantis/file_download.php?file_id=1976&type=bug
? DockingBayDepartB.fs2 (6,350) 2012-11-19 09:50
http://scp.indiegames.us/mantis/file_download.php?file_id=1977&type=bug
? DepartTest.fs2 (11,880) 2012-12-06 20:07
http://scp.indiegames.us/mantis/file_download.php?file_id=2024&type=bug
patch bay_departure_v3.patch (8,905) 2012-12-09 18:19
http://scp.indiegames.us/mantis/file_download.php?file_id=2038&type=bug

Notes
(0011549)
KeldorKatarn   
2010-01-21 09:50   
Could this be related to issue 0001953 ?
(0011582)
Goober5000   
2010-01-24 17:27   
Nope. Different issue.
(0014070)
MjnMixael   
2012-11-19 09:38   
(Last edited: 2012-11-19 09:51)
Confirmed still an issue on 9357. Test missions to be uploaded shortly.

Missions added. Mission A is current behavior and is wrong. Mission B has the text edits as suggested, but currently crashes FRED and FSO.

(0014341)
Admiral MS   
2012-12-06 17:25   
(Last edited: 2012-12-06 17:59)
Uploaded a patch to fix this: bay_departure.patch
Includes some updated checks to prevent further waves arriving, wing still appearing in com menu and such stuff.

Edit: I think the original code implies that this bug may have been intended behaviour, not sure if this will cause any issues. Ships not in wings already got their departure info and obeyed it for the warp-out ai-order and with the patch wings will do the same.

(0014342)
MjnMixael   
2012-12-06 17:39   
Works for me. Good job!
(0014344)
MjnMixael   
2012-12-06 20:07   
Mission added to allow for testing departure when mother ship is and isn't present.
(0014351)
Admiral MS   
2012-12-07 14:44   
So here is another patch that also covers things like the target ship departing and anything else that may lock a wing if the departure failes.
Basically wings will have the same behaviour that ships not in a wing already have:
- they obey the departure info set in fred for any type of warp-out or departure order
- they use a fighterbay if they can and if this isn't possible (capship has departed/ not arrived before order was given) just subspace jump out
- they won't other accept orders as long as they fly to the bay
- they will again accept orders and stop their approach if the capships departs or get's destroyed

Now fixing this bug may break missions that assumed wings will always depart via subspace unless the condition in departure info set in ship editor turns true. MjnMixael suggested making the change an option in mod.tbl. I'm not sure if I should do this.

-------------

Additionally the currently working ship departure options to fighter bays are inconsistent. They differ between ships that are part of a wing and ships that aren't in case the ship with fighter bay departs or gets destroyed. When setting a departure condition in the ship editor wings will stop, lock up and ignore any further orders while ships no in a wing will automatically warp out some seconds later. If a ship not in a wing gets the depart order by sexps or player then they will just stop and accept new orders. My patch won't address any of these issues at the moment.
(0014356)
MjnMixael   
2012-12-08 02:17   
Tested. Patch works as detailed out there, but some decisions still need to be made.
(0014372)
Zacam   
2012-12-08 22:39   
Idea: Game Settings flag (suggested by Mjn.Mixael)

This preserves existing behaviour without potentially breaking anything that "relies" on the existing behaviour, but allows us to "correct" for the perception of behaviour and make it unified and consistent.

(0014393)
Admiral MS   
2012-12-09 18:19   
(Last edited: 2012-12-09 18:20)
New patch bay_departure_v3.patch, this time with a game settings flag $Fixed departure settings: True/False

It should cover any wing and departure failures, wing and fighter lockups (cause the target ship went away) and so on.

Behaviour should be consistent now and it is based on what single ships already did:
- Departure cue set in ship editor is true: will force a departure no matter what and renew that order every frame, if set to fighterbay the ship or wing departs to bay or warps if bay not available
- Other departure orders (warp-out sexp, comm menu, scripting) with a fighterbay as target:
--won't accept other orders via comm menu as long as they are departing
--can be stopped by removing or clearing orders. Doing this to a single ship in a wing with departure order will make that ship and wing available for orders again but the other ships will continue their departure
--will fallback to warp out if the ship with fighterbay is not available
--will stop and accept any new orders if the ship with fighterbay gets destroyed or departs

(0014402)
Goober5000   
2012-12-09 23:14   
Here is an additional wrinkle. If you use FRED to add the ai-warp-out goal, the ship should actually warp out, cause that's what the goal says. There are missions out there that use this sexp to cancel departure to a hangar bay.
(0014409)
Admiral MS   
2012-12-10 11:55   
In the case of ships not part of a wing ai-warp-out already made them depart to the bay if set so in departure info.

My fix is only active with a mod.tbl option so it doesn't break anything old. Someone who sets that option should read the description, know what it does and be able to use set-departure-info to get it right.

Clear-goals also stops ship and wing departures to a bay and did so since retail.

I would suggest we change the description of ai-warp-out to what it actually does cause otherwise I have to add an ai-depart goal and modify the current ai-warp-out to reset departure info (all of which can already be done with set-departure-info by a fredder).
(0014640)
Goober5000   
2013-01-12 17:57   
Well, I took a careful look at Admiral MS's patch, and unfortunately, it tries to solve the problem by checking and setting flags outside of the goal code. This won't cooperate well with the existing code, especially if it has to be modified in the future.

I'll take a look at the code over the next hour or two and see what I can do.
(0014644)
Goober5000   
2013-01-12 21:12   
There was a regression from retail code which is what caused the single ships to follow their departure cues. I fixed that.

I've also almost fixed the general design issue that was causing ordered ships to depart. Just have to tie up a loose end with wings...
(0014645)
Goober5000   
2013-01-12 22:19   
Okay, this is fixed as of revision 9501. Retail compatibility is maintained with ai-warp-out, and the comm menu will use the ship or wing departure information.

Issue History
2010-01-19 04:08FUBAR-BDHRNew Issue
2010-01-19 04:23portej05Relationship addedrelated to 0002096
2010-01-21 09:50KeldorKatarnNote Added: 0011549
2010-01-24 17:27Goober5000Note Added: 0011582
2010-01-24 17:27Goober5000Relationship deletedrelated to 0002096
2012-11-19 09:38MjnMixaelNote Added: 0014070
2012-11-19 09:50MjnMixaelFile Added: DockingBayDepartA.fs2
2012-11-19 09:50MjnMixaelFile Added: DockingBayDepartB.fs2
2012-11-19 09:51MjnMixaelNote Edited: 0014070bug_revision_view_page.php?bugnote_id=14070#r226
2012-11-26 00:24Goober5000Assigned To => Goober5000
2012-11-26 00:24Goober5000Statusnew => assigned
2012-12-06 17:24Admiral MSFile Added: bay_departure.patch
2012-12-06 17:25Admiral MSNote Added: 0014341
2012-12-06 17:32Admiral MSNote Edited: 0014341bug_revision_view_page.php?bugnote_id=14341#r285
2012-12-06 17:39MjnMixaelNote Added: 0014342
2012-12-06 17:59Admiral MSNote Edited: 0014341bug_revision_view_page.php?bugnote_id=14341#r286
2012-12-06 20:07MjnMixaelFile Added: DepartTest.fs2
2012-12-06 20:07MjnMixaelNote Added: 0014344
2012-12-07 14:44Admiral MSNote Added: 0014351
2012-12-07 14:44Admiral MSFile Added: bay_departure_v2.patch
2012-12-08 02:17MjnMixaelNote Added: 0014356
2012-12-08 18:49ZacamStatusassigned => code review
2012-12-08 22:39ZacamNote Added: 0014372
2012-12-08 22:39ZacamNote Edited: 0014372bug_revision_view_page.php?bugnote_id=14372#r300
2012-12-09 18:19Admiral MSNote Added: 0014393
2012-12-09 18:19Admiral MSFile Added: bay_departure_v3.patch
2012-12-09 18:20Admiral MSNote Edited: 0014393bug_revision_view_page.php?bugnote_id=14393#r306
2012-12-09 23:14Goober5000Note Added: 0014402
2012-12-09 23:14Goober5000Assigned ToGoober5000 => Admiral MS
2012-12-09 23:14Goober5000Statuscode review => assigned
2012-12-10 11:55Admiral MSNote Added: 0014409
2012-12-10 11:56Admiral MSFile Deleted: bay_departure.patch
2012-12-10 11:56Admiral MSFile Deleted: bay_departure_v2.patch
2013-01-12 17:57Goober5000Note Added: 0014640
2013-01-12 17:57Goober5000Assigned ToAdmiral MS => Goober5000
2013-01-12 21:12Goober5000Note Added: 0014644
2013-01-12 21:26Goober5000Changeset attached => fs2open trunk r9500
2013-01-12 22:19Goober5000Note Added: 0014645
2013-01-12 22:19Goober5000Statusassigned => resolved
2013-01-12 22:19Goober5000Resolutionopen => fixed
2013-01-13 03:54Goober5000Changeset attached => fs2open trunk r9501