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

[JadeOfMaar]

42 minutes ago, Yakvi said:

From what I understand, SCANSat operates the best at "Ideal" altitude. If you right-click the instrument, it says if it's "sub-optimal", "Ideal" or "too high!" (it stops working when too high). Still, interesting info, thanks!

In addition, there is an FOV penalty when sub-optimal. The scanning width is reduced.

Spoiler

From this old image (still on the SpaceDock page) it looks like 1/3.

 

[ThreePounds]

14 minutes ago, JadeOfMaar said:

In addition, there is an FOV penalty when sub-optimal. The scanning width is reduced.

  Reveal hidden contents

From this old image (still on the SpaceDock page) it looks like 1/3.

 

Well that's explained in the new documentation. It's a linear panelty so half the minimum altitude, half the FOV.

While I couldn't find a formula of determine what exactly FOV does, I found out that it scales with the home world size. So if you have a rescale mod installed, my above table won't be true anymore. The angles are basically normalized.

Spoiler

What does the "field of view" mean?

When a sensor is at or above its "best" altitude (but below its maximum altitude) the field of view is half of the width of the swath mapped by the instrument, if it were in orbit around Kerbin. In other words, a field of view of 5° would map swathes which are 1/36th (10°) of the planetary surface wide. The field of view is scaled for smaller bodies so that more of the surface is covered

 

Edited September 13, 2017 by Three_Pounds

[Tyko]

How do I remove Grannus?

I tried changing Grannus.cfg to Grannus.txt. This got rid of Grannus but also caused the terrain on Gael to disappear - Gael was a black sphere with white clouds passing over it. Not sure why removing Grannus would have that effect.

[Galileo]

3 minutes ago, Tyko said:

How do I remove Grannus?

I tried changing Grannus.cfg to Grannus.txt. This got rid of Grannus but also caused the terrain on Gael to disappear - Gael was a black sphere with white clouds passing over it. Not sure why removing Grannus would have that effect.

Because you need to remove it everywhere, not just the Grannus cfg.

[Tyko]

35 minutes ago, Galileo said:

Because you need to remove it everywhere, not just the Grannus cfg.

Thanks...where else are changes necessary? I have a mission with 2/3 of it's solar panels pointed towards Grannus and not producing any power  

EDIT: Started nuking references to Grannus and finally hit the right one. Here are all the things I changed:

• GPP_Planets/Grannus.cfg - changed to Grannus.txt
• GPP_Configs/SunCurve.cfg - commented out Grannus portion
• GPP_Configs/GPP_PlanetShine.cfg - commented out Grannus portion
• GPP_Scatterer/Sunflares/Grannus/Grannus.cfg - changed to Grannus.txt

 

Edited September 13, 2017 by Tyko

[Frameshift]

Thanks everyone for the input regarding the bases and stations contract pack, I went looking into a config file and found a reference to Kerbin, changed it to Gael and got an orbital station mission within a play session.  All good now.

[ThreePounds]

@JadeOfMaar @Yakvi Okay, rummaging through the code I found the answer. Here is what SCANSat does to determine the swath width:

It takes the radius of the planet to be scanned and compares it to the home world planet (Kerbin, Gael, Earth ..). If the radius is the greater or equal, the swath width is 2 * fov. If the radius is smaller, it's 2 * sqrt ( homeworld radius / radius) * fov. However, if that's more than 40°, it's set to 40°.

Using this information it's now possible to predict how wide the swaths are and I can once again use my Excel table to find orbits with periods that are just the right fraction from the central body rotational period to make the swathes appear side by side to perfectly cover the surface in the shortest time possible. I guess the 2° error in my measurements were due to the fact that Kerbin / Gael rotated under my sensor, which gave me an extra bit of coverage I wasn't expecting. Also,  the scan is 720px wide meaning that the maximum resolution is 0.5°.

Here is the relevant piece of code for it:

Spoiler

private double getFOV(SCANvessel v, CelestialBody b, out Color c)
		{
			c = palette.xkcd_DarkGreenAlpha;
			double maxFOV = 0;
			double alt = v.vessel.altitude;
			double soi_radius = b.sphereOfInfluence - b.Radius;
			double surfscale = Planetarium.fetch.Home.Radius / b.Radius;
			if (surfscale < 1)
				surfscale = 1;
			surfscale = Math.Sqrt(surfscale);

			for (int j = v.sensors.Count - 1; j >= 0; j--)
			{
				SCANsensor s = v.sensors.At(j);

				if (alt < s.min_alt)
					continue;
				if (alt > Math.Min(s.max_alt, soi_radius))
					continue;

				double fov = s.fov;
				double ba = Math.Min(s.best_alt, soi_radius);
				if (alt < ba)
				{
					fov = (alt / ba) * fov;
				}

				fov *= surfscale;
				if (fov > 20)
					fov = 20;

				if (fov > maxFOV)
					maxFOV = fov;
			}

			return maxFOV;
		}

 

 

[Yakvi]

3 hours ago, Three_Pounds said:

@JadeOfMaar @Yakvi Okay, rummaging through the code I found the answer. Here is what SCANSat does to determine the swath width:

It takes the radius of the planet to be scanned and compares it to the home world planet (Kerbin, Gael, Earth ..). If the radius is the greater or equal, the swath width is 2 * fov. If the radius is smaller, it's 2 * sqrt ( homeworld radius / radius) * fov. However, if that's more than 40°, it's set to 40°.

Using this information it's now possible to predict how wide the swaths are and I can once again use my Excel table to find orbits with periods that are just the right fraction from the central body rotational period to make the swathes appear side by side to perfectly cover the surface in the shortest time possible. I guess the 2° error in my measurements were due to the fact that Kerbin / Gael rotated under my sensor, which gave me an extra bit of coverage I wasn't expecting. Also,  the scan is 720px wide meaning that the maximum resolution is 0.5°.

Here is the relevant piece of code for it:

  Reveal hidden contents

private double getFOV(SCANvessel v, CelestialBody b, out Color c)
		{
			c = palette.xkcd_DarkGreenAlpha;
			double maxFOV = 0;
			double alt = v.vessel.altitude;
			double soi_radius = b.sphereOfInfluence - b.Radius;
			double surfscale = Planetarium.fetch.Home.Radius / b.Radius;
			if (surfscale < 1)
				surfscale = 1;
			surfscale = Math.Sqrt(surfscale);

			for (int j = v.sensors.Count - 1; j >= 0; j--)
			{
				SCANsensor s = v.sensors.At(j);

				if (alt < s.min_alt)
					continue;
				if (alt > Math.Min(s.max_alt, soi_radius))
					continue;

				double fov = s.fov;
				double ba = Math.Min(s.best_alt, soi_radius);
				if (alt < ba)
				{
					fov = (alt / ba) * fov;
				}

				fov *= surfscale;
				if (fov > 20)
					fov = 20;

				if (fov > maxFOV)
					maxFOV = fov;
			}

			return maxFOV;
		}

 

 

That's really cool! I've also found a wiki for SCANSat. One thing which I wasn't aware of is that the mod allows you to predict the coverage you'll be making of a body thanks to the small dots in the middle of the "Big map". It simulates the next 100 orbits and provides you a handy overview:

 

 

[KAL 9000]

INFERNUM III COMPUTER LOGS: THALIA APPROACH: 

Switching mission phase (Interplanetary Cruise -> Thalia Approach)... 

Gathering high-orbit Thalia science... 100%

Transmitting science... 100% 

Science.AutoCollect("enable","newBiome")

Science.AutoTransmit("enable","newData")

Entering hibernation (WakeUp: WhenSituation == InThaliaLowOrbit)... 

Exiting hibernation... 

Rebooting... 100% 

Gathering low-orbit Thalia science... 100% 

Transmitting science... 100% 

Science.AutoCollect("enable","newBiome")

Science.AutoTransmit("enable","newData")

Periapsis in 1 hours, 32 minutes, 4 seconds 

WARNING! Overheating detected in subsections 5, 8, and 13! 

WARNING! Severe radiation detected in all subsections! 

WARNING! Overheating in subsections 5, 8, and 13 is now severe!

WARNING! Overheating detected in all subsections! 

WARNING! Subsection 7 failure! 

DamageAssess: Subsection 7 failure due to radiation damage 

WARNING! Subsections 5, 8, and 13 failure! 

DamageAssess: Subsection 5, 8, and 13 failure due to thermal damage 

WARNING! Severe overheating detected in all subsections! 

WARNING! Structural integrity at 50% and dropping! 

WARNING! Subsections 1-20 offline! 

WARNING! Severe damage detected to control computer! 

WARNING! Control computer fail438hfwpahjajüsjaęasja;as20r290puhdja 

ERROR! ERROR! ERROR! 

SIGNAL LOST

[Galileo]

^^^^^^^^^^^^

[Galileo]

On 9/13/2017 at 8:33 AM, linuxgurugamer said:

@Galileo

You need to fix the netkan:

Add the line which says it provides the loadingscreenmanager

and another line which says it conflicts with the loadingscreenmanager

Actually, you shouldn't install loadingscreenmanager, it should make it a dependency, and then add an extra file with the configs.  I have to go to work, but I'll see if I can get you some info on that, but check the LSM thread for details

 

Ummm, I have no idea, I just installed GPP with CKAN, and it recommended OPM as well

EDIT: Saw your post on GitHub

Edited September 14, 2017 by Galileo

[Chimer4]

Hi @Galileo Just started a new career now once I saw that this had been updated and i'm enjoying it so far, although the volcano seems to be much harder to land on now  

1 small typo I noticed doing my early science grind, the entry for crew report whilst flying low over the highlands appears to be missing a "from" in the part about "...sheep fleeing from a large group..."

Thank you for your (and everyone elses) hard work on this mod  

 

[Poodmund]

12 minutes ago, Chimer4 said:

Hi @Galileo Just started a new career now once I saw that this had been updated and i'm enjoying it so far, although the volcano seems to be much harder to land on now  

1 small typo I noticed doing my early science grind, the entry for crew report whilst flying low over the highlands appears to be missing a "from" in the part about "...sheep fleeing from a large group..."

Thank you for your (and everyone elses) hard work on this mod  

 

Lili's Equatorial Ridge biome is also called its Equitorial Ridge too... we English R very good.  

[The-Doctor]

@Galileo what does the advanced settings do?

[Galileo]

13 minutes ago, The-Doctor said:

@Galileo what does the advanced settings do?

It's a terrain detail preset. 

[Poodmund]

1 hour ago, The-Doctor said:

@Galileo what does the advanced settings do?

To expand on Galileo's response, it changes the max LOD/Level of Sub-divisions of the PQS mesh on the bodies, basically giving the mesh more tris as you get closer to the surface. In the settings file instructions you'll see that we are asking you to paste in level values for each body. You can see what we mean by the values of the levels as described in this video by ex-developer Mu:

https://youtu.be/mXTxQko-JH0?t=32m42s

 

[Gilph]

For those looking to build stations and are concerned about the Grannus solar panel issue, may I recommend the excellent NF Solar:

The curved panels on the Hitchhikers up top are the equivalent of a Gigantor, the panels are obvious, and the thin curved 3.5 panels are stacked close together.  I keep my stations in a Normal orientation so I can rendezvous easily, so it is always perpendicular with the solar plane.  No tracking needed..

Edited September 14, 2017 by Gilph
typos

[Norcalplanner]

55 minutes ago, Poodmund said:

To expand on Galileo's response, it changes the max LOD/Level of Sub-divisions of the PQS mesh on the bodies, basically giving the mesh more tris as you get closer to the surface. In the settings file instructions you'll see that we are asking you to paste in level values for each body. You can see what we mean by the values of the levels as described in this video by ex-developer Mu:

https://youtu.be/mXTxQko-JH0?t=32m42s

 

Would I be correct in thinking that this is most valuable in upscaled systems? Because I'm using the highest detail setting in my 2.5x save, and the terrain contours on Iota are freaking fantastic.

[Galileo]

8 minutes ago, Norcalplanner said:

Would I be correct in thinking that this is most valuable in upscaled systems? Because I'm using the highest detail setting in my 2.5x save, and the terrain contours on Iota are freaking fantastic.

Nope, also looks good in stock scale. The advanced settings is the same thing as the stock presets. They are meant for the stock scale but do help in larger scales too. Big difference though, no???  

Edited September 14, 2017 by Galileo

[Norcalplanner]

4 hours ago, Galileo said:

Nope, also looks good in stock scale. The advanced settings is the same thing as the stock presets. They are meant for the stock scale but do help in larger scales too. Big difference though, no???  

Looks great, although my computer is chugging just a wee bit more - not sure if it's due to the high terrain settings or one of the many mods.  I removed a few mods which were throwing errors, and edited the asteroid config file to halve the total number of 'roids the computer has to keep track of.

[Sigma88]

7 hours ago, Gilph said:

For those looking to build stations and are concerned about the Grannus solar panel issue, may I recommend the excellent NF Solar:

The curved panels on the Hitchhikers up top are the equivalent of a Gigantor, the panels are obvious, and the thin curved 3.5 panels are stacked close together.  I keep my stations in a Normal orientation so I can rendezvous easily, so it is always perpendicular with the solar plane.  No tracking needed..

 

a small bit of info for those that might still want to use tracking solar panels:

 

currently there is a "bug" in kopernius where the solar panel at the moment of deciding which star to track, will focus on the star that is more centered in its field of view.

we have already changed it so that from next release the solar panels will choose the star that provides the most Ec/s

in the meantime, it's sufficient to rotate your craft until the solar panels face the closest star (ciro)

 

of course with stations it will be a bit more difficult, but at least you have an option while you wait for the next kopernicus release to drop

[Mattasmack]

On 9/13/2017 at 8:18 PM, Frameshift said:

Thanks everyone for the input regarding the bases and stations contract pack, I went looking into a config file and found a reference to Kerbin, changed it to Gael and got an orbital station mission within a play session.  All good now.

Oh, thanks for mentioning that!  I was a bit confused about why I had so many possible contracts referring to station crews and adding modules and whatnot, but none to put a station up in the first place.  I ran into the same problem with the space telescope contracts in ResearchBodies, I think -- references to Kerbin in the contract cfg files were keeping them from showing up.

[Yakvi]

On 15/09/2017 at 9:24 AM, Sigma88 said:

 

a small bit of info for those that might still want to use tracking solar panels:

 

currently there is a "bug" in kopernius where the solar panel at the moment of deciding which star to track, will focus on the star that is more centered in its field of view.

we have already changed it so that from next release the solar panels will choose the star that provides the most Ec/s

in the meantime, it's sufficient to rotate your craft until the solar panels face the closest star (ciro)

 

of course with stations it will be a bit more difficult, but at least you have an option while you wait for the next kopernicus release to drop

Huh! I KNEW my solar panels were reacting to Ciro when I was rotating my craft towards them, but couldn't find the pattern.

That explains it, thanks a lot for the update!  

[Gilph]

Sorry if this is a dumb question, but is it possible to go the low tech route and maybe have a menu item with a dialog that asks what your preferred star is for solar tracking? You can set when the vessel becomes active. At least until it can be fixed?

[Poodmund]

34 minutes ago, Gilph said:

Sorry if this is a dumb question, but is it possible to go the low tech route and maybe have a menu item with a dialog that asks what your preferred star is for solar tracking? You can set when the vessel becomes active. At least until it can be fixed?

This consideration has been made but this isn't a GPP issue, this is a Kopernicus issue and should be discussed in the appropriate place as such: https://github.com/Kopernicus/Kopernicus/issues/214