SHIP:SOLIDFUEL can't be used to detect zero fuel - it bombs with error when fuel is zero.

[Dunbaratu]

The value of SHIP:SOLIDFUEL doesn't return zero when there's no solid fuel. Instead it says "suffix SOLIDFUEL not found on object" and bombs out.

I was trying to modify my ascent script, which used to only work if all the engines are liquid fueled, to handle working when there may or may not be solid boosters attached, but it's currently a mess to try to write the script because of this problem. If I try to query for whether or not solid fuel exists on the ship outside the current stage, the script bombs out while attempting the query.

Note, it does seem to work for STAGE:SOLIDFUEL. That does return zero. But SHIP:SOLIDFUEL, which seems to be taking its value from the KSP resource , is finding no such resource when querying for the SOLIDFUEL resource and thus producing that error.

Note that if you have solid boosters that have just run out and you haven't detached them yet, then SHIP:SOLIDFUEL does return zero. But the moment you decouple them, then SHIP:SOLIDFUEL will bomb out if you try to query it. It seems that as long as a part is attached to the ship that is capable of holding a resource but has run out, then querying for that resource will return zero. (i.e. empty fuel tanks or spent batteries) But the moment the part is no longer attached, then querying for that resource will error out.

i'm not sure how to fix this cleanly, since the KSP API itself seems to treat "this type of resource is currently not part of THIS ship" identically to "this type of resource cannot be part of ANY ship because I've never heard of it." Therefore if you change it to return zero when the resource is not found, then all misspelled resources would return zero as well and that's not desirable.

Rant: This is part of the reason I think it's important to expose some means for the script programmer to perform a boolean check against NULL and NaN conditions, and allow the script writer the means to handle these sorts of conditions instead of making them crash the script. Because there's no exception try/catch in the language, and I agree that implementing it would make the language too complex for entry level people, these conditions end up being impossible to work around.

If ship:solidfuel returned null, and there was a means to check isnull(ship:solidfuel) then I could handle the problem in my own script. Similarly with math functions that return NaN like taking the arccos of a number larger than 1. it's impossible to ever check for this condition currently. When a math function returns NaN you can't ever check for that case in kOSscript and instead you just have a variable that will cause a crash when you try using it.

[marianoapp]

There was a validation to avoid this exact situation but it wasn't working properly. It's fixed now.

Implementing NULL and NaN would be a major change since we would have to check every place where an operation takes place and add the relevant validations. It's simpler to throw an exception like it's doing right now, and let the user add the required range check validations before calling a function.
If you are really interested in having support for NULL and NaN then you should open another issue and we can continue the discussion there.

[Dunbaratu]

Adding null and NaN checks would not require adding code everywhere it could be returned. It would require just adding two functions that return boolean: "is operand a NaN" and "is operand a NULL" - you don't have to care which particular function call caused that sort of value to be returned.

I will open the issue.