Jump to content

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


Recommended Posts

42 minutes ago, VoidSquid said:

Hey @Snark, I've been wondering, since KSP 1.11.0 came out, CKAN lists the latest couple of versions of several of your mods only to be compatible with 1.11.0, but these versions aren't new at all. In fact, I have installed those 1.11.0-marked versions months ago for KSP 1.10.1:

MH 1.8.2
IL 1.7
BBT 1.10
VP 1.1

Probably just an oversight with the respective CKAN meta data.

hNZUcHi.png

This rang a bell since I was just looking at BBT the other day --- the most recent update (bbt v1.10) back-ported compatibility to KSP1.8 so CKAN is correct in this case.

The way I interpret that column is "Max-compatible KSP Versions"

Link to post
Share on other sites

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 by Beetlecat
Link to post
Share on other sites
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.  ;)

Link to post
Share on other sites
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 by HebaruSan
Link to post
Share on other sites
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.)

Link to post
Share on other sites

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.

 

Link to post
Share on other sites
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:

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

Edited by HebaruSan
Link to post
Share on other sites
  • 2 weeks later...
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.

Link to post
Share on other sites

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 by dhex_21
Link to post
Share on other sites
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 by Captain828
Link to post
Share on other sites
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.

Link to post
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...