2018-08-21 22:09 EDT


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002390FSSCPSEXPspublic2011-01-31 04:18
ReporterFUBAR-BDHR 
Assigned ToGoober5000 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version3.6.13 
Target VersionFixed in Version 
Summary0002390: sexp_set_cargo() crash
DescriptionI was working on adding additional functionality to cargo scanning when I hit this bug. Went back to trunk and it still occurred. Basically something is wrong with line 10786:

ss->subsys_cargo_name = cargo_index | (ss->subsys_cargo_name & CARGO_NO_DEPLETE);

And probably 2 other lines with similar syntax. Changing it to ss->subsys_cargo_name = cargo_index; fixes the issue. CARGO_NO_DEPLETE isn't even a subsystem flag it's a ship flag. Why it's even trying to be set here I have no idea. If it's set nothing here would unset it so it would stay set.

Hopefully someone can shed some more light on this. Attaching mission that causes the crash. Just scan the comm subsystem which will set the cargo on the sensors then scan the sensors.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0012618

Goober5000 (administrator)

CARGO_NO_DEPLETE is a *cargo* flag, not a ship flag. It means that when a ship transfers its cargo to another ship, it should still retain its cargo name.

The function of the OR statement is to ensure the CARGO_NO_DEPLETE flag remains persistent even when the cargo changes. Otherwise, setting the cargo would overwrite the flag.

The problem is not that the OR statement was present, it's that something else (the CARGO_INDEX_MASK) was absent. I've taken care of this and verified that the mission now works properly.

This illustrates the necessity of checking the history of something you don't understand before removing it. (And not saying you didn't, since you filed the Mantis report, but just as a general advisory.) Removing the OR statement would have fixed the immediate problem but broken the CARGO_NO_DEPLETE feature.

~0012619

Goober5000 (administrator)

Fixed in revision 6990.
+Notes

-Issue History
Date Modified Username Field Change
2011-01-31 02:07 FUBAR-BDHR New Issue
2011-01-31 02:07 FUBAR-BDHR File Added: 0scantest2.fs2
2011-01-31 03:19 Goober5000 Status new => assigned
2011-01-31 03:19 Goober5000 Assigned To => Goober5000
2011-01-31 04:17 Goober5000 Note Added: 0012618
2011-01-31 04:18 Goober5000 Note Added: 0012619
2011-01-31 04:18 Goober5000 Status assigned => resolved
2011-01-31 04:18 Goober5000 Resolution open => fixed
+Issue History