Jump to content

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


Sigma88

Recommended Posts

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

Link to comment
Share on other sites

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 by OhioBob
Link to comment
Share on other sites

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 by Sigma88
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

23 minutes ago, Sigma88 said:

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

This works like a charm. :D

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.

Link to comment
Share on other sites

3 minutes ago, OhioBob said:

This works like a charm. :D

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 by Sigma88
Link to comment
Share on other sites

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
		}
	}
}

 

 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by OhioBob
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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;

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 1 month later...

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.

Link to comment
Share on other sites

  • 4 weeks later...
  • 1 month later...
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 :)

Link to comment
Share on other sites

  • 3 weeks later...

Updated to KSP v1.3.1

 

Enjoy

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

 

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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!

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...