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

[Snark]

4 hours ago, Loren Pechtel said:

Anyway, I found what appears to be a bug--I'm not getting a suicide burn timer for a Kerbal, just a time to impact.  I have a rover on Minmus that needs a part, I stuck it, a screwdriver and some extra fuel in an engineer's backpack and kicked him out the airlock.  Impact timer but no burn indicator.

It's not a bug, it's a (missing) feature, by design.  You'll find that there's also not a burn time indicator for orbital rendezvous for an EVA kerbal, either.  It's not that something broke, it's that the feature simply isn't there.

EVA kerbals are hard to do right, because they don't have free-axis rotation the way that ships do, so I never added that feature for them.

2 hours ago, Jebs_SY said:

What I wonder more... I start a 60 seconds estimated burn in my highly modded install, but only set the throttle to 50%.... it stays around 60s after the burn start. I had expected, it would show 120s cause I am only using the half throttle.
However, when I limit the engine to 50% it does go to 120s. Is this a mod conflict on my side or was it that way always?

Yup, that's exactly by design, and it's the way it always has been.

BetterBurnTime, by design, shows you "how much burn time will it take if I max the throttle?"  If you think about it a little... it pretty much has to be that way.  If it changed every time you adjusted the throttle, not only would the numbers be jumping all over the place, but also you'd have "N/A" showing up whenever the throttle is at 0%, which is the exact opposite of what you want.  ("Your throttle is at 0%.  It will take you infinity seconds...")

BetterBurnTime doesn't try to tell you what a ship will do (because that's impossible, since it can't predict what you're going to do).  Instead, it says what the ship can do, i.e. assuming max throttle.

It does take the thrust limiter into account, because it treats that as part of the ship design.  It's a clear statement of player intent, so is safe to base predictions on.

[Loren Pechtel]

37 minutes ago, Snark said:

It's not a bug, it's a (missing) feature, by design.  You'll find that there's also not a burn time indicator for orbital rendezvous for an EVA kerbal, either.  It's not that something broke, it's that the feature simply isn't there.EVA kerbals are hard to do right, because they don't have free-axis rotation the way that ships do, so I never added that feature for them.

Why does the lack of proper rotation interfere with with figuring a suicide burn?  Simply assume the jet is pointed correctly.

[Snark]

13 hours ago, Loren Pechtel said:

Why does the lack of proper rotation interfere with with figuring a suicide burn?  Simply assume the jet is pointed correctly.

Because it's not, in fact, pointed correctly, and therefore any number it gives would be a misleading lie that would cause players to kill kerbals.

I'd rather present no information at all, than present misleading information-- particularly if the misleadership is such that it would cause wrecks.  That's why, for example, I deliberately don't provide a "start burn" countdown indicator for time-to-impact, even with ships:  because it would be off, sometimes badly so, as the mod currently stands.

There's also the question of coding time.  Internally, the game treats EVA kerbals completely differently from ships.  Dealing with them would involve a bunch of extra code-- especially if I "do it right" to provide a similar level of support for ships.  It's not insuperably hard-- I mean, we're not talking weeks of work, here-- but it is a chunk of time, which I have very little motivation to do, since I rarely need that functionality in my own games.

Bear in mind that modders, like me, are doing this as a hobby, for our own enjoyment-- it's not like we're getting paid for this.    There's IRL stuff competing for my time:  full-time job, various IRL responsibilities, spending time with friends and loved ones.  And when I do have time to spend on KSP... I'm a player, first and foremost.  Every minute spent coding a mod is a minute taken away from my KSP play time.  So when I mod, I do so in order to improve my gameplay experience.  And where modding is concerned, there is far, far more to do than there is time available to do it.  Therefore, I have to prioritize:  focus my modding time on the features I care about the most.

That's not to say that I would never, ever give EVA kerbals some love... but in terms of bang-for-the-modding-buck, it's fairly far down on the list.  There are a couple of BetterBurnTime features, in particular, that would come ahead of it, and both of those are likely to be time-intensive.  One would be to enable time-to-impact for atmospheric planets.  The other would be to improve the calculation of impact time to take terrain and projected retrograde thrust into account, so that it actually would be accurate enough that I could put a countdown timer for the suicide burn.

Not that I'm promising either of those features soon.  They'll be a chunk of work, I'm not sure how long it'll take or when I will have time to get to it; and when I do set out to implement them, it's possible I could run into some type of difficulty that makes it turn out to be impractical.

But I can say fairly confidently that until and unless those features come along first, you won't see EVA kerbal burn times.

[Loren Pechtel]

20 hours ago, Snark said:

Because it's not, in fact, pointed correctly, and therefore any number it gives would be a misleading lie that would cause players to kill kerbals.

There's also the question of coding time.  Internally, the game treats EVA kerbals completely differently from ships.  Dealing with them would involve a bunch of extra code-- especially if I "do it right" to provide a similar level of support for ships.  It's not insuperably hard-- I mean, we're not talking weeks of work, here-- but it is a chunk of time, which I have very little motivation to do, since I rarely need that functionality in my own games.

If your jetpack isn't pointed correctly and you try a suicide burn you're going to die anyway.  Might as well assume it's pointed correctly.

I do understand about coding time.

[Snark]

On 1/25/2017 at 11:03 AM, Loren Pechtel said:

If your jetpack isn't pointed correctly and you try a suicide burn you're going to die anyway.

No, I disagree.

• If your jetpack isn't pointed correctly, and you try a suicide burn just by eyeball, then you may or may not die, depending on your skill and caution level.
• If your jetpack isn't pointed correctly, and a mod is lying to you by telling you a radical underestimate of the burn time, and you trust it and wait too long to start, then yes, you're going to die.

IMO, the second alternative is far worse than the first.  In the first alternative, they may die... and if they do, that's entirely the player's responsibility.  In the second, they will die... and that's my fault.  Uh-uh.  Nope.  Do not want.

Just to repeat what I said earlier (perhaps it got lost in the shuffle, I know I tend to toss a whole lotta words out there):

On 1/24/2017 at 2:06 PM, Snark said:

Because it's not, in fact, pointed correctly, and therefore any number it gives would be a misleading lie that would cause players to kill kerbals.

I'd rather present no information at all, than present misleading information-- particularly if the misleadership is such that it would cause wrecks.

^ This.  This is the complete showstopper right here.  I will not produce a feature that's virtually guaranteed to kill kerbals.  I would be doing my users a grave disservice by doing so.  As far as I'm concerned, end of story right there.

The coding-time thing makes doing this feature a lower priority than other stuff... but I won't do it at all if it's kerbicidal.  I'll take the time to do it the "right" way (i.e. non-kerbicidally, taking into account how EVA orientation generally works), or I won't do it at all.  Unfortunately in this case, doing it the "right" way makes the feature a lot more complex and expensive to implement, which further bumps it down the priority totem pole.

Sorry, them's the breaks.

 

[Blackline]

What's the status of some basic information in atmospheric conditions? You mentioned a possibility earlier (maybe an advanced option to just ignore drag at all, which is OK for the low speed we usually have during space-x style landings)

[Snark]

6 hours ago, Blackline said:

What's the status of some basic information in atmospheric conditions? You mentioned a possibility earlier (maybe an advanced option to just ignore drag at all, which is OK for the low speed we usually have during space-x style landings)

Status is pretty much unchanged from previously.

• Atmospheric stuff is hard.  Adding this would be a pretty big-ticket item.
• IRL stuff keeps me pretty busy, as have my other mods.
• If-and-when I do have time to give BBT some new-feature love, "make the impact tracker more accurate so that it actually projects your impact point instead of just using the ground height under the ship right now" would be a higher priority than atmospherics.

So, basically, atmospheric features would be a great big time-consuming thing that has to wait in line behind other, higher priority time-consuming things, and I only have a certain amount of time to spend.  Also, my motivation's fairly low for that feature, since I don't need it myself in my own gameplay, which is overwhelmingly what prods me into implementing stuff.

TL;DR:  really not happening any time soon.  I'm not saying "never", but I'd be surprised if I get to something like that inside a year.  Sorry I don't have better news for you-- it's a reasonable feature to ask for, it just happens to have the stars aligned against it these days.

[linuxgurugamer]

@Snark

Came across a very bad issue here.  I was building a new mod which will be using BBT, and am getting the following errors:

Severity	Code	Description	Project	File	Line	Suppression State
Warning		The primary reference "BetterBurnTime" could not be resolved because it was built against the ".NETFramework,Version=v4.5.2" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v3.5".	SuicideBurn			
Warning		The primary reference "BetterBurnTime" could not be resolved because it has an indirect dependency on the framework assembly "System.Numerics, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v3.5". To resolve this problem, either remove the reference "BetterBurnTime" or retarget your application to a framework version which contains "System.Numerics, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089".	SuicideBurn			
Warning		The primary reference "BetterBurnTime" could not be resolved because it has an indirect dependency on the .NET Framework assembly "System.Xml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "4.0.0.0" than the version "2.0.0.0" in the current target framework.	SuicideBurn			
Warning		The primary reference "BetterBurnTime" could not be resolved because it has an indirect dependency on the .NET Framework assembly "System.Security, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which has a higher version "4.0.0.0" than the version "2.0.0.0" in the current target framework.	SuicideBurn			
Warning		The primary reference "BetterBurnTime" could not be resolved because it has an indirect dependency on the .NET Framework assembly "System.Data.SqlXml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "4.0.0.0" than the version "2.0.0.0" in the current target framework.	SuicideBurn			
Warning		The primary reference "BetterBurnTime" could not be resolved because it has an indirect dependency on the .NET Framework assembly "System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "4.0.0.0" than the version "3.5.0.0" in the current target framework.	SuicideBurn			
Warning		The primary reference "BetterBurnTime" could not be resolved because it has an indirect dependency on the .NET Framework assembly "System.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which has a higher version "4.0.0.0" than the version "2.0.0.0" in the current target framework.	SuicideBurn			
Warning		The primary reference "BetterBurnTime" could not be resolved because it has an indirect dependency on the .NET Framework assembly "System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "4.0.0.0" than the version "2.0.0.0" in the current target framework.	SuicideBurn			
Warning		The primary reference "BetterBurnTime" could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "4.0.0.0" than the version "2.0.0.0" in the current target framework.	SuicideBurn			

This is version 1.5.3

I also forked the repo, and in VS, it says that the target framework is .NET Framework 4.5.2

I fixed it on my system, it compiled cleanly.

Apparently I ran afoul of the license.  It was my belief that an unchanged copy could be redistributed (the license is: Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International Public License), it doesn't say no distribution.  But, since I've been told that I can't provide a DLL of the mod totally unchanged, just recompiled, I'm going to provide a series of steps here for you to recompile it for yourself.

1. Install Microsoft Visual Studio
2. Download and unzip the source for this mod from Github
3. Start Visual Studio
4. Select the option to Open an existing project
5. Navigate to where you downloaded the source, open the file: BetterBurnTime.sln
6. Once it opens, right-click on project in the left: BetterBurnTime, it will be the line which DOES NOT SAY Solution.  Select the last item in the right-click menu which says Properties
7. In the right-pane, in the list of tabs on the left side, click the one which says: Application
8. Find the dropdown which says: Target framework:
9. Select it and select the entry which says:  .NET Framework 3.5.  You will be prompted by Visual Studio that it will need to reopen the project, go ahead and allow it to do so.
10. Now, in the left window, find the line which says References, and click the little arrow to the left of that to open it up  You might need to open up the BetterBurnTime project first (click the little arrow to the left)
11. Select all entries in that section EXCEPT for the one which says Analyzers
12. Right-click and select Remove, and hit OK when asked
13. Now, right-click the line which says References and select Add Reference..., this opens up the Reference Manager
14. In the left of the window, click Browse
15. Navigate to the Kerbal Space Program folder
16. Find the folder which says KSP_x64_Data and double-click on it
17. Find the folder which says Managed and double-click on it
18. In this folder, find the following files and double-click on each:
    1. UnityEngine.UI.dll
    2. UnityEngine.dll
    3. System.dll
    4. Assembly-CSharp.dll
19. You can either repeat the above steps (starting at step # 13) for each file, or you can select all 4 files at the same time by (in Windows) Ctrl-leftClick on each one, then click Add
20. In the top toolbar, there will be a dropdown which says either Debug or Release .  Select Release
21. Hit the F6 key to build the project, you can also do the menu item:  Build->Build Solution
22. Now in Windows, navigate to the BetterBurnTime folder where you put the source code
23. Open the folder called:  src/bin/Release
24. In this folder, you will find a number of files.  Find the file called:  BetterBurnTime.dll and copy it to the BetterBurnTime folder in your KSP GameData directory

 

My apologies for not being able to provide the DLL.  Things like this are why I don't like the No Derivatives licenses, and also why I don't contribute to mods which have that kind of license. 

 

 

Edited April 24, 2017 by linuxgurugamer
removed link to forked version, against ND clause of the license

[bpiltz]

I love your mod.

I have 2 useability requests:

Notice the green burn data text to the right of the NavBall is very difficult to read against the white clouds.  I have to move the camera a lot to work around this.

 

In this second shot, I have changed the camera angle so the green text from KER data (upper right) is now over the same bright white clouds.  It is much easier to read KER text over clouds because KER has a transparent smoke background.  This background decreases the whiteness of the clouds, which increase the contrast and legibility of the green text.  No camera angle gymnastics needed.

 

1st request:  Please make a nifty transparent smoke background box around the Better Burn Time green text readout to fix the cloud contrast problem.

In the screenshots, note that I am using KER to give me a distance to target under the altimeter (top middle).  That piece of data is very helpful info when docking and doing maneuvers in the dark. It's kind of a waste of a whole KER box just to show that and KER distance has it's limitations.  The downfall of using KER for distance: it only calculates to the center of mass of the target (not too helpful for docking) and it always displays a distance to target (e.g. even Minmus when doing a transfer burn from 46 million km away).  

2nd request:  Please have Better Burn Time indicate current distance to target as part of the intercept data near the NavBall.    Extra love if you can display distance to the part of the target ship selected (i.e. a docking port) instead of only the center of mass.  Center of mass is ok for gross rendezvous, but once the docking part is selected, the distance should calculate docking port to docking port.  Better Burn Time is good at knowing when is a good time to start displaying data, so if distance only appears when the intercept data populates that is great!

Thanks for considering.

[Snark]

On 4/23/2017 at 2:00 PM, linuxgurugamer said:

Came across a very bad issue here.  I was building a new mod which will be using BBT, and am getting the following errors:

Thanks for the heads-up!    I'm busy with IRL stuff for a few days, but will take a look as soon as I'm able.  If it's a straightforward fix without side effects, I expect I can release an updated BBT version in fairly short order.

On 4/23/2017 at 2:00 PM, linuxgurugamer said:

Apparently I ran afoul of the license.  It was my belief that an unchanged copy could be redistributed (the license is: Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International Public License), it doesn't say no distribution.

Correct.  Distribution is just fine, for an unchanged copy.  Emphasis on "unchanged".  If you want to take one of my BetterBurnTime-version.zip files, as-is, byte-for-byte identical without changing one single solitary bit, and then put it up on a website somewhere (with appropriate attribution to me, and license information, as required by my license), then you're perfectly welcome to do so.

On 4/23/2017 at 2:00 PM, linuxgurugamer said:

But, since I've been told that I can't provide a DLL of the mod totally unchanged, just recompiled

Except that it's not totally unchanged.  Nor is it "just recompiled".  It's recompiled with different settings.  Which means it's a different binary from what I've released into teh internetz with my own two hands, and therefore as a mod author I have no a priori way of knowing it won't break anything or anybody anywhere ever under any circumstances, ever.  If there's a bug fix in it, then it's not an "unchanged" copy.

Just to be clear what I'm not worried about:

• Do I think it's a bad idea?  No.
• Is it likely to cause problems?  Very probably not.
• Do you, personally, @linuxgurugamer, know what you're doing?  Sure, of course you do-- you've been around the forums long enough for folks (including me) to know that you're a technically competent guy.

But for me, none of the above issues are the point.  It's simply a matter of my personal requirement that the only BetterBurnTime versions out there are ones that I, myself, have released.  And by "version", I mean that in the very strict sense of "byte-for-byte identical with the zip file that I released".

On 4/23/2017 at 2:00 PM, linuxgurugamer said:

I'm going to provide a series of steps here for you to recompile it for yourself.

<detailed step-by-step instructions>

Thanks!

Or, an alternate approach, with much simpler steps, would be "Thanks for raising it to Snark's attention, just give him a little while to release an updated copy himself." 

Given that BBT has been working this way since November 2015 (ever since initial release), and also that the issue has never come up before now, I expect just a little more time won't be the end of the world.

I hope that the numerous examples in my mods' forum threads have demonstrated that I'm pretty responsive to users who report bugs in my mods, and am fairly prompt about providing bug fixes.

On 4/23/2017 at 2:00 PM, linuxgurugamer said:

My apologies for not being able to provide the DLL.  Things like this are why I don't like the No Derivatives licenses, and also why I don't contribute to mods which have that kind of license.

Yah, sorry about that.  I hate the restrictive license myself, and wish I didn't have to use it.  I originally had a much more permissive license on BBT (and my other mods), until some unfortunate events forced me to reconsider my choice of license.  It made me sad, because the more restrictive license is less friendly to users and (especially) to modders, but I felt I had no choice.

Detailed discussion here, for anyone who's interested, but it boils down to "it only takes one problem user to spook a mod author."  At least, it does if the mod author is me.

That said, though, I am highly motivated to make my mods friendly to mod authors who want to work with them.  Certainly I've got my sacred cows that I refuse to touch... but depending on what a mod author actually wants to do, I'd love to come up with a workaround they can live with, if it's technically possible.

It totally depends on the technical specifics, though.  If any mod author is interested in working with BetterBurnTime, but has issues with the restrictive CC-BY-NC-ND license, please reach out to me in a PM, so we can get down to brass tacks.  Would love to work something out, if it can be done.

[Snark]

On 4/23/2017 at 4:27 PM, bpiltz said:

1st request:  Please make a nifty transparent smoke background box around the Better Burn Time green text readout to fix the cloud contrast problem.

Nice idea!

One issue with it is that I'm a total Neanderthal ignoramus when it comes to UI programming in Unity.  Minimal as the BetterBurnTime UI may seem, it's actually by far the most UI programming I've ever done... and it's basically just cloning the display that was already there for stock burn times, so I didn't have to figure out how to code custom UI elements.

Not saying it's a showstopper, just that I'd have a bit of a learning curve to climb if I decide to go with it.  Not that learning is a bad thing. 

No promises, but I like the idea (assuming it's not super hard to code, and that I like how it looks if I can get it to work)-- lemme mull it over a bit.

On 4/23/2017 at 4:27 PM, bpiltz said:

2nd request:  Please have Better Burn Time indicate current distance to target as part of the intercept data near the NavBall.    Extra love if you can display distance to the part of the target ship selected (i.e. a docking port) instead of only the center of mass.  Center of mass is ok for gross rendezvous, but once the docking part is selected, the distance should calculate docking port to docking port.  Better Burn Time is good at knowing when is a good time to start displaying data, so if distance only appears when the intercept data populates that is great!

Hmm.  I can see two issues with this:

First issue:  it adds to the UI clutter.  I'm very much a UI minimalist, and I hate having lots of numbers everywhere.  I'm incredibly stingy with UI pixels & information (which is one of the reasons I never use KER-- I can't stand having any extra dialog boxes or other UI in my game window).  When I was adding the rendezvous-tracker feature to BBT, I mulled over various ways of displaying information, and finally settled on "how long to intercept" and "how far at closest intercept" as the really important numbers.  I'm such a tightwad with UI clutter that even showing just two numbers pushes my envelope.  Adding a third number would give me the collywobbles.

Yeah, I know, I'm a bit of an odd duck. 

(I suppose one thing I could do would be to make it customizable, i.e. allow the user to supply a format string in config, so that people who want a distance display could have it.  But since I would never, ever use such a feature myself, that greatly lessens my motivation to code it; when I mod, I'm primarily motivated by the selfish desire to improve my personal game experience, so I'm not so great at implementing feature requests for features that I myself wouldn't use.)

Second issue:  I'm having trouble understanding the need for such a feature.  I dock in KSP myself, a lot, including in pitch darkness, and I've never found myself wanting this.  Probably because the stock game already gives a nice display of the distance, right there in the main view... so what's the need to display that number somewhere else?

Could you explain your use case a bit more?  i.e. why the stock display of distance-to-target isn't enough for your purposes?

[bpiltz]

7 hours ago, Snark said:

Could you explain your use case a bit more?  i.e. why the stock display of distance-to-target isn't enough for your purposes?

Hmmm... I don't see a distance to target displayed in the stock view.  Perhaps a setting I have missed?

[Snark]

9 hours ago, bpiltz said:

Hmmm... I don't see a distance to target displayed in the stock view.  Perhaps a setting I have missed?

I mean the standard one that everyone always uses. I think it toggles via... F4, maybe? Not sure how to turn it on/off, since it's so essential to me that I've never had any reason to turn it off.

[monstah]

Yes, f4.

[bpiltz]

13 hours ago, Snark said:

I mean the standard one that everyone always uses. I think it toggles via... F4, maybe? Not sure how to turn it on/off, since it's so essential to me that I've never had any reason to turn it off.

LOL.  That fixed my problem.  >1000 hrs playing this game and it's the simple things.  I must have inadvertently toggled it off at some point and wrongly assumed a KSP update nerfed the feature.  So,....nevermind on that feature request.  I, too, appreciate UI simplicity.  Thanks for the tech support!

[Snark]

48 minutes ago, bpiltz said:

LOL.  That fixed my problem.  >1000 hrs playing this game and it's the simple things.  I must have inadvertently toggled it off at some point and wrongly assumed a KSP update nerfed the feature.  So,....nevermind on that feature request.  I, too, appreciate UI simplicity.  Thanks for the tech support!

Ha!  Well, darn.  Now I see that I should have responded to your feature request with "Oh, sure, I already added that feature to BetterBurnTime long ago, you can toggle it on with F4." 

[Gordon Dry]

I still have the issue that it says
Est. burn: (~N/A)
Node in T -46s
Start burn in >24h

I never see the estimated burn prior the burn.
Start burn is always >24h

I suspect ProceduralParts or ProceduralFairings because they provide weidness on all corners. But I'm not sure.

Log:
https://www.dropbox.com/s/8crvues68k58vqt/2017-05-12-1 KSP.log.7z?dl=1

Edit for convenience:
https://www.dropbox.com/s/hogdvl99f5wst43/2017-05-12-1 KSP.log.zip?dl=1

Edited May 16, 2017 by Gordon Dry

[Gordon Dry]

This time I set up a vessel in Saturn V style but still with procedural fairings.

I discovered something new:

"BetterBurnTime" with activated engine
RCS thrusters are set to "Fore by throttle" It shows no "estimated burn" but the "burn time"

"BetterBurnTime" with deactivated engine
RCS thrusters are set to "Fore by throttle" It shows no "estimated burn" (this time with a ~ added) and NOT the "burn time" anymore

 

Edited May 17, 2017 by Gordon Dry

[Snark]

On 5/12/2017 at 8:43 AM, Gordon Dry said:

I still have the issue that it says
Est. burn: (~N/A)
Node in T -46s
Start burn in >24h

I never see the estimated burn prior the burn.
Start burn is always >24h

This is the typical behavior if BBT decides that you have no ability to thrust at all-- e.g. if there are no engines on your craft, or they're all deactivated, or you have no fuel for them, etc.

On 5/12/2017 at 8:43 AM, Gordon Dry said:

I suspect ProceduralParts or ProceduralFairings because they provide weidness on all corners. But I'm not sure.

Not impossible, I suppose, but seems pretty unlikely to me-- parts packs generally wouldn't cause a problem unless they do something very weird to the data on the ship.  BBT just does math involving total ship mass, and the mass / orientation / fuel consumption of the engines, so adding some procedural parts shouldn't make BBT completely freak out.  Would need to see a log to be sure.

On 5/12/2017 at 8:43 AM, Gordon Dry said:

Log:
https://www.dropbox.com/s/8crvues68k58vqt/2017-05-12-1 KSP.log.7z?dl=1

Thanks, but it appears to be a ".7z" file, whatever that is, which means I can't read it unless I figure out what software that is and then install something (which I'm not gonna).  Could you post a plaintext log somewhere?

On 5/13/2017 at 2:23 AM, Gordon Dry said:

I discovered something new:

Yes, the clue is in your album title, "with deactivated engines".  If your engines are deactivated, the burn time is infinity, and BBT won't give you any estimate.

Yes, I see that you mention that you've got a game setting for RCS thrusters are set to "Fore by throttle" .  So I assume your concern is, "I've got RCS thrusters, and they're turned on, so why doesn't BBT tell me about that?"

Answer:  because I never implemented any such feature.  The "fore by throttle" setting is a reasonable indicator that "I plan to use this like a regular engine", so I suppose it's reasonable to expect BBT to take that into account.  However, that feature didn't exist when I wrote BBT, so you don't have it now.  RCS is implemented using a completely different system from "regular" engines in KSP, so it would need special code in BBT to handle it, and such code has never been written because it never occurred to me (and nobody ever asked for it) before now. 

So, what you've found in that particular case isn't a bug-- it's a missing feature.  "Fixing" it means writing a new feature, and a non-trivial one at that.

So, thanks for pointing this out!  I'll add it to my "to do" list-- at least, to consider for implementation.  No promises on whether-and-when I'd actually implement it; I'd have to see how big a deal it would be to add.  If it looks like something that would be large and complex, then the likelihood would be small.  If it's fairly quick and easy, then I'd be much more likely to consider it. 

[Gordon Dry]

You really don't know what 7-zip is?
You're kidding ...

Quote

This is the typical behavior if BBT decides that you have no ability to thrust at all-- e.g. if there are no engines on your craft, or they're all deactivated, or you have no fuel for them, etc.

Of course I write about this issue because I got engines which are activated and got fuel ...

Edited May 16, 2017 by Gordon Dry

[TheRagingIrishman]

3 minutes ago, Gordon Dry said:

Of course I write about this issue because I got engines which are activated and got fuel ...

On 5/13/2017 at 5:23 AM, Gordon Dry said:

In the picture above, whatever mod provides those info windows says you have a max thrust of 0 so something is wrong with your engine setup, not with BBT 

[Gordon Dry]

Well, in that specific album I got the engines turned off, but alltogether within the last days I also got the engines activated sometimes...

And the issue is always there...

[TheRagingIrishman]

5 minutes ago, Gordon Dry said:

Well, in that specific album I got the engines turned off, but alltogether within the last days I also got the engines activated sometimes...

And the issue is always there...

Well can you put up a pic where the engines are active but BBT is wrong?

[Snark]

14 hours ago, Gordon Dry said:

You really don't know what 7-zip is?

Correct, never heard of it.  Perhaps it might have slid past my eyeballs at some point in the past as part of the alphabet soup of various compression formats that have swirled around out there over the years, but certainly nothing that I ever had any reason to pay any attention to (or remember).  When I'm on Windows (e.g. anything relating to KSP), I just use what basically everyone uses, which is .zip.  When I'm on Linux (e.g. work stuff), I use what basically everyone uses, which is .gz.

Certainly I "know" what it is, in the generic sense that everyone "knows" everything now, because Google is just a mouse-click away.  However, my main point above-- in case it wasn't clear-- is that I'm not going to install new software on my system just to read this one file.

14 hours ago, Gordon Dry said:

You're kidding ...

Nope.  Not sure which of my posts (here or in my other mod threads) may have given you the impression that I'm jokingly dismissive of users' concerns.

In any case, it's up to you.  When you're using a product that someone has put in a lot of hard work to give you a shiny toy for free, and then you ask them to spend their personal time to give you free tech support on it, and they politely ask for clarification to help them help you:  you can,

1. meet them halfway by providing them what they've requested, or
2. ridicule them and choose not to provide the additional information they've asked.

It's your choice, of course, but I'd suggest that the former course would be more likely to result in productive help. 

Posting a log file somewhere that's just plain text would be most convenient for me-- I'd prefer that if possible, thanks.  If there's some reason why you can't do that, a .zip file would also be doable, albeit not as convenient.  Anything else is not going to get looked at, sorry.

14 hours ago, TheRagingIrishman said:

Well can you put up a pic where the engines are active but BBT is wrong?

^ Pretty much this.  In particular, in your screenshot here,

14 hours ago, TheRagingIrishman said:

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

^ this.  This grabs my attention, right here (thanks, Irishman, for pointing this out).  There's something about your ship that is convincing not just BBT but at least one other mod as well that you have no thrust capability.

I have no idea what that other mod might be, or how it's implemented (i.e. how it comes up with its "max thrust" number), but just applying Occam's razor, I would hazard a guess that it just iterates through all the parts in your ships, identifies what it considers to be "engines", and adds up their thrust ratings, or something like that-- i.e. at least approximately the same thing BBT does.

So, in the absence of further evidence, I gotta say that however you've got things set up on your computer, there's something about it that's making your engines appear to have zero thrust capacity to mods (such as BBT) that try to track that sort of thing.

Do you get this kind of problem even if you just launch a plain-vanilla rocket that only has stock parts on it (including stock engines)?

[Gordon Dry]

Okay, I'm doing .zip from now on, but have to say that .zip is nearly double the size than .7z and I didn't use it for years as long no special circumstances forced me to do.
I edited the post above with a new link.

And I can't provide "text postings" of full logs because I don't want to get an account on pastebin to be able to post text stuff that is longer than 512 KB ...