[WIP][1.8.x] SSTULabs - Low Part Count Solutions (Orbiters, Landers, Lifters) - Dev Thread [11-18-18]

[Shadowmage]

that would also allow for a Jupiter-like recreation without using Procedural Parts

They will likely be coming soon'ish (more texture sets). Going to take a fair bit of plugin work, but I think I'll get that going next week.

Also, just curious, in .4.x, what does LC SKY mean? A new lander can?

LC2-SKY, LC3-SKY, etc are going to be 1/2m tall skycrane modules; will have deployable engines, SAS, and (some) integrated fuel and EC capacity (perhaps solar or RTG as well, so kind of a skycrane/service module).

Although I have been contemplating doing a Dragon-like capsule (or set of?) for atmospheric landers / ascent setups. The problem is the balance / making it look good while still keeping it modular, esp. in regards to stock planets (Duna is easy enough to lift off from, but Laythe and Kerbin require substantial dV, and... I don't touch Eve with anything intended to return to orbit...). Would be quite a ways off, if at all.

Oh my God...

PS: Just to refresh, would you classify this as stockalike?

I would certainly call it stock-compatible; balance should be in the range of stock parts, and quite usable alongside them without introducing things that are too obviously overpowered (or that is the intent; please let me know of stuff you find to be too OP).

Stockalike though... would depend on your definition of the word. I usually take it to mean stock-compatible -and- textures are done in a stock consistent manner. Under that definition, no, I would not call it stockalike; I use a different color pallete (b/w closer to KW rocketry, other colors sampled from photos, a few custom), and my textures make extensive use of (noisy) AO bakes and generated noise rather than the hand-painted (I believe?) textures that stock uses (they do use AO on many textures as well). I'm generally going for a cleaner/newer/more serious look than stock parts, while still keeping things at least slightly cartoony.

[VenomousRequiem]

Updated test/pre-release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.2.12-beta

Tons of changes, see the link for downloads and the full change log.

Highlights include DDS textures for many parts, several new parts to play with 5m stuff and the semi-procedural fuel tanks for 1.25m, 2.5m, and 3.75m diameters (no engines/etc yet), and quite a few bug fixes.

Please let me know if you run into any problems/issues with any of the parts or plugin functionality.

I'm also interested to hear what you all think of the balance regarding fuel quantities/mass/etc for the tanks, engines, and SRBs.

Did you update this in the Dropbox folder? :b

Edit- Thank you.

Update- You're going to include radial decouplers for the SRBs, right? Why not make then include rockets of some extent to fire the spent SRBs away from the core! I believe SpaceY Heavy Lifters has these, and they're great.

Edited October 4, 2015 by VenomousRequiem

[davidy12]

KW, in my opinion is stockalike, so yeah, stockalike SLS FTW!!!

- - - Updated - - -

PS: Where are the SRBs? Can't find them in the engines.

- - - Updated - - -

NVM. R I ttly blind.

[davidy12]

Though in my opinion, the five segment SRB needs more burn time.

- - - Updated - - -

PS: I think a dragon v2 capsule would be fantastic. 7 crew on the surface of Duna FTW!!!

[riocrokite]

engines and tanks work and look fantastic

Maybe I missed it but it could be worth to make 5-3.75 and/or 5-2.5m tank (long and/or short?) adapters

[Shadowmage]

[VenomousRequiem]

I like every last bit of that.

Have you made a texture switch plugin?

Also, another thing I've noticed...

With just an Orion MPCV and a ICPS upper stage, the 4 nozzled engine doesn't seem to have a sufficient TWR to get to orbit without reaching apoapsis on it's ascent and just falling back down... Orbital mechanics sure are weird.

Maybe it's just because the tank I used was too big? I used the 35m tank.

Edited October 4, 2015 by VenomousRequiem

[_Augustus_]

http://i.imgur.com/RcgxNci.png

http://i.imgur.com/7n4nEKg.png

http://i.imgur.com/Sw4XLHt.png

That is beautiful. When will I be able to test that?

[davidy12]

Looks great!!! You think you can make a 1/2 engine Earth Departure stage for Ares models?

- - - Updated - - -

Or at least increase the times for the SRBs.

[Shadowmage]

engines and tanks work and look fantastic

Maybe I missed it but it could be worth to make 5-3.75 and/or 5-2.5m tank (long and/or short?) adapters

I'm contemplating/working on a more complex system for the fuel tanks. Likely will be a custom module rather than the cobbled-together set of modules I have now; would include the option to add/remove a top and bottom adapter or nosecone to the fuel tanks, and multi-fuel handling capabilities. I realized trying to make it all work with my existing modules would be a giant hack and be such a PITA to maintain / enhance in the future, so doing a custom-fuel-tank module seems the best way to go about it; clear design requirements, cohesive data layout, and I've already worked out most of the working bits from the other modules (and might even be able to still use some of them).

So, yes, adapters and nosecones are planned for the fuel tanks, but will be a ways out due to needing a ton of plugin work (advance warning... will likely break existing setups when modules are changed over).

I like every last bit of that.

Have you made a texture switch plugin?

Also, another thing I've noticed...

With just an Orion MPCV and a ICPS upper stage, the 4 nozzled engine doesn't seem to have a sufficient TWR to get to orbit without reaching apoapsis on it's ascent and just falling back down... Orbital mechanics sure are weird.

Maybe it's just because the tank I used was too big? I used the 35m tank.

Yeah, I cobbled together a quick texture switch plugin. It works, but wow... the length of the config for it all is silly (>1000 lines for the file). So, not sure if I'll actually be using it or not (see above)

I've upped the SLT/atmo ISP on both the SRBs and several of the engine clusters to help with this a bit. Though what you are describing is strange; I had no problem getting that one to orbit that I posted yesterday (using 4-engine, 35m tank, 5-segment boosters)... might have been the 5-engine I was using though. Also, it helps to reduce the thrust on the SRBs to ~50% (1-minute duration). The increase in srb burn time means more fuel is burned from the main tank by the time they separate, and the TWR at that point is a bit higher.

Will check into... however, the 4-engine isn't really meant for the super huge tanks (thats what the 5-engine is for...lots of thrust). I'm not really going for enabling SLS-recreations, just using it as a basis for some parts. Will see what I can come up with though, perhaps increase the thrust on the 4/5 engine variants even more, and decrease the gap between their thrust levels a bit. Might be able to fudge the numbers a bit to make it work.

That is beautiful. When will I be able to test that?

-Maybe- next week. Texture looks alright, but could use some work. I'm mostly debating on the plugin... it is very functional as-is, but cumbersome to write the config for, and will likely be replaced in the near future anyway (possibly a few weeks). So... not sure yet/we'll see.

Looks great!!! You think you can make a 1/2 engine Earth Departure stage for Ares models?

- - - Updated - - -

Or at least increase the times for the SRBs.

The best/only way to increase SRB burn time is to use the throttle-limiter in the VAB. The only other 'options' won't really work, as they would violate physics/game balance (increasing ISP substantially, or adding a lot more fuel).

I intentionally left them with a ton of thrust and a 30s burn time to allow for a bit more variety in use.

The upcoming increase to their atmo isp/sea level thrust will also help with this, as they will have more thrust where it is needed (on the ground), and thus more room for lowering it to increase burn time if needed.

- - - Updated - - -

You're going to include radial decouplers for the SRBs, right? Why not make then include rockets of some extent to fire the spent SRBs away from the core! I believe SpaceY Heavy Lifters has these, and they're great.

Still contemplating, figuring out how it would work. Ideally, yes, I want to add some separation motors into the radial decouplers (in addition to the decoupling force). Will take a look at the SpaceY stuff to see if I can figure out what/how they did it.

Sadly, the way I really want to set it up just won't work out properly (built-in separation motors with separate staging icon/action). Perhaps someday KSP will support it

[Shadowmage]

Working through the design requirements for a 'CustomFuelTank' PartModule. This would be the module responsible for managing all aspects of the customizable fuel tanks.

Going to throw it all out here for feedback before I get too far along; always easier to design with something in mind than to hack it on later at the end.

Requirements:

01.) MODEL node based setup - not procedural geometry. This allows for discrete UV mapping of models, better textures, and more interesting geometry.

02.) Allow multiple tank length variants for each part. Specific variants are not limited by the plugin, but by the models used. All values relating to tank sizes will be exposed in the config.

This will need the ability to move attach nodes depending upon tank length.

03.) Allow independent variable end-caps/adapters for the tanks. One adapter for top, one for bottom, both controlled independently. Can choose between various sized/length adapters, slopes of nosecones, or no adapter/nosecone at all.

This will need the ability to offset attach nodes or remove them entirely.

This will need the ability to add the adapter/nosecone fuel quantity into the main tank quantity.

04.) Allow switching between multiple fuel types in the VAB.

Might be able to use existing resource switch module; if it can be adapted to 'add' tank definitions together (likely doable, hopefully not too much of a hack)

05.) Allow switching of fuel types in-flight (config-option to disable); only works on empty tanks.

06.) Allow switching of tank textures (in VAB only?). No limitations or special treatment for textures. End caps get texture swapped at the same time as main tank segments.

Likely will end up using existing texture switch, as there really is no cleaner way to do it; its just going to require 100+ lines per texture to define all the texture-mesh combinations; no way around it that I can see.

07.) Allow defining tanks by basic phyical characteristic - volume -- this combined with other input determines final tank stats; no need to enter actual fuel quantities, mass, or costs; they are all calculated for you.

08.) Raw volume defined per tank and end cap; added up to determine total raw volume; might allow a 'mass offset' for minor special cases

09.) Basic data map containing info regarding the per-fuel-type tankage ratio, tankage mass factor, and costPerDryTon; this is used to calculate the final tank resource stats, mass and tank cost.

10.) Data regarding resource volumes will be included in the map and density pulled from GameDatabase

Alternatively, use a custom .cfg file to define resource volumes? IMHO these -REALLY- need to be defined in the game somewhere universal; preferably as part of the resource definition; otherwise you end up with the silly situation we have now (multiple volume units being used; 1l, 5l, 10l, 0.5l; its chaos)

11.) Completely -remove- unused meshes after flight state is initialized (cannot swap length in flight, no need to store all the extra data). -Might- offer a slight optimization in memory use and object tracking overhead.

--Late additions--

12.) Allow limiting main-tank variant availability by tech-tree-node; tank sizes can be unlocked by specific tech-tree nodes.

13.) Multi-attach node support for end-caps. Includes multi-orientation nodes. Want a 3-way hub on top of your tank and a flat adapter at the bottom? Sure...

Anything obvious that I am missing?

Will likely start on the prep work for this today -- adapting ResourceSwitch to accomodate multiple active tanks and fixing up the current MeshSwitch modules to make use of it.

Current intent is to have this finished up and usable for this weekends' release. Should be quite doable after I finalize the requirements and design layout.

Edited October 5, 2015 by Shadowmage

[riocrokite]

Working through the design requirements for a 'CustomFuelTank' ...stuff...

One word : FAN-TAS-TIC

A quick thoughts-dump below, note that those are not necessary, just good-to-have because you've already covered the most important stuff:

- support for an animation (i.e. for a separate mesh that won't be switched). Multiple animations (separate animation per mesh) depending on mesh would be perfect but I guess code-wise it's not worth the effort (i.e. different variants of inflatable tanks)

- separate (mini)mesh switch for different variants of fuel (probably not worth it since it can be done vie standard mesh switch)

- account for different center of mass depending on mesh (as I think of it I guess it can be done already just have to prepare meshes that have parent node with offset)

- ability to attach simple converter or other module to some mesh variants (i.e. a tank version with integrated fuel cell or rtg)

- ability to add passengers to mesh variant (tank with some space for a cabin). Probably not worth the effort

- ability to add mesh variants with integrated decoupler/docking port.

- node groups that are switchable depending on mesh (for example long tank might have more side attachment points, while other tank has less). Ideally nodes could be grouped to form something like JSIpartutilities node group switch; example config from my MFS mod:

node_stack_top1 = 0.0, -1.05, -0.15, 0, 0, -1, 2
node_stack_top2 = 0.0, 1.05, -0.15, 0, 0, -1, 2
node_stack_top3 = 0.0, 0, -0.15, 0, 0, -1, 2

node_stack_ut1 =  0.6925, -0.525, -0.15, 0, 0, -1, 2
node_stack_ut2 =  -0.6925, -0.525, -0.15, 0, 0, -1, 2
node_stack_ut3 =  0.6925,  0.525, -0.15, 0, 0, -1, 2
node_stack_ut4 = -0.6925,  0.525, -0.15, 0, 0, -1, 2
//----------------- Utility NODES SWITCH -----------------------------------
MODULE
{
    name = JSIPartComponentGroup
    groupID = UtilityNode
    areComponentsEnabled = true
    persistAfterEditor = false
    activeInEditor = true
    activeInFlight = false
    activeWhenUnfocused = false
    enableMenuString = - Utility Attachment
    disableMenuString = + Utility Attachment
    showToggleOption = false
    managedNodes = ut1|ut2|ut3|ut4
}

//----------------- TOP NODES SWITCH -----------------------------------
MODULE
{
    name = JSIPartComponentGroup
    groupID = TopNode
    areComponentsEnabled = true
    persistAfterEditor = false
    activeInEditor = true
    activeInFlight = false
    activeWhenUnfocused = false
    enableMenuString = - Top Attachment
    disableMenuString = + TOP Attachment
    showToggleOption = false
    managedNodes = top1|top2|top3


}

[VenomousRequiem]

Is there a testing version of the texture switch stuff in the Drop Box folder?

[Shadowmage]

One word : FAN-TAS-TIC

A quick thoughts-dump below, note that those are not necessary, just good-to-have because you've already covered the most important stuff:

- support for an animation (i.e. for a separate mesh that won't be switched). Multiple animations (separate animation per mesh) depending on mesh would be perfect but I guess code-wise it's not worth the effort (i.e. different variants of inflatable tanks)

- separate (mini)mesh switch for different variants of fuel (probably not worth it since it can be done vie standard mesh switch)

- account for different center of mass depending on mesh (as I think of it I guess it can be done already just have to prepare meshes that have parent node with offset)

- ability to attach simple converter or other module to some mesh variants (i.e. a tank version with integrated fuel cell or rtg)

- ability to add passengers to mesh variant (tank with some space for a cabin). Probably not worth the effort

- ability to add mesh variants with integrated decoupler/docking port.

- node groups that are switchable depending on mesh (for example long tank might have more side attachment points, while other tank has less). Ideally nodes could be grouped to form something like JSIpartutilities node group switch; example config from my MFS mod:

Animation Support - Not sure what use there would be for animation support in a fuel tank. However, as animations are attached to models/meshes, this should still be doable using traditional animation modules. As long as the animated part were always present (e.g. was a non-changable end-cap), there should be no problems.

Mini-Variants - I'm contemplating allowing swapping of fuel types of the end-caps separately from the main tank. That would be about as complex as is going to get though; adding any more 'optional mesh variant' type stuff would require explicit coding per-variant-type due to the whole height-offset needed for sub-models (such as end-caps).

COM Offset - Maybe. Will likely just ignore end-caps/nosecones for COM though. If I really wanted to go this route I would figure out the proper COM offset for the fuel in the tank (e.g. a LH2/O2 tank will be heavier on whichever end has the O2).

Converter Module - Likely not. Would require custom coding of the converter module to allow it to be disabled, custom coding of support for module switching, and add additional complexity to the config setup; and stock plugin code is mostly non-adaptable for these purposes (too many non-overridable methods).

Passenger Sections - -Might- be workable. Will give it some thought. The main problem would be swapping of the internal space definition (or removal if no passenger section); no idea if this is possible on-the-fly / at runtime. At the very least it would already be possible to define a crew count and internal space in the config that is applicable to all tanks, you would just be responsible for making sure the crew compartment was present in -all- of your models (e.g. I don't think it will be possible to have a single fuel tank part that has both crewed and non-crewed variants, or that has multiple IVA choices).

Integrated Docking Ports - See the bit on converters above; even less possible with docking ports due to how tightly locked-down stock code is. Most importantly, there is no way to disable a docking port/module... so while I could properly move/position the transforms and model, I could not -remove- it. So, all of the fuel tanks would need the integrated docking port. Would already be possible to do this (always present docking ports) given planned code/layout - just build the docking port(s) into a single-non-swappable end-cap for the tank.

Additional Node Groups - I guess I don't see the point for a fuel tank? It has a top node, a bottom node, and a surface attach node. Adding anything else would really be going beyond the scope of a fuel tank. Would also greatly increase the complexity of the config setup (and plugin coding). I might be willing to look into adding multi-node support for each 'end' of the tank though. I can think of at least one use-case that I would possibly implement in the future (multi-tank cores; e.g. triple-tank core; would require multiple top and bottom nodes). Could also potentially be a case for an end-cap that is a multidirectional hub. Hmm... will see if I can get this worked in without too much overhead/complexity.

Basically, I'm trying to make a highly customizable -fuel- tank module, not the ultimate part-mesh-resource-texture-module-switch. I really -would- like to be able to create such a module (and would incorporate many of your ideas), but there are too many stock KSP/engine limitations that I cannot cleanly work around (such as runtime removal or disabling of PartModules).

- - - Updated - - -

Is there a testing version of the texture switch stuff in the Drop Box folder?

Nope; as I have to update it manually, I will only be doing it when I do new releases. If you want access to live in-dev stuff, you will need to setup + learn Git / GitHub (will be happy to help you get setup/started if you want, just let me know). Probably should have just gone that route in the first place...

It is also only a temporary test-module, and will be being rewritten sometime this week (going to make it much cleaner in the part.cfg by moving all the texture definitions to an external file and load them in the plugin).

- - - Updated - - -

One additional thing I would like to add to the fuel tanks is the ability to set Career Tech Nodes by tank-length; so that larger tanks are only available with specific unlocks. Just trying to maintain stock-compatible balance.

Edited October 5, 2015 by Shadowmage

[VenomousRequiem]

One additional thing I would like to add to the fuel tanks is the ability to set Career Tech Nodes by tank-length; so that larger tanks are only available with specific unlocks. Just trying to maintain stock-compatible balance.

Kind of like MechJeb does with it's modules? Maybe you could ask the creator/dev of MechJeb about it.

[Shadowmage]

Kind of like MechJeb does with it's modules? Maybe you could ask the creator/dev of MechJeb about it.

-Very similar-. I likely would not have dummy parts that show up in the tech-tree, rather the part would be unlocked by a specific node and would have an initial set of tank-lengths available. Unlocking the next/requisite nodes would unlock the further tank selections.

[blowfish]

Interesting plugin idea, I've been contemplating something similar myself. Some notes on what I've discovered:

1) Drag cubes for variable parts are a major question. There is a way to dynamically re-render them. If you're only working with cylindrical (or anything right prism-like), then it might be possible to just scale certain numbers in the drag cube.

2) Some animations, for instance, those on cargo bays, use multiple drag cubes (interpolating between them). This is even more difficult to support

3) If animations are supported, the same animation would need to be triggered across multiple models, which might require a bit of extra code

4) I don't know when/where Unity calculates MOI. Variable length parts seem to work fine for Procedural Parts so it might not be an issue but worth asking.

5) IVAs make crewed variants difficult - it might be possible to switch out the IVAs though

6) I've already written a plugin, based on the work of snoj and bac9, which allows switching of resources, meshes, and nodes, and drawing resource amounts, tank masses, and tank costs from central definitions. You can find it here. It's still in development, but feel free to use it as a resource, or if you want to collaborate on something more integrated let me know.

[JoseEduardo]

idk if this has been asked or not, but, is a RO/RSS version planned?

EDIT: btw, is there a specific reason for the tanks not be surface-attachable? I changed them on my end, but I'm wondering if doing so will invoke the kraken or not

EDIT 2: got my answer, kraken invoked while in VAB

Edited October 5, 2015 by JoseEduardo

[riocrokite]

I completely understand that Shadowmage, no worries:)

One more thing that comes to my mind since you're planning resource switching in flight when tank is empty: what about integrated resource dumping function for a tank? Something like fuel valve from smartparts:

http://forum.kerbalspaceprogram.com/threads/64227-1-0-4-Smart-Parts-v1-6-6-DDS-Textures-and-Bug-Fixes-July-5

Could be useful since you don't always have the ability to pump remaining resource to other tanks (or burn it:)).

[Shadowmage]

Interesting plugin idea, I've been contemplating something similar myself. Some notes on what I've discovered:

1) Drag cubes for variable parts are a major question. There is a way to dynamically re-render them. If you're only working with cylindrical (or anything right prism-like), then it might be possible to just scale certain numbers in the drag cube.

2) Some animations, for instance, those on cargo bays, use multiple drag cubes (interpolating between them). This is even more difficult to support

3) If animations are supported, the same animation would need to be triggered across multiple models, which might require a bit of extra code

4) I don't know when/where Unity calculates MOI. Variable length parts seem to work fine for Procedural Parts so it might not be an issue but worth asking.

5) IVAs make crewed variants difficult - it might be possible to switch out the IVAs though

6) I've already written a plugin, based on the work of snoj and bac9, which allows switching of resources, meshes, and nodes, and drawing resource amounts, tank masses, and tank costs from central definitions. You can find it here. It's still in development, but feel free to use it as a resource, or if you want to collaborate on something more integrated let me know.

1.) Yep, its pretty easy to recalc the drag-cube for a non-animated / simple part. Its pretty much DragCubeSystem.RenderDragCube(part). No point in rescaling them when re-rendering them properly is so easy.

2.) Aye, animations are tricky, and the drag-cubes for animated parts even more so. Is one of the main reasons that I was questioning requests for animations on a fuel tank. Currently I have no plans to include animation support in the custom fuel tank module (or any other module-swapping support). At a time when stock supports run-time disabling of partModules I will revisit this. Would love to dynamically add/remove the modules as needed, but it is not cleanly possible in stock.

3.) ^^

4.) I believe it treats the part as if mass were evenly distributed across the render bounds. Haven't dug into it much, but it hasn't seemed to be needed to mess with it so far (if its even possible)

5.) Aye. I'm also not sure if 'crewCapacity' is a persistent variable that is saved out in the persistence file for a part; would hate to accidentally vent someones crew when KSP re-initializes the part with 0 crew capacity before my module could 'fix' it. Should still be possible with the caveats I had posted above -- the crew compartment would need to always be present in the tank.

6.) Sounds interesting, and right in line with some of what I am trying to accomplish. Will certainly take a look at it. Might be interested in doing some collaboration at some point; will see what you have going and what the feature-set is.

idk if this has been asked or not, but, is a RO/RSS version planned?

EDIT: btw, is there a specific reason for the tanks not be surface-attachable? I changed them on my end, but I'm wondering if doing so will invoke the kraken or not

EDIT 2: got my answer, kraken invoked while in VAB

Currently I do not have -plans- for an RO/RSS version. Could be interesting though. And should easily be accomplishable through an MM patch (rescales, fuel changes). Will give it more thought as I get things closer to being stable/finished.

Will investigate the surface-attachability; it is just something I never think about when designing parts (I rarely use surface attach except for parts designed explicitly for it, such as science bits or radial decouplers). Honestly, it -should- work if enabled in the part.cfg file, but I cannot guarantee that there won't be weird bugs.

I completely understand that Shadowmage, no worries:)

One more thing that comes to my mind since you're planning resource switching in flight when tank is empty: what about integrated resource dumping function for a tank? Something like fuel valve from smartparts:

http://i.imgur.com/1F1Hkqc.png

http://forum.kerbalspaceprogram.com/threads/64227-1-0-4-Smart-Parts-v1-6-6-DDS-Textures-and-Bug-Fixes-July-5

Could be useful since you don't always have the ability to pump remaining resource to other tanks (or burn it:)).

Aye, should be easy to add a fuel-dump capability. Also looking to add the checks in place to disallow switching if the tank still contains fuel; so you can't accidentally swap your tank mid-burn

I did add in multi-node handling capability to the fuel-tank module; so that each end-cap can now be responsible for positioning (and enabling/disabling) multiple attach nodes. Should allow for some interesting adapters and fuel tank setups. Will give some more thought to a few of your other propositions; might be able to work a few of them in.

On that note, I did get most of the plugin written up last night; after I figured out the flow and layout, things started falling into place rather orderly. Works excellently so far. Still need to add in the tech-node validation bits, and updating drag cubes on model changes. Will also add in the in-flight fuel-change check, in-flight fuel swapping, and in-flight fuel jettison.

Will likely get that all cleaned up today and start working on the modeling end of things; have tons of end-caps and adapters to make now.

To start (bold denontes unique geometry, italics denote re-used model geometry):

NoseCone Straight 1 (tall) (rescaled for all diameters)

NoseCone Straight 2 (short) (rescaled for all diameters)

NoseCone Slanted 1 (tall) (rescaled for all diameters)

NoseCone Slanted 2 (short) (rescaled for all diameters)

5m -> 3.75m (short)

5m -> 3.75m (long)

5m -> 3.75m (flat)

5m -> 2.5m (short)

5m -> 2.5m (long)

5m -> 2.5m (flat)

5m -> 3.75m x4 (maybe)

5m -> 3.75m x3 (maybe)

5m -> 2.5m x4 (maybe)

5m -> 2.5m x3

3.75m -> 2.5m (long)

3.75m -> 2.5m (short)

3.75m -> 2.5m (flat)

3.75m -> 1.25m (long)

3.75m -> 1.25m (short)

3.75m -> 1.25m (flat)

3.75m -> 5m (long) (re-used)

3.75m -> 5m (short) (re-used)

3.75m -> 5m (flat) (re-used)

3.75m -> Mk3

2.5m -> 1.25m (long) (rescaled)

2.5m -> 1.25m (short) (rescaled)

2.5m -> 1.25m (flat) (rescaled)

2.5m -> 5m (long) (reused)

2.5m -> 5m (short) (reused)

2.5m -> 5m (flat) (reused)

2.5m -> 3.75m (long) (reused)

2.5m -> 3.75m (short) (reused)

2.5m -> 3.75m (flat) (reused)

2.5m -> 1.25m x4 (rescaled)

2.5m -> 1.25m x3 (rescaled)

2.5m -> Mk2

1.25m -> 3.75m (long) (reused)

1.25m -> 3.75m (short) (reused)

1.25m -> 3.75m (flat) (reused)

1.25m -> 2.5m (long) (rescaled)

1.25m -> 2.5m (short) (rescaled)

1.25m -> 2.5m (flat) (rescaled)

1.25m -> Mk2

If that seems like alot....well... its probably because it is. And still far from complete. Multi-way hubs can also be done / should be planned, not sure where/when (really would like the suggested option to include docking ports in them, if it were possible; could greatly reduce station part count by using a long central tank with docking adapters at either end; will continue investigating possible solutions). If you can think of options that I've missed, please let me know and I'll consider adding them to the list.

Hoping to be able to use a single texture for all of these parts. They will be mostly/entirely external faces, so there will be no/little need for AO bakes; which greatly increases texture re-usability. They will all share texture-set data with the main tank and have their texture swapped out appropriately when the main-tank texture is updated.

Thinking a bit further out on this module, I will likely be able to use it for -some- of the station parts as well (or perhaps just regular mesh-switch) to allow for multiple part-length variants and setups all in the same editor part. (really wish stock supported swapping part-modules; really want to add solar panels and docking port variants to the station parts....)

[JoseEduardo]

it did surface attach to the decoupler I was trying, the problem is that it decided to go transverse to the core tank

as for the RO version, I'll certainly be waiting for both, final version and RO (if you decide to go ahead with it of course)! tested your mod yesterday and I must say, well done! one of my favorite, for sure!

[Shadowmage]

All of the 'standard' adapters.

Have included Shuttle-ET derived nosecones; standard length, double height elliptic, and half-height pointed. Still would like one or two more nose-cone varieties. What do you all think? And have any pics for reference/curves for other nosecone types you would like to see implemented?

- - - Updated - - -

it did surface attach to the decoupler I was trying, the problem is that it decided to go transverse to the core tank

as for the RO version, I'll certainly be waiting for both, final version and RO (if you decide to go ahead with it of course)! tested your mod yesterday and I must say, well done! one of my favorite, for sure!

Ahh; can likely fix that issue up easy enough, just need to add the proper attach direction in the config file. Will get surface attach nodes defined for the next update.

Initial RO/RSS configs -may- come after I get the fuel tank stuff finalized. Would be interesting to see what these parts are capable when the stats are proper for the vehicle.

And thanks

[VenomousRequiem]

Wow that's a lot of nosecones and adapters! I could make a proper space shuttle ET, eh? Why not include a single version of the SX-25 so we can make proper shuttles?

Well hey, I found something:

The solar panels clip through the spacecraft adapter! I seem to remember the spacecraft adapter being a lot longer in previous updates, back when it was an actual part/decoupler. Is there any way you could get it to be all long again? It looked more like Orion and plus the panels didn't clip...

[riocrokite]

this is a part-o-bonanza ! I love it

[Shadowmage]

Wow that's a lot of nosecones and adapters! I could make a proper space shuttle ET, eh? Why not include a single version of the SX-25 so we can make proper shuttles?

Well hey, I found something:

The solar panels clip through the spacecraft adapter! I seem to remember the spacecraft adapter being a lot longer in previous updates, back when it was an actual part/decoupler. Is there any way you could get it to be all long again? It looked more like Orion and plus the panels didn't clip...

Yep, you can now (err.. will be able to) make mostly proper looking shuttle ETs of multiple diameters.

I -might- be willing to include a single engine. Lets see what the KSP 1.05 / SSME looks/performs like; supposed to be optimal for building kerbalized shuttles.

Yes, that -should- be able to be fixed. Best part, it can be done entirely in the config! Move the attach node downward, move the bottomY of the upper fairing portion down by the same amount, and move the top and bottomY of the lower fairing down by the same amount, and finally adjust down the bottomY of the side-panel fairings to line up with the bottomY of the top fairing portion. You are more than welcome to have a go at it if you would like. Will add it to the issues list though and mark it for this week, so I should be able to have it for next update. Will only apply to newly built vessels; already constructed vessels would end up with some messed up looking fairings (but would be otherwise perfectly functional).

this is a part-o-bonanza ! I love it

Yah, went a bit crazy lately on the new/stock replacement parts. Hopefully it should help out with vessel part count a bit in the end. Adapters at least are a good thing for me; I always skip them on my craft due to them being an unecessary/function-less part (unless I actually need the length). Thankfully most of these are quick/easy parts that shouldn't take me too long to get done acceptably. Hoping to wrap up all the fuel tanks/adapters stuff this week (as well as a bit more work on some of the other unfinished stuff).

In other news, hearing of KSP 1.05 makes me sad. It is a good thing that they are releasing what they can as it is available, but the (mod) community -really- needs 64bit support. And I was (almost) looking forward to being able to finally do a bit more complex GUI work (have been holding off in favor of the new unified GUI system, have a few planned parts/features that will need more GUI than can be done with stock right-click stuff).