Upcoming 'new' parts -- rework of the existing LC fuel tanks.

• Will include proper solid/hollow support, and include a 'paneled' variant.
• Will use the same module as the current MFT fuel tanks, with some additions/changes to allow for per-variant adapter limitations/selections.
• Full texture set and recoloring support.
• Diameter scaling support
• Configurable container contents and type (standard, zbo, lightweight, etc)

Geometry is as follows:

• Basic octagonal shape
• All variants will have a central-pillar structural mesh / braces that tie the tanks together and
• Skeletal variants will have external structural bracing on the sides
• Small lip between domes and tank sides -- allow attachment of bracing, and a good place to hide texture seams between cylinder and dome UVs.
• Meshes will be split between the main tank and adapters
  • Adapters will contain tank domes and upper bracing/paneling
  • Bodies will contain cylindrical tank portions and their bracing/paneling
• Adapter meshes will contain small fuel lines that go to each tank dome and match up with the fuel ports on existing adapters/tanks (both top/bottom).
• Main body models will include collision mesh for the adapters, especially on the hollow variants. Will save up to 16 colliders on hollow models.
  

Unscaled dimensions is as follows

• 5m diameter when measured at widest points
• ~4.8m diameter when measured from flat side to flat side
• Height varies in ~1m increments (at 5m diameter scale)
  • 1.5m (no body) (shown)
  • 2.5m (single segment) (shown)
  • 3.5m (double segment) (shown)
  • 4.5m+ (more segments) (not shown)

Will have the following body variants:

• Skeletal - Solid
• Skeletal - Hollow
• Paneled - Solid
• Paneled - Hollow
• ?Service Bay?

Each variant will have its own adapter selection:

• Uncapped / none (all)
• Flat cap (solid variants, service bays)
• Flat cap hollow (hollow variants, service bays)
• Round adapter - octagonal -> round, skeletal/truss adapter with fuel adapters (all)

Will use AO switching to facilitate the use of the same diff/spec/nrm textures across all variants / adapters

• Each variants' adapters will have their own model definitions (one per variant per adapter)
• Will need different texture sets for each variant for each adapter, or alternate solution for texture switching
  • Could use default shader assignment handling to set the AO into the model itself, only switch out diff/nrm/spec
  • Would allow for only a single set of texture sets to be re-used across all variants (minus the AO).

Bits that are not part of this development cycle (but can/will be looked at in the future):

• Habitats/crewed modules usable for a few standard sizes as inserts for the hollow tanks.
• Large RCS/engine parts for radial mounting - to use as landing thrusters.
• Landing legs - will probably use KSPWheel w/scaling. Should likely offer 2-3 variants for different weight class and clearance distances.
• LC-POD parts -- also scheduled for reworking, but as they work fine currently (aside from some collider oddities), they will be looked at further in the future.

Nice, can't wait to see them!

Still very early in the concept dev work -- the geometry shown above will still be changing substantially; but should give a general idea what is going on with the new models. This is mostly to let me 'see' how everything will fit together, make sure there is enough clearance for 'hollow' uses, and make sure things line up like they should with existing parts.

So far, so good. Quickly got a couple of the models exported and setup in KSP for validation of the plugins' variant-based adapter selection feature; it works, mostly, sort of. Needs some work still, but should be able to get the new feature cleaned up.

At this point I would say that I'm still at least a few weeks/months out on having them finished, and at least a week or two before the first prototype parts would be available (after main geometry is done, before textures and detail work has started).

Really awesome. Did you see the images I posted on the forum from that Boeing paper I linked? Figured those might be useful, there were some good images.

One very interesting thing in the Boeing concepts is that you have something that looks very much like the tanks you have, but with 1 tank (in the radial sense) missing, and replaced with an airlock (presumably the opposite side is balanced with other non-tankage?). Then the hollow center has a habitat instead of a tank (in SSTU that would fit in like an engine bell from above). This allows easier access to the vehicle from a crew standpoint. Getting ladders right is always touchy in KSP...

Dunno is such an option is possible.

Re: Hab stuff -- not directly workable due to KSPs failure in regards to dynamic crew-capacity (it doesn't work). The best I would be able to do is give a fuel tank (in this case a service bay) with a side being 'empty' for the player to place their own hab/airlock parts.

On that note, I've been thinking of if/how to do service-bay like parts for these (octagonal tank w/ fold-out/retracting side panels). Would really like to, but will require additional concept work to see how it would all fit together with the existing parts.

If it were done, it would be as a new body variant; e.g. for your image above, it would require two parts -- the top 'fuel tank' part, and the bottom 'service bay' part (both being hollow, with the hab extending vertically through both of them).

Wow!!!!! It's happening :)

For this set of work I'm going to concentrate on making the fuel tanks functional again (which was the main point of this rework).

Service bays -- possible; might work up the geometry alongside the fuel tanks, but they would end up as a second part (due to animations).

More new/specialized hab parts are not in the current plans, but I will reconsider them (and the proposed ascent-module from above; looks like a good option for the LC5-POD geometry) when I am working on the update of the LC-POD parts (still a ways out). Landing legs / landing engines likewise will be part of another 'set' of dev-work (note how the proposal above uses 'large-RCS' looking thrusters for landing; no central engine).

As it stands now I'm going to have my hands plenty full with just the fuel tanks (and possibly service bays). 4 main tank variants x 4 lengths (at least) = 16 new tank models; 4 adapter types x 4 variants = 16 new adapter models as well. Service bays would take that total up further (at least 4 bodies, 2 adapters). So something like 38-48 new unique models that I'll be creating just for the tanks/service bays and their adapters.

Short of the open/close animation, you could just have the bottom part look like storage, and be set as a KIS tank, right?

One thing KSP is not great at is getting things like rovers to the ground, either. A bottom "service bay" framework to allow a rover might do the trick.

Related to the habs, I know that they don't work with the scaling. I was thinking along the lines of perhaps a 1.25m, 1.875m, and 2.5m hab designed with landers in mind in some fashion. A side hatch, etc. In the last image above, you have a COS like part at the top, perhaps with a window looking out/down for landing. Looking at that image, the thing in Kerbal scale is maybe 3.75m in diameter. You'd then attach something smaller underneath, in the above example we will say a 1.87m diameter hab part with a side airlock. The tank shown at the bottom would be a 3.75m octo tank, but hollow with a 1.875m hole that the airlock hab slides into (like an engine). That bottom ("mount") octo tank has a door/ramp that allows the player to click the airlock and EVA the kerbals to the inside of that empty space, to walk out. In this case it is also hollow. That bottom take might also have spots for engines to be tucked into?

It;s non-trivial, clearly. Landers might need some specialized parts, hurting low part count, but...

When looking over examples/renders of quite a few of the lander concepts that are floating around, it seems that many of them use a 16-tank layout for their octagonal setup (e.g. in the images above). This has several advantages as far as structural layout are concerned (for bracing), but would impact other areas in the existing design as well.

Left = 16-tank layout, with four additional tanks in the center where the 'hollow' would reside. Right = current 8-tank layout that I'm prototyping.

(will only be doing one or the other; unless I can think of a method to reduce the number of models needed)

I do like the bracing options for the 16-tank layout, though I dislike its use of the central space. However it might actually make more sense than the single central tank when considering bi-propellant setups. Have not yet played around with the external bracing on the 8-tank layout much, but last I checked it was going to be difficult to get a good layout. The 16-tank layout would also change the hollow variants to have much less usable fuel volume compared to the 8-tank layout.

Tough one. I love the 8 tank look. I particularly like the one with spherical tanks, even if I'd rarely use it.

That said, the bracing is certainly an issue.

One thing that just comes to mind, would it be possible to have the bottom and or top panels (the middle ones in the very top render) on a toggle? For example: you have a hollow panel tank, and the top panel is off in the hollow area (as shown above), but the bottom panel you can elect to cover the hole? This would allow a "fire in the hole" engine (LEM), and another mounted on the bottom.

from NASA.gov

I am a pretty big fan of the 8-tank layout myself. Simple, effective.

I was highly debating whether to even do the external bracing (as in the image above). As all of the tank designs will have a central bracing/pillar structure, the external bracing is less necessary. Lack of bracing would make attaching other parts to the tanks seem a bit out-of place (e.g. landing legs)... but I guess that is what the paneled versions are for?

Re: adapters -- sure. There should be a 'bare' (no platform), 'full' (full platform), and 'hollow' (platform with cutout) option available for the hollow-tank variants (both bare tank and paneled hollow variants). Can select independently for top and bottom; so on the 'hollow' tank setup (either paneled or non-), you could select 'hollow' adapter for top and 'full' adapter for the bottom.

(can also leave the bottom adapter as hollow as well, stuff another smaller octagonal tank on the node, offset it into the hollow recess, and put the descent engine on the smaller tank; adds one more part, but can be a better use of space, and gives more fuel volume)

Anything not yet flying is basically really YOUR vision. If you like the 8 tank (I do, too, lol), then that's it.

I have another tank layout thought. Half hollow.

The 8 tank you show a few posts up. Imagine the central tank only taking up ~1/2 of the hollow space vertically. If the empty space is in the top half, the player can sink an ascent engine into it. If the empty space is on the bottom (just flip the tank in the VAB with the s key), then the engine can be inset into the landing stage.

1. LOVE the new tanks
2. the 8 tank exposed Round reminds me of the Soviet Fregat and some of it's predecessors... So it could also be the Probe/Satellite bus for a smaller upper stage.

I have another tank layout thought. Half hollow.

The 8 tank you show a few posts up. Imagine the central tank only taking up ~1/2 of the hollow space vertically. If the empty space is in the top half, the player can sink an ascent engine into it. If the empty space is on the bottom (just flip the tank in the VAB with the s key), then the engine can be inset into the landing stage.

Yeah, I had had the same thoughts. Would be nice to be able to have half of the tank as hollow, the other half as full, to allow for inset engines on only one end.

The problem comes down to -- where to split up the model, and how to enforce proper AO and adapter selection? (and also, it would mean making another at least 4 body models).

• As the top dome of the 'central tank' is part of the upper adapters, it would require using the 'hollow' adapter -- BUT ONLY ON ONE END.
• Would need its own AO bake - for each length - as the AO would be different for each and every setup. -- would mean lots more textures (trying to reason through a way to simplify this bit of it, might come up with something).
• More colliders. Would also require changing the collider layout for every other model used in this variant to accommodate it (prohibitive, as those models are intended to be used in other variants as well).

And then someone is going to come along and be like 'ooh, but can I get it inset on -both- ends'. F__k me.

Really, you can already get the 'half-hollow' setup using the proposed models by simply using two fuel tanks.

(I'm still going to give it a bit more thought, but no promises; the 30 models I already need to create is far too much for me at the moment)

(unless someone wants to offer their modeling and texturing time?)

Oh, yeah. Or a hollow mount tank. Or just the plate on the bottom for an engine, with a hollow top.

I love that Idea personally Tater. But isn't that going to cause the need for 7 or more collieders? I am OK with that but I want to make certain we mention that due to the discussion in forum prior to the start of this revamp section.

Well, the current tanks allow this by using the nose/mount options, basically 2/3 tanks in one part, but that's not an option anymore?

The current tanks are a giant ugly hack of trying to get the original tank models to work with the MFT system (editor list cleanup mostly), and also reduce part-count through the nose/mount 'stacked' tank options. Some of it is a bit weird though, like I had to add empty dummy nose options to add inset nodes and such. The texture scales / structure scales for some of the combinations are clearly out of sync.

The new tank layout is quite a bit different; instead of each model being a complete tank assembly, the tank will be split into three pieces - nose, body, tail. This is being done for several very good reasons, but does have its downsides as well.

• + Allows multiple heights of tank simply by changing out the central body model. Tank-stacking for more volume shouldn't be necessary.
• + Tight coupling of the texture scales/model scales.
• + Overall increase in available variants (even before considering inset tanks).
• + Simpler initial modeling of the shared geometry - most meshes will be shared across all of the variants / lengths.
• + Simpler texturing arrangement - Diffuse/spec/nrm/mask textures can be shared across all variants. Only AO will need to be redone for each exported part/set (more per-variant, so 4x AO sheets).
• + Hopefully lower texture size (per set); the current set is 10mb for the diff/nrm, and that is only one texture set.
• - More actual models to put together, bake, and export. Old system had ~15 models (all unique), new system will be >30 models (mostly shared/re-used geometry).
• - No more built-in tank stacking. Was kind of useful, even with with the scale mismatches.
• - Loss of the modular attachment slots for legs/etc in the models. But as those functions haven't worked since ~KSP1.0/1?, its not a huge loss.