AccidentalDisassembly

Think you do NEEDS:[AirplanePlus,TweakScale,OtherMod,OtherMod] (I believe commas mean "AND" in context...)

I'll remember not to make the mistake of trying to contribute in the future.

Fair point; in any case, a lot of it is a matter of taste/designer's preference, there's not a "right" way. Either way, though, I don't see the point of introducing another resource for maintenance unless some kind of progression is established that's different from what's already there. Otherwise it's just (yet another) thing to keep track of in order for the base to do what it's already doing at the same moment it becomes capable of doing so. Seems to me that MaterialKits (as they are now) would be the logical thing for a wear-mechanic resource; you can start there (3 resources) and then move up (5 resources) in order to build stuff, maybe.

Still, though, since GC is involved, you don't progress on the planet, right? You ship in GC stuff from Kerbin (upcoming potential modifications to GC notwithstanding). Inflating existing modules, OK - in which case it could make sense (just as an example) to make MatKits the thing needed for maintenance. But there are still no tiers: you're still shipping in everything from the homeworld here; MatKits save mass, I guess, but they don't create anything alone. Still need all 5 resources simultaneously to create anything new (and "progress" in that sense, as opposed to unlocking existing things).

Well, maybe I'm confused because I don't understand what you mean by "resource contention" or "resource conflicts," then. What (potential) conflicts are you talking about...? Maybe I'm reading the flowchart (http://i.imgur.com/YYDXetX.png) wrong, too, or not understanding how things work in current versions (this seems pretty likely to me, but what the heck, here goes anyway). Just in case I've understood the flow chart, though, here's what I get from it: 1. Substrate, MetallicOre, and Minerals are used for Polymers, Metals, and Chemicals. Those three things are used to create MaterialKits and nothing else (I'm ignoring life support in all of this). 2. Silicates and RareMetals or ExoticMinerals (why are there two here?) can be refined to Refined Exotics and Silicon, which combine to make Specialized Parts. 3. MaterialKits AND SpecializedParts are required to build base components / crafts like rovers / whatever, aren't they? And, furthermore, Machinery is effectively in this same tier, because no additional input is required to fabricate it. Or am I going off the rails already? So what that means in practice is that you need all 5 of those resources simultaneously to actually do something, since nothing can be done with MaterialKits alone or SpecializedParts alone. You can do nothing without all 5, and you can do everything at once with those 5. 4. That means, effectively, that when it comes to things other than life support, there are no tiers. There is an immediate need for all of those resources at the same time and all of the converters that work with them. 5. I'm proposing that this doesn't make sense from a gameplay perspective IF (if!) you want the narrative to look like Send a small colony ship -> set up maintenance so you don't die -> now turn attention to expanding base --> base expands and can do more -> does more (complexity increases, # of resources increases) -> now can build its own interplanetary ships and stuff. If you're already mining everything, there is no progression on the planet. If there is no progression possible on the surface of the planet, there is no bootstrapping, there's only fully functional bases that can then build bigger fully functional bases. Depends on what you're going for; I had the impression that you were going for progression/bootstrapping. 7. Without a form of progression on the planet, the wear mechanic will only functionally amount to an additional refinery or a different button to press on an existing refinery in order to produce a different (maintenance) resource. It's just another thing you have to do all at the same time in order to make the base function; another number in the mix to balance against others. To my mind - again, I'm guessing there's a lot about MKS in its current state I don't understand, so there's that - it makes more sense to limit the number of resources and place them in a progression. Doesn't prevent you from shipping in a complete base; does allow you not to. There are a million ways to do this, I'm sure, but maybe something like: - MetallicOre and Minerals (what is the difference between a "Mineral" and "Substrate"? What is Substrate supposed to represent here? Is it just to increase the number of resources you need to mine to make MatKits...?) combine to create crappily-titled TierOneParts. TierOneParts are consumed to maintain the base, and they can build additional base structures if there is a surplus. - OR, alternatively, TierOneParts are used to maintain things only. - By adding an additional resource or two to the mix - Substrate or Silicates or whatever - now you can create TierTwoParts. If TierOneParts are only usable for maintenance, TierTwoParts can be used to construct things, but not all things. Things like drills and rovers so you can go find the next resource you need. - Now that you have maintenance/ability to construct stuff, you go find and mine ExoticMinerals (what is the difference between an ExoticMineral and a RareMetal...? they both seem to refine to the same things...), you can build SpecializedParts. SpecializedParts in combination with TierOne/TwoParts are what you use to build fancy things (I don't know, science labs? rocket engines?). None of that makes sense if you're thinking in terms of "realism," or what materials actually get used to build thing X in real life, but it makes sense if you want the player to be able to go land an outpost on a planet and have the outpost advance on its own (which is not precisely equivalent to getting bigger), in which case the wear mechanic can be part of that advancement and distinct from other Gather-Refine-Combine-Consume chains because of its temporal order and its place in the hierarchy of complexity.

Sure, completely agree, then everyone's happy. =) The difficulty settings probably fix that worry, unless I'm misunderstanding here. So you're saying there just needs to be added a setting that changes the existing mechanic to break parts rather than lower efficiency? But here: why? What is the diference between a "ReplacementPart" and a "Machinery" and a "MatKit"? They are all things you manufacture in order to put together other things. They are conceptually identical (so far). The only reasons to distinguish them is to (A) make players have to get different ore/dirt/whatever from the planet in order to manufacture them, which ideally means (B) there is some progression involved, e.g. at first you can only maintain your base; then, with the addition of another resource, you can build new parts... But concerning the idea of wear and tear, it's not logically coherent to have one mining pipeline for things that fix stuff and another one for things that make stuff. All that does is make an additional resource necessary (if there's any difference in how one or the other part is made) OR force the player into using multiple recipes to create products that should be interchangeable - I mean, if you can manufacture Machinery, and you can manufacture MaterialKits, why can't you turn your Machinery into Material Kits? And if there's one specialized resource required for expanding a hab, for instance (meaning: adding parts to the hab), and another specialized resource for keeping things running (Machinery?), and another specialized part for overhauling things (ReplacementParts?): why? Why is replacing something different than replacing its parts? Why is manufacturing parts that make something expand different than manufacturing parts for some other base element? They are conceptually the same thing (in terms of their place within the overall concept of the mod) with distinctions for their own sake. Or, in short: Why not just have one resource for constructing and maintaining basic things? Perhaps the incentive not to run out of said resource could be (after a grace period) would be that, if it runs out and your stuff "breaks" or wears out, you dun screwed up and you have to use more of that resource than you normally would to get things back in order? That accomplishes (my interpretation of) what you want, I think. The point I was trying to make earlier with this whole wear and tear mechanic is that it's meaningless in terms of gameplay unless it fits in to some kind of narrative/progression involving bases [edit: or space-based habitations, or the idea of colonizing, you get the point] - at a place in the hierarchy of "base stuff" that other things don't already occupy. Something like this (although I recognize there are probably holes in what I'm saying): 1. At the beginning, you send a small base and crew to a faraway planet. The first thing you have to do is prevent all the kerbals from suffocating and all the parts of the base from wearing out. At this stage, there are perhaps 2 or 3 or 4 (or however many you think is actually fun and challenging to go deal with at this point) different planetary resources in play: the stuff that makes life support stuff (if you have that turned on), and the stuff you have to combine to create Machinoreplacmenparteny for the base. 2. When you have a surplus of "stuff you've manufactured that goes into base bits," which is to say the exact same stuff you use to keep your existing base running, because they're still conceptually identical - if you can manufacture replacement parts for a drill, you can manufacture a drill -, you can build more parts for your base, perhaps ones that allow for more kerbals and more mining. Now, however, you start to need additional resources (in some vaguely coherent order of ascending complexity and difficulty) to make your base capable of doing increasingly interesting things. You start mining these new resources in addition to the ones that keep the base functioning. Now we're talking 5 or 7 resources or whatever. 3. Eventually, in order for your base to be "fully" functional, you add new parts and new capabilities, which lead you again to a higher tier of resources (or however you want to think about that). Now your base can do it all! The meaning of the wear and tear mechanic in my example is that it is the first (and therefore more attainable) step in the overall progression of the base [or deep-space explorer ship or whatever]: the precursor to the wider processes for which it is a pared-down model. If being able to address the wear mechanic is simultaneous with other processes used to make the base a base, then it's just an additional set of resource gathering needs, and an additional set of recipes, and so on, not meaningfully different from others. In which case, why not just cut through the clutter and make one recipe for "the things you need all at the same time to make your base not die" with many planetary resources included?

It makes sense that you'd have to arrive with a cache of spare parts / life support to hold you over, or ship some in shortly, yes. However, making maintenance and basic construction materials difficult to obtain is the exact opposite of bootstrapping. Bootstrapping suggests using a small starter base (sure, I guess it could be temporary) and its capabilities to progress to larger more complex bases. In other words, bootstrapping IS fabricating on site. So if you want bootstrapping (as opposed to shipping in bits and pieces constantly), you have to have spare parts and basic building materials be first: if the machines don't run, you can't get anything else working. It would make sense to make fancy, exotic things harder to obtain (science stuff, labs, fuel refining, I don't know), but drills and habs and refineries and workshops are the first elements of bootstrapping (ergo maintenance materials too). One logical progression would be something along the lines of (A) Base drops, (B) While burning through starter materials, acquire capability to prolong life support (if it's on) and the life of the existing base (meaning replacement parts), (C) Use the existing base to build more parts for itself. In this case, the actual practical outcome of the wear mechanic is the need to set up this first set of gathering/refining/production chains as a precursor to others. Once it's established, you add more resources/refineries etc. to the mix and things get progressively more complex. Missions from the homeworld would accelerate that process quite a bit, of course, or you could just shoot an entire 500-ton base into space if you want. It depends on what you mean by bootstrapping and the way you think that should translate into gameplay. If you want the gameplay to look more like (A) Drop base, (B) Figure out resupply and expansion missions for years, enhance base/ship elements from homeworld during that time, (C) NOW it's self-sustaining and can expand itself, that's a different way of looking at it, and of course it's up to you. In this case, though, the wear mechanic only means additional mass on the supply missions, for that phase of the base (and one more resource to keep track of) -- until the base can do things on its own, at which point it would come to mean another resource gathering/refining/production loop in addition to the others.

My two cents: 1. The wear mechanic needs to be simple. MKS is already complex. 2. On that note: making a distinction between "small" parts and "large" parts adds complexity for complexity's sake. Attempts at logically distinguishing what "should" and "should not" be reparable will be masochistic and won't add anything to the gameplay. (Why can't small machines be maintained with a resource called Machinery? Or, if ReplacementParts are used... are they not parts meant to replace others...?) 3. Never being able to "refill the health bar" or adding part lifespans also adds complexity for complexity's sake and stretches logic in an aggravating way for the player. If you run out of spare machinery pieces or ReplacementParts or kits full of materials, sure, the machines will probably stop working after a while. But if you ship in (or make) more machinery etc. for the base, it makes no sense not to consider that act the one that makes parts work again. Unless your purpose is to force players to go manually replace things with kerbals every so often (why?), it makes mores sense to incorporate the wear mechanic into the overarching challenge of MKS, which is the process of making a base self-sustaining, not performing individual acts of maintenance as a kind of janitorial duty rather than getting a resource or building something for the base overall. 4. The resource used to keep rudimentary base things going (like drills for resources) needs to be the easiest (or nearly the easiest) to create, because it's the condition of possibility for the rest (if you turn on wear). I can't remember how to make Machinery (there are so many resources!). Hopefully it's somewhere down at the bottom of the tree of things that get combined with other things to make stuff. Seems to me that wear should either use an existing resource (Machinery?) or combine Machinery and ReplacementParts (and maybe even MaterialKits) into something else. For the most part, those things are not meaningfully different on a conceptual level in context. Things that can wear out consume the resource every X time from any container on the base. When there's no more, parts' "health" counts down slowly from 100 (or whatever). (Perhaps) after reaching 50 or some other arbitrary number, efficiency begins to drop (= grace period). When it hits zero, efficiency either bottoms out (and the base is still minimally functional) or things shut down, based on a setting as you described. The nuance could come in the form of better/worse parts consuming more or less of the resource, or wearing out slower when they're out of replacement parts, or (maybe) having different efficiency floors unless the difficulty setting says otherwise. Easy that way for a player to determine (A) do things wear out? [OFF/ON] and (B) how much does it suck when things wear out? [0-100 suckiness], IMO.

Hmmm... Interstellar Fuel Switch maybe? All I can think up is that there are two models/textures fighting because of the absence of a switching mod, or some related problem, sorry.

My guess: you don't have the associated part switcher (B9 part switch, or maybe firespitter, or something) installed.

The short answer is: nothing.

Right, but what does that mean in terms of the properties of a parachute that FAR recognizes? I've tried manipulating cfg files in order to produce parachutes that do more/less, but it has no effect. RealChute's (full version) own scaling method doesn't seem to have much effect in FAR either.

Any ideas on the parachute issue I mentioned earlier? Properties of parachutes in CFG files don't seem to make any difference to how they perform. What is FAR looking at to determine what kinds of effects parachutes will have? Is it possible to make modded chutes compatible with FAR?

I did not! wonder what all of those are about...

I'm having a strange issue with MKS drills in the editor on my (heavily modded) 1.3.1 Win10. When I first click on an MKS drill (but not stock drill) to select it in the editor, the game freezes for a second or two. At the same time, many instances of this line appear in KSP.log: [LOG 20:03:52.822] Found 14 overheatable modules And many instances of this appear in the outputlog: Found 14 overheatable modules (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) The duration of this short freeze *seems* proportional to the number of separator slots in the MKS drill, and is not noticeable with stock drills. Then, a much longer freeze occurs when trying to place MKS drills using symmetry. After picking a drill from the parts list, dragging my mouse on to a part of my craft will cause the editor to freeze at the moment the game switches between "part is picked up by the mouse" mode (or however you'd say that) and "part made real/created in editor and placed on another part" mode. This pause is not noticeable (I don't think) when placing a drill without symmetry, but very noticeable with 2x symmetry and seems exponentially longer with higher symmetry numbers. Dragging a strip miner on to a craft in 4x symmetry freezes the game for 10-15 seconds or so. Loggery: KSP.log - https://www.dropbox.com/s/jfp962ydk9b8plm/KSP_MKSDrills.log?dl=0 output_log - https://www.dropbox.com/s/ugk3zhs5oz8d35p/output_log_MKSDrills.txt?dl=0

It does, so far as I can tell (am using it), but it does not automatically transfer experiments from DMagic (possibly others, dunno), just FYI. It runs them, but doesn't reset the experiment/transfer the science to an appropriate pod.

Huh, I was just thinking this myself. I've had roughly the same experience; I don't understand the use case of the cryo engines over others. They *seem* to have lower TWR than most and to require vastly more tankage - not just somewhat more. Their higher ISP doesn't *seem* to balance things out to where they're preferable, but maybe I'm also missing something. I'd like to figure it out though! Is there some situation where LH2/Ox is the better way to go?

It's possible you're missing a part-switching mod - I think this issue can sometimes occur when the absence of a part-switching mod (like B9PartSwitch or Firespitter or whatever) means that the editor scene doesn't hide alternate textures or meshes that are supposed to be hidden. Or something like that.

Did a little searching, didn't find anything, so in case it's useful, here is a patch that (probably, kind of) makes the Buffalo wings (and other aero parts) work more nicely with FAR: @PART[WBI_BuffaloWingType1]:FOR[FerramAerospaceResearch] { @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 !dragCoeff = DELETE !deflectionLiftCoeff = DELETE !MODULE[ModuleLiftingSurface] {} %MODULE[FARWingAerodynamicModel] { %b_2 = 2.34375 //distance from wing root to tip; semi-span %MAC = 1.6875 //Mean Aerodynamic Chord %TaperRatio = 1 %MidChordSweep = 0 } } @PART[WBI_BuffaloWingType2]:FOR[FerramAerospaceResearch] { @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 !dragCoeff = DELETE !deflectionLiftCoeff = DELETE !MODULE[ModuleLiftingSurface] {} %MODULE[FARWingAerodynamicModel] { %b_2 = 1.1719 //distance from wing root to tip; semi-span %MAC = 1.6875 //Mean Aerodynamic Chord %TaperRatio = 1 %MidChordSweep = 0 } } @PART[WBI_BuffaloWingType3]:FOR[FerramAerospaceResearch] { @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 !dragCoeff = DELETE !deflectionLiftCoeff = DELETE !MODULE[ModuleLiftingSurface] {} %MODULE[FARWingAerodynamicModel] { %b_2 = 0.586 //distance from wing root to tip; semi-span %MAC = 1.6875 //Mean Aerodynamic Chord %TaperRatio = 1 %MidChordSweep = 0 } } @PART[WBI_BuffaloWingType4]:FOR[FerramAerospaceResearch] { @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 !dragCoeff = DELETE !deflectionLiftCoeff = DELETE !MODULE[ModuleLiftingSurface] {} %MODULE[FARWingAerodynamicModel] { %b_2 = 1.3394 //distance from wing root to tip; semi-span %MAC = 0.7232 //Mean Aerodynamic Chord %TaperRatio = 1 %MidChordSweep = 0 } } @PART[BuffaloWinglet]:FOR[FerramAerospaceResearch] { @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 @ctrlSurfaceRange = 0 @ctrlSurfaceArea = 0 !MODULE[ModuleLiftingSurface] {} MODULE { name = FARControllableSurface MAC = 1.0488 MidChordSweep = 27.6 maxdeflect = 15 b_2 = 1.1104 TaperRatio = 0.58 } } @PART[BuffaloCanard]:FOR[FerramAerospaceResearch] { @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 @dragCoeff = 0 @deflectionLiftCoeff = 0 @ctrlSurfaceRange = 0 @ctrlSurfaceArea = 0 !MODULE[ModuleLiftingSurface] {} MODULE { name = FARControllableSurface MAC = 0.5244 MidChordSweep = 27.6 maxdeflect = 15 b_2 = 0.5552 TaperRatio = 0.58 } } @PART[BuffaloElevon1]:FOR[FerramAerospaceResearch]:FINAL { @maximum_drag = 0 @minimum_drag = 0 @angularDrag = 0 !MODULE[ModuleControlSurface] {} %MODULE[FARControllableSurface] { %b_2 = 1.4208 %MAC = 0.747 %TaperRatio = 1 %MidChordSweep = 0 %nonSideAttach = 1 %maxdeflect = 20 %ctrlSurfFrac = 1 %transformName = Elevon4 %rootMidChordOffsetFromOrig = 0, 0.09375, 0 } }

For me, the problem exists either way. With BTW installed, the maneuver node DV climbs steadily. Without BTW, it doesn't... Log: https://www.dropbox.com/s/0ijppslqmrlwfgp/output_log_BTWnode.txt?dl=0

OK - But go look at what's in the ZIP that's linked to from the Hooligan labs thread (which is linked to in the OP): https://spacedock.info/mod/638/Hooligan Labs Airships What's in the ZIP is only the same Hooligan Labs folder (inside the WBI folder) that's included in the Heisenberg ZIP. This is why I'm confused. If you remove that Hooligan Labs directory from the WBI directory and place it directly in GameData, parts don't load correctly. HOLD THE PHONE. I may be stupid. One sec. I can confirm that I am indeed dumb. This is the cause of my problem. Don't know how, but confused the two ZIPs. Sigh... I wish I had a built-in posting delay that prevented me from making dumb comments on the KSP forum.

I have all of those things - I downloaded the Heisenberg ZIP, which includes Hooligan Labs (apparently) - I say this because when I tried to download Hooligan Labs separately, what was included in the ZIP was exactly the same as what was already in the Heisenberg/WBI folder. And I also have Firespitter installed. Is there some separate instance of Hooligan Labs other than the Hooligan Labs stuff included in the Heisenberg ZIP and also the Hooligan Labs ZIP?

Wanted to give this a try, but ran into a hitch - in the OP, you indicate that Heisenberg's airship mod isn't included. It sure looks like it's in the ZIP inside the WildBlueIndustries folder, though. When I install what's in the ZIP, run KSP and launch a craft, there seems to be no way to control buoyancy / any other controls I would associate with airships. Nothing on the app launcher or toolbar... Am I missing something obvious here? I would not be surprised if I were!

What are the characteristics/stats/whatever of parachutes that influence their effectiveness in FAR? I'm having a hard time figuring out how I could use MM to create a rescaled radial chute (for instance) that's both bigger and more effective. When I create one and modify the stats in the config file, it seems to have no effect on how well the chute actually works... In fact, the rescaled version with upped stats works worse because of its increased mass. This is with Modular Flight Integrator 1.2.4 and FAR 15.9 on 1.3.1. (Took out ModuleTestSubject from following configs for brevity.) Or, for another example, the stock radial chute : Actually works BETTER than this one from LETech: What am I missing?

Small bug to report, but don't know whether it's TS or FAR - when both TS and FAR are installed, along with FAR's patch which alters parachutes to have RealChute modules rather than stock parachute modules, scaling a parachute part has no effect on the amount of drag the chute provides - it just adds mass and visual size. Log, if that's useful: https://www.dropbox.com/s/pkyf6w07fkr9df4/output_log_FARchutescale.txt?dl=0 Dunno if it will be intelligible in the log, but to test, I put a command pod on top of an SRB with a non-scaled chute - descent speed 13.6m/s or so. Scaled the chute to 2x size --> descent speed 15.some m/s due to higher mass, no benefit gained from scaling chute.