King Arthur

@DStaal @Starstrider42 I see, many thanks for the insight. I was aware that resource distribution was based on a seed that was initialized at new game start, I just wasn't aware how static or dynamic the systems beyond that seed were. If everything is generated on the fly based upon that seed, then I can understand there won't be any major problems. Fortunately I haven't setup any immovable ISRU-related infrastructure yet, so I don't have anything to worry on that front. Will I need to perform a rescan with my resource scanner satelites, or will they be updated without my intervention? On a related note, is resource distribution in asteroids also generated on the fly like with planets? I understand that asteroids are handled like ordinary vessels in the save file, unlike planets which are on rails and not recorded in any way in save files. I got curious and took a look inside one of my save files, and asteroids have a "ModuleAsteroidResource" module with a saved value of "displayAbundance", so am I correct in presuming that KSP will generate resources in asteroids dynamically based on this number, changing composition depending upon currently active mods like CRP? I've captured a few asteroids in orbit around Kerbin and like 20 more tracked/untracked outside of Kerbin SOI, it would be a shame if CRP and similar mods only take effect for newly generated asteroids.

So I wouldn't have something like, say, "I installed CRP but the new resources (when applicable as dependencies) don't show up in resource distribution" and other such "variables initialized only at new game start"-esque shortcomings I often see in other games? Asking because I sincerely am not familiar (yet) with how KSP handles this, and a lot of other games usually choke or fallback on these modified-after-the-fact things. In any case, it's good to know that this doesn't seem to be the case for KSP and I can install CRP with minimal worry, if any. Thanks, this further opens up the range of mods I can try out now.

Would installing the CRP have any ramifications for an ongoing save file? I saw that the CRP messes with resource distributions in planets and asteroids, and I'm not familiar with how that system works as far as resource distributions getting changed mid-game. A few mods I'm interested in trying out have the CRP as a dependency, and I would like to know if the CRP is safe to (un)install on the fly.

Also having problems with soil recyclers demanding EC during timewarps at 100x and higher, despite running Dynamic Battery Storage. I don't mind it too much since it's mostly an aesthetic problem, though right-clicking away the messages gets old fairly quickly. I'm almost tempted to just remove EC consumptions from resource converter modules, which soil recyclers use... :V

I would need to mess with the CFGs since the black/whitelist is completely separate from the actual ModuleManager patching of stock part CFGs. I could whitelist the stock Vector for example, but unless I also remove or modify the 1.25m engines CFG containing the Restock Vector I'm still not going to get the stock Vector back. As far as I can tell, Restock would presumably still work if I were to just take out the black/whitelist system wholesale; it's only there as a RAM- and load time-saving measure. The actual stock parts replacement is done by ModuleManager CFGs, which are all centralized rather than individualized.

I don't think so, since my plan is to have both the stock and Restock heatshields side-by-side rather than the latter replacing the former. If that doesn't work out though, I'll make sure to replace the stock Mk1-3 too.

Roger that, appreciate the reasoning behind it. As a personal workaround, I'll see about taking the Restock heatshields and using them as a separate standalone mod rather than a stock-replacer for my own personal use with NFSpacecraft, since I find using the tweak gizmo for this kind of thing to be tedious and above all inconsistent. Thanks!

My impression of the SSME is mostly from this wonderful picture of the RS-25 SSME (courtesy Wikipedia): The stock Vector's plume is predominantly blue (perhaps too blue as it gets farther from the nozzle, I admit), whereas I find the Restock Vector's plume is predominantly red. This is going to be a case of YMMV, since everyone is entitled to their opinions, so I just prefer the stock Vector's take on the RS-25 SSME and find it more accurate as far as I'm concerned. I'm not raining on anyone, just to be clear. This is really just a matter of my own taste and thoughts, especially since KSP is more about just having fun rather than being 100% realistic. Restock uses a very different, more centralized file structure compared to stock and most other mods. Whereas stock and most mods organize parts by category>individual-part and keep the part's CFG and associated models and textures together, Restock centralizes assets (models and textures) and CFGs separately, and only goes as deep as organizing by categories (all the 2.5m fuel tanks' definitions are under one CFG and its assets all in one 2.5m fuel tank directory, for example), and the blacklist is similarly centralized in one file rather than individually defined per part. I can certainly see that I can pick apart Restock given enough time and willpower, but it's a lot more tedious than just removing the directory structure for parts I don't want.

I gave Restock and Restock+ a trial run to see if it's something up my alley. Personally, I found it a mixed bag. Some of the changes I really loved, namely most of the fuel tanks and some of the engines like the Twin Boar. Given that fuel tanks make up the majority of an average rocket (hah), the visual improvement really goes a long way. Clipping fixes for things like the Z-4K battery are also great to have. On the other hand, I hated the "foiled" parts like the HECS2 probe core and toroidal fuel tanks, and I found the stock Vector (specifically the plume) to be much more true to the RS-25 SSME than the Restock version. I also really, really, really dislike the Restock version of the Aerodynamic Nose Cone: Left: Stock, Right: Restock. The stock nose cone and Mk3 Cockpit are flush with each other, making a beautiful and smooth aerodynamic line, but the Restock version ruins it. Yes it's minor, but I find great pleasure in these small details lining up. Overall, I wish Restock was modular so I could easily pick and choose what I want from it. There's a lot of good and a lot of disagreeable stuff in here. I also wish Restock+ didn't have a hard dependency on Restock, because those parts (obviously) scratch an itch that stock (and even a lot of stockalike mods) doesn't.

So I finally bit the bullet and installed Restock/Restock+ for a trial run to see what it's like. As I found out, the restock'd-stock heatshields work perfectly with the NFSpacecraft command modules (stock heatshields otherwise have hideous clipping). While it is not my intention to sound ungrateful or anything, I would appreciate it if Restock was listed as a soft dependency if the expectation for NFSpacecraft (and other NFT mods...?) is that it's to be used with Restock. I'll leave my thoughts on Restock/Restock+ proper (if any) for its thread, as that would be ill-suited for here. :V

Gameplay. I feel anything that delves into remodels and spec changes should be a mod separate from stock (ie: ReStock+) rather than a stock-replacer. Retextures are great, they change nothing tangible, but model and spec changes not so much.

I'm a bit hesitant on using ReStock since, from what I understand, there are subtle remodels and respecs in addition to just simple retexturing. I would prefer to leave stock parts' gameplay as untouched as possible (additions to accomodate mods notwithstanding, of course). Not to mention that there seem to be a number of significant bugfixes waiting on a 0.2.0 release anyway, judging from its Github issue tracker. This isn't the ReStock thread though, so I digress. Appreciate the suggestion though! Was basically looking for a 4-man command and 3-man lander modules to make a slightly sized up "Apollo"-esque mission, but I ran into a dead end as far as using NFSpacecraft since a lot of it seems to be holdovers from before re-entry heating and all the newer (well, "newer") stuff in KSP nowadays. Love the rest of NFTechnologies, but NFSpacecraft is still waiting on a bit of modernization, I guess.

I'm kind of confused what the intended use-case for the command modules in NFSpacecraft is supposed to be. None of the stock heat shields appear to fit nicely (especially the Mk4-1), so are these in-orbit use only unlike the stock Mk1-3?

The Structural Fuselage is not a physicsless part.

Hitting CTRL+Z should allow you to undo stuff. Be warned though that this is very flaky, more often than not you will likely summon the Kraken for tea.

The music selection in KSP really reminds me of The Sims, personally.

^ https://en.wikipedia.org/wiki/Lockheed_P-38_Lightning Great minds certainly think alike.

Originally the piggybacked Mk2 shuttle was launched STS-style like so: However, that launcher is expendable. I wanted to make a recoverable, reusable launcher to cut down on costs, so I made those carrier shuttles. The Mk2 shuttle itself carries a crew of 6 and has a full-size Mk2 cargo bay for carrying stuff, as well as hauling other smaller ships around via its junior docking port on its underside.

Given that a lot of fuel flow logic and node handling needed to be rewritten with 0.90, among other things, I doubt that any of the MJ builds for 0.90 will work properly in 0.25.

^ Magnificent.

It's perfectly fine and normal operating procedures for smaller airports to have aircraft use the runway(s) as a taxiway, and even something as huge as the Boeing 747 can perform a 180 at the end of the runway. Granted, KSC is not a "small airport" given what its facilities are for, but yeah.

Choice #1 for everything. Except when I'm "simulating" stuff, then it's revert-ahoy.

I'll just leave these here: The above has since been succeeded by a B9 SSTO design as it performed better and proved safer to fly, as follows: They are both reusable carrier shuttle launchers for the smaller Mk2 shuttle that's piggybacked. ------ 1. Aerodynamic Nose Cone. 2. Mk2 wings can lift the Mk3. 3. Easy enough to make your own double-sized copy of the stock landing gear. 4. Mk3->2.5m adapter into multi-couplers/engines. 5. Same goes for all other stock parts, though.

Ah, I missed that part. My bad, will go and test that (and edit this post once I get something post-worthy). ---EDIT--- Mod present: KJR 2.4.5 -> 3.0.1 Steps to reproduce: 1. Made a new blank sandbox save, KJR 2.4.5 installed. 2. Launched Kerbal X to orbit. 3. Exited, deleted KJR 2.4.5, installed KJR 3.0.1. 4. Booted up KSP after KJR 3.0.1 install, loaded save with Kerbal X in orbit. 5. Switched to Kerbal X via Tracking Station. 6. KJR did its magic. 7. Nothing out of the ordinary happened. The end result was that, once again, KJR did not do anything bad or not intended to a pre-existing Kerbal X, in an environment where no other mods were at play. The logs: http://rpgmaker.net/media/content/users/6088/locker/245_output_log.txt http://rpgmaker.net/media/content/users/6088/locker/301_output_log.txt

This sounded easy enough to test and try reproducing, so I tried the following to see if KJR v3.0.1 would blow up a pre-existing stock Kerbal X: 1. Made a new blank sandbox save. 2. Launched a Kerbal X under pure stock, no mod (not even KJR) environment into a stable orbit. 3. Exited KSP and installed KJR. 4. Booted up KSP (with KJR installed) and loaded up the save with the Kerbal X. 5. Switched to it through the Tracking Station. 6. KJR did its magic. 7. Nothing out of the ordinary happened. The end result was that KJR did not do anything bad or not intended to a pre-existing Kerbal X, in an environment where no other mods were at play. The logs, even though I doubt they'll be interesting: http://rpgmaker.net/media/content/users/6088/locker/PreKJR_output_log.txt http://rpgmaker.net/media/content/users/6088/locker/PostKJR_output_log.txt