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

[Bloojay]

13 hours ago, Snark said:

The impact tracker does show you how many seconds of burn time is needed to cancel your velocity at the surface.

All I was asking

13 hours ago, Snark said:

"please show a countdown indicator that would put the start-of-burn exactly when the time-to-impact equals the time-to-burn."

Not at all what i was asking

[Snark]

14 hours ago, Snark said:

The impact tracker does show you how many seconds of burn time is needed to cancel your velocity at the surface.

 

6 minutes ago, Bloojay said:

All I was asking

Great!  Problem solved. 

[DStaal]

I can't recall if I saw anything on this on my previous read-through of this thread: Is it possible to get a burn time indicator for a falling Kerbal?  I'm sure we've all had those 'Jeb just got launched at 45m/s into space' moments on some weird miscalc 'collision', and it'd be nice to have some idea of what it's going to take to land him safely. 

[Snark]

10 hours ago, DStaal said:

I can't recall if I saw anything on this on my previous read-through of this thread: Is it possible to get a burn time indicator for a falling Kerbal?  I'm sure we've all had those 'Jeb just got launched at 45m/s into space' moments on some weird miscalc 'collision', and it'd be nice to have some idea of what it's going to take to land him safely. 

Not really.

The impact-tracker does work for EVA kerbals-- you'll see an indicator of how many seconds to impact.  But it won't show any indicator of "burn time", because BBT does all of its calculations based on engines, and an EVA kerbal doesn't have engines per se-- the EVA thrusters are handled differently, internally.

Nor would it be a quick or simple feature for me to add in any useful fashion.  EVA thrusters are quirky-- you don't maneuver kerbals the way you do spaceships.  For example, a kerbal near the surface of a planet on a suborbital trajectory is going to orient heads-up, so you can't thrust "retrograde":  you can only thrust up and/or back, and either one of those (horizontal or vertical speed) could be a limiting factor for landing safely.  It's not trivial to figure out what the right behavior should be, and in any case, it would require a completely different body of code from what I've written for engines.

All of which is to say that such a feature is pretty much in the "ain't gonna happen" category.  Too much code and too much problem complexity for too little return (i.e. handling one particular edge case that comes up pretty rarely, at least in my experience).

(Incidentally, the closest-approach indicator for orbital rendezvous works for EVA kerbals, too.  Like the impact tracker, it won't give you a burn time.  But it'll tell you how long until intercept, and what the closest approach will be, so that can be useful for navigating your orbiting kerbal if you're using their EVA thrusters to meet up with a ship.)

[DStaal]

Thanks - I was wondering if there was some special issues with an EVA Kerbal that prevented it from working.  So, thanks for the explanations.     (Is it the same reasoning why they only ever show 'time to impact', without it switching to 'time to land'?)

[Snark]

4 hours ago, DStaal said:

Is it the same reasoning why they only ever show 'time to impact', without it switching to 'time to land'?

Kind of.  A "time to land" feature is there, but it turns out to be a lot less useful than you'd think.

Long boring explanation in spoiler section.

Spoiler

One of the things that makes a "time to impact" indicator a lot trickier than you might think (compared with an orbital burn time) is this:  Essentially what you're showing is a prediction about the future.  And in the case of descending to a planetary surface... the future is uncertain, because a lot of it depends on what the player will do.  There may be one particular course of action that's a very common scenario for what a player is likely to do, but the mod doesn't actually know.

Therefore, all it can do is fall back to the simplest, deterministic case:  It shows "what will happen if the player does nothing."  In other words:  If you just coast to your doom, how long will it take to hit the surface?  (That's why you generally want to wait until a bit after the time-to-impact equals the time-to-burn, because when your burn your engines to slow down, the actual impact will happen later than it would have if you hadn't.)

A few versions ago, I actually had what seemed like a clever idea to me at the time, and then realized after implementing it that it's practically useless.  My brilliant idea was this:  "Hey, how about I take whichever part on the ship is the bottom-most (i.e. the one that will hit the ground), and then take its impact tolerance, and then look at the projected speed when the surface is reached.  If the speed of impact is lower than the impact tolerance, then change the wording to say 'Touchdown' instead of 'Impact'.  That way the player knows when they've burned enough and can cut the engines!"

Great idea, right?  Except here's the problem:  I'm using the projected speed if you're not burning at all.  At all times, even if you're actually burning already.  In other words, the only time it would ever display the "touchdown" wording is if your speed at the surface is below impact tolerance, if you free-fall from where youare now to the surface, and that's including the downwards velocity that you already have now.

And in practice, that means that it never switches from "Impact in ___" to "Touchdown in ___" until just a split fraction of a second before you touch down, even on a somewhat low-gravity world like the Mun.  You can see it on Gilly, but that's about it.  So I expect that very few BBT users are even aware that this "feature" exists.

(Fun trivia fact:  The mod also takes surface liquid into account, so if you're coming down over an ocean, it will say "splashdown" instead of "impact".  Except that you can never, ever see this in the stock solar system, or in any planet pack I've played with thus far.  Because I've got BBT coded so that it completely disables the impact tracker if you're on a world with an atmosphere, and there aren't any vacuum planets with oceans... at least none in any mod I've played with.  But if you're ever playing with some mod that has a vacuum planet that does have oceans, then BBT has got you covered.) 

 

[Kerbart]

On 5/30/2016 at 11:07 PM, Bloojay said:

All I was asking

Not at all what i was asking

Thank you Snark, for taking the time to figure out what was asked and answering it.

(Hey, someone has to say “thank you” for your efforts, right?)

[Snark]

Hi all,

I've released v1.4.4 of BetterBurnTime.  This is just a compatibility update for KSP v1.1.3-- no new features.

To be clear:

• BBT 1.4.3 won't run in KSP 1.1.3 or later
• BBT 1.4.4 (which I've just now released) won't run in KSP 1.1.2 or earlier

When I say "won't run"... well, actually, it kinda-sorta runs, but the "time to impact" is broken:  doesn't display, and the log gets spammed with thousands of error messages.  Other features are unaffected.

So, if you're running KSP 1.1.3, update to the latest BetterBurnTime.

Enjoy!

[eberkain]

2 minutes ago, Snark said:

Hi all,

I've released v1.4.4 of BetterBurnTime.  This is just a compatibility update for KSP v1.1.3-- no new features.

To be clear:

• BBT 1.4.3 won't run in KSP 1.1.3 or later
• BBT 1.4.4 (which I've just now released) won't run in KSP 1.1.2 or earlier

When I say "won't run"... well, actually, it kinda-sorta runs, but the "time to impact" is broken:  doesn't display, and the log gets spammed with thousands of error messages.  Other features are unaffected.

So, if you're running KSP 1.1.3, update to the latest BetterBurnTime.

Enjoy!

Thanks for the update.   

[Loren Pechtel]

MechJeb did a suicidal burn and BetterBurnTime responded by filling the Alt-F12 debug window with exceptions about not finding something like gForce.  Unfortunately, things went kablooie before I got it copied down.  (Periapsis was 3km above Mun--it flew into a mountain.)

 

Update:  MechJeb set up an even more suicidal burn but I didn't let it do the burn.  It was still enough to freak out BetterBurnTime.  From Alt-F12:

[Error]: [BetterBurnTime] (MissingFieldException) Field '.Vessel.gForce' not found.:  at BetterBurnTime.ImpactTracker.Recalculate () (0x00000) in <filename unknown>:0

at BetterBurnTime.ImpactTracker.LateUpdate () (0x00000) in <filename.unknown>:0

Edited July 2, 2016 by Loren Pechtel

[Snark]

19 hours ago, Loren Pechtel said:

MechJeb did a suicidal burn and BetterBurnTime responded by filling the Alt-F12 debug window with exceptions about not finding something like gForce.  Unfortunately, things went kablooie before I got it copied down.  (Periapsis was 3km above Mun--it flew into a mountain.)

Update:  MechJeb set up an even more suicidal burn but I didn't let it do the burn.  It was still enough to freak out BetterBurnTime.  From Alt-F12:

[Error]: [BetterBurnTime] (MissingFieldException) Field '.Vessel.gForce' not found.:  at BetterBurnTime.ImpactTracker.Recalculate () (0x00000) in <filename unknown>:0

at BetterBurnTime.ImpactTracker.LateUpdate () (0x00000) in <filename.unknown>:0

Sounds like you're running into exactly the reason why I updated BetterBurnTime to v1.4.4, for KSP 1.1.3 compatibility.  See my release notes just two posts above your own. 

So, just to confirm:  are you running a BBT version earlier than 1.4.4, on KSP version 1.1.3?  I expect that the answer is "yes", in which case you can fix the problem by updating to 1.4.4.

[RageMode]

On 5/20/2016 at 8:53 PM, Snark said:

Not quite sure what you mean by that.  All engines are deactivated until they're staged, including in stock.  That's what staging means.  As long as you have staged the engines, so that they're active (but throttled to zero, since you haven't started the burn yet), BetterBurnTime ought to pick up on them.  Clearly there's something going on with the mod you're using that's somehow interfering with BBT's calculations, but I have no idea what that might be.  Do you have a clear repro case?  Describe the state of the ship when you're seeing the N/A?

Just want to be sure we've got our terminology straight-- dV is completely irrelevant to burn time, and to the BetterBurnTime mod.  A 100 m/s burn is a 100 m/s burn.

Do you mean "burn time"?  (Which is a completely different thing from dV.)

This has to do with the fact BBT doesn't handle staging. In RO, your engines have a limited number of ignitions. This means it's best not to activate the engine until you're ready to use them, because accidentally hitting the throttle up key would ignite the engine, and possibly ruin your mission. A lot of the engines have only a single ignition, so this is a pretty important fail-safe. Especially when you factor in the ability to lock staging temporarily to further prevent the engine from being activated unless explicitly activated.

 

I haven't actually tried your mod with RO, but I'm guessing it isn't able to calculate the burn time for the next stage. Perhaps a simple way to handle this would be to calculate the burn time based on the next stage if the current stage has no active engines or has no fuel.

 

Another simple way to solve this would be to implement some sort of stage selector for the burn time, so that you can choose which stage the burn time calculations would be performed for. Being able to select the stage by number is the best way I can think of to do this, because it provides a fairly clear way to figure out what engines the burn time is being calculated for.

 

I understand that calculating burn times divided between multiple stages would be rather difficult, but these two options should be fairly simple and shouldn't add excessive performance penalties. The second option would be the best one in my opinion, as it allows the most in terms of versatility, and would work with the most ship designs and staging setups (some people put the decoupler and engine activation on a single stage, some divide them between two stages, for example). It would also be useful to have in the stock solar system, and not just RO.

Edited August 1, 2016 by RageMode

[Snark]

36 minutes ago, RageMode said:

This has to do with the fact BBT doesn't handle staging. In RO, your engines have a limited number of ignitions. This means it's best not to activate the engine until you're ready to use them, because accidentally hitting the throttle up key would ignite the engine, and possibly ruin your mission. A lot of the engines have only a single ignition, so this is a pretty important fail-safe. Especially when you factor in the ability to lock staging temporarily to further prevent the engine from being activated unless explicitly activated.

Ah, okay, that explains it.  Thank you for tracking that down!

BetterBurnTime deliberately ignores any engines that the user has chosen not to activate.  It pretty much has to; it has no way of predicting the future, it doesn't know what the user intends to do.  Added to which, trying to handle staging would also require handling fuel flow, and would make the code insanely more complex.

So, the answer is:  no, BBT doesn't handle staging.  It's by design, and that will never change.  If the user chooses to run a mod that makes them want to not activate engines, then they've effectively made BBT unusable with that mod.

So, basically, this means either "don't try to use BBT with RO", or else go ahead and stage your engines to activate them and be careful not to hit the throttle until you mean it.

36 minutes ago, RageMode said:

I haven't actually tried your mod with RO, but I'm guessing it isn't able to calculate the burn time for the next stage. Perhaps a simple way to handle this would be to calculate the burn time based on the next stage if the current stage has no active engines or has no fuel.

Except that it doesn't handle staging, and never will.  Handling staging = impossibly complicated code.  Handling fuel flow = more impossibly complicated code.  When I say "impossibly", I don't mean literally impossibly-- it could be done, to a certain extent, given a large enough time investment.  It's just that it would require many, many hours of coding work, and multiplying the complexity of the mod (i.e. total lines of code) by a large factor, and essentially what I'd be doing would be trying to re-implement KER on my own.  Which is never, ever going to happen.  If someone wants to use KER, they should just use KER!

This is something I do in my spare time for fun-- I've got a day job, it's not like I get paid for modding.    Adding staging and fuel flow to BBT would be a matter of taking weeks of 8-hour days, to accomplish something that I myself never need or use (I don't use RO), for the benefit of people who happen to use one particular mod.  It's simply a time tradeoff that's never going to happen.

36 minutes ago, RageMode said:

Another simple way to solve this would be to implement some sort of stage selector for the burn time, so that you can choose which stage the burn time calculations would be performed for. Being able to select the stage by number is the best way I can think of to do this, because it provides a fairly clear way to figure out what engines the burn time is being calculated for.

Also, a huge amount of work.  Conceptually a simple idea, yes, but a lot harder than you'd think.  Not going to happen.  (Just to put things in perspective:  simply getting BBT to handle the current really simple model that completely ignores staging was weeks of work for me.  This is one of those areas that's far more difficult to program than a typical user would think.  It's the Lego-like freedom of KSP that makes the problem so difficult.)

Aside from the fact that I simply don't wanna. There's no way to implement what you just suggested, without adding UI.  I'm violently allergic to UI (it's a design philosophy of mine, which is a fancy way of saying "pet peeve").  Call it a personal quirk.  I like mods that accomplish what they do with no UI.  I'd rather have a simple mod that does one thing I want it to do, and does it well, without any UI at all, than something fancier and UI-ridden.  It's simply not my cup of tea.  I enjoy the design challenge of "how can I make <thing> better without requiring any additional UI?"

The closest thing I've come to a UI, in any of my mods, is that little row of "countdown" dots that I've added as the burn timer in BBT.  That's about the furthest extreme I'm willing to go.

36 minutes ago, RageMode said:

I understand that calculating burn times divided between multiple stages would be rather difficult, but these two options should be fairly simple and shouldn't add excessive performance penalties.

Performance isn't an issue.  Code complexity is.  There are a lot more edge cases than you'd think, and writing to try to handle all of that is just a great big fat hairy deal, trust me on this one.  There's a reason why everyone just uses MechJeb and/or KER, rather than having a hundred engineering mods out there.  It's a really hard problem.

 

[RageMode]

22 minutes ago, Snark said:

This is one of those areas that's far more difficult to program than a typical user would think.

 

I'm not a typical user. While I haven't worked on any KSP mods, and have never actually looked at any KSP mod code, I'm a C# programmer myself with a fair amount of programming expertise. I understand your reasons for not wanting to implement it though. It seems like a simple concept, but I don't understand enough about KSP modding to know everything it would require.

Perhaps I'll take a look at the github repo at some point and see if I'm able to find a fairly simple way to implement it. I have a significant amount of free time available, and I'm pretty sure stock KSP burn times don't cooperate very well with staging either.

Edited August 1, 2016 by RageMode

[Snark]

Just now, RageMode said:

I'm not a typical user. While I haven't worked on any KSP mods, and have never actually looked at any KSP mod code, I'm a C# programmer myself with a fair amount of programming expertise. I understand your reasons for not wanting to implement it though. It seems like a simple concept, but I don't understand enough about KSP modding to know everything it would require.

Fair 'nuff, helps to calibrate the response.     However, I'll say that the problem's a lot harder than a typical user would think, even if you're including "experienced software developers" in the category of "typical users."

Read back up the thread (in the first page or two) for a discussion of just how hard this problem turns out to be.  This is a classic case of "problem is a lot harder than it looks."  I set out to write BBT because it seemed to me that it ought to be trivially simple to write a burn-time calculator that would be far more accurate than the stock one.  And I thought (naively, as it turned out) that just because I'm a professional software engineer with 20 years of industry experience, not to mention a physics degree and a minor in math, that I was in a good position to judge how difficult it would be.

Turns out I drastically overestimated my competence to judge. 

It turned out to be an order of magnitude more complex than I expected, even for the very simple case of completely ignoring staging and fuel flow.  The list of complications is long (again, read back up the thread)... but basically it boils down to the edge cases being killers.  The beauty of KSP, from the player's perspective, is the practically infinite freedom it gives you to design your ships any which way.  That same freedom which makes it so delightful to play, makes it utter hell when you're trying to write code that attempts to analyze the future behavior of the whole ship.  There's practically nothing but edge cases-- and it's not just a question of handling the edge cases, it's being able to even detect that you're in a particular edge case.

[RageMode]

2 minutes ago, Snark said:

Fair 'nuff, helps to calibrate the response.     However, I'll say that the problem's a lot harder than a typical user would think, even if you're including "experienced software developers" in the category of "typical users."

Read back up the thread (in the first page or two) for a discussion of just how hard this problem turns out to be.  This is a classic case of "problem is a lot harder than it looks."  I set out to write BBT because it seemed to me that it ought to be trivially simple to write a burn-time calculator that would be far more accurate than the stock one.  And I thought (naively, as it turned out) that just because I'm a professional software engineer with 20 years of industry experience, not to mention a physics degree and a minor in math, that I was in a good position to judge how difficult it would be.

Turns out I drastically overestimated my competence to judge. 

It turned out to be an order of magnitude more complex than I expected, even for the very simple case of completely ignoring staging and fuel flow.  The list of complications is long (again, read back up the thread)... but basically it boils down to the edge cases being killers.  The beauty of KSP, from the player's perspective, is the practically infinite freedom it gives you to design your ships any which way.  That same freedom which makes it so delightful to play, makes it utter hell when you're trying to write code that attempts to analyze the future behavior of the whole ship.  There's practically nothing but edge cases-- and it's not just a question of handling the edge cases, it's being able to even detect that you're in a particular edge case.

I can understand. I would imagine if KSP doesn't have any sort of API to work with stages that's beneficial, and I doubt it does, then it would probably be a difficult thing to do. But I know the delta-v is already available information. And at the very least, MechJeb and KER are open source and capable of calculating delta-v per-stage. So the needed source is already available. Combining these two would make it a much more manageable task. Perhaps it would even be possible to use information already provided by MechJeb or KER if they're installed.

 

Unit testing can go a long way to help with edge cases as well. You'll spend a lot of time writing tests for the edge cases, but in the long run it will make the code much more maintainable and much more reliable. And from my brief research, unit testing seems like it's possible with KSP mods.

[Snark]

26 minutes ago, RageMode said:

I can understand. I would imagine if KSP doesn't have any sort of API to work with stages that's beneficial, and I doubt it does, then it would probably be a difficult thing to do.

No, it has an API for just about everything.  I haven't actually written code to work with stages, but I would guess that it's pretty straightforward to get a list of "here are the stages, and which piece is tied to which ones."  That's not the issue here.

26 minutes ago, RageMode said:

But I know the delta-v is already available information.

No, it isn't.  It's something that MechJeb and KER do, not something that the stock game provides.

26 minutes ago, RageMode said:

And at the very least, MechJeb and KER are open source and capable of calculating delta-v per-stage.

Yep.  And they each have no fewer than three total showstopper issues, any one of which would mean I will never, ever copy them to achieve the same thing:

1. They're an order of magnitude more complex than BetterBurnTime.  MechJeb and KER are colossal.  I'm not about to try to re-implement either one of them.
2. They need UI to address the problem, which I Do Not Want.  It's a different kind of mod, and not one that I want.  I will never turn BBT into a UI-intensive mod.  It's one of the big reasons why I have never run MechJeb or KER myself, and never will.  (Not that there's anything wrong with them, they're simply not my cup of tea.)
3. They're not guaranteed.  They sometimes generate results (typically on some edge case) that are laughably wrong.  This comes down to a matter of philosophy:  if you have something that gives an improved experience most of the time, but occasionally gives a laughably-wrong, worse-than-stock experience, is that an improvement?  There's no right answer there, it's a matter of taste.  But it's not my taste.  I want to maintain an ironclad guarantee that my mod puts out accurate information; if there's an uncertain case, I'd rather provide no information than provide potentially misleading information.  (It's why my time-to-impact display deliberately doesn't show a burn countdown indicator.)

 

26 minutes ago, RageMode said:

Combining these two would make it a much more manageable task.

No, it would be the exact opposite.  It would make it a much more complicated and difficult task.  Trying to merge code bases that were never designed as a single component is hard work.  So is trying to extract bits of code that work in certain ways with one mod, and making them work in the context of another mod.

That's not to say they're worthless.  Both of these could be fertile sources of "here's how you do it," i.e. look at what APIs they use, what algorithms, etc.  In fact, I did that very thing during BBT development-- I was trying to figure out how to implement the time-to-intercept tracker, and sarbian kindly pointed me at some code in MechJeb that calculates this, and I cheerfully copied the algorithm.  But not the code. It's not a case of lift-and-shift, just copy-all-this-over-here-and-problem-solved.  It would be a big, hard job.  And at the end of it, I'd have a mod that is 10 times more complex than BetterBurnTime is now.  Not to mention the maintenance hassle of trying to stay up-to-date with bug fixes and versions and such.

26 minutes ago, RageMode said:

Perhaps it would even be possible to use information already provided by MechJeb or KER if they're installed.

Not without taking a run-time dependency on them, which I won't do.  My mods are standalone and work without requiring to install a bunch of other mods; ModuleManager is about the most dependency I'm willing to take, and even that is a config dependency rather than a run-time code dependency.  I hate cross-mod dependencies, it's why I don't put dependencies in my own mods, and generally don't install other mods if they require suites of dependencies in order to work.

Trying to extract programmatically usable numbers from one mod to another, if one of them doesn't have an explicit dependency on the other (i.e. a .NET assembly reference, which would make it incapable of loading if the other mod isn't present), is a difficult, cumbersome, complicated problem.  It requires lots of edge-case error handling, it requires using reflection (which isn't super performant), and it adds all sorts of maintenance headaches, given that you're taking a run-time dependency on some other 3rd party code that may update at any time in a way that can break you.  It's not a place I want to go.

26 minutes ago, RageMode said:

Unit testing can go a long way to help with edge cases as well.

Not if the list of edge cases isn't well defined.  Nor do I know of any well-defined system for unit testing something that has to be run inside a computer game that doesn't have an automation framework that I know of.

Unit testing is mainly useful for preventing code regression, which isn't actually a problem I've had difficulty with in BBT.  My problem is just trying to write code to handle all the infinite possible permutations about how things can work, without adding any UI (because I refuse to), without adding the chance of getting it laughably wrong in cases that I don't handle (because I refuse to), and without taking weeks and weeks of my time to add a feature that I myself don't need, don't want, and will never use, in order to benefit people who happen to run a particular mod that, while popular, is not one that I will ever use nor is in use by the majority of the KSP population.

I'm not saying it can't be done, simply that it won't be, by me.  Ever. 

[RageMode]

14 minutes ago, Snark said:

No, it has an API for just about everything.  I haven't actually written code to work with stages, but I would guess that it's pretty straightforward to get a list of "here are the stages, and which piece is tied to which ones."  That's not the issue here.

No, it isn't.  It's something that MechJeb and KER do, not something that the stock game provides.

Yep.  And they each have no fewer than three total showstopper issues, any one of which would mean I will never, ever copy them to achieve the same thing:

1. They're an order of magnitude more complex than BetterBurnTime.  MechJeb and KER are colossal.  I'm not about to try to re-implement either one of them.
2. They need UI to address the problem, which I Do Not Want.  It's a different kind of mod, and not one that I want.  I will never turn BBT into a UI-intensive mod.  It's one of the big reasons why I have never run MechJeb or KER myself, and never will.  (Not that there's anything wrong with them, they're simply not my cup of tea.)
3. They're not guaranteed.  They sometimes generate results (typically on some edge case) that are laughably wrong.  This comes down to a matter of philosophy:  if you have something that gives an improved experience most of the time, but occasionally gives a laughably-wrong, worse-than-stock experience, is that an improvement?  There's no right answer there, it's a matter of taste.  But it's not my taste.  I want to maintain an ironclad guarantee that my mod puts out accurate information; if there's an uncertain case, I'd rather provide no information than provide potentially misleading information.  (It's why my time-to-impact display deliberately doesn't show a burn countdown indicator.)

 

No, it would be the exact opposite.  It would make it a much more complicated and difficult task.  Trying to merge code bases that were never designed as a single component is hard work.  So is trying to extract bits of code that work in certain ways with one mod, and making them work in the context of another mod.

That's not to say they're worthless.  Both of these could be fertile sources of "here's how you do it," i.e. look at what APIs they use, what algorithms, etc.  In fact, I did that very thing during BBT development-- I was trying to figure out how to implement the time-to-intercept tracker, and sarbian kindly pointed me at some code in MechJeb that calculates this, and I cheerfully copied the algorithm.  But not the code. It's not a case of lift-and-shift, just copy-all-this-over-here-and-problem-solved.  It would be a big, hard job.  And at the end of it, I'd have a mod that is 10 times more complex than BetterBurnTime is now.  Not to mention the maintenance hassle of trying to stay up-to-date with bug fixes and versions and such.

Not without taking a run-time dependency on them, which I won't do.  My mods are standalone and work without requiring to install a bunch of other mods; ModuleManager is about the most dependency I'm willing to take, and even that is a config dependency rather than a run-time code dependency.  I hate cross-mod dependencies, it's why I don't put dependencies in my own mods, and generally don't install other mods if they require suites of dependencies in order to work.

Trying to extract programmatically usable numbers from one mod to another, if one of them doesn't have an explicit dependency on the other (i.e. a .NET assembly reference, which would make it incapable of loading if the other mod isn't present), is a difficult, cumbersome, complicated problem.  It requires lots of edge-case error handling, it requires using reflection (which isn't super performant), and it adds all sorts of maintenance headaches, given that you're taking a run-time dependency on some other 3rd party code that may update at any time in a way that can break you.  It's not a place I want to go.

Not if the list of edge cases isn't well defined.  Nor do I know of any well-defined system for unit testing something that has to be run inside a computer game that doesn't have an automation framework that I know of.

Unit testing is mainly useful for preventing code regression, which isn't actually a problem I've had difficulty with in BBT.  My problem is just trying to write code to handle all the infinite possible permutations about how things can work, without adding any UI (because I refuse to), without adding the chance of getting it laughably wrong in cases that I don't handle (because I refuse to), and without taking weeks and weeks of my time to add a feature that I myself don't need, don't want, and will never use, in order to benefit people who happen to run a particular mod that, while popular, is not one that I will ever use nor is in use by the majority of the KSP population.

I'm not saying it can't be done, simply that it won't be, by me.  Ever. 

You're assuming what I'm saying is that you should implement these features. That's not what I'm saying. I'm not saying you should necessarily do anything. I'm just throwing some ideas around. If I want it that bad, the source is available and I know how to use the fork feature.

[Snark]

34 minutes ago, RageMode said:

You're assuming what I'm saying is that you should implement these features. That's not what I'm saying. I'm not saying you should necessarily do anything. I'm just throwing some ideas around. If I want it that bad, the source is available and I know how to use the fork feature.

Ah, okay, makes sense then. 

Unless explicitly specified otherwise, I tend to interpret anything posted about <potential feature> in this thread as "please implement <feature> in BetterBurnTime, Snark."

(Which is fine-- I've gotten a lot of such requests in this thread, many of which were better ideas than I had had, and which I subsequently implemented.  In case it's not obvious, I love having a vocal community of users who have constructive suggestions for new features!)

[brusura]

Hi @Snark

I have this NRE

Spoiler

[Error]: [BetterBurnTime] (NullReferenceException) Object reference not set to an instance of an object:   at BetterBurnTime.ImpactTracker.CalculateVesselHeight (.Vessel vessel, .Part& lowestPart) [0x00000] in <filename unknown>:0 
  at BetterBurnTime.ImpactTracker.GetVesselHeight (.Part& currentLowestPart) [0x00000] in <filename unknown>:0 
  at BetterBurnTime.ImpactTracker.CalculateTimeToImpact (.Vessel vessel, System.String& verb, System.Double& impactSpeed) [0x00000] in <filename unknown>:0 
  at BetterBurnTime.ImpactTracker.Recalculate () [0x00000] in <filename unknown>:0 
  at BetterBurnTime.ImpactTracker.LateUpdate () [0x00000] in <filename unknown>:0

I have two kerbals in seats rovering the mun, it happen when touching the ground after a jump off a cliff , here is the log: https://drive.google.com/file/d/0B4kd548FeSEpTnRSSWtLVHVsNzA/view?usp=sharing

Nothing affecting gameplay just spamming the log

[Snark]

15 hours ago, brusura said:

I have this NRE

I have two kerbals in seats rovering the mun, it happen when touching the ground after a jump off a cliff , here is the log: https://drive.google.com/file/d/0B4kd548FeSEpTnRSSWtLVHVsNzA/view?usp=sharing

Nothing affecting gameplay just spamming the log

Thanks for calling it out!

A couple of follow-up requests, if you don't mind:

• Do you have a screenshot of your rover?  (So I can try to build one and reproduce the problem.)
• Does it make a difference whether the rover has kerbals in the seats or not?

 

[brusura]

6 hours ago, Snark said:

Thanks for calling it out!

A couple of follow-up requests, if you don't mind:

• Do you have a screenshot of your rover?  (So I can try to build one and reproduce the problem.)
• Does it make a difference whether the rover has kerbals in the seats or not?

 

This is the craft, it's stock : https://drive.google.com/file/d/0B4kd548FeSEpS0VUeHNidV8xNzQ/view?usp=sharing

And here is a video, it happens only with kerbals onboard: https://youtu.be/a-5uIJQ3iy0

[Waxing_Kibbous]

Anyone using this in 1.2? I have a feeling the new fuel flow paradigm could break this mod

[Snark]

21 hours ago, Waxing_Kibbous said:

Anyone using this in 1.2? I have a feeling the new fuel flow paradigm could break this mod

The current version (1.4.4) doesn't work in 1.2, but the reason has nothing to do with fuel flow. 

It's because the entire UI of this mod involves tinkering with text objects, and KSP 1.2 completely rejiggered text objects and replaced them with a new kind of object.  (And may I go on record as saying that's a great change.  The new text in KSP 1.2 is frickin' gorgeous.)

This means that BetterBurnTime won't work until it's updated to use the new text objects instead of the old ones.  It's a simple fix, and I already have it in hand, and it works great.    I'll be releasing it as soon as KSP 1.2 is out of pre-release.

The new fuel flow paradigm, incidentally, doesn't affect BetterBurnTime at all, simply because it makes no attempt whatsoever to trace fuel flow and never has; it's dumb, that way.  So it doesn't have to worry about changes to the fuel flow model.

[Vingo]

Maybe you should pre release the 1.2 version *wink wink nudge nudge*