arbsoup

It's in the folder where the game executable and all the other contents are. If your previous log is correct, the full path should be D:\SteamLibrary\steamapps\common\Kerbal Space Program\KSP.log.

There was an RSS release in October 2013, though I don't actually know if that added new bodies or just customized and rearranged everything.

I don't know what file that is. It doesn't look like a description of the game getting stuck loading — there's text here about flying and crashing a spacecraft. Please launch the game, wait for it to get stuck on the loading screen like you said, and then force quit the game. KSP.log will then appear in the main directory where you launch the game from, where the "GameData" and "screenshots" folders and all that are. (For example, if you're using Steam, it'd be steamapps/common/Kerbal Space Program/KSP.log.) Please do not paste the entirety of KSP.log into a forum post. Upload it to a file-sharing site like Google Drive or Dropbox, and then post the link in the forum. I have no idea what you mean by "blackracks parallax" — Blackrack is not the developer of any Parallax version — or what you mean by it not loading. Let's focus on one thing at a time.

That's what Scatterer does — it replicates the effect of looking through an atmosphere, and Earth's atmosphere (and thus Kerbin's) is very much blue. Compare this Apollo 17 photo, where the Earth visibly has a blue tint to it. It probably seems a little weird because there's atmospheric extinction but no actual clouds. It'll look better if you get EVE-Redux and some config for it (e.g. Astronomer's or Spectra) to add some clouds and make it look more natural/cinematic.

Never mind, I found a reference to "snacks" in your mod list. It is almost certainly Progressive Colonization System which is adding its own snacks feature (I wouldn't say "secretly", it does have "life support system" right there in the description). I can't see an easy way to turn it off in the mod config options, so you may have to uninstall it to avoid this problem.

I would also appreciate if you could post the exact text that appears onscreen (and where).

KSP.log would be enough, as it already contains a list of everything in GameData.

You have Kcalbeloh and OPM_Parallax installed, a combination which is known to cause infinite loading and has a known fix. See if following the advice here (rename the GameData/OPM_Parallax folder to GameData/ZOPM_Parallax) does anything of use. You will also want to change the first line in GameData/MPE/Patches/Parallax/ParallaxTerrain.cfg as instructed at this second link, as that is also known to cause infinite loading.

There seem to be two types of files in JNSQ_ParallaxScatters. The first is for JNSQ bodies, which duplicate stock bodies' default Parallax configs and make minor tweaks. The second is for the stock bodies, to tweak their scatters a bit, and they all begin like this: @ParallaxScatters:HAS[#body[Dres]]:NEEDS[JNSQ]:AFTER[ParallaxStock] Somehow, in your log, this patch is not just getting applied to nodes with body=Dres; it is getting applied to every ParallaxScatters node for both stock and JNSQ bodies. And so on down for every single stock body patch in JNSQ_ParallaxScatters, which sums to over 200 patches. I was wrong. I don't know how to fix this. The worst-case approach might be to make do without JNSQ_ParallaxScatters, wait until Parallax Continued comes out (next month?), and use the corresponding JNSQ patch for that (this one?), which will be better-supported and more-discussed at least in the immediate aftermath of the release. (Maybe not discussed here, though, you might want to get a Github account ready.)

I am going to suggest you try something entirely different. Parallax and Kopernicus are likely not at fault. You can put everything back (hope you have backups!); try removing solely JNSQ_ParallaxScatters from your install. I noticed a bunch of questionable Parallax scatter patches in the log coming from it; this might have to do with how it keeps using @ParallaxScatters{} instead of ParallaxScatters{}, and similar problems are known. If this and this alone is enough to fix it, I may have advice for you on how to keep it.

You also really don't want to run EVE Redux and EVE Volumetrics in the same install (since Volumetrics is intended to replace Redux). Pick one version of EVE and stick to it; I believe one intentionally blocks the other, but having less stuff going on in your GameData folder can't hurt in this particular case. Are you using a very high-quality texture pack for one or the other? Redux does nothing to your game by itself, it relies on having another mod bring textures and configs (Volumetrics brings its own but allows for optional replacements), but you don't say what you're actually using. If it's something gigantic, yeah, that'll eat up a lot of resources.

I would strongly advise against pretty much everything in this approach. As a beginner, it's really important not to hype yourself up too much about all the stuff you want to do, because in addition to likely disappointing whoever else might've been excited by the words on the page, you are likely to burn out and disappoint yourself. Pick a thing and do it well. And if you don't know how to do that yet, pick a smaller thing and do it decently. You say that you have problems with EPL being too complex, for example (which is surprising, because my complaint is that it is almost too simple, especially in its complete isolation from CRP). Could you identify a change and make it? The source is on Github and it's under the GPL license, so you're welcome to make a fork to tinker around with it. In the process, you'll learn about the C# build environment and using git, and you'll do it in a context where you know what's supposed to happen so it's easier to fix bugs. My one true code contribution so far is my tiny little USI-LS fork to fix some issues with the habitation time system. I could've decided to make a life support mod that does everything I want it to, from the ground up — but that would be a lot, and I wouldn't even know where to start coding. But I have a bit of a better idea now, because of that experience getting into the guts of someone else's project and figuring out how they made it work. And in the meantime I've produced a small thing done decently that improves my KSP experience, and that's something I could be proud of even if I quit afterwards.

Because I'm not sure the KSS2_Moon tag is even intended to exist; the Nova Kirbani moons don't use it. So any firm solution is going to feel a little wrong to me until the devs weigh in.

Just checked. I am willing to bet that in your install the planets' orbit radii, and the planets' sizes, have all been correctly adjusted, but the moons specifically have not been rescaled or moved outwards (so they end up inside the planets). With JNSQ installed, changing Rescale shouldn't have any impact on any planet sizes or orbit radii (the 2.5x config is forced if KSS2 detects JNSQ). DistanceFactor should only work if it's 0.5 (not 0.1 as documented!), 10, or 100, per Core/Configs/DistanceScales.cfg. Also from that file, it should only impact the stars' distance from the Sun. If the Aethera system's distance from the Sun changed after you changed DistanceFactor from 1 to 2.5, or if the planets' orbit radii changed, that is probably unintended behavior. Double-check these and report your findings: how far away is Aethera, and what distance away from it are the planets, for each value of DistanceFactor? KSS2's rescale configs target objects with the tags "KSS2_Planet" and "KSS2_Comet" and such, but some bodies in Aethera have the tag "KSS2_Moon" instead, which is not targeted. There are a couple ways to fix this, though I don't know which one would be developer-intended. For a temporary hack solution, copy lines 38-82 in Core/Configs/Patches/Rescale_Sigma/2.5x.cfg (those being the two "@Body:HAS[#Tag[KSS2_Planet]]" sections), then paste them below, replacing "KSS2_Planet" with "KSS2_Moon" in the two places it appears at the start of the new duplicates.

Hi! 10x Kerbin player here! Glad to have you onboard. Get SigmaDimensions directly and then set its config options in settings.cfg. Here are mine (ignoring my various body-specific changes), for reference: SigmaDimensions { // Base Settings Resize = 10 //Necessary for 10x. Rescale = 10 //Necessary for 10x. Atmosphere = 1.3 //Your call, but this seemed right for an Earthlike atmosphere. dayLengthMultiplier = 4 //Makes Kerbin days 24h, though other planets rotate kind of slowly. // Advanced Settings landscape = 0.15 //Terrain will still be very flat, but this is about as high as you can push it without ridiculous 10km+ elevations. geeASLmultiplier = 1 resizeScatter = 1 resizeBuildings = 0 groundTiling = 1 CustomSoISize = 0 CustomRingSize = 0 atmoASL = 1 tempASL = 1 atmoTopLayer = 1.5 //Also your call. 1.3 & 1.5 puts Kerbin's atmosphere limit at 136.5 km atmoVisualEffect = 1.3 lightRange = 1 scanAltitude = 1 } Parallax 2 works just fine in a rescaled system, and in fact I'd recommend it — it fixes certain PQS-related lag near the Mun and other bodies. You might want to add Lithobraker's rescale patch to some folder in GameData, though scatters will still be much more sparse than at stock scale (there's not much helping that without the risk of massive lag). As for changing the parts — I'm not fond of approaches that resize them, I prefer capabilities rescaling so I won't be able to help you if you want to physically make stuff bigger. SMURFF is the usual pick if you just want better mass ratios to orbit (though it makes all engines much stronger), but check out RSS Adapter as an alternative.

The compatibility list has Restock (new models for stock SRBs), but not Restock+ (replacements for DLC parts). The Castor is a duplicate of the Pollux SRB from the stock Making History DLC. If you have the DLC installed, it should be hidden from the VAB in place of the Pollux. Regardless, you should be able to just go into Avalanche/Configs/restock/pollux.cfg, make a copy of the file (name the new one whatever you want, just don't forget .cfg) and change the first line from @Part[Pollux] to @Part[restock-srb-castor-1] — let me know if that ends up looking better.

I assume you're making a thruster that also consumes EC, or the like. Here's a good starting post. I'll be talking you through it from the file-creation side. First calculate the mass flow rate for your massed resources: thrust divided by exhaust velocity (itself being ISP * 9.80665 m/s^2). The answer has units of mass/time. Then divide by resource density to get resource consumption rate. (If you have multiple massed resources, you'll need to separate this out into components when writing it up.) In the case of a 1 kN thruster with 250s ISP using MonoPropellant (density 0.004 tons/unit), Wolfram|Alpha gives 0.102 units/second. That is now your starting ratio for the massed resource. Then, when you add the massless resource (say, EC), give it a ratio based on however much EC you want the engine to consume. If you set EC ratio = 1 and MonoPropellant ratio = 0.102, the engine will consume 1 EC/s. If you set EC ratio = 2 and MonoPropellant ratio = 0.102, the engine will consume 2 EC/s, and of course the same amount of MonoPropellant. If you set EC ratio = 1 and MonoPropellant ratio = 0.051, the engine will consume 2 EC/s and the same amount of MonoPropellant (0.102 units/second), because you can't do any better than conservation of momentum — instead, true to the name, the game respects the ratio between the quantities. The usual convention is to set either of the resources' ratios to 1 and scale everything off of that, but the stock ion engine breaks the convention so it's not a huge deal.

The intent is for boosters to gradually switch to a special "flame-out" plume after they've stopped burning, like with real SRBs — e.g. the Shuttle SRBs notably continued producing tons of smoke long after they had stopped providing thrust for the vehicle and been jettisoned. For reasons I really don't know, Avalanche has most boosters switch to the flame-out plume from 0-10 seconds, and then switch back to the full-throttle plume during 30-60 seconds (which looks super weird during pad tests!): ENGINEEVENTCONTROLLER { eventName = flameout eventDuration = 60 name = Burnout eventCurve { key = 0 0 0 0 key = 0.01 0.01 0 0 key = 10 1.5 0 0 key = 30 1.5 0 0 key = 60 0 0 0 } } Then at 60 seconds the plume abruptly stops, not even fading out or anything. I don't know how to fix the abrupt cutoff (I'd have liked to see a flame-out and then gradually fading away to nothing), but you can fix the "flame-out plume continues forever and then flares back up for some reason" problem by setting eventDuration = 10 in the Avalanche .cfg files for all the SRBs you use. Or set eventDuration = 0 if you want the plume to cut off as soon as the SRB stops thrusting.

On the other hand, EVE-Redux + Astronomer's Visual Pack seem to still work on the outer planets with OPX (at least giving them clouds and aurorae from space on my rescaled install, though the aesthetics don't match what's intended in OPX). So I don't know if you installed OPMVC wrong or anything, but Redux should probably be an acceptable path forwards for this mod, I'd think — it seems robust enough to OPX's changes.

Hi all. Close to a year ago I decided to get back into the game, and after fiddling with configs, making patches, and checking and double-checking everything many times over as my install grew ever more complex, I'm finally at a position where I can probably focus a bit more on gameplay. So I figured I'd share that all with you here. I'm running a sandbox game (career's broken beyond belief in this setup, and I'm still tired of biome-hopping from the last time I played a couple years back) in a 10x scale Kerbin system (plus plenty of extras) where I'm basically giving myself some gentle pushes towards certain styles — use USI Life Support (my fork!) for extra challenge, use chemical rockets (thank you SMURFF) for lifters even if I have all those cool nuclear engines, focus on relatively conventional approaches early on until I feel like I've earned the advanced stuff, build "infrastructure" even if I don't strictly need it, that kind of thing. I'm in mid-Year 2 now, and I've done a Duna orbiter+rover, sent out a couple probes towards the other planets for later, got one on the way to Eve, saved Kerbin from an asteroid on an impact trajectory, and built and ran a Mun base for a year before it was consumed by the darkness. Today it was a pretty mundane launch: a scanning satellite for the Mun so I can figure out where to put my next project, probably some sort of factory-base to test various ISRU features. So this first post is less to brag about accomplishing a cool thing and more to introduce what I've got — since not a lot of people do 10x Kerbin at all! I am voiding the warranty on all the mods here. Any reports are made in test installs; everything in this one is my bad. ----- ----- The Ausnan B is a lifter that sits on the pad at 240T and puts 7T into LKO. (Pretty typical ratio for my setup; I leave the SMURFF dials at 0.5.) I love building lifters, but this one is absolutely atrocious to fly. Fortunately I got a nice picture with the Mun and Minmus up there. (All images are links to imgbb where the full versions are.) Small bummer: the same fix for Firefly that starts the re-entry plasma at a reasonable altitude for real-sized systems also makes all my lifters glow as they ascend, with sketchy results. Upper stage burn. The engines like to flicker, sadly. And here's our ejection, nicely framing just how huge Kerbin is here. (The sun is KSS2's.) SigmaDimensions' inflated ScaledSpace textures make the Mun look a little ugly on approach... ...but Parallax takes over when the Munsniffer gets a bit lower. (Honestly, I had originally installed it just to prevent massive lag spikes while in PQS range of the Mun — it's doing its job for that well, at least!) One insertion later — mission success! Scans are in and the northwestern part of the East Crater seems to be our most favorable landing site for trying out ISRU with as many things as possible.

Not easily or conveniently. You could try messing with the ScaledVersion{} in its OPM .cfg, but that's probably a bad idea. You might be interested in Minor Planets Expansion's ReEeloo bonus folder, which has its own take on it.

This should be more-or-less possible with the right bumpmap. Take a look at RSS Origin's Arrokoth — try downloading the Core (which contains the required PQS plugins) and TNOs pack and checking it out. I can't speak for what the gravity field of such an object would be like in KSP — it probably won't be accurate?

-removed-

Probably not. The porkchop tool's departure calculator seems to always be off from the estimate, even for an Earth-Mars transfer with the default bodiesSolarSystem config loaded. MFMS (must've had the flight simulator on the brain last post) will usually produce a better-looking maneuver for the situation (I got a 1.1 km/s departure burn, matching your results with your config), but that's assuming the genetic algorithm doesn't just randomly decide to forget its "best" solution.

Why does the genetic algorithm's "Best" value sometimes (and quite randomly/erratically) increase again? Was it wrong about what the best solution was? It's very disheartening to see MSFS appear to converge on a good value, only to go wildly off and report something with gigantic delta-v cost because "Best" just shot back up.