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

[Norcalplanner]

Ditto here regarding solar.  I'm using the tiniest ones in BDB and they're providing many many times what they should be.  Makes transmitting science easier, though. 

[JadeOfMaar]

Free energy for the masses. Civilization has finally reached the next level.  

[Luovahulluus]

1 hour ago, JadeOfMaar said:

Free energy for the masses. Civilization has finally reached the next level.  

Now all we need to do is find the bug, implement it in real life and profit!

[eddiew]

If anyone has any ideas of why the latest GPP + Scatterer causes me a massive memory leak, I'd be happy to hear them...  

Removing Scatterer solves it, but I don't really want to...

[Galileo]

6 minutes ago, eddiew said:

If anyone has any ideas of why the latest GPP + Scatterer causes me a massive memory leak, I'd be happy to hear them...  

Removing Scatterer solves it, but I don't really want to...

I dunno but I'll bring it up to blackrack and see if he can figure it out. 

[Urses]

21 minutes ago, Galileo said:

I dunno but I'll bring it up to blackrack and see if he can figure it out. 

With scatterer i have some funny artifacts too. If i EVA a Kerbal i see sometimes water animations as if the Kerbal is on Sealevel. It is flickering and mostly need a specific kamera rotation to see this. The funny thing about is it is not permament effect and looks like this will be some memory artifacts. But it could clarify where the memory leack comes from? Like a animation in background wich not belongs there?

Funny Kabooms 

Urses

PS: without scatterer the problem isn't here and i see no expectations in the log. But RAM usage shots up for roughly 10% on a 16GB system.

PPS: i seen this effect on Iota, Ceti and polar over Kerbin(i though at fist i downloaded by acsident a planet on realy low Gael orbit because it looked like mirrowed Gael by proportions but thus was only once)-> if i think back i mean it was somewhere wattery too. 

Edited April 15, 2017 by Urses
PPS

[astroheiko]

@RocketPCGaming Your pictures are also incredibly beautiful.

 

@all

Here is an update of the Tarsiss 6 Expedition.

Tarsiss 6 Expedition Update

A brief summary: landing on Lilli for refueling. Then flown to Gratian, landed and fueled on Geminus. On the way to Otho to land on Jannah.

two random pics

Greetings

Edited April 15, 2017 by astroheiko

[Ed_]

I'm not 100% sure if this has happened since 1.2.2 but there are 0 asteroids anywhere in the system. I did post here previously about issues with asteroids because I'd forgotten to switch them on in the tracking station (because I'm an idiot) but this time I'm positive they're just not there. I removed Research Bodies to no effect, and I tried starting a new game and the same thing happened - no unknown objects anywhere. What have I done this time?!

[MaxL_1023]

Have you upgraded the tracking station? It has to be level 3 before you can see asteroids. I am only saying this because you mentioned starting a new game. 

 

[OhioBob]

Solar Panel bug...

It looks like the solar panel problem may be the recurrence of a bug we found in testing right after we added Grannus.  This problem was fixed in Kopernicus 1.2.2-3, but it may be back in 1.2.2-5.  I'll inquire about it to see if we can get it corrected.  In the meantime, if you want to return the output of solar panels around Ciro back to the normal levels, you need to make a change to the file GPP/Grannus/Grannus.cfg.  Open Grannus.cfg and search for the line that says, luminosity = 42.  Change 42 to 1360 and save.  That should do it.

[CatastrophicFailure]

@JadeOfMaar Did something change with the 1.2.x update regarding the decals? Below is the MM config I was using, but my decals seem to have disappeared? The folder's in the right place.

@PART[sticker]:NEEDS[blackheart]
{
	@title = Place Anywhere Ussari Sticker Type A
	@MODEL 
	{
		@texture = placeholder , Ussari
	}
	
	@MODULE[FStextureSwitch2]
	{
		moduleID = 1
		@nextButtonText = Next Stock Flag
		@prevButtonText = Previous Stock Flag
	}
	
	MODULE
	{
		name = FStextureSwitch2
		moduleID = 2
		showListButton = True
		nextButtonText = Next Ussari Flag
		prevButtonText = Previous Ussari Flag
		statusText = Current in Ussari 
		objectNames = stickerflat;sticker125;sticker250;sticker375
		textureRootFolder = Ussari\
		textureNames = flag3a ; flag3b ; ussari ; 8SQEW2a ; gFJz0JO ; wDrSAaq
		textureDisplayNames = Flag1;Flag2;Flag3;BurntFlag;Texture;Wedge
		debugMode = false
		showInfo = false
	}
}

@PART[stickerv]:NEEDS[blackheart]
{
	@title = Place Anywhere GPP Sticker	Type B
	@MODEL 
	{
		@texture = placeholder , Ussari
	}
	
	@MODULE[FStextureSwitch2]
	{
		moduleID = 1
		@nextButtonText = Next Stock Flag
		@prevButtonText = Previous Stock Flag
	}
	
	MODULE
	{
		name = FStextureSwitch2
		moduleID = 2
		showListButton = True
		nextButtonText = Next Ussari Flag
		prevButtonText = Previous Ussari Flag
		statusText = Current in Ussari 
		objectNames = stickerflat;sticker125;sticker250;sticker375
		textureRootFolder = Ussari\
		textureNames = flag3a ; flag3b ; ussari ; 8SQEW2a ; gFJz0JO ; wDrSAaq
		textureDisplayNames = Flag1;Flag2;Flag3;BurntFlag;Texture;Wedge
		debugMode = false
		showInfo = false
	}
}

@PART[stickermini]:NEEDS[blackheart]
{
	@title = Place Anywhere Mini GPP Sticker
	@MODEL 
	{
		@texture = placeholder , Ussari
	}
	
	@MODULE[FStextureSwitch2]
	{
		moduleID = 1
		@nextButtonText = Next Stock Flag
		@prevButtonText = Previous Stock Flag
	}
	
	MODULE
	{
		name = FStextureSwitch2
		moduleID = 2
		showListButton = True
		nextButtonText = Next Ussari Flag
		prevButtonText = Previous Ussari Flag
		statusText = Current in Ussari
		objectNames = stickerflat;stickerh;stickerv
		textureRootFolder = Ussari\
		textureNames = flag3a ; flag3b ; ussari ; 8SQEW2a ; gFJz0JO ; wDrSAaq
		textureDisplayNames = Flag1;Flag2;Flag3;BurntFlag;Texture;Wedge
		debugMode = false
		showInfo = false
	}
}

 

[JadeOfMaar]

1 hour ago, CatastrophicFailure said:

Did something change with the 1.2.x update regarding the decals

Yes. That patch changed since the structure of the parts' configs changed in v1.3 of the decals mod. There's also accommodation for a new large decal part from v1.2 of the mod.

2 hours ago, OhioBob said:

luminosity = 42

23 hours ago, JadeOfMaar said:

I'm seeing 34 ~ 56x rated EC production.

This may make no sense but if I divide the standard luminosity 1360 by 42, I get 32.38 which I now assume is at the very low end of the range of multiples by which I'm seeing insane EC production. There must some kind of weird overcompensation going on.

[OhioBob]

3 minutes ago, JadeOfMaar said:

This may make no sense but if I divide the standard luminosity 1360 by 42, I get 32.38 which I now assume is at the very low end of the range of multiples by which I'm seeing insane EC production. There must some kind of weird overcompensation going on.

The test that I just ran was using a 3x2 solar panel.  At a distance of 14,000 Mm, I got a power output of 53.9 e/s around Ciro.  Moving to the same orbit around Grannus, I got a power output of 1.665 e/s.  That's exactly the 1360/42 ratio.

The problem is that the power output around Ciro should be 1.665 e/s, and the output around Grannus should be reduced by a factor of 42/1360.  But for some reason it's going the other direction and increasing the power output around Ciro by 1360/42.

[MaxL_1023]

Either way, 42 is the answer to everything.

[Ed_]

16 hours ago, MaxL_1023 said:

Have you upgraded the tracking station? It has to be level 3 before you can see asteroids. I am only saying this because you mentioned starting a new game. 

 

Yes I upgraded everything in the new game just for the purposes of testing, and still no asteroids to be seen!

[MaxL_1023]

There might be some researchbodies related configuration changes still in place - I don't think deleting the mod would undo anything it changes elsewhere. Have you tried re-installing GPP 1.2.2? Your saves will be fine - they are stored in a different location. 

Also, holy crap - it takes more delta-V to reach a slightly inclined, 70,000km x 50,000 km Gael orbit and return than it takes to get into orbit of Iota and back! Damn you Oberth effect!

At least the rescue contract didn't involve an orbit inside the atmosphere!

[OhioBob]

On ‎4‎/‎12‎/‎2017 at 9:09 PM, JadeOfMaar said:

Sorry, dude. There's no known way to scale the asteroids. it's why I've seen people still requesting higher classes than E.

If I knew how to control this floatcurve I could make a field full of only A class, or only E class. That's the best anyone's going to get.  

I think I have an idea of how the size curve works.  I'm not sure what KSP's default curve looks like.  The curve in GPP is:

Size
{
   key = 0 0
   key = 0.3 0.45
   key = 0.7 0.55
   key = 1 1
}

But I've seen this curve posted elsewhere:

sizeCurve
{
   key = 0 0 1.5 1.5
   key = 0.3 0.45 0.875 0.875
   key = 0.7 0.55 0.875 0.875
   key = 1 1 1.5 1.5
}

Assuming the second is the default curve, it looks like this:

Then here we're given the following description:

Quote

Sets size distribution for asteroids

The output range of [0, 1) is divided equally among the classes. So [0, 0.2) is class A, [0.2, 0.4) is class B, ..., [0.8, 1) is class E.

Default curve translates to 12% class A, 13% class B, 49% class C, 13% class D, and 12% class E

Based on the description and the shape of the curve, how I think it works is this...  When a new asteroid is created, a random number between 0 and 1 is generated.  We read the value of this random number on the bottom horizontal axis.  We then follow that number upward until it intersects the curve, then move to the left to read the corresponding number on the on the vertical axis.  The number on the vertical axis gives us the size of the asteroid, with 0 being the smallest size and 1 being the largest size.

For example, a random number of 0.2 is generated.  From this we read a corresponding size number of about 0.33.  An asteroid with a size of 0.33 is probably going to fall somewhere in the class B category.

I agree with you that there is apparently no way to create asteroids smaller or larger than the current minimum and maximum size, but the size distribution is certainly adjustable.  For example, the curve to the bottom left would change the distribution so that there are more small asteroids, the curve to the bottom right would generate more large asteroids.

The curve to the left is,

Size
{
   key = 0 0 0.3 0.3
   key = 0.5 0.25 0.9 0.9
   key = 1 1 2 2
}

and the one to the right is,

Size
{
   key = 0 0 2 2
   key = 0.5 0.75 0.9 0.9
   key = 1 1 0.3 0.3
}

Although the request was for larger asteroids, real life distributions tend to have far greater numbers of the smaller sizes than the larger sizes.  Therefore the curve to the left is probably more realistic, though perhaps less desirable from a game play perspective.

At least this the way I think it works.  I could be wrong.

 

Edited April 16, 2017 by OhioBob

[MaxL_1023]

I wouldn't mind more small asteroids, as long as the class A and B asteroids are large enough to make them worth capturing. Why would you drag a 3 ton asteroid halfway across the solar system, only to mine it dry for 1% of the transfer cost?

[OhioBob]

22 minutes ago, MaxL_1023 said:

I wouldn't mind more small asteroids, as long as the class A and B asteroids are large enough to make them worth capturing. Why would you drag a 3 ton asteroid halfway across the solar system, only to mine it dry for 1% of the transfer cost?

After thinking about it some more, I think I favor a straight line function that produces equal numbers of all classes.  That way you should be able to find plenty of small ones if you prefer small ones, and plenty of large ones if you prefer large ones.  I certainly see no reason why the distribution should be so strongly bias toward class C.

[MaxL_1023]

It could be a Gaussian-type asteroid distribution. 

[astroheiko]

I thought I had to land in the fog. The cloud cover disappeared only 200m before the surface. The pulse is quite high.

Spoiler

My spaceplane for Catullus has arrived and I went to explore the Polar region. Then this picture was created.

By the way. When I see the postings of @OhioBob, I would need hours to create something like that. I'm sure he does it by the way when he reads newspaper in the morning, does not take 5 minutes. A really smart guy - I think.

Edited April 16, 2017 by astroheiko

[OhioBob]

On ‎4‎/‎16‎/‎2017 at 1:44 PM, MaxL_1023 said:

It could be a Gaussian-type asteroid distribution. 

I'm sure that was probably the reasoning behind creating the default curve.  In real life, however, asteroids don't follow that type of distribution.  There are many things in nature where quantity increases exponentially with smaller size.  There are far more ants in the world than elephants, and far more microbes than ants.  We also see this with stars, where low-mass red dwarfs far outnumber the more massive stellar types.  The largest O-type stars are the most rare.
 

Edited April 18, 2017 by OhioBob

[CatastrophicFailure]

17 hours ago, JadeOfMaar said:

Yes. That patch changed since the structure of the parts' configs changed in v1.3 of the decals mod. There's also accommodation for a new large decal part from v1.2 of the mod.

OK, so, what'm I doing wrong here? Using the following MM patch hacked from the GPP patch, getting nothing. /Ussari is a folder off of /Gamedata

@PART[sticker*]:NEEDS[blackheart]
{
	@MODEL 
	{
		@texture = placeholder , Ussari
	}
	
	@MODULE[FStextureSwitch2],2
	{
		@nextButtonText = Next Ussari Flag
		@prevButtonText = Previous Ussari Flag
		@statusText = Current in Ussari
		@textureRootFolder = Ussari\
		@textureNames = flag3a ; flag3b ; ussari ; 8SQEW2a ; gFJz0JO ; wDrSAaq
		@textureDisplayNames = Flag1;Flag2;Flag3;BurntFlag;Texture;Wedge
	}
}

@PART[sticker]:NEEDS[blackheart]
{
	@title = Place Anywhere Ussari Sticker Type A
}

@PART[stickerv]:NEEDS[blackheart]
{
	@title = Place Anywhere Ussari Sticker	Type B
}

@PART[stickermini]:NEEDS[blackheart]
{
	@title = Place Anywhere Mini Ussari Sticker
}

@PART[stickerbig]:NEEDS[blackheart]
{
	@title = Place Anywhere Big Ussari Sticker
}

 

[MaxL_1023]

56 minutes ago, OhioBob said:

I'm sure that was probably the reasoning behind creating the default curve.  In real life, however, asteroids don't follow that type of distribution.  There are many things in nature were quantity increases exponentially with smaller size.  There are far more ants in the world than elephants, and far more microbes than ants.  We also see this with stars, where low-mass red dwarfs far outnumber the more massive stellar types.  The largest O-type stars are the most rare.

I also find it odd that a belt exists between Gael and Tellumo, but neither planet has any trojan asteroids.

The game could also be reflecting the observability bias - larger asteroids are much easier to see. Up to a point, this over-rides the actual size distribution. 

[OhioBob]

Just now, MaxL_1023 said:

I also find it odd that a belt exists between Gael and Tellumo, but neither planet has any trojan asteroids.

We just didn't set up the configs to generate trojan asteroids.  I did not take part in writing the asteroid configs, but now that I look at how the orbits of the asteroids are defined, I think it might be possible to produce a random group of trojan asteroids.  I'll check with the rest of the team to see if that's something we might consider adding.
 

Just now, MaxL_1023 said:

The game could also be reflecting the observability bias - larger asteroids are much easier to see. Up to a point, this over-rides the actual size distribution. 

That's a good point.  I didn't think of that.