Source Code Project Mantis - FSSCP
View Issue Details
0002390FSSCPSEXPspublic2011-01-31 02:072011-01-31 04:18
ReporterFUBAR-BDHR 
Assigned ToGoober5000 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
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? 0scantest2.fs2 (4,368) 2011-01-31 02:07
http://scp.indiegames.us/mantis/file_download.php?file_id=1637&type=bug

Notes
(0012618)
Goober5000   
2011-01-31 04:17   
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   
2011-01-31 04:18   
Fixed in revision 6990.

Issue History
2011-01-31 02:07FUBAR-BDHRNew Issue
2011-01-31 02:07FUBAR-BDHRFile Added: 0scantest2.fs2
2011-01-31 03:19Goober5000Statusnew => assigned
2011-01-31 03:19Goober5000Assigned To => Goober5000
2011-01-31 04:17Goober5000Note Added: 0012618
2011-01-31 04:18Goober5000Note Added: 0012619
2011-01-31 04:18Goober5000Statusassigned => resolved
2011-01-31 04:18Goober5000Resolutionopen => fixed