Shadowmage

After a bit more research I have noticed the vast differences between the F1 / F1B. As such, the standard F1 would not work for those boosters, it is far too large (its like 2.5m diameter even after scaling 64% for KSP). So.. if I can find enough reference materials, I might look at doing an F1B engine as well. Seems like it would fill a niche pretty well. I've had lots of requests for decouplers/separators, and I've been putting some thought into a booster-separation mechanism, unfortunately I haven't had the time to even start prototyping it yet. Ideally I want to strap a couple of thrust transforms for SRBs onto a decoupler, and move the thrust transforms around (up/down) in addition to some model geometry (for the clamps/struts/surround rings). However this is going to require yet-another plugin and set of models and textures (will likely be making models for 0.625, 1.25, 2.5, and 3.75m strut/attach rings), and as such I'm currently lacking a bit of motivation to do much on it. It could/should be quick once I start on it though. Perhaps I'll see if I can muster up the will to get this done this week. I'm not really interested in doing any more vehicle specific stuff (unless it is truly unique and iconic -and- usable outside of its original use/modular). However I was already planning on doing the J2, J2X, and RL10(A+ engines; so, you should be able to make most of those vehicles with the existing fuel tanks and new engines when they are done. What I could use some suggestions / links / info on are some smaller KEROLOX engines. It seems that there are tons of LH2 engines around, or at least info on them, but very little in the way of kerosine engines (at least American ones, where the info is readily available; have noted several Russian ones, but I have problems trying to locate enough reliable info/pics on that stuff do to them). I'm open to engines from wherever, but there needs to be a ton of pics and diagrams available for me to work on it. Prefer 3-view/engineering diagrams where possible; photos are even harder to work from (though sometimes necessary for getting the details that were not well presented in the 3-view). Or really just any engines with lots of diagrams/specs/pics available. At this point I'm not going to be picky; if there are enough reference materials I'll likely do one up.

Nothing, yet. Need to model a bunch of engines before I can do what I want with them (or... at least 2 to get the basics working). The plan so far is for a semi-procedural engine part (like the fuel tanks) that allows for easy clustering of engines and gives a choice of mounting options (really just shrouded or skeletal). Ideally I will find a way to set these up to work for both lifters and upper stages (seems doable, mostly dependent on engine choice and mount size). Still in the very early concept stages though, haven't even started on the coding yet (starting on the models this time, as I figure I wanted a bunch of engine models whether the plugin works out or not). So... if I can pull the plugin off, you will be able to cluster the 2 F1's that you need, and already have variable sized fuel tanks (which is far more useful together than a single LFB model that would only be usable for one case/purpose).

Nope. Just making a bunch of various engines for an upcoming use. Chances are, as these engines will likely take me ~1 week each, that you guys won't be seeing any of these for a few months (have a bunch of engines to make, need them all done before I can work on the next bit, which needs to be done before the engines can be released). - - - Updated - - - Ehh? They look to me to be a fuel tank with some engines on the bottom? How/why do you need me to create them? And either way... probably not. I have no interest in creating discrete liquid fueled boosters. A fuel tank+engine works fine.

Yesterday and today's progress: The F1 Engine (Saturn-V). Playing around with/learning how to do all the pumps/piping, while keeping it at reasonable poly count for the amount of detail included. Finished model should be <6k triangles (SSME that I just did is ~4.2k per engine, for reference).

-Not- reworking textures. Maybe working on finishing existing WIP textures. Any texture marked as 'finished' will -not- be being touched until/if/when the part is completely redone. I hate doing textures enough as it is; there is no way I'm going to redo a finished texture just for the heck of it. And I personally think some of those are the better looking textures. Well, the CM could perhaps use some better tiles; but there is no way to do it given texture size/resolution limitations(unless you are wanting me to do 2048x textures for -every part-; which I'm actually unwilling to do anyhow). Really, I hate texturing things. And modeling. I seem to suck at both, and they take unreasonably long amounts of time for minimal and mostly unsatisfactory results. Those are the reasons -why- I am burned out; sadly it seems to be that KSP modding is 80% texture/modeling work, and only ~20% coding work (which is the part that I actually enjoy, or at least don't despise). (Seriously, I spent -all @#%^@#$^ day- yesterday working on engine geometry / plumbing stuff. For a single engine. And got maybe like 5% of the model done.) You are more than welcome to re-texture them yourself however. I can/will provide the original UV and AO maps if needed/wanted. But I will not be touching the textures on those parts in their current form.

Chances are very good (already have most of the config drafted up). However, I need to look into the legalities of distributing CRP with my mod, or otherwise redefining the resources when no other mods are present. And need to write up the actual patches to enable the choice. I actually didn't try to even launch that rocket (nor could I have, there were no decouplers on it anywhere), just wanted a recognizable pic to post up with the release Sadly, I got little/no time to test or play with things over the weekend; real-life decided to step in and keep me occupied. It does that from time to time. 5m fairings are on the 'todo' list. Likely a 5m straight, and 5m expanded (starts at 5m, tapers outwards a bit) fairing, using the stock fairing module with some custom base geometry. If you've seen the KW rocketry ones, they will likely be very similar. Nope, not at all (worth it). However, when I modeled those parts I was going for 'realism' (and had intended on originally using proper scaled values for mass/isp/etc), and as such designed the engines and RCS as they are (or close to) the real article. However, if/when I rework the model I will either be removing the secondary engines or repurposing them as high-thrust RCS ports. Currently all the 2nd engine does is mess up MechJeb when you have the engine disabled (it thinks you have higher TWR than you do, and doesn't start burns early enough). So, yes, that is a problem that will be looked into as time permits, but it is likely months out before I start re-doing any of the older parts (probably sometime after KSP 1.1); have tons of stuff to finish and a few new concepts that I would like to develop. Redoing a few of those parts is on the extended todo list (want to rework the ICPS/HUS as well a bit) Feeling a bit burned out at the moment, so will likely be taking things a bit slow this week. Will likely concentrate on bugfixes, balance, and a bit more texture work for this weekends update/release. I'm currently thinking through options for a customizable-engine module, and might start doing a bit of engine geometry for various engines, though none of it would likely be finished/usable for the next release (engines generally take me a bit). Will probably post up the preliminary design/draft/specs on the engine stuff later for feedback -- if I can get the initial specs figured out.

Sorry for the delay. Just as I was wrapping up testing and getting ready to package things up, I had to help a friend out whose motorcycle had died on him. To make a long story short... now I've got a motorcycle stored in my garage for a bit. Anyhow... I present to you... the 'Lots of textures' update. Also nosecones. Maybe its the 'Lots of adapters' update. Its got lots of new stuff one way or the other... WARNING - This update will break craft using existing versions of the custom fuel tanks due to a complete plugin rewrite/change. I think the new feature set is probably worth it in the end though (nosecones, fuel types, texture switching). https://github.com/shadowmage45/SSTULabs/releases/tag/0.2.13-beta Full change log is behind the link, as are the downloads. I did notice one problem in the VAB related to using part symmetry on surface-attached custom tanks; I believe the symmetrical tanks are trying to update one another, but doing so poorly. I had noticed model duplication and texture-set inconsistencies, but only when symmetry was used with surface attached tanks. For now you can work around it by setting up a single tank fully to your preference, and -then- using symmetry to attach it. Or just setup to tanks without symmetry, whatever works. Texture bloat in the main release will likely be dealt with soon through texture size reduction for some parts, and moving the alternate texture sets off into a separate optional download. As usual, please let me know if you run across any problems or issues, or have suggestions regarding improvements or balance. You can find the issue tracker at: https://github.com/shadowmage45/SSTULabs/issues, please check it before reporting issues. If your problem is already listed, feel free to add any new / relevant information you may have. Thanks, and enjoy Shadowmage

Hit a last minute issue with the editor-part-size detection stuff. Thought I had it cleaned up last night, but apparently I didn't test it well enough. Implementing a new solution that actually solves many other problems as well -- model load-on-demand. Going to take likely another few hours to get it all sorted and working. The good news is that it cleans up the last of the known issues and improves performance by not having all of the meshes/colliders constantly attached to the part.

Aye, got that one saved into my resources folder. Had actually used some images from that for the diagrams when I made the HUS Is certainly one of the more informative and detailed bits of information out there. One thing that I do want to make is a set of payload adapters / fairings (at least for 5m). Still a bit undecided as to how I want to do it (stock fairing w/ custom texture + geometry, custom fairings... ??) So far the texture-switch module is separate from the mesh switch/custom fuel tank modules, and they can work completely independently (and is the only way they work currently). However I do have the texture switch setup in such a way that it will accept input from external modules, so in the future I could specify a per-fuel(resource)-texture; similar to MKS/Kontainers texture switching. Or really, you could trigger the switch off whatever; it just accepts a single input parameter -- the String name of the texture set to enable. Texture sets are defined outside of the part.cfg, in separate files (GameData/SSTU/Data/TextureSet-XXX), and can be added/removed fairly freely (and have parts added to/removed from them). If a texture set is not available that is specified in the part, nothing bad happens (you get to click the button an extra time to skip past it). So yes, you can certainly add in more texture variants... now... later... both... whichever. Should have no effect on stability / existing save games. Things are looking good so far on the release. Had a last minute scaling issue that I had to clean up, but it looks like all the fuel-tank stuff is in and working, at least well enough for its initial setup (a few adapters are not included where they could be). Going through and doing a bit of internal testing on all that stuff, and then I have a couple other small issues to tackle (SC-B-SM lower fairing clipping with solar panels), but I can't forsee any problems with those. So.. hopefully here in a few hours I'll have the updated release ready. Advanced Warning -- This update is going to break any craft (saved or in-flight) using the previous versions of the configurable fuel-tanks. I'll post more warnings with the release post, and on the download page. I would apologize for breaking things... but such is the nature of development and progress (and why these are test releases, in the test/dev thread, with a big disclaimer at the top stating things will often break between releases). But I will thank you all for helping to test things and provide feedback, and generally guide the evolution of the mod.

I actually -just- noticed and fixed that bug while I was working through the editor-icon size stuff (which should also be fixed here shortly). Thanks for the report though, let me notice if you run into anything else odd.

Hmm... Feels like there is something big missing from this picture: Oh, right! SSTU doesn't have any shuttle parts! (and I removed the stock ones from my dev setup to speed up the load times) - - - Updated - - - Awesome, thanks for the references. Will see what I can do about adding in a few more decorative paint-schemes based on a few of those (after I get the parts finished/working!). And yes, I believe the white on the Soyuz is ice/frost on the tanks (you can see the fogginess of it in higher-quality versions of that photo...probably even that one if you zoom in). Regarding upper stages/engine configs... have a few ideas in the works that I need to investigate a bit more, but chances are that I will be writing a custom plugin to handle the upper stages; so you -can- swap in different engine variants/etc, or swap tank configs, based upon your specific needs for the mission. They will likely -not- be 'one size fits all' deals like the current ICPS/HUS, but more of a modular/configurable part(s). It may well be that I end up creating some strange engine-config-swapping plugin to handle the differences in engine specs.... we'll see. Still a ways out on those, so its good to post up your ideas / feedback / suggestions. Even if I don't use them exactly, they will likely influence the final design / part setups. Thanks Be sure to check back in a few weeks to see the upcoming developments (going to be interesting!), lots more fun stuff to come. There are currently no RO/RSS configs, and it would still be a -bit- early to start working on them anyhow, as so much of the mod is still in flux. However I'm pretty sure they -will- be developed in time, even if not directly by me. You are more than welcome to help contribute when the time comes (... could start on them now, but might have to rebalance / update stuff as the mod progresses). Edit -- Two more quick questions before I dive back into dev stuff: Thoughts on the upper/lower stringers on the orange tank texture? I'm a bit torn... they break up the monotony of such a large texture, but they also seem a bit out of place for the orange tanks. Any desire for a Delta-IV specific orange texture, with the white inter-tank (as opposed to the yellow/orange on the Shuttle ET)? Would mean more textures / larger download / bigger memory footprint (not as relevant with 64-bit, but VRAM is still limited). Perhaps I should offer most of the variants in a separate texture pack(s)?

Thanks Still lots of improvement to come. Aye, the Merlin looked like it would be good candidate for an engine, at least based on its stats and intended use. Sadly the information availability is a bit low, but I can hopefully dig up enough to sketch one up. If I were to already be modeling the thrust-plates, I might as well stick the engines on them (And as reducing part-count is the entire premise of this mod....yah...) I have no (personal) problem with editor part-count (though I do try and keep it as minimal as possible), and would much rather have a long parts-list than induce higher part-count on my vessels. Edit: Anyone have any information / links to Russian rocket paint-schemes? (or really, any specific pics of paint-schemes you would like to see included.... German, Chinese, whatever). Would like to include a few more paint-scheme variants, but my imagination is fairly limited in those regards.

Aye, I personally prefer options. Have had complaints in the past though regarding right-click menus being too long. Though, these should still easily fit on the screen. Flags -- umm...not currently? It is complicated working out the placement of the actual flag mesh relative to what tank size is being used; cannot easily use multiple meshes (e.g. one per tank) as the module only supports a single mesh (would require 8 separate modules, and the subsequent config file bloat). Will give it some thought though; could always code in some special handling to move/reposition the flag mesh depending upon the tank used, though that would require yet-more-data to be setup in the tank definitions in the config file. Ideally, yes, I want to be able to have flags on the tanks. Just had not yet thought about how to do it. Might not be finished for tomorrows release, but I'll add it to the 'todo' list. Consider it done then. Not too much extra complexity for the coding end of things (and actually simplifies the configs a bit); just didn't want to overload the GUI too much. Oh-well, GUI clutter can/will be cleaned up after KSP 1.1. Ahh, well, that explains why I was having such a time with the geometry of the RL-10 between the ICPS and HUS. I was aware there were different versions, but I thought the extending nozzle was standard/universal across them (or at least that the HUS and ICPS were using the same version; with extending nozzle). Makes a ton more sense now, and will likely help me get the geometry straight when I rework those parts. Here is the -very- preliminary list of engines that I'm -thinking- about modeling for lifters and upper-stages: Lifter / first stage engines: RS-27 - Delta-III -- https://en.wikipedia.org/wiki/RS-27A RS-68 - Delta-IV-CBC -- https://en.wikipedia.org/wiki/RS-68 RD-180 - Atlas-V-CCB -- https://en.wikipedia.org/wiki/RD-180 Merlin M2/M3 - Falcon 1/9/Heavy -- https://en.wikipedia.org/wiki/Merlin_%28rocket_engine_family%29 RD-107 - Soyuz 1st Stage -- https://en.wikipedia.org/wiki/RD-107 RD-253 - Proton 1st Stage, UMDH (monoprop) -- https://en.wikipedia.org/wiki/RD-253 Second Stage/Upper Stage engines: RL-10 - DCSS/Centaur/Saturn-IV -- https://en.wikipedia.org/wiki/RL10 (likely make 2 variants) RD-0124 - Soyuz 2nd Stage -- https://en.wikipedia.org/wiki/RD-0124 J2/J2-X -- Saturn S-II and S-IVB 2nd Stages -- https://en.wikipedia.org/wiki/Rocketdyne_J-2 --Seems like there are not that many different upper-stage engines currently in use? Other suggestions appreciated; links to specs and images required if you want them to be considered. Having a bit of a problem locating engines that would be acceptable for 2.5m lifters (and 2.5m in general). Seems most of the newer stuff is all geared towards really large rockets. Will likely go retro and look into some engine designs from the early days of rocketry (and a bit lower-tech; which makes sense for the KSP tree progression), Mercury-era or so. Would love to be able to rely on Nertea's work (he does excellent work!), unfortunately, that would leave the mod/part pack missing large portions of capability (and Cryo-engines are geared specifically towards Nertea's LH2 balancing), and does nothing to further the 'low part-count' goal (Nertea seems to like forcing lots of extra parts to be used...for example, requiring external radiators just for a reactor..... the radiators need to be included in the reactor model, or at least have that as an option).

Quick question: Should I have the textures for the end-caps/nosecones swappable independently from the main tank texture? This would enable, for example, Delta-IV like configurations with an orange tank + white nosecone. It would also add yet-more-buttons to the right-click GUI. Thoughts?

Ahh, yah, I can see about some layouts like that. In the end it will depend on which engines (bells) I model and what kind of performance is needed from the upper stages. For the lower stage; unfortunately off-center engines like that won't work properly in KSP due to lack of proper per-engine thrust vectoring and throttle control. I might be able to do a 3 or 4 engine in-line config, but would have to be fully symmetrical. Again, will depend upon what engine(s) I model and the needs of the lifters. Any engine suggestions (with lots of pics and diagrams!)? Already going to look into the RS-68, and re-doing a proper version of the RL-10 (used on the ICPS/HUS), and possibly a JX-2. Not sure what is used on the Atlas / Delta upper stages (or lower stages even), but can probably find that out easy enough. Ideally, I'm looking for engines with distinctive engine-bells -- all the plumbing/pumps are hard for me to model and add insane tri-count, but I might be willing to try one or two in decent detail. You craft is looking good Saw the SRBs and went 'Wow, those look nice... wonder where they came from'... then realized they were mine. Probably time for me to 'play' a bit more KSP again Things are looking good towards having an updated release tomorrow. Plugin code seems to be working well so far. Models have all been exported and are available in-game. Have a few updates/changes to make/re-export a couple of them (only 4...), and -tons- of texturing work to do. So... textures might be a bit rough for the nose-cone/adapter bits initially, as I don't think I have time to fully clean them up for this release; they will all have textures, but there might well be visible seams and most will be lacking detail, and none will be finished. On the config end of things I managed to get the tank config file definition down from >2000 lines to ~500 lines last night through some refactoring of data storage, parsing, and layout, while still allowing for the same level of control and customization, and greatly increasing the human read/write-ability of the file. Still have a bit of optimization to do on the texture set definitions (they are currently like 300-500 lines each), but as those are stored/parsed separately from the part.cfg file, that is something I can work on a bit more leisurely. Currently for the GUI/controls I'm using the stock right-click gui with standard 'next ___ ' buttons. This is a temporary interface and _will_ be rewritten when KSP 1.1 is available; holding off on doing any custom GUI work until the new GUI system is available. Ideally I will replace each button/set of buttons with a single slider that includes prev/next buttons as well as the description (you can see these types of widgets/controls used by other mods / implemented through KSPAPIExtensions). Sadly, I finished up pretty late last night, so don't have any SS to show yet... but will get some teaser shots tonight

When they are ready, sure Right now they are in various states of broken as I finish up the new plugin to drive them, add in all the end-caps, texture-set definitions, volume/height/fuel stuff, node definitions and positions, and finally link it all together. If I were to pack up and release what I have right now... none of it would be working properly/fully. If you haven't noticed, I tend to do test/beta releases weekly (not guaranteed though)... so expect a new one around a week since the last one was posted (So..... likely Saturday, assuming I can clean things up to a usable state by then).

Point noted. Will play around with the stripe thickness a bit. Really those nose-cones in the render were me just playing around seeing what was (easily) doable given the UV mapping of the pieces. Vertical or horizontal stripes should work well on any of the standard adapters. The multi-couple adapters though... ugh.. the UV maps on those is... ugly. There was just no way to map them to allow for both ease of texturing -and- distortion free textures. Had to be some of the worst pieces to unwrap that I've seen (like a cone...but worse because the angles change between every face...). So far the adapters are only included as end-cap options on the fuel tanks. Will consider also releasing them as discrete parts if there is demand for them (though... it is _alot_ of parts). Have any specific pics of the engine/adapters you are referring to? Tons and tons of pics behind that link, and I've no clue which you are referring to. Now is a good time to start with suggestions regarding the upper stages though, hoping to go into work on those knowing exactly what I need/want.

And.... the current full set of adapters/end-caps (not all will be available on every part, or even used initially): Now to do some texturing for all these end-caps and noses... Any suggestions? Kind of want to add some stringers to the sides of most of the adapters, and the bottom edge of some of the nose-cones. Suppose I should just get to it and see what it looks like

Hehe, welcome to being a modder. I break things at least twice a day (oftimes, much more!). Just gotta be not afraid of it (and know that it can always be fixed / restored to where it was at least). Sounds good on the configs/patches. I have no problem if someone else wants to make them up (I do accept pull-requests / can merge them in). Will let you know when things are stable enough for patches/configs to be made; currently it would be counterproductive to do them as they would need constant updating to stay synched with the normal asset versions. I probably won't entirely skip this KSP version, but I certainly won't be doing anything special for it. So far it is seeming like a minor update though and hopefully there won't be too much needing fixed or updated to maintain compatibility. Regarding splitting the mod up, I have been considering it, but I've got a few 'situations' to clean up before it could be done. I use a lot of texture sharing, even between seemingly unrelated parts; for example both the LC and SC-C series use geometry and textures from the SC-A RCS blocks. I suppose I could always split them as needed, with duplicating assets where they are needed. Would result in a slightly larger .zip sizes; but if I setup the layout properly they should all merge into the same folder and result in the same setup in the end. Advertising -- aye, I will need to come up with a good plan when I'm ready for a bit more exposure. Still a ways off though. I'm really hoping/aiming to get things more cleaned up and releasable before/around the time of 1.1. I suppose I need to start outlining precisely what the precise direction of the mod will be, what parts are in the works, what parts are finished, etc, and perhaps start getting promotional material setup for those portions that are done/nearly complete.

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). 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).

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 - - - 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

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. 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. 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....)

-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.

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 - - - 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.

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.