max number of year?

[Pecan]

wow thats bizzare. why not store seconds, minutes, hours, days, months, and years all separately?

store right now for example as:

25s; 44m; 12h; 11d; 6mn; 2014y

seconds/minutes roll back to zero every 60 units, hours roll over every 24, days are coded so the roll over depends on the value of the months, and leap days in february are added based on the value of the year(since it happens every 4 years consistently)

Because that would need more storage and more processing to accumulate. Yes, only an extra few bytes, yes only a simple "if seconds >= 60" condition, yes all those 'trivial' things add up and end-up making a programme much, much more complicated. Sooner or later in designing a system you have to set a limit somewhere. Imagine almost any single function in any game or other programme you use. It consists entirely of trivial statements and conditions that generally manipulate quite small amounts of data. Then look at the MegaBytes that a programme takes on disc. Think of the number of people whose KSP crashes because it hits the 4GB limit of 32-bit Windows. Programming isn't complicated - computers are too stupid to do complicated things - but it can be very, very complex ^^.

As a different example - why not just put extra solar panels, batteries, RTGs, spare antennae and multiple-redundancy parachutes, legs, powered-landing ability, etc. on your orbiter? The answer, of course, is because it has a huge knock-on effect for the complete launch mass, part count, handling and everything else.

[KvickFlygarn87]

how is a time-counter linked to memory? why cant it just go to year 234?

Look.

The time counter is stored internally as an "int" (coder language for integer). One int is worth 2^32 or 4 bytes (one byte is 8 bits). Therefore, things go out of whack when they pass that limit. Or, at least in this case. In normal cases it rolls back to the negative limit. However, time can't be negative. Therefore, bugs.

[The Jedi Master]

So basically, Year 233 is the Y2K of the KSP universe.

[KvickFlygarn87]

So basically, Year 233 is the Y2K of the KSP universe.

Eh. That's one way to put it, but it doesn't really have to do with the cause of Y2K

[Mitchz95]

What will happen depends to where is used the value. Here in KSP I think that the time is used for moving planets and ships. So bad things will happen to them (planets going in crazy directions, ships being eaten by the Long Time Kraken).

That would be amazing to see. Might even be worth the 6h wait.

[theend3r]

I'm at 98 years with my regular save I've kept since 0.19 and I don't really play that much, so it definitely is possible to reach that limit. On the other hand I don't think it's nescessary to do anything about it even if it did break the game (unless, of course, Squad incorporates an easter egg where a huge meteorite hits Kerbin and you get game over, that'd be awesome ).

Possible solution would be to use dynamic variables but it would just make things needlessly complicated.

Edited June 11, 2014 by theend3r

[cantab]

Look.

The time counter is stored internally as an "int" (coder language for integer). One int is worth 2^32 or 4 bytes (one byte is 8 bits). Therefore, things go out of whack when they pass that limit. Or, at least in this case. In normal cases it rolls back to the negative limit. However, time can't be negative. Therefore, bugs.

The current time or "UT" is not stored as an integer number of seconds. Just look in the save file:

FLIGHTSTATE
        {
                version = 0.23.5
                UT = 850423999.083749
                activeVessel = 0

It's also evident that the game needs to store the UT with a resolution finer than whole seconds, in order to run the physics calculations. Even the on-rails physics updates more than once a second.

I suspect SkyRender had it right early on - that some part of the code handling displaying the current date casts the UT to an integer, meaning the integer overflow will break the displays but not the physics.

Assuming the UT is stored as a floating point, I would expect issues to arise when the precision of the floating point became equal to the gap between physics frames. Say that time's 1/100 of a second, then if UT is a double precision float issues will start to arise around 10¹⁴ seconds, or a few million years. (Were it single precision, we'd be in trouble in a couple of days, so it can't be that.)

So, we should be safe.

PS: No need to timewarp to experiment with this - one can simply edit the save.

[Pecan]

So basically, Year 233 is the Y2K of the KSP universe.

Like I said on page one :-)

http://forum.kerbalspaceprogram.com/threads/82739-max-number-of-year?p=1207811&viewfull=1#post1207811

Exactly so - it is how much memory and processing you decide to dedicate to that issue - also like the millenium bug ... it isn't a bug and in practice it probabaly isn't a problem, so everyone should relax a bit.

[samstarman5]

(unless, of course, Squad incorporates an easter egg where a huge meteorite hits Kerbin and you get game over, that'd be awesome )

That would definitely provide for an endgame, to where you would want to have established self-sustaining colonies on Duna, Eve, and Laythe by the year 233. Eve and Laythe requiring certain...high tolerances for kerbals to be able to survive on those worlds.

But as I have determined so far with my careers, 233 years is a long time to have during a career or sandbox span. A lot can be accomplished alone in the time it would take for a mission to reach Jool. Can easily retrieve a couple of asteroids, visit Duna and Eve and their moons and return(possibly even Moho and Dres), and make a solar mission as well for some science.

[problemecium]

My findings with HyperEdit suggest that nothing bad will happen. KSP will continue running under the impression that the current time is, as in the Y2038 bug, before Day 1, but ships will remain in their orbits and since the times predicted for encounters and other nodes are A: procedural and B: relative to the current time, they will still function normally.

However, ships in "negative" time, or at a date prior to that of launch, may be unable to turn on their SAS due to an input lock (I had this happen once).

EDIT: by "my findings" I mean that I've edited the UT before and seen what happens when you go back before the launch date. I haven't specifically tested Year 234, but I intend to when I have a chance.

Edited June 12, 2014 by parameciumkid

[JordanL]

Well... I didn't know about this and I'm up to about year 200 because I set up a station to generate antimatter for KSPI.

Hmmmm.

[guitarxe]

This all assumes that time is stored as an integer... is that confirmed? It could be double or even a float.

[Thomassino]

So that's why on extremely elongated and eccentric orbits around the sun time to apoapsis doesn't want to change...

[yorshee]

I started up a new career save today, I'm going to see if I can get it to go on for more than 234 years.

[theend3r]

I've gotten to year 144 (I had one save from 0.21 to 0.23.5) in one campaign so reaching 234 is definitely possible but so rare that it doesn't matter at all.

[ClF3]

So basically, Year 233 is the Y2K of the KSP universe.

Actually more like the year 2038 of the KSP universe (somewhere in 2038 the unix time stamp runs out of positions - the number of seconds since 1970-01-01)

[Spartwo]

Glad the furthest I've gotten is 82 *begins grumbling about save breaking updates*

[guitarxe]

Actually more like the year 2038 of the KSP universe (somewhere in 2038 the unix time stamp runs out of positions - the number of seconds since 1970-01-01)

Linus ಠ_ಠ

[TheMoonRover]

Once you pass 233 years, the display shows -233 years (and however many days, hours, minutes and seconds it is) and freezes, and orbits continue as expected IIRC. I think it's 64 years using earth time, again IIRC. What it shows in the save file I don't know.

^That's what you find out when you start messing about with time warp rate altering mods.

[LordFerret]

Well, there is a way to check this ..........

... any volunteers? lol

[FancyMouse]

I remember when I had a Sun-escaping trajectory it also stopped showing curve beyond year 233.

[samstarman5]

how is a time-counter linked to memory? why cant it just go to year 234?

https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs#Year_2042

It's all about what the computers can do, and what is initially programmed into the code. Reading up on those might help you get an idea.

[SAI Peregrinus]

Technically if you didn't care at all about performance you could store the time in a BIGNUM of some sort. Since the time is used every frame the game wouldn't so much run as limp slowly along like a leper on a field of caltrops, but it could keep counting until you ran out of memory.

[Xyphos]

wow thats bizzare. why not store seconds, minutes, hours, days, months, and years all separately?

store right now for example as:

25s; 44m; 12h; 11d; 6mn; 2014y

seconds/minutes roll back to zero every 60 units, hours roll over every 24, days are coded so the roll over depends on the value of the months, and leap days in february are added based on the value of the year(since it happens every 4 years consistently)

that's not how it works.

electronic devices only operate through sequences of on/off switches, these switches are known as "bits".

a bit is just a switch, and it is the smallest piece of information possible to store in memory, it represents true/false, yes/no, on/off, etc.

a series of bits is often represented in Binary Notation in which the "off" bits are represented as zero "0" and the "on" bits are represented as one "1"

a sequence of 8 bits is called a "byte" - 8 bits was established as a standard back when computing first started and memory was very expensive to produce, by using 8 bits instead of 10, manufacturing costs could be reduced without sacrificing too much functionality.

a single byte can contain up to 256 unique bit patterns, each pattern represents a number; for example, using only 3 bits, we can have 8 unique bit patterns:

0 = 000

1 = 001

2 = 010

3 = 011

4 = 100

5 = 101

6 = 110

7 = 111

I'll stop there because I won't list all 256 patterns but you'll notice that every time a bit is "flipped" back to zero, it's neighbor gets "flipped" also. because of this, each bit is a direct exponent of two.

0 bits = 1 pattern; NULL / NOTHING

1 bit = 2 patterns; on/off itself

2 bits = 4 patterns

3 bits = 8 patterns

4 bits = 16 patterns

5 bits = 32 patterns

6 bits = 64 patterns

7 bits = 128 patterns

8 bits = 256 patterns

9 bits = 512 patterns

--- and so on, and so fourth ---

16 bits = 65,536 patterns (known as 64k)

32 bits = 4.7 BILLION patterns

64 bits = 16.2 QUINTILLION patterns (that's 5 times 1000 times 1 million, [plus a few quadrillion more...])

in the early 1970's, computers were only 8 bits as a standard limitation for programming, as the need back then rarely ever exceeded those limitations.

1980's adopted a 16 bit standard, as memory costs started to wane and home computing started to take off.

the late 1990's adopted 32 bits as a standard, which is what KSP still uses today. - IDK y KSP is still using 20-year old technology but requires a recently-designed computer to run, makes no sense.

in the late 2000's, 64 bits were adopted as a standard, and is still a standard we use today. (come on squad, get with the times!)

it wasn't until recently, when technology advanced so much that the cost of memory significantly dropped to less than 10 cents per gigabyte.

back in the 1970's, a single MEGAbyte would easily run in excess of $10'000

and so, in conclusion, memory=money and due to the fact that KSP is 32-bit and 32-bits have a 4.7 billion pattern limit, that's exactly how many Kerbal-Seconds you have of playtime, which computes to about 233 Kerbal years. after that, everything gets flipped back to zero, and unexpected results are likely to occur. worst-case scenario, loading the file causes KSP to crash, making your game save unplayable.

if KSP ever goes fully 64 bit, AS IT SHOULD that limit too, will be multiplied by an exponent of two, which is roughly 54'289 Kerbal years.

also, to touch on the 2038 "problem" - it wouldn't be a problem if a new epoch was started in 2030, and use a single bit to note which epoch the system uses, until all systems have moved away from the 1970 epoch, but I expect that by 2038, home computers will be using 512 bit standards, so the problem will become moot either way.

Edited July 27, 2015 by Xyphos

[Cydonian Monk]

if KSP ever goes fully 64 bit, AS IT SHOULD that limit too, will be multiplied by an exponent of two, which is roughly 54'289 Kerbal years.

That's not how it works. The precision of your variables doesn't automatically increase because you're targeting a platform with a 64-bit address range instead of a 32-bit address range. If you're specifically using a 64-bit or 32-bit int, it'll still have the same level of precision on a 64-bit or a 32-bit compile.