Jump to content

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


Snark

Recommended Posts

58 minutes ago, Snark said:

whatever mod provides those info windows says you have a max thrust of 0

It's MechJeb ..

btw the titles of the imgur pictures were mismatched, I changed the titles but inside the post they still show the wrong title... perhaps a forum issue with a cache not actualizing soon...

Then the issue is more clear if you switch "deactivated" with "activated" and vice versa ...

Link to comment
Share on other sites

1 hour ago, Gordon Dry said:

It's MechJeb ..

btw the titles of the imgur pictures were mismatched, I changed the titles but inside the post they still show the wrong title... perhaps a forum issue with a cache not actualizing soon...

Then the issue is more clear if you switch "deactivated" with "activated" and vice versa ...

In this picture http://imgur.com/lH1EOIO it looks like you have no LH2 left in the stage. I'm not certain of this because I don't use ARP but it does say 0.00/0.00 and if your engine relies on LH2 as it looks like in the pic then BBT will be unable to calculate a burn time seeing as there's no fuel. Also, there's a chance BBT doesn't work with the RO engine module (@Snark does it?).

Gordon, I'm going to say to you what has been said in several other threads. Please take some time and find a reproducible problem with the minimum set of mods needed to create the problem and post exact steps on how to reproduce. It'll make debugging a heck of a lot easier.

 

Link to comment
Share on other sites

3 hours ago, TheRagingIrishman said:

Also, there's a chance BBT doesn't work with the RO engine module (@Snark does it?).

BetterBurnTime finds engines that use ModuleEngines (or a module derived therefrom, such as ModuleEnginesFX).  As long as it's using something derived from ModuleEngines, I think that ought to be fine.  (If I'm looking in the right place-- am I?-- then I think it uses ModuleEnginesFX, which would work okay.)

I do have a vague memory of somebody having trouble getting BBT to work with RO, but it was a long time ago, and whatever it was may or may not still be relevant.  Can't say from first-hand experience because I never run RO myself.

@Gordon Dry, you could try running without RO installed and see whether that makes the problem go away-- that would definitively answer the question.  Based on how BBT works, I'd say that RO would be far more likely to be the issue than Procedural Fairings, since that mod tinkers with engines, which is what BBT cares about.

3 hours ago, TheRagingIrishman said:

In this picture http://imgur.com/lH1EOIO it looks like you have no LH2 left in the stage.

Yeah, that would do it-- if an engine has been starved for propellant, BBT discounts it, so it's the same as if the engine weren't there, even if it's activated.  Easy way to test this:  turn on the "infinite propellant" cheat, then briefly blip the engine to some non-zero throttle setting to clear the "starved" flag.  If that makes the problem go away, then this is the issue and it has nothing to do with RO itself.

3 hours ago, TheRagingIrishman said:

Please take some time and find a reproducible problem with the minimum set of mods needed to create the problem and post exact steps on how to reproduce.

^ Very much this.

3 hours ago, TheRagingIrishman said:

It'll make debugging a heck of a lot easier.

That, and also the mod author would probably be considerably more inclined to spend their time trying to help you.  :wink:

4 hours ago, Gordon Dry said:

btw the titles of the imgur pictures were mismatched, I changed the titles but inside the post they still show the wrong title... perhaps a forum issue with a cache not actualizing soon...

I've noticed that the forum software can be a bit flaky where imgur albums are concerned.  Better to just post the imgur image link directly, so that it shows up as an inline image rather than an album.  That works, reliably.

Link to comment
Share on other sites

17 hours ago, TheRagingIrishman said:

it looks like you have no LH2 left in the stage

No, this is allright, with this specific engine it's just to be switched with "Toggle mode" and only shows the "main ingredient" but not the amount.

16 hours ago, Snark said:

Better to just post the imgur image link directly

I will do.

Link to comment
Share on other sites

20 minutes ago, Gordon Dry said:

No, this is allright, with this specific engine it's just to be switched with "Toggle mode" and only shows the "main ingredient" but not the amount.

Could you post a link to the.cfg file for the engine? (It ought to be available on whatever place the mod lists its source code, like GitHub or wherever.) Being able to see the config will allow me to verify (or eliminate) some possible root causes of the issue.

Link to comment
Share on other sites

38 minutes ago, Gordon Dry said:

@Snark it's using a regular noduleenginefx 

@Gordon Dry could you post your ModuleManager.configCache. That'll show us if anything is being overridden in the part's .cfg. 

Link to comment
Share on other sites

1 hour ago, Gordon Dry said:

Thanks, that's helpful to see.  For one thing, I gather that it's a multi-mode engine with different modes that use different fuels.  Not sure how well BBT handles that-- it wasn't a specific test case that I can recall looking at.  I don't know that it can't.... but then, I don't know that it *can*, either.  Something to check.

Can you please check the following:

  • Launch a test ship that has a standard stock engine on it (with appropriate fuel).  Do you still see the problem?
  • Launch a test ship that has this engine on it... and also has fuel tanks with appropriate fuel for all engine modes (regardless of which mode happens to be active at the moment).  Do you still see the problem?

Also, would be helpful to see a log file in an appropriate format, per my earlier request.

 

Link to comment
Share on other sites

  • 2 weeks later...

In case anyone's curious, the mod seems functional on 1.3. The first set of large dots show up as unicode missing character blocks, but it seemed to be working as intended otherwise at a precursory glance. It showed up, counted down right for a ship with a maneuver.
There didn't also appear to be any logspam or issues with the mod functioning, but I can't say i thoroughly tested it.

EDIT: To be clear, not complaining/asking for an update/etc, just passing along information from what i'd noticed.

Edited by Lupi
Link to comment
Share on other sites

19 minutes ago, Lupi said:

In case anyone's curious, the mod seems functional on 1.3. The first set of large dots show up as unicode missing character blocks, but it seemed to be working as intended otherwise at a precursory glance. It showed up, counted down right for a ship with a maneuver.
There didn't also appear to be any logspam or issues with the mod functioning, but I can't say i thoroughly tested it.

EDIT: To be clear, not complaining/asking for an update/etc, just passing along information from what i'd noticed.

I can confirm/second this.

Mod seems to be working as intended besides the last three circles appearing as squares. (Still perfectly usable like this.)

I used it quite extensively most of the day today; Mun landings, Orbital rendezvous, etc...seemed just fine, so no rush @Snark.

Link to comment
Share on other sites

4 hours ago, Lupi said:

In case anyone's curious, the mod seems functional on 1.3.

Woot! :D

Sorry for the delay in updating-- I've been otherwise occupied for the last few days.  I'll look into issuing an update as soon as I can-- thanks for the heads-up.

Not super surpised this happened-- the same thing occurred with the update from 1.1 to 1.2, since they updated the fonts then, too.

FWIW, in the meantime (until I release an update) you can customize that little string-of-dots by editing  the PluginData/BetterBurnTime/config.xml file within your BetterBurnTime directory (it shows up as soon as you've run KSP once with BBT installed).  So if you can find some other symbol to put there that renders correctly in-game, that'll do ya.  (And if you do find such a handy symbol, share it here!  You may save me some work hunting for a viable substitute.)  :wink:

Link to comment
Share on other sites

10 hours ago, Snark said:

FWIW, in the meantime (until I release an update) you can customize that little string-of-dots by editing  the PluginData/BetterBurnTime/config.xml file within your BetterBurnTime directory (it shows up as soon as you've run KSP once with BBT installed).  So if you can find some other symbol to put there that renders correctly in-game, that'll do ya.  (And if you do find such a handy symbol, share it here!  You may save me some work hunting for a viable substitute.)  :wink:

I've tried a bunch of different symbols but few work, and the ones that do, don't look right.

This symbol which apparently stands for "currency" but looks remarkably like a pro-grade symbol does show up, ¤ It's not perfect, but it looks better than a square. There were some really nice circles with numbers in them and I tried to do a 3, 2, 1 sort of a thing but they didn't show of course.

However, another issue I've noticed; the dots all appear to be really small on my screen, and I can't seem to make them any bigger. Even after re-installing BBT.

http://steamcommunity.com/sharedfiles/filedetails/?id=934730471 (Screenshot, Navball is at max scale 150%)

Update: Reinstalling the game fixed the size issue for me. I'm going to stop mucking with it for now, as I seem to be breaking more things than I'm fixing. Lol. :confused:

Edited by Rocket In My Pocket
Link to comment
Share on other sites

Hi all,

I've released BetterBurnTime 1.5.4.  This is a KSP 1.3 compatibility update that addresses the broken "countdown dots" due to 1.3 messing up the fonts.  Since the character is no longer displayable in-game, I've settled on ʘ as a replacement.  It ends up looking a little bigger and gaudier than I'd prefer, but at least it's nicely visible, and it looks better than the I-can't-render-this hollow squares.  As I mention above, if anyone doesn't care for my choice of display character, you can just go into the config.xml file and change it to something you like.

NOTE:  This update only changes the default character.  If you have previously run an earlier version of BBT, you're going to have an old config.xml file sitting there with the old, unrenderable ● character in it, which will override the new ʘ, meaning you'll see the annoying square boxes.  Easily fixed, just delete your config.xml; the next time you run KSP, BBT will create a new config.xml file for you, with the new character in place.

Other than the fix for countdown dots, the one other change is that I've fixed BetterBurnTime to target version 3.5 of the .NET framework, which is what KSP mods are supposed to do.  (It was previously targeting .NET 4.5.2.)  Thanks to @linuxgurugamer for catching this!

Link to comment
Share on other sites

  • 2 weeks later...

@Snark Ive run into a bit of a bug, or at least a bunch of "N/A's" in my burn time. With the throttle restrictor patch i am writing using the minThrust value my engines no longer stop at zero throttle. This means i use action groups to shut down my engines (thank you default actions, as you know snark, i also wrote a patch for default actions to shut down engines with AG09).

 

The problem is that butterburntime seems to not like using shutdown engines in its calculations. So here is my request. Could you add a feature where when ever N/A would be displayed to do a check for engines that were were recently shut down and use the thrust values from them to display a guess rather then N/A? 

Edited by Errol
Link to comment
Share on other sites

6 hours ago, Errol said:

@Snark Ive run into a bit of a bug, or at least a bunch of "N/A's" in my burn time. With the throttle restrictor patch i am writing using the minThrust value my engines no longer stop at zero throttle. This means i use action groups to shut down my engines (thank you default actions, as you know snark, i also wrote a patch for default actions to shut down engines with AG09).

The problem is that butterburntime seems to not like using shutdown engines in its calculations.

Correct.  And that's not a bug-- it's a feature.  It's by design, and it basically has to be that way.

BetterBurnTime, when you think about it, is all about predicting the future, which is always dicey-- particularly when the actual results of that future may involve human decisions that are impossible to predict.

So BetterBurnTime can't (and therefore makes no attempt to) guess what the player is going to do.  Instead, it makes simpleminded predictions based on what the ship can do, which is better-defined.

There were several places where I had to make a judgment call.  Should I include deactivated engines, or not?  If an engine has a thrust limiter set-- should I make prediction based on the current value of the thrust limiter,  or should I use the 100% thrust level, since the player could up the thrust if they wanted to?

In each case, there wasn't an unambiguously "correct" answer that's guaranteed to cover all possible situations ever, so I picked what seemed to me to be the most reasonable choice-- i.e. what would most players want or expect, most of the time.  In software UI design we refer to this as the "principle of least surprise".  So, I deliberately do not include deactivated engines, and I treat thrust-limited engines as having the current thrust-limiter value set.  Why?  Because both of those things (active/inactive status, and thrust limiter setting) are fairly clear statements of player intent, so it's best to just take them and use them without second-guessing the player.

For example, there are lots of scenarios (I would contend, by far the majority scenario) where including an inactive engine would be bad.  What if you have a mothership, with little ships docked to it-- perhaps with their engines pointing sideways, or even retrograde to the main ship.  Their engines are turned off, of course.  Calculating burn time for the ship had better not include those, because they're going to stay turned off.  Another case:  suppose someone has two different kinds of engines on a ship, one of which is high-thrust and the other is high-Isp.  They use the high-Isp engines for dV efficiency when TWR doesn't matter, but they turn on the heavy hitters for takeoff and landing.  Again:  including the turned-off engine in the burn time calculation would be flat-out wrong.

Basically, the issue here is that if an engine is turned off, BBT has absolutely no way of knowing why the engine may be turned off, i.e. what the player's intentions are-- and, more to the point, what the player's future intentions are, i.e. "does the player intend to turn this on when the burn happens?"  There's no way to know.  So, since there's no way to know, BBT just makes the simplest, most reasonable default assumption:  that "off" means "off".

6 hours ago, Errol said:

So here is my request. Could you add a feature where when ever N/A would be displayed to do a check for engines that were were recently shut down and use the thrust values from them to display a guess rather then N/A?

Nope.  Can't, won't.  Reasons as stated above.  Also, can't use "recently shut down" as any sort of indicator, for a variety of reasons.  First, what does "recent" mean?  One minute?  Ten?  An hour?  A day?  There exists no number that will be correct for all situations.  It's not even clear whether it ought to be wall-clock time or in-game time.  Added to which, even if I did have some reasonable number-- which I don't, and there can never be-- it would be a fairly complicated thing to implement.  It would mean that BBT would have to keep track of "when was this engine shut down in the past"-- and would have to remember that for every engine, and would have to remember it even if you save, exit, and re-start the game.  That means I'd have to implement some sort of custom part module to remember the past state, and add MM config to get that added to all engines... it's a mess.

It would also complicate BBT semantics and make them uglier, both for me to debug and for the player to troubleshoot.  Right now, BBT's behavior is completely stateless.  Everything it does is based purely and simply on the current state of the craft-- there's no "history", at all.  That's actually really valuable in keeping the semantics simple, and makes its behavior much easier to understand both for me and for the player.  If it kept track of history, then that would significantly muddy the waters, because predicting "what will BBT do in a given situation" would require analyzing "what has happened in the past" in addition to "what's going on right now".  Yuck.

So, basically, this is a feature that can't happen.  It's too much of an edge case, would involve way too much complexity for the amount of benefit it provides, and in any case it would be a cure worse than the disease because any scheme that involves including shut-down engines would break lots of scenarios that are more common than the one you describe.

So, sorry, them's the breaks.  It's not a bad idea, and I can see how the current state of affairs could be frustrating; but I really don't see any reasonable way to make it work.

Link to comment
Share on other sites

@Snark Ok, working from there and trying to come up with something more specific. 

I really just want it to give me the last known value instead of replacing that with N/A upon engine shutdown. Using only the thrust values of what ever engines were being fired right before N/A is printed on the screen. I know i can just fire the engines again for a second to get an update, but that is hardly an ideal solution, especially with more sensitive maneuvers or more complicated navigation (engine ignitor..)

 

EDIT: as an example:

If you are going to print N/A ask:

Is this because engine(s) were shut down via action group?

If yes; then use those engine's values only to continue providing predictions

If no; print N/A

Edited by Errol
Link to comment
Share on other sites

10 minutes ago, Errol said:

I really just want it to give me the last known value instead of replacing that with N/A upon engine shutdown.

That's exactly what the stock burn time indicator does.  :P  So maybe the best answer is just to not run BBT for that case.  :wink:

10 minutes ago, Errol said:

were being fired

But it doesn't know.  That's history, not current state.  So BBT would have to become history-aware, which I contend is a bad thing for various reasons I discuss in my post above.  (In fact, most of what's wrong with the stock indicator-- i.e. the behaviors that everybody hates, which is why BBT is popular-- is precisely because the stock indicator is history-based.  For the most part, people hate that behavior.  The big thing that BBT does is to make the burn time based on current state rather than on history.)

11 minutes ago, Errol said:

ask:

Is this because engine(s) were shut down via action group?

Impossible to know, unless I write a bunch of code to try to intercept action group requests, and then persist that in a VesselModule somewhere so that it remembers that fact.  History again, = bad.

A KSP engine knows if it's active or not.  It doesn't know why it's inactive, or how it got that way, or when.  Trying to make it know is a fat hairy deal.

Believe me, I'm highly motivated to want to make my mods cover a variety of use cases.  If I could see a way to solve your problem that I thought was reasonable, I'd be motivated to see what I could do.  I've been mulling it over and considering various combinations and permutations of logic I could use-- including stuff similar to what you suggest above  And I've come to the conclusion that it just won't work.  I'm sorry, I really am, but I think that's just how the cookie crumbles, here.  I don't see any reasonable way to give you what you want, short of just uninstalling BBT and using the stock indicator, which sounds like it has just about exactly the behavior you're looking for in this case.  :wink:

Link to comment
Share on other sites

20 minutes ago, Snark said:

So, basically, this is a feature that can't happen.  It's too much of an edge case, would involve way too much complexity for the amount of benefit it provides, and in any case it would be a cure worse than the disease because any scheme that involves including shut-down engines would break lots of scenarios that are more common than the one you describe.

So, sorry, them's the breaks.  It's not a bad idea, and I can see how the current state of affairs could be frustrating; but I really don't see any reasonable way to make it work.

I do agree that what he's asking for would be a nightmare that shouldn't be implemented.

However, I see two things that would allow for pretty much accomplishing his objective.

1)  Auto Asparagus can figure out where engines are pointed.  It uses this to recognize separation motors (they burn sideways) and upper stages (something's attached to the engine, it can't fire yet.)  This would rule out almost all unusable engines.

As for the case of the space and landing engines on the same craft (something I've personally never done, I haven't seen a case where it doesn't make more sense to leave the space engines in orbit) simply figure they'll all fire.

2)  Don't try to track recently turned off.  Simply have two modes--active engines and all engines (not counting those removed by my first point.)  If nothing is turned on always display the all engines value.  If all engines are being counted do something like put the time in red to indicate it won't actually work.

Link to comment
Share on other sites

The only thing I can come up with that would be simple would involve creating some sort of UI to allow you tell BBT what engines to use, but that would defeat the purpose of having it be lightweight and automatic. 
 

Do an unstaged engine and an engine that was staged and shutdown have any differentiating markers in the game engine? Do they look different from engines that are otherwise not producing thrust (either no fuel, or throttle set to zero and minThrust = 0 for that engine)?

Link to comment
Share on other sites

32 minutes ago, Loren Pechtel said:

Auto Asparagus can figure out where engines are pointed.  It uses this to recognize separation motors (they burn sideways) and upper stages (something's attached to the engine, it can't fire yet.)  This would rule out almost all unusable engines.

BBT also knows where engines are pointed, and takes that into account.  If you have a powerful engine on the back of your ship... and mount a retrograde engine on the front of your ship... the BBT burn time estimate goes up when that retrograde engine is active, since activating the throttle at that point would have the engine working against you.  Or if you've got engines that are pointed outwards at an angle rather than straight retrograde, BBT will accurately calculate cosine losses.

So no, that wouldn't work, at all.  Asking BBT to do something other than what it's currently doing would basically be asking it to infer what the player's intentions are based on which direction an engine is pointing, and that's simply something I won't do.

Also... even if I did do that, that wouldn't solve the problem of engines that are pointed the same way but aren't all active, for some reason known only to the player.

BBT is not about inferring player intentions.

32 minutes ago, Loren Pechtel said:

Simply have two modes--active engines and all engines

That would certainly be doable... but I don't like the idea.  It would mean in the 99.99% use case (i.e. where users neither need nor want the "all engines mode", and just want it to calculate based on the engines that are turned on), it would be showing two numbers instead of just one.  Which would be clutter, which I loathe.  I've kept BBT deliberately minimalist, and I really don't want to add any additional information snowing under the user.  I don't want people to have to post here in the thread asking "hey, what are these extra numbers", or having lots of cluttery labels contaminating the nice clean KSP window.

So, no, I'm not gonna go there.  Do not want.

32 minutes ago, Loren Pechtel said:

put the time in red to indicate it won't actually work

Also not gonna do this.  Important principle of UI design.  Never use color as the sole source of vital information, for the prosaic reason that a surprisingly high percentage of the population have color-blindness issues.  It's fine to use color as an enhancement, but it always has to be possible for someone who can't see the color to be able to tell what's going on.

24 minutes ago, Errol said:

The only thing I can come up with that would be simple would involve creating some sort of UI to allow you tell BBT what engines to use, but that would defeat the purpose of having it be lightweight and automatic.

Yup.  And therefore pretty much a deal-killer.

It would be easy to, for example, indicate a PartModule that decorates the right-click menu of engines with a toggle button, "Include in Burn Time Estimate", or perhaps "Include In Burn Time Estimate Even When Inactive", or whatever.  Except that I'm not gonna.  It's an extreme edge case, and it would add clutter to the window, and it would be confusing to the 99.99% of the users who will never, ever use this feature and neither need nor want it.

And I really, really hate UI clutter.

<rant>
I still have the slithering creeps over all the tons of buttons they infested the PAW with in KSP 1.2.  If I want to take a crew report, every blessed time I have to spend several agonizing seconds visually rummaging through all the buttons in the menu, like I was reading a Form 1040, because the gosh-darn menu for command pods now has about umpty-zillion buttons on it instead of the tiny handful I want.  I wish to dickens that they'd give me some sort of a game setting for choosing what I want to see, so that I can turn off the ones I find stupid, useless, and cluttery and never, ever, ever use, and always get in my way.  Such as "Aim Camera Here", or the autostrut options, or various others.  The last thing I'm going to do is add yet another button that never gets used.  Blech.
</rant>

[pause to inhale]  So, anyway, no, not gonna happen.  :wink:

24 minutes ago, Errol said:

Do an unstaged engine and an engine that was staged and shutdown have any differentiating markers in the game engine?

Not in front of my KSP computer at the moment, but I believe the answer is yes-- stageable parts need to know whether they've been staged, so that the game knows how to populate the staging UI and what should happen when the player hits the spacebar.  So excluding "engines that aren't staged yet" would be easy, I think, if I wanted to do something with "engines that are inactive but not if the reason is that they haven't been staged yet."

Except that I don't want that, because there are plenty of use cases that tell me not to count inactive engines, even if it's not because of staging, as discussed above.

24 minutes ago, Errol said:

Do they look different from engines that are otherwise not producing thrust (either no fuel, or throttle set to zero and minThrust = 0 for that engine)?

The main cases for an engine not producing thrust are:  1. it's inactive, or 2. it has a zero thrust limiter, or 3. it's starved for fuel, or 4. the throttle is set to zero.  BBT handles all of these cases.

In the case of inactive engines, I believe it's easy to know whether it's been staged yet or not.  But that's not super useful in this case, so the fact that it's easy is not particularly relevant.

Link to comment
Share on other sites

Thank you for the detailed explanations.

EDIT: I tried your suggestion of uninstalling BBT, @Snark and lo, I get predictions again, only now they are completely wrong for some strange reason. Like every burn is predicted to be orders of magnitude longer then they are. And they continue to remain many times what they should be, all throughout the burn. I have no idea what is causing this. The dV gauge still works fine though. 

Edited by Errol
Link to comment
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...