Sigma88

[1.3.1][Plugin] Kronometer v1.3.1-1

Recommended Posts

Kronometer

A mod to manipulate the clock for Kerbal Space Program. It was previously a part of Kopernicus (called ClockFixer), but it was moved into its own mod.

Kronometer.svg KSP-1.3.1-orange.svg total.svg

 

Copyright

  • Thomas P.
  • Sigma88

This mod is licensed under the Terms of the MIT License. It was previously licensed under the LGPL License.

 

Downloads

 

Credits

Sigma88 wrote most of the original code, Thomas P. made various improvements. The name is an idea of the IRC user "acc"

This uses the Kopernicus parsing and attribution library written by Nathaniel R. Lewis (Teknoman117), which is LGPL

 

If you want to buy us a cup of coffee you can do it here:

@Thomas P. iSFDI5f.png

@Sigma88 iSFDI5f.png r8916yD.png

 

 

Syntax

Kronometer Syntax at Github
Edited by Sigma88

Share this post


Link to post
Share on other sites
9 minutes ago, PocketBrotector said:

Any description of what the mod actually does?

18 minutes ago, Sigma88 said:

Kronometer

A mod to manipulate the clock for Kerbal Space Program.

18 minutes ago, Sigma88 said:

 

you can basically change everything about how time is displayed on the various KSP clocks

it's mostly be intended to be used as a dependency for other mods, not really made to be used directly by players

Edited by Sigma88

Share this post


Link to post
Share on other sites
2 hours ago, Nightside said:

Is this mod the best way to have my RSS game start in the year 2017 (or whenever)?

RSS has it's own time formatter, so I would assume that's "the best way"

https://github.com/KSP-RO/RSSTimeFormatter

 

But I have nevet used it

 

Also, to make it start in 2017 you will need to change the "Epoch" at which planets load

You'll have to ask the RSS people by how much because I am not sure

 

Edited by Sigma88

Share this post


Link to post
Share on other sites

@Sigma88, it looks like there's a mistake on your syntax page.  The instructions on useLeapYears says the same thing for both true and false...

useLeapYears

Boolean, default value = false

  • When 'false':

    if the year ends halfway through a day, the clock will go:

    Year 1 Day 365 ==> Year 2 Day 0 (Instead of starting directly with Day 1)

    Day 0 will last untill Day 365 would have ended, then Day 1 will start.

  • When 'true':

    if the year ends halfway through a day, the clock will go:

    Year 1 Day 365 ==> Year 2 Day 0 (Instead of starting directly with Day 1)

    Day 0 will last untill Day 365 would have ended, then Day 1 will start.

  • In both cases: a new day will not start earlier just because a year has ended.
     

Edited by OhioBob

Share this post


Link to post
Share on other sites

yup, my bad

it's fixed now

Quote
  • When 'true':

at the end of a day, if there is not enough time left in the year to fit another full day,

the current year will end as well, and the new day will be the first day of the next year

 

Edited by Sigma88

Share this post


Link to post
Share on other sites

@Sigma88, I just tried Kronometer out on GPP and it works great, but there is just one thing I'm not so sure about.  We already had GPP set up to work using ClockFixer in Kopernicus.  To avoid the whole leap year problem, we tweaked Gael's semimajor axis to make sure the year ended on an exact integer number of solar days.  So to configure Kronometer I just made the following MM patch:

@Kronometer
{
 @useHomeDay = true
 @useHomeYear = true
}

which should make it work just as it did before using ClockFixer.

The problem is that I'm not sure the year is ending on the right day.  For the particular rescale I was using (2.5X), we have a 10-hour solar day with exactly 404 solar days in a year (405 sidereal days).  The calendar turned over from Y1, D403, 9:59, to Y2, D1, 0:00.  Shouldn't there have been a day 404 before the calendar flipped over to the next year?  I think the calendar is only giving me a 403-day year.  Had we started with day 0, then you're right, but since we start with day 1, I think there needs to be a day 404.

Maybe you're right and I'm wrong, but I need some convincing.

Share this post


Link to post
Share on other sites
23 minutes ago, OhioBob said:

@Sigma88, I just tried Kronometer out on GPP and it works great, but there is just one thing I'm not so sure about.  We already had GPP set up to work using ClockFixer in Kopernicus.  To avoid the whole leap year problem, we tweaked Gael's semimajor axis to make sure the year ended on an exact integer number of solar days.  So to configure Kronometer I just made the following MM patch:

@Kronometer
{
 @useHomeDay = true
 @useHomeYear = true
}

which should make it work just as it did before using ClockFixer.

The problem is that I'm not sure the year is ending on the right day.  For the particular rescale I was using (2.5X), we have a 10-hour solar day with exactly 404 solar days in a year (405 sidereal days).  The calendar turned over from Y1, D403, 9:59, to Y2, D1, 0:00.  Shouldn't there have been a day 404 before the calendar flipped over to the next year?  I think the calendar is only giving me a 403-day year.  Had we started with day 0, then you're right, but since we start with day 1, I think there needs to be a day 404.

Maybe you're right and I'm wrong, but I need some convincing.

erm, squad changed the values of G and g like a year ago from 6.674e-11, 9.81 to 6.67408e-11, 9.80665

Somehow I never noticed that SD was still using the old values so that might be your issue

you should try with the latest SD that has those values fixed >_>

Share this post


Link to post
Share on other sites
Just now, Sigma88 said:

erm, squad changed the values of G and g like a year ago from 6.674e-11, 9.81 to 6.67408e-11, 9.80665

Somehow I never noticed that SD was still using the old values so that might be your issue

you should try with the latest SD that has those values fixed >_>

I'm pretty sure I did use the latest SD.  I had fresh install of KSP 1.3.0 with no mods other than GPP and Kopernicus 1.3.0-1.    I then downloaded and installed SD 0.8.0.

Share this post


Link to post
Share on other sites
8 minutes ago, OhioBob said:

I'm pretty sure I did use the latest SD.  I had fresh install of KSP 1.3.0 with no mods other than GPP and Kopernicus 1.3.0-1.    I then downloaded and installed SD 0.8.0.

Could you upload the mm cache file and the cfgs for ciro and gael?

Share this post


Link to post
Share on other sites
Just now, Sigma88 said:

Could you upload the mm cache file and the cfgs for ciro and gael?

Yes, I can do that.  I'll do it via PM because the latest cfgs are a dev version.

OK, this is weird.  I just time warped through a second year and this time I got a day 404, but when it flipped over to the next year it was on Day 2.  It went from Y2, D404, 9:59 to Y3, D2, 0:00.

Share this post


Link to post
Share on other sites

Ugh

Yeah I need to know which values ksp is getting

You don't need to share much, just radius, geeasl, gravparameter and mass of ciro (whatever of those you have)

 

And sma of gael

Share this post


Link to post
Share on other sites
12 minutes ago, Sigma88 said:

And sma of gael

I just sent you files, but disregard Gael's SMA in its cfg.  For the 2.5X version we're using, semiMajorAxis = 34948895994.9601.

Share this post


Link to post
Share on other sites
17 minutes ago, OhioBob said:

I just sent you files, but disregard Gael's SMA in its cfg.  For the 2.5X version we're using, semiMajorAxis = 34948895994.9601.

it looks like a rounding error to me, sadly there's very little I can do to prevent that, you will need to check the numbers with kittopia, see what gets rounded badly, and manually fix the cfg untill you get the correct approximation

right now for example, rotation period of gael is 36000.0000000001

you can fix that with a mm patch that loads after SD, sadly that's a limitation that I am not sure I will be able to fix, I might try some shenanigans later to see if I can get it to work better by forcing an approximation of the approximation

Share this post


Link to post
Share on other sites
8 minutes ago, Sigma88 said:

it looks like a rounding error to me ...

I thought that might be the case.  If I can find a way to fix it via cfgs, I will.  Otherwise we'll just have to live with it.

By the way, I never noticed this problem with ClockFixer in Kopernicus.  Is there anything you did differently then that could be implemented now?

 

Edited by OhioBob

Share this post


Link to post
Share on other sites
18 minutes ago, OhioBob said:

I thought that might be the case.  If I can find a way to fix it via cfgs, I will.  Otherwise we'll just have to live with it.

By the way, I never noticed this problem with ClockFixer in Kopernicus.  Is there anything you did differently then that could be implemented now?

 

the code is the same, it might just be that the rounding errors with the wrong values SD was using were falling in your favor

Share this post


Link to post
Share on other sites

@Sigma88, I've got something new to report.  I just created a new game to start over from the beginning.  Year 1 actually starts on Day 0 (I mistakenly believed it started on Day 1).  So that means year 1 runs from day 0 to day 403.  Year 2 then runs from day 1 to day 404.  Year 3 runs from day 2 to day 405.  And year 4 starts on day 3, which is where I stopped.  So the problem isn't that I have the wrong number of days in the year - they all have 404 days.  The problem is that the start day of each subsequent year is advancing 1 day.

Does that still sound like rounding, or could there be something else causing this?
 

Edited by OhioBob

Share this post


Link to post
Share on other sites
24 minutes ago, OhioBob said:

@Sigma88, I've got something new to report.  I just created a new game to start over from the beginning.  Year 1 actually starts on Day 0 (I mistakenly believed it started on Day 1).  So that means year 1 runs from day 0 to day 403.  Year 2 then runs from day 1 to day 404.  Year 3 runs from day 2 to day 405.  And year 4 starts on day 3, which is where I stopped.  So the problem isn't that I have the wrong number of days in the year - they all have 404 days.  The problem is that the start day of each subsequent year is advancing 1 day.

Does that still sound like rounding, or could there be something else causing this?

I don't know, I will need to test this further

with your cfg you should get every year starting with day 1

 

Share this post


Link to post
Share on other sites
1 minute ago, Sigma88 said:

I don't know, I will need to test this further

with your cfg you should get every year starting with day 1

Is there any code you could add that would ensure each new year always start with Day 1?

Share this post


Link to post
Share on other sites
4 minutes ago, OhioBob said:

Is there any code you could add that would ensure each new year always start with Day 1?

both leap year and stock do that

the difference being that, since your last day is 0.000000001%  too long, it would be cut by leapyear, going to next year with that much remainder

the stock clock would be the best option for you since it will just ignore the carry over and restart from year 2 day 1

the problem being that after a certain number of years you get the carry over summed and it could offset the time of day with the position of the sun in the sky

of course being that the carryover for you is so small, you might get awat with that

 

I'll add an option to maintain the stock math for now, while I find a solution to to the rounding errors

Share this post


Link to post
Share on other sites
Another issue I had when using ClockFixer (haven't tested it with Kronometer yet) is that some other mods are not compatible with it.  These other mods are apparently not detecting that the length of day has changed.  For example, Kerbal Alarm Clock.  KAC alarms go off at the correct time - probably because the internal calculations are based on seconds - but the display is incorrect.  For instance, if an alarm is set for 30 hours, the display shows five 6-hour days instead of three 10-hour days.  I've seen similar problems with other mods, but I can't recount all of them.
 
I understand this isn't a Kronometer problem per se.  But is there any recommendation you can make that would help remedy these compatibility problems?

Share this post


Link to post
Share on other sites
4 minutes ago, OhioBob said:
Another issue I had when using ClockFixer (haven't tested it with Kronometer yet) is that some other mods are not compatible with it.  These other mods are apparently not detecting that the length of day has changed.  For example, Kerbal Alarm Clock.  KAC alarms go off at the correct time - probably because the internal calculations are based on seconds - but the display is incorrect.  For instance, if an alarm is set for 30 hours, the display shows five 6-hour days instead of three 10-hour days.  I've seen similar problems with other mods, but I can't recount all of them.
 
I understand this isn't a Kronometer problem per se.  But is there any recommendation you can make that would help remedy these compatibility problems?

there are 2 options, there are some hardcoded variables used by KSP to define year and day

if the mod in question uses those, it might not have worked with ClockFixer since we didn't change those numbers, we fixed that in kronometer and now mods that read those variables work correctly with Kronometer (like KAC)

 

if the mod in question uses its own hardcoded numbers (eg. it just assumes a day is 6hrs) there's nothing we can do about it, they'll need to change to use the stock values if they want to be compatible with Kronometer

Share this post


Link to post
Share on other sites
1 minute ago, Sigma88 said:

there are 2 options, there are some hardcoded variables used by KSP to define year and day

if the mod in question uses those, it might not have worked with ClockFixer since we didn't change those numbers, we fixed that in kronometer and now mods that read those variables work correctly with Kronometer (like KAC)

if the mod in question uses its own hardcoded numbers (eg. it just assumes a day is 6hrs) there's nothing we can do about it, they'll need to change to use the stock values if they want to be compatible with Kronometer

I'm glad you implemented a solution that will fix some of the problems.  If I notice any mods that are still broken, I'll post in their thread requesting they make the necessary change.

How about Transfer Window Planner?  Do you know if that one works with Kronometer?  KAC and TWP are two of the mods I most rely on, so if those both work, I'll be pretty happy.

Share this post


Link to post
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.