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

[Snark]

2 hours ago, ThePatsch78 said:

So may I ask you to recompile BBT containing that fix against 1.7.3?

Alas, no. It's a totally reasonable request, and you're totally justified in asking, it's just that I have a very low tolerance for administrivia. Doing backward compatibility patches is something I've never done because, straightforward as it is, it would push me past my "hassle limit" of keeping track of things.

Thank you very much for your courteous approach, by the way; I really appreciate it, and I'm sorry I can't oblige. It's worth noting that BBT's license, unlike Kopernicus, actually deliberately prohibits people from publishing forks, for the reasons you mention (I used to use a more permissive license but got burned).

Even though publishing a fork is off the table, though, you can totally build a patch for yourself if it's not published. I believe (though have not tested) that you should be able to just take the most recent code for current KSP, and then swap out the .csproj file and MM version from an older BBT that's compatible with your current KSP version. I think that'll work.

[ThePatsch78]

Thank you for your reply and your hint. I absolutely understand your point - no worries

PatSch

 

[ForgiLaGeord]

No big surprise, but this works perfectly fine in 1.9.

[NikoKun]

nvm

Edited February 26, 2020 by NikoKun
delete figured it out myself

[VelRahnKoon]

Snark, I have a question. I am using Kerbal Engineer and BBT (version 1.9.1 of the game), and I noticed a discrepancy between the two mods' readouts when I put a satellite into geostationary orbit. Here's a screen capture:

BBT shows that I'm dead-on for a geostationary orbit (down to the ms mark), but the orbital period is 5:59:9.246, almost a full minute off from the 6:00:00 it should be as given by KER. Is there a problem in one of the mods, or am I not understanding how geostationary orbit works? Originally I used KER to set my orbital period to 6:00:00, not realizing that BBT would give a time to geosynchronous orbit. When I set the orbital period to 6:00:00, BBT reported gsync as +50 s. I thought that the orbital period would be a good indicator of geosynchronicity, but now I don't know.

Any thoughts? Thanks in advance.

 

VRK

[bcqJC]

KEO is based on sidereal day - 5h 59m 9.425s ( https://wiki.kerbalspaceprogram.com/wiki/KEO )

[VelRahnKoon]

Brilliant, thanks bcqJC!

So a follow-up question then: can you use the period shown in KER to set the relationship between communication satellites? I have 3 commsats in a triangular formation about 750k above Kerbin's surface. I used the period in KER to set their periods relative to one another (to minimize drift). Will that work, or am I going to have trouble with them drifting because KER bases the period on the sidereal day and not the solar day?

I think the answer is no, there won't be a problem, since all three satellites are based off the sidereal relationship to each other, but that's more of a gut feeling.

 

VRK

[Snark]

20 minutes ago, VelRahnKoon said:

So a follow-up question then: can you use the period shown in KER to set the relationship between communication satellites?

A gentle reminder that if you have KER questions, perhaps that would be better addressed in the KER thread.

That said: if you want a satellite to stay over the same spot on the planet, it needs to be synchronized to the planet's sidereal (not solar) rotation period. BBT can do that for you, as is shown above.

If you want a group of satellites to stay in the same position relative to each other (which is often the case for comsat networks), then you have more choices. You could synchronize them to the planet. Or, if you don't need that, you can synchronize them to each other. BBT supports that, too. If you have an orbiting ship, just set another ship as your target. If you do that, then the BBT synchronicity indicator will use the target vessel's orbital period instead of the planet's rotation.

[VelRahnKoon]

12 hours ago, Snark said:

A gentle reminder that if you have KER questions, perhaps that would be better addressed in the KER thread.

Fair point. I wasn't specifically asking about KER, but about using the sidereal period to set comm sats. I should have been more careful in my wording.

Thank you for the rest of the explanation!

[Musa Bağrıyanık]

Why this mod is not exist on CKAN? Is it related to you or CKAN?

EDIT: I am sorry, this add-on exist on CKAN but CKAN can not find it for 1.9, people needs to filter as all for find this modification on CKAN. I will report it to CKAN.

Edited June 16, 2020 by Musa Bağrıyanık

[Musa Bağrıyanık]

@Snark you should change game version on SpaceDock, because CKAN can not detect it as 1.9.x.

[linuxgurugamer]

1 hour ago, Musa Bağrıyanık said:

@Snark you should change game version on SpaceDock, because CKAN can not detect it as 1.9.x.

No, you should tell CKAN that 1.8 mods are compatible.

Modders have a life.  There are hundreds of mods which are 1.8 compatible which haven't been updated on Spacedock.  I know this because about 200 of them are mine.  The solution is very simple, and spares the modders from unnecessary work:

• At the main CKAN screen, click Settings->Compatible KSP Versions
• In the main window, you will see all the versions of KSP listed.  Put a check mark next to 1.8 and 1.9, then click Accept

 

 

[Musa Bağrıyanık]

On 6/26/2020 at 7:53 PM, linuxgurugamer said:

No, you should tell CKAN that 1.8 mods are compatible.

Modders have a life.  There are hundreds of mods which are 1.8 compatible which haven't been updated on Spacedock.  I know this because about 200 of them are mine.  The solution is very simple, and spares the modders from unnecessary work:

• At the main CKAN screen, click Settings->Compatible KSP Versions
• In the main window, you will see all the versions of KSP listed.  Put a check mark next to 1.8 and 1.9, then click Accept

 

 

I said it already, they says we are collecting data from SpaceDock, If SpaceDock data is wrong, this will cause CKAN to be wrong.

I just suggested changing the version 1.9.0 to 1.9.x on SpaceDock, this mod is compatible with the 1.9.x version, but there is a minor problem in SpaceDock. All I say is that it does the same thing there. I didn't say anything about 1.8.x. I know, modders have a life, everyone have a life. It just a suggest.

Edited June 28, 2020 by Musa Bağrıyanık

[linuxgurugamer]

5 hours ago, Musa Bağrıyanık said:

I said it already, they says we are collecting data from SpaceDock, If SpaceDock data is wrong, this will cause CKAN to be wrong.

I just suggested changing the version 1.9.0 to 1.9.x on SpaceDock, this mod is compatible with the 1.9.x version, but there is a minor problem in SpaceDock. All I say is that it does the same thing there. I didn't say anything about 1.8.x. I know, modders have a life, everyone have a life. It just a suggest.

No, it's not.  The mod was compiled for 1.8, however it is compatible with 1.9.  I don't have time to change 200 mods on Spacedock, @Snarkis busy with IRL right now as well;  when all you need to do is click the mouse 4 times:

1. At the main CKAN windows, click Settings->Compatible KSP Versions (2 clicks)
2. In the window, click the box to the left of 1.8 (1 click)
3. Click Accept (1 click)

CKAN added this capability for exactly this reason.

[Musa Bağrıyanık]

7 hours ago, linuxgurugamer said:

No, it's not.  The mod was compiled for 1.8, however it is compatible with 1.9.  I don't have time to change 200 mods on Spacedock, @Snarkis busy with IRL right now as well;  when all you need to do is click the mouse 4 times:

1. At the main CKAN windows, click Settings->Compatible KSP Versions (2 clicks)
2. In the window, click the box to the left of 1.8 (1 click)
3. Click Accept (1 click)

CKAN added this capability for exactly this reason.

I know mate, I did it already. Thanks anyway!

[MrZurkon]

Can confirm that this still works in 1.10

[dtoxic]

Works except the UI scaling Issue witch is still present sadly

[Snark]

On 7/2/2020 at 11:16 AM, dtoxic said:

Works except the UI scaling Issue witch is still present sadly

Yes, that particular issue has been there since forever, and will be there forever until and unless some kind soul debugs it and figures out how to fix it and hands me the solution on a silver platter.  I poked around on that for a while, way back when, and couldn't figure out how to fix it-- it gets into Unity UI ledgerdemain, which is an area I'm highly ignorant of.  I'm sure there's a solution, but  figuring it out would require more time and energy than I'm willing to invest.

So I won't be pursuing that fix, myself.  If someone else figures out the solution and lets me know, then I'm happy to fix it.

[dtoxic]

48 minutes ago, Snark said:

Yes, that particular issue has been there since forever, and will be there forever until and unless some kind soul debugs it and figures out how to fix it and hands me the solution on a silver platter.  I poked around on that for a while, way back when, and couldn't figure out how to fix it-- it gets into Unity UI ledgerdemain, which is an area I'm highly ignorant of.  I'm sure there's a solution, but  figuring it out would require more time and energy than I'm willing to invest.

So I won't be pursuing that fix, myself.  If someone else figures out the solution and lets me know, then I'm happy to fix it.

wish i could help,unfortunately my coding skills are on par with my Chinese speaking skills (non existent) hopefully someone more skilled will pick this up  

Edited July 3, 2020 by dtoxic

[flart]

I like the BBT indicator more, than the stock extended indicator (logarithmic dots). 
Since the stock extended indicator can be disabled in the options, could you make come back of the BBT in the case, when user disable the stock extended indicator?

Edited December 16, 2020 by flart

[Snark]

On 12/16/2020 at 1:14 PM, flart said:

I like the BBT indicator more, than the stock extended indicator (logarithmic dots). 

Yeah, me too.  I miss it. 

On 12/16/2020 at 1:14 PM, flart said:

Since the stock extended indicator can be disabled in the options, could you make come back of the BBT in the case, when user disable the stock extended indicator?

That's a neat idea.  I'd have to do some research, though, to figure out how practical this might be.  The issue is that even though the stock countdown might be turned off... the stock estimated burn time is still there.  And the countdown indicator has to be keyed off of that.  And the stock estimated burn time won't necessarily mesh with BBT's  estimate (since stock takes into account staging, and BBT doesn't).  So to prevent it from being out of whack, if I were to show the BBT countdown dots, I'd need to figure out how to get at the numeric data that stock has calculated for the burn duration, and I don't actually know that that's programmatically exposed anywhere that's accessible to modders.  Hopefully it might be, but I don't actually know that.  And even if it is, I'd then have to do a fair amount of rewiring in BBT to feed that number (rather than BBT's own calculations) into the countdown display.

So, I'm not saying "no", and I do like the idea-- it's just that it would take some research and a fair amount of coding to do, so it's non-trivial.  Therefore, I'm not sure when I might have  a chance to get around to it.  (What would make it more likely to be sooner rather than later would be if some kind soul did the footwork for me and could tell me exactly what code's needed to, 1. get the status of the extended indicator being turned on or not, and 2. get the numeric data for the stock burn time estimate, and-- ideally but not strictly necessarily-- 3. the ability to get at the numbers for the extended burn indicator, even if it's not being displayed, i.e. what countdown value it would be giving based on the current selected dV percentage.  Hint, hint.) 

So, thank you for the suggestion and I'll definitely bear it in mind-- but I don't know when or if I might implement it.

[VoidSquid]

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

MH 1.8.2
IL 1.7
BBT 1.10
VP 1.1

Probably just an oversight with the respective CKAN meta data.

Edited December 30, 2020 by VoidSquid

[Snark]

9 minutes ago, VoidSquid said:

CKAN lists the latest couple of version of several of your mods only to be compatible with 1.11.0, but these versions aren't new at all.

¯\_(ツ)_/¯

I don't have anything to do with CKAN or its metadata-- all I do is, when a new version of KSP comes out, I tell SpaceDock (where I host my mods) that "this mod is compatible with <latest version>".  Since it's the same version of my mod that SpaceDock already knew was compatible with the previous KSP version, then you'd think that SpaceDock would have all the info it needs to be able to do the right thing when it does whatever-it-does to communicate to CKAN.  Apparently it's not doing that.

Since I'm not involved with CKAN at all and don't have the time or the inclination to tinker with it, it's all opaque to me.  This seems like an issue with SpaceDock's CKAN integration.

[VoidSquid]

I see, thanks.  

[Beetlecat]

42 minutes ago, VoidSquid said:

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

MH 1.8.2
IL 1.7
BBT 1.10
VP 1.1

Probably just an oversight with the respective CKAN meta data.

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

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