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

[VoidSquid]

Not true, take for example Chatterer which is also hosted at spacedock

[Beetlecat]

I know we're drifting away from BBT-centric stuff, but in Chatterer's case, the current .version file has the min version as 1.8 still (even though it's had a .net update, and probably a better idea to use the previous one in a pre-KSP1.9 game).  CKAN is simply reporting as it's told.  Regardless, if you spot an error, report it on the CKAN thread, and they can fix/override the listing.
 

[edit] ahh-- I see. It's showing a range. It's probably something the CKAN folks can better fix.  --or snark rebuilds BBT to include a version file, etc.

Edited December 30, 2020 by Beetlecat

[Snark]

12 minutes ago, Beetlecat said:

or snark rebuilds BBT to include a version file

I get that that's a thing that one can do, but alas, I have no intention of doing so.

Because I'm not going to put something in my mod unless I test it.

And the only way to test a CKAN version file would be to actually verify via CKAN that it's behaving as expected.

And that would require installing and running CKAN, which I am unwilling to do.  I don't need it, I don't use it, and the time and effort it would take for me to test and implement all that is more than I'm willing to commit, even if the version file itself is very simple.

So it's a good suggestion, and thank you for that, but it's never going to happen, mainly because I'm a curmudgeon. 

[VoidSquid]

21 minutes ago, Beetlecat said:

It's probably something the CKAN folks can better fix

I've created an issue at Github https://github.com/KSP-CKAN/CKAN/issues/3252

7 minutes ago, Snark said:

curmudgeon

Had to look up that word, hehe, and now I need to remember it and include it in my English vocabulary  

[HebaruSan]

1 hour ago, Snark said:

Since it's the same version of my mod that SpaceDock already knew was compatible with the previous KSP version, then you'd think that SpaceDock would have all the info it needs to be able to do the right thing when it does whatever-it-does to communicate to CKAN.

Yes, you might think that. Unfortunately, SpaceDock only tracks one game version per release, so the following two actions are impossible to distinguish based on the contents of its database and API:

• My mod is marked as compatible with 1.10.0, and it's also compatible with 1.11.0, so I'm going to mark it as compatible with 1.11.0...
  (This is what you're doing)
• Oops! I marked my mod compatible with 1.10.0, but it isn't—I meant 1.11.0. Let me just go and change that...

I.e., fixing an error looks exactly the same as trying to extend the range (and CKAN conservatively favors the error-fixing case); in both cases SpaceDock retains and shares no record of the mod's previous compatibility. Hence the value of .version files in dismbiguating between the two cases.

12 minutes ago, Snark said:

And the only way to test a CKAN version file would be to actually verify via CKAN that it's behaving as expected.

For what it's worth, CKAN did not invent .version files, it just adopted the format used by KSP-AVC. So you could try installing KSP-AVC and test it that way.

Edited December 30, 2020 by HebaruSan

[Beetlecat]

1 minute ago, VoidSquid said:

I've created an issue at Github https://github.com/KSP-CKAN/CKAN/issues/3252

Had to look up that word, hehe, and now I need to remember it and include it in my English vocabulary  

Awesome!

And it's also ironic in Snark's case that, while being a curmudgeon, is hardly ever a snark.

[Snark]

On 12/29/2020 at 8:44 PM, HebaruSan said:

For what it's worth, CKAN did not invent .version files, it just adopted the format used by KSP-AVC. So you could try installing KSP-AVC and test it that way.

Thank you, that's a good suggestion.  Unfortunately, it's also a non-starter for me, because reasons.  Lengthy rant in spoiler, but it boils down to "same problem as with CKAN."

Spoiler

Yep.  But I don't use AVC either, so the same objections apply.

Yes, I know I'm being an ornery cuss, and I'm sorry about that.

But I have a horror of version churn, and the more moving parts I put in a mod, the bigger the attack surface for potential bugs.  And the juiciest targets for bugs are pieces of code that I myself never, ever exercise in my usual gameplay because I won't notice a breakage when (not if) I break something.

I would far rather tell someone "no" than tell them "yes" when it might be a lie-- and I just don't have any use for the .version file myself, so including it with the mod would stress me out and make me have to live with anxiety that I've screwed something up, and would be an additional testing hassle that I would very quickly come to loathe.  Which would, in turn, be a strong disincentive for me to do any modding.  "Hey, I could add a feature that would-- oh crap, that means I'd have to do the whole version-verification thing, never mind, I don't really need that feature, I'd rather not disturb it."

Bearing in mind, too, that I have over a dozen mods that I actively maintain.  Anything I do for one, I'd have to do for all of them.  Every single time KSP updates.  Every single time I update any one of them.  I'd be unwilling to do this for even a single mod, but this makes it a dozen times worse.

Yes, I know I'm being mulishly stubborn on this point to a perhaps silly degree.  But I know my own idiosyncrasies well, and therefore I know this is a non-starter for me.  There is can be no possible way I can include a .version file in my mods without having to test that, which I am unwilling to do for reasons of my own.  So it seems to me that that pretty much ends the discussion, right there.  Ain't gonna happen. I'm sorry. 

When I consider a potential "solution" to this (or any problem), then unless it's solving a problem for me personally, I have two immutable, non-negotiable requirements:

• It cannot impose any additional hassle on me.
• It cannot present any additional risk for my users.

Futzing with a .version file that I myself never use for anything would mean that either I'd have to test it (additional hassle for me) or just bang it out and trust that it works (additional risk for users).  It can't satisfy both requirements simultaneously, therefore it's a non-starter for me.

(You'll note that "additional hassle for users" isn't on the above list.  I get that the lack of a .version is a hassle for some users.  And sure, I'd like to reduce hassle for users, if possible.  But not if doing so would incur risk for them, or if it would impose hassle on me.)

My current solution for version compatibility-- which does meet both criteria simultaneously-- looks like this:

1. I check that my mod version X works on KSP version Y.
2. I say as much in my mod thread.

There, done.

That's good enough for me, as a mod author.  It's good enough for me as a mod user for every 3rd party mod I've ever used.  It's good enough for anyone who doesn't depend on some system like CKAN for managing all their mods.  Therefore, as far as I'm concerned, it's good enough, period.

It's true that it doesn't work for users who do choose to depend on a version-management system such as CKAN, and I'm sorry about that.  But, unfortunately, that's their lookout, and not something that would induce me to violate either of my two principles.  It would be an intolerable burden to me to support something I never use.

Since I already have a system that works for me and doesn't poke me in any sore spots, then I will not change that under any circumstances whatsoever if doing so would add any additional hassle, or impose any additional risk that I might be lying to my users.

About the only solution I can think of that would give users better "programmatic" compatibility information, without violating either of my two principles, would be something that looks like this:

1. I check that my mod version X works on KSP version Y.
2. I click a mouse button, on someone else's site, without doing a git commit or editing a file, that basically says "X works on Y" without claiming anything else.
3. Done.

This is basically what I'm already doing with SpaceDock.  When KSP updates, I can go to my mod page, and SpaceDock presents me with a helpful prompt "do you want to tell people that this version works on KSP version such-and-such?" and I say "yes".  That works for me.

It turns out that there are reasons why SpaceDock doesn't then do what I'd always assumed it did, and therefore this solution doesn't work for CKAN users.  But that is SpaceDock's problem and CKAN users' problem, not mine.  I can't adopt a new solution unless it works for me, because if it doesn't, then I know that I would react by finding excuses not to do modding anymore, and then everyone would lose, including me. 

 

On 12/29/2020 at 8:46 PM, Beetlecat said:

And it's also ironic in Snark's case that, while being a curmudgeon, is hardly ever a snark.

Thank you.     Though I'd contend that that's not irony, that's just people coming up with a new and wrong usage of the word "snark" (starting circa 2000... yes, I'm calling that "new", fight me) that has nothing to do with my prior adoption of the moniker. 

(And yes, I'm aware that this attitude of "you people are all wrong because I was there first, how dare the world change" is a perfect example of what makes me a curmudgeon.)

[VoidSquid]

A final idea/suggestion, if I may, requires very little time and work:

You mark the existing BBT 1.9.1 at Spacedock as compatible with KSP 1.10.1

Then add a line to the changelog and upload the mod again to Spadedock, this time telling Spacedock that the new upload is BBT version 1.9.2, being compatible with KSP 1.11.0

Result: two mod-wise identical uploads, but with different version numbers for different KSP version. And no need to tinker with any .version files at all.

 

[HebaruSan]

3 hours ago, Snark said:

Which would, in turn, be a strong disincentive for me to do any modding.  "Hey, I could add a feature that would-- oh crap, that means I'd have to do the whole version-verification thing, never mind, I don't really need that feature, I'd rather not disturb it."

Hmm, I don't recognize anything familiar in that concern. It sounds like you're imagining something that it isn't. It's just a small metadata file that gives you better control over how people use your mod, you get to specify when it is and isn't compatible. Here, I'll make one for your current release right now:

{
    "NAME": "Better Burn Time",
    "URL": "https://location_of_updated_copy_of_this_file_on_the_internet.version",
    "VERSION": {
        "MAJOR": 1,
        "MINOR": 10
    },
    "KSP_VERSION_MIN": {
        "MAJOR": 1,
        "MINOR": 8
    },
    "KSP_VERSION_MAX": {
        "MAJOR": 1,
        "MINOR": 11
    }
}

3 hours ago, Snark said:

There is can be no possible way I can include a .version file in my mods without having to test that, which I am unwilling to do for reasons of my own.

Yes, testing is important. Believe it or not, @DasSkelett wrote a tool that validates .version files automatically on GitHub:

• https://github.com/DasSkelett/AVC-VersionFileValidator

If you make a mistake, it'll tell you a few seconds after you push the changes.

Edited December 31, 2020 by HebaruSan

[Captain828]

@Snark I just noticed in the source code that you have

public const double KERBIN_GRAVITY = 9.81;

which you use as g0 in the fuel consumption formula but shouldn't you be using the standard gravity, as in 9.80665? 

[Sovetskysoyuz]

9 hours ago, Captain828 said:

@Snark I just noticed in the source code that you have

public const double KERBIN_GRAVITY = 9.81;

which you use as g0 in the fuel consumption formula but shouldn't you be using the standard gravity, as in 9.80665? 

AFAIK KSP physics use the rounded-off 9.81, so that is the appropriate value.

[dhex_21]

is there a countdown for maneuvre nodes? its not showing in my game. i mean by countdown is that there are no dots appearing beside the navball when I make a maneuver node.

Edited January 13, 2021 by dhex_21

[Captain828]

10 hours ago, Sovetskysoyuz said:

AFAIK KSP physics use the rounded-off 9.81, so that is the appropriate value.

According to https://wiki.kerbalspaceprogram.com/wiki/1.2 that's not the case.

There are a number of other mods that use g0 in their ISP-related calculus like Mechjeb, KER and kOS and all of them use the 9.80665 value.

7 hours ago, dhex_21 said:

is there a countdown for maneuvre nodes? its not showing in my game. i mean by countdown is that there are no dots appearing beside the navball when I make a maneuver node.

That only shows up for close-approach on rendezvous targets.

Edited January 13, 2021 by Captain828

[Snark]

On 1/12/2021 at 12:21 PM, Captain828 said:

@Snark I just noticed in the source code that you have

public const double KERBIN_GRAVITY = 9.81;

which you use as g0 in the fuel consumption formula but shouldn't you be using the standard gravity, as in 9.80665? 

Perhaps, and you're not the first person to observe this.

But the difference is so tiny as to be trivially unimportant, so I've never bothered correcting it.  It's a difference of one part in nearly 3000, and makes absolutely no significant difference to gameplay whatsoever.

14 hours ago, dhex_21 said:

is there a countdown for maneuvre nodes? its not showing in my game. i mean by countdown is that there are no dots appearing beside the navball when I make a maneuver node.

Correct, there isn't.  There used to be, but I removed it for maneuver nodes in BBT version 1.7, since it was superseded by the improved stock implementation in KSP 1.5.

[Dominiquini]

KSP is crashing here, and the last thing I see was logs from this mod:

KSP.log: https://www.dropbox.com/s/ogsuit7s0qywiw1/KSP(BBT).log?dl=0

Player.log: https://www.dropbox.com/s/4ymb5u8p5b5szvm/Player(BBT).log?dl=0

I create a new Sandbox game to test somethings and was using the cheat menu to put some probe/vessel in a 90' inclination!

Thanks

 

I removed this mod and it keeps crashing. So I guess it's another mod's fault...
Sorry!

Edited July 13, 2021 by Dominiquini

[Noah Foloni]

This is amazing thank you for making this. This is amazing!

[Snark]

On 7/13/2021 at 3:17 AM, Dominiquini said:

I removed this mod and it keeps crashing. So I guess it's another mod's fault...
Sorry!

No worries, it happens.    FWIW, I glanced at your logs and I'm seeing a bunch of errors that say "Trajectories" on them-- so if you're running that mod, maybe it's the culprit?  Might want to go and ask about it in their thread.

On 7/13/2021 at 11:12 AM, DaBakonAder said:

This is amazing thank you for making this. This is amazing!

Quite welcome. 

[Dominiquini]

26 minutes ago, Snark said:

No worries, it happens.    FWIW, I glanced at your logs and I'm seeing a bunch of errors that say "Trajectories" on them-- so if you're running that mod, maybe it's the culprit?  Might want to go and ask about it in their thread.

Quite welcome. 

I tries without Trajectories installed and the game crash too! I ended up testing only in stock and the bug is there.

I opened a bug for Squad Bugtracker!

 

Thanks.

[obnox twin]

I have a problem like the burn time doesn't even show the ones with dots can I have help with this?

[Snark]

On 8/4/2021 at 6:08 PM, obnox twin said:

I have a problem like the burn time doesn't even show the ones with dots can I have help with this?

Hello, sorry for the late response!

So, about the countdown dots, like this:

...The current version of BetterBurnTime only shows those dots for the closest-approach tracker.  It doesn't show them for maneuver nodes or the surface-impact tracker.

• Reason why it doesn't show them for maneuver nodes:  Actually, it used to.  However, KSP 1.5 added a much improved burn-indicator for maneuver nodes, so BetterBurnTime now defers to this, since BBT version 1.7.
• Reason why it doesn't show them for surface impact:  It's never shown them for that, mainly because the code in the mod is not currently smart enough to be able to accurately calculate exactly when the burn would start.  (Reason for that is that it requires split-second accuracy, and being accurate about that is a Great Big Fat Hairy Difficult Problem™, so I've never had the gumption to tackle it.  It would be a very big job.)

You should be getting the dots for the closest-approach tracker, though, so if you're not getting them for that, then that would be a bug I'd like to know about.

[obnox twin]

5 hours ago, Snark said:

Hello, sorry for the late response!

So, about the countdown dots, like this:

...The current version of BetterBurnTime only shows those dots for the closest-approach tracker.  It doesn't show them for maneuver nodes or the surface-impact tracker.

• Reason why it doesn't show them for maneuver nodes:  Actually, it used to.  However, KSP 1.5 added a much improved burn-indicator for maneuver nodes, so BetterBurnTime now defers to this, since BBT version 1.7.
• Reason why it doesn't show them for surface impact:  It's never shown them for that, mainly because the code in the mod is not currently smart enough to be able to accurately calculate exactly when the burn would start.  (Reason for that is that it requires split-second accuracy, and being accurate about that is a Great Big Fat Hairy Difficult Problem™, so I've never had the gumption to tackle it.  It would be a very big job.)

You should be getting the dots for the closest-approach tracker, though, so if you're not getting them for that, then that would be a bug I'd like to know about.

Thanks for the help.

[Gordon Dry]

The maneuver is 1 hour long and done with a Xenon Ion engine.
Not sure if it's BBT or stock behaviour, but as the KER readout is correct I assume it's BBT:

btw no matter if I created a maneuver node with more or less than this one, the BBT/stock readout always showed a burn time of "1d 3h".
 

 

[Snark]

20 hours ago, Gordon Dry said:

Not sure if it's BBT or stock behaviour, but as the KER readout is correct I assume it's BBT:

Nope, nothing to do with BBT.  Whatever's going on here, it's pure stock behavior.

BetterBurnTime hasn't done anything with maneuver node burn times since I released version 1.7 in October 2018, for compatibility with KSP 1.5:

On 10/16/2018 at 6:51 PM, Snark said:

I'm pleased to announce the release of BetterBurnTime v1.7, for KSP 1.5 compatibility.

The main change is that the "maneuver node" burn-time functionality (which has been part of BetterBurnTime since its inception, and was the original reason for the mod's existence) has been removed, since it's no longer needed with the much-snazzier navball functionality added to the stock game in KSP 1.5.

The trackers for surface landing, orbital target rendezvous, and atmosphere transition are still in place, and their functionality is unchanged from before.

(BBT does still do burn calculations... but only for target intercepts and surface landings.  It doesn't do maneuver nodes anymore, deferring to KSP's stock behavior.)

[dtondo]

Please add the atmosphere suicide burn time
:D

[Snark]

19 hours ago, dtondo said:

Please add the atmosphere suicide burn time

Agreed that that would be nice, but it's actually a Very Hard Problem™.  I looked at it once, but the thing is, air resistance is critically important in determining this sort of thing, and when I poked at it a little bit, I found that it fluctuates in ways that would require a fair amount of code to smooth out.  (There are other complexities, too, such as predicting the varying engine thrust due to Isp decreasing as the atmosphere gets denser on descent, that sort of thing.)

Trying to address this would involve adding a fair bit of code complexity, plus I'd be almost guaranteed to get it wrong to some degree... and "getting it wrong" on a suicide burn can mean "player's craft goes splat".  So I'd rather emit no signal at all than a likely wrong signal, which is why I ended up not adding the feature.