[KSP 1.12.1+] Galileo's Planet Pack [v1.6.6] [23 Sept 2021]

[Urses]

56 minutes ago, JadeOfMaar said:

I'm watching a Twitch stream (Dr Doof) right now. The streamer accepted a 3-star Iota rescue contract with the orbit altitude at 4.3km.  

4,3km on Iota is absolutely healthy. The only problem is if you aproach from higher orbit. If you have some crafts on Iota already a Monoprop Hopper is more as enough. Or a Automated loworbit grabber in equatorial.... but if i control this beast i go every time realy dizzy... you see every stone on the surface. But the sight is spectacular!

Funny Kabooms 

Urses 

Edited April 27, 2017 by Urses

[Akira_R]

@Poodmund @New Horizons @Galileo

Regarding using Kopernicus time with rescales.

I have been using a 3.2x game modified to an 11 hour day for a while now, using this the in game clock ticks by with 11 hour days and contracts and maneuvers all use the same 11 hour day, I have not had an issue with KAC's auto generated alarms, they always go off at the right time and I haven't really looked to see if they are counting down by 6 hour days or the new 11 hour days, and I haven't had to input a manual alarm in quite some time sooooo there is that.

However any mod that keeps track of time will stay in the 6 hour day format, this includes KCT, USI-LS, and TAC-LS (I think), and probably things like EPL, NFT, KSPI-E. This is because the game itself and all mods (that I am aware of) keeps track of everything in seconds and for UI purposes simply does some division to display things in the year/month/day/hour/minute format we see. In all the mods that I have come across that handle time this division factor is hard coded and not changeable, I have made some requests to mod authors to allow us the ability to specify a day length in some way in a cfg but have not had any luck so far.

This in no way makes them inaccurate though, the times themselves haven't changed, they are still showing the correct number of seconds until that particular event, you just have to remember that if USI-LS says you have 5 days of life support left it's really saying you have 5 days * 6 hours = 30 hours of life support left. This isn't game breaking in any way, it's simply annoying.

Until more mod authors get on board with either getting their day length factors from Kopernicus directly, or at least have an option in a cfg to make adjustments to it, I would recommend not having any day length changing behavior be the default behavior in GPP rescales because of this potential confusion, I would probably leave them as an additional optional feature along with the rescales with all the appropriate warnings about their use.

[Urses]

44 minutes ago, Akira_R said:

However any mod that keeps track of time will stay in the 6 hour day format, this includes KCT, USI-LS, and TAC-LS (I think), /snip

If i may Insist.

For USI-LS you can Change all stats (ticks) ingame in settings on KSC, you only need to switch all second timers for 6 hours/day with your 11h/days. The bigger Problem is more USI-MKS, for catchup mechaniks you will probably add storage for 11h ciclus.

Funny Kabooms

Urses

Edited April 27, 2017 by Urses

[Akira_R]

4 minutes ago, Urses said:

If i may Insist.

For USI-LS you can Change all stats (ticks) ingame in settings on KSC, you only need to switch all second timers for 6 hours/day with your 11h/days. The bigger Problem is more USI-MKS, for catchup mechaniks you will probably add storage for 11h ciclus.

Funny Kabooms

Urses

You can change the rate at which USI-LS uses resources (which I have done in my game) however the UI will still display the time in 6 hour days, so if I have changed it so that the supplies in a pod will last for 5 of my 11 hour days, the UI shows it has 9 days 1 hour of LS

[Urses]

Just now, Akira_R said:

You can change the rate at which USI-LS uses resources (which I have done in my game) however the UI will still display the time in 6 hour days, so if I have changed it so that the supplies in a pod will last for 5 of my 11 hour days, the UI shows it has 9 days 1 hour of LS

Sorry for misinformation

But as you describe it it looks like the daylenght is hardcoded in USI-Tools.

May be worth a pull request for next USI update?

Urses

[Akira_R]

2 minutes ago, Urses said:

Sorry for misinformation

But as you describe it it looks like the daylenght is hardcoded in USI-Tools.

May be worth a pull request for next USI update?

Urses

I posted a request on the USI-LS forum but I doubt that Rover Dude really paid much attention to it, if i knew the first thing about C# I would definitely make a pull request, however I only know a little bit of C, and that was taught to me over 10 years ago now sooooo......

[Urses]

Just now, Akira_R said:

I posted a request on the USI-LS forum but I doubt that Rover Dude really paid much attention to it, if i knew the first thing about C# I would definitely make a pull request, however I only know a little bit of C, and that was taught to me over 10 years ago now sooooo......

Welcome in "C to old"-Club.

RD would change something on the Time code. The USI year is 1 day to short maybe the UI scalling will be added? And as he upgrade to USI-Team it may be that more eyes see more? Who knows.

Urses

[TheRagingIrishman]

1 hour ago, Urses said:

Welcome in "C to old"-Club.

RD would change something on the Time code. The USI year is 1 day to short maybe the UI scalling will be added? And as he upgrade to USI-Team it may be that more eyes see more? Who knows.

Urses

The 1 day too short is fixed in the next release.

1 hour ago, Akira_R said:

I posted a request on the USI-LS forum but I doubt that Rover Dude really paid much attention to it, if i knew the first thing about C# I would definitely make a pull request, however I only know a little bit of C, and that was taught to me over 10 years ago now sooooo......

Feel free to put something about non-hardcoded year/day lengths up on https://github.com/UmbraSpaceIndustries/USI-LS/issues and I or one of the other people on the USI team will see what we can do.

[MaxL_1023]

Kerbalism is starting to get Kerbal - can't seem to go a week without something breaking down. High quality solar panels having critical failures 3 days after launch - must have been snacking on the job at the factory. 

[wafuru]

15 hours ago, Poodmund said:

PSA: Anyone who is using an upscaled system (and therefore an extended day length due to the day length modifier in the rescale config), how are you experiencing time dependent mods i.e. KAC, Transfer Window Planner, USI-LS, Kerbal Construction Time etc. in your game? Are they working correctly or are the times show in game (game clock time) out of sync with the times listed in any of the mod GUIs?

It would be nice to hear how how mods are interacting with the Kopernicus Clock.

@Poodmund@Akira_R

Signed up just to talk about this. Agree w/ Akira's assessment.

Playing 10x and lately have focused on investigating the time interactions with KAC, KCT, and Monthly Budgets.

• Contracts obey Kopernicus time.
• KAC has its own built-in toggle to switch between Kerbin and Earth time formats. It doesn't care what the Kerbin/Earth time game setting is. There's also some unused code that would allow for a user-defined calendar (but it probably wouldn't work with scaled Kopernicus time anyway, more on that below).
• KCT checks the Kerbin/Earth time setting and adjusts its formatting accordingly.
• Monthly Budgets only operates on 6 hr days.

Small sample size, but it's not too far of a stretch to assume that most mods that deal with time were designed with stock or RSS in mind.

Then the way Kopernicus handles time scaling is also pretty interesting.

Gael's orbit at 10x puts its orbital period at 449.043-ish 18-hour days. Not sure if anyone has noticed already, but Kopernicus tries to reconcile the remaining time by adding a partial day to the end of the year:

• Year 1 day 449 is the last full 18-hour day of that year.
• Calendar continues to year 1 day 450. But day 450 only lasts for 47 minutes.
• 47 minutes into day 450, the year rolls over to 2.

This is why the theoretical KAC custom calendar wouldn't work, it always expects whole days.

Unfortunately there also seems to be an issue with date formatting when years roll over.

Spoiler

When year 1 rolls over, year 2 day 1 immediately starts with 47 minutes already elapsed. The overall effect is that the year start and end days essentially slide to the right by 47 minutes with each passing year. It goes something like this:

1y 450d 0h 47m rolls over to 2y 1d 0h 48m
2y 450d 1h 33m rolls over to 3y 1d 1h 34m
3y 450d 2h 21m rolls over to 4y 1d 2h 22m
...
23y 450d 17h 59m rolls over to 24y 2d 0m
24y 451d 0h 46m rolls over to 25y 2d 47m

Every 23 years the year start day and year end day advance by 1 Gaelian day.

After ~462 years the year start day and year end day would have advanced by 20 days (start day = 20, end day = 470).

So for now I'm going to turn of Kopernicus time and stick with Earth time since it feels close enough and is mentally easier to keep track of.

Edited April 28, 2017 by wafuru
maths

[KerbolExplorer]

I have a windows 8 and ksp doesnt load with this mod

[JadeOfMaar]

14 minutes ago, KerbolExplorer said:

I have a windows 8 and ksp doesnt load with this mod

1. Does your PC have more than 8GB of RAM?
2. Did you follow the install instructions?
3. Can you give a clue as to what's causing or related to your problem?

 

[KerbolExplorer]

2 minutes ago, JadeOfMaar said:

1. Does your PC have more than 8GB of RAM?
2. Did you follow the install instructions?
3. Can you give a clue as to what's causing or related to your problem?

 

Yes and Yes.the problem is that the game needs a lot of time to load but at the main menu it totaly frezz.I dont have idea how scoot have a lot of mods in the galileo series

[JadeOfMaar]

Just now, KerbolExplorer said:

Yes and Yes.the problem is that the game needs a lot of time to load but at the main menu it totaly frezz.I dont have idea how scoot have a lot of mods in the galileo series

If you have a Dropbox or pastebin, copy the contents of KSP\KSP_x64_Data\output_log.txt into that and share it.

There are a lot of people out there with even more mods installed than Scott Manley and they do just fine...

[OhioBob]

22 hours ago, MaxL_1023 said:

At this point there isn't much around Grannus anyways - if planets are ever added around it then the luminosity issue would need to be fixed. 

Sadly I agree.  I already started doing some preliminary work on a Grannus planet pack.  My vision for the system was based entirely on the fact that Grannus is a low luminosity red dwarf.  But if I can't create the planets I want and put them in the orbits that I want to because the solar irradiance is too high, then I don't see much point in continuing.  I'm not going to compromise my vision and settle for something I don't want because of a bug.  I'd rather just shelve the project until somebody figures out a way to fix the problem (though at this point I don't have a lot of confidence it will get fixed).

[Poodmund]

6 hours ago, wafuru said:

*snip*

I'll take a look at this over the weekend.

Edited April 28, 2017 by Poodmund

[CatastrophicFailure]

22 hours ago, Poodmund said:

 

PSA: Anyone who is using an upscaled system (and therefore an extended day length due to the day length modifier in the rescale config), how are you experiencing time dependent mods i.e. KAC, Transfer Window Planner, USI-LS, Kerbal Construction Time etc. in your game? Are they working correctly or are the times show in game (game clock time) out of sync with the times listed in any of the mod GUIs?

It would be nice to hear how how mods are interacting with the Kopernicus Clock.

Edited 22 hours ago by Poodmund

I'm playing at 6.4x scale, can confirm that Kerbal Construction Time is out of synch on days but not hours/minutes. However, I see that @magico13 has an update out that might address this, I'm not completely in the loop on that thread.

[eddiew]

Ok, so I took a long break and did some things I'm not proud of (like played Cities Skylines, Subnautica and Minecraft), but hey, look, I stripped my KSP install back to minimum, then stripped it some more and nuked the whole frikking thing and started again and eventually got rid of the mysterious GPP+scatterer memory leak! Tellumo's rings seem kind of pale, but at least they're there  

Turns out that with just GPP + visual mods, the game "only" uses about 5.6gb of memory to get this far. But I've been slamming extra volts into my ram and I'm hoping it'll get past the 10gb crash limit too  

...I have no idea what weird combination of versions it is that causes memory leakage, but it does seem that the latest of everything plus the special Kopernicus dll linked in the install instructions works - but may need a total wipe of all folders involved. Clearly some hangers on were involved from something.

[magico13]

19 minutes ago, CatastrophicFailure said:

I'm playing at 6.4x scale, can confirm that Kerbal Construction Time is out of synch on days but not hours/minutes. However, I see that @magico13 has an update out that might address this, I'm not completely in the loop on that thread.

Yes, the latest dev build should hopefully (crosses fingers) work correctly. If not, let me know over in the KCT thread or the KCT dev thread and I'll sort it out.

[CatastrophicFailure]

20 minutes ago, magico13 said:

Yes, the latest dev build should hopefully (crosses fingers) work correctly. If not, let me know over in the KCT thread or the KCT dev thread and I'll sort it out.

Awesome.   For the record here, is an update to KCT itself needed or just MagiCore?

[magico13]

2 minutes ago, CatastrophicFailure said:

Awesome.   For the record here, is an update to KCT itself needed or just MagiCore?

Technically just MagiCore, but there was a breaking change a few weeks back that requires a newer KCT version as well. Easier just to grab the latest KCT as it includes the updated MagiCore, but you can always try just updating MagiCore if you really want. It'll break pretty fast if you've got the wrong versions together.

The change I made to MagiCore is to not use a hardcoded 6 hour day or 24 hour day based on the KSP Use Kerbin Time setting, but instead to get the number of seconds per year/day/hour/minute from the KSPUtil.dateTimeFormatter under the assumption that that's how the time was being changed (at least in regards to the UI). If that's not the case then I'll provide a config that lets you set an arbitrary number and I'll have to make another change to MagiCore to accept those settings.

[MaxL_1023]

2 hours ago, OhioBob said:

Sadly I agree.  I already started doing some preliminary work on a Grannus planet pack.  My vision for the system was based entirely on the fact that Grannus is a low luminosity red dwarf.  But if I can't create the planets I want and put them in the orbits that I want to because the solar irradiance is too high, then I don't see much point in continuing.  I'm not going to compromise my vision and settle for something I don't want because of a bug.  I'd rather just shelve the project until somebody figures out a way to fix the problem (though at this point I don't have a lot of confidence it will get fixed).

Why not continue making the planet pack, and if the Grannus bug can't be fixed releasing it as a stand-alone solar system? I would still try it out - I don't think there is a red-dwarf system out there yet. Anyways, I am sure the bug will be fixed eventually. 

[OhioBob]

1 hour ago, MaxL_1023 said:

Why not continue making the planet pack, and if the Grannus bug can't be fixed releasing it as a stand-alone solar system? I would still try it out - I don't think there is a red-dwarf system out there yet. Anyways, I am sure the bug will be fixed eventually. 

I've considered that possibility but still haven't made up my mind.  I have a certain vision of what I want to do with this planet pack (which I'm not ready to disclose) that just gets messed up if it were released as a stand-alone solar system.  If I were to work on a planet pack with the intention of releasing it as stand-alone solar system, I have other ideas that I'd like to explore.  I'd rather save my Grannus ideas until which time the bug gets fixed.

 

Edited April 28, 2017 by OhioBob

[Akira_R]

8 hours ago, wafuru said:

*snip*

Then the way Kopernicus handles time scaling is also pretty interesting.

Gael's orbit at 10x puts its orbital period at 449.043-ish 18-hour days. Not sure if anyone has noticed already, but Kopernicus tries to reconcile the remaining time by adding a partial day to the end of the year:

• Year 1 day 449 is the last full 18-hour day of that year.
• Calendar continues to year 1 day 450. But day 450 only lasts for 47 minutes.
• 47 minutes into day 450, the year rolls over to 2.

This is why the theoretical KAC custom calendar wouldn't work, it always expects whole days.

Unfortunately there also seems to be an issue with date formatting when years roll over.

  Reveal hidden contents

When year 1 rolls over, year 2 day 1 immediately starts with 47 minutes already elapsed. The overall effect is that the year start and end days essentially slide to the right by 47 minutes with each passing year. It goes something like this:

1y 450d 0h 47m rolls over to 2y 1d 0h 48m
2y 450d 1h 33m rolls over to 3y 1d 1h 34m
3y 450d 2h 21m rolls over to 4y 1d 2h 22m
...
23y 450d 17h 59m rolls over to 24y 2d 0m
24y 451d 0h 46m rolls over to 25y 2d 47m

Every 23 years the year start day and year end day advance by 1 Gaelian day.

After ~462 years the year start day and year end day would have advanced by 20 days (start day = 20, end day = 470).

So for now I'm going to turn of Kopernicus time and stick with Earth time since it feels close enough and is mentally easier to keep track of.

I don't really see a problem or potential error here, in fact this makes perfect sense, in the real world we would handle this by forgetting about those last couple minutes and adding an extra day every 23 years so as to keep the calendar in sync with the season. However in KSP this is not much of an issue, sure it may look funky with the year starting on say 2 but at least your day cycle still syncs up with the actual day/night cycle, which to me is the most important thing in this regard.

[OhioBob]

We could tweak Gael's semimajor axis to make the years come out to an exact number of days, if that helps anything.