[1.12.x] BetterBurnTime v1.10: Provides extra burn-time indicators on the navball for suicide burns & target rendezvous.

[sidfu]

this error appears when i swtich ships. it doesnt spam it just shows once or twice and seems to be thre only on swtiching from one ship to another.

 

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

[BetterBurnTime] Error trying to set whether text is enabled (NullReferenceException) :   at (wrapper managed-to-native) UnityEngine.Behaviour:set_enabled (bool)

  at BetterBurnTime.SafeText.set_Enabled (Boolean value) [0x00000] in <filename unknown>:0 

this is from newest updated 1.1 version

[Snark]

10 hours ago, sidfu said:

this error appears when i swtich ships. it doesnt spam it just shows once or twice and seems to be thre only on swtiching from one ship to another.

 

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

[BetterBurnTime] Error trying to set whether text is enabled (NullReferenceException) :   at (wrapper managed-to-native) UnityEngine.Behaviour:set_enabled (bool)

  at BetterBurnTime.SafeText.set_Enabled (Boolean value) [0x00000] in <filename unknown>:0 

this is from newest updated 1.1 version

Excellent, thanks for the report!  That means that my 1.4.1 fix band-aid is doing its job. 

As far as I can tell, Unity 5 has a bug that causes a particular method call, which should never throw, to throw an exception.  It does so unpredictably and unavoidably, at least as far as I can tell.

I put this SafeText wrapper class around it to contain the damage.  Not only does it trap the exception, but it also has some "cooldown" code in it so that if the exception gets thrown once, it won't touch the native Unity 5 object again until one full second has elapsed.  This is so that it won't spam the log with exceptions, the way it was doing pre-1.4.1.  It's a horrible kludge, and nothing I'd submit for inclusion in the Great Code Hall of Fame, but without knowing why Unity's having conniptions over it, this is about the best I can do for now.

I could just make it silently swallow the exception, and then you'd be none the wiser that anything's going on.    However, I like to log it when it happens, so that at least there's a record of the problem, and if anyone ever notices a correlation about when it happens, then I can learn something.

As I just did-- your observation of "only on switching from one ship to another" is absolutely priceless, thank you for that!  At least now I have some idea of when it happens.  Not that I can actually do anything about it, yet, but (for example) I've got a more useful data point for when I go talk to people who know more about Unity than I do.

Anyway, thank you for the report, and rest assured that this is expected and there's nothing that affects you here.

[sidfu]

only reason i found it is cause the smokescreen 1.1 pre was throwing a error when u went to map. in acutaly the error fro smoke screen has some similarites in that seems like game and mod are on 2 differnt pages. in smokescreen cause mod was saying fx effects should be showing when in map mode but game was saying they should be destoryed(or whatever unity does in that case)

that error for burntime looks like its caused by game cant decide if the betterburn display should be shown or not. the ship switching i did was from map screen from space and i didnt have any nodes up didnt check to see if it showed if u had nodes.

[ExEvolution]

So I tried landing on Minmus using this mod to calculate the suicide burn, and as I got closer to the estimated time, the counter accelerated. It initially told me I had 15 seconds estimated burn, but by the time I was able to react to fire the engine, it nearly skipped 15, by the time I impacted, it said I had 7 seconds of burn time remaining, even though I started as soon as I saw 15 appear.

I recorded it after reloading my save and you can see how fast the timer counts. 

Please give it a moment to process,  just uploaded it.

[Snark]

11 hours ago, ExEvolution said:

So I tried landing on Minmus using this mod to calculate the suicide burn, and as I got closer to the estimated time, the counter accelerated. It initially told me I had 15 seconds estimated burn, but by the time I was able to react to fire the engine, it nearly skipped 15, by the time I impacted, it said I had 7 seconds of burn time remaining, even though I started as soon as I saw 15 appear.

I recorded it after reloading my save and you can see how fast the timer counts. 

Yup.  You're seeing the effect BBT's very simplistic time-to-impact calculator, which I specifically call out in the "Caveats" section of this thread's original post. 

In case you missed it, here's the relevant bit, emphasis added here because this is what you're running into:

On 11/20/2015 at 3:28 PM, Snark said:

• Time to impact is very simplistic. It looks at the elevation directly under the ship, and at your current vertical speed.  It corrects for the acceleration of gravity, but nothing else.  This means that if you're flying over rough terrain, the time-to-impact indicator will be irregular (it will suddenly get shorter when you're flying over an ascending slope, or longer when you're flying over a descending slope).  If you're hurtling horizontally and about to smack into the side of a mountain range looming up in front of you, the mod has no clue.  Be warned.

As soon as I saw your post, I guessed that's what's happening, and looking at the video confirms it.  The counter is suddenly accelerating because the ground is rushing up to meet you.

...Now, at this point, you're probably thinking "well, that's dumb, why didn't Snark just code it to give the right answer instead of being so simplistic?"    And that's a perfectly reasonable question.

The answer is:  because it's hard.

Giving you what you really want (i.e. projecting the path forward and taking varying elevation into account so that it knows where your trajectory will actually intersect terrain) turns out to be considerably more complicated to code than you might think.  The game doesn't have any simple API for getting that information, which means that the mod would have to do all the heavy lifting itself, in iterative fashion.  That would be a lot of complex code to write.  What would make it even more complex would be the need to add some cleverness about caching partial results so that it wouldn't spam the CPU and bog your game down or eat up RAM with GC churn.  In short:  it's a pretty big order, it would take me a lot of time to write, and it's not as though I get paid for this stuff-- I've got a day job, KSP modding is what I do for fun in my spare time.    So I figured "don't let the perfect be the enemy of the good", and a simplistic tracker that gives 90% of the value for 20% of the effort is better than having no impact-tracker feature available at all.

In any case, I'm sorry that you got bitten by this, and thank you for taking the trouble to make a detailed bug report including video.  It's not really your fault that it's a "feature" (well, okay, a missing feature) rather than a bug; you just missed the caveat in the mod description.  Your report was way more bug-reporting diligence than most mod authors are lucky enough to get, so thanks for the effort!

[ebigunso]

Where can I get the older version of this mod for 1.0.5?

[Snark]

6 hours ago, ebigunso said:

Where can I get the older version of this mod for 1.0.5?

Right here (BBT version 1.3.5). 

The slightly more long-winded explanation, about how to get to such a link (for BetterBurnTime, or for any other mod hosted on SpaceDock):

1. Go to the mod's web page (here, for BetterBurnTime)
2. Don't click the "Download" link, because that will just give you whatever version is most current
3. Instead, click the "Changelog" tab
4. That will show you a list of every version of the mod, starting with the most recent.  Each one has a download button and tells you "what version of KSP is this for".
5. Just read down the list until you find a release for the version of KSP you're using, and download that one.

In the case of BetterBurnTime, if you read down the changelog list, you'll see that the most recent version marked for KSP 1.0.5 is version 1.3.5, so that would be the one you'd get (it's the "right here" link I posted above).

[Kerbart]

22 hours ago, Snark said:

Yup.  You're seeing the effect BBT's very simplistic time-to-impact calculator, which I specifically call out in the "Caveats" section of this thread's original post. 

In case you missed it, here's the relevant bit, emphasis added here because this is what you're running into:

As soon as I saw your post, I guessed that's what's happening, and looking at the video confirms it.  The counter is suddenly accelerating because the ground is rushing up to meet you.

...Now, at this point, you're probably thinking "well, that's dumb, why didn't Snark just code it to give the right answer instead of being so simplistic?"    And that's a perfectly reasonable question.

The answer is:  because it's hard.

How dare you not to take this into consideration in your calculations, you worthless scum! I demand that you fix this right now!

Hahaha, now that we have that thankless reaction out of the way...  KER reports the slope underneath the vessel, which makes me suspect that it's exposed through some interface somewhere (I'm truly clueless on mod programming). Now, assuming the slope is easy to read out, you could mitigate this problem by adding "APPROX" next to the burn time if the slope is greater than, say, 5°? That would be a lightweight "fix" that is easy to implement (“nothing is impossible for the man who doesn’t have to do it himself,” as my father used to say) while at the same time reducing the chances that users get caught by a surprise like this. Of course all this can be ignored if the slope is not easy to read out.

Playing stock 1.1 reminded me how how high your mod has climbed on my list of “essential mods,” by the way. Thank you for that.

[Snark]

48 minutes ago, Kerbart said:

KER reports the slope underneath the vessel, which makes me suspect that it's exposed through some interface somewhere (I'm truly clueless on mod programming). Now, assuming the slope is easy to read out, you could mitigate this problem by adding "APPROX" next to the burn time if the slope is greater than, say, 5°? That would be a lightweight "fix" that is easy to implement (“nothing is impossible for the man who doesn’t have to do it himself,” as my father used to say) while at the same time reducing the chances that users get caught by a surprise like this. Of course all this can be ignored if the slope is not easy to read out.

TL;DR:  That's a great idea, and actually I previously considered doing just that.  But chose not to, because reasons.

Okay, now the long-winded version:

From a technical standpoint, what you suggest would be trivially easy.  The game has a convenient API for getting the slope at my location, just takes one line of code to get it.  In fact, I can easily get not just what the slope is directly under the ship, but also which direction it's sloping (i.e. am I going up-slope? down-slope? sideways along the slope?)

Because it would be so easy, I actually considered doing exactly what you suggest.  In fact, I even considered taking it one step further, and just extrapolating linearly (i.e. "assume that the slope is going to continue at the same angle as the ground directly under the ship right now" instead of what it currently does, "assume that the ground is flat and level").  That would be a better approximation, right?

However, having played around with it a bit, I decided not to.  It's a matter of game design and UX, not technical programming.  I came to the conclusion that it would be a cure worse than the disease, from the player's perspective.

The problem is that slope is "noisy"-- any time you have a little 'bump' in the terrain, the slope changes by a lot in a very short distance.  And essentially every solid surface in the solar system is bumpy, except for Minmus' flats.  Even terrain that looks "smooth" to you is very bumpy indeed when you're sailing over it at hundreds of meters per second.  (Try driving a rover at 20+ m/s and turning physics warp up to 4, and see how long your tires last.  You'll quickly see what I mean.) 

So if you're sailing over terrain at a few hundred (or even just several dozen) meters per second, it will usually be the case that the slope is very rapidly "jittering", by a lot.  So if there's any UI calculation or display at all that's based on that slope, it's going to be very hard to make it something useful to a user.  To take your specific recommendation, for example:  there would be two UX problems with that.  The first would be that I'd have yet another visual indicator for the user to have to see and understand, which would add complexity that I prefer to avoid if possible.  (I'm fanatically obsessed with keeping UX as simple as possible.)  The second (and worse) problem is that the indicator would be flickering and blinking all the time. ("It's approximate!  No it isn't.  Now it is!  No it isn't.  Whoops, now it is again!")  It would look horrible.

My idea of extrapolating the slope would make it even worse-- the estimated time would be jumping up and down erratically, by a lot, to the point that it would be totally useless.

Yes, it would be possible to add technical fixes for the above.  I could, for example, take a sliding time-weighted average of observed slope, rather than the actual current slope, in an attempt to smooth out the jitter.  But that would also be more code to write, more code to test, more potential bugs that I'd miss and then have users report and then I'd need to put out another update, etc.  I'd rather have something simple that I know works (if imperfectly) than build something complex, unpredictable, and likely bug-prone.

And the final nail in the coffin:  even if I implemented all of the above, and it worked perfectly... it still wouldn't have solved the problem that ExEvolution ran into.  ExEvolution's problem was not that "the slope is nonzero".  The problem was that the slope suddenly got steep, and the countdown that said "you have 15 seconds" almost immediately jumped to a value much less than that.  Having a feature such as you described would not have solved that.  All that would have happened would be that ExEvolution would have gotten a "WARNING" indication in those last couple of "WTF?" seconds before impact, after the countdown suddenly jumped down, i.e. when it was too late to do anything.  It would have been a redundant warning because it was already obvious that "there's a problem" (since the counter did in fact suddenly jump down).  In fact, such a warning would have accomplished nothing useful to ExEvolution at all.  (Maybe it would have been an indicator that "this is a feature" rather than "this is a bug"... but he'd still be wondering "what the hell just happened?" and would probably still have posted here to ask about it, and rightly so.)

So... if I ever decide to try to actually address the problem for real, I'll probably just add trajectory-extrapolation-to-actual-impact-point and be done with it.  In fact, if I imagine "what would be the next major feature, if any, that I add to BetterBurnTime", my best guess would be that very thing.  But that's not a promise (either for a schedule, or that I'll do it at all), just an idle speculation, so don't quote me on that! 

[KocLobster]

I looked all over SpaceDock and the github repository, and was unable to find what I was looking for. I'm sure this is probably obvious, but I just wanted to make certain. I could not find a version file or anything of the nature saying the minimum KSP version needed for 1.4+. I assume its KSP 1.1 and that 1.0.5 will not run 1.4.x but just wanted to confirm. I guess 1.3.5 is the most up to date version for me then?

[Kerbart]

1 hour ago, Snark said:

TL;DR:  That's a great idea, and actually I previously considered doing just that.  But chose not to, because reasons.

Reasons work for me! Proof once again that something that might seem simple on the surface can add a lot of complications.

I'm all for keeping BBT as simple as can be; that guarantees that it does well what it does without gradually evolving into The Kraken.

[Snark]

1 hour ago, KocLobster said:

I looked all over SpaceDock and the github repository, and was unable to find what I was looking for. I'm sure this is probably obvious, but I just wanted to make certain. I could not find a version file or anything of the nature saying the minimum KSP version needed for 1.4+. I assume its KSP 1.1 and that 1.0.5 will not run 1.4.x but just wanted to confirm. I guess 1.3.5 is the most up to date version for me then?

Yeah, someone else was also complaining about that same problem recently.  I'm sorry about that.  I really should just add a "changelog.txt" or something to the mod's directory, with a version history, to make it easier for folks to figure out that sort of thing.

In the meantime, the way you answer the question is to go to the mod's page on SpaceDock and click on the "Changelog" tab.  It lists all published versions of the mod (starting with the most recent).  For each version, it gives not only the date, but also the KSP version for that version of the mod.

To save you the trouble of looking it up right now:

• If you're running KSP 1.0.5, you should install BBT version 1.3.5.
  • That's the newest version of BBT that will run on KSP 1.0.5.
  • Nothing 1.4 or later will run on 1.0.5.
  • Note that it will always be 1.3.5.  I don't plan on releasing any further versions of BBT for 1.0.5.
• If you're running KSP 1.1, you should install the latest BBT, which is currently version 1.4.1.
  • That will change whenever I release a new version.
  • If you're running 1.1, the oldest BBT version you can run is 1.4.  BBT versions before 1.4 won't run in KSP 1.1.

Sorry for the confusion!

[KocLobster]

Thanks for clarifying @Snark! I figured that 1.3.5 was the most up to date for my version of KSP...I also figured it'd be the last version put out for 1.0.5. Unfortunately, I haven't bothered updating to 1.1 yet just because there are so many mods that have not been updated yet and are incompatible with 1.1. I use a lot of mods, and a good number of them I just can't imagine playing without. 

[ebigunso]

12 hours ago, Snark said:

Right here (BBT version 1.3.5). 

The slightly more long-winded explanation, about how to get to such a link (for BetterBurnTime, or for any other mod hosted on SpaceDock):

1. Go to the mod's web page (here, for BetterBurnTime)
2. Don't click the "Download" link, because that will just give you whatever version is most current
3. Instead, click the "Changelog" tab
4. That will show you a list of every version of the mod, starting with the most recent.  Each one has a download button and tells you "what version of KSP is this for".
5. Just read down the list until you find a release for the version of KSP you're using, and download that one.

In the case of BetterBurnTime, if you read down the changelog list, you'll see that the most recent version marked for KSP 1.0.5 is version 1.3.5, so that would be the one you'd get (it's the "right here" link I posted above).

Thank you! I'm totally gonna love this one, I know it.

[Gen. Jack D. Ripper]

Would it be possible to make it possible to configure the time-to-burn increments? One of the things I'd like to use this for is knowing when to slow down or stop time-warping. The current increments just aren't very useful for that: two or three dots that take a long time to go by, and then the rest flash by.

Actually, if I had my *real* wish, it'd be for the option to display time-to-burn in the same d/h/m/s format as the time-to-impact display - it would be (in my view) the most intuitive, broadly useful, and stock-alike way of displaying that information.

[Snark]

3 hours ago, Gen. Jack D. Ripper said:

Would it be possible to make it possible to configure the time-to-burn increments? One of the things I'd like to use this for is knowing when to slow down or stop time-warping. The current increments just aren't very useful for that: two or three dots that take a long time to go by, and then the rest flash by.

That wouldn't be too hard, and actually sounds like a nice idea.  I haven't run into this problem myself, but that may be that I've just trained myself to control warp in a way that's friendly to the countdown indicator, when actually it should be the other way around. 

A simple config setting that's a list of numbers corresponding to elapsed seconds wouldn't be hard to add.  (It wouldn't even have to be the same length as the number of dots-- if it's too long the extra just doesn't get used, and if it's not long enough I'd just double the time per dot for the remainder, same as what I'm doing now.)

Thanks, I'll bear that in mind for the next update.

 

3 hours ago, Gen. Jack D. Ripper said:

Actually, if I had my *real* wish, it'd be for the option to display time-to-burn in the same d/h/m/s format as the time-to-impact display - it would be (in my view) the most intuitive, broadly useful, and stock-alike way of displaying that information.

Also an interesting idea.  I'll have to think about it.  If I did implement this, it would be an option (i.e. "show a timer instead of dots"), with the default setting being "show the dots" (i.e. the current behavior).

Rationale:  I would hate this for my own gameplay; too many numbers.  I've been playing KSP for a couple of years with just two (2) numbers staring at me, and I would have cognitive dissonance if there were more than that.  For something as simple as "start now!", I want a graphical thing, not a textual thing.  But I could see how it would be handy to have this option for someone who has a different way of playing than I do, or whose brain is better wired for looking at lots of numbers.

So, I'm happy to load up BetterBurnTime with plenty of options so that users can tune it just how they like, but when it comes to picking "what should the default setting be?", the answer will always be "whatever settings Snark plays with." 

Anyway, thanks for the ideas-- I'll definitely keep them in mind for the next update.  Might be a little while, I'm currently working on my next mod and would like to get it to a reasonable stopping-and-publishing point before circling back to BBT.

[smjjames]

On 4/10/2016 at 8:24 PM, sidfu said:

this error appears when i swtich ships. it doesnt spam it just shows once or twice and seems to be thre only on swtiching from one ship to another.

 

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

[BetterBurnTime] Error trying to set whether text is enabled (NullReferenceException) :   at (wrapper managed-to-native) UnityEngine.Behaviour:set_enabled (bool)

  at BetterBurnTime.SafeText.set_Enabled (Boolean value) [0x00000] in <filename unknown>:0 

this is from newest updated 1.1 version

Just came over here to report that one. Still happens in 1.1 full and happens on scene change in general maybe, when switching from flight to VAB or launching from VAB/SPH.

edit: I think this might be contributing to a maybe memory leak or a general increase in memory usage, not sure....

Edited April 21, 2016 by smjjames

[Snark]

16 hours ago, smjjames said:

Just came over here to report that one. Still happens in 1.1 full and happens on scene change in general maybe, when switching from flight to VAB or launching from VAB/SPH.

edit: I think this might be contributing to a maybe memory leak or a general increase in memory usage, not sure....

Thanks!

Yes, this is what I was talking about above, when I said,

On 4/10/2016 at 6:52 AM, Snark said:

Excellent, thanks for the report!  That means that my 1.4.1 fix band-aid is doing its job. 

As far as I can tell, Unity 5 has a bug that causes a particular method call, which should never throw, to throw an exception.  It does so unpredictably and unavoidably, at least as far as I can tell.

I put this SafeText wrapper class around it to contain the damage.  Not only does it trap the exception, but it also has some "cooldown" code in it so that if the exception gets thrown once, it won't touch the native Unity 5 object again until one full second has elapsed.  This is so that it won't spam the log with exceptions, the way it was doing pre-1.4.1.  It's a horrible kludge, and nothing I'd submit for inclusion in the Great Code Hall of Fame, but without knowing why Unity's having conniptions over it, this is about the best I can do for now.

I've got a band-aid around it that prevents it from becoming a problem.  I'm reasonably sure it's not contributing in any significant or measurable way to a memory leak, because one of the features I built into the band-aid is that it has a built-in cooldown timer to prevent that sort of spamming exception.  So the only real effect here is the occasional log messages, which are annoying and disturbing to see but don't actually hurt anything.

Fortunately, since I wrote the above, I have found out just what the dickens is going on.

<rant>
It turns out that the Unity API has a so-called "design" feature that is stark raving stupid.  I won't go into technical details, because it's the sort of thing that only a programmer would care about, but I gotta say it's one of the most idiotic things I've ever seen, and I have no idea what on earth they were thinking when they wrote it that way.  So I feel comfortable putting the blame squarely on Unity, here.
</rant>

...The good news is that now that I know what's actually happening, I can tweak my code to get rid of those annoying messages-- i.e. fix it properly, rather than putting a band-aid on it.  I'll take care of that with my next update to BetterBurnTime.

[smjjames]

Did you see whether there was a 'memory leak' (whether or not that's the correct term to be applied here) happening with it because GCmonitor showed a small, but steady, increase in memory usage over time. Without Better Burn Time, it didn't happen.

Edited April 22, 2016 by smjjames

[Snark]

20 minutes ago, smjjames said:

Did you see whether there was a 'memory leak' (whether or not that's the correct term to be applied here) happening with it because GCmonitor showed a small, but steady, increase in memory usage over time. Without Better Burn Time, it didn't happen.

It's entirely possible that there could be a memory issue somewhere in BetterBurnTime (hoo boy, would that be a fun one to track down... ).  However, if there is, I very much doubt that this particular issue is it (i.e. I can fix this issue, but I doubt it would affect the memory one.)

[smjjames]

1 minute ago, Snark said:

It's entirely possible that there could be a memory issue somewhere in BetterBurnTime (hoo boy, would that be a fun one to track down... ).  However, if there is, I very much doubt that this particular issue is it (i.e. I can fix this issue, but I doubt it would affect the memory one.)

The fact that it's only happening on scene change probably helps narrow it down.

[Snark]

1 minute ago, smjjames said:

The fact that it's only happening on scene change probably helps narrow it down.

Just to be clear, there are (presumably, unless demonstrated otherwise) two issues here:

1. An occasional error log message about a NRE, which sometimes happens on scene changes
2. A small, gradual memory leak that may be somewhere in BetterBurnTime

I haven't seen anything at all in this thread or my gameplay to indicate that these two things are at all related to each other.  I know now what the NRE is, and have a fix for it in hand.  The only reason that I haven't bothered to push out a BBT update with just this fix is that I'm pretty sure it's a microscopically tiny problem that looks scarier than it is, at least with the current band-aid in place.  As soon as I release the next BBT update (which will incorporate the actual fix), hopefully that issue will go away.

However, I would guess that doing so would be highly unlikely to address any memory issues.  If there's a memory leak, it could be anywhere, and tracking that down will be a real bear given how small it is.  My reading of the thread thus far is that "only happens on screen changes" narrows down #1, but doesn't narrow down #2.  Which means it would be an excruciating, un-fun, dozens-of-hours-of-my-time pain to track down, if past adventures with that kind of problem are any indicator. 

Unless I'm misreading what I've read so far, and you actually have a narrower repro case for the memory issues themselves?

[smjjames]

Launching craft from the editor or KSC screen, going back to the SPH/VAB from flght is really all I have to go on. It was with old saves that I was trying to see how much things would explode on (unfortunately, things weren't as buggy or explodey as I expected, or hoped), so, I wasn't really doing any serious bugtesting. So, it would be better to do it with a fresh save or even stock only+BBT.

[HebaruSan]

2 hours ago, Snark said:

<rant>
It turns out that the Unity API has a so-called "design" feature that is stark raving stupid.  I won't go into technical details, because it's the sort of thing that only a programmer would care about, but I gotta say it's one of the most idiotic things I've ever seen, and I have no idea what on earth they were thinking when they wrote it that way.  So I feel comfortable putting the blame squarely on Unity, here.
</rant>

Just curious, how does that misfeature cause problems for BBT? If I recall previous posts, you're checking for null and then using functions or properties on the object, as per normal practice, and the null check is failing to protect you from null reference errors. But that means their overloaded operator must be returning false in some cases where the system operator would be returning true, right? From the unity3d article, it sounds like they would be returning true when the system operator is true, and true when that operator is false but their object's internal state is destroyed, and false otherwise. How does their wrapper object create the possibility to return false when the reference is actually null?

[sinpro]

I'll give a try to this mod. Seems nice and I really appreciate the implication of Snark

Thx