JadeOfMaar

Most likely. It will definitely complicate things. You will likely find the word "procedural" in the drag cube entry for parts like this, and procedural drag cubes are something I have no experience with. Assuming its overall size never changes, you can get away with stopping this and giving it the same single settings as the next closest part by size.

@ztoundas @SuicidalInsanity An introduction to understanding drag cubes: Look at the part from each of the orthogonal axes (X+, X-...). The amount of solid surface area is taken and mushed down into an equilateral square. All negative space due to hollow bits is considered and reduces the total area. Drag cube area is not simply a function of how tall and wide the face at that axis is. This number (the drag cube area) is most important for the Y+ and Y- because this axis is where stack nodes and the airflow direction apply nearly all of the time. Once the drag cube area is near identical for the Y faces across all parts in a given bulkhead profile (or a given stack, regardless of profile), this particular problem is squashed. The matter of negative space is the reason why (for example) the Mk3 Expansion drone core should bring players an exceptional lot of trouble. I remember it having a lot of hollow area. Any cargo bays added by mods are the absolute worst as they only have their really thin side walls and practically don't exist in the Y axis view.

It uses Kopernicus which isn't available yet.

I think there is only one standard chemical formula for SolidFuel: Aluminum + Ammonium Perchlorate. It gets the job done and it burns clean, I think. I'm not aware of any other solid fuel that contains its oxidizer in itself. Hybrid solids may exist (they do in concept anyway) that accept a SolidFuel and a liquid oxidizer but you never hear about them. Correct me if I'm wrong but IRL, their advantages aren't worth the added complexity of the engine/exit machinery. So in KSP, if you want "other fuels" just go LFO. You can achieve a lot of the performance tuning dynamics of a solid rocket just by customizing its nozzle. The nozzle's throat width affects thrust, the throat to exit width ratio affect Isp, the bell length and bell curve (like on any liquid rocket) also affect Isp. @linuxgurugamer just has to envision that for his mod. The remainder and most important portion of the performance tuning lies in the grain geometry which affects thrust as the fuel runs out. There are 6 prominent geometries, and from the looks of their curves, 2 of these are great for Vac kick stages and would suck for sea-level lifters. I'd put away the idea of fuel options due to how dominant the perchlorate formula is. The stock feature Throttle Limit already delivers that bit and simulates having an appropriately smaller nozzle.

@Stone Blue Heh. ikr? I was encouraged at one point to possibly make parts for the Swordfish from Cowboy Bebop but there's no way in hell that would be stable in KSP. On another note, I scaled the J-60 to 200% to better fit the J body and better resemble the anime craft. While it would very likely deliver performance like the anime craft, it unfortunately swelled to a mass of 37 tons, and would drag the CoM too far back as all the fuel mass and the bulk of lift surfaces were now ahead of it. Now I wonder, too. It even had a mount under the cockpit (like a fish's beard like bits) to hold the front landing gear. I easily replicated that with a Mk2 adapter and OPT Mk2 nose. But I clipped a big S Elevon in it to add Yaw control to prevent any yaw induced hell due to itself and other Mk2 parts aligned vertically (like the Mk2 intakes and noses on the Humpback adapters). I feel guilty for that but play-ability matters more. @AG-cs always doing epic designs like that. And I noticed the custom-painted ARI-73 engines.

"Spaceplane Orion" is the name of the anime version and what nearly all of the involved OPT parts came from! Mine is "Orion JL" (due to my first making an "Orion J" featuring no Humpback parts). * Comparison pic features the visually more accurate version featuring more Tweakscale and no boarding ramp. This is not flight-tested. After a lot of testing this one has been proven ready for service. The wings (140%) and engines (150%) are Tweakscaled and larger than default. I chose to add the J boarding ramp so kerbals would be able to board/depart without using ladders. By consequence, this makes it a low rider and (in addition to being very long) it needs to reach the runway's edge for liftoff. It weighs 256 tons too but handles well at 70m/s (for the touchdown). With the J-60 (not the J-60D) it can SSTO in JNSQ, which is fine for me, but I wanted it to operate involving the J-60D like the anime version, but its TWR is too low to be viable. The anime plane's center engine is effectively J body sized, not Mk2 sized. Scaling the J-60 to meet it would make the engine take up way too much space. My Orion JL it's not great at holding its AoA during reentry so it can easily flip out and expose the J-60 engine which will all too easily melt off by JNSQ's reentry heat.

I made a replica of the anime hypersonic airliner "Spaceplane Orion." It needs some sprinkles of Tweakscale to meet the mark. Now you know exactly where nearly all the involved OPT parts came from. The above is more visually accurate but this one (below) is the flight-tested version that I spent a few hours on. Less Tweakscale, and including the J Inline Boarding Ramp so kerbals can get in/out without using ladders. It's a low-rider, as a consequence, and can't nose-up enough before reaching the end of the runway. (There are small wheels on the center engine (J-60 ScreamJet) to prevent tail-strikes).

oh lol. Well using the full name in everything would cause trouble. But I didn't foresee things from this angle.

@Galland1998 @flart The way they work is that you approach them with the active vessel then you interact with each static that has a module to them. clicking on them brings up a UI where you pay up-front to open or close the item or to assign kerbals (I don't know the condition needed for the kerbals. I assume you only pick from the un-hired ones). The module-bearing statics include: Any stand-alone fuel tanks. They will let you buy and sell some propellants and empty or fill the active vessel. Treat them as actual gas stations. All of JNSQ's KK bases have these except maybe the Mountain Observatories. Helipads. I think I had a special reason why these are open by default but I don't remember and I'm not sure if it's a huge oversight. The tiles with white paint road markings on them (Rover Pads). All runways (except at the Welcome Back Island. It may be a dumb judgement call on my part but I don't see it as a place for spawning large craft. It's for recovery. If you guys feel very strongly about it, I don't mind changing that. But I can't promise when JNSQ will update again since we're waiting for Kopernicus for 1.8.1 now.) All launchpads. The Universal Spawn Points (used for ocean spawn). Look for a blue circle with triangle inside, seated in the water. Currently only KSC Harbor and C. Yeager have these. All landing pads. These (in addition to the rover pads, helipads and runways) have a recovery module on them for when you play hard mode and disable yourself from recovering craft if they're not near enough to the KSC. The recovery module is technically the cheapest thing to think about. They also allow you to recover for up to 50% your craft's value and save you from needing to land near the KSC every time. Some of the small building complexes. These are mostly "research station" statics, however, I use them mostly for roleplay housing/residential capacity. The ones you can interact with generally allow you to place kerbals and farm science. Anything that looks like the Astronaut Complex or Mission Control. These likely have the barracks module and will accept a lot of kerbals to keep in reserve and should clear out the astronaut complex. Three certain mid-sized buildings: the Orbiter Processing, Payload Integration and Horizontal Integration facilities. These accept kerbals and let you farm funds. Fully staffed they will pay for themselves in 1 year. Horizontal Integration can be found near the ends of all airport runways. Any comm dish static except the transmitter mast. The masts are always open and provide for the air traffic controller experience. But they have a short range (60km). The extra comm dishes are for the probe control/satellite internet experience. Tracking Station complexes (like at the KSC). These occur at the mountain Observatories and the C. Yeager center. They have signal range comparable to that of the KSC itself. These were arranged with RemoteTech in mind. You will need to go into Difficulty Settings and hit the toggle to Enable (extra) GroundStations. It is off by default, making these and all of the comm dish statics useless. The small Standalone Utility Buildings (tiny cube buildings with just one door and tall, blinded windows) may have a storage volume with a fixed limit and will accept all resources like a piggy bank. The hangars unfortunately, are useless. A craft storage module exists and allows you to stow up to 3 craft inside them like how Allista's Hangars mod works, but it's broken and it currently only allows up to 25 tons. I don't know if this was fixed for KSP 1.8. The Island Airfield is randomly placed by KSP due to Kerbin's geography being changed. We don't control where it appears. We can only control if it appears. I don't play career mode so I don't have a grasp on how GAP works, especially whether there's a master switch that you can flip and buy the whole base at once.

@Errol Nertea's not the kind to accept random requests, neither to let anyone reuse his art. He has fought mod makers who did so, and so his licenses make his stance abundantly clear. Your proposal is quite attractive but sadly, it may be better you learn to make models or you find a small-time part maker who *does* take on random requests. That said... Breaking Ground's robotics will properly allow you to produce a non-kraken spinning lego centrifuge system. The rotors have stack nodes, after all, and the prop blades or whatever else you attach will spin as you want them to but not on rails. Just make/configure a big and powerful rotor, and offset the nodes out to where you need them to fit your ring pieces.

Angel-125 typically has all of his mods and only his mods installed (as far as i can ever tell from his screenshots). MM 4.1 is exclusive to KSP 1.8. Get MM 4.0.

I camped out in the VAB all day, messing with shiny stuff (Damon's Starship). I've confirmed that it can do expendable SSTO without Super Heavy in JNSQ (on methalox, not LFO). I made it with 100 m/s to spare but I'm no expert pilot. I'm sure 100 or 200m/s more could be squeezed out. I visited the TU Recolor Depot and whipped up a sample of my vision for shiny OPT spaceplanes. White is modestly shiny with dull reflections; Gray is less so; Black is zero shiny. No pure chrome anywhere. The mis-matched shinier pieces are stock parts.

@Xd the great I was corrected a while ago. The methalox mod (Nertea's side) is in the extras in NF Launch Vehicles, not CryoTanks.

@Ratwerke_Actual That's normal. The custom names don't persist but the settings themselves still exist.

@yocracra Do not install the included MM and Firespitter. Those are ancient and broken by now. Get MM 4.0 for KSP 1.7 or older, or MM 4.1 for KSP 1.8. Instead of Firespitter you'll want OPT Reconfig and B9 Part Switch.

@Xd the great Most (I think) of this mod's engines change over to methalox when you install Nertea's Cryo Tanks and enable its methalox sub-mod or install Rational Resources (made by me).

As it so happens! ... I'm doing some re-balancing on the parts right now (Super Heavy engine thrust buff and tank volume buffing for the most part... a lot of tank volume (1/3) is actually missing in the current beta vs up-sized Kerbodyne tanks) and I just confirmed expendable SSTO Starship without Super Heavy in 2.7x scale. But... The Methalox Engine patch must be active. It won't happen on LFO.

You'll primarily want SMURFF which enables all parts to have their stockalike (excessive) dry masses shaved down to proper, lower masses and (I think) their thrust and Isp tuned to be more playable. For a decent mod list you'll have to find someone else who plays as you're aiming to play. I wish you good luck with that. It seems like a very rare thing or such players may be scattered and far apart.

It's so close I can feel the gravity! Release 0.8.6 for KSP 1.7.3.

I'll need you to show me where Elon Musk says Starship can lift itself without Super Heavy. Any 3 engines (just SL or just Vac) clearly will provide 1 TWR, but of course that only applies in vacuum. Engine specs tend to be given only in Vac/not in SL. It's not possible. This mod is made for 2.5x and real scale where it's no longer OP. Only at stock scale can you afford to cut out lots of dV and TWR to make way for things like this. Everyone who follows Elon Musk and uses this mod is already aware of and prepared for the crew access situation. Perhaps once Starship is flight tested, we'll start to see a focus on crew access solutions (aside from the tower). Perhaps SpaceX has lots of solid ideas already but now is not the time to show those off. It's also possible that you may be using Starship far out of its scope. I see it as more of a colony ship where once it's landed (long after, and alongside one or more cargo Starships) everyone gets out and starts doing long-term stuff like base building. I get the impression you're treating it as an overblown lander can.

@infinite_monkey I'm not sure what can be done about that. It happens to me too. A scene switch or quickload should be enough for it.

The TU download required for Starship's eye candy is only a few KB large. No need to sweat it. (Or am I somehow downloading the wrong TU?) Super Heavy's fins are not working aero surfaces. Starship's fins are. Any vehicle that has most of its aero surface to the front will easily flip (like any badly designed plane or any small spaceplane mounted on a rocket, like X-20 or X-37). To counter this you should keep your AoA within the prograde marker as much as possible while in thick atmo, and learn to do your ascent turn better with such craft. Also, don't turn on the steering response in the fins, or do learn how to deal with those things bing on. Starship has not been designed nor shown with the intent to be steered like a plane. The ideal technique is to reserve an action group for the deploy of each fin, and toggle each of them as the situation calls. It may help you a lot to deploy them for ascent as when they're angled up, they drag less. @_AstroNot_ Starship's landing legs require their own plugin which is either bundled in Tundra Exploration, or also found in Station Parts Redux. I haven't landed one so I have no further advice, sadly. Starship's fins use the stock elevon module and don't need any plugin [Retractable Lifting Surfaces] in order to work. Just action group their deploy buttons as you have done. That's the equivalent to how Starship is meant to steer. Unfortunately I overlooked adding a control point toggle to the crew pod. Without it, you cannot change back to control from prograde once you control from the docking port. The next beta release will have that. Also the control point may be oriented funny which causes or adds to the fins' misbehavior. You also shouldn't need to use the docking port in order to control the fins in atmosphere (or at all for that matter). Everything would be wrong with that on a craft like this.

Be sure to isolate before doing so. We really don't want any accidents now.

I wouldn't spare any bit of that config if I were you. The large power sphere has its 18x value of XenonGas (directly in its part config) already. What you're doing in effect is making it require 18x more xenon. The way that portion of the patch makes sense is: The first portion that you delete will replace XenonGas then copy the converter module and change the input amounts (which then become identical) through both parts, then the second portion scales the input amounts to be correct for the large sphere. Since the first portion no longer applies, the second part blindly does so to the xenon converter. Thanks for bringing this up. Since I'm making moves to stop forcing CRP (in order just to use OPT Legacy) I should add the appropriate needs to this patch.

The dependencies are exactly the same as any other planet mod. Kopernicus is absolutely required for any planet pack to work.