Some functions, such as Orbit -> Periapsis return NaN over part of their range, in this example, where the Periapsis falls below sea level. This is unintuitive as the orbit is well defined even when it results in a collision with a planet (the value for Periapsis is simply negative). Returning NaN results in counterintuitive behavior; for example, I used a while(Orbit.Periapsis < TgtPeriapsis){do... burn for orbit}, but this continued immediately because NaN < anything is always false. Being a programmer who works largely in .NET I was able to figure out a workaround easily enough (&& Orbit.Periapsis > 0), but with the lack of debugger that was still 30+ minutes and multiple test flights to get to the bottom of. At minimum odd behavior like this needs to be in function documentation (tooltips, etc). Exposing the double.IsNaN function would also mitigate this somewhat. Overall though if the goal is to make this approachable to non-programmers/first programing language students, functions should avoid returning NaN, if they must then clearly advertise the range over which they're defined, and provide/expose the tools to cleanly handle NaN.
2 Comments
- Log in to leave a comment
-
We need nodes such as Nodes like
bool: IsNan(value);
bool: IsNanOr(value, func<bool>); // check NAN OR passed boolean check
bool:IsNanOrLessThan(value, lessThan);
bool:IsNanOrGreaterThan(value, greaterThan);
Simply writing the following loop is 100% failure because of
NAN
.
This is counter intuitive and not first time user friendly.
No user who is new to SR2 will expectNAN
from any node whatsoever.
// loop executing while no periapsis exists yet:
// 100% failure rate while periapsis is NAN
while(orbit:periapsis less-than orbit:aopopsis)
{
// do stuff
}
So the only way to garuntee the above loop executes is to add multiple extra comparison checks for ALL rockets during launch and ascent - resulting in higher (and unessesary) complexity.
I think the root cause is taking the periapsis from the surface instead of the center of the planet..