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

[Sigma88]

56 minutes ago, OhioBob said:

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.

I have no idea about transfer window planner.

But I think most of the code works handling seconds, it's just wheb the time is displayed that years and days come into play

So the changes should be pretty easy if they are required

@OhioBob it just occurred to me

Try hardcoding the year and day values and just set useHomeYear/Day to false

[OhioBob]

21 minutes ago, Sigma88 said:

Try hardcoding the year and day values and just set useHomeYear/Day to false

How do I write that?  Would I do something like this:

Kronometer
{
    CustomTime
    {
        Year
        {
            Value = 14544000
        }
        Day
        {
            Value = 36000
        }
    }
}
 

Edited May 29, 2017 by OhioBob

[Sigma88]

8 minutes ago, OhioBob said:

How do I write that?  I don't know what the variable names are.

@Kronometer
{
	%CustomTime
	{
		%Year
		{
			%value = // year length in seconds
		}
		%Day
		{
			%value = 36000
		}
	}
}

Edited May 29, 2017 by Sigma88

[OhioBob]

Just now, Sigma88 said:

@Kronometer
{
	@CustomTime
	{
		@Year
		{
			@value = // year length in seconds
		}
		@Day
		{
			@value = 36000
		}
	}
}

Yep, I figured that out just as you were typing it (except I forgot the @).  I'll give it a try.

[Sigma88]

Just now, OhioBob said:

Yep, I figured that out just as you were typing it (except I forgot the @).  I'll give it a try.

I edited my post

use the edited one since I don't think the year value is defined by default, which means the @value will fail

[OhioBob]

23 minutes ago, Sigma88 said:

@Kronometer
{
	%CustomTime
	{
		%Year
		{
			%value = // year length in seconds
		}
		%Day
		{
			%value = 36000
		}
	}
}

This works like a charm. 

I started a new game from the beginning and time warped through several years.  Every new year started right on schedule just like the one before it.  The only thing that I think is a little weird it that each year starts with Day 0.  That's not a big deal and I can certainly live with it, but having a Day 0 just seems odd to me.  I would think the year should start with Day 1.

[Sigma88]

3 minutes ago, OhioBob said:

This works like a charm. 

I started a new game from the beginning and time warped through several years.  Every new year started right on schedule just like the one before it.  The only thing that I think is a little weird it that each year starts with Day 0.  That's not a big deal and I can certainly live with it, but having a Day 0 just seems odd to me.  I would think the year should start with Day 1.

try adding offsetDay = 1, it should be 1 by default but maybe there's something going wrong

 

@Kronometer
{
    %DisplayDate
    {
        %PrintDate
        {
            %offsetDay = 1
        }
        %PrintDateNew
        {
            %offsetDay = 1
        }
        %PrintDateCompact
        {
            %offsetDay = 1
        }
    }
}

also, I found out what was going wrong with your install, you have 

dayLengthMultiplier = 1.66666666666667

and that 7 is what is destroying stuff

I think I will add a parameter to round year and day values to the nearest second

Edited May 29, 2017 by Sigma88

[OhioBob]

10 minutes ago, Sigma88 said:

try adding offsetDay = 1, it should be 1 by default but maybe there's something going wrong

No difference.  Years are still starting at Day 0.

I put everything under the same @Kronometer{} node, that shouldn't make any difference, should it?

Spoiler

@Kronometer
{
	%CustomTime
	{
		%Year
		{
			%value = 14544000
		}
		%Day
		{
			%value = 36000
		}
	}
	%DisplayDate
	{
		%PrintDate
		{
			%offsetDay = 1
		}
		%PrintDateNew
		{
			%offsetDay = 1
		}
		%PrintDateCompact
		{
			%offsetDay = 1
		}
	}
}

 

 

[Sigma88]

Just now, OhioBob said:

No difference.  Years are still starting at Day 0.

I put everything under the same @Kronometer{} node, that shouldn't make any difference, should it?

  Hide contents

@Kronometer
{
	%CustomTime
	{
		%Year
		{
			%value = 14544000
		}
		%Day
		{
			%value = 36000
		}
	}
	%DisplayDate
	{
		%PrintDate
		{
			%offsetDay = 1
		}
		%PrintDateNew
		{
			%offsetDay = 1
		}
		%PrintDateCompact
		{
			%offsetDay = 1
		}
	}
}

 

 

could you send me the mm cache file?

[OhioBob]

3 minutes ago, Sigma88 said:

could you send me the mm cache file?

Here you go:  http://www.braeunig.us/KSP/MMcache.zip

[OhioBob]

38 minutes ago, Sigma88 said:

also, I found out what was going wrong with your install, you have 

dayLengthMultiplier = 1.66666666666667

and that 7 is what is destroying stuff

I think I will add a parameter to round year and day values to the nearest second

Ah, that makes sense.  Rounding off to the nearest second sounds like a reasonable solution.  That tiny bit of rounding could cause things to get a little bit out of sync, but insignificant for the time periods we're liking dealing with.  (And in my case, the rounded off value is really the value I want.)

Must dayLengthMultiplier be a number, or can it be an operation, e.g. dayLengthMultiplier = 5/3 ?
 

Edited May 29, 2017 by OhioBob

[Sigma88]

11 minutes ago, OhioBob said:

Ah, that makes sense.  Rounding off to the nearest second sounds like a reasonable solution.  That tiny bit of rounding could cause things to get a little bit out of sync, but insignificant for the time periods we're liking dealing with.  (And in my case, the rounded off value is really the value I want.)

Must dayLengthMultiplier be a number, or can it be an operation, e.g. dayLengthMultiplier = 5/3 ?
 

no, it must be a number...

stupid hands with 5 fingers, if we had 6 all these issues would not sussist

[OHara]

The code in Kopernicus used a round-to-nearest on the ratio of total-years-to-date-length / day-length, but here you round down.  That matters more now that you have an option to show the year change at the nearest whole day.  Someone other than OhioBob will likely have more than a one-second error, such as a year 99.999 days long, and the 100th day will be in year-2 because a few seconds wouldn't fit into year 1.

Also, both values of 'useLeapYears' use a variable number of days between the first of one year, and the first of the next, so one might think both cases use leap years.  I can't think of a better name than 'yearMayChangeDuringDay'

For the new option to change year-number on a day-boundary, I would like the mod more if you choose the closest day-boundary: 

Spoiler

/*
 yearMayChangeDuringDay: 
 if true change the year-number at the moment of the astronomical year-change, numbering the part of the transition day in the new year as day-0 if the portion is less than half a day;
 if false, change the year-number at the nearest whole day to the astronomical year.

 variableOrFractionalDaysPerYear:
 if true compute leap days;
 if false use an fixed whole nubmer of days per year and let the calendar drift from the astronomical year
*/

double daysPerYear = variableOrFractionalDaysPerYear ?
                      year.value / day.value :
                      Math.Round(year.value / day.value);

int daysSinceEpoch = Math.Floor(time / day.value);

// zero-based year- and day-numbers
int year = yearMayChangeDuringDay ?
            Math.Floor(time / year.value) :
            Math.Floor((daysSinceEpoch +0.5) / daysPerYear);

int firstOfYear = Math.Round(year * daysPerYear);

int day = daysSinceEpoch - firstOfYear;

double left = time - daysSinceEpoch * day.value;

 

 

[Sigma88]

1 hour ago, OHara said:

The code in Kopernicus used a round-to-nearest on the ratio of total-years-to-date-length / day-length, but here you round down.  That matters more now that you have an option to show the year change at the nearest whole day.  Someone other than OhioBob will likely have more than a one-second error, such as a year 99.999 days long, and the 100th day will be in year-2 because a few seconds wouldn't fit into year 1.

Also, both values of 'useLeapYears' use a variable number of days between the first of one year, and the first of the next, so one might think both cases use leap years.  I can't think of a better name than 'yearMayChangeDuringDay'

For the new option to change year-number on a day-boundary, I would like the mod more if you choose the closest day-boundary: 

  Hide contents

/*
 yearMayChangeDuringDay: 
 if true change the year-number at the moment of the astronomical year-change, numbering the part of the transition day in the new year as day-0 if the portion is less than half a day;
 if false, change the year-number at the nearest whole day to the astronomical year.

 variableOrFractionalDaysPerYear:
 if true compute leap days;
 if false use an fixed whole nubmer of days per year and let the calendar drift from the astronomical year
*/

double daysPerYear = variableOrFractionalDaysPerYear ?
                      year.value / day.value :
                      Math.Round(year.value / day.value);

int daysSinceEpoch = Math.Floor(time / day.value);

// zero-based year- and day-numbers
int year = yearMayChangeDuringDay ?
            Math.Floor(time / year.value) :
            Math.Floor((daysSinceEpoch +0.5) / daysPerYear);

int firstOfYear = Math.Round(year * daysPerYear);

int day = daysSinceEpoch - firstOfYear;

double left = time - daysSinceEpoch * day.value;

 

 

In the option used by ohiobob the year is not supposed to end on a day boundary. Usually a year starts with day = 0 (later offset to show day1)

When the last day of the year ends, the left over time is displayed as next year's "day -1" (later offset to 0)

The code had a couple of errors that I've now fixed in the dev version (probably copy paste errors since some line didn't make any sense)

Math.Floor is used to make the code work with both positive and negative values of time

I'm still testing to make sure everything works fine but all tests I made are promising.

The problem here wasn't the error in the number but the fact that the number was supposed to be different.

If the error is bigger it means it is either introduced on purpose (eg. 365.25 days in a year) or it's just bad config syntax

A bigger error would also give more consistent results as there would be no issues of time lost to rounding errors.

[Sigma88]

I've released a new version of Kronometer (v1.3.0-2)

it contains a fix to an error in calculation for non-leap-dates and I've added a true/false option to force time unit values to be integers

 

see the OP for links, and the github page for downloads and readme

[Gordon Dry]

A little brainfart:

GameData\zFinal\zzz_Kronometer.cfg

@Kronometer:NEEDS[Kronometer,!RSPO,!RealSolarSystem,!StockalikeSolarSystem]
{
	%useLeapYears = true
	%useHomeYear = true
	%useHomeDay = true
	%resetMonthsAfterYears = 4
	%resetMonthNumAfterMonths = 12
	!CustomTime,* {}
	!DisplayDate,* {}
	!Months,* {}
	CustomTime
	{
		Year
		{
			roundToNearestInt = True
		}
		Day
		{
			roundToNearestInt = True
		}
	}
	DisplayDate
	{
		PrintDate
		{
			offsetTime = 0
			offsetYear = 1951
			displayDate = <D><Dth> <Mo0>, <Y>
			displayTime = < - <H:00>:<M:00>
			displaySeconds = :<S:00>
		}
		PrintDateNew
		{
			offsetTime = 0
			offsetYear = 1951
			displayDate = <D><Dth> <Mo0>, <Y>
			displayTime = < - <H:00>:<M:00>
			displaySeconds = :<S:00>
		}
		PrintDateCompact
		{
			offsetTime = 0
			offsetYear = 1951
			displayDate = <D><Dth> <Mo0>, <Y>
			displayTime = < - <H:00>:<M:00>
			displaySeconds = :<S:00>
		}
	}
	Months
	{
		Month
		{
			name = January
			symbol = Jan
			days = 31
		}
		Month
		{
			name = February
			symbol = Feb
			days = 28
		}
		Month
		{
			name = March
			symbol = Mar
			days = 31
		}
		Month
		{
			name = April
			symbol = Apr
			days = 30
		}
		Month
		{
			name = May
			symbol = May
			days = 31
		}
		Month
		{
			name = June
			symbol = Jun
			days = 30
		}
		Month
		{
			name = July
			symbol = Jul
			days = 31
		}
		Month
		{
			name = August
			symbol = Aug
			days = 31
		}
		Month
		{
			name = September
			symbol = Sep
			days = 30
		}
		Month
		{
			name = October
			symbol = Oct
			days = 31
		}
		Month
		{
			name = November
			symbol = Nov
			days = 30
		}
		Month
		{
			name = December
			symbol = Dec
			days = 31
		}
		Month
		{
			name = January
			symbol = Jan
			days = 31
		}
		Month
		{
			name = February
			symbol = Feb
			days = 28
		}
		Month
		{
			name = March
			symbol = Mar
			days = 31
		}
		Month
		{
			name = April
			symbol = Apr
			days = 30
		}
		Month
		{
			name = May
			symbol = May
			days = 31
		}
		Month
		{
			name = June
			symbol = Jun
			days = 30
		}
		Month
		{
			name = July
			symbol = Jul
			days = 31
		}
		Month
		{
			name = August
			symbol = Aug
			days = 31
		}
		Month
		{
			name = September
			symbol = Sep
			days = 30
		}
		Month
		{
			name = October
			symbol = Oct
			days = 31
		}
		Month
		{
			name = November
			symbol = Nov
			days = 30
		}
		Month
		{
			name = December
			symbol = Dec
			days = 31
		}
		Month
		{
			name = January
			symbol = Jan
			days = 31
		}
		Month
		{
			name = February
			symbol = Feb
			days = 28
		}
		Month
		{
			name = March
			symbol = Mar
			days = 31
		}
		Month
		{
			name = April
			symbol = Apr
			days = 30
		}
		Month
		{
			name = May
			symbol = May
			days = 31
		}
		Month
		{
			name = June
			symbol = Jun
			days = 30
		}
		Month
		{
			name = July
			symbol = Jul
			days = 31
		}
		Month
		{
			name = August
			symbol = Aug
			days = 31
		}
		Month
		{
			name = September
			symbol = Sep
			days = 30
		}
		Month
		{
			name = October
			symbol = Oct
			days = 31
		}
		Month
		{
			name = November
			symbol = Nov
			days = 30
		}
		Month
		{
			name = December
			symbol = Dec
			days = 31
		}
		Month
		{
			name = January
			symbol = Jan
			days = 31
		}
		Month
		{
			name = February
			symbol = Feb
			days = 29
		}
		Month
		{
			name = March
			symbol = Mar
			days = 31
		}
		Month
		{
			name = April
			symbol = Apr
			days = 30
		}
		Month
		{
			name = May
			symbol = May
			days = 31
		}
		Month
		{
			name = June
			symbol = Jun
			days = 30
		}
		Month
		{
			name = July
			symbol = Jul
			days = 31
		}
		Month
		{
			name = August
			symbol = Aug
			days = 31
		}
		Month
		{
			name = September
			symbol = Sep
			days = 30
		}
		Month
		{
			name = October
			symbol = Oct
			days = 31
		}
		Month
		{
			name = November
			symbol = Nov
			days = 30
		}
		Month
		{
			name = December
			symbol = Dec
			days = 31
		}
	}
}

I use this without issues, also Editor Time from

works well.

[The-Doctor]

Is this recommended for Galileo's?

[TheRagingIrishman]

15 minutes ago, The-Doctor said:

Is this recommended for Galileo's?

If you're rescaling then yes, if not then no

[OhioBob]

@Sigma88, it appears Kronometer isn't working with version 1.3.1.  I've got GPP installed with Galileo's 2.5x SD config, which should give me 10-hour days, but I'm getting 6-hours days in the game.  If you need logs I'll provide them.

[Sigma88]

2 minutes ago, OhioBob said:

@Sigma88, it appears Kronometer isn't working with version 1.3.1.  I've got GPP installed with Galileo's 2.5x SD config, which should give me 10-hour days, but I'm getting 6-hours days in the game.  If you need logs I'll provide them.

I'll take a look as soon as I have some time

[Sigma88]

Updated to KSP v1.3.1

 

Enjoy

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

 

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

@Thomas P. 

@Sigma88  

 

 

Syntax

Kronometer Syntax at Github

 

[klgraham1013]

2 hours ago, Sigma88 said:

Updated to KSP v1.3.1

Been waiting for this.  Thanks a bucket load.

[Tyko]

21 hours ago, Sigma88 said:

Updated to KSP v1.3.1

 

Thanks! Is there any way on your end to enable compatibility with KAC and TWP? Those two don't seem to sync with Kronometer and it's a thorn in the side when you don't have Y/D/H matching between various UI elements.

Thanks!

[Sigma88]

50 minutes ago, Tyko said:

Thanks! Is there any way on your end to enable compatibility with KAC and TWP? Those two don't seem to sync with Kronometer and it's a thorn in the side when you don't have Y/D/H matching between various UI elements.

Thanks!

if I recall correctly Kronometer changes the stock variables that are available to all mods, as long as those mods use the proper variables they should work even with kronometer installed

[Tyko]

40 minutes ago, Sigma88 said:

if I recall correctly Kronometer changes the stock variables that are available to all mods, as long as those mods use the proper variables they should work even with kronometer installed

Hmmm..It hasn't in the past. I'll give it another try tonight. Thanks for the reply!