JadeOfMaar

Somebody never noticed GPP_Secondary. It's an optional mod that makes GPP: into a remote star system; not delete the stock planets. Knowing that, the recommendation is very good in your case. (Just be sure to delete its KSC++ stuff. You won't need it, and it has some recently reported issues that need fixing under Secondary mode). As far as keeping up with game updates is concerned, you're better off learning to not jump on the KSP release hype train, and stick with whatever good version of KSP for a long time. You seem like you have a very simple and straightforward vision for your game, so I'm sure that for you, the "new features" hype trains aren't worth your time. Say you start a game in 1.9. Don't update until 1.11 or 1.12 or a bug somehow occurs that ruins your playthrough. I've seen some nasty bugs come about in 1.x.0 releases then a 1.x.1 hotfix has to rush out after. 1.5.0 had the epic drag cube system failure 1.6.0 conflicted with ModuleManager 1.9.0 I think reverted a major issue that cropped up with wheels, again, but introduced the Atlas shader and its GPU-saturating goodness 1.10.0... well, a few serious things had to be fixed by 1.10.1 Notice that trend and resist getting into the flow of putting up with that. Where Extrasolar is concerned, it does misbehave with its visuals. I found an issue where its EVE configs will break those of another planet mod and I had to hack it somewhere. My case was special as I had GPP involved. So maybe the conflict is triggered by Extrasolar meeting a system replacer. Galaxies Unbound is very much WIP, though it releases in sections. Consider each section (each star system) of GU as a full release and stable enough to add to your main game. @StarCrusher96 takes absolute care to make his mod, and there is no other planet mod that promises both size and quality like his.

@OrbitalManeuvers The problem is that none of the KSC++ stuff is supposed to appear on stock Kerbin but they do. They should only appear on Gael. Your situation (Without Secondary) is fine. That's how it's supposed to be.

@OrbitalManeuvers GPP's KK stuff was never setup to not activate when GPP Secondary is installed. Evidently, nobody used KK with GPP Secondary so Galileo wouldn't know to deal with it. also, I only learned KK stuff during KSP 1.7 (for the relevant work in JNSQ) so I wasn't aware to do anything about this for GPP.

@damonvv @FatherOfGold The CC tanks config (which is in use, as I can see) is giving Tundra's tanks 2.2x the expected amount of fuel. I just fixed it and added life support switching to the mk3 and mk4 Starship pods. (idk why I didn't do the LS bit before)

@OhioBob No, that's not it. The player has GPP Secondary so the trees are on the wrong planet.

@lane1572 Those would have to be from GPP's KSC++. I'm surprised this was never brought up. They'll be dealt with. Until then, you can delete the GameData\GPP\GPP_KSC++ folder to make it all go away.

@Lisias @pmborg The second engine module is not rogue. It's supposed to be there. That's the vac optimized engine mode that the B9 switch targets. All the OPT WarpJet engines except SURGE have that second engine mode and the B9 Isp config...but I don't think they have the duplicate "Activate Engine" PAW button problem.

@Clamp-o-Tron I can easily agree on the mixed feelings. RBCC does sound quite powerful, possibly even OP, but there are a few points where I think it's ok to not worry too much: There's a price to pay for the lack of a turbojet phase in this engine. Rocket mode is going to be required at all speeds under Mach 2. And if you try to go around it, you're either bringing dead mass of jet engines into space or you're defeating the point of the engine (its ramjet phase becomes redundant where a Whiplash cluster is at peak performance). Unlike my SABRE rockets, RBCC needs to be very good ASL so it's going to lose out on vacuum efficiency. Well, we'll see how that goes. Being balanced explicitly to 2.5x+, hoping to see these used in RSS, and being largely advanced to the stock engines, they are automatically OP for stock scale. If anyone plays stock scale and comes crying OP then I'm not afraid to say, they are not in the target audience. There are several other great engines that'll help SSTO spaceplanes (or rockets) to get going: the 2.5m and 3.75m SABREs (with atomic version), the Mk2 scramjet and shcramjet, and the circular aerospikes and RDEs (not shown yet). There's a mod for X-33, designed to SSTO in JNSQ. This mod provides nothing to help SSTOs to survive in JNSQ. There's no OPT or Thor Tech handwavium going on here. Just chemical rockets that could have been and easily could if today's aerospace companies went all-out to develop them. The total roster of engines is over 30 now, maybe 40. And that's not including the separate intakes and the RCS package.

@Clamp-o-Tron Souptime just wants a mention in the README. Help'em out. As for your float curves, I fixed them. They looked pretty nasty as I expected. Also, add OSE Workshop to your recommended mods list. I'm pretty sure you don't want to ship a decaying solar panel in a KIS box. It might still decay in there. OSE Workshop allows you to build individual parts in-flight and deposit them into KIS.

That's a surprise. Well it's got to be something KSPI is doing. I know KSPI has its own propellant switch mechanism for engines, and pmborg's screenshot showed me that KSPI has attached stuff to the SAGE. But I dont know for sure if the actual KSPI propellant switcher is added to it (as KSPI has its own copy of that engine now). If not all that then my final guess is whatever bug is in the part config for my engine which causes two "Activate Engine" buttons to appear in its PAW. (When you have to engine modules and don't have the multimodeengine module.)

@pmborg As I said, the root of the conflict is that the SAGE uses B9PS to change engine properties, specifically, propellant ratios and the Isp curve (it clears properties and re-initializes the stock module due to how it works). B9PS doesn't communicate that level of complexity to Tweakscale, and Tweakscale has to deal with prefabs being restored on quickload or whatever (as Lisias would say) which Tweakscale doesn't handle well or at all. This solution (delete those two files) applies not just to SAGE but to any other engines that say they can exchange thrust for Isp. You may want to consider instead of WapJet SAGE, clipping in some WarpJet MARGE as they are compact and powerful near sea level. (These ones are actually scaled up a bit, I think) Or use the form-fitting Wrapper WarpJet FVT-L for Humpback body (but be mindful that its intake gets blocked due to the aero shielding radius of Humpback's cargo bays, and their origins being in the center of the bays). And personally MM them to have the thrust that you need. That's why I made them. They're made to be used on crafts like yours.

@Clamp-o-Tron At line 12 when you first add the decayingPanelsType key, you should remove the @ prefix. That prefix means it's already there (as if added by another mod) and you're changing it then. Side note: Remove the :FINAL pass markers. That's very bad practice because of how powerful :FINAL is. Don't allow that habit to form and grow. I honestly think you shouldn't need to use :AFTER or :FINAL at all. The only mod that could interfere with your patches is Kopernicus and it recently stopped its practice of renaming the solar panel module. If you indeed need to use :AFTER or :FINAL, consider using :FOR[zDecayingPanels]. I'll inspect those float curves when I can, and fix their tangents for you if they need it.

@RandomKerbal This might be what you need.

I've heard on a few occasions that Blender's layout, as-is, comes out of an engineering and technical efficiency perspective, which precisely isn't good for artists as they need things to have a "natural" feel and to be in the right place for them. Artists don't need to know keyboard shortcut chains and don't need these shortcuts to be available for everything. They need to have the most relevant tools, and in just enough context menus, and a proper arrangement of menus, to feel at home. I'm pretty sure Blender is the way it is because of just how much it can do, so the technical efficiency perspective works well for it and the user base that can handle it.

Lol

Pardon me. I don't want to sound like I'm trying to decide how you should make your mod, but, there are already many part packs out there that'll meet your needs, are finely crafted (either in looks or behavior), and do their jobs without ultimately producing laughably high thrust and Isp from stock fuel. Near Future Propulsion Far Future Tech KSP Interstellar CEDA Future Tech (WIP, unreleased) Photon Sailor (standalone, from KSPI) Solaris Hypernautics USI Karbonite Plus WBI DSEV Stuff I've made and may make soon™ A parts pack requires at least as much heart, soul, and knowledge of KSP's workings as does a planet pack so I don't think anyone would be disappointed if you take the energy you're budgeting to parts, and give it all to planet making. We have the parts already. We're just waiting on planets. Wormholes by nature are cheats, yes. But ask yourself "What are the downsides?" and you'll see that they're just as easily balanced off: It is unknown what the conditions are that would cause a wormhole to spawn in the first place. Whatever they are, chances are good that they are extreme and extremely rare. When or where they do appear, they provide a nice, much-needed shortcut between two places that are incredibly far apart. (Not a downside but a fair advantage actually.As a planet maker,) You're going to need quite some time and quite some engine in order to reach one anyway. As a planet maker, simply don't put many of them, and never put them near a habitable planet. Strategic placement means the world when choosing where wormholes go. If you provide 5 star systems, place only 1 or 2 wormhole bridges. 3 is too much. A good range imo, for the number of wormholes in an interstellar neighborhood is (At minimum: the cube root of the number of systems. At maximum: the square root.) Wormholes, warp drives, torch drives, and jump drives are all cheats, but all of these have equal and great disadvantages and great openings to fit together for an ideal interstellar highway infrastructure.

@pmborg @Lisias OPT SAGE is one of my engines which uses B9PS to change engine stats (in this case, Isp). The console problem is most likely an effect of Tweakscale not supporting such parts. A good means to confirm this is to either: Try tweakscaling any of the new VTOL series of OPT engines which can change propellants (IntakeAir + LF or IntakeAtm + LFO) (nearly al of them) or change Isp (any WarpJets except for SURGE)... So practically all of those engines. Remove all the tweakscaled SAGEs and add fresh ones (scaled if Tweakscale allows it), launch, and fire them just to see if the console doesn't spam. Delete the two "VIsp" config files at OPT_Legacy\MM_Patches\ If the problem is due to intakeAtm not having a DrainFX definition (unlikely, I think) then CRP's owners have some work to do.

Mk2 Engines I love spaceplanes. And I love spaceplanes whose fuselage have lifting surface, so there's a guarantee for an array of Mk2 shaped engines. Note: These are still in the (well-colored) 3D sketch phase. They're not at all playable yet. Linear aerospike Turbojets Scramjet & Shcramjet Linear aerospike My vision for the Mk2 linear spike isn't quite as beautiful as I'd like, but where it fails in style, it makes up in raw form. This one is designed to nearly make a seamless wall when stacked horizontally (so it tapers from Mk2 shape into a rounded rectangle). Such can't be done well or at all with the QuizTech engine (which I loved way back in the 1.0.5/1.1 days). I might revise this but I can't see how, as yet, anyway. Turbojets Mk2 Expansion's engines alone made me pretty happy. They've inspired the designs here. I've worked out how I'll setup vectoring nozzle action for these so they won't be static when gimballing. These are Whiplash-class engines and will bring much bang for the buck. The mono-jet (with 1.7m chamber) intends to have greater performance or be more versatile than the bi-jet but I can't decide what/how. I'm considering a rocket form to the uni-jet but there's a myriad of use cases to pick from and of nozzles to create to answer them. Perhaps I'll make an engine cowl/plate and call it a day. Scramjet & Shcramjet I was advised quite a bit where these are concerned. These are arguably the ones trying hardest to be scientifically accurate. A lot of care was paid to the intake and exit geometry to be faithful to the reference "Waverider" engine shapes and flat surfaces but also to deal with a conflicting awkwardness caused by the Mk2 profile. To those not in the know, a scramjet (upper row) and shcramjet (lower row) are very much not the same thing. In addition to Mk2, there will be a 2.5m scramjet, a 1.25m shcramjet, and the Mk3 RBCC engine (rocket, ramjet, scramjet) a few pots above. Mk3 intakes improved look The turbofan's blades are better now (vs the previous sketch), the shock cone will get to extend/ retract, and their lengths will now differ according to their assumed internals...or lack thereof. Matched Mk2 intakes TBA.

Ohhhh, thaaaaaat. I did not remember that.

I remember that way back with the engine reactor patch there would be no alternator since the reactor is used entirely to power the engine. Either the reactor bias (power source vs thrust) is completely towards thrust, or an alternator just doesn't fit into Nertea's vision of the anatomy of the engine. That's part of why I made RR's NTRs separate parts and not a modification to the stock NERVA itself. If their specs appeal to you, use them and tweak them. And I don't have to step on Nertea's toes by trying to undo any of his patches to the stock NERVA. RR strips out any resource placements that are not given certain tags, so it should cancel SMX's Eve LF oceans patch (and Ore oceans patch). The feature is missing, however, to protect or ensure, that SMX's pumps all can draw from the LF ocean. The air scoop shouldn't have ocean harvesting features now. I'm very, very sure I took that out when I made the hydroscoop. Really, thanks for spotting these things. The air scoop's modules have HarvesterType = 2 (atmosphere) and the hydroscoop's modules have HarvesterType = 1 (oceanic). The configs on GitHub appear to confirm that I didn't mess up.

Good timing. I'm burned out and hoping for your agency to go on cooldown for a bit.

I bet you're on KSP 1.10. Kopernicus is version locked, or should be, and is not to be expected to function properly (or at all) on 1.10. If you see Nyan Cats having a party, your game is already over.

Not a bug. According to your screenshot you have Configurable Containers installed. Once you have other certain fuel switchers installed (In your case, once you have any of Allista's mods, you have Configurable Containers) you don't get to use B9. That's how it is. But it helps to make sure you have OPT Reconfig 2.0.3 or newer as that's where I fixed the detection of Configurable Containers. OPT Reconfig is watching for this specific directory: GameData/ConfigurableContainers/Parts/ (which is actually just full of tank patches) to know that you're using that mod. Finally, the console info in the screenshot isn't at all helpful. The "simulation" stuff sounds like a life support calculator (confirmed by the presence of USI LS).

@Iodyne Thanks for all that you're doing. I just figured out the tank type issues and fixed it. Removing the " !CryoTanks" from NEEDS was intentional, but that was only half of what I had to do to make things CryoTanks friendly. (Previously they weren't.) I've also updated the tank patch to: Provide RR's Methalox tank types if CryoTanksMethalox (via NFLV's methalox engine patch) is not active. Handle the stock parts that hold only MonoPropellant or only LiquidFuel. CryoTanks doesn't patch them. I can't say that I have much interest in the more intricate reactor patches now (I loved it back in KSP 1.1's time, however) but I do have complete faith that you'll figure out the missing bits that need to be done to iron them out. And if you want me to, I'll include and release them. Just one question: Does the engine reactor delete/replace the alternator? I guess not.

This is very normal when your installed (and version locked) Kopernicus does not agree with your KSP version. Or National Cat Day came twice this year.