PocketBrotector

There are known issues with the colliders for the ladders/hatches that you can read about in the last few pages of discussion. Apparently they're not likely to be fixed except by the original mod authors.

You make a lot of good points, but I'd like to clarify one thing in particular: when I referred to an "unimplemented style standard", I was referring to the standard that was unimplemented, not the style. I don't disagree that they are certain art style(s) in the base game that new parts should ideally adhere to, but the very fact that we're still complaining about the 2.5m oil drums, and all the other remaining archeological layers, means that there's no implemented unifying standard. There was one planned via the rocket part overhaul, yes, which would have brought the rocket parts in line with Porkjet's style... but we've received zero indication from Squad as to whether they're still pursuing that in any fashion. We simply have no idea what their priorities are here - that's why I personally have hopes for better and more consistent art, but no particular expectations.

In the interest of keeping the conversation respectful and productive, I suggest that you avoid dismissing others' comments as "kneejerk reactions" and instead respond to them on their merits. Particularly as you admit that your own arguments were incomplete - it's on each of us to explain and defend our positions clearly to each other.

Pretty sure that was me (via Reddit); and I have to say that the detailed discussion, and relatively respectful disagreement, in this thread is way more useful in helping me understand what the objections/critiques of the new parts are. If it's really as simple as showing wear-and-tear on the textures at high zoom, and a few other fairly fine details... well, I'm not assuming that the previewed versions of the parts are completely final. They were presented with minimal commentary and so it's an open question whether or not Squad still intends to do finishing touches on the textures, or the models for that matter. I personally am more interested in the other information conveyed by the post (i.e. we are getting official 5m and 1.875m parts) than I am concerned about the question of whether those parts as they exist at this point in time are perfect, especially given that we have no idea when all this is going to be released. That's not to say that it's wrong to critique the work as it stands right now, but rather that we should at least be mindful of the possibility that the critiques may become moot as they may have been planning on changing or refining the textures anyway. It also occurs to me that the DLC, which is explicitly a historical-replica pack, may not be following the exact same style intentions as the base game, which is much more focused on mix-and-match Lego-style modularity. (Certain stock parts are fairly explicit in their influence, such as the Mk3 shuttle or 3.75m SLS parts, but many others are pretty generic). We've seen a hint of that already, with indications that the LEM is going to have built-in RCS and some internal LFO storage; to some, that's heresy, but personally I'm okay with the notion that some content is going to be slightly more purpose-driven in the DLC. It's entirely possible that the textures of the Saturn tanks are going to be influenced in the same way: if they're explicitly intended for use in an expendable launcher, perhaps it makes sense that they have a clean paint job with no wear-and-tear. (That's not to say that this hypothetical approach won't have it's drawbacks - perhaps the new parts won't fit in seamlessly with base-game parts, which would be a bummer.) Lastly I understand that it's painful that Squad has been in a state of radio silence about whether the rocket part overhaul will ever be resumed. But that was the case for months before these DLC parts were previewed, and there's no reason to believe it's going to change anytime soon. We can rake Squad over the coals for having an inconsistent art style if we want (and the criticism would be warranted in my opinion) but the scope and stakes of the hypothetical overhaul would be a lot larger than just fuel tank textures - among other things, it would replace the existing engine balance entirely by adding new engines and adjusting the roles of several existing engines, not to mention move from a tankbutt-based system to a clusterable surface-attached paradigm. That would be welcomed if it happened, but we've been given zero indication that Squad still intends to move forward with these enormous, fundamental changes to the way rockets would be constructed in KSP. We don't even know if we going to have to live with the godawful 2.5m oil drums forever. So given that I'm resigned to the wildly inconsistent existing stock art for the foreseeable future, I'm okay with evaluating these parts on their own rather than comparing them to an unimplemented style standard.

I eventually got tired of fiddling with different values to keep this satisfactorily updated, but if anyone is still interested in the last version of the patch it should remain available here: https://github.com/LouisB3/LB_KSP_Configs/blob/a5eb4971c6a3e1f288994032a7efd81b94c0814e/Deprecated/MicroSat_Rebalance.cfg

The old LFO orbital engines were replaced in part because they were too good at everything. If the Isp on the new monoprop engines drops, are we at risk of balance swing too far in the opposite direction - that is, they won't be good enough to compete in their intended role? My impression is that monopropellants are used for real-world orbital engines because the low-ish specific impulse is outweighed by other engineering advantages (e.g. hypergolic; storability) that aren't modeled in KSP. So if a Near Future Spacecraft engine has appreciably lower Isp than a stock Terrier or Poodle, the player might not have a compelling reason to use it. (Except, of course, because they look much cooler...)

Just wanted to drop in and say bravo to everyone working on this. Once upon a time, I myself tried creating a "compatibility layer" between KPBS and UKS... but I was hampered by a lack of texturing skills and I struggled to keep up with the combined development speed of both mods. So it is great to see others in the community have apparent success here.

Not sure. I've used them unshielded on Kerbin launches without issue but never tried reentry with them, let alone on Eve. But if you're willing to put up with boil-off, you could just use a regular lifter tank without active refrigeration. Ascent shouldn't take more than a few minutes, and not much propellant would leak out in that time. You would still either refrigerated tanks to store the liquid hydrogen prior to refueling, or the converter capacity and ore storage to produce it faster than it could boil off.

I had forgotten about those. Hard to keep track of all the part packs out there - the only nuclear jet I've used is from Atomic Age, which is basically even more of a novelty than what you've described (not enough power to get anywhere fast, too heavy to haul anywhere.) It depends on whether you're willing to go with an gas core NTR, which offers much higher thrust and specific impulse than the puny solid-core NTRs we're used to. Kerbal Atomics has got you covered in a big way. Put some parachutes on one side and some legs and wheels on the other, and I'm guessing you'd get the bare minimum of surface mobility needed to load it into a Mk4 plane.

If you can already get it to 15-20km, you're dealing with only .25-.5 atm pressure from your air launch (according to the wiki). At that point a second-stage-to-orbit vehicle seems solvable with a high-end NTR. (Not sure how you'd get it back into or onto a plane or blimp though - some kind of KAS/IR/Konstruction gizmo?) Nice. I know that a Mk3 nuclear turbojet is on the roadmap for the Mark IV pack, though I imagine it won't be developed till Nertea's wrapped up primary development for Near Future Tech, which is still months out.

I think you've gotten at the crux of the problem here. Eve return missions are by design the hardest "normal" tasks in stock KSP. Even a fully expendable mission ends up being nearly as tough and/or complex as a "stunt" mission (e.g. SRB-only, SSTA, or minimum-mass, etc.) to a lower-gravity vacuum or near-vacuum body. Crewed return missions to multiple biomes on Eve would likely be the ultimate accomplishment for the kerbals' space program, undertaken only after they've explored and possibly colonized most of the rest of the solar system, if only because everything else would be so much easier. In the past I've mulled over what kind of architecture would be required, and the best I can do is along these lines: A base on Gilly to produce fuel and coordinate exoatmospheric operations within Eve's sphere of influence (i.e. recovering kerbals and science results from Eve's orbit after ascent A base on Eve at some high-altitude point to build and launch (disposable) ascent vehicles. This would be by far the biggest part of the operation, requiring lots of mass for the industrial effort required for extraction, refining/processing, and manufacturing One or more vehicles to get around Eve from the main base with crew and science equipment - probably a nuclear-powered prop aircraft for a combination of speed and endurance. It's a far cry from an SSTO, but it saves you from having to try to land on a mountain peak from orbit. I don't think that stock balance supports the possibility of an Eve SSTO without granting it a significant altitude handicap from launch - the performance of engines at 5 atm of pressure and 2g is basically insurmountable. Depending on how generous your interpretation of "stock balance" is, maybe you could do something like use electric propellors to loft an ultra-high-performance NTR (like the Emancipator from Kerbal Atomics) to a useful altitude (10+km?). That would be the Eve analog to a RAPIER-based SSTO: use atmosphere-specialized engines to get as much altitude and velocity as cheaply as possible before switching over to vacuum-specialized engines. But I'm not going to venture a guess on whether either the propellors or the NTR are going to have sufficient performance to make it work - and there are plenty of other design challenges involved, like surviving reentry and/or refueling once landed.

Very cool both in function and appearance. (I haven't seen very many translucent parts anywhere in KSP!) I was looking at OPM the other day and I was a bit disappointed that it completely overwrote rather than extended the stock balance for antennas etc. The special deployable relay is a lot smarter than my idea of simply using rescaleFactor on the stock fixed dishes, which would require either off-world construction or 5m+ fairings and launch vehicles just to launch a <3-ton part.

Very nice! I like that KSP's modding ecosystem now supports more than one execution of the sounding rocket concept (i.e. Taerobee and USI - though it's a tiny bit saddening that they're technically not compatible due to the slight difference between the .3125m and .35m size standards.) Spin stabilization via fin angling, and despin via RCS, both work fine. I do find the monopropellant consumption by SAS to be mysterious during gameplay though - the first couple of times I went up, I enabled SAS but not RCS, then I ran out of monoprop before I could figure out what I was doing wrong. (The VAB SAS readout does not display resource consumption so there's no discoverability.) I would suggest going with regular EC consumption for the SAS - at the start of the game you don't have antennas or reaction wheels for the sounding rocket, so the SAS is useless without the RCS, which is monoprop-limited anyway. And if you're worried about the early access to SAS being abused, well, it's moot slightly later in the tech tree when the OKTO is unlocked, anyway. (If anything, the early access to a lightweight probe core is more problematic for super-early balance, but it's necessary and still basically harmless.) Other than that, I noticed that my aerobee experiments sank when I splashed down, then exploded on the ocean floor... not ideal for recovery. I think that's because they're ten times more massive than the stock thermometer + barometer.

Everything seems to work fine in 1.2, though the decouplers are still in the old Structural category. If anyone is using this with Community Tech Tree, you'll want to put the 5m parts into Experimental Rocketry: I'm not completely certain that the Isp's of these engines are appropriately balanced - since the 2.5m engine is a booster, it should have relatively good atmospheric efficiency. That would mean that the central 5m engine is a sustainer, so it should have relatively good near-vacuum efficiency. Instead they're both just kind of inefficient everywhere - the stats don't seem to stack up favorably against the Twin-Boar or Mammoth. That said, there obviously aren't any stock benchmarks to balance 5m engines against, so I'll keep playing around with these to see what kind of niche they can fit into alongside SpaceY and the rest.

Now we're talking... If you launch a rocket from a zeppelin, that counts as reusable launchpad infrastructure instead of staging... right? In any case, I think that getting "free" altitude might be the key here. Eve's atmosphere is extremely punishing to stock-balanced engines - I spent a while looking at both aerospikes and conventional-bell heavy-launch engines from stock, RLA, Mk4, and SpaceY, but none of them had both the deep-atmospheric thrust to launch from Eve sea level and the Isp to get more than ~4500 dv before hitting the practical limits of the rocket equation. On the other hand there are Eve Optimized Engines, which I haven't looked into.

You've inadvertently revealed the next major phase of development for MKSpedia - localizations! First order of business: creating separate versions for British and American English.

I've just noticed that the DIRECT "Thunderstorm" SSME uses a different hydrogen/oxidizer ratio than Nertea's CryoEngines, which probably explains why folks are running out of oxidizer when they still have plenty of LqdHydrogen. It's a simple fix... //S3 KS-25-H “Thunderstorm” Cryogenic Engine //Use CryoEngines standard propellant ratios @PART[DIRECT_RS25]{ @MODULE[ModuleEnginesFX]{ @PROPELLANT[LqdHydrogen]{ @ratio = 1.5 } } } So between patching the fuel tanks, and the engine, DIRECT should now be fully compliant with both stock and the CryoEngines paradigm - though the latter would have a couple of extra dependencies: CRP for the resource definition, and CryoTanks for the fuel switcher (and boiloff effects).

It seems fine as is. Yes, the smallest greenhouse isn't enough for one kerbal - but only if you don't use a good recycler, which reduces supply consumption per kerbal dramatically, in which case large greenhouses are often massive overkill. Currently the inline recycler means you only need 21% as much Supplies, and the greenhouse mean that you can instead bring along 1/11 as much Fertilizer. Used together it's a substantial mass of equipment, but you need very few consumables no matter how long your mission is. Again, Roverdude is expected to tune this balance soon, at which case it will make sense to revise the wiki with a detailed strategy explanation.

Wow, lots of movement in the last day. It looks like folks are too enthusiastic to wait until KSPedia is finished before they continue work on the wiki, which is fine. I will probably wait until Roverdude releases his balancing guidelines until I update the USI-LS wiki. USI-LS is comparatively straightforward mechanically, so the tutorials there are basically an illustration of how to leverage the various multipliers to minimize payload mass - no reason to do all that math twice. Yes, I can take a look at keeping it up to date with the current state of the documentation, time permitting. What I may do next is make a list of the pages in the wiki currently and note which ones are currently maintained, abandoned, out of date etc. That should highlight what needs to be updated, still needs creation or more detail, deletion candidates, and so on. Hopefully this will lend itself to the coalescence of the docs into an outline like the ones proposed upthread, where there's a logical organization and natural progression of topics. Seconding this. EpL puts its "productivity" stats in the same place as MKS's efficiency/load, leading to lots of questions about which is which when people install them at the same time. MKS used to use a really complex efficiency formula that was almost completely hidden from the user, but that's been largely ejected in favor of a system based on the KISS-esque stock system (with added wrinkles like efficiency parts). EpL productivity is totally different and has a lot to do with kerbal stupidity - the only explanation of it I've seen is here, where someone created 3d graphs using matlab... yeah. We should probably point to that both on the EpL section of the Mod Compatibility page and wherever MKS efficiency is primarily discussed, just to disambiguate between the two systems.

This looks great and it reminds me that we need some documentation on how the Colony Rewards mechanic works...

Not lately, but I was one of the people who built it out much earlier in the year. It looks like DStaal and a few others had worked on it since then. Would need to be updated primarily to bring the values up to date to v0.5.x Fertilizer production in USI-LS is pretty simplistic - it just adds an Ore -> Fertilizer option to one of the stock ISRU. Gypsum and Minerals are strictly MKS. One more thought... we should make a pass through the existing pages and examine whether they should be incorporated into the updates or just deleted. There are a few that are blank, explicitly outdated, or have inscrutable titles/content. Based on the broken link in my signature I think that renaming a page is as good as deleting it, anyway, since it breaks all links (GitHub it seems is not as nice as MediaWiki when it comes to redirects). Supposedly GitHub wikis are implemented as repos, so if we "delete" anything of value, it should be possible to recover it afterwards with some digging... haven't tested it though.

Outline looks good and I imagine it will evolve as things are fleshed out. Earlier this evening I created a Resources reference/glossary that incorporates the flowchart and provides a (deliberately terse) description of each resource's relationship to its precursors and products. I will reiterate that I'd like to see documentation of USI-LS features primarily on the USI-LS wiki rather than the MKS wiki. MKS extends and expands upon USI-LS concepts, but there are plenty of people who use life support without MKS, and they need support just as much as the MKS users. Best not to conflate the two different mods as it will confuse the folks who need help the most. MKS wiki should point to the USI-LS wiki where possible for the following topics: Habitation - kerbal-months, hab multipliers Recycling Agroponics (Mulch + Fertilizer = Supplies) - this exists in both USI-LS via the nom-o-matics and MKS via the various ag modules Supplies, Mulch, Fertilizer Fertilizer production using Ore Advanced life support topics are specific to MKS and include: Medical bays and colonization modules Purifiers (recyclers that consume Water) Organics and ColonySupplies Cultivation (Dirt/Substrate + Water + Fertilizer = Supplies) and Agriculture (Dirt/Substrate + Water + Fertilizer + Organics = more Organics) Fertilizer production using Gypsum or Minerals

Read the last page of the thread, particularly Deimos Rast's posts...

The answer is really "both." MKS is complex enough that we need all of the above in the documentation: general descriptions of parts or resources, complete explanations of particular mechanics, and tutorials or strategy outlines saying "if you want to accomplish X, first you need Y and Z." I realize that this may not be the most satisfying answer, but that's what I think would be most beneficial based on years of trying to keep up with the mod. I've typically found myself wondering: Okay, what's the big picture here again? What are the things that I can ignore, and what's going to be absolutely required, based on my objectives? (Short-term life support vs complete self-sufficiency, research lab vs refueling outpost vs vessel construction, etc.) What does this part do now? And what are the differences between the Ranger, Duna, and Tundra variants? And what are the "hidden" requirements for full functionality - profession, efficiency parts, etc.? Oh, this produces [for example] Organics... what do those do again? Huh, this says something about "logistics" [or "inflatable", or "BulkConverter", or some other MKS-specific mechanic] but I can't figure out how to make it work... Can I just see an example of something that works so I can tinker with it? Even the specific quantities involved (e.g. the ratio of MetallicOre consumed to Metals produced) might as well be included since we're going to be looking at them anyway in the course of examining the part configurations. The limitation of the in-game description is that they're designed to be evocative or funny rather than deeply informative. If the Kerbitat claims that it provides "all the comforts of home," that's very colorful but it tells me exactly nothing about how it differs in practical terms from, say, the Colonization module. I try to think of it in analogy with the stock KSP mechanics. When I download a part pack that includes engines, I generally skip the verbal description entirely and look at the stats, which tell me the fuel efficiency, the thrust and mass, whether it's better suited for atmospheric or vacuum use... of course, before I could make sense of those stats, I had to get a sense of how the Tsiolkovsky rocket equation worked. Those are the mechanics of stock KSP; MKS has its own mechanics (resource chains, logistics, and so on), and so its documentation should explain the general strategy: "Build a Ranger base capable of life support before you tackle a huge Tundra base capable of off-world construction" might be the MKS equivalent of "when you're first trying to orbit, start out going a straight up and turn east very gradually..." the particular mechanics: "here's what you need to inflate that greenhouse" is the equivalent of "here's how you need to set up RCS thrusters to get full control for docking" the specific numbers: "this Tundra module has a better conversion rate than the Ranger module" is the equivalent of "here's why the Poodle is better than the Mainsail once you've reached space..."

The KSPedia work looks like it will make a fine backbone for the wiki... it would be primarily a matter of formatting for Markdown and then adding more details as desired. Like you said, it would make sense to wait until KSPedia is complete before converting it. The only other caveat I can think of is that basic life support (habitation, recyclers, and agroponics) should point to the USI-LS wiki, while MKS docs should cover the advanced life support (organics and colony supplies). Please feel free to use the flowchart however you you see fit. Once I created it, I found that the software wouldn't let me directly as an image without a paid upgrade, but it should let you create a copy in case you want to divide it into multiple sections or whatever. We could potentially fit more detail if there were separate charts dedicated to, say, basic & advanced life support & industry.