Jump to content

[1.1.x] Kerbin Date Calendar Redux (Version 1.5)


nuclearping

Recommended Posts

Ok, did some tests. Some considerations that may help, though not a solution (yet).

To be safe, I not only put the Kerbin factor to 4 in the config window, I hardcoded it to 4 in the plugin.

First off, confirm there is this differenc in time for each passing day. Could be about 4 minutes/day. Can't yet say why.

Then, checked with a fixed star, how long it takes for Kerbol to make one (apparent) revolution around Kerbin. It is confirmed it takes 9203545 sec.

That time makes for 426 sidereal rotations of Kerbin (Torv/Tsro), of course one day less due to the apparent movement of Kerbol in local time, so 425 "kerbin days". With your plugin, the difference in dates in a Kerbin revolution is indeed that (426 days, hope the 1 day difference is due to inaccuracy in the measurement), but of course the representation of the date is not correct, as it is based on the calendar on Earth: 426 days are about 14 months, so the date is shifted of about 2 months for each revolution. If you want to provide a representation of date similar to the Earth calendar, you should invent a year of 425 days (12 months of 35or 36 days each? 14 months of 30 or 31 days each? or just no months, 425 days in all). It seems weird to have a measurement of time, that on Earth is strongly perceived as tied to a year, that instead changes the starting day each passing year (like, if new year's day was moved to 1st March, than 1st May, and so on).

Now, I have a suspect (but still must make my mind on it, maybe with your help and your friend's...). It is common knowledge that one Kerbin's year is 106,5 days (of course, Earth days 24 hours long). Indeed 106,5 = 9203545/86400 (that is, the UT difference in one of Kerbin's revolutions, divided by the seconds in one of Earth's days). But if we are to consider 106,5 days a year, while the true ratio of rotations/revolution is 406, we would be missing 300 rotations for revolution. It is not exactly like the 4 minutes a day difference (that would require 360 missing rotations to make, given the 6 hours/rotation period of Kerbin) but is close... So, there is to check if that factor of 106,5 kerbin days is someway coded (also indirectly, as a ratio of other numbers) and used in lieu of the true rotations while computing time.

Hope that is not too confusing, it's late (in every sense) and I should better get some sleep rather than writing this... but hope from this may spark the good idea we need to solve this problem.

Link to comment
Share on other sites

hopely next version it stays up when u hit the button for it. right now every time i switch scenes it disspears and have to redispaly

It will. :P

Ok, did some tests. Some considerations that may help, though not a solution (yet).

[...]

Sorry for the late response. Spend my freetime rather playing then thinking.

I asked my buddy if he wants to have a look on this.

Regarding the date and calendar: Yea, you're right (once more :D). But "date" doesn't really matter at the moment, or at least it is not top-priority, as it shouldn't have any impact on the time.

Main problem is to figure out where the time deviation comes from. :P

Link to comment
Share on other sites

Regarding the date and calendar: Yea, you're right (once more :D). But "date" doesn't really matter at the moment, or at least it is not top-priority, as it shouldn't have any impact on the time.

Main problem is to figure out where the time deviation comes from. :P

Yes absolutely. I am concerned with the date (the +/- 1 day) mainly because it is another indicator of what may be wrong in the calculations. The representation of the date in Kerbin's calendar of 106,5 days (of 86400 sec. each) or 406 revolutions/year is another issue completely, it is mostly a flavor thing currently, though I would like to see that covered (using a Earth's year of 365,24.. days to represent Kerbin's calendar is off to me).

What is mostly striking for me, is that your plugin works fine with the 3.991 factor you found (or, perhaps, should be 3.99064 as calculated?) and the simplified formula:

dblUniversalTime *= dblKerbinTimeScaleFactor;

But, it doesn't work if programmed with the complete formula and the correct KerbinTimeScaleFactor = 4:

dblUniversalTime = (dblUniversalTime + 11700 - ((21600 / 9203545) * dblUniversalTime)) * dblKerbinTimeScaleFactor;

though on a board or a spreadsheet the two formulas would give the same results (a very minor difference due to approximation; if I use the exact factor calculated from the ratio of revolution/rotation periods (4*(1-Tsro/Torv))=3.9906399003, the result is exactly the same). Really seems like I am lost on some basic arithmetic, on paper the two *must* behave the same, as the result is identical. But in practice, once that last formula is written in C#, it gives something different.

While I have your attention, may I ask for a minor improvement? I would like if daytime on Kerbin was more evident, and think about having different colors in the Kerbin time box to represent that. Like, light grey text on dark grey background at night; white text on blue background in daytime, and even some purple/pink variations for sunrise/sunset.

Link to comment
Share on other sites

Yes absolutely. I am concerned with the date (the +/- 1 day) mainly because it is another indicator of what may be wrong in the calculations. The representation of the date in Kerbin's calendar of 106,5 days (of 86400 sec. each) or 406 revolutions/year is another issue completely, it is mostly a flavor thing currently, though I would like to see that covered (using a Earth's year of 365,24.. days to represent Kerbin's calendar is off to me).

Yes, it is not "non-important". Using Earth's calendar doesn't work here. Will be fun to program a calendar having 35 / 36 days. :D But that comes least.

What is mostly striking for me, is that your plugin works fine with the 3.991 factor you found (or, perhaps, should be 3.99064 as calculated?) and the simplified formula:

dblUniversalTime *= dblKerbinTimeScaleFactor;

But, it doesn't work if programmed with the complete formula and the correct KerbinTimeScaleFactor = 4:

dblUniversalTime = (dblUniversalTime + 11700 - ((21600 / 9203545) * dblUniversalTime)) * dblKerbinTimeScaleFactor;

though on a board or a spreadsheet the two formulas would give the same results (a very minor difference due to approximation; if I use the exact factor calculated from the ratio of revolution/rotation periods (4*(1-Tsro/Torv))=3.9906399003, the result is exactly the same). Really seems like I am lost on some basic arithmetic, on paper the two *must* behave the same, as the result is identical. But in practice, once that last formula is written in C#, it gives something different.

As I said: For the "simple 3.991" formula I used a fixed Initial Date / Time of ... 13:00:00 to get decent results. Although it should be covered by the 11700 seconds, I suspect that maybe the 13 hours should not be divided by 4 to get "Kerbin" 13 hours (11700s) but real 13 hours (46800s) instead.

Because the previously used "hardcoded" 13:00:00 initial time was not influenced by the "Kerbin factor". And that would kinda explain the 13-hours offset we have now and maybe also the increasing offset each day. I gonna test it later.

While I have your attention, may I ask for a minor improvement? I would like if daytime on Kerbin was more evident, and think about having different colors in the Kerbin time box to represent that. Like, light grey text on dark grey background at night; white text on blue background in daytime, and even some purple/pink variations for sunrise/sunset.

Sure, good idea. :)

Link to comment
Share on other sites

Ok, I did some quick tests.

Summary:

It doesn't matter what "correction time" (K) you use together with the formula. The more the game advances in time, the more inaccurate it still gets.

I made an editable config field for the Correction time K (like for Kerbin factor). When I loaded my game I needed to correct the value to 23450 to have a sunrise at 06:00. Then 11 days later sunrise was at 06:47 so I had to change K to 22900 to be at 06:00 again.

It seems like there is either some variable missing to balance this (you said 4° a day?) or a variable already too much. :D

Link to comment
Share on other sites

So, 11 days passed and sunrise gets late by 47 min? Pretty close to that rate of 4 min/day you already discovered. And that I would still like to find what it means.

But, could you please recheck and tell me about the change to K. 22900 - 23450 = -550 sec., or 9 min 10 sec. (that is way different from 47 min on Earth, but are different also with the rotation in 21600 sec on Kerbin). Each minute on Kerbin, when measured on a 24 hour cycle, is 15 real seconds worth; then those 550 sec / 15 = 36.67 min.

Also, I would like to test the precision of that KerbinScaleFactor. However, I don't have much time currently to run that test. As I wrote, from the ratio of rotation and revolution, that factor should be 3,9906399003. As soon as I can, I will use that value with a very long test: given the precision of that factor, if correct it would take 96285 days (or, 903.896 of Kerbin years) to find a slight error. Anyway, in case that is found to be correct, I would actually hardcode it in the plugin.

One more question. The correct formula (if worked) would actually allow to compute daytime for any planet or moon in Kerbal's universe (it may be at times sllightly off for bodies with eccentric orbits, like Moho and Eeloo). So, apart from the interest in finding why that formula doesn't work, it would be useful to keep looking at this issue if you plan to implement other bodies, in a future release.

Link to comment
Share on other sites

We got it. Friend had a look, made a suggestion and voilá ... Formula works. He is always like that ... :D

From my testings so far it is even daunting accurate. I Time Accelerated to 100'000 several times for several seconds and could even see the shadow of the night side moving on Kerbin and we still hit sunrise at 06:00 and sunset at 18:00. Pinpoint accuracy.

The final formula is:

dblUniversalTime = (dblUniversalTime + 11700.0 - ((21600.0 / 9203544.6) * dblUniversalTime)) * dblKerbinTimeScaleFactor

The major issue was just rounding ... thats all. Friggin' rounding. With the .0 we tell the compiler that we always want to have floating point precission during the whole formula. :cool:

Link to comment
Share on other sites

We got it. Friend had a look, made a suggestion and voilá ... Formula works. He is always like that ... :D

From my testings so far it is even daunting accurate. I Time Accelerated to 100'000 several times for several seconds and could even see the shadow of the night side moving on Kerbin and we still hit sunrise at 06:00 and sunset at 18:00. Pinpoint accuracy.

The final formula is:

dblUniversalTime = (dblUniversalTime + 11700.0 - ((21600.0 / 9203544.6) * dblUniversalTime)) * dblKerbinTimeScaleFactor

The major issue was just rounding ... thats all. Friggin' rounding. With the .0 we tell the compiler that we always want to have floating point precission during the whole formula. :cool:

NOOO. I can't believe...it was so... simple! (but, damned C language: why it uses integers when we mean otherwise :D).

Please extend my thanks to your friend.

EDIT: BTW, noted you put 9203544.6 for Kerbin's revolution period, rather than 9203545 (as reported by KSP Wiki). The first value is exactly what I have by calculating the orbital period from Kerbin semimajor axis and Kerbol gravitational parameter, so confirm you have it correctly. Now.

Edited by diomedea
Link to comment
Share on other sites

I want to find a meaning for that value of 11700. Even if I have begun to call it K (as is called the correction to chronographs, used in navigation), I had to believe it is tied someway to the longitude.

Until now we have considered local time as tied to KSC. That is right, but local time (in the astronomical sense) is used for navigation purposes, not in everyday life. What we have on the clock is the time of the timezone we live in.

On Earth, 24 hours define 24 timezones; and with a Kerbal day of 24 hours, it should go the same. Each timezone is (unless for geography and state borders) 15° wide in longitude (7.5° Eastward and 7.5° westward of its center meridian). So, KSC, at a longitude of 74.558° W, is almost in the center of the timezone -5 (its time is 5 hours less than at the prime meridian, that is the reference with longitude=0°).

Because of the above, it means it will be 11:00:00 (5 hours more) at the prime meridian, when we have sunrise at KSC (06:00:00 on the clocks of that timezone).

Now, time is computed from midnight (00:00:00). So, I should rather choose to start not from 11:00:00, but 11 hours before. With Kerbin's rotation period at 21600 sec, 11/24 hours is 9900 sec. Therefore:

- the correct value of K, as (now really) a chronograph correction, is 11700-9900 = 1800 (Chronographs are never updated for the timezone, so when used for navigation are generally set on Greenwich Mean Time. K is the error of the chronograph in relation to GMT);

- the time difference at KSC (measured on the clock) is -5:00:00 (the reference is the timezone 0 centered on the prime meridian);

- the local time at KSC (astronomical) is (-74.558°/360°*21600)= -4473.48 sec (= -4:58:14) different than the local time at the prime meridian;

- the value of UT (as "Universal Time") has no implication of locality. It is the same everywhere (KSC, prime meridian, and in outer space).

About K. I would have expected from Squad a choice of initial positions matching the notion of midnight at UT=0 for the prime meridian. Instead, that value of K shows a different choice. At UT=0 it is midnight for the timezone +2 (centered on longitude 30° E), if K is assumed = 0.

Conclusion. We now have the correct value of the local time at KSC, matching with sunrise. Let we consider them to be astronomers, so they go with local time. But, when we move around Kerbin, we see time differences due to the different longitude (note: as Kerbin has no axial tilt, there is no change in local time due to seasonal changes and latitude). If we want, it could now be possible also to use the local timezone, instead of a local time valid only for KSC. To do so, we better have to use K=1800.0 and subtract the timezone number *900.0 sec to the formula. We set timezone = -5 as default for KSC, but that may be changed to let show the time of other timezones.

Edited by diomedea
Link to comment
Share on other sites

Updated the Plugin with the latest changes.

While I have your attention, may I ask for a minor improvement? I would like if daytime on Kerbin was more evident, and think about having different colors in the Kerbin time box to represent that. Like, light grey text on dark grey background at night; white text on blue background in daytime, and even some purple/pink variations for sunrise/sunset.

I tried to implement this but it doesn't work out very well. The text becomes very hard to read, kind of itchy in the eyes, if you put it in purple / pink colors. So I tried to put it in some yellow-colors, like Gold for the sunrise, Yellow for daytime, Orange for sunset and black for night. But you hardly see any difference in the colors, except from night. But at night when he is supposed to draw a black text he only draws a black text but without the window box around it. So it is only blank black text on the game screen. Weird ... So I reverted it. :P

Please extend my thanks to your friend.

Friend says "You're welcome". :D

EDIT: BTW, noted you put 9203544.6 for Kerbin's revolution period, rather than 9203545 (as reported by KSP Wiki). The first value is exactly what I have by calculating the orbital period from Kerbin semimajor axis and Kerbol gravitational parameter, so confirm you have it correctly. Now.

Friend also found out about that the value in the Wiki was rounded. Thats also what caused the deviation.

[...] If we want, it could now be possible also to use the local timezone, instead of a local time valid only for KSC.

From the experimental point of view this is interessting, yes.

But from the practical pov: Who would want to use this? Unless you want to "colonize" Kerbin or so ... :P

Displaying the local time at KSC is what I wanted. So I'm fine for now. But feel free to use the code to experiment with it if you want. :D

Link to comment
Share on other sites

Because they told me I get Snacks when I do so. But they were not handed over yet ... :(

Look here: http://forum.kerbalspaceprogram.com/threads/68270-0-23-Kerbin-Date-Calendar-%28Version-1-3%29?p=958721&viewfull=1#post958721

I don't want to relocate it yet because usually people who already use the Plugin will forget to delete the old DLL file from Plugins. :D

And unless it works I don't see any problem. Do you?

Link to comment
Share on other sites

Because they told me I get Snacks when I do so. But they were not handed over yet ... :(

Look here: http://forum.kerbalspaceprogram.com/threads/68270-0-23-Kerbin-Date-Calendar-%28Version-1-3%29?p=958721&viewfull=1#post958721

I don't want to relocate it yet because usually people who already use the Plugin will forget to delete the old DLL file from Plugins. :D

And unless it works I don't see any problem. Do you?

Not in the "it kills me" way :D but it could end up in trouble if someone want to remove the mod and has forgot about the special location.

But what you can do is change the plugin to a empty file and move the real plugin in your gamedata subdirectory, so there is no double plugin loading after updating. And the source folder is usually in the gamedata subdirectory too.

Just as a matter of form ;)

Link to comment
Share on other sites

I tried to implement this but it doesn't work out very well. The text becomes very hard to read, kind of itchy in the eyes, if you put it in purple / pink colors. So I tried to put it in some yellow-colors, like Gold for the sunrise, Yellow for daytime, Orange for sunset and black for night. But you hardly see any difference in the colors, except from night. But at night when he is supposed to draw a black text he only draws a black text but without the window box around it. So it is only blank black text on the game screen. Weird ... So I reverted it. :P

But from the practical pov: Who would want to use this? Unless you want to "colonize" Kerbin or so ... :P

Displaying the local time at KSC is what I wanted. So I'm fine for now. But feel free to use the code to experiment with it if you want. :D

About the different combinations of colors for the time box. I would like to make some tries, if you could hand me the code where you already had the styles defined for those tests. It certainly requires some effort to find combinations appeasing and looking good with anything that KSP may be displaying.

About the timezones. If KSC time is all you want, no problem. There are users who actually "colonize" Kerbin, or at least conduct missions in different places over its surface. The very minimum, to have a look at the anomalies at specific points; or to collect science from different biomes. But they have always had to do without any correct clock, so may not miss much not having time for the correct timezone. It was an additional feature that could be made without much effort.

Link to comment
Share on other sites

too bad the list of significant dates got cut. Could have integrated somehow with the Achievements and Final Frontiers mods. Also I thought this would affect the game clock overall, but the tracking center still shows a regular time of day. I'm not sure why the devs didn't have days match Kerbin rotation

Edited by Gaiiden
Link to comment
Share on other sites

Ah, sorry for late response. Didn't think anybody is going to respond here anymore. :D

@diomedea: Well, from the mathematical point of view it is a quick-change, sure. You only need to make the 11700s available to be changed by the user. But how does the user "visually" pick the zone for the timetracking? You know what I mean? The most simple (and user-unfriendly) way would be to offer another edit field where the user either puts the offset-seconds, a 360° digit or a longitude. But I don't like that idea since it is very unintuitive.

You know the Landing AutoPilot from MechJeb? If you click "Pick Target on Map" you get into map view and can select the place to land with a nice crosshair. That would be great for the user. But I don't know the efforts (code-wise) to do that and I'm not sure if I want to figure that out at the moment. :D

@mjukis: Thats a good point. ;)

@Gaiiden: Can you give more details on how you think a list of significant dates could have been integrated with the Final Frontiers mod? It would have been just a list of "Initial Dates" to pick from to set the Calendar's starting date. But you still can freely change the initial date in the settings window.

No, it doesn't affect the game clock. But thats an idea I might try figuring out. And yea, you're right. I also don't know why Kerbin's revolution period is some 106 days, but the game clock counts 365 days ... :confused:

Link to comment
Share on other sites

@diomedea: Well, from the mathematical point of view it is a quick-change, sure. You only need to make the 11700s available to be changed by the user. But how does the user "visually" pick the zone for the timetracking? You know what I mean? The most simple (and user-unfriendly) way would be to offer another edit field where the user either puts the offset-seconds, a 360° digit or a longitude. But I don't like that idea since it is very unintuitive.

You know the Landing AutoPilot from MechJeb? If you click "Pick Target on Map" you get into map view and can select the place to land with a nice crosshair. That would be great for the user. But I don't know the efforts (code-wise) to do that and I'm not sure if I want to figure that out at the moment. :D

...

No, it doesn't affect the game clock. But thats an idea I might try figuring out. And yea, you're right. I also don't know why Kerbin's revolution period is some 106 days, but the game clock counts 365 days ... :confused:

About timezones. IMO, you have got what I mean. The change is really simple code-wise, more so if one goes to use the local time (astronomical) tied to the exact longitude of a place; barely more complex if one goes to use the timezone time, as it also requires to convert longitudes to what is the one for the central meridian of the timezone. You say it is unintuitive if the longitude is to be given in a entry box, and certainly having a graphical way to input the longitude (as your nice example with MechJeb's landing autopilot) would be much nicer. But, I guess most of the users with KSP have pretty good knowledge with longitude, and where to read it from one of many tools that show it; therefore for them it would not be unintuitive. I would say, it was certainly less intuitive and clear the kerbinrotationfactor. Those users who don't care to see other places than KSC, may well leave the longitude default for KSC and never use that entry.

Wanna know about the 106,5 days for Kerbin's year? Take the 9,203,544.6 sec it takes for a revolution and divide by 86400 sec in a standard 24 hours day = 106.5225 standard days in a year. Of course, because Kerbin is said to have days of 24 hours, while instead it rotates 4 times faster. Counting standard years of 365 days with Kerbin is totally off; it shows that, while creating KSP, some concepts were left behind. So yes, the game clock is totally wrong, and a much better way of counting years (as revolutions around Kerbol) could instead be offered with this mod.

Link to comment
Share on other sites

  • 2 weeks later...

Hello! I don't know if you will see this, but would it be possible to release a small config tweak to, instead of rescaling the meaning of a second or hour,make it so that each second passes real time, and a day ends after 6 hours? This mod's approach is to speed up time to match the 6 hours rotation with the 24 hour real day, which leads to 4 ingame seconds per real second.

I was wondering if it was possible to have a version were seconds pass normally, but upon reaching 6 hours, the clock makes it a day. Thank you in advance!

Link to comment
Share on other sites

@Gaiiden: Can you give more details on how you think a list of significant dates could have been integrated with the Final Frontiers mod? It would have been just a list of "Initial Dates" to pick from to set the Calendar's starting date. But you still can freely change the initial date in the settings window.

N/M, I was new to the FF mod and hadn't looked closely at the detail window to see that they do track day/times of events - and also I think I misinterpreted the feature you had planned

Link to comment
Share on other sites

  • 2 weeks later...

It may be nitpicky, but I too would like to support the change to have the day counter relative to six hours, rather than a clock adjustment. This is something I've thought about calculating out myself for mission historical records, but a mod such as this makes it so much easier.

Thanks for sharing your creation with the community.

Link to comment
Share on other sites

Somewhat new to the forums here and trying out various addons. I particularly like the KSP Calendar mod. Though, any chance the date format could be just the year, day of the Kerbal year (1-106), and Kerbal time? I find it difficult to imagine the Kerbal's would have the same Gregorian calendar with the various months which Earthlings use. ;-)

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

×
×
  • Create New...