Make ENCOUNTER return null OrbitInfo with default values.

[a1270]

Somewhat addresses #243 but the real issue that needs to be fixed is eluding me for now.

if encounter == "Mun" { awesome things }.

In the above example i believe kOS doesn't think value 2 is a string. A simple workaround is to declare a variable and compare that.

set trgt to "Mun".
if encounter == trgt { magic things }.

monodevel and it's indenting RAGE

[Dunbaratu]

That workaround is NOT a workaround. If encounter is "None", then you can treat it like a plain string. But if it's not "None" then it's en entire structure and it gives an error to compare it to a string. You have to explicitly append :BODY:NAME to make it into something that you're allowed to compare to a string. Thus the same statement can't handle both the "none" case and the "Mun" case.

In your example it fails to run when I run it. if encounter is in fact the Mun, then the expression (encounter = "Mun") actually errors out because it lacks the :BODY:NAME part.If encounter is "None", on the other hand, then it runs fine.

Thus the case where the body of the check, { awesome things }., is supposed to run, can never actually happen. The only way the expression doesn't error out is if encounter is "None".

Anyway, I'm glad it's being fixed at any rate.

[a1270]

I may be missing something. This is the master build http://i.imgur.com/pfSpeSW.jpg http://i.imgur.com/ZkjWaXw.jpg and holds true on the spaceport version. I am seriously confused by :BODY:NAME as subelements don't support subelements(yet). ENCOUNTER always returns the body of the encounter or, if none, "None".

You could also check against BODY(celestial body):name. I used a var originally as you can change it later if need arise.

if encounter == mun:name { stuff }.

EDIT: Seems subelements do support subelements. Don't know why i didn't think they did.

[Dunbaratu]

The problem is that where you were using strings inside variables in all your examples and I was testing with literal strings.

The fact that this: if encounter == "Mun" {stuff.}. does not handle the types of the operands in exactly the same way as this does:

set stringVariable to "Mun".
if encounter == stringVariable {stuff.}.

Was only explained just recently. It's utterly unlikely that anyone would assume those two are different. They're both comparing encounter to a string type, so any place the system complains about mismatched types in the comparison should be the same for both, or so one would think.

The fact that the version with the variable forces encounter to cast itself to a string for the comparison to occur, while the version with the literal string does not, is why I got errors in places you didn't.

The fact that string comparisons only cause casting when comparing to a string variable and not when comparing to a string literal is the real bug here underlying all this as it turns out. But you didn't explain that odd quirk of the language until much later. It's relevant to why your examples worked and mine didn't, and it's really not what one wold expect.

[a1270]

I'll blame it on being too close to the issue but apologize anyways. I'm looking into the real bug now.