JadeOfMaar

@NermNermNerm Except for TAC life support, I think I generally buff the Mk2 version of a converter by up to 25% over what I find in a 1.25m form, as long as the volume of the thing makes sense to me. I understand your decision against bio-waste. I tried a life support mod which had one job: produce sustenance from a steady EC input alone and hold a small amount within the converter. There were no tanks outside of the converters. Since food production comes in two very distinct forms, I'm confused now how to treat them in my mod. I provide only 3 parts for holding converters. And it's not easy for me to choose which 3 features of your mod to put into them. If you experiment with B9PS as I do, you will be aware of B9's ability to alter the I/O lists in a given converter (but a quicksave and quickload need to happen after the switch). I've entertained the idea of using this on your modules but I wont be sure if your plugin will agree with it. I guess hydroponics is more appropriate for Airline Kuisine. Until now I didn't know that each one was appropriate for a certain situation and so I couldn't decide. I haven't gotten an answer #3 from your explanation (due to the number of industrial converter chains not directly tied to food), though your explanation is sufficient for understanding PKS better. I'd like to mention that (pardon me if you know already): I'm very aware of the tiered food resources and that they're availed through B9PS; As subtypes, and with recent feature additions to B9PS, you can make each tier/each subtype require a tech node unlock, and progressively make them all available which is that much better and more fitting for PKS.

@vardicd Balanced for stock scale: No. If it was, Starship would be built in 3.75m not 5m. And 5m is too big for a mod like this for stock scale. The engines would have to be as efficient as SRBs, or the tanks would need to have far less volume. Tundra's RO patches are a separate download in the 3rd post or so on page 1 of this thread. 2.5x~2.7x system scale is the middleground between stock scale for beginners and real scale for the hardest of players-- where you don't even need yet to add mods to keep stock parts playable.

It's very safe. Nothing was changed that can threaten active flights or progression elements. The only threat is that Moho gets a new biome map and can cause ISRU problems but only if anyone just happens to be landed and mining there. It depends. Since the Kopernicus GitHub is lit with activity now...I expect a new delay to be in progress. I give it 3 days at most.

KSP-AVC users know it's here ( *cough cough* @Galileo teasing harder as usual *cough* ), but can't do anything about it without Kopernicus for 1.8.1. Here's a taste of what things look like, featuring the KSC, the C. Yeager space center, and Lindor. ...

Reincarnate of possibly my first OPT SSTO spaceplane, the Nosebleed Shuttle which existed in the KSP 1.0, 1.1 days while @K.Yeon was still around. It was named for having so much power in its horribly unbalanced engines back then that it was its own railgun and payload. Peak acceleration exceeded 10 gees and it threatened to explode during mid-ascent (so then it had a heatshield on its nose.) Now, though, in 2.7x and with OPT under my authority, it's no longer an SSTO, but it's still worthy of its name. Peak acceleration reached 9 TWR and 6 gees while ascending with the drop tanks, and while using airbrakes later in descent, it steadily takes on 5 gees. Before I made this tri-engine form, which causes certain feelings in me... I managed, almost, the original 2-engine form but angled the ARI engines upward somewhat to deal with torque from the sunken CoM due to the deliberately low-haging Mk2 engine nacelles. The Mk2 engines were also angled downward like the curved Skylon SABRE to deal with thrust torque at high acceleration. That causes a rather notable amount of drag, but it's not enough to cause alarm. It seems to have up to 300m/s to spare after reaching orbit. Not satisfactory to find out, but the flight was satisfying.

I revived and refit (possibly) my first OPT spaceplane, the Nosebleed Shuttle. In 2.7x scale, its small size doesn't allow it to be an SSTO so it must launch with drop tanks. I also did quite a bit of wrestling with KK stuff for KSP 1.8+. That tri-engine setup stirs certain pleasant feelings in me.

I'm expecting the same business model as with current KSP: free updates to the base game for life + paid DLC. However, I'm not expecting the bargain bin pricing scheme as with KSP 1. These guys know their stuff. I also expect the DLCs to be more mod friendly too. Remember the anticipation of building upon MH's Mission Builder and how that got extinguished by the failure of MH. Planet packs cannot place and mix BG's ROCs freely on their added planets. There is also no means to create custom ROCs. Anyone who votes against DLCs is hoping for the business model where every major upgrade to the base game is paid. It's a fair scheme, when done right, but I bet that's going to go against Star Theory's promise to not shell-shock the whole player-base.

Throwback to KSP 1.1 or 1.2 when I built something quite high-fidelity with Mk3 Stockalike Expansion and up-scaled stock shock cone intakes. I didn't need the scramjets, and this thing had way too much dV, easily reaching the Mun in one go. I bet it could return without refueling too. I think it could keep pace with Captain Kipard's Skylon if it was rebuilt today. The old terrier sucked so much egg with how it looks and that variants and Restock didn't exist so there was no hope for a "compact" form.

That interest is definitely out there. I've seen the rise and use of a few tech trees apart from CTT, or which modify CTT, and I catch mention of ETT at times.

I never used this mod but I've seen it in action (on YouTube or Twitch) and I'm very sure it does not use the stock feature. B9 Part Switch has a method for upgrades now, which builds upon the stock feature. I've created and confirmed a good number of use cases with it already. (But you would know. You're an OPT user. ) Some demonstrations in spoiler, to not be obvious and possibly derail thread: Heh. Now I'm really curious. Things may get a bit more interesting for you with my mention of B9PS above.

It is (or should be) common knowledge to experienced players that KSP was made by inexperienced devs and was a learning exercise by which those devs became as great as they are today. Those of us who dive deep into KSP's workings (by making plugin mods) will know this. Of course, the numbers of bugs that still remain will anger and discourage us, but the fact that KSP is an epic game in spite of that, adds to our respect for its very existence. Sometimes, bugs will happen to you alone and to nobody else because that's how old and novice code is. Sometime back when KSP 1.1 was the latest I had a couple versions of KSP installed, and some of them became really buggy or completely unusable (I think my PC even crashed the moment I launched them but the 1 good usuable version that I didn't want still worked and my PC seemed quite fine the rest of the time). I fixed that problem.......by reinstalling Windows. That was a pretty extreme fix but it was required, and I sailed happily after and continued enjoying the particular version(s) of KSP that I had focused on. KSP very frequently drops its price and by quite a lot, which will cause the more aware of us to ponder how Squad hasn't bankrupted. KSP's replay value is beyond measure (I'm sure there are still people around who have played KSP 0.9 or even 0.25), meanwhile you'll likely spend a lot more for a game that demands top performance hardware (not just 1 CPU core like KSP, but all of them, and your GPU, and several, several gigabytes of hard drive space)...and then after a few days or weeks you reach the definite end, grow bored, and want to buy something else, and the next game likely costs just as much. Too many people don't see that they get far more gameplay value for quite less $$ in KSP versus other games, and don't acknowledge the fact that KSP was made to be modded, and most of the DLC is the freely available mods themselves, and so these people become quick to cry about the price tag for KSP itself or the paid DLC, and they tend to feel entitled, as was seen in the storm when the DLCs were first coming out and it was announced that everyone who bought KSP before a certain date would get those for free. So many people even demanded free DLC and thus showed no respect for the fact that KSP goes on discount at least half the time so there's always an opportunity to grab these for even less. I'm in a state where I have a pretty low-paying job, but still I would save up, little by little, and show my appreciation and buy KSP 1 (or 2), whatever the price, when the time is right. So have a heart, my dude.

Heh. I hadn't fully caught on yet that you've taken over RPM. I'll leave all that to your discretion then. And I like the idea of the custom boot screen. When I wrote up Kerbalism compatibility for OPT I went to the trouble of describing a unique AI for its drone cores. I'd like to take the advantage to add a little imagery to represent it.

@JonnyOThan @Stone Blue If an IVA fix for OPT can exist entirely in a config then it would go into OPT Reconfig. If any files for models and textures need to be added then they go into OPT Legacy. It was the original OPT dev who created the IVA stuff but he has long since vanished from the KSP world, and IVAs are not my thing so I cannot make any decent changes to them. Whoever is willing can and may create the config(s) such that it first strips out any offending non-RPM IVA stuff before applying the RPM stuff, and I will include it in my next OPT releases. (I often publish Legacy and Reconfig updates as a pair.) The restriction on Reconfig keeps it an easy download for folks who don't want or don't know of OPT Legacy.

Flip the Advanced Mode toggle by the search bar ( <||| ) as though to access Subassemblies and you'll see them.

You can sure count on @Kottabos to spot potential issues that you just didn't quite catch for yourself. The payload bay shouldn't be able to hold fuel right now (or at all). I did not need this for my final test flight in 2.7x before release. Video added to OP. Aside from the wheels, there's the other thing that he missed thanks to how Janitor's Closet works. The auxiliary bay.

I use Blender only to rip models so I can't answer that. Resizing a model is among the most basic things you can do in a 3D art program.

@Tiberius @linuxgurugamer @Jognt the JNSQ repo (and so, its downloads area) is public again (since Monday), as Galileo promised. Temporary server invite link if anyone is interested: https://discord.gg/ZrZF566 We're highly concerned with security so this link has no time limit but a use limit.

OPT's HAE-02 (non-Legacy) Mk2 engine and the ZZZ engine mounts are big-time offenders. (Their scales are in the order of 100s.) The ZZZ boxes used by my Rational Resources have a custom rescaleFactor I set (0.85) but due to this conversation I'm more alert (and more confused) to it now.

@Space_Coyote I blundered with the zip file. The correct thing is posted now. You can type @ and then a portion of my name to get my attention without having to quote a post.

Release 1.1 Moved and rotated harbor to north-west position. Added connecting roads to Squad KSC and some KSC Extended facilities. Added billboards (will show the active flag) and a roundabout for TOKYOU DURIFTU shenanigans. Raised costs and adjusted craft mass limits on hangars. Confirmed compatibility with KerbinSide Remastered.

The problem of NodeHelper displaying differing node distances to what's in the config is related to the scale or rescaleFactor key. One of these (likely rescaleFactor), when set to a value other than 1, or not declared in the config, scales the node distances accordingly. NodeHelper reads this output and not the input (before rescaling) when it gets to the part. You only need to declare rescaleFactor when you use MODEL{} to link a mesh to a part, and either scale, rescaleFactor, or both, default to 1.25 if you don't declare them, which will mess you up by design. When I say "by design" I refer to some deep and obscure way that the standard part sizes are setup in-game. crossfeed as an argument of attach nodes is obviously deprecated and need not be supported in this mod. It is its own key elsewhere in the part config. Decouplers, many structural parts, and possibly engines, will have the line crossfeed = false set within them. Note that the problem, if any, with scale = x does not apply when you're concerned with MODEL {} as then you use it inside of MODEL {} if needed, and it's a vector3 and defaults to scale = 1, 1, 1.

@FreeThinker I cannot edit a post or thread I did not make. The Reconfig thread is indeed the new discussion thread. I merely have not asked the forum mods to lock this one, and that is because I have not fully taken over this mod.

I don't fully understand it myself but if you understand layers and hierarchy in 2D or 3D art, then the thing is that these parts were put together in a very messy way and what I've been told are: the origins of some of the animated sub-pieces are far from the actual geometry and technically end up under the terrain; KSP also may not like the way that certain animated objects are nested. Up until KSP 1.4, the Unity engine didn't care but then it started to care. It can be fixed but it is beyond me to deal with the UV unwrapping that needs to be re-done afterward because of another complex issue with these parts. K. Yeon is long gone but thanks for pointing it out. I've changed the link to the OPT Reconfig thread.

Originally made by @CaptainKipard and availed in open alpha dev state in December 2014. It's close enough to "finished" in looking good and being playable. Umm, no, I do not intend to add parts. Before anyone asks. Ideal fuel loadout for default build: [main tanks: LH2O], [aux tanks: LH2]. Main Features 5m diameter at the midsection. 3.75m engines. Its Payload Bay comfortably holds 2.5m or tightly holds 3.75m. Runs on Hydrolox (not LFO) by default: SABRE, OMS/tail engine, Payload Bay's builtin fuel cell and RCS. Balanced for 2.7x ~ 3.2x scaled systems. Rated for 30 tons to 600km in 2.7x with its own bay. Drone core contains 4 control points: Forward, Up (Docking), SABRE thrust vector, OMS thrust vector. Precoolers each create up to 200 Oxidizer per second between Mach 1.2 ~ 6. (This is off by default. At first I needed it but now I realize I don't, and have left this in as a toy to play with, and reference material for other modders to view.) Shock cones animate if B9AnimationModules mod is installed. SABRE (as per true turborocket nature) sips on Oxidizer in air-breating mode which explains its enduring power in higher atmosphere than most other jet engines. Aerodynamics stats thoroughly tested but there's always the inherent issue of the center of lift being under the center of mass due to the wing placement. Bonus Features Added custom cargo bay for use as a service bay. Can comfortably hold 3.75m and can provide a wide selection of inner node clusters for mounting useful 1.25m things. Can sweat Liquid Hydrogen for thermal control/transpiration. (Extras config) Includes reconfigured, recolored stock wheels to fit its profile. Includes some part upgrades. Variant themes: Black & White, All Black. Dependencies B9 Part Switch Community Resource Pack (though I say this, the required CRP resources are defined separately within this mod and will activate in CRP's absence) Integrations B9 Animation Modules (bundled) WBI Classic Stock Issues Some lasting issues that I've discovered in the process of this takeover include: A drag cube problem with the largest tank pieces. I am not sure if they can be properly fixed. Until then these tanks have an extra stack node added to them and must receive a 3.75m nose cone there. Feel free to hide (but do not scale down) the cones afterward. The pre-made wheels run on Firespitter but misbehave even with the current version of Firespitter (as at KSP 1.8.1). While these remain un-usuable I have supplied customized stock wheels to use in their place, and removed them from the game. They can always be fetched from the "Broken" folder in my GitHub repo of this mod. Warning Players who at least have an idea how aerodynamics work already know that Skylon, by nature, is incredibly unstable due to having such little lift surface and having all of its lift surface under its CoM. Players who can't get their own planes to liftoff before the edge of the KSC runway or liftoff in one piece are not ready for this mod. Drag fix illustrated: Original thread: DOWNLOAD :: GITHUB :: SPACEDOCK LICENSE : CC-BY-NC-SA

Hey @Jiraiyah. No, there's no documentation. But fuzzy logic is straightforward. When I target parts I look for a very specific combination of known keys or nodes, and values in their configs. For the :HAS block, I have a comma-separated list of what I want to see for the part to qualify to be patched. Like OPT Reconfig's patch that enables OPT RCS thrusters to dynamically change between MonoPropellant and other things, and Rational Resources' Extras config that targets all stock branded fuel tanks, what @zer0Kerbal used above in this thread, for their B9 config with less subtypes. Be very careful when you start yo use this. It becomes easy to miss a ] when you start getting into nested/recursive :HAS blocks. // OPT Reconfig RCS fuel switch // Parts that HAVE (manufacturer OPT, RCS module that HAS (resource name "MonoPropellant")) @PART:HAS[#manufacturer[OPT?Aerospace?Division],@MODULE[ModuleRCSFX]:HAS[#resourceName[MonoPropellant]]]:NEEDS[B9PartSwitch,CommunityResourcePack] { @description ^= :$: <color="green">This part can change its RCS fuel mix.</color> MODULE { name = ModuleB9PartSwitch moduleID = OPTRCSSwitch switcherDescription = RCS Fuel Mix switcherDescriptionPlural = RCS Fuel Mixes switchInFlight = True ... // lots of stuff } } // Rational Resources fuel switch for Squad tanks // Parts that HAVE (manufacturer "X stock brand", no B9 module already, LiquidFuel tankage) @PART:HAS[#manufacturer[Jebediah*],!MODULE[ModuleB9PartSwitch],@RESOURCE[LiquidFuel]]:NEEDS[B9PartSwitch,!CryoTanks]:FOR[RationalResourcesSquad] { // refVolume takes the stock tank's full amount and preps it for use as B9 baseVolume refVolume = #$RESOURCE[LiquidFuel]/maxAmount$ @refVolume += #$RESOURCE[Oxidizer]/maxAmount$ !RESOURCE[LiquidFuel] {} !RESOURCE[Oxidizer] {} MODULE { name = ModuleB9PartSwitch moduleID = RRStockSwitch switcherDescription = RR Fuel switchInFlight = True baseVolume = #$../refVolume$ ... // SUBTYPES are added later } } // Parts that HAVE (manufacturer "Y stock brand", no B9 module already, MonoPropellant tankage) @PART:HAS[#manufacturer[C7?Aero*],!MODULE[ModuleB9PartSwitch],@RESOURCE[MonoPropellant]]:NEEDS[B9PartSwitch,!CryoTanks]:FOR[RationalResourcesSquad] { refVolume = #$RESOURCE[MonoPropellant]/maxAmount$ !RESOURCE[MonoPropellant] {} MODULE { name = ModuleB9PartSwitch moduleID = RRStockSwitch switcherDescription = RR Fuel switchInFlight = True baseVolume = #$../refVolume$ ... // SUBTYPES are added later } } // Add SUBTYPES to all stock parts that were given the tagged B9 module through fuzzy logic @PART:HAS[@MODULE[ModuleB9PartSwitch]]:NEEDS[B9PartSwitch,!CryoTanks]:FOR[RationalResourcesSquad] { @MODULE[ModuleB9PartSwitch]:HAS[#moduleID[RRStockSwitch]] { SUBTYPE { name = LFO tankType = LFO title = LF + Ox } ... // more SUBTYPEs } }