PocketBrotector

Per suggestion by @dboi88, this will be a place to discuss development of KSPedia and wiki documentation for @RoverDude's MKS.

I am seeing these issues even with USI Tools 0.8.6, and AVC is telling me that everything is up to date.

This is an issue that I'm dealing with as well. It seems that the various life support tooltips and windows in the VAB are not consistent so there's not a great way of seeing what hab times, etc., one is actually going to get. I have been using Alt-F12 to get into orbit to find out what the actual in-flight values will be. This also helps to plan out power requirements, since there is currently no way to see how much electricity is required for habitats. Here is an overview of the readout issues using a craft with just the three stock parts: Recycler readout in the part tooltip always reads 0% Hab multiplier shows up as zero in the VAB life support summary Hab time (kerbal-months) per part is inconsistent between part tooltip and life support summary Total calculated hab-time does not reflect in-flight value I'm also still trying to figure out what the CrewCapacity value in ModuleHabitation represents - it doesn't always reflect the part's actual crew capacity (see the cupola), but I don't know how it's incorporated into the overall formula for total habitation time.

SoundingRockets has a 20EC radial battery you may like

Quick note for anyone using this in conjunction with SpaceY but not HotRockets... The SSR HotRockets patch uses FOR when it should be using NEEDS, which makes ModuleManager think that HotRockets is installed even if it's not. This will cause missing plumes in SpaceY and probably other mods as well.

No dedicated forum thread as it's just an effort to promote interoperability between existing mods. Part pack support/configuration for USI-LS is best implemented as pull requests to the part packs themselves, I think - the repo I created is just a place for me to share the configs as I work on them, or if the mod's not under active development on GitHub, etc.

Yes, but it's out of date pending the new balance guidelines

Per RoverDude the balance guidelines will be issued when ready - once that's published I plan to update my configs for Nertea's stuff and a few others. The crew cabins don't seem like strong candidates for additional hab-time - they already get some effective hab-time by virtue of their crew capacity, and additional time is generally for parts that are unusually bulky and/or heavy for their crew capacity. So the Hitchhiker Can, for example, gets additional time while the Mk2 Crew Cabin does not, because the former is a larger, heavier, more fragile version of the latter.

These are some neat parts! I especially like the 3.75m command pods. Looking forward to seeing more. I noticed that the mass ratios on these fuel tanks was not consistent (either with stock or with one another), so I put together a rebalance patch to adjust the mass, capacity, and cost of these tanks. Operating from the premise that anyone interested in using LqdHydrogen would already have Nertea's CryoTanks, I converted all of the tanks to LFO so that the CryoTanks fuel switcher could do much of the tedious math on my behalf. As an added benefit, this means that we can use the tanks any way we want now - e.g., you can fill an orange external tank with LFO, should you care to. I also added some tankage to the adapters, because why not?

Unfortunately both of these would require me to have some understanding of how meshes work, but I don't The issue with the new Mk1 command pod is that the node is in the right place (to preserve backward compatibility) but there's a big dumb hemisphere sticking out of the bottom. This means it'll clip through anything placed underneath - heat shields are most obvious, but also e.g. the boattail-less Pug engine. Moving the node just means that there will be an awkward gap between the pod and whatever's below. The "right" fix would be to flatten out the bottom of the pod so it sits flush on top of everything.

I have a feature request that may or may not be in-scope for this mod... Apparently since 1.2 off-world monoliths grant a research node when approached for the first time. However there are reports of receiving empty nodes this way - even in the stock game this is an issue as searching out monoliths can grant you Experimental Motors, but obviously in CTT the issue is more pronounced since it's more likely that we'll have a large number of empty nodes for the monolith to (randomly?) choose. Would it be possible to force the game to choose a non-empty node when granting free tech? ... and I see you've already addressed this issue, literally as I was typing this. Belated thanks in advance!

Yes, now that I compare it to the other decoupler configs in this mod, I can't actually see any difference. Nor can I see anything of interest in the log when the part is loaded. Still, it doesn't show up in the VAB - though if I delete the StockReplacementAssets config, it does show up normally... As far as I can tell, the only other thing that's affected by recent versions of KSP is that the decoupler/heatshield thumbnails are screwy. Not sure what the fix would be there.

If there was ever a crucial mod that cried out for a community patch, surely this is it... And here it is: - Old versions of overhauled parts are hidden - They are removed from the tech tree. In existing saves, this does not affect nodes already purchased - They are removed from all categories in the VAB and SPH - They are retained in the game files so active craft will still function normally - Testing contracts are added to overhauled parts (copied from old part versions) - Part variants are renamed to distinguish between them - Attachment ring engine variants get a -A suffix - Boattail engine variants get a -B suffix - Compact engine variants (not published) would get a -C suffix - Old part variants get a -Z suffix - FilterExtensions support (overhauled parts are added to the Squad category)

Is anyone else experiencing the 2.5m separator go missing here? Doesn't appear in my VAB even in sandbox mode. A quick look at the config suggests that the mesh is being simply removed rather than replaced.

Thanks for getting this all in one place. Discussion of the part overhauls as they exist currently can be hard to find. It looks like no one has yet assembled a complete integration patch for the overhauled parts - this would need to address the following: Hiding or removing the old versions of overhauled parts Issues with testing contracts (adding contracts and name variants to the engines) Optionally converting the engine variants from separate parts to switchable parts via a plugin Is this correct? If so I may try to put something together. Worth noting that this is also available as part of a larger Stock Replacement Assets pack by the same author, @hoojiwana! Porkjet's Habitat Pack and Atomic Age mods now have community patches by @Deimos Rast in the form of PorkWorks Continued. (Implementation details differ between the updates provided by Deimos Rast and those offered by @Tokamak.)

I suppose now would be a good time to mention that I gave RoveMate-equivalent KerbNet access to the TET and TET-G cores, which are the pizza-box-shaped ones, on the premise that those are probably meant to be rover bodies. The IKOTET cores are the heat-resistant circular ones ("24-sided" in the configs), which are presumably meant for... aerobraking? low solar orbit? high noon on Eve and Moho? Not a problem per se, but just wanted to check if this was intentional.

Tha ambiguity is whether a "Probe" Control Point can be used to enhance control of a crewed vessel. Which would make it a misnomer, that's all. Sort of like how KSC can provide full control via Remote Pilot Assist even if you don't technically have any pilots in the Astronaut Complex.

Well, sort of. The nomenclature is never really explained, but it seems to refer very generically to the ability to use one's antenna connection to a remote "control point" to upgrade from limited to full control. The control point is typically KSC, but it can also be a vessel with a Probe Control Point and the required number of pilots. The naming for these features leaves something to be desired, as I'm now wondering whether it's possible to use a Probe Control Point to upgrade a crewed vessel from limited to full crew control.

After much digging around, my working theory is that it allows vessels controlled exclusively by non-pilot kerbals to upgrade from "limited crew control" to "full crew control," allowing you to create maneuver nodes. You'll still need a local source of SAS in order to not hate your life, though, so you're probably bringing along a pilot or probe core anyway (not to mention an external antenna, if you're going beyond LKO, or transmitting science). This is evidently what the enigmatic "Remote Pilot Assist" feature refers to when it appears in command modules that require crew. Incredibly obscure! (I feel sort of awkward for answering my own question, but then again I did wonder about this for days before posting, and I only just now thought up something that I could test...)

Internal antennas aren't combinable and can't be used for transmitting science (or relaying signals) - their only purpose is to provide short-range control to unmanned craft. It makes sense that probe cores would include an internal antenna, but why command pods? If you have a command pod with a kerbal inside, then the kerbal provides control and the pod's antenna provides no benefit. If you have a command pod without a kerbal inside, then you're not going to have control even though you have an internal antenna - unless you have a probe core as well, in which case you can just use the probe core's internal antenna. Either way, the pod's antenna still provides no benefit. So why include the antenna module in command pods at all? Is there any circumstance in which it would have any meaningful functionality?

I believe it's actually the opposite - once upon a time we could only transfer crew by clicking the hatch, but at some point Squad decided to take pity on folks who wanted to add hatchless crewable parts, so they added a Transfer Crew button to the right-click menu. Eventually they made use of the feature themselves with the Mk1 Crew Cabin - the only hatches for that part are covered when the top and bottom nodes are attached to anything, which would trap crew in that part completely under the old system (hatches would be both blocked and covered, preventing EVA or transfer respectively.) That must be it then. I'm basically ignorant of the modeling side of things in KSP, so while I had heard about centrifuge mesh issues I hadn't realized it would cause the whole program to blow up. From what I could tell in Tokamak's thread, he never got the centrifuge working either as he couldn't modify the relevant files (though he was considering making his own from scratch). I don't mind having USI tools as a dependency since I'm already using USI mods anyway... but since Tokamak appeared to be bundling rescued parts from several mods all together, I figured the patches by @Deimos Rast would be more focused (particularly since I was using his updates for Atomic Age and several other mods already). Also I was probably mistaken about missing items from the right-click menu on inflated parts. I think I must have actually been losing control of my vehicle completely because I was transferring crew out of the orb and into inflatables, and the latter lacks ModuleCommand... Edit: I see now that there was much discussion of the broken drag cubes during the six months that I was away from KSP... shame on me for not catching up on the thread when I came back.

I noticed that these parts, when inflated, lose pretty much every option in the right click menu. I was still able to transfer crew by clicking on the hatch though. Unfortunately the centrifuge is causing my copy of KSP to crash to desktop. Everything works "normally" in the VAB (well, I get the usual issues of a fast-spinning centrifuge that can't be stopped) but KSP crashes upon either launching or reverting the flight (I only tested a couple of times before I decided to avoid the part altogether). I am on a Mac if that makes a difference.

There is a typo in several of the LS part configs that causes them to be listed under Fuel Tanks (I think that Tanks is a fallback category when parts aren't correctly assigned one). I reported it here. And here is a workaround for the meantime: @PART[Fert_Tank_*,USILS_*,*MiniPack,LS_Tank_*]{ %category = none // Fix typo: "Category" should be "category" }

Not exactly. For some reason it appears that certain parts (possibly mod-introduced parts) are triggering BCA right away while others (such as Mk1-2 pod) require the place-delete-place behavior that you're describing. Here is what I got after placing a Taurus HCV pod, deleting it, placing a Mk1-2, viewing the crew, deleting it, and placing another Mk1-2. (Forgive the screenshot of the console screen - I assume that there's some way to get an actual text log output, but I haven't dealt with logs much so I'm not familiar.)