AccidentalDisassembly

Not sure what you're referring to; I am aware that the stock patches on the github repository aren't supported, hence they don't work, hence why I tried rewriting them myself. @Citizen247 indicated in his post that s/he was writing patches for the stock parts, and I was curious to know if he had has luck with the stock patches s/he was writing or already wrote.

Have you had any luck with the stock patches? I've tried the ones I found on the Kerbal Foundris github, and they don't seem to function. Meanwhile, I've tried rewriting them myself, but I can't get the retractable landing gear to , well... retract, or steer/sit on the surface of the ground/rotate... Ugh.

Unfortunately I don't know of any contract packs that spawn vessels... maybe this is why! I did see that Vessel Mover has a method for spawning vessels in the flight scene that works (I tried it), I don't know if maybe that could be incorporated into CC... then remains the problem of figuring out how to get the game to activate BDArmory's autopilot and Wing Commander commands (e.g. telling the plane to go to guard mode and move to a point, attack near a point, etc. like you can when controlling a craft or group of crafts)...

Hmmm, nothing seemed to work - I even created my own agent, just in case, complete with icons and whatnot. Unless it was set to deferVesselCreation = true, I could not even accept the contract - clicking on the green check mark at first caused a slight pause (but didn't accept the contract), then clicking on accept a second time made the contract disappear from the offered list, but not appear in the active list. Changing it back to deferVesselCreation = true allowed accepting the contract, but the vessel still doesn't spawn. I tried spawning using lat = X, lon = <number>, height = whatever, too; no dice. Made a new craft called SpawnTester, simply a drone core, battery, and some structural parts/wings, and that produced a similar error (although it did not then also cascade into BDArmory stuff, it seems): Strange... it appears that either A) SpawnVessel is just plain broken, it doesn't work at all, or B) Something with PhysicsRangeExtender and/or BDA is preventing it from working, maybe? I removed any other mods (VesselMover and HyperEdit) that I thought could conceivably have some impact on spawning; the only other mods in the install are Engineer and Editor Extensions Redux. Poop. Just out of curiosity - I assumed I need these contracts only on game startup? I have been restarting KSP with each change to the config, but wondered if I could avoid having to do that...

Been trying to make a simple BDA contract that spawns a vessel that you need to go kill. However, I can't seem to get the thing to spawn, and when it tries to spawn, there's apparently a cascade of errors in the log. Here's the contract config: Here's the errors from the log: Anyone able to tell what I'm doing wrong, by chance? KSP 1.9.1 with the latest release of CC...

Odd re: the difficulty settings. I never hear Squad mention things like this (and wheels, and heat, and ...) that seem to be very, very long-standing bugs - maybe this particular bug is new, I have no clue, but it seems to fit with a pattern of not testing/fixing basic things; I wish they would fix some of the basics of the game. You know, like silly things that have no effect on the game whatsoever, like the aforementioned wheels... /Rant Regarding surface extraction, what brought on my questions/comments was attempting to create a set of drills and ISRU patches that would produce a kind of "flow chart" similar in concept (but not in content) to the one used for MKS, and have parts and converters that sort of just "make sense". The idea being: drills are probably a little specialized; perhaps make 2-4 drills in total, one for Rock and MetalOre, another for Mopedantte and SomethingElse, whatever combinations seemed like they made sense. Perhaps adapt an oceanic extractor from MKS to pull in liquids, too - in any case, the goal was separating out a limited number of collectors and ISRU parts that abstracted purpose-built machinery to strike a balance between "one drill gets everything" and "one drill for each thing" - similarly with conversions. The end goal was some kind of sensible path to MaterialKits, Ablator, SpecializedParts, whatever. I got stuck, though, because of phases, but also because of things like "Alumina" (is that corundum/rubies/sapphires?), which "felt" like it should come from the more-abstracted, more-general MetalOre (or MetallicOre) rather than the ground, and because of the number of overall steps already set up on the ISRU parts... In short, I am really struggling to visualize the overall flow chart (similar in concept, but not content, to the one for MKS here: https://github.com/UmbraSpaceIndustries/MKS/wiki/Resources) - each time I tried to come up with something, it seemed to get extremely complicated (and not in the fun gameplay/challenge kind of way). So I wasn't so much looking for a way to eliminate a resource like Nitrogen, but trying to figure out how to make a flowchart that involves it sensibly along with a limited number of more specialized converters (seems like you are thinking about the same thing) that still make sense when things like Kerbalism are not installed. So I guess, long story short - is there some kind of flowchart somewhere that I can piggyback on, or refer to, or modify without reinventing the intended ISRU-path wheel? EDIT: every time I fix my garbled M o n a z i t e, it is changed to Mopedantte when I save the post...

Aha, OK, thanks. So presumably deleting the settings.cfg will allow the selected options to "stick" the next time I fire things up and choose the JNSQ_High setting? Sweet!

I've also had an issue with selecting JNSQ terrain details. The first time I installed JNSQ to try it out, I was able to select the terrain detail levels with "JNSQ_" just fine, I think. Now I get these errors when trying to select detail. The slider isn't correctly populated with text (it says "New Text" to begin, and when dragging it to raise detail, the JNSQ_ text doesn't appear although the correct number of steps in the slider is established..). Could some other mod/conflict be causing this behavior? These are the only [EXC I can see in the log, tried it on a mostly clean install... sadly, I pasted this out and then overwrote the log file on my KSP test install, sorry! And this, which seems to repeat each time I made an attempt attempts to increment the detail slider:

Works perfectly fine in 1.9.1 for me...

Couple of comments/questions as I've been playing with RR and JNSQ -- Many PLANETARY_RESOURCE definitions have "PresenceChance = 1000". Isn't this number expressed as a percent, 0-100? What does 1000 do? Does 100% mean "100% chance of being in at least one biome" and 1000% mean "100% chance of being in every biome" or something like that? The ISRU patch allows conversion of (presumably) gaseous Nitrogen, Hydrogen, Methane, etc. to Lqd______ form. However, some conversions use the gas to produce things - e.g. the CO2 spliiter uses CarbonDioxide, not LqdCO2. Right now, there's no way to convert Lqd_______ back to a gas. It seems like there needs to be an additional converter for each Lqd____ resource,; presumably you can make a gas out of the Lqd___ version without too much trouble in your ISRU if you can make a Lqd___ out of the gas. OR, the ISRU chains for certain things could be simplified and abstracted a bit to avoid having to have 10 converters purely dedicated to phase changes. Things like Nitrogen, Methane (etc.) seem to be treated as gases, but they are crustal resources in some templates and can be mined by drillomatics too. If those resources are meant as abstractions of three things put together: <resource>-rich solids, AND hypothetical gas vents (or gas pockets, or something), AND also ices you might find in a crust, e.g. solid CO2 on Duna, then ISRU chains could be simplified and made a bit more intelligible for the user by placing all of the non-Lqd forms as a "first step" in conversions, and generally reserving the Lqd forms for rocket fuels. For instance, there doesn't seem to be a point to having both Ammonia and LqdAmmonia (so far as I can tell! maybe I'm missing something); the phase change serves no purpose except adding complexity and an additional tank (same with LqdOxygen, which doesn't seem to be used by anything). For Ammonia, too, it might be possible to remove LqdAmmonia from some biomes (cold oceans?) and replace it simply with Ammonia just to avoid the second tank and additional converter that don't have a function right now. Possibly. Intake rates for gaseous resources, such as they are patched in to the air scoop (whatever that air intake is called), are very high - nearly instantaneously fills a tank. I think the effective intake airspeed being set to mach 8.75 when stationary is perhaps a bit extreme

FYI - GameData\ContractPacks\HistoryofSpaceflight\Missions\USAMissions\MannedMissions\GeminiMissions\Gemini-XII.cfg is missing a closing curly brace at line 103.

Yes, exactly - it's a Space Camp contract where you get to keep a certain number of the tourists after the contract is successfully completed.

Hmmm, the more I am playing around with this, the more lost I am - I do now notice a strange behavior on my save. To compare with my heavily modded install, I put KRnD in a (mostly) clean install to test it out. Works. Also seems to work fine with variants - fuel tanks retain their upgraded max capacity when textures are switched (stock part variant), for instance, and stuff like mastodon engines retain their new mass values when applying different mount variants, picking up & re-placing parts, leaving and coming back to editor, going to flight & reverting... However, on my save, it seems like absolutely no parts will populate the KRnD window with the part's stats/upgrade options in the editor - I click on the window, bring it up, then start clicking on all the unlocked parts I have; none cause upgrade options to show in the window (unlike the clean install). My save has a lot of mods, including TweakScale (which results in a very long list of blacklisted parts), but I *think* at least some of my unlocked parts don't have any of the blacklisted modules, but nevertheless don't seem to work with KRnD in the editor. My intention with the save was to allow upgrades of engines, so I used a custom MM patch to remove TweakScale from all engine parts. Still, none give upgrade options in the editor, including engines whose names are not in the list of blacklisted parts in the log. There are other things marked as "ERR" in my log re: KRnD and "no original-stats" for parts, like this: Could something else (other than blacklisted modules) be preventing the research options from appearing for all parts, or does it just so happen that all of the parts in my save have blacklisted modules (which is possible, I suppose)? Also - does KRnD malfunction with B9 Part Switch fuel switching and such as well? Just curious; I didn't see B9PartSwitch in the blacklisted modules settings file.

Could this kind of exception have effects on other mods/aspects of the game, or is it a harmless "nope, not going to work with that part, move along" kind of error? EDIT: Somehow this ended up under your post (time travel...?) - thanks!

Hi @linuxgurugamer - been trying to figure out some odd behavior in a save, and came across this in my log. I'm not sure if it's a real problem and/or meaningful, but though I'd pass it along. I don't notice any obvious issues with KRND yet, but haven't used it yet, either (on this particular save). Just passing this along in case it's useful. Error looks like this: Log is here: https://www.dropbox.com/s/lnckeho5og1ofcq/KSPLog_FlightTrackerEXC.log?dl=0

Found this in my log related to Flight Tracker (I'm using Earn Your Stripes) - unsure which thread to post in or if it's meaningful, but here it is: Log is here: https://www.dropbox.com/s/lnckeho5og1ofcq/KSPLog_FlightTrackerEXC.log?dl=0 There seem to be other issues going on in my save as well, trying to track down funky business...

Did not notice I do have some small feedback about the beta - plumes are not scaled correctly (down or up), and sometimes it seems like plumes are scaled in the opposite direction of the part - for instance, in this screenshot, I *think* the white fluffly plume is much larger than when the part is normal scale. It's from the Snazzy pointed side tank (separation motors), which is scaled down to 0.3m in the screenshot, normally 1.25m. On the other hand, the specific parts i tried (mastodon, kodiak thing, the snazzy tank) did not move around when reverting... so there's that

Hmm, I assumed I should grab it from the list of releases, here:

I downloaded the beta file to give it a whirl on my testing install of KSP, but it doesn't come packaged with 999_ScaleRedist.dll or any dlls inside the GameData/TweakScale folder - how do you actually test it out?

I think I understand a little better, but am still stuck on (at least) one thing. Maybe I am not understanding terminology, that's quite possible - and I'm probably about to butcher some terminology in what follows. I understand the idea that certain systems have operating temperatures - like they do in game now, e.g. NFE reactors want to operate at 1000k (or whatever the number is), and if you don't have enough cooling, they run poorly or blow up eventually. If you have a billion times the cooling you need, that part (system) still runs at 1000k. But what exactly is the operating temperature of a loop? The idea of "the temperature of a loop" really has me stumped. If it's something like "the average temperature of the coolant or the radiator parts" or something like that, then I am extra stumped, because I don't understand where I'm going wrong in my logic...: You have a "loop" with the 3000k reactor and a 300k snack machine. (I am imagining this as an actual circuit of pipe moving coolant around, but I think the principle would be theoretically the same even if you were talking about taking those two systems, which need vastly different temperatures to function correctly, and gluing them to opposite ends of a gigantic metal brick with radiating fins.) There's a coolant reservoir somewhere. It's ambient temperature. Ambient-temperature coolant starts there, then goes to the reactor. The inside of the reactor is a nice, toasty 3000k - its operating temperature. Once it achieves that temperature, its flux/heat output is 1000kW, so 1000kW of energy is applied to the coolant, which heats up. Toasty coolant (presumably close to 3000k and a volume determined by a bunch of math related to how much energy it takes to heat this magic liquid by X degrees) exits the reactor, then pipes through four 250kW radiators. After coming out of the radiators, the coolant has returned to ambient temperature. If it hasn't, then the radiators didn't actually achieve that rate of cooling, presumably. Now, still on the same loop, the coolant enters the 300k part, an insanely powerful snack fabricator whose flux is also 1000kW - applied to coolant, which then passes through four more 250kW radiators (so 8 in total on the single loop). Coolant is back to ambient temperature again, and it returns to reservoir. Loop complete. Every system is on the same loop; the only thing that seems to matter is flux in, flux out (and/or heatsink mass, if your design works just fine by spreading out your flux over time) - unless you are also proposing that the user should need to design the order of radiators on the loop, so as to avoid putting the 300k snack machine before the first set of radiators (in which case the super hot coolant would cook it). But if the order is abstracted, then I am not understanding why the "Loop operating temperature" is swooping in to level out the temperature (of the coolant?) - effectively making everything but the reactor suddenly become the same averaged temperature until the very last radiator in the loop, if you see what I mean. If I'm missing something reasonably obvious here, please don't feel obligated to explain it all - maybe just point me in the general direction and I'll try to figure it out!

OK, that makes sense - so the idea is that (assuming everything, even really high temp stuff, is on one loop), you would need to add a bunch of mass (large amount of coolant) in order for the high temp parts not to cook everything. This simulates the idea of "sure, you can stick the 3000k thing in the same loop, but you need a bunch of mass/you need to dilute that superhot coolant/whatever before it touches your more tender parts." That makes sense as a design tradeoff: more flexible = potentially more mass (probably), but scenarios with multiple kinds of heat sources = probably more efficient to be less flexible. If you did do one single loop, then, presumably you could just keep adding a combination of high and low temp radiators until you got what you needed in total? Would it be possible just to add only high temp radiators to the system and call it done - or is there another mechanic in play, e.g. "high temp radiators work really well when the coolant is hot, so they'll bring the loop down to medium temps just fine; but they work poorly when the coolant is medium temperature, so the total loop will be fine for the reactor, but will still be too hot for the other parts"? Seems like an interesting design decision. I would say that distance could be an interesting design decision too, simply because otherwise in theory I guess it would be possible to just cram a bunch of radiators into a cargo bay somewhere, I suppose.

Couple of questions about the Loops and such: As a new user who sees something like the screenshot for the first time, it makes a lot of sense - the 4 radiators and the engines are together on the same circuit; I assume the fact that the lines are green means the thing won't overheat (barring outside factors). It does make me wonder - is there any meaning in the order of connections on the loop? is there a "direction" to the loop, where one of the radiators is "first" - and if so, does that have some kind of effects? It seems like it doesn't, based on the description, just curious. Since distance isn't factored in (system is perfectly efficient), it's possible to assign all systems on the ship to one loop, right? (I'm going go ignore OutputTemperature for now.) Then, from the quote above, what I understand is: if you put parts on separate loops, overheating part A on loop A won't affect nominal part B on loop B. But if you can only assign a part to one loop at a time, and if you also can assign all parts to a single loop, I'm thinking of a scenario and wondering how it would play out: Your ship has a nuclear engine loop as pictured, on EngineLoop, with exactly enough cooling (-2000kW?). LSLoop has a life support system (+1000kW) and 2 radiators (each -500kW, for the sake of argument). One radiator on LSLoop is destroyed. Now the life support system can only run at 50% capacity; you're on a long trip, half your kerbals will die. Or maybe it can't run at all without sufficient cooling - however that works. Regardless, EngineLoop is untouched. Another accident destroys the second radiator in LSLoop. Life support is inoperable, maybe, or just really, really intermittent or something. More Kerbals die. EngineLoop is still happy. But now: If you had placed all the heat generators and all the radiators on only one loop when designing the craft, there would be an advantage: you can run the life support if you turn off the engine, and maybe you can even run both at the same time (with the engine at 50% power). Is that actually how the loops are envisioned to work? If so, what's the reason for ever opting for more than one loop? Sorry if I have missed something ! Moreover, a single loop would seem to always be more efficient: you can design a single loop to have cooling for the total number of systems that run at the same time (which is maybe < all craft systems, e.g. engines and drills don't run together). But if you take the loops to the extreme and do 1 system per loop, your cooling requirements grow to the total possible heat output of all systems, not just the output of systems that run simultaneously... thus more radiators/weight. If instead each system on the ship is forced to be on a different loop, then you're just forcing the second condition in (5), effectively simulating "We didn't put any valves in the coolant tube network." Or something. I feel like I am missing some step in the logic here, maybe, so if I am, sorry to waste time. Regarding OutputTemperatures: I get that some parts might have higher OutputTemperatures than specific radiators could handle - just curious as to how that would play out. For example: can you just make a single loop on a craft, and add at least X number of high-temperature radiators to that loop to accommodate the "special heat" produced by those parts (the abstraction of really hot coolant)? Or do you effectively have to have something like a nuclear reactor on its own loop with high temp radiators? So is the idea that you now need one loop for "special heat" and one loop for "normal heat"? Re: heatsinks - if heatsinks (more volume) is a thing, presumably that means "lots of volume/mass of something whose temperature is raised in proportion to the heat & flux of coolant" (i.e. slowly heats up over time, starting from ambient). If they exist, then wouldn't normal temperature radiators (in enough quantity) be able to handle high OutputTemperature coolant?

Hooray! I think extending it will indeed make it a lot better, and also easy for people to write tech patches for their parts / mods / TS Companions too!

I agree, but there are two things I'm proposing. One is simpler, and it is related to how TweakScale addresses exactly the kind of scenario you describe. I agree, tech is not linear. But look what happens in your scenario - the problem is that TweakScale does not allow for scaling the part <some degree> smaller than its original size when you unlock a tech, it unlocks a specific numerical value or multiple because it ties specific numerical scaleFactors (or percents, with free/surface) to specific techs. Your example illustrates the need for relative logic in TweakScale. Scenario: Assume you have unlocked FUSELAGE_2_5 and, as you say, you have not researched in the direction of Advanced Light Materials and Advanced Materials (for now), because the tech tree is not linear and you made choices. You unlock Precise Tooling. The problem: you CAN now scale FUSELAGE_2_5 to 0.625m, because the SCALETYPE defined the scaleFactor "0.625" as becoming available with PreciseTooling. Second problem: you can't solve the problem by using free or surface scaletypes either (which multiply), because Precise Tooling would unlock a specific multiplier. Expanding: You unlock FUSELAGE_2_5, then go for Precise Tooling. Logically, Precise Tooling applies to more than just fuselages, I agree. Nothing stops you from writing other SCALETYPES that reference Precise Tooling. Furthermore, logically, researching Precise Tooling should have some effect on FUSELAGE_2_5, because it lets you build smaller things. But: there's already a problem. As you say, the tech tree is not linear, and you have opted for Precise Tooling (for now) instead of Advanced Materials/ Advanced Light Materials. Because Precise Tooling is assigned to the value 0.625 in the SCALETYPE (while AM is assigned to 1.875, ALM is 1.25), you can in fact scale FUSELAGE_2_5 down to 0.625m, but you can't scale it to 1.875m or 1.25m, because those are assigned to different techs. This makes no sense - how can your tooling let you make it 75% smaller, but not 50% or 25%...? How can only one of these three related techs allow for so much scaling? It would seem reasonable that researching Precise Tooling should nevertheless allow FUSELAGE_2_5 to scale smaller than its original size (relative to its defaultScale) - let's say one size smaller (or whatever), or 1.875m. ("One size" here is defined by whatever increments are in the SCALETYPE) - but not already to 0.625m, because the other techs aren't researched. TweakScale simply can't handle this logic right now. Now let's say you research Advanced Materials (on your way to Advanced Light Materials). Advanced materials should give additional improvements in miniaturization: it should allow you to scale FUSELAGE_2_5 further, but not to some specific, arbitrary value. This is what I mean by relative logic. "Further" in this case is relative to how much you can already scale the part - you can already scale it down X amount / X steps, to 1.875m, so this additional tech should allow you to scale it further - to 1.25m. Then, you unlock ALM - now, finally, you should be able to finally scale it to 0.625m. But because the tech tree is not linear.... what if you START with Advanced Materials? Here, the problem appears again from a different direction: it's not a question of writing another SCALETYPE or TWEAKSCALEBEHAVIOR - we need relative logic that allows for adding "more and more scaling" from tech research meeting some criteria (specific nodes, total science spent, whatever). This is why I am proposing the ability to allow a part to scale "by an additional amount in X direction," or "more / less," or "more scaleFactor increments", or whatever, by unlocking tech nodes - allow nodes to add an amount of additional scaling ability to the part, not a specific scale. There is a second part to what I am proposing: Another but: Assume the tech tree is linear enough to avoid the problem in that scenario. You now have to write many, many SCALETYPES to account not only for types of parts (fuselages responding to Precise Tooling, robotic parts also responding to Precise Tooling...), but also for specific sizes of parts, and also account for where they appear in the tech tree. The number of SCALETYPES/TWEAKSCALEBEHAVIORS is prohibitive, even with stock, let alone with mods/modded tech trees. Continuing the scenario: You unlock FUSELAGE_25, but you're using a modded tech tree. Now, Precise Tooling, Advanced Materials, and Advanced Light Materials may or may not exist, and they may or may not be at positions in the tech tree where they make sense. That's a problem already, but not a big one; you could write patches to account for modded tech trees. But now do this for every part and every mod.. again, an astronomical number of configs. What if you had another fictitious part, ENGINE_50, and you wanted things to work like this?: Unlock ENGINE_50. Precise Tooling, AM, and ALM all allow for improvements to this engine - researching one of those allows scaling to 3.75m, then researching another allows 2.5m, and then finally 1.875m with the last one. But now, assume there is no specific tech node in the tech tree that makes sense in terms of making the engine bigger. And: with modded tech trees, I have no idea what tech nodes even exist in the tech tree, or where this engine is even located in the tech tree. So: I still want research to have an effect on how large the engine can be scaled... But the conditions for allowing larger scales need to be not absolute references to names of tech nodes: instead, something like "any tech node meeting certain criteria", let's say. One of those criteria could be: "if you research any tech node that branches off from the part's own tech node (a "later" related node, shown by an arrow in the tech tree), then you can scale ENGINE_50 up one more size (to 6.25m, maybe)". Or, another criterion could be: "If you research any tech node that costs more science than ENGINE_50's own tech node, then you've probably made some discoveries that are relevant; allow scaling up one (more) size (to 6.25m, or to 7.5m, depending on what else you have done)." Or, another criterion could be: "The next size up for this engine is unlocked after spending X total science on techs after unlocking ENGINE_50's tech node" (which also captures the idea of interdisciplinarity, non-linearity, etc.) If you implement this kind of possibility (in addition to what is already in TweakScale right now), there is a side effect: you can have a default behavior for tech and size limits that works for every part regardless of tech tree and position in the tech tree: If you default to "allow this part to scale up or down one additional size / <x> additional percent for every tech node unlocked by and researched after the part's own tech node", then every part in the game has some kind of tech progression built in, it's all roughly logical, and every mod part in existence instantly CAN have tech limits applied to it without writing a million SCALETYPES/BEHAVIORS. It's very hard to describe what I'm thinking in text without visuals and tone of voice, unfortunately, sorry! I am not asking for a restrictive change in how TS deals with scaling + techs, only an extension. Let me know if there's some way I can be clearer, I am finding it very hard to describe what I mean!

I use AVP and it produces a similar effect at the main menu, not quite so saturated colors, though.