|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002390||FSSCP||SEXPs||public||2011-01-31 02:07||2011-01-31 04:18|
|Target Version||Fixed in Version|
|Summary||0002390: sexp_set_cargo() crash|
|Description||I 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.
|Tags||No tags attached.|
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.
|Fixed in revision 6990.|
|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|