Sigma88 Posted May 28, 2017 Share Posted May 28, 2017 (edited) Kronometer support for the latest ksp patch is available here https://github.com/linuxgurugamer/Kronometer/releases/latest thanks to @linuxgurugamer and @R-T-B for updating it 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. Copyright Thomas P. Sigma88 This mod is licensed under the Terms of the MIT License. It was previously licensed under the LGPL License. Downloads Latest Release at Github 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 Syntax Kronometer Syntax at Github Edited August 26, 2021 by Sigma88 Quote Link to comment Share on other sites More sharing options...
drtedastro Posted May 28, 2017 Share Posted May 28, 2017 H'mm, sounds good. cheers, Quote Link to comment Share on other sites More sharing options...
PocketBrotector Posted May 28, 2017 Share Posted May 28, 2017 Any description of what the mod actually does? Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 28, 2017 Author Share Posted May 28, 2017 (edited) On 5/28/2017 at 5:14 PM, PocketBrotector said: Any description of what the mod actually does? Expand On 5/28/2017 at 5:05 PM, Sigma88 said: Kronometer A mod to manipulate the clock for Kerbal Space Program. Expand On 5/28/2017 at 5:05 PM, Sigma88 said: Syntax Kronometer Syntax at Github Expand 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 May 28, 2017 by Sigma88 Quote Link to comment Share on other sites More sharing options...
Nightside Posted May 29, 2017 Share Posted May 29, 2017 Is this mod the best way to have my RSS game start in the year 2017 (or whenever)? Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 29, 2017 Author Share Posted May 29, 2017 (edited) On 5/29/2017 at 2:44 AM, Nightside said: Is this mod the best way to have my RSS game start in the year 2017 (or whenever)? Expand 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 May 29, 2017 by Sigma88 Quote Link to comment Share on other sites More sharing options...
OhioBob Posted May 29, 2017 Share Posted May 29, 2017 (edited) @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 May 29, 2017 by OhioBob Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 29, 2017 Author Share Posted May 29, 2017 (edited) 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 Expand Edited May 29, 2017 by Sigma88 Quote Link to comment Share on other sites More sharing options...
OhioBob Posted May 29, 2017 Share Posted May 29, 2017 @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. Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 29, 2017 Author Share Posted May 29, 2017 On 5/29/2017 at 2:50 PM, 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. Expand 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 >_> Quote Link to comment Share on other sites More sharing options...
OhioBob Posted May 29, 2017 Share Posted May 29, 2017 On 5/29/2017 at 3:16 PM, 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 >_> Expand 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. Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 29, 2017 Author Share Posted May 29, 2017 On 5/29/2017 at 3:22 PM, 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. Expand Could you upload the mm cache file and the cfgs for ciro and gael? Quote Link to comment Share on other sites More sharing options...
OhioBob Posted May 29, 2017 Share Posted May 29, 2017 On 5/29/2017 at 3:31 PM, Sigma88 said: Could you upload the mm cache file and the cfgs for ciro and gael? Expand 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. Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 29, 2017 Author Share Posted May 29, 2017 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 Quote Link to comment Share on other sites More sharing options...
OhioBob Posted May 29, 2017 Share Posted May 29, 2017 On 5/29/2017 at 3:40 PM, Sigma88 said: And sma of gael Expand I just sent you files, but disregard Gael's SMA in its cfg. For the 2.5X version we're using, semiMajorAxis = 34948895994.9601. Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 29, 2017 Author Share Posted May 29, 2017 On 5/29/2017 at 3:54 PM, 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. Expand 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 Quote Link to comment Share on other sites More sharing options...
OhioBob Posted May 29, 2017 Share Posted May 29, 2017 (edited) On 5/29/2017 at 4:14 PM, Sigma88 said: it looks like a rounding error to me ... Expand 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 May 29, 2017 by OhioBob Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 29, 2017 Author Share Posted May 29, 2017 On 5/29/2017 at 4:19 PM, 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? Expand 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 Quote Link to comment Share on other sites More sharing options...
OhioBob Posted May 29, 2017 Share Posted May 29, 2017 (edited) @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 May 29, 2017 by OhioBob Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 29, 2017 Author Share Posted May 29, 2017 On 5/29/2017 at 4:59 PM, 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? Expand I don't know, I will need to test this further with your cfg you should get every year starting with day 1 Quote Link to comment Share on other sites More sharing options...
OhioBob Posted May 29, 2017 Share Posted May 29, 2017 On 5/29/2017 at 5:24 PM, 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 Expand Is there any code you could add that would ensure each new year always start with Day 1? Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 29, 2017 Author Share Posted May 29, 2017 On 5/29/2017 at 5:27 PM, OhioBob said: Is there any code you could add that would ensure each new year always start with Day 1? Expand 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 Quote Link to comment Share on other sites More sharing options...
OhioBob Posted May 29, 2017 Share Posted May 29, 2017 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? Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 29, 2017 Author Share Posted May 29, 2017 On 5/29/2017 at 5:46 PM, 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? Expand 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 Quote Link to comment Share on other sites More sharing options...
OhioBob Posted May 29, 2017 Share Posted May 29, 2017 On 5/29/2017 at 5:52 PM, 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 Expand 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.