ballisticfox0

EarthUHD uses cubemaps to make the stock ksp terrain system even higher detail, where as MTE uses meshes to make what looks like terrain on the ground.

For Linx's Beyond Home you must use Parallax 1.0.1, for my fork you need to use parallax 2.0.6

My discord is publicly accessible.

I used discord embeds for the images, unfortunately discord got tired of their platform turning into a pseudo-image sharing service meaning that any image link copied from discord will now have a hash with a timer set, after the timer is expired the image is offloaded off the server. Honestly not sure why they did this, I'd assume images having individual hashes would be even more server intensive than just a reference to the image but oh well, such is life.

That would be correct yeah, I removed KSRSS-64k a few commits ago in favor of: https://github.com/ballisticfox/KSP-64k/releases, which performs better, runs through Kopernicus, has better lighting and supports normal and emissive maps.

That assumption is actually correct, up until a couple weeks ago all homeworlds needed be named Kerbin internally Since EVE just points to the body Kerbin (Kerbin)'s clouds end up getting applied to Kerbin (Rhode)

I'd happy to try helping if ya'll are interested.

It’s less about the engine more how they set up the rotating/stationary reference frames from what I can tell. Tilt ‘em attempted to get around this by attaching some additional functions to account for rotation but the math is wrong to a certain extent and nobody has truely bothered with figuring it out. Principia, understandably doesn’t have this issue as they’ve completely rewritten the way the reference frame system behaves.

Jupiter fix is out

Try removing GasGiantsEnhanced as it’s already built into KSRSS

fun fact, most mods post-1.8 work just fine in modern KSP If this is one of the “Well CKAN says it’s not” feel free to go to settings > compatible game versions and just select all the ones you need

I would suggest you use https://gitlab.com/ksrss/KSRSS

I've actually thought about this a fair bit and it's probably possible. Take the cloud cover from a time step, lerp that between the current timestep and next time step, turn that into a coverage map, you could probably derive a type map from wind speed, altitude and various other factors. The main issue would be resolution, it's only 180x90 pixels afaik (it's a bit different) which is far lower than what most people use for cloud maps. Would be an interesting experiment nonetheless.

Can you verify that the profile you're using has/doesn't have Depth of Field? There's some pretty strong differences between HDR and non-HDR