Jump to content

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


Galileo

Recommended Posts

1 hour ago, Galileo said:

No, Rald is not one of our planets and it won't become one. As for a bop or gilly size body, we have plans for that either. The closest is going to be Eta or Lili. We are adding something that will allow other planet pack makers to add on to GPP though and a gilly or bop sized body might show up

I knew there was too much discussion of my planet on this thread :P

I'll agree that they don't really belong together - yours are all created completely new, i'm not even exactly sure how you made them.

Mine, on the other hand, is quite obviously mars with a modified color map and config file. Rather than create something new... I did fancy coloring on something from RSS because I couldn't put in the amount of detail required to make a good looking planet :P

Link to comment
Share on other sites

1 minute ago, KerikBalm said:

I knew there was too much discussion of my planet on this thread :P

I'll agree that they don't really belong together - yours are all created completely new, i'm not even exactly sure how you made them.

Mine, on the other hand, is quite obviously mars with a modified color map and config file. Rather than create something new... I did fancy coloring on something from RSS because I couldn't put in the amount of detail required to make a good looking planet :P

Oh, it's not that it's not as good looking, because it is. I think it's special as it's own body that can be put absolutely anywhere, in any pack. Why repackage it? The appeal for me is how diverse it can be

Link to comment
Share on other sites

3 hours ago, CatastrophicFailure said:

Quick question @Galileo: The GPP sub-group for Decal Stickers, how'd you do that? Is it an add-on MM config or something the other author included?

It's an expansion I developed myself. It renames the existing decal parts and their buttons then injects a second decal-switching module and adds moduleID numbers to prevent overlap/conflicts and make my modules the default. If you haven't seen it in action this is what you can do: add GPP's flags and make banners out of them all over a ship, and still pick from its default selection too. The decal selection might break and reset when such a craft is opened/shared without GPP but the craft itself won't break due to loss of cloned "GPP-exclusive" parts.

The decal parts will also wear the Gaeo Tao flag in its part selection thumbnail (these screenshots are before I perfected it).

HKXArnq.jpg

Laj3YXx.jpg

Edited by JadeOfMaar
Link to comment
Share on other sites

1 minute ago, eddiew said:

On another note, I do use Transfer Window Planner... technically a resized Ciro should be calculated by that, so's I'd know the transfer costs ahead of time, while the in-SoI costs for everything else would stay default. My brain is too tiny for this sort of thing :( 

As I understand it, Transfer Window Planner should work with the rescaled/resized system.  So, yes, that will give you the interplanetary transfer delta-v.  Transfers within a body's SOI will stay the same, or change, depending on how you want to think about.  For instance, it takes about 905 m/s to get from LGO to Iota, where Iota's orbit is 28,000 km.  In your modified system, it will still take 905 m/s to go from LGO to 28,000 km, however, Iota's orbit is no longer 28,000 km.  If you factor everything by, say, 3.2x, then Iota's orbit is now 89,600 km, therefore it will take more delta-v to get there.  So transferring from one orbit altitude to another orbit altitude within a body's SOI stays the same as 1x size.  But transferring from one body to another body within the same SOI will increase because the distance between the bodies has increased.

Link to comment
Share on other sites

Yes, I think with scatterer and eve clouds it looks good.... but most of the detail there I didn't make - thats my point. The RSS mars planet starts off looking good. 

If I were to just start making a height map and color map from scratch, it would probably look childish.

 

So what we have is your beautiful planets that are entirely fictional and a product of imagination, juxtaposed against something that most KSPers will immediately recognize as a reskin of mars.

Maybe some raondom person on the street wouldn't see rald for a reskin of mars, but I think >95% of KSPers will

Link to comment
Share on other sites

While landed on Thalia, I discovered

 

Spoiler

some very interesting thermal properties. Yes, the vessel was getting hot. Yes, I expected this to happen to some degree while being somewhat near Ciro. The thing that I found very unusual was that thermal data in KER was actually changing while the game was paused. I found this extremely unusual, so I started some digging. After hitting ALT-F12 and turning on various thermal debug windows, I discovered that at least some of the thermal simulation was either running or updating while the game was paused (as indicated by changing values in KER). The weird thing is that none of the stock "right click" windows were showing changing thermal data. I am no expert in the code that runs under the hood of KSP, but I found this strange. Loading up exactly the same craft and simply placing it on the launch pad on Gael did NOT generate the same behavior - i.e. KER and the ALT-F12 thermal data was completely static while the game was paused.

 

I discovered an unusual entry that I've never seen before in any planetary body config file (Thalia.cfg) called HazardousOcean. Icarus also has this entry. There were a number of "key" entries where the first number seemed to roughly correspond with what altitude, in meters, my vessels begin to overheat. Entering time warp (not physics warp) eliminates all overheating. I also found this quite unusual.

 

After some more digging, I found some Kopernicus code which described what HazardousOcean is located here: https://github.com/Kopernicus/Kopernicus/blob/master/Kopernicus/Kopernicus.Components/HazardousOcean.cs

 

I understand adding planets which are "hardcore", but the implementation seems to be broken. Why does some thermal simulation data change while the game is paused? Why do my crafts suddenly cool off when I enter time warp (not physics warp)? With the current HazardousOcean thermal simulation code, is it possible for a vessel of any size, with any number of radiators, of any size, to survive in a HazardousOcean for a "long" period of time while not in time warp?

 

Link to comment
Share on other sites

10 minutes ago, OhioBob said:

As I understand it, Transfer Window Planner should work with the rescaled/resized system.  So, yes, that will give you the interplanetary transfer delta-v.  Transfers within a body's SOI will stay the same, or change, depending on how you want to think about.  For instance, it takes about 905 m/s to get from LGO to Iota, where Iota's orbit is 28,000 km.  In your modified system, it will still take 905 m/s to go from LGO to 28,000 km, however, Iota's orbit is no longer 28,000 km.  If you factor everything by, say, 3.2x, then Iota's orbit is now 89,600 km, therefore it will take more delta-v to get there.  So transferring from one orbit altitude to another orbit altitude within a body's SOI stays the same as 1x size.  But transferring from one body to another body within the same SOI will increase because the distance between the bodies has increased.

Right, with you. That's basically what I was thinking of originally. I'd like to make the body-body part of the trip challenging, requiring good mission planning (e.g. dedicated transfer stage, left in orbit, as done for Apollo), while not sacrificing the funsize landers that come with the regular system. Might play with it a bit in sandbox and see what it feels like :) 

Link to comment
Share on other sites

30 minutes ago, JadeOfMaar said:

It's an expansion I developed myself. It renames the existing decal parts and their buttons then injects a second decal-switching module and adds moduleID numbers to prevent overlap/conflicts and make my modules the default. If you haven't seen it in action this is what you can do: add GPP's flags and make banners out of them all over a ship, and still pick from its default selection too. The decal selection might break and reset when such a craft is opened/shared without GPP but the craft itself won't break due to loss of cloned "GPP-exclusive" parts.

Cool... now how can I corrupt such a thing to my own uses? (So that future updates of the decal mod won't break the flags I want to put in.)

Link to comment
Share on other sites

@CatastrophicFailure Be my guest and rip my config; use it to inject modules with moduleID = 3. The main things are the textureRootFolder, textureNames, textureDisplayNames parameters. The highest moduleID becomes the default and the decal part will wear that module's first flag item in part selection. 

  • textureRootFolder lets you specify your own main dir and becomes a relative root dir for that module.
  • textureNames: every item, semicolon-separated, is the path to a PNG image without its filename extension and without spaces in the filenames just in case.
  • textureDisplayNames are the respectively ordered in-game display text for when you click the Next/Prev Flag button.

@eddiew I'm kinda sad that you took out Karbonite but it's fine. I was hoping to see what you'd invent with it and I didn't have scaled systems in mind when I wrote the buff for its engines. You have however, found one thing that I now know that mod isn't good for: getting to space from upscaled planets using karbonite itself. As @Norcalplanner hinted at, karbonite's polar opposite, Karborundum is sufficiently hard to find and should yield ships at least as powerful as what you previously engineered with the help of KRnD. :wink: I've been looking forward to that the most, from either of you two.

 

@thecross What if I told you that...

Spoiler

HazardousOcean is present in those planets on purpose, not just for the challenge but for the story, but that I didn't know about that bug until sometime after this v1.1 release. Theoretically no ship of any size and with any amount of cooling should be able to survive the game-pause heat bug, but it can be avoided by changing to any other situation: go to Tracking Station or switch to a vessel outside of these planets' areas of effect, anything to put the endangered vessels back on-rails.

HazardousOcean is not a new feature. It's in some planets made by KillAshley and should be in every lava world in any other pack.

 

Link to comment
Share on other sites

I suppose it's a new feature for me. Thank you for the explanation.

 

 

1 hour ago, JadeOfMaar said:

 

@thecross What if I told you that...

  Hide contents

HazardousOcean is present in those planets on purpose, not just for the challenge but for the story, but that I didn't know about that bug until sometime after this v1.1 release. Theoretically no ship of any size and with any amount of cooling should be able to survive the game-pause heat bug, but it can be avoided by changing to any other situation: go to Tracking Station or switch to a vessel outside of these planets' areas of effect, anything to put the endangered vessels back on-rails.

HazardousOcean is not a new feature. It's in some planets made by KillAshley and should be in every lava world in any other pack.

 

 

Link to comment
Share on other sites

1 hour ago, JadeOfMaar said:

Be my guest and rip my config; use it to inject modules with moduleID = 3. The main things are the textureRootFolder, textureNames, textureDisplayNames parameters. The highest moduleID becomes the default and the decal part will wear that module's first flag item in part selection. 

Brilliant! That worked like a charm, I can even throw some GPP flags in to spice it up a bit. :D

 

In other news, with great trepidation, here's my Rald/GPP setup-in-a-box:

https://www.dropbox.com/s/aawzgg8o0b9ig0o/MyRald.zip?dl=0

It's probably very inefficient if not very broken altogether. IF anyone's actually gonna try it, please please please backup your backups, then back them up again to a thumb drive and put it in a safe deposit box in Switzerland.

And now, after much ado, I think I'm gonna actually go and play this sucker for once!

Link to comment
Share on other sites

I hadn't realised you'd changed the Karbonite engines, @JadeOfMaar... what did you do to them? Looking through the stats, they all seemed to be low-ISP high-thrust booster stages, so yeah, in a scaled system where you're mostly fighting distance rather than gravity, they don't really help.

Still, I'm not quite decided yet. Basically I want to try at least one more mission to Niven with a kermanned rover, plus some Rald landings. What I don't want is to find that I'm making 200 part motherships to deliver 300 part landers and living in a world of lag. Even with 1.2.2, there's still a point where the clock goes yellow, and if I can, I'll keep my missions under that size. Thing is, the last Niven rocket required the entire height of the VAB, pushing beyond the height you can move the camera too. Stock VAB is not geared for this kind of madness :)

Link to comment
Share on other sites

8 minutes ago, eddiew said:

I hadn't realised you'd changed the Karbonite engines, @JadeOfMaar... what did you do to them? Looking through the stats, they all seemed to be low-ISP high-thrust booster stages, so yeah, in a scaled system where you're mostly fighting distance rather than gravity, they don't really help.

Still, I'm not quite decided yet. Basically I want to try at least one more mission to Niven with a kermanned rover, plus some Rald landings. What I don't want is to find that I'm making 200 part motherships to deliver 300 part landers and living in a world of lag. Even with 1.2.2, there's still a point where the clock goes yellow, and if I can, I'll keep my missions under that size. Thing is, the last Niven rocket required the entire height of the VAB, pushing beyond the height you can move the camera too. Stock VAB is not geared for this kind of madness :)

try this mod out. it extends the hanger for larger vessels, and im pretty sure the size is configurable

https://github.com/Alewx/FShangarExtender/releases/

the 1.2 version supposedly works

Edited by Galileo
Link to comment
Share on other sites

24 minutes ago, eddiew said:

Still, I'm not quite decided yet. Basically I want to try at least one more mission to Niven with a kermanned rover, plus some Rald landings. What I don't want is to find that I'm making 200 part motherships to deliver 300 part landers and living in a world of lag. Even with 1.2.2, there's still a point where the clock goes yellow, and if I can, I'll keep my missions under that size. Thing is, the last Niven rocket required the entire height of the VAB, pushing beyond the height you can move the camera too. Stock VAB is not geared for this kind of madness :)

 
3

Galileo already suggested the mod I was going to suggest for VAB size, (I haven't had a chance to use it yet, but I hope to make a lot of use now that I've upscaled my GPP system... Those big monster launchers are the kind of rockets I want to build. :-) ) but for the part count you might want to check out 

It's already saved my butt once, though with a fairing size rather than part count problem. Still, part count is one of the big reasons it exists.

It's work in progress, but SSTU is also great for lowering part count. It packages together many things often used together into one part, to save part count. I especially love the option to turn engines into cluster configurations in the right click menu. (There is even an expansion patch available to add that feature to other engines from a few other mods.)

 

Edited by Fobok
Forgot link to SSTU.
Link to comment
Share on other sites

On 5.2.2017 at 8:08 AM, JadeOfMaar said:

Since no one here really has the skill yet to make a skybox from scratch (as in, load up on textures and brushes), requests for skyboxes cannot be taken seriously... but I found yours quite reasonable and did some good hard Googling and managed to get the goods. It's not ready to be published yet but the nebula is real, the Eagle nebula. This is the best non-EVE Online one I've made yet. :) 

Codename "Foreign Eagle" :: Gallery

e6TTkPg.jpg

Don't mean to rush...

... but is this ready to be published soon?

Link to comment
Share on other sites

So since 3.2x is making me sad, I've been pondering the idea of a 3.2x orbit, 1x body size setup, with the goal of making transfers harder without sacrificing fun things like SSTOs and rover expeditions. It's the sort of situation that I feel will encourage "Apollo style" play, in that a separate transfer stage/fuel cache becomes desirable, but also won't restrict you by demanding that you make everything purely for utility or forcing huge part counts.

ISRU is a good idea when you need to find 5-10km/s to get home, but your miner can be of conventional scale. (Even Iota proved to be a pain to mine at 3.2x since I lost about 40-45% of the fuel yield back to the drilling rig itself.)

And yes, it encourages Odyssey-like motherships that can carry <max weight> up to <known range> :wink:

So at the moment, I have this config:

Spoiler

@SigmaDimensions
{
	// Base Settings
	@Resize = 1 // obviously back to 1x
	@Rescale = 3.2
	@Atmosphere = 1
	@dayLengthMultiplier = 1

	// Advanced Settings
	@landscape = 1 // standard terrain
	@geeASLmultiplier = 1

	@resizeScatter = 1
	@resizeBuildings = 1

	@CustomSoISize = 0 // nothing in GPP uses SphereOfInfluence it seems
	@CustomRingSize = 1 // otherwise it'll follow orbital size, which we don't want

	@atmoASL = 1
	@tempASL = 1
	@atmoTopLayer = 1
	@atmoVisualEffect = 1

	@scanAltitude = 1
}

@Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim]
{
	@Body:HAS[#name[Ceti]]
	{
		@SigmaDimensions
		{
			@Rescale = 1.6 // anything over this and it ends up outside of Gael's SoI, which wants to be 105,000km
		}
	}
}

@Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim]
{
	@Body:HAS[#name[Iota]]
	{
		@SigmaDimensions
		{
			@Rescale = 1.6 // needs to be sensibly set relative to Ceti
		}
	}
}

@Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim]
{
	@Body:HAS[#name[Lili]]
	{
		@SigmaDimensions
		{
			@Rescale = 1 // Lili is relative to Tellumo's rings, we don't want to fiddle it's orbit
		}
	}
}

@Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim]
{
	@Body:HAS[#name[Eta]]
	{
		@SigmaDimensions
		{
			@Rescale = 1.4 // Thalia's SoI is quite small
		}
	}
}

@Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim]
{
	@Body:HAS[#name[Sun]]
	{
		@SigmaDimensions
		{
			@Resize = 3.2 // sun scaled to match regular 3.2x config, otherwise very slow orbits will result. Gael year = 720 days approx.
		}
	}
}

// all @dayLengthMultipliers removed

 

I've kept basically all of the GPP 3.2x planetary settings, but everything except orbital radii is reset to 1. Gael is back to being a stock-comparable experience, especially if you launch from Rook's Glory on the equator. Ciro swells to its 3.2x size (suggested by @OhioBob) to avoid having very slow planetary orbits. Rough Gael-to-destination transfers listed below:

  • Icarus: 16174m/s, 211 days  (2.7x)
  • Thalia: 7129m/s, 197 days  (2.1x)
  • Niven: 2261m/s, 300 days (1.3x)
  • Tellumo: 3369m/s, 1 year 104 days  (1.1x)
  • Gratian: 4703m/s, 2 years 58 days  (1.5x)
  • Otho: 6754m/s, 4 years 146 days  (1.5x)
  • Gauss: 7560m/s, 15 years (1.6x)
  • Nero: 8159m/s, 28 years 41 days  (1.5x)
  • Hox: 9155m/s, 81 years  (2.0x)
  • Leto: 7030m/s, 81 years  (1.9x)

Thalia and Icarus are even harder to get to than in the regular 3.2x config (which makes sense since they are now smaller targets vs a bloated sun...), while Niven and Tellumo remain relatively soft targets. As soft as Tellumo gets, anyway. You still won't be coming back from it in a hurry. The way to Icarus is almost certainly via gravity assists, or with a refuelling base on Thalia/Eta. In the outer system, the further out you go, the bigger the transfer cost becomes, but it never gets obscene. Again, a mining base at maybe Gratian or Augustus would be helpful. 

There's definitely some variance in transfers depending on the time you make your plots (my career at year 28 vs sandbox at year 1 have about a 10% difference), which I assume is down to orbital eccentricity and thus "normal".

The SoI's of Gael and Thalia are too small to contain their moons, so I brought Iota and Ceti down to 1.6x their normal distance, and Eta is at 1.4x. It's possible that Eta's SoI pokes outside of Thalia's at AP, but I don't think that's a big deal. I guess I'll find out later if it is.

So yeah, I'm going to have a go with this setup and see how it plays. If I find any weird places where SoI's are being silly then I'll post an updated config. I may also be inclined to reign in the gas giant moons to 1.6x (or 1x) their regular orbits, because having them so spaced out might make gravity assists too hard to find. And of course, if anyone likes the sound of what I'm aiming at, feel free to try the config out and let me know how you get on with it :) 

Link to comment
Share on other sites

5 minutes ago, eddiew said:

It's possible that Eta's SoI pokes outside of Thalia's at AP, but I don't think that's a big deal. I guess I'll find out later if it is.

It's a big deal if you have a craft in orbit around Eta.  Eta will continue to orbit Thalia even if it moves outside the SOI, but as soon as it moves outside the SOI, any craft that you have orbiting Eta will drift away into a solar orbit.  We actually had this situation with the original design.  I hadn't been thorough enough with my math to notice that Eta's apoapsis was beyond the Thalia's SOI.  I ended up having to decrease Eta's semimajor axis and eccentricity to keep it inside Thalia's SOI.

Link to comment
Share on other sites

7 hours ago, eddiew said:

I hadn't realised you'd changed the Karbonite engines, @JadeOfMaar... what did you do to them? Looking through the stats, they all seemed to be low-ISP high-thrust booster stages

I haven't done much. The buff only raises the max thrust and top speeds of most of the jet engines. By default they have at best peak performance at around Mach 1.7 and die in Mach 3. The karbonite turbojet (all the other engines turbofans or turboprops) has the greatest buff with at I think 50% more thrust, peak perf in Mach 2, dies near Mach 5, and is still very powerful in nearly the faintest of atmospheres.

Spoiler

On the flip side they're all a little heavier and heat up faster.

i've done nothing to the karbonite rocket engines. They're quite powerful already and only need to be supplemented (for now) with clever engineering to keep karbonite coming while they go. Furthermore karbonite is in every ocean and every atmosphere in GPP.

Link to comment
Share on other sites

18 minutes ago, OhioBob said:

It's a big deal if you have a craft in orbit around Eta.  Eta will continue to orbit Thalia even if it moves outside the SOI, but as soon as it moves outside the SOI, any craft that you have orbiting Eta will drift away into a solar orbit.  We actually had this situation with the original design.  I hadn't been thorough enough with my math to notice that Eta's apoapsis was beyond the Thalia's SOI.  I ended up having to decrease Eta's semimajor axis and eccentricity to keep it inside Thalia's SOI.

Ah, right, in that case I'll bring it down from 1.4x to 1.2x, that should sort it out. Thanks for the warning :) 

(Why is Thalia's SoI so small? Proximity to Ciro?)

6 minutes ago, JadeOfMaar said:

I haven't done much. The buff only raises the max thrust and top speeds of most of the jet engines. By default they have at best peak performance at around Mach 1.7 and die in Mach 3. The karbonite turbojet (all the other engines turbofans or turboprops) has the greatest buff with at I think 50% more thrust, peak perf in Mach 2, dies near Mach 5, and is still very powerful in nearly the faintest of atmospheres.

  Reveal hidden contents

On the flip side they're all a little heavier and heat up faster.

i've done nothing to the karbonite rocket engines. They're quite powerful already and only need to be supplemented (for now) with clever engineering to keep karbonite coming while they go. Furthermore karbonite is in every ocean and every atmosphere in GPP.

Ahh, so basically they were jets for Tellumo :wink:  I hadn't noticed that, I may take another look :) 

Link to comment
Share on other sites

21 minutes ago, eddiew said:

Ah, right, in that case I'll bring it down from 1.4x to 1.2x, that should sort it out. Thanks for the warning :) 

(Why is Thalia's SoI so small? Proximity to Ciro?)

Ahh, so basically they were jets for Tellumo :wink:  I hadn't noticed that, I may take another look :) 

I think there may be a scenario, using a Karbonite-fueled jet and Karbonite intakes, where it's possible to fly around pretty much indefinitely. At the very least, a spaceplane outfitted with Karbonite tanks, drills, and an on-board converter should be able to use the Karbonite jets for the first part of the ascent, then turn the converter on and make LF in real time to feed any LV-Ns on board.

Link to comment
Share on other sites

40 minutes ago, eddiew said:

(Why is Thalia's SoI so small? Proximity to Ciro?)

Yep, its proximity to Ciro along with the fact that Thalia just isn't very big.  Have you checked out Icarus' SOI?  It makes Thalia SOI look enormous.

Link to comment
Share on other sites

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