[1.12.5] Kcalbeloh System Planet Pack (v1.1.8) - A journey to a black hole (Aug 31, 2024)

[JonnyOThan]

1 hour ago, Lisias said:

CKAN's metadata is lacking on Planet Packs.  Kerbol Origins, for example, is flagged to work only to KSP 1.8.1 on SpaceDock, and this information is replicated on CKAN.

That’s the mod author’s responsibility. CKAN does not make assumptions about what is compatible against the mod author’s own statements. Can you imagine the madness that would ensue otherwise?

Nearly every mod for 1.8+ does actually work in 1.12.5, so enabling extended compatibility settings on CKAN is the right move there. And it’s far less error prone than manual installs.

On 9/11/2024 at 5:07 AM, Zum of all trades said:

Hello, I've encountered a problem with kcalbeloh system mod. for some reason all the planets in the aralc system have glitchy messed up atmospheres, and if I go too close to the planet arorua it just crashes my game. And it is ONLY the aralc system every other system looks just fine, and I have no clue why. I installed kcalbelloh via CKAN so it should be free of problems. could anyone explain to me what's going on!?

Any time you report an issue you should include your KSP.log file.

[Grenartia]

Yeah, I gotta agree with Jonny here. CKAN does a lot less erroring than manual, and 1.8.x usually works flawlessly on 1.12.x unless there's some sort of conflict with a different mod. 

[Lisias]

1 hour ago, JonnyOThan said:

That’s the mod author’s responsibility. CKAN does not make assumptions about what is compatible against the mod author’s own statements. Can you imagine the madness that would ensue otherwise?

And, so, how exactly telling @Iapetus7342 to install manually the Planet Packs and letting CKAN handling the other dependencies is not the best solution for this problem?

And exactly how this madness is less mad than users bluntly telling CKAN to allow installing incompatible add'ons as a workaround to allow installing a single (empirically confirmed) compatible add'on?

 

33 minutes ago, Grenartia said:

Yeah, I gotta agree with Jonny here. CKAN does a lot less erroring than manual, and 1.8.x usually works flawlessly on 1.12.x unless there's some sort of conflict with a different mod. 

What doesn't means that CKAN is not behaving wrongly on borderline situations, and then manual installing of these specific use cases would be the best compromise.

We have a problem here: CKAN is preventing people to install add'ons that are perfectly usable on the target KSP, and the users are (rightfully) trying to find a workaround for it.

By telling these users that manual installing is not an acceptable solution, exactly how do you think the users will handle the problem?

 

Edited September 12 by Lisias
Hit "Save" too soon

[JonnyOThan]

13 minutes ago, Lisias said:

And exactly how this madness is less mad than users bluntly telling CKAN to allow installing incompatible add'ons as a workaround to allow installing a single (empirically confirmed) compatible add'on?

Because 99.999% of mods for 1.8+ are safe.  This path puts the burden on the user if something breaks because they were appropriately warned (just as it is when manually installing).  Setting compatible versions in CKAN is something you only ever need to do once per KSP install.   Yes it’s often a stumbling block for new CKAN users but that’s hardly a reason to avoid it entirely.  Manually installing mods often leads to incorrect installations or installing older versions of bundled dependencies.

Anyway all of this is off topic for this thread.

Edited September 12 by JonnyOThan

[Lisias]

59 minutes ago, JonnyOThan said:

Anyway all of this is off topic for this thread.

Moved to

 

[Iapetus7342]

Somehow i managed to start a debate over a single mention of something @The Minmus Derp said on the thread for OPx. I love the internet

[The Minmus Derp]

6 minutes ago, Iapetus7342 said:

Somehow i managed to start a debate over a single mention of something @The Minmus Derp said on the thread for OPx. I love the internet

What the hell happened here?

[Iapetus7342]

1 hour ago, The Minmus Derp said:

What the hell happened here?

Someone was having problems and i said that CKAN wasn't reliable for planet packs. This sparked a debate that extended into this page.

[Streetwind]

Well then, to get back on topic...

I'm strongly considering using Kcalbeloh as a star system replacement (starting on Suluco, Kerbol completely disabled). Since I haven't played KSP1 in... four or five years(?) I'm pretty clueless when it comes to these newfangled visual mods that the kids are using these days So I have questions.

How is the status of the volumetric clouds config? The release page names five bodies as finished, but does that mean that they are the only ones that have clouds at all? Or do all the atmospheric bodies have at least basic support, and just aren't all considered "finished"? On one hand I really want to try out volumetric clouds, but on the other hand it would bother me if there was a big disconnect between the visual appearances of different celestial bodies. If there is such a thing, I might consider dropping volumetric clouds in favor of a more unified visual style.

If I do end up using volumetric clouds, can I install that together with the likes of Spectra or AVP? Or are they incompatible? I have since learned: they are incompatible.

If I do end up using either Spectra or AVP (either because they are compatible or because I dropped volumetric clouds), which one would you recommend? Since I am disabling the Kerbol system, it doesn't matter which of the two does that system better; I only care about how the Kcalbeloh system itself looks. (And yes, I realize that beauty is largely subjective, but there can also be objective measures like when one of the two packs simply works better/implements effects in places the other doesn't/etc).

Do the rescale configs shipped with this pack also take care of rescaling the Parallax configs? Or would this be something I'd have to do myself if I wanted to go for a rescaled setup? I have since learned: Parallax Continued itself offers appropriate patches.

EDITed to add two other questions:

Do asteroids generate in the Kcalbeloh system? I actually wouldn't mind if the answer was "no", since I don't like the feature very much. In the past I often ended up delaying the upgrade to the level 3 tracking station as long as possible to keep these things from clogging up my save. So... just saying... if there was a way to ensure that no asteroids generate... I would be all ears

And, given that I'll not be starting on Kerbin, what happens to the contracts in career mode? I assume it still gives me the first contract in the "Explore the Mun" series, and then remains stuck there because it will never get completed, and meanwhile I'll be getting the usual assortment of procedurally generated, non-Exploration contracts?
Who knows, maybe I can disable the stock Exploration contracts using Contract Configurator or something...

Edited September 17 by Streetwind

[CashnipLeaf]

2 hours ago, Streetwind said:

Do asteroids generate in the Kcalbeloh system? I actually wouldn't mind if the answer was "no", since I don't like the feature very much. In the past I often ended up delaying the upgrade to the level 3 tracking station as long as possible to keep these things from clogging up my save. So... just saying... if there was a way to ensure that no asteroids generate... I would be all ears

Yes, asteroids will generate in various locations in the kcalbeloh system

2 hours ago, Streetwind said:

And, given that I'll not be starting on Kerbin, what happens to the contracts in career mode? I assume it still gives me the first contract in the "Explore the Mun" series, and then remains stuck there because it will never get completed, and meanwhile I'll be getting the usual assortment of procedurally generated, non-Exploration contracts?
Who knows, maybe I can disable the stock Exploration contracts using Contract Configurator or something...

Actually, the game will note that "mun" doesn't exist, so it wont generate contracts for it. 

However, the order in which the game delivers the progression contracts for the various homeswitches needs some retuning since after going to Tot and going sundiving, it'll ask you to go to Maelg (before exploring the rest of the sunorc system). I believe it's based on recovery value but I could be wrong

Edited September 17 by CashnipLeaf

[Streetwind]

Neat, I didn't know the game could generate Exploration contracts like that. I thought they might have been predefined.

Maybe it's based on science value? That's also something I was going to ask about, since the system is offering you multiple start locations, in addition to the default start of Kerbin. Science values should be low in places easy to reach from your starting location, and high in places difficult and/or time-consuming to reach. Does each of the starting locations actually change up all of the science values? That would be an impressive amount of effort. Or is there some compromise in this regard?

EDIT:

Would the Exploration contract progression work better when starting on Efil?

Edited September 17 by Streetwind

[SheepDog2142]

On 9/17/2024 at 2:03 AM, Streetwind said:

Neat, I didn't know the game could generate Exploration contracts like that. I thought they might have been predefined.

Maybe it's based on science value? That's also something I was going to ask about, since the system is offering you multiple start locations, in addition to the default start of Kerbin. Science values should be low in places easy to reach from your starting location, and high in places difficult and/or time-consuming to reach. Does each of the starting locations actually change up all of the science values? That would be an impressive amount of effort. Or is there some compromise in this regard?

EDIT:

Would the Exploration contract progression work better when starting on Efil?

Have you gotten volumetric  clouds and parallax continued working when removing Kerbin solar system and starting on Suluco?
Parallax continued seems to be completely broken when using homeworld switcher and Volumetric clouds even with the config seem to be black and theres no atmo on the planet.

[Streetwind]

@SheepDog2142

Yeah, I noticed significant issues too. Didn't get as far as trying volumetric clouds, but even with just a default install of EVE, I got heavily broken atmospheric visuals. Eventually I found out that this would only occur when starting KSP fresh, and would fix itself once the player enters the tracking station and then exits it once. In the tracking station itself there were also issues - for example the launch sites seemed to jitter and move about on the surface of the planet. This also fixed itself in most cases by entering and exiting the tracking station, though in some cases (like when not using the home switch feature but instead moving the stock system to Kcalbeloh) it remained broken permanently.

I ran into the Parallax issue aswell. Made a bug report to Linx, he said that he's never tried moving the player's start location elsewhere, so he needs to look into how that works before being able to say for sure why it breaks. But he did notice that apparently whatever body you move the KSC to gets internally renamed as "Kerbin" by the home switch patch, which results in there being two bodies named Kerbin (even if you remove the stock system, the planet definition still exists), which is what might well be the thing that breaks Parallax.

Since I had already been on my ninth consecutive day of testing, troubleshooting, and configuring mods at the time, and I just wanted to play already, I ditched Kcalbeloh in favor of stock system + OPM.

But perhaps you can try and modify the home switch patch so that it renames the old Kerbin into some dummy value the same way that Suluco gets renamed into Kerbin? Ideally that should remove the error about two Kerbins being present.

[Barry Kerman]

Hello! I relly appreciate your work on Kcalbeloh System! Is the config. of the Kcalbeloh bodies for StockVolumetricClouds provided? I really  appreciate it!

[zonyfony]

how do i read this mod's delta v map? i've used it to get to sera's moon only to find out that i needed much more delta v then I had brought. the map is very confusing to me, but i might just be reading it wrong. could somebody give me some help? (i've home-switched to suluco)

Edited September 30 by zonyfony

[Leganeski]

3 hours ago, zonyfony said:

how do i read this mod's delta v map? i've used it to get to sera's moon only to find out that i needed much more delta v then I had brought. the map is very confusing to me, but i might just be reading it wrong. could somebody give me some help? (i've home-switched to suluco)

The Δv map doesn't show all of the possible transfer costs, only those between objects orbiting the same thing (i.e. between planets in the same star system, moons in the same planetary system, or stars orbiting Kcalbeloh) as well as between solid planets and their moons. (This is likely not an oversight but rather a way to avoid the map being gigantic, extremely cluttered, and full of lines that cross each other.) Dipuc is a moon in the Sera planetary system but Suluco is not part of that system, so the direct transfer between them does not appear on the map. What it does allow you to calculate is the cost if you were to come from Suluco and brake at Sera:

Suluco ascent: 2920
Suluco ejection to Sera: 1280
Brake at Sera from Suluco transfer trajectory to Dipuc transfer: (1400 - 946) = 454
Dipuc capture from Sera: 298
Dipuc descent: 631


Coincidentally, I am currently working on a Δv table for this system which should hopefully show the cost for every direct transfer, not just the ones in the map. The value I calculated for a capture directly from Suluco to the 20 km Dipuc orbit suggested by the map (or, equivalently, the ejection from that orbit back to Suluco) is 759 m/s, which happens to be close to the total cost of the brake-at-Sera route.

[ProximaCentauri_star]

This is what PEAK gaming looks like

[zonyfony]

On 9/30/2024 at 1:01 AM, Leganeski said:

The Δv map doesn't show all of the possible transfer costs, only those between objects orbiting the same thing (i.e. between planets in the same star system, moons in the same planetary system, or stars orbiting Kcalbeloh) as well as between solid planets and their moons. (This is likely not an oversight but rather a way to avoid the map being gigantic, extremely cluttered, and full of lines that cross each other.) Dipuc is a moon in the Sera planetary system but Suluco is not part of that system, so the direct transfer between them does not appear on the map. What it does allow you to calculate is the cost if you were to come from Suluco and brake at Sera:

Suluco ascent: 2920
Suluco ejection to Sera: 1280
Brake at Sera from Suluco transfer trajectory to Dipuc transfer: (1400 - 946) = 454
Dipuc capture from Sera: 298
Dipuc descent: 631


Coincidentally, I am currently working on a Δv table for this system which should hopefully show the cost for every direct transfer, not just the ones in the map. The value I calculated for a capture directly from Suluco to the 20 km Dipuc orbit suggested by the map (or, equivalently, the ejection from that orbit back to Suluco) is 759 m/s, which happens to be close to the total cost of the brake-at-Sera route.

thanks, this helped a lot with the map. but now im trying to go to the simetra-simeht system, and its much harder to reader even with your help. the moons only have the delta-v calculations from starting on it, and im having a lot of trouble connecting it with starting at suluco. if its possible could you give me some help with that? thanks a lot once again

[Tychonoir]

Just installed Kcalbeloh, and everything seems to work, except I was getting weird graphical glitches when viewing the inner planets in the map view. Basically, they looked right when facing the black hole, but the background space would glitch with residual images if facing away from the black hole. Outer systems seemed fine.

I tried hyper-editing a ship to the locations, and same issue.

I thought this might be related to a visual mod, but the problem persisted even when turning them off.

Is this a known issue with a way to fix?