2019-12-09 21:21 EST


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002343FSSCPgameplaypublic2011-11-10 07:20
ReporterFSF 
Assigned ToEchelon9 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version3.6.13 
Target VersionFixed in Version3.6.14 RC1 
Summary0002343: Assert on arriving from destroyed ship
DescriptionTransport arrives from fighterbay of a destroyed station -> assert. Tested on (today's) Nightly 6773.
Additional InformationAttached mission (runs on retail) produces the assert 30 seconds into the mission.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0012492

Echelon9 (developer)

I believe the current approach is the correct one. In Release, nothing will happen. In Debug, it will Assert with the explanation that having a ship arrive from a destroyed fighterbay doesn't make much sense. Where in space would the ship be arriving from?

The check has been there for some time, it looks like previously we weren't setting the P_SF_CANNOT_ARRIVE flag on destroyed objects.

Just because it is in Retail doesn't make it necessarily correct.

~0012493

FSF (reporter)

Well, asserts are always kinda hard to interpret. Something like "Warning: <ship name> cannot depart from <ship name> fighterbay" would be more useful.

~0012494

The_E (administrator)

Actually, an assert or warning popup would be wrong here. All that is warranted is a mention in the log (Ship X was set to arrive from bay Y on object Z, but Z doesn't exist anymore), as a mission designer might want to set it up that something like this might happen (imagine a scenario where you're escorting a bunch of non-critical ships that launch reinforcements after some time).

~0012495

Echelon9 (developer)

I agree, in this circumstance a mention in the log is all that should occur in Debug; and no event in Release.

~0012949

FSF (reporter)

For reference: still asserts on 3.6.14 RC1.

~0012950

Echelon9 (developer)

Thanks for reminding me I had the patch sitting on my laptop.

Fix committed to r7971. If one of the good build maintainers approvers, it'll be in RC2.
+Notes

-Issue History
Date Modified Username Field Change
2010-11-23 17:18 FSF New Issue
2010-11-23 17:18 FSF File Added: Test_arv.fs2
2010-11-29 09:27 Echelon9 Note Added: 0012492
2010-11-29 09:27 Echelon9 Status new => feedback
2010-11-29 09:27 Echelon9 Status feedback => assigned
2010-11-29 09:27 Echelon9 Assigned To => Echelon9
2010-11-29 14:18 FSF Note Added: 0012493
2010-11-30 02:27 The_E Note Added: 0012494
2010-11-30 08:16 Echelon9 Note Added: 0012495
2011-06-24 00:47 Zacam Category --------- => gameplay
2011-11-10 04:38 FSF Note Added: 0012949
2011-11-10 07:20 Echelon9 Note Added: 0012950
2011-11-10 07:20 Echelon9 Status assigned => resolved
2011-11-10 07:20 Echelon9 Fixed in Version => 3.6.14 RC1
2011-11-10 07:20 Echelon9 Resolution open => fixed
+Issue History