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

[Rocket In My Pocket]

Thanks for the explanation!

Your insights into this are most interesting indeed.

Taking staging into account was an unusual choice on their part imo. Although it's certainly a great QOL feature, it never really bothered me to not have it, and I can't say I pay that much attention to it now that it's there. But then again I suppose, I'm used to not having it of course, new players I'm sure will appreciate it. Here's hoping we may get 1.6 as an X-mas present lol.

[Beetlecat]

44 minutes ago, Rocket In My Pocket said:

Thanks for the explanation!

Your insights into this are most interesting indeed.

Taking staging into account was an unusual choice on their part imo. Although it's certainly a great QOL feature, it never really bothered me to not have it, and I can't say I pay that much attention to it now that it's there. But then again I suppose, I'm used to not having it of course, new players I'm sure will appreciate it. Here's hoping we may get 1.6 as an X-mas present lol.

Agreed -- thanks for the insight on this particular hiccup, @Snark. And, as an aside, you've never once lived up to your userid, attitude-wise. Ironically or not, it's appreciated.

Edited November 13, 2018 by Beetlecat

[Snark]

49 minutes ago, Rocket In My Pocket said:

Taking staging into account was an unusual choice on their part imo. Although it's certainly a great QOL feature, it never really bothered me to not have it, and I can't say I pay that much attention to it now that it's there. But then again I suppose, I'm used to not having it of course, new players I'm sure will appreciate it.

Well, MechJeb's been doing it for a while now.    I think it's an excellent candidate for a stock feature, myself-- it's the main value-add that they provide over BetterBurnTime, as far as I'm concerned.

I've wanted this feature for quite some time.  Heck, I wanted it in BetterBurnTime.  I just didn't want it quite badly enough to put in the time it would have taken me.

2 minutes ago, Beetlecat said:

you've never once lived up to your userid, attitude-wise. Ironically or not, it's appreciated.

Thanks, though that's actually not the etymology in my particular case.  Both the name itself, and my use of it, predate the sense that it has acquired in recent decades. 

[JH4C]

4 hours ago, Rocket In My Pocket said:

Thanks for the response! I understand your reasoning completely.

I may give the older version a try for now myself, since I still have a copy sitting around in my Downloads folder.

You could always try out DMagic's BasicDeltaV, as I believe (if I understood the update notes properly) that makes some adjustments to the stock readout to try and mitigate the current bug issues.

On 5/29/2017 at 8:47 PM, DMagic said:

- Option to disable stock dV calculator
      - Basic DeltaV will fill in all stock dV numbers from its own calculations

 

[Rocket In My Pocket]

24 minutes ago, JH4C said:

You could always try out DMagic's BasicDeltaV, as I believe (if I understood the update notes properly) that makes some adjustments to the stock readout to try and mitigate the current bug issues.

Nice find! Thank you.  I'll definitely check that out.

Edited November 14, 2018 by Rocket In My Pocket

[Snark]

Hi everyone,

I'm happy to announce the release of BetterBurnTime 1.8, now with burn time indicators for SRBs.

I like to launch with a mix of SRBs and liquid-fuel engines-- usually with asparagus-draining LFO tanks atop the SRBs, often with different sizes of SRBs, often with thrust limiters tuned.  I find that I'm often in the position of wanting to judge "which thing is going to burn out when" so I can judge, for example, how much LFO to put on top of them, etc.  Anyway, this little addition to BetterBurnTime solves that problem nicely.

The new indicator shows up in the following places:

• On the parts-pane tooltip for the part (see above image).  This is the "base" burn time with the default fuel-content and thrust-limiter setting.
• On the part's right-click menu in the editor (see above image).  This number takes into account the fuel-content and thrust-limiter settings.
• On the part's right-click menu in flight (not shown here).  Same deal as in the editor... plus you can watch it count down while the engine burns. 

Enjoy!

[severedsolo]

15 hours ago, Snark said:

now with burn time indicators for SRBs.

Just FYI you don't need two MM patches to target ModuleEnginesFX and ModuleEngines separately. You could just use @MODULE[ModuleEngine*] instead and it would target both. I'm also not entirely sure it's necessary to target parts that have both a SolidFuel resource, and run on SolidFuel (are there any SRBs that don't contain their own fuel?)

You could probably simplify it to this:

@PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[SolidFuel]]]

Cool feature though

Unfortunately I can't use it, something about your MM patch is causing one of the Making History tanks to not load, and causing my game to hang (Don't worry, I'm not asking for help on this, it's very much a "too many mods" problem - it doesn't happen on a stock+BBT game. - I'm just mentioning it in case anyone else brings it up).

 

Edited December 2, 2018 by severedsolo

[Gordon Dry]

Like @Stratickus mentioned here:

After updating BBT, the game is stuck in the loading screen.

btw, I don't use KOOSE actually.

Nearly at the end of the log:

NullReferenceException: Object reference not set to an instance of an object
  at PartLoader.<CompilePartInfo>m__0 (.ModuleInfo ap1, .ModuleInfo ap2) [0x00000] in <filename unknown>:0 
  at System.Array.qsort[ModuleInfo] (.ModuleInfo[] array, Int32 low0, Int32 high0, System.Comparison`1 comparison) [0x00000] in <filename unknown>:0 
  at System.Array.qsort[ModuleInfo] (.ModuleInfo[] array, Int32 low0, Int32 high0, System.Comparison`1 comparison) [0x00000] in <filename unknown>:0 
  at System.Array.Sort[ModuleInfo] (.ModuleInfo[] array, Int32 length, System.Comparison`1 comparison) [0x00000] in <filename unknown>:0 
Rethrow as InvalidOperationException: Comparison threw an exception.
  at System.Array.Sort[ModuleInfo] (.ModuleInfo[] array, Int32 length, System.Comparison`1 comparison) [0x00000] in <filename unknown>:0 
  at System.Collections.Generic.List`1[AvailablePart+ModuleInfo].Sort (System.Comparison`1 comparison) [0x00000] in <filename unknown>:0 
  at PartLoader.CompilePartInfo (.AvailablePart newPartInfo, .Part part) [0x00000] in <filename unknown>:0 
  at PartLoader+<CompileParts>c__Iterator1.MoveNext () [0x00000] in <filename unknown>:0 
  at UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress) [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

Full log and stuff:
https://www.dropbox.com/s/idmdvqxxbz0dbxw/2018-12-02_1 KSP.log and stuff.7z?dl=1

[Superfluous J]

16 hours ago, Snark said:

burn time indicators for SRBs.

Very cool. This will keep me from slowly sliding SRB thrust limiters until KER numbers or number of stages change.

Edited December 2, 2018 by 5thHorseman

[flart]

After a burntime isn't part of the betterburntime mod you have no reason not to going crazy,
but extended SRB-info feature makes changes in the different place than other features of the mod.

It is more like ScienceLabInfo mod what extend info panels for ScienceLabs. 

Do you have some other idea in mind about extending Engine info panels? You could separate the feature. 

[Snark]

11 minutes ago, severedsolo said:

 You could just use @MODULE[ModuleEngine*] instead and it would target both.

And would also target any third-party mod modules that happen to start with "ModuleEngine"... I prefer to limit the blast radius.

12 minutes ago, severedsolo said:

I'm also not entirely sure it's necessary to target parts that have both a SolidFuel resource, and run on SolidFuel (are there any SRBs that don't contain their own fuel?)

Not super necessary, no, but I'm a big fan of limiting the blast radius, and it's not hurting anything, either.  No, there can't be a functional SRB that doesn't contain its own fuel, since solid fuel is non-pumpable and non-transferable.  But suppose someone modded a part with a bug in it and it had extra stuff?  I'd rather just keep things as narrowly focused as possible, better to just keep this mod out of it in that case.

20 minutes ago, Gordon Dry said:

Like @Stratickus mentioned here:

After updating BBT, the game is stuck in the loading screen. 

No idea.  The BBT update doesn't touch anything except parts that have ModuleEngines-with-solid-fuel.  @Stratickus is observing that.

4 hours ago, Stratickus said:

it appears to be locking up on the decoupler for the cradle

...and I looked at the KOOSE parts, and that part doesn't have any SRB in it and therefore shouldn't be affected by BBT.  As far as I can tell from looking at the KOOSE config, there's only one part that has SRB in it, and that's the KOOSEpod.  So it seems a little odd that he's seeing a problem on the decoupler?

Also, just as a sanity check... sorry if this is a dumb question, but I've learned it's best not to assume.  Have you, in fact, verified that BBT is relevant, here?  That is, have you verified that "running BBT 1.8 with KOOSE causes a lockup, but running the same version of KOOSE without BBT doesn't lock up"?

27 minutes ago, Gordon Dry said:

Full log and stuff:

Thanks, but you've put it in some ".7z" format that no software on my machine knows how to read.  Could you post it in a common/universal format such as plain text or .zip?

Just now, flart said:

After a burntime isn't part of the betterburntime mod you have no reason not to going crazy,
but extended SRB-info feature makes changes in the different place than other features of the mod.

Sure.  But it's burn time.  And I want to know the burn time of SRBs for very similar reasons that I want to know the other burn-time info in the mod.

So as far as I'm concerned, this is where it belongs.

2 minutes ago, flart said:

It is more like ScienceLabInfo mod what extend info panels for ScienceLabs.

Yes, but it's such a tiny feature by itself that there's no way I'd release a whole mod just for that one little thing.  And since it's burn time, to me it belongs in BetterBurnTime.

2 minutes ago, flart said:

Do you have some other idea in mind about extending Engine info panels?

Nope.  Don't need anything else, really.  This is the one thing I wanted.

[Gordon Dry]

2 minutes ago, Snark said:

format

https://www.dropbox.com/s/gxme396jj42xpz7/2018-12-02_1 KSP.log and stuff.zip?dl=1

3 minutes ago, Snark said:

but running the same version of KOOSE

I don't use KOOSE, I just updated BBT.

[Stratickus]

1 minute ago, Snark said:

No idea.  The BBT update doesn't touch anything except parts that have ModuleEngines-with-solid-fuel.  @Stratickus is observing that.

Honestly, I did not think to associate the freeze with BBT, as the log seemed to point to the decoupler. 

4 minutes ago, Snark said:

Also, just as a sanity check... sorry if this is a dumb question, but I've learned it's best not to assume.  Have you, in fact, verified that BBT is relevant, here?  That is, have you verified that "running BBT 1.8 with KOOSE causes a lockup, but running the same version of KOOSE without BBT doesn't lock up"?

But I did come here to see if I could find the pre v1.8 of BBT (1.7?) to see if that resolved anything. Do you have a link to GitHub or an older version? I personally have not been able to verify that BBT was the culprit without using BBT pre v1.8 and KOOSE.

Cheers,

[severedsolo]

11 minutes ago, Snark said:

And would also target any third-party mod modules that happen to start with "ModuleEngine"... I prefer to limit the blast radius.

I'd argue that mod module would be freaking stupid to call it something that starts with the same name as a stock module, but I do see your point

TBH, I just wanted an excuse to mention the whole "game locks up when starting" thing - but I figured that I'd better say something useful too

I have verified it's BBT, or rather that BBT triggers it - I'm not actually willing to point the finger directly at BBT yet.

More specifically it's the MM patch you added for SRBs. Without that patch, the game loads fine (even if I change it to the way I suggested, it happens too) Now, I don't know what is wrong with it - on a stock (and DLC) game it works fine, and mine locks up at a different place to Gordons. I just didn't want to just dump in the thread with a useless bug report (and it would be useless because I'm running 70 mods, it works fine on stock, and the part thats locking up is a Making History part (the FL-C1000), which is nothing to do with SRBs.)

Edited December 2, 2018 by severedsolo

[Loren Pechtel]

11 minutes ago, Snark said:

Not super necessary, no, but I'm a big fan of limiting the blast radius, and it's not hurting anything, either.  No, there can't be a functional SRB that doesn't contain its own fuel, since solid fuel is non-pumpable and non-transferable.  But suppose someone modded a part with a bug in it and it had extra stuff?  I'd rather just keep things as narrowly focused as possible, better to just keep this mod out of it in that case.
@Stratickus

I can think of a legitimate case for something to have solid fuel without being an engine.

There's a mod that adds landing rockets.  AFIAK they're not reloadable (although you can put it's controller on a rocket and use normal liquid engines, which obviously do reload) but what if KIS-style reloads for the rockets were made?

[Snark]

27 minutes ago, Gordon Dry said:

https://www.dropbox.com/s/gxme396jj42xpz7/2018-12-02_1 KSP.log and stuff.zip?dl=1

I don't use KOOSE, I just updated BBT.

Thank you.  I took a look, and unfortunately the log file really isn't helpful at all.  There are a ton of mods that you're running int here, and the only info available is that one exception right at the end, which contains zero useful information-- nothing about what's null that shouldn't be, nothing about what part is the issue, not even anything that actually says it's BetterBurnTime at all.

Sure, I agree that it seems likely that BBT is somehow involved, just based on the coincidence of timing (i.e. that you and @Stratickus are seeing this problem after updating to BBT 1.8).

But even if it turns out that BBT is involved... I can't look at a problem that I can't reproduce.  Clearly you're running tons of mods.  Wouldn't be surprised if Stratickus is runing a whole bunch of mods, too.  But guess what?  I'm running various mods, and it works just fine for me... so I have no way of reproducing the problem at all and therefore can't look at it.

What's needed is a repro case-- by which I mean, one that I can reproduce.  It's not helpful to me to say "BBT causes a lockup on my machine, by the way I'm running dozens of various other mods".

I need someone to reduce the problem to its essentials:  i.e. find me a case of "If BBT 1.8 and this one other mod are installed, then it locks up."  Without that, I can't really investigate, sorry.

18 minutes ago, severedsolo said:

I'd argue that mod module would be freaking stupid to call it something that starts with the same name as a stock module

I strongly disagree.  If someone wants to call something "ModuleEngineFilter" or "ModuleEngineTimer" or whatever, there's absolutely no reason they shouldn't be able to do that.  Heck, for that matter, there's nothing that says that a thing deriving from "ModuleEngines" which should be applicable would necessarily start with that-- "ModuleSuperCoolEngines" or whatever.  (Heck, I came within a whisker of calling my own module "ModuleEngineBurnTime"... and the reason I didn't had nothing to do with trying to avoid colliding with "ModuleEngine*".

The fact is, there are two stock PartModule modules that are in common use out there... and it's only a coincidental happenstance that they can both be matched with the regular expression ModuleEngine*.  It's an internal implementation detail.  And Software Engineering 101 says, "don't base software on internal implementation details if you want it to be maintainable".)

There are thousands of mods out there, and there's no particular convention on naming them (other than they tend to start with "Module").  Best not to build in assumptions, and focus things as narrowly as possible so as to leave the fewest possible footprints.  Witness how much hilarity can ensure (e.g. the current issue people are reporting with KSP 1.8) even when the modder does try to keep things as self-contained as possible.

18 minutes ago, severedsolo said:

TBH, I just wanted an excuse to mention the whole "game locks up when starting" thing - but I figured that I'd better say something useful too

I have verified it's BBT, or rather that BBT triggers it - I'm not actually willing to point the finger directly at BBT yet.

Thanks, that's useful to know.  However,

18 minutes ago, severedsolo said:

Now, I don't know what is wrong with it .... I just didn't want to just dump in the thread with a useless bug report (and it would be useless because I'm running 70 mods

Ding ding ding ding ding. 

It's the "running 70 mods" thing that's the killer.  Guess what?  I'm running 24 mods myself, and it works just fine!  I just happen not to be running whichever-one-of-the-70 it is that's causing the problem.

Almost certainly it will turn out that there's one specific mod that doesn't play nice with BBT 1.8.  But without knowing what that mod is, there's simply nothing I can do about it.  I need to know what mod actually causes the issue with BBT before I can do anything at all to address the problem.

10 minutes ago, Loren Pechtel said:

I can think of a legitimate case for something to have solid fuel without being an engine.

There's a mod that adds landing rockets.  AFIAK they're not reloadable (although you can put it's controller on a rocket and use normal liquid engines, which obviously do reload) but what if KIS-style reloads for the rockets were made?

Well, if they're rockets, then they're presumably using ModuleEngines or ModuleEnginesFX.  And if they're not rockets, then they don't work, do they?

In any case, it's a moot point because if it's not an SRB-containing-its-own-fuel then this mod wouldn't be able to work with them anyway-- meaning that the current specification of the MM patch should be just fine.

[Gordon Dry]

By chance, do you use B9PartSwitch latest rls?
(I guess so, then "who does not")

[Snark]

4 minutes ago, Gordon Dry said:

By chance, do you use B9PartSwitch latest rls?
(I guess so, then "who does not")

No, I have never used that mod for any reason ever, nor do I particularly expect to.

For the other folks who have observed this problem (@Stratickus, @severedsolo) -- by any chance do you happen to be running B9PartSwitch?

25 minutes ago, Stratickus said:

Do you have a link to GitHub or an older version?

They're all right there on SpaceDock, in the same place that you presumably downloaded the mod itself.  SpaceDock preserves all old versions of every mod by default.  Just go to the mod's page on SpaceDock and click the Changelog tab.  All the old versions are listed there, with a download link for each one.

[severedsolo]

7 minutes ago, Snark said:

by any chance do you happen to be running B9PartSwitch

I'm not no, but I'll do the 50/50 method tomorrow and see if I can figure out which mod it is. 

[Nik Power]

Dear Snark, I have encountered the problem, that Mk2 Expansion hungs with the new BBt 1.8 version on Module Manager phase

showing Mk2Expansion/Parts/Engines/AASRB/Radial/M2X_RATO

took me half-a-day to figure the problem (reinstalled all my 136 mods 1-by-1)

Made I have only Mk2 Expansion and BBT installed - same result

I installed BBT 1.7 and  it worked normally.

Edited December 2, 2018 by Nik Power

[Stratickus]

30 minutes ago, Snark said:

I need someone to reduce the problem to its essentials:  i.e. find me a case of "If BBT 1.8 and this one other mod are installed, then it locks up."  Without that, I can't really investigate, sorry.

BBT 1.8 + KOOSE 1.1.11 + a literal butt-load of other mods = game freezes on load.

BBT 1.7 + KOOSE 1.1.11 + a literal butt-load of other mods = all is well.

For the record, I'd like to point out, I am not insinuating that BBT is the issue, merely that where the game freezes and the logs pointed to KOOSE. Someone else pointed to BBT and this was my result.

I can try it on a vanilla install if that helps, I always keep a back-up for troubleshooting instances like this. I can produce logs as well; for both 1.8 and 1.7 games. In the mean time, I'm more than happy to run 1.7. This is an essential mod for me.

Let me know if there is any other way I can help.

Cheers,

Edited December 2, 2018 by Stratickus

[Snark]

3 minutes ago, Stratickus said:

BBT 1.8 + KOOSE 1.1.11 + a literal butt-load of other mods = game freezes on load.

BBT 1.7 + KOOSE 1.1.11 + a literal butt-load of other mods = all is well

Yep, that confirms that it's something-not-playing-nice-with-BBT, thanks! 

Unfortunately it's not useful to me in tracking down the problem, since I'd need to know which of the "literal butt-load" is the issue, so that I can reproduce the problem myself.

13 minutes ago, Nik Power said:

Dear Shark, I have encountered the problem, that Mk2 Expansion hungs with the new BBt 1.8 version on Module Manager phase

showing Mk2Expansion/Parts/Engines/AASRB/Radial/M2X_RATO

took me half-a-day to figure the problem (reinstalled all my 136 mods 1-by-1)8

I installed BBT 1.7 and  it worked normally.

Thank you!  That gives me something to work from, hopefully. It's the one-by-one bit that really helps-- thank you for taking the time to run this down!  (Really sorry that it cost you that much time... by the way, there's an alternate approach that should take you much fewer installs-and-restarts than 136.  The "50/50 approach", are you familiar with it?)

Got a download link for that mod?

[Apollo13]

Don't include Module Manager.  Inevitably, a new MM will come out and the one you include will conflict with it.  I've had a situation where my mods install had several MMs stored in multiple mods GameData files.  Given my 60 mods, it was a real poodle to find the offending GameData files that included MMs so I could remove them.

 

Or, include MM outside your GameData directory.

Edited December 2, 2018 by Apollo13

[Stratickus]

1 minute ago, Snark said:

Unfortunately it's not useful to me in tracking down the problem, since I'd need to know which of the "literal butt-load" is the issue, so that I can reproduce the problem myself.

Let me know what would be more useful and I will try and help. This isn't the first time I've run into a problem like this, so I can understand your frustration. At least from and end user stand point.

Cheers,

[Nik Power]

2 minutes ago, Snark said:

Yep, that confirms that it's something-not-playing-nice-with-BBT, thanks! 

Unfortunately it's not useful to me in tracking down the problem, since I'd need to know which of the "literal butt-load" is the issue, so that I can reproduce the problem myself.

Thank you!  That gives me something to work from, hopefully.  Got a download link for that mod?

I think, Github is what You need https://github.com/SuicidalInsanity/Mk2Expansion/releases

I'm lazy and using CKAN generally...

CKAN does not want to install mods w/o MM