Apparently (objDestroy obj) and (objDestroy obj nil) have different effects: The first simply deletes the object in question, the second treats the object to have been destroyed but with no destroyer. This is rather unintuitive behavior; you would generally expect them to behave identically.

0xabcdef 3 Jul 2017:

That is intentional. (objDestroy obj) could be renamed to (objRemove obj) while making the destroyer argument mandatory in (objDestroy obj [destroyer])

assumedpseudonym 3 Jul 2017:

 Intentional or not, it’s still unintuitive. If you really need to destroy an object (as opposed to just deleting it) and not link it back to a specific object, (objDestroy obj true) would be a better way to go about it. It would maintain backward compatibility better as there would be no “insufficient arguments” errors involved.

 Basically:

(objDestroy obj1 [obj2|true|nil]) -> Destroy space object

obj1:  Object destroyed
obj2:  Destroying object (can be the same as obj1)
true:  No destroying object
nil or no second argument:  Object removed

 As a current workaround, if you need to destroy and not delete a space object without, for example, calling on retribution forces or some such, you can use (objDestroy obj obj) and add in a check like (eq destroyedObj destroyingObj) to prevent unwanted behavior.

george moromisato 21 Jul 2017:

Unfortunately, sometimes we call objDestroy with two args expecting the second arg to sometimes be nil (because the destroyer got destroyed). In that case, we always want to destroy (not remove).

I agree it is unintuitive, but I'd rather fix it a different way (perhaps by doing what Archannon suggests: split into two different functions).

wolfy 27 days ago:

Here is a PR that splits it into two different functions, and updates all the core uses of objDestroy (single argument) to objRemove.
https://github.com/kronosaur/TranscendenceDev/pull/110