if (encounter == encounter) { ... }. // can't compare orbitinfo to orbitinfo ...

[weissel]

if (encounter == encounter) { ... }. // can't compare orbitinfo to orbitinfo ...

[Dunbaratu]

The fact that the type returned when you say "encounter" changes depending on if there's an encounter or there isn't is really annoying. If it exists, then it's an orbitinfo. If it does not exist then it's a string. But you need to write code that handles both cases and doesn't bomb out with error when testing for whether an encounter exists or not. But you don't know which way to write the syntax until after you discover if the encounter is "None" or not, and you can't discover if it's "None" or not until you write the syntax and execute it.

The only solution I've found that works around this is to create a de-facto "casting to string" by doing this:
The expression ("" + encounter) is always reliably a string regardless of whether or not encounter is "None" or is a real body. This is because when it's a string then you add "None" to null string and get "None", whereas when it's a real body, the act of adding an orbitinfo to a string forces the system to run the orbitinfo.toString method to get its string name out, so it's like casting encounter to a string.

So this: (""+encounter)
is always a string no matter what, enabling you to make your check work this way:

if "" + encounter == somebody.name {….}.
Where somebody is Mun, or Minmus, or whatever.

And then if you do want to look at the parts of the orbitinfo structure, you can protect those checks like so:

isEnc on.
if "" + encounter == "None" { isEnc off. }.
if isEnc {
// There is an encounter, so do something with it here.
}.

(The reason for the strange extra lines of logic there is because there's no such thing as a "not" operator in kOS , nor a not-equal-to operator, nor an 'else' statement.)

[JoCRaM]

yup, that's how I do it.