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

[nuclearping]

Kerbin Date Calendar Recalculated

Please note that this Plugin is deprecated!

You can find a updated version for 1.5.x+ here:

Thanks @linuxgurugamer  

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Description:

Adds a small calendar window to keep track of the date and time at home on Kerbin KSC and displays it in a proper format.

 

Preview:

 

Summary:

This is a small Plugin I created in first place for myself as a proof-of-concept for Plugin-development. Also whenever I'm playing KSP I often wanted to have something which shows me the passed time in my universe in a proper date and time representation, instead of "Year 1, Day 64, 2h 41m 12s".

So I made this ... and thought to share it with you.

 

License:

The Source Code of the Plugin and Plugin itself are released under the Creative Commons Public Domain Mark 1.0 license.

See http://creativecommons.org/publicdomain/mark/1.0/ for further details.

 

The Source Code is included in the Zip file in the folder Source\KSPCalendar.

You are of course free to change, contribute or modify this plugin.

However if you plan to improve its functionality and/or features you are invited to send me a PM here on Kerbal Space Program forums so that we can maintain a consistent branch.

 

Future Plans:

• Time Zones
• Utilization of the Toolbar plugin. (Version 1.1)
• Display on demand (not always visible). (Version 1.1)
• Dropdown-list of (famous) initial dates. (Discarded)

 

Requirements

This Plugin utilizes and requires the Toolbar Plugin, which can be found here:

http://forum.kerbalspaceprogram.com/threads/60863

 

The Toolbar Plugin is NO LONGER shipped with this package.

 

Download & Installation:

Latest version (1.1.x)

https://github.com/nanathan/KSPCalendar/releases

 

Old versions (for 0.25, 0.90)

http://www.curse.com/ksp-mods/kerbal/223684-kerbin-date-calendar

 

Extract the Zip archive into your Path/To/KSP/ directory.

 

Usage:

 

After installation just start KSP and load your savegame.

Add the Calendar Button(s) to your Toolbar.

Displaying the Calendar can be enabled or disabled by clicking the button:

Configuring the Calendar can be done by clicking the button:

The windows can be moved by drag & drop.

The display format settings of the date follow the C# DateTime format strings:

http://www.csharp-examples.net/string-format-datetime/

The Plugin will work with any savegame since the passed time in your universe will be added to the initial date and time of KSP Calendar.

The Plugin will not modify savegames.

 

Hints:

1. If you enable the new Kerbin time scale feature you will have an accurate Real Time display of the local time at Kerbin Space Center!
2. If you enable the new Override MET timer in flight mode feature you will get the Kerbin date and time displayed in the top left corner, instead of the default Mission Timer.

 

Changelog:

 

Version 1.5-Redux - nathan1
	* Recompile for KSP 1.1.x

Version 1.5-14/08/25 - nuclearping
	* Removed included Toolbar from Mod package
	* Removed config button from calendar window
	* Integrated Config button into Toolbar
	* Removed obsolete Calendar window from Flight Scene when "Override MET display" is enabled
	* Calendar window will now only be visible in Flight Scence when "Show System date" and "Override MET display" are enabled
	  to display the System date / time.

Version 1.4-14/08/24 - nuclearping
 	* Recompile for 0.24.2
 	* Added Option to override flight mode MET display with KSPCalendar Date

Version 1.3-14/02/13 - nuclearping
 	* Fixed the "Kerbin time scale" problem from 1.2
 	* The Calendar window will now stay visible when switching scenes
 	* Removed unnecessary config window entries introduced with 1.2

 	* Thanks to diomedea who helped me figuring out the problem from 1.2
 	* Also thanks to Christian who helped us aswell figuring out the problems with the getCurrentKerbinDateTime()-formula for Kerbin time scale

Version 1.2-14/02/08 - nuclearping
 	* Found an issue in the "Kerbin time scale" calculation.
 		In the long run the date & time go awfully inaccurate.
		Like it is late at night at KSC but Calendar shows ... 14:37
 		So my tests have shown that either Kerbin doesn't rotate exactly
 		4 times faster or there is some sort of floating point inaccuracy 
 		occuring in the long run.
 		However I found out that a fixed Time Scale factor of 3.991 does a
 		pretty good job instead.
 		So with an Initial Time of ... 13:00 and a Kerbin factor of 3.991
 		you should get an accurate result.

Version 1.1-14/02/04 - nuclearping
	* Toolbar implementation
	* Added "Kerbin time scale" feature
	* Added "System time" feature
	* Cleaned up GUI
	* Cleaned up code

Version 1.0-14/02/02 - nuclearping
	* Initial release

 

Issues:

If you encounter any issues (maybe because you messed up with some of the settings ) close the game and delete the file

X:\Path_To_Your_KSP\GameData\KSPCalendar\Plugins\PluginData\config.xml

 

This will reset the Plugin to default settings.

 

Otherwise ...

Have fun!

 

Edited January 7, 2019 by nuclearping

[aeTIos]

New year's Eve... I saw pun.

Nice little plugin here! Might try this at some point.

[BananaDealer]

I've needed this.

Thank you so much.

[TheCanadianVendingMachine]

Why isn't this given more attention?

[Proot]

Nice small detail! +1 Download!

[jpinard]

Can I ask a dumb question? Kerbin doesn't have the same number of hours in a day, and days in a year does it?

[nuclearping]

Wow, thanks for all the nice feedback. Much appreciated!

Can I ask a dumb question? Kerbin doesn't have the same number of hours in a day, and days in a year does it?

Actually no, and yes. Kerbin needs 6 hours for a full rotation. http://wiki.kerbalspaceprogram.com/wiki/Kerbin (search for "rotation")

However the ingame timer has a 24 hours rythm. So after 23h 59m 59s it increases the Day and resets the time to 00h 00m 00s.

Edited February 3, 2014 by nuclearping

[kookoo_gr]

very nice plugin indeed. may i make a suggestion? is it possible to add an option to see in parallel with the ingame date system you made the actual date/time from the pc's clock?

[nuclearping]

Updated.

is it possible to add an option to see in parallel the actual date/time from the pc's clock?

Added.

[nuclearping]

Can I ask a dumb question? Kerbin doesn't have the same number of hours in a day, and days in a year does it?

Actually it was a pretty good question. Because it gave me the idea to implement a "Kerbin time scale" feature into my plugin, by multiplying the KSP Universal Time by (24 / 6) = 4,333.....

It looks like if you start a (new) game, you will be starting at noon. So if you set the initial date of the plugin to something like 1980/01/01 12:00:00 and enable the new "Kerbin time scale" feature you will have sunset at 18:00, sunrise at 6:00 and noon at 12:00. Pretty cool.

Edit - Forgot to add: This also works with savegames, since the passed time since game was created (Universal Time) is added to the Initial Time of the Plugin.

Edited February 4, 2014 by nuclearping

[Proot]

Updated.

+Toolbar +RealWorldâ„¢ small date/clock???

From a nice curiosity to a must have! Thank you!

Actually it was a pretty good question. Because it gave me the idea to implement a "Kerbin time scale" feature into my plugin, by multiplying the KSP Universal Time by (24 / 6) = 4,333.....

It looks like if you start a (new) game, you will be starting at noon. So if you set the initial date of the plugin to something like 1980/01/01 12:00:00 and enable the new "Kerbin time scale" feature you will have sunset at 18:00, sunrise at 6:00 and noon at 12:00. Pretty cool.

Very Cool!

[KerbMav]

Is this correct, you are using the old obsolete historical legendary plugins folder in KSP root instead of putting everything into your own mod folder under gamedata?

[nuclearping]

I updated the Plugin. I found an issue in the "Kerbin time scale" calculation.

In the long run the date & time go awfully inaccurate. Like it is late at night at KSC but Calendar shows ... 14:37.

So my tests have shown that either Kerbin doesn't rotate exactly 4 times faster or there is some sort of (floating point) inaccuracy occuring in the long run.

However I found that a fixed Time Scale factor of 3.991 does a pretty good job instead.

So I added an option in the configuration window to let you play with it. But with an Initial Time of ... 13:00 and a Kerbin factor of 3.991 I'm getting quite accurate results.

Is this correct, you are using the old obsolete historical legendary plugins folder in KSP root instead of putting everything into your own mod folder under gamedata?

As I said, it is my first plugin / addon. I basically followed the tutorial at http://wiki.kerbalspaceprogram.com/wiki/Creating_your_first_module ... Had no idea that this is important? However, it works.

[diomedea]

I updated the Plugin. I found an issue in the "Kerbin time scale" calculation.

In the long run the date & time go awfully inaccurate. Like it is late at night at KSC but Calendar shows ... 14:37.

So my tests have shown that either Kerbin doesn't rotate exactly 4 times faster or there is some sort of (floating point) inaccuracy occuring in the long run.

I have one possible explanation.

Kerbol (the Sun) moves apparently because of Kerbin's revolution around it. Kerbin's sidereal rotation period has been defined = 21600 sec.; please note "sidereal", meaning in relation to fixed stars, not to Kerbol.

With our Earth, the 24 h rotation period is defined around the Sun instead: because of the Earth's revolution, there is a difference of one rotation in a year against the sidereal period.

So, to correct your "Kerbin time", you should consider it takes 9203545 sec. (accordind to KSP Wiki) to complete a revolution, and compute apparent time (with reference to Kerbol position in the sky) not only for the rotation, but for the revolution period as well.

[Goldham]

Well I guess i can squeeze 1 more mod into my folder.

[nuclearping]

I have one possible explanation.

Kerbol (the Sun) moves apparently because of Kerbin's revolution around it. Kerbin's sidereal rotation period has been defined = 21600 sec.; please note "sidereal", meaning in relation to fixed stars, not to Kerbol.

With our Earth, the 24 h rotation period is defined around the Sun instead: because of the Earth's revolution, there is a difference of one rotation in a year against the sidereal period.

So, to correct your "Kerbin time", you should consider it takes 9203545 sec. (accordind to KSP Wiki) to complete a revolution, and compute apparent time (with reference to Kerbol position in the sky) not only for the rotation, but for the revolution period as well.

Thanks for your explanation. I would really love to try it. But sorry mate ... Can you explain it again in a way so that dumb people like me, who always had bad notes in Mathematics at school, can understand it?

[diomedea]

Thanks for your explanation. I would really love to try it. But sorry mate ... Can you explain it again in a way so that dumb people like me, who always had bad notes in Mathematics at school, can understand it?

I think you will smile after getting it. It is not too difficult.

Consider if Kerbin was not rotating. So, KSC zenith would always point to a fixed location in space (think like there is a distant star in that location).

That would be, by definition, making Kerbin sidereal rotation speed = 0 (and, conversely, Kerbin rotation period infinite).

While Kerbin does not rotate, it still revolves around its star, Kerbol. This revolution period is given (9203545 sec.), of course it is tied to the mean distance D from Kerbol and the gravitational parameter GP of Kerbol (period T = 2 * À * √(D³/GP) ), however we don't need to calculate that.

The fact we have to note, instead, is that Kerbol apparent position in the sky will change, exactly the same as if it wasn't Kerbin revolving around the star, but the star around Kerbin. This is the same concept that, on Earth, was at the base of the Ptolemaic (geocentric) system.

Because of this revolution, the star is seen as doing one full circle around the planet, in a year on Earth, or in 9203545 sec. on Kerbin. That full circle will make one day long as one revolution: there will be one sunrise and one sunset.

Now, on Earth, since the beginning of humanity, there was no knowledge of the planet moving. Because it took some time (apparently) for the Sun to complete one round, that time was used to define the duration of a day. Humanity had no knowledge that time was due to both the rotation of the planet and the revolution. It was observed, however, that the stars (the distant ones, considered fixed in space) actually moved in relation to the Sun, day after day. The length of the year was put not only because of the seasons, but because the stars took that time to complete one full round in relation to the apparent position of the Sun.

So, our time reference of 24 hours/day in not due to the planet Earth's rotation, but is tied to its rotation and its revolution, together. And humanity took the sun movement as a fixed reference for time, while observing the fixed stars rotate in relation to it (while the truth is just the opposite).

In Kerbin's case, the fact is that Squad, instead of thinking like ancient humans, defined time in relation to the fixed stars (sidereal). And that means we will see Kerbol change its position along one of Kerbin's years, making exactly one more day that what we would expect based on the sidereal rotation period.

Edited February 9, 2014 by diomedea

[Mecripp]

Try'ed to use this mod but it took out some of magicsmoke's mod part's, I can se there blank squares and can click on them but can't see them any use magicsmoke and have the same bug ?

[nuclearping]

I think you will smile after getting it. It is not too difficult. [...]

Yea, thanks, I got it. Also implemented it.

I drew a picture to see if I understood you correctly:

Basically for one full "sidereal" rotation Kerbin needs 9'203'545 seconds and this causes an "additional" day per year, right?

So to balance this in my calculation, I have to add a fraction of the passed "sidereal" day to the universal time, right?

private void getCurrentKerbinDateTime() {
	double dblUniversalTime = Planetarium.GetUniversalTime(); // Get passed time in Universe since game started (in seconds)
	double dblKerbinTimeScaleFactor = 4; // 24 / 6

	dtKerbinInitial = dtKerbinInitial.Date; // Strip time from Initial date since we add our own time

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

	dtKerbinCurrent = dtKerbinInitial.AddSeconds (dblUniversalTime);
}

So what I now do here is:

Kerbin_UT = (Passed_UT + 11700s + (21600s / 9203545s) * Passed_UT) * 4

Passed_UT = 3969694s (in my save game for instance, so we are like half a "sidereal" day in the game)

11700s = If you create a new game you start somewhat after noon, like 13:00. So we add 11700s (13 / 4 * 60 * 60) to midnight.

(21600s / 9203545s) * Passed_UT = We need the fraction of the passed sidereal day.

4 = Kerbin's day (relative to Kerbol) is 6 hours, so the day passes (24 / 6) times faster.

Kerbin_UT = (3969694 + 11700 + (21600 / 9203545) * 3969694) * 4

Kerbin_UT = 15'962'842s (rounded from 15962842.24486542957088817406771)

Hence from calculations we should be somewhat at 184d 18h 7m 22s in the game.

But as you can see in the screenshot we're still off ... The date is somehow correct, but the time is really screwed. It is like 22:30-23:00 at KSC, but the clock shows 07:46. I know the time automatically comes from all the other calculations. So the mistake must be somewhere out there ...

Any idea?

Try'ed to use this mod but it took out some of magicsmoke's mod part's, I can se there blank squares and can click on them but can't see them any use magicsmoke and have the same bug ?

If you mean Infernal Robotics: Yea, I'm using it aswell but didn't encounter any sort of issues.

Edited February 10, 2014 by nuclearping

[diomedea]

@ nuclearping:

1) from the picture, and the implementation you did, it seems you got it!

2) I use a different method than your implementation (computing time angles from time elapsed and rotation or revolution periods, and then converting those angles in time) but the end result is the same. With the same data you used, time is 184d 18h 07m 22s. BUT:

3) Just thinking back at my example, with a non-rotating Kerbin: if Kerbol was observed to rise because of the revolution, it would rise from West!! A counterclockwise revolution brings to time elapsing backwards! So, my fault as I did not consider the sign: not add, but subtract the angle due to revolution from the angle due to sidereal rotation. With the same data of your example (UT=3969694) that would give 183d 21h 25m 10s. Time seems to match with Kerbol position in your picture; about the 1 day difference (183 instead of 184) can't say, could it come from how the variable "dtKerbinInitial" is initialized?

4) About the picture showing 07:46:17 in your example. You did yourself the calculation correctly, but what is shown is different. Possibly, there is some hidden conversion not correctly executed (I have no knowledge about functions like .Date and .AddSeconds, so can't say if those may be responsible).

[nuclearping]

Hey,

thanks for the clarification for point 3. I didn't think about that. The whole small thing becomes quite complex, but also quite interessting tho.

I also don't know where the display-issue comes from. dtKerbinInitial is just the date from "Initial Date" which you can see in the settings window, "01.01.1980 00:00:00". So thats our "entry point" in the year.

But after changing the code to subtract the fraction now and loading the savegame it looks like we are ...

1) like 13 1/2 hours off. I have sunset at 04:30 and sunrise at 16:30 ...

2) the more the game advances in time the more the offset grows. If I time-accelerate day by day to check the sunset / sunrise times, I'm at 4:55 sunset and 16:55 sunrise after 5-6 days or so.

DateTime.AddSeconds handles the date and time by our real world calendar according to your regional and language settings. So if you initialize DateTime with 01.01.1980 00:00:00 for instance and execute DateTime.AddSeconds(3600) you will get 01.01.1980 01:00:00 as result, because you just added 3600 seconds = 1 hour, DateTime.AddSeconds(86400) will result in 02.01.1980 00:00:00 because we added 24 hours, etc.

So the Date may vary a bit, but this shouldn't affect Time at all ...

[diomedea]

Short of making simulations myself, I have no idea at the moment what could be wrong now.

One thing is, anyway, sure. That factor you found to be working (3.991 instead of 4), is exactly the same that would be found computing the rotation - revolution period against only the rotation period. To show that, first I will show how I compute the apparent time.

My procedure for calculating time is (UT= passed time; K= cronograph correction=11700; Tsro=sidereal rotation period=21600; Torv=orbital revolution period=9203545, all in seconds):

- Time Angle due to sidereal rotation (Θsro): (UT+K)*360°/Tsro

- Time angle due to orbital revolution (Θorv): UT*360°/Torv

- Total Time angle (ÃŽËœt) = ÃŽËœsro - ÃŽËœorv

- Apparent Time (t) = Θt/360°*(86400/4) (on Kerbin)

while the procedure you found working is:

- Apparent Time = (UT+K)/Tsro*(86400/3.991)

the two procedures give ~ the same results. Infact, your 3.991 factor is found if calculated as 4*(1-Tsro/Torv)=3.99064. That is to show, the issue about that factor IS really the one due to the revolution period.

Anyway, I want to think a bit about what you found. It seems time is getting late at a rate of about 4 minutes/Kerbin day, and that rate is 1° a day in our universe (360°*4/(60*24h)), or about the same angular movement the Sun would be seen as moving each day (360°/365.2425 days). A very telling rate for an astronomer. Maybe I will find what that means. In the meantime, if you could make some more extended tests, those will probably allow to find what is wrong. Or, in case, would you provide the C# sourcecode of the version you have in development? So that I may make some tests myself.

DateTime.AddSeconds seems really straightforward. But, a thought: does it manage leap years (like 1980 is)? That may be one possible cause for the missing day, if the added seconds make it go beyond a 29th feb boundary.

[nuclearping]

Remarkable. I just played around with the numbers and found that 3.991 is giving me the most accurate results, but for that I had to set the Initial Date to 01.01.1980 13:00:00, which probably also got rid of the ~13 hours offset we have now. However adding the 11700s should have kind of fixed that too ... So it is a bit confusing.

Leap years are being handled by DateTime correctly, so that could explain the +/- 1 day, but as said before it shouldn't affect time in any way.

I will ask a good friend of mine if he may want to have a look on this. He's really great and enthusiastic about mathematics. So I guess we could figure it out together.

Here is the current WiP source: https://dl.dropboxusercontent.com/u/16274518/KSP-Calendar-1.2_WIP.zip

The function of interesst is CalendarFunctions.cs private void getCurrentKerbinDateTime()

Edited February 10, 2014 by nuclearping

[diomedea]

I will ask a good friend of mine if he may want to have a look on this. He's really great and enthusiastic about mathematics. So I guess we could figure it out together.

Here is the current WiP source: https://dl.dropboxusercontent.com/u/16274518/KSP-Calendar-1.2_WIP.zip

The function of interesst is CalendarFunctions.cs private void getCurrentKerbinDateTime()

Thanks for the sourcecode. May I ask, are you using dblKerbinTimeScaleFactor = 3.991 together with the (-(Tsro/Torv)*UT) part of the formula that deals with the revolution effect? Cause with the last, the TimeScaleFactor should return to be = 4.

		double dblKerbinTimeScaleFactor = 3.991;

		.....
			if (isKerbinTimeScale) {
				dtKerbinInitial = dtKerbinInitial.Date;
				dblUniversalTime = (dblUniversalTime + 11700 - ((21600 / 9203545) * dblUniversalTime)) * dblKerbinTimeScaleFactor;
			}

			dtKerbinCurrent = dtKerbinInitial.AddSeconds (dblUniversalTime);

Fine if you want to involve others. More eyes on this (especially if good ones) the faster this thing will be dealt with. If you like, I will continue to try and see about it, anyway. This is one kind of problem similar to what I have to deal with in my profession.

[nuclearping]

Thanks for the sourcecode. May I ask, are you using dblKerbinTimeScaleFactor = 3.991 together with the (-(Tsro/Torv)*UT) part of the formula that deals with the revolution effect? Cause with the last, the TimeScaleFactor should return to be = 4.

No, the 3.991 is just the initial value. He uses the value from the config, otherwise if he cannot convert it somehow he uses the 3.991 as fallback:

try {
	dblKerbinTimeScaleFactor = Convert.ToDouble (strKerbinTimeScaleFactor); // <== Set in the config window
}
catch(InvalidCastException) {
	dblKerbinTimeScaleFactor = 3.991; //(24 / 6); // Fallback
}

So if you installed the plugin make sure you set "Kerbin factor" to 4 in the config window.

If you like, I will continue to try and see about it, anyway. This is one kind of problem similar to what I have to deal with in my profession.

Sure, you're welcome.