Araym

... considering the above (LEM that fits in 3.75m S-IV-B), to not rescale the Sarnus I (it should go around 4.375m, to proper comparison to an Saturn V, using 0.625m increments), the "stock" dimension at 2.5m for 3x kerbal pods and to avoid a weird, "small" third stage (and just living with a slightly bigger CSM), I posted my "placeholder" Saturn V to let you have an idea about a 3,75-5.625m scale for third and second/first stage, to consider it: easier to manage in the VAB, without any Hangar Extension follow a stockish scale, in 1.25 or 0.625m increments keep better proportion for the whole 1st-2nd-3rd stage, leaving just the CSM off it (just slightly, at 2.5m rather 2.216m) with tweakscale and stock tanks, or proper tanks made by you, it could eventually lead to those uprated Saturn proposed and never realized, still fitting in the VAB (stretched first/second stages; solid boostered one - using your Titan solids; etc etc etc) ... different from my "placeholder", a "Sarnus V" should have just a longer S-II and S-IV-B (I considered to add the small, black and white, 3.75m tank, both to the third stage and, tweakscaled to 5.625, to the second stage, but I disliked just the look of it with that texture pattern)

... uhm... ... maybe... <Araym makes some maths> ... uhm... all right... probably I rounded these pieces used in my Saturn for a third upper stage at 3.75m (as I planned to use the stock tanks), regardless CSM dimensions (as I had none up to now)... Remembering back in time when I used OLDD Saturn (that was in perfect scale for a CSM at 2.5m), in effect it scraped the inner VAB roof................ ... but then: it isn't the BD's Sarnus I actually a bit small?? I didn't check it exactly, but it seemed to me at around 3.75m... an ipothetical S-IV-B should be in the same diameter... 3.75/6.6= 0.568181818181... so S-IC/SII 10.1*0.57 = ~5.738.... m (basically my scales up there) BUT Apollo CSM at ~2.216m??? The CSM could be rounded (to recicle the stock 3x kerbals IVA) as it is at 2.5, BUT as Venomous said, we could stand an "not exactly scale" between it and the rocket, to keep easier building it in the VAB, without mods. That probably (I have to find my old sheet) I did the rocket I posted above in the range of 3.75-5.625m, as a compromise: a bit bigger than FASA one (5m seemed too skinny for me), with a probably total height in the range of 60m (mine is shorter, as second and third stages were made with stock -tweakscaled when needed- parts that are probably too short for the diameter i chosen, to avoid to use the black and white smaller 3.75m tanks as a gap filler)

... and the very same rocket (5.6-3.75m) with BD Apollo-Kane CSM (LES from Tantares, capsule shield and S-IVB fairing covering a stockish LEM done with Procedural Fairings). It's big, but not so gigantic to need Hangar Extension... ... is anyone willing to see it launched??? The downside of this mod (IT'S NOT PART of BD mod) is that it has very rudimental model of engines (surelly compared to CobaltWolf detailed ones); it has not the same "LEGO" approach for the tanks (difficoult to build any possible "stretched" version of a Saturn, as they were proposed, rather the standard Saturn V), even if, opposed to the engine, the tanks, ullages rockets and small complements of the rocket are more nice looking than the engines; S-II second stage and S-IV-B third stage are made with stock tanks (tweackscaled up to 5.6m for the second stage, left original at 3.75m for the third stage) and I had to mess with ALT-F12 part clipping to connect some decouplers (as they lacked proper nodes to build it flush with stock parts) ... but waiting BD's Saturn V, it's a good placeholder overall... In comparison with the real one, my creation it's just probably a bit short on second and third stage, but I'm doing what I can with partial parts available from other mod, some tweascaled ones and a lot of engineering fantasy (mine were just the cfg edits from the mod where i took the first stage and Saturn engines, that were done for Real Scale - and Real Fuels - mods)

Actually, recycled from a KSP's Real Solar System mod, waiting for your Saturn, I have a Saturn V at 5.6m diameter that fit EXACTLY the VAB height. I just build each stage separately, then merge them from top to bottom, scrolling it up and down (clipping sometime them under the VAB floor, if i need to check upper ones once assembled). But then, once built, it fits. Hangar Extender is overrated: pure will could do everything --- EDIT --- For proof (of a Saturn V at 5.6m diameter, even if it's an old craft without any BD parts: the top pod it's a 1.875m diameter, but the rocket it's 5.6m-3.75m, like it should be with a 2.5m Apollo) ... there is plenty of room (as I looking to a Saturn V from above), without any Hangar Extension... ... even for a BIGGER Nova rocket

You cannot go "small" doing some of the bigger (an sexier) rockets ever built... ... we need just a bigger VAB X°D Pester Squad about it, and all we'll be fine. LOL

To be "in scale" with an Apollo at 2.5m (and looking at Cobalt precision, to search almost real proportions), actually a Saturn V should be in the range of 5.6m diameter... ... but maybe a 6.25m could be nice for a Nova-like, concept, rocket (8 or more F-1 engines ???)

I'm playing a KSP 1.1.3 with a lot of mods, so probably could be a conflict here on there, but once I added Orbital Decay, NO orbit were shown in map lowering their altitude (aside from the active one, as said by the author that it is not not active) when I was in an active vessel, BUT, as predicted, low orbit one suddenly disappear as "crashed" even if a moment before they were still in +75-80 km range (basically, in the "original" orbit). Only jumping from vessel to vessel "updated" in the map their "predicted decayed orbit" as they should be... I was very interested to the mod, but if this behaviour is considered "normal", it could put in danger (and visually, not easy to check) many many vessel, so I removed for the moment, waiting for a better implementation...

Both tanks or only the longer, with ETOH engine ISP, an Hermes-Mercury capsule will never go orbital, but visually, not using the "chekered pattern" one make the suborbital karbaled one very "unpleasant" and different from what expected: why do I think that the thrust value was just miscalculated? Because when I did a simple math: (Thrust/vacuum ISP)*sea level ISP I found that "143" was exactly the value of thrust needed at sea level to have, exactly, for the "full/2 tanks" Hermes-Etoh, 1.1 TWR and just send it in suborbital. So reversed: (Sea Level Thrust / Sea level ISP) * Vacuum ISP (143/230)*255=158.5434782608696... rounded at 158.5 for me, for a basic rocket at 1.1 TWR sea level, that looks like a Mercury-Redstone, fly only suborbital, has not any better capacity (it cannot be orbital even using the Hermes retrorocket as boost in altitude) and do not remove the needs of the Muo-Atlas to send the Hermes-Mercury in orbit. Use of such a rocket? Mostly nothing as it is (aside probably send in low Kerbin orbit very small payloads like the same early US probes that already we have in BD)

... ehm... I was looking at it superficially (I had those file saved from way back in the days I used those mods), but anyway (if working) I think they could be a good reference to ease the pain to Cobaltwolf, redrawing them from scratch. By the way, I ended my "tweaks" for the Apollo-Kane pod IVA: INTERNAL { name = PodCockpit offset = 0.0, 0.0, 0.57 } Adding this code to the internal module should place more properly the IVA, activating the external overlay. For those willing to use a more Apollo-ish IVA (3 kerbals placed side-by-side, as the Apollo's crew), as the original author give them as "open source", I suggest to use the one coming from K-P0110, with this tweaks: INTERNAL { name = KP0110internal offset = 0.0, 0.0, 0.13 } I consider this a better solution overall: there are some differences to Cobaltwolf model seen by an external view (mostly lateral windows not perfectly alligned and a slightly different shape) but with that placement (considering the Kane pod+heatshield) it fits pretty decently, considering not only the crew placement inside the pod, but also the already present hatch over the crew heads (this is also a bit misalligned with the pod module, but not so horribly). Personally, I decided to implement the KP0110 internal, to have some different looks than the stock 3 crew pod, already used by me also with the Super67 pod, aside by the stock one. --- EDIT --- Another fix I consider pretty important: as it seems, the ETOH engine is actually unable to lift off properly the Redstone-Mercury assembly (it starts with 0.99 TWR at the launchpad). From my basic maths, I think it was just a misjudgement about ISP: a thrust value of 143 "should" be enough, BUT only if it was the real thrust value at sea level, and not the vacuum one. If let run on the pad a bit, to gain a positive thrust, it also fails to be, sometime, a suborbital rocket capable to give an hop in space (1 of 3 launch for me fails to leave the atmosphere, burning too much fuel in the initial phase of the flight, without gaining any speed/altitude). I modified it with the value of 158.5, just enough to give about 143 at sea level (with an initial TWR around 1.1), pretty decent and probably the right feel for the old suborbital rocket.

there was OLDD Saturn, pretty detailed (HUGE ram footprint) and with real proportion (now the download is lost, but I still have the files on my pc, if you wanna take a look at them) with the whole Saturn V at around 5.6m (stock kerbal scale) diameter... ... and: for Real Solar System (I made them smaller, to fit it in a stock game, and simplified to stock resources/FX, to lower RAM usage). About FASA, it was used the LEM and Apollo capsule-CSM from OLDD, but with tanks at 5m, so the scale was ackward: I'm actually using the Real Scale version I privately modded in stock values to fill the gap you have up to now (basically, SATURN I-B first stage tanks -a bit bigger than your Saturn I-, SATURN V, Delta IV, and bigger shuttle and Ares 1 SRB) Said that, and back to some of my old behaviours, some "tweaks" I did to your Kane-Apollo capsule: the stock pod 3 crew IVA shows in a weird position, when activated the IVA overlay during a launch (to look inside the capsule from outside), way too much forward (or "up", if you look at it on the rocket). To center it, there is a command line to be added inside the IVA MODULE in the part cfg (called "offset"): I'm working on it to position the IVA properly. I'm also looking to adapt the IVA from here: to have a different looking one than stock 3 crew pod, but I'm still unsure if it will be better (or if I'm willing to add an IVA more on my already pretty full install, even if now i'm running a 64 bit windows)

I know that "cost" should be a "wet cost", that why I found always problematic any mod that add new resources to parts (like, as I was patching, life support ones) and I was fighting with MM to add the new resource cost (I found the very same "bug" also in DangIt, with the "spare parts" resource needed to repair broken assets) That is even better than the previous one! Implemented right now Thanks again for the help!

Oh! I missed the idea to create a new, specific, "addedCost" value... CLEVER! Thank you

I'm going to add USI-LS supplies to all my crewed parts: There was already an old MM cfg around doing so, and I just modded it to latest values: // Adds 15 days worth of Supplies (per kerbal seat) to Command Modules // Ignores parts that already have Supplies values declared @PART[*]:HAS[@MODULE[ModuleCommand],!RESOURCE[Supplies],#CrewCapacity[>0]]:FINAL { RESOURCE { name= Supplies maxAmount = 243 @maxAmount *= #$/CrewCapacity$ amount = #$maxAmount$ } } // Adds 30 days worth of Supplies (per kerbal seat) to non-Command Modules // Ignores parts that already have Supplies values declared @PART[*]:HAS[!MODULE[ModuleCommand],!RESOURCE[Supplies],#CrewCapacity[>0]]:FINAL { RESOURCE { name= Supplies maxAmount = 486 @maxAmount *= #$/CrewCapacity$ amount = #$maxAmount$ } } Easy and simple, a check on crewed parts and some supplies added based on number of crew seats, in their 2 flavours (command and crew cans) ... then my problem started: as a lot of crewed parts have a very low cost, if I empty the supplies they went on a "negative" cost (meaning I even get a "discount" on other part's costs). I figured how add a flat value to the "cost": @cost += xxxxx meaning that I'm adding "xxxxx" to the original cost value, and manually added all the possible cases 1 by 1 (some example only for crewed command module: I have similar one for not command but crewed parts) @PART[*]:HAS[@MODULE[ModuleCommand],!RESOURCE[Supplies],#CrewCapacity[1]]:FINAL { @cost += 607.5 } @PART[*]:HAS[@MODULE[ModuleCommand],!RESOURCE[Supplies],#CrewCapacity[2]]:FINAL { @cost += 1215 } @PART[*]:HAS[@MODULE[ModuleCommand],!RESOURCE[Supplies],#CrewCapacity[3]]:FINAL { @cost += 1822.5 } @PART[*]:HAS[@MODULE[ModuleCommand],!RESOURCE[Supplies],#CrewCapacity[4]]:FINAL { @cost += 2430 } ... etc etc... but it is tedious to figure out how many crewed parts I have, to cover all the cases, and also I liked the "automatic" calculation that the original life support patch could achieve. So... what is it my problem? How could I write a "function" like: @cost += .......(SUPPLIEScost * crew capacity).......????? ** NOTE: "SUPPLIEScost" as a "number": 607.5 is the actual value I need for command-crewed parts, multipled x crew seats, and 1215 is the cost of the same but for crew cans/labs/passenger seats ** As I figured, I need 2 different codes (one for crewed command parts and one for non-command but crewed cans/labs, as I add different supplies quantity), but I cannot figure how to syntax it....... Thanks In advance for any help

Solution to my problem during landing with "new" landing gears from 1.1.2/1.1.3: 1- as EVERY KSP version, reassigned "steering" for wheels to the same keybinding for yaw in planes with vertical rudder(s): command need to be correlated... 2- ... then, as I preferred "older version", almost removing all "spring" value (... rarely I use above 0.3) while increasing "dampner" MINIMUM at 1.5: landing gears tend to settle any plane lower (as they sink on their own weight), but regain the old appeal of "solid landing gear", almost removing the bounciness of stock values: I came very shallow on approach landing smoothly, settling on brakes pretty well (Long story: low spring value to remove bounciness, hi dampner value to remove movements up and down, basically returning to the feeling of a "fixed landing strut with wheels" rather than an "ammortized one") 3. NEVER used the fixed gears: they are broken! I landed pretty everywhere on Kerbin with this setup, allowing them also some long taxing in case of missions requiring multiple ground samples around. The very same set up used on up/downscaled version elaborated maybe in some design using tweakscale mod.

... when you find your "QWEASD" key by memory on the pc keyboard, just because their letters are totally worn out and disappeared long ago... (and you laugh at your brother going mad, because "how you can type so fast in a keyboard without letters on it???")

Basically my conclusion, done by more "emphirical" gameplay: my mk.3 shuttles (standard configuration: orbiter + external tank + 2x boosters mounted sideway to E.T.) have rather the orbiter ending with any of the mk.3 tanks than the mk.3 shuttle mount, because any design using it had a deadly drag in the glinding/reentry phase, and magically using an empty tank in the same layout of (space)plane resolved its flight properties it have some useful role of sort (a tank... fuel, fuel+oxi, monoprop), in a comparable lenght fuselage empty, as a simple "structural part", with a tank there is no any particulary mass penalty the "Vernor" SSME engine is surface-attackable, so it's not so a problem a x3 engine layout shuttle-alike in surface attack, i can set symmetry for the "Vernor" engines as I like: the engine mount does not accept ANY symmetry, radial or mirrored, in their nodes KSP rule "open node creates drag": a tank has only ONE node... a mount has FOUR ones... BETTER "a tank" to manage/cover it ... and for my ease of design, mods like "editor extension" (to set more free assembly capability) and "no offset limits" (to be capable, freely, to offset parts with the editor tools even out of the parent collider properties... a GOD SENT MOD tha correct some annoying mk.3 parts behaviour of surfaced attacked parts) saved my life ... so, basically, DO NOT USE it... ... unless you have some creative use of it, that forgive the bad properties of it overall, like Cupcake: (see his creations here: http://forum.kerbalspaceprogram.com/index.php?/topic/25343-cupcakes-dropship-dealership/)

I did a lot of costruction of "spaceshuttles" with Mk3 spaceplane parts, using a reference Inigma's one (link on my sign, if you hover above the engineer patch), so I provide you some ideas: Shuttle-like designs (like yours, even if it has not external tank and booster, referring to the orbiter itself when it reenters from space) have very poor lifting capability. I generally compensate it building "double layered wings" (basically another shuttle-like wings, clipped on the one you already have, maybe slightly angled to have more lift) Engine/tail/rear section tends to be the heavier portion of the plane, if you put there your tanks: it could develop (mostly in the landing phase) the issue to drag you down like a standard, balistic landed, capsule, with your back pointing down. In that case, you generally cannot recover, as in KSP "inverted control surfaces" go nuts. (My issues with my shuttles were the weight of my engines, umbalancing the CoM to the rear too much) Split your fuel load both forward and back the central cargobay: both for better payload weight management and to resolve orbiter weight balance as well, try to have you center of mass at the center of your cargobay(s) Check if you have the wings "empty" o "fully fueled"... you might have deadweights on you plane We cannot fully design wings properties, to fullfill the role you need, plenty: generally, on the drawing board, we replicate some plane designs, but pratically KSP handle then lifting factor not really realistically. FAR does it, so then you could design a (space)plane with all the needed characteristcs... ... or stock, you can "cheat" it using clipped lifting surfaces. In my shuttles, adjusted the "weight to the rear" problem on my own way (like Inigma's one, I used 3x Skipper as SSME, then switched to the new KS-25 "Vector" just for looks, but they were way too powerful, and squad balance "thrust" with "dead weight" on the engine, so I made a edit for a new engine using the Vector model, but weigth and thrust of a Skipper ) I found my orbiter nose-heavy. I resolved the issue putting a square wing CLIPPED INSIDE the cockpit, slightly angled up, to provide the needed lift to the nose on the unpowered-gliding phase. If it's not a design choice (I was looking to a clean shuttle-like design, unlike you, designig it more feeely) you can add some externa canards on the nose, to balance the lift, leaving them outside/not clipped, to help yourself to have some autoriti to raise the nose of your planes. I generally found any conventional design based on mk3 in the needs of some lift/control surface on the nose. Almost always. So the 2 options: clipped inside the cockpit or outside, they always work and generally are welcomed by any design.

I'm almost in the same thing about you: I liked a "simple" life support, and sadly the "old" USI Life support (up to 0.2.1) was between the "unarmfull" SNACKS and the more complex/realistic TAC. Later versions from 0.3 onward are not my stile (I'll prefer then to NOT have such a bother and then play only "rockets", or go for TAC, if I have to be busy with mutliple resources) I then made "my tweaks" to that version and stopped to add a pletora of other resources, and made a "Recycler" based on any labs I have (Not only stock ones, but some I have from other mods, like the Mk2Expansion, some Tantares part that has a lab and a "modded one" that is a stock 6x Kerbal lab - with 6x seat inside) in a way that if I have: Ore EC (I have some Nuclear Reactors that need nuclear fuels, if I'm planning big colonies, that is the only resource not available, if not shipped from Kerbin) Mulch it gives me Fertilizer to run a "close cicle" with the BigGreenHouse (if enough of them are added) This is the MM patch I made, but "numbers" are still a work in progress: @PART[*]:HAS[@MODULE[ModuleScienceLab],#CrewCapacity[>0]]:FINAL { MODULE { name = ModuleResourceConverter ConverterName = Recycler StartActionName = Start Recycler StopActionName = Stop Recycler INPUT_RESOURCE { ResourceName = Mulch Ratio = 0.00005 @Ratio *= #$/CrewCapacity$ } INPUT_RESOURCE { ResourceName = Ore Ratio = 0.05 @Ratio *= #$/CrewCapacity$ } INPUT_RESOURCE { ResourceName = ElectricCharge Ratio = 3 @Ratio *= #$/CrewCapacity$ } OUTPUT_RESOURCE { ResourceName = Fertilizer Ratio = 0.00001 @Ratio *= #$/CrewCapacity$ DumpExcess = False } } With this MM, any labs will recycle 1 Kerbal's produced Mulch in the needed proportion to have 1 Kerbal's Fertilizer ratio needed by the Big Green House, if Ore provided... ... the patch itself calculates automatically how much big is the lab (misured by the crew number it could have inside) to caluclate its needed resources (so multiple seats labs produce more fertilizer, but needs more EC and mulch). I set just a number of Ore roughly based on "dirt" used by more later USI-LS conversion, to be "high" enough to make it profitable only when I have Ore to spare. (A colony set in an good Ore concentration landing spot... a ship that have a big Ore tank to bring itself the needed supply of it...) ... that could be balanced out by your needs. I worked out that (setting by USI-LS Setting files and greenhouse modifications): a Kerbal eats 0.00005/s supplies, producing 0.00005/s Mulch (as up to USI-LS v0.2.1 rate) a "small" GreenHouse use 0.0001/s Mulch+6 EC to feed the 0.00005/s x 1 Kerbal (double amount of Mulch produced by a Kerbal to feed it... so eventually it cannot work anymore when "mulch" is not available) a JumboGreenHouse use 0.0002/s Mulch+12 EC x 0.0001/s Supplies in "normal mode" (like a 2x small greenhouse- feeding 2 Kerbals, but ending to consume all the Mulch available) or 0.0002/s Mulch+0.00004/s Fertilizer+12 EC in "Agrophonics mode" to produce 0.0002/s Supplies (to feed 4x Kerbals)... NOTE: as in USI-LS v.0.2.1, they are 2 separated converter, so using BOTH it doubles the EC needed, and a JumboGreenHouse produce up to 6x Kerbal supplies rate: bug/feature that could work in an Electric rich colony/ship, to avoid cluttering/lower part amount, as I have a crappy pc, but at the cost to use too much Mulch than actually produced by 6x Kerbals... adding labs (as patched above) a 4x Kerbal colony/ship could also use Mulch+Ore to replenish fertilizer and run in a "closed cycle" if: it has any labs combo equivalent to 2x stock labs to produce fertilizer it has an Ore supply to feed the labs above at a 0.2 units x second (directly drilled or from an Ore tank) it has a Jumbo GreenGouse runned only in "Agrophonic mode" (not using the "simple greenhouse" converter eve if available) it has the Mulch produced by the above mentioned 4x Kerbal it has 24 unit x second of EC (12 x the Jumbo Green House, 12x the 2 stock labs - 4 seats total) Probably not a realistic proportion, but it's good for my needs. ... as I always said, I like to "mod myself" the mods that I download, and probably I'll just modify it finally making a "BigGreenHouse" (a copy of the "JumboGreenHouse") to separate the 2x Kerbal converter not using the Fertilizer from a "new" JumboGreenHouse that it works only in "agrophonic mode" (maybe the last in a 3.75m dimension, to add diversity) to feed 4x Kerbal if used with fertilizer (or finally go like in the later USI-LS version, all and only in agrophonic mode, to make sens to have a fertilizer supply in any colony, in a form of small-1.25m, big-2.5m and jumbo-3.75m, for 1x, 2x, 4x kerbals )

Probably should be this one (from Github): https://github.com/ferram4/MouseAimFlight ... if you download it from the "download ZIP" button, you need probably just to install the portion "Gamedata/MouseAimFlight" in the KSP game (anything else should be the source code :P)

It's needed this added to the .cfg file, to use symmetry: stackSymmetry = 1 anywhere is good, aside to be out of a "MODULE"

The Force is Strong in this thread! A badge is needed!!! - free to use -

Waiting to see this "spiritual journey to find himself" event in the next episode My Kerbal-sense is tingling: are 2 Bill going to find the most awesome equation possible to save Plan-Kappa universe? E=m*Bill2???

I'm feeling like JSO: The smallest adapter in your pack should be just "structural adapters". (It comes in mind all those used on the Vanguard-Brun, or the smaller one in the Titan 1 needed to connect the second stage to the nose probe) Inon and Muo ones should be kept tanks, just to let build actual stages: Obviously the Muo ones are needed for the tapered version of early Atlas, the Inon ones come handly to build the odd shaped Centaur for Titan 4 (401) and Titan 4-B (401B) (in your scale, it started like a 1.875 meter with its O2 tank, then become a 2.5m H2 Tank, in a -probably- common bulkead) Thor bigger tapered tanks (bluedog_thorLongAdapter and bluedog_thorShortAdapter) are definitely tanks... other smaller ones should be Structural pieces (it comes in mand to me that the actual "various rocket" that flew with the basic Thor PGM as first stage, often, had oddly-longer shaped first stage just because it was built a lot of different pieces to adapt it to different upper stages) Small fins for Thor. A lot of them had x4 small triangular fins attached on the engine casing. Thor rocket feel right in lenght and balance. Sadly you removed the "blue" XL tank (it was nice as future "Delta 2000" part, even if it was without an RS-27) even if it has a small visual glitch (it seemed built with two blue-ish cilinder, tapered together by the white-ish adapter in the middle: it could be possible to see thru the adapter and the long cilinder making the long upper half of the tank :P). In meantime, we will building up to the "Delta 1000" serie Personally, I liked that blue/grey-ish shade, rather to have in the future a more bright blue.

... as I said in other post, it's a common thing for a lot of rockets: stock Kerbin is always that... When I build something like a Saturn V, all the time I end to could do a munar transfer with the second stage, so I'm pretty fine to have "overperforming" rockets all the time. I do look for stock performance, as I'm playing in that behaviour. Waiting a "transtage", I made some rocket more than a Titan II GLV, with an added 3rd stage of comparable masses (or what it could be) to a "transtage", to make a Titan 3-A: 120kN become probably a bit short of needed thrust even in stock, in a comparable configuration. Pointing out then that on a x3 Kerbin, then, a rocket it's not working, for me, it's the same to look stock parts in an RSS behaviour: Then, at this point, different from mine and yours tweaks, we should follow proportion from real life Titan II first stage/second stage: it was 1:2.44... took a 565 kN in the first stage (i'm still not moving from a value that fall in a TWR 1.2/1.3 for a Titan II) it should be then 235kN for the second stage. With a stock weight/thrust right like a LV-T30 it should have a mass even worse of 1.76 tons........ Then we should consider what we like to be "a replica part": proportion to real life thrust, then stock-comparable masses and ISP? proportion to real life ISP, then stock-comparable thrust and masses? Try to achieve "a stage performance" with fuel depletion during flight as it was in real-life? balancement all around to have good stock engine, good x3 Kerbin engine, and performance like real-life rocket replica? Real life ISP, thrust, masses = using RSS with FAR and DRE, nad real fuel load/tank mass to not make mistake??? I'm more for a mix of the first two option, aiming for a bit of the 3rd if possible (almost NEVER possible, in stock behaviour). Problem coming for "modded Kerbin behaviour" then has no issue for me, in balance: proportion / issues could be also from problems about "what kind of Gemini" those using x3 Kerbin are developed: Tantares "Spica", in a 2.5m form, is not usable with BD... FASA "Gemini" neither... CobaltWolf give to us just just "a 2x Kerbals" pod, then, if we are looking to build a "Gemini-replica", it should have just some RCS for orbital manouvers (400-500 dV from RCS??? a couple of round surface attacked tanks???) and maybe 200 dV from some "solid srb bottles" to deorbit... are we sure that the "lack of performance" is not coming from an "overengineered" Gemini, with maybe thousand of dV coming from an heavy liquid fueled service module with engines that a Gemini capsule hadn't? Judging MY Gemini replica, and the MORE THAN OVERNEEDED dV I always ditch, in orbit, from the second stage, I'm sure that even in x3 Kerbin it could reach more than stable orbits with my "heavier" upper stage engine........ ... for those that had then "problems", in a x3 Kerbin, they should look on "what they added" as payload. Over some proportions, they probably could have issues NOT coming from "bad balanced rocked", but from "too heavy Gemini". Stock only RCS thrusters are not the awesome thing to use only for space propulsion... any added "system" (rocket fuel-tanks + engines) is NOT a replica and make the spacecraft heavier than it should be... with some sepatrons as "reentry solid rockets", it's just needed a 200 dV to deorbit (not pretendig a pin-pointing land, if you are going "replica" ) I'd like to "look" at some picture and data from not orbiting Titan II + Gemini from x3 Kerbin users, because if they fail to be "strict mass balanced" developing their Gemini, they will need, probably, some "advanced rocket" than a Titan II, in their "game-time line", rather than those needed by NASA. do you wanna play difficoult? Be smart! Or you need to follow the Jeb's motto: "... add more boosters", because you have not developed a Gemini with the strict parameter it should have (in a more likely cross-over with a Gemini and a MOL-Gemini ) Then I point that a mod should be balanced on "stock"... modded behaviour (x64 Kerbin, x3 Kerbin, RSS, anyelse) have their value and problem: I feel sorry for them, but they could discuss "in their 3x Kerbin thread" about light changes to balance "their game". I generally "kill" any engine coming from mods, for "overperformance" in a stock enviroments, just because (multiple choice): modders tend to balance engine to have ALWAYS TWR>1 in ANY STAGE, misured a.s.l., and generally going maybe around 1.5/1.7 I generally had my best rocket with a global launch a.s.l. TWR of 1.2 and a second stage at TWR (a.s.l measured) at 0.9. It means that ad second stage ignition it has already a TWR>1.2... sometime I launched rockets with a second stage at TWR ~0.8 and they were awesome capable to go "orbital" directly from launch, with just a "puff" of thrust to, maybe, circularize an already orbit at 120x80... modded engines have always "awesome ISP", took generally from real life comparison, in an atmosphere that, even if better than the soup-sphere of old version, it is still a "soup" untill 20/25km, then become "non existent" above (yes... it make drag, but balancing an engine, at that altitude a rocket engine already is perfoming at 90-95% of vacuum ISP) modders that create "replica-ish parts" for "real-ish looking rockets" have to fight with parallel in dimensions and proportion, then fill it with "stock lead-dense fuel" in "stock cast-iron tanks". If they follow "maths proportion" of dimension with stock tanks, the had to generally have engines NOT being stock-alike, generally with strange ISP or too much kN... if they follow stock values for engine first, and add mass and fuel to JUST be like real-life performance (... given a stage, the fuel must deplete in a given moment of the flight), they have "tanks fueled of air", with 30-50% less fuel than a stock one (an example was the "Ariane" in Tantares LV early version: a 3.75m tank that could be considered fueled just with "nothing" :P) modded part are always "unbalanced": maybe in performances, maybe in career kredits cost, maybe placed in too early or too late R&D tech nodes. Neither the "best mod authors" provided a "perfect set of parts". Neither SQUAD has still found perfect balanced parts/behaviours... I provided my thought to CobaltWolf for a pure "stock behaviour", balanced for a "forgiving scenario" of not a perfect flight for not "master of space" players (fun first), or variation on payload to have multiple design available, without having out of scale performance (neither undeperformance or overperfomance from stock). NOT interested (for the moment) for any x3 Kerbin, x2 Kerbin, x64 Kerbin, Real Solar System playstyle, to look further... Then... I'm done enough for the moment. Overall, my KSP install is a modded by me of a "modded one": I always change things in every part pack I add, finding always imbalances from a mod to another. (Basically I add the parts, then i re-write them... Basically at this point of experience, playing KSP, i could just need models and textures... cfg files are always different in my games, ditching unneded features, changing things, balancing there, moving things, at a point that it's more the time passed by me with BlockNotes open, than KSP itself ) --- EDIT --- ISP from my "proposal" are directly took from http://www.astronautix.com/ (better tha wikipedia, for me, and generally my "basic knowledge information site" when I search rocket data). I made a bit of compromise for the "mod2" series of engines, as there were little differences from "Titan II" as balistic missile/satellite launcher and "Titan II GLV" for Gemini. But it was just 1 or 2 point max here and there, and almost fallen when I rounded them for easy lifestyle But if you see "worste Titan 1" ISP, they WERE reported there as they are in my proposal (I basically copied them ). Actual differences could be just in the LR-91 for the Titan 1, as the combined ISP from vernier could change a bit the "main engine" ISP i took from that site... (I'm not so math addicted to make an equation of both engines combined on paper, to have the "perfect" ISP ) Just only the "thrust" value are a bit of compromise in perforformance (I started trying to balance the Titan II x Gemini first, then added values to "Titan 1" and "Titan 4") not to make them "obsolete" but only "different" from eachother (the comments about "Titan 1 obsolete engine" was made in a kerbalish way to figure some "advancement/changes" in the next version, not a part that is not worth to be used... )

Simple test of the above tecnique: from left to right: Atlas (base version) tanks, Redstone tanks, x1.5 Thor tanks stretched with above explained method, original Thor Tanks that we have already... ... what I did (as example) here: ... taking an arbitrary value of x1.5 to make an experiment, in the bluedog_thorLongAdapter I made these changes: First was needed to stretch the height: MODEL { model = Bluedog_DB/Parts/EarlyRockets/bluedog_thorLongAdapter } rescaleFactor = 1 became MODEL { model = Bluedog_DB/Parts/EarlyRockets/bluedog_thorLongAdapter scale = 1, 1.5, 1 } scale = 1 rescaleFactor = 1 ... this make the model x1.5 in height... Then was the moment to fix the nodes node_stack_top = 0.0, 1.49, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -1.49, 0.0, 0.0, -1.0, 0.0 became node_stack_top = 0.0, 2.235, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -2.235, 0.0, 0.0, -1.0, 0.0 ... I select an arbitrary x1.5 height, so I had to multiply the vertical value of the nodes x1.5 too Finally, change the proper values for fuel RESOURCE { name = LiquidFuel amount = 342 maxAmount = 342 } RESOURCE { name = Oxidizer amount = 418 maxAmount = 418 } became RESOURCE { name = LiquidFuel amount = 513 maxAmount = 513 } RESOURCE { name = Oxidizer amount = 627 maxAmount = 627 } ... as I changed just 1 dimension of the tank, I do not need to make particulary math: just x1.5 values will fit. I DID NOT REALLY CHECKED IF DIAMETERS OF ABOVE TANKS ARE PERFECTLY FITTING "ORIGINAL" PARTS THOSE EDITS ARE JUST LENGHTENED VERSION OF THE ORIGINAL PARTS: the above procedure is just an example to the procedure available in KSP to change dimension on parts by cfg editing, NOT CHANGING ANY, IN THIS CASE, THE DIAMETER. (Those edits are making perfectly fine 1.5m diameter parts as ALL Thor parts we have) NOW, the x1.5 scale is a bit too much, for me for both parts, but It was made as a simple example to show how it should be easy (without any need for CobaltWolf to design new models) adjust dimensions to put in better scale the above tanks. I already added them in my savegames without any issue, as ADDITIONAL tanks (made new .cfg files and called differently both in part name and description in game ) Actually, probably, an Atlas stack built like that is a "bit short" (it could need an added bluedog_atlas1ShortTank to be long enough to be an "Atlas"),to make a Redstone tank and the "edited" Thor tank be in scale. Also, the tapered upper Thor tank, in real life, is not starting exactly half way like the above example, so it could be needed a bit longer lower tank, and a little less stretched tapered upper one. --- EDIT --- Some additional consideration: as I made some size comparison with various graphics showing the three rockets and a couple of fact could be pointed: Taken the Redstone tank as a "Redstone-Mercury" (differently, it is too long), to be properly proportioned an Altas needs, aside those tank I used in the picture, definitely a bluedog_atlas1ShortTank to be right (and maybe a new "shorter tanks" half the height of the mentioned "short tank") The right tank assembly for a "Thor balistic missile" is a bit shorter than a Redstone-Mercury (and the tapered upper part was slightly above the mid-height): it could be the lower x1.5 that I stretched + the "original" long adapter (that shown in the full right example, as it is in the BD mod). This is also the right choice for earlier Thor-Able/Thor-Ablestar/Thor-Agena (A and B) Those couple of x1.5 stretched/edited Thor tanks are the right height for a Thor used as "first stage" of earlier "Delta rockets" and Thor-Agena D (Basically a Thor-Able/Ablestar a little streched before there were developed longer version that could be used also as a Thorad-Agena D and some latter Delta still cathegorized with "letter" definition before the built of a Delta-II) Final version of Deltas, before the development of the Delta-K that built the "Delta-II" rocket, could be a bit stretched again without being longer than a Delta-II Delta-II (the final product we should considered built by actual CobaltWolf parts) need the blue-ish XL tank and, probably by guessing made by eyes, the longer, original, white tank (the same shown in the picture in the full right). Using my x1.5 stretched/edited version is a bit too much longer Our only limit is, in between them, having fantasy: nobody stop to add tanks and make longer, stranger, customized versions