Frostiken

Okay thanks everyone for the responses. I'm not sure I totally get it though, but that porkchop planner did help by illustrating more extreme examples. Basically, that sliver is where it wants to do a polar dive over the sun, because of the inclination difference? I kind of feel like I need an MS Paint illustration of why this is the problem, and why for that very magical sliver of transit, a standard transfer is impossible... So if Mechjeb can't account for mid-course plane changes, what can? Should you just use the standard Mechjeb transfer planner, or is there something better? If you're using the Mechjeb system is it actually less efficient than it ever could be with mid-course correction? And what's the best point for correction?

PERFORMANCE. First, KSP1 has some kind of nasty memory leak that gradually grinds the game performance until you reset. Second, graphically, you do a lot to make the game look nice, but your framerate will just be awful. Third, the enormous RAM usage, the absurdly long 'render' times when approaching things, terrible performance with 400+ part space stations, etc. This is a concession of the wings we have. They can't really know how we have the wings used and they need to be dynamic enough for all sorts of usage, so... that's what we get.

Man I'm getting deeper into the tech tree and some of these engine ratings really stop making sense and hurt the game. Notably, aerospike engines. There's no reason for them to be ignition-limited. Ignition limits made some sense on lifter engines because of the amount of power in them, but an aerospike is, like, the opposite of fragile. Given the nature of aerospikes and their use in-game, having ONE ignition makes them basically worthless. They aren't actually lifter engines. Terrible. There's also a lot of engines that really do need more ignitions just by nature of their intention, for example, the Mk.2 Expansion has some chemical engines for spaceplanes/SSTOs. Obviously a single-ignition limit makes them worthless for SSTO, but, alas, the formula has rendered them purposeless. I love the idea and for the most part I find the concept functional, but when you run into situations - like with Aerospikes - where the feature essentially makes them worthless, I have no choice but to disable the feature

You can see that there's an efficient transfer but in the middle of it is a little sliver of inefficient transfer. I'm just rather curious what actually is causing that?

Hey thanks. Though... how do I deploy it? I only have a button to 'deposit resources', is that normal? What do I need to 'deposit'? Material Kits? Did I miss the documentation on this? The original post is beyond worthless.

Does anyone know how to get the RPM MFDs to work in the Fishhead? I noticed two things: 1) The TunaCockpit is the only one missing an "internal_RPM" file, and 2) In M2X_RPM_ASET.cfg, TunaCockpit is the only one missing a config. I added @PART[*]:HAS[@INTERNAL[TunaCockpit]]:NEEDS[ASET]:Final { @INTERNAL { @name = TunaCockpitASET } } But all that did was break the IVA such that you can't even go internal at all anymore.

Did nobody notice that the greenhouse module Kerbalism config grow rate is one decimal point off and takes five years to grow food?

NULL

This appears to have a conflict with Kerbalism. When an engine fails, the sound gets stuck and keeps playing a rocket rumble. I tested it by failing an engine with minimal throttle and you get really no noise... but if you full-throttle a failure you get stuck with this rumble. Although... when an engine fails on me in Kerbalism even before the mod, I had problems with the 'shaking' persisting, too, so I don't know if this is actually a bug caused by something else.

Soimething is wrong with the Konstruction Bay. I can't transfer crew into it. If I add crew to it in the VAB, their portrait is invisible in the bottom right. The Konfabricator works okay.

I just screwed up ANOTHER burn because the goddamn game decides I want to steer my rocket from the perspective of the backwards-facing docking node on the station part I'm towing into location. AAAAAAARGH.

Maybe I don't really understand EVA construction but for the most part I find it a pain in the ass, namely that I can't even place parts half the time as they're permanently redded out from some kind of clipping error, yet I can sometimes place them in insane locations that are clearly clipped. Are there any mods that free constraints on EVA construction?

Good grief, how did this mod get an update a few months ago and STILL doesn't include a methane configuration by default? People have been literally sharing code and asking for it for years.

Does anyone have the issue where the resource "MaterialKits" is basically stripped from cargo modules? In fact, my cargo container mods (esp. USI) are basically restricted down to just water, and food. I can't use anything else, Kerbalism injected its own code. This means I can't use ANY of the orbital construction mods, they all use MaterialKits, so I can't supply them.

Does the EVA Science Experiment still use the vanilla science system? Or is there something I'm missing here? I ran the experiments, and the Kerbalism science tracker shows 1.0x for the regions I ran them in, but it still shows them otherwise marked as 'available science'. It also describes biomes the experiement is impossible in, like flying high / flying low.

Man... is there like, a "diet" version of this mod? There's some really good unique stuff in here, like the deployable litter you can leave all over the surface, but there's also just so damn much crap it really clogs the parts list. I nearly had kittens when I, without even most of the tech tree unlocked, opened the VAB and saw like 891 capsules/command pieces listed, and most of them are these weirdo satellites and stuff. Or the excrementsloads of engines, like, I have enough engines without needing to sort through them. Is there a cut down version of this mod that kind of narrows it down to the more unique/niche parts only?

lmao I knew I wasn't crazy, thanks.

Even without a scientist the base flow of science is 0.05625.

So I've had a surface-deployed goo experiment running for 111 days on the Mun, and it's ONLY 2% COMPLETE. It has 4 power units available. 0.005625p/hr is the stated science gain rate. This cannot be serious. Is this serious? This is pointless, it's going to take centuries for this stupid thing to finish, what is the point?

I found a bug: GT wants to create files based on the name of the vessel. However, you can put invalid Windows characters into a vessel name, but it explodes GT when it tries to create/read those files. In this case, you can't put a colon in a file name, GT apparently didn't get that memo, so when you reach space, GT has a meltdown and spams the log with this.

Well, I still can't get functional behavior here. I use CraftManager, and my building strategy is to make everything very modular. Lifting templates in the VAB saves, payloads in the Subassemblies saves. EVERYTHING was made with KSP-Recall, which you said you were able to fix if the subassembly had been made with old versions. I attached the craft files and you can see that they have AttachedOnEditor modules. But loading the satellite from the in-game subassembly menu doesn't work. Loading the lifter from the CraftManager "load as subassembly" doesn't work. The root part of the lifter will be the US2 decoupler which is attached to the AE-FF1 payload fairing base. The root part of the satellite is a Spark engine attached to a Restock Octo bus. Craft file for satellite: https://drive.google.com/file/d/1qrUVE-qkuRL_qrfQlKWib_UWLLio8tc-/view?usp=sharing Craft file for lifter: https://drive.google.com/file/d/1gPz2g1NwFDIlLAaWoTMmRCytVGiPKZ2F/view?usp=sharing I don't get it. Did I miss something about what I need to do here? MORE: I just made a brand new subassembly, right there. Saved it as a subassembly, and then immediately tried to load it. It's right over there on the left, 'unnamed'. And it's all still broken. I replaced the US2 decoupler with a stock decoupler and it loads the subassembly. Reverted back to US2 and it's broken. There is no AttachedOnEditor module for the US2 part in the .craft file. Checking my satellite, I have 23 parts, but only 16 occurrences of 'AttachedOnEditor', and there's no US2 part, but there are Restock parts. Recall has NEVER and IS NOT applying AttachedOnEditor to modded parts. So, what, is every single craft that uses modded parts irreparably broken and unusable now for subassembly loading? I wanted to say this in that last post, but I changed my post to try to fully understand the situation. With all due respect, and I mean that sincerely: who, exactly would "everybody" in this situation be? I have never, ever heard of this problem. I have never, ever seen of any issues that were related to it. I've never seen anybody ever talk about it. I believe you discovered an actual problem that used a hacky fix, but I also believe that what you are doing to try to fix it is at this point causing vastly more damage than whatever 'problems' could have arisen from Squad's fix. It's as if we have a table with a little wobble in it, and you didn't like that we just shoved a napkin under the leg to even it out, so you disassembled the table and are chopping at it in your workshop and at now the table wobble is gone, but the table is a foot shorter, half its size, and sometimes tips over completely, and you're saying that we just need to buy brand new chairs to accommodate the shorter table. I still don't understand how a crappy Squad-level fix is somehow worse than the fact that Recall effectively says that any old saved ships are effectively trashed. Whatever problem was behind the scenes never manifested as an issue for me in my entire 12 years of playing KSP, until you tried to fix it, and now things have come to the point where calling the current version of KSP Recall (and by extension: Tweakscale) "A mod that will completely break your game" is fair criticism. We've spoken a lot before and I respect the work you do and the service you provide considerably, but this is tough-love. You're very clever and skilled but we're going on several months of hacking together a series of broken fixes to repair a devastating problem that was entirely induced by an attempt to fix a problem that as near I can tell, you're the first and only one to have ever noticed or cared about fixing. Is this just the Sunk Cost Fallacy? Because I would at this point just say to roll everything back, and never touch it again. Pretend you never saw it. Leave this underlying hacky fix where it's been for the last two years. There is a certain degree of trust that the players need to have in modders, that they will A) Keep players informed, and B) Not break their games, and I feel like that trust was violated here. I feel uninformed because you've basically turned us into QA testers for four versions of your mod that are so clearly broken, you should have caught it yourself, so how on earth did we get to version 0.2.2.2 and it still isn't fixed? If you said "here's a working version on Git, let me know if you have issues", I am informed. When you push a stable release to CKAN, at least three times, to fix a bug that does not appear to have ever been fixed in any version, what is this besides completely untested, unfinished versions being willfully pushed to the public for us to figure out all the problems for you? And second, the game is broken. Yes, most of it works, nothing appears to be permanent, but when a major core feature of the base game is genuinely unusable for four versions, that's bad. That's really bad. If Modders had a Hippocratic Oath, that'd be one of the things you never do. Break your own mod, fine. Break the base game, no. I've rolled back Recall to 0.2.0.6, before this mess was unleashed, and I will be unlikely to ever update Recall again. If after four version releases we're still dealing with clearly broken features that appear to be totally untested, when will a version of Recall be released that causes permanent damage in some fashion? I have no reason to believe that that couldn't easily happen in the future. I'm sorry.

Oh it looks like the code to replace them is in the PF-Everything mod addon.

Things I like about this mod: - Makes for nicer, smoother fairings. - More customizable colors. - Fairings are persistent debris parts with collisions. Things I don't like about this mod: - It replaces the stock fairing parts, including the stock fairing build method. Why not just make new parts? - Interstaging, honestly, is too complicated and I don't understand. The default fairings you just dragged them to where you wanted and clicked, and your interstage fairing was done. How am I expected to conjoin a fairing with, say, one of the MH Soyuz capsules to smooth it out? - Fairing bases themselves are not colorable. TBH just making the fairings new parts and not replacement would address the problems. In my opinion it's bad form to replace stock parts completely outside of texture/model replacements, or some kind of overhaul where that behavior is expected.

Is the stock science box supposed to have hard drive space? There's an upgrade that seems to suggest it should, but mine does not, only slot space.

Fingers are crossed for an authorized update from the author. I'd love to see 'folders' added to this, and some way to save subassemblies directly as subassemblies (so you can edit them without screwing everything up). This is seriously one of those "indispensable" mods I can't play without anymore.