JadeOfMaar

Release 1.10.0 DOWNLOAD :: GitHub :: SpaceDock Classic Stock focus Added support for CryoTanks. (Note, you may want to delete all of CryoTanks' own patches except for CTT.) Added options for stock fuel cells. Disabled most tank types for fuel tanks as they are mostly not fuels, and enabled Ore tanks to hold them all. Fixed resources for RR atomic engines. Fixed removal of stock converter modules for Boxed Convert-O-Trons (where OmniConverter modules are added). Fixed Configurable Containers detection. Updated Extras: RR_TankswitchForSquad.cfg to stop detecting CryoTanks. This is handled elsewhere. @Bombaatu @Clamp-o-Tron yo!

@Bombaatu Oh, that. Yeah I had to address that for myself too. I fixed it for my personal game but I'm not quite sure I cleaned it up and pushed to GitHub. I'll check and push a release very soon.

Ultimately you shouldn't need CRP at all. But I'm curious to what resource and the mod that uses it. You shouldn't need to install CRP. The play mode switcher is supposed to default to CS if it finds that the CRP folder is missing. Also you can edit GameData/WBIPlayMode.cfg before you launch KSP. Change its one value between "CRP" and "Classic Stock".

@Bombaatu A significant part of the purpose of RR is to add value to Classic Stock. I'm currently entirely invested in building up for such a game too, and so I'm fixing any such issue I encounter. I believe this is what you're looking for: B9_TANK_TYPE:NEEDS[B9PartSwitch] { name = RR_Ore tankMass = 0 tankCost = 0 RESOURCE { name = Ore unitsPerVolume = 0.2 } } Add this to RationalResources/Classic/zTankTypes.txt (/.cfg)

If it means anything, the Hacienda (among other inflatables) have a reverse-oriented Back node: KISMount. This has been since IgorZ made a huge, breaking update to KAS and KIS, and reversed node orientation in those mods. Use the KIS key combo (N or R, whatever it is) for cycling the attach node. I have Pathfinder v1.35.1 and the Ponderosa's nodes look fine.

@RandomKerbal What? The stock linear RCS? It's there (center, 4th row, Restocked). The big white one with its nozzle pointing up. I never use Janitor's Closet.

@Bombaatu Wild Blue Tools has DeepFreeze covered and defines Glykerol without CRP. As for OSE Workshop, I recently revised WBT's file and some configs within OSE itself, including the one that hands out the recipes. I did this solely for @Angel-125's convenience. I used the mod once ever, a few years ago. The revised file will inflate your MM cache to a notable degree (introducing 4 patch passes to set out empties, do the Math, and finally clean up) but instead of parts having several part recipe nodes each, they have just 1 node with high numbers, which I hope OSE can handle. I'll PR this to LinuxGuruGamer once I get good news. // A glimpse at what the recipe handout config looks like now // - - - - Set blanks for addition passes - - - - - - - @PART:HAS[@MODULE[ModuleGroundSciencePart]]:FOR[Workshop1] { %OSE_PartRecipe:NEEDS[!ClassicStock] { %MaterialKits = 0 %RareMetals = 0 %ExoticMinerals = 0 %Complexity = 0 } %OSE_PartRecipe:NEEDS[ClassicStock] { %Equipment = 0 %PreciousMetals = 0 %Gemstones = 0 %Complexity = 0 } } // - - - - Addition passes - - - - - - - @PART:HAS[@MODULE[ModuleGroundSciencePart]]:FOR[Workshop2] { @OSE_PartRecipe:NEEDS[!ClassicStock] { @RareMetals += 1 @ExoticMinerals += 1 @Complexity += 1 } @OSE_PartRecipe:NEEDS[ClassicStock] { @PreciousMetals += 1 @Gemstones += 1 @Complexity += 1 } } // - - - - Clean up - - - - - - - @PART:HAS[@OSE_PartRecipe]:FOR[Workshop3] { @OSE_PartRecipe:HAS[#MaterialKits[0]]:NEEDS[!ClassicStock] { !MaterialKits = 0 } @OSE_PartRecipe:HAS[#RareMetals[0]]:NEEDS[!ClassicStock] { !RareMetals = 0 } @OSE_PartRecipe:HAS[#ExoticMinerals[0]]:NEEDS[!ClassicStock] { !ExoticMinerals = 0 } @OSE_PartRecipe:HAS[#Equipment[0]]:NEEDS[ClassicStock] { !Equipment = 0 } @OSE_PartRecipe:HAS[#PreciousMetals[0]]:NEEDS[ClassicStock] { !PreciousMetals = 0 } @OSE_PartRecipe:HAS[#Gemstones[0]]:NEEDS[ClassicStock] { !Gemstones = 0 } @OSE_PartRecipe:HAS[#Complexity[0]] { @Complexity = 1 } } // Instead of having several of this node which add up to this // Each part now has just one node with the totals OSE_PartRecipe { Equipment = 5 PreciousMetals = 1 Gemstones = 3 Complexity = 7 } I've made this file Classic Stock friendly too but I have yet to hear back from Angel about it. This is my edit to OSE's files and WBT's config (renamed to .txt for caution and for CRP users to safely try it). DOWNLOAD.

Suddenly, you realize your +1 Free Internets token had a shorter half-life than usual.

@Clamp-o-Tron It turns out that I didn't do the Configurable Containers detection properly. That mod is present when any of Allista's mods (particularly, his core mod "AT Utils") is installed, and Allista's mods are closely associated with USI. Open RationalResourcesParts/CRP/OreTanks.cfg and change !ConfigurableContainers to !ConfigurableContainers/Parts My configs are supposed to detect that specific portion of Allista's mods.

@pp3d Correct. OPT Reconfig does that. To stop it, delete OPT_Reconfig/CRP/OPT_CryoEngine.cfg

@kcs123 In regards to this snippet, this is not how MM works. If it does work, do let me know, otherwise, this is a recipe for bad behavior from MM. // detect combination of already installed mods @something[]:NEEDS[ModName1,ModName2] { // declare new name that MM is aware of and that can be used for other patches :FOR[ModCombination1] } @Lisias regarding your proposal here, I'll have you know that :FOR does two jobs. It sets the order that a given patch runs, but it also declares that the given mod is installed so it should never be used if you don't own that mod. @PART[CanardController,tailfin,sweptWing,R8winglet]:FOR[AirplanePlus]:NEEDS[UnkerballedStart,AirplanePlus,CommunityTechTree] { @TechRequired = flight3 } This patch is self-confirming (and therefore, a very bad example) because the needed mod is given in the FOR. FOR says "I exist" which meets the NEEDS. UnkerballedStartPatchingErrors:FOR[zzzUnkerballedStart] { error:NEEDS[UnkerballedStart,IncompatibleAddOn1,IncompatibleAddOn2] = "IncompatibleAddOn1 and IncompatibleAddOn2 were detected. You should choose only one of them, you can't have both installed" error:NEEDS[UnkerballedStart,IncompatibleAddOn3] = "IncompatibleAddOn3 was detected. This thing is imcompatible with Unkerballed Start, you need to remove it" } This looks like good syntax. I'm confident that this will work correctly. With regard to this sample piece: @PART[CanardController|tailfin|sweptWing|R8winglet]:NEEDS[CommunityTechTree]:AFTER[zzzUnKerballedStart] { @TechRequired = flight3 } That's perfectly fine. :AFTER includes the function of :NEEDS. But assuming these are stock parts, the AFTER segment isn't necessary. :FOR[UnkerballedStart] is implied by the patch merely existing inside the UnkerballedStart folder in GameData. Otherwise, that patch should be be changed to: @PART[CanardController|tailfin|sweptWing|R8winglet]:AFTER[CommunityTechTree] { @TechRequired = flight3 } @kcs123 You are correct. Having a "zzzUnKerballedStart" pseudo-mod is largely unneeded. Alphanumerically, this mod is already positioned to have any patches it carries run after nearly every other mod within the LEGACY pass (before the BEFORE, FOR, AFTER passes, and barring the use of LAST, FINAL and FOR[zzz]). Furthermore, this mod is primarily a tech tree mod, mutually exclusive with other tech tree mods, so there should be no competition to prepare for, and there should be no need to have more than one z, or, such passes can be replaced with :LAST[UnkerballedStart]. This is why :LAST exists. (Granted @theonegalen owns this mod I respect where he knows or believes that competitive patching is still needed.)

@NiL @hemeac I've updated the config to do plume switching as well. Try it out and let me know how things go. It includes an altered form of the existing LH2RCS patch which clones and changes the Lithium thrusters for CryoTanks. Obviously that's no longer necessary. (So in case of any crafts that use these, the altered patch soft-deprecates them.) DOWNLOAD :: OneDrive

You could take a page from my work on Tundra Exploration. That said, the engine patch is a bit dated, requiring CryoTanksMethalox or Rational Resources to be present, and doesn't allow you to change the propellant mix in-game, and doesn't simply multiply all thrust and Isp by a given factor. The RCS patch is perfect, however. Like what I did for NF Proplusion's RCS, on someone's request on Discord.

@Krzeszny I believe Nertea spoke some time ago about deprecating and replacing all the NFLV engines. Perhaps that is why things are as they are. (Correct me if I'm wrong. I want to use NFLV but I never get to start a playthrough so I don't bother to install it.)

I guess I should add a default mode with no thrust curve.

The Sledgehammer SRM has a number of engine modes, each for a different use case and each has a thrust curve so thrust rises and falls as the fuel amount changes. The massive thrust -should- be the effect of your test craft being nothing but a small pod, a short tank and the engine. I've changed the options in the Sledgehammer (and found and fixed a problem that I somehow caused: its engine mode options are loaded twice. So maybe that's where your problem is coming from) so perhaps your problem will go away. If this happens with stock SRMs then I have no clue.

The 'Puff' engine, actually. The vernier engine is the RCS thruster that uses LFO.

@Flightologist Not really. No.

@HansAcker Okay, cool. But have you confirmed this works with a converter module that you created/ that is not already provided by Kerbalism itself?

@Aniruddh I've tried your unedited patch and found no problem. This tells me that your patches, outside of your resource definition, are broken somewhere. My config: RESOURCE_DEFINITION { name = Photons displayName = Photons abbreviation = γ density = 0.001 unitCost = 0.001 flowMode = STACK_PRIORITY_SEARCH transfer = PUMP isTweakable = true isVisible = true volume = 5 } // Terrier @PART[liquidEngine3_v2] { @MODULE[ModuleEngines*] { @PROPELLANT[LiquidFuel] { @name = Photons @ratio = 1 } !PROPELLANT[Oxidizer] {} @atmosphereCurve { !key,* = nope key = 0 90000 key = 0.1 0.001 } } RESOURCE { name = Photons amount = 50000 maxAmount = 50000 } } Side note: 50 tons. Holy crap. I think 1kg per unit of "Photons" is pretty excessive (objectively speaking). I'd divide this density by 1000 and preserve some more of the emphasis of being a near-massless resource. And I'd expect that any engine that uses this would only hold as much as possible for a few seconds of burn time assuming the beamed power connection suddenly dropped.

Having someone build an SSTO craft for you is not the way. There are a couple of things you need to learn or address in order to escape your problem: You're at the edge of the practicality of the stock drag cube system. It's time to install FAR and adapt your craft design tendencies to it. You need the Contract Reward Modifier mod to re-balance your earnings and penalties so that in-game economy continues to make sense as you scale up. The "expert" SSTO builders you're hoping for probably only operate in stock scale. They cannot help you. If you really like jet engines you may want to consider adding scramjets to your spaceplane formula. When you leave stock scale, these become very practical and relevant.

@Neil Kermstrong SMURFF and FAR are absolutely required if you're going to play on real scale. Parts are made to be (unrealistically) dense to balance out the planets being super small, and the drag cube system will not allow you to achieve sufficient aerodynamic efficiency to make it to orbital speeds in real scale. It's sufficient up to 3.2x scale but after that you reach the end of its viability. RO is a huge suite of game changing mods that you'll want to avoid if what you're looking for is basic gameplay (or anything sort of super-realistic). Some mods you'll find interesting if you want heavy lift engines include: SpaceY + SpaceY Expanded (5m to 10m tanks and engines) Near Future Launch Vehicles (5m, 7.5m tanks and engines) Real Scale Boosters If you're interested in spaceplanes that can perform in RSS you can try out the following: B9 Procedural Wings OPT Spaceplane (Continued + Legacy) Mk3 Hypersonic Systems MkIV/Mark IV Spaceplane Near Future Aeronautics (originally the intakes and engines in MkIV)

This is a pretty interesting little thing that's going on here. I've entertained the idea of replacing stock variants entirely with B9PS, especially for where some variants very clearly add potential fuel volume. I just have one piece of criticism. I don't like the idea of touching thrust. For that to logically happen, the turbopumps of a given engine would need to be calibrated. And how would messing with aesthetics end up messing with that? Some exceptions would be fine imo, such as the dual-bell Poodle revamp vs the ESA uber-Poodle. Same 'part' and yet a world apart. The Isp curve on that would likely change too because the bell shape and size would be sufficiently different between them.

@Aniruddh Try not using exotic characters in the config. Your value for abbreviation should be the trigger. The Community Resource Pack had an enormous crap storm for a time due to, I'm pretty sure, exactly this (abbreviations in exotic languages having only one character). Angel-125's Classic Stock resources don't have all that drain valve stuff in them and that absence doesn't break KSP. Related note: The abbreviation value only shows up in KerbNet's resource overlay selector (which is only useful for crustal mined resources). I'm pretty sure no mod uses it so it's not important that you have that key in this definition.

I know a few great mods, and their makers, who make ample use of the under-developed part upgrade system. Given the case, it's worth pointing out that the upgrade system (a forgotten feature in @SQUAD 's eyes) doesn't acknowledge localization which is quite a bother. I'm not asking for any focus to be turned towards building it up...I'm only asking for this. Some large mods that use this system: B9 Part Switch (expands on this system's abilities) Bluedog Design Bureau OPT Spaceplane Wild Blue Industries (suite)