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

[blowfish]

WRT to custom engine module; I might be contacting Sarbian shortly to figure out the best way to set this up. It seems like I'm not the only mod that could benefit from custom engine modules with full MJ support, but I'm unsure as to the proper method to setup such compatibility through c# while maintaining stand-alone capability (with Java you would use byte-code manipulation to strip interface defs from the class when the interface-base-class was not present). Ideally stock would add such an interface and all other mods would be able to use it for their custom engine implementations; though I highly doubt I will be able to get Squad devs to listen to my requests.

Can I ask why you don't want to derive from ModuleEnginesFX? A lot of the behavior is now overridable, and the module itself isn't very heavy performance-wise.

Re: effect switching - it should be pretty simple, since ModuleEnginesFX finds effects by name (note that there are default names so the relevant fields won't exist on every engine). You should just be able to change the relevant effect field names in the engine module.

[Shadowmage]

Can I ask why you don't want to derive from ModuleEnginesFX? A lot of the behavior is now overridable, and the module itself isn't very heavy performance-wise.

Re: effect switching - it should be pretty simple, since ModuleEnginesFX finds effects by name (note that there are default names so the relevant fields won't exist on every engine). You should just be able to change the relevant effect field names in the engine module.

Originally I wanted to implement a custom engine module to -cleanly- implement a deployable engine module. The current ModuleEngines/FX derived solution relies heavily on run time checks and basic hacks in order to enforce that the engine must be deployed before it can be activated; a very 'dirty' solution that has a few issues that I have been unable to fix or find workarounds for.

On the performance front I was doing a cleanup of the propellant-use code and had a much more optimized method for updating FX that did not run on every tick/game update (unless needed). It is more that I want custom engine modules for the bits that you can't cleanly implement on top of the stock modules; deployable engines and electric-only engines (I believe someone has figured out how to make these run using stock modules, but its been awhile since I looked into it).

However, for the time being, I -am- deriving from ModuleEngines/FX for the sole purpose of mod compatibility (mostly for MJ, though good for RO/RSS/RF as well).

Yeah, the effects shouldn't be too hard to link to the engine module. But I also need to manually create all of the effects groups at runtime from the config definitions as they will not exist in the part config like they normally would. IIRC I should have most of the code needed already in my retired custom-engine module (as it also dealt with run-time effects configuration).

Think I may have found a decent compromise for the scaling issues (also reduces models needed by a ton). Will result in slightly less detailed / less optimal mounts and shroud configurations, but should be much easier to develop assets for and do maintenance on. It might require ditching a few of the 'features' I had planned (such as custom engine-specific shrouds, e.g. for the rs-68); still working through the logistics on that end. I'm hoping to be able to keep them, but they might be a non-rescalable asset and only available on the stock setup (unless someone else wants to make the custom sized models for RSS).

[JoseEduardo]

With all the work you guys are putting in for RO, I'll probably be giving it a try for my next new game that I start (if I can get it all working properly in career mode).

I would consider that an honor

General Progress Update:

Running into some rather large issues with regards to rescaling; more specifically, allowing the custom engine clusters to cleanly be rescaled for use in RO/RSS/whatever and how it relates to the manually built models that I currently intend to use.

Engines are all modeled at 64% of real scale. Would be easy enough to rescale the engine models themselves back to realistic sizes. The problem comes from the hand-crafted mounts for stock stack-sizes; these do not cleanly rescale to RSS sizes using the standard 1.5625 '100% correction' rescale (e.g. 64% * 1.5625 = 100%). This results in strange/odd tank sizes (6.25m rescales to ~9.74m rather than the 10m it should, 5m = 7.8125 rather than 8.4m). If you rescale the mount to match the exact size needed all of the engines will need to be rescaled with it as well; resulting in different stack-sizes having different scaled engine models. Not good for a realism-based mod.

1.) The first alternative that I've thought up is to use consistent scaling for the engine mounts (e.g. 1.5625 scale), but allow specification of the interstage fairings to be whatever size is needed for that stack size. So, while the mount itself might be slightly smaller than the tanks, the engines would all be at proper scale. This seems like it -might- be the most workable solution; the aesthetics would be slightly off as the mounts/fuel lines would not match the tanks, but it should work.

2.) A second alternative that I'm heavily considering at this point is fully-procedural mounts rather than hand-built models. The problem that is ran into here is how to do this while still making them look good? Not sure that I could pull it off (without years of coding on it). A big problem with this is how to handle the special-case oversized mounts.

3.) A third alternative that I'm considering is somehow splitting up the mount model into multiple independently scalable parts. So you could maintain the motors at a standard rescale factor (1.5625x) but scale the stack-mounting plates by a different amount to make them cleanly line up with the stack size they are mounted on. This would also -greatly- cut down on the number of specific models that I need to create.

And just to throw a wrench in the gears there is the case of the special 'oversized' engine mounts and how to cleanly rescale those to be usable with random rescaling (can't see how it would be possible).

Perhaps I am getting a bit too ambitious with my plans and might need to scale this project back a bit. Even as it is (if I ignore the RSS rescale problems) the full set of parts will be 20 engine models, 51+ mounts, and 51+ mount shrouds. Of course this was with attempting to do very-detailed skeletal type mounts where all the fuel-lines match up and are routed properly. Might just rethink the mounting layout along the lines of #3 where there is a single tank-cap model that can be freely rescaled, and a single skeletal adapter per cluster layout that is rescaled appropriately for the motor mount size. Still has problems related to external shrouds (specifically the oversized/special ones).

Strangely the plugin-end of things I think will be the easier bit to figure out this time. Setup thrust transforms per engine type: check, simple enough to do. Alter engine module stats for selected engine (thrust/isp/mass/heat): very doable. Position engine models where needed based on cluster layout: no problem. Re-setup engine gimbal properly for engine type: simple. Re-setup engine FX properly for engine type: Not yet figured out, but preliminary investigation points out that it is doable.

Rescaling of models for use in RSS: No clue where to start.

Hmm... still quite a bit of figuring out to do on this stuff.

Will look at doing some mock-ups of engine mount stuff a bit later to see if I can figure out an easily freely-rescalable solution.

don't worry at making your scaling compatible with RO, keep it at how you have done, stock doesn't scale to most rockets out there, and those who stick at 64% doesn't always get stock scaling, if you check bobcat's stuff for example, they are 64% scale and few things there match stock, another example is the Space Shuttle, the ET isn't 5m, it is ~5.4m in diameter

btw, I like option 3 myself as it would allow easy stock and RO scaling

oh, here's an extra I saw over at Chaka's thread:

I like the booster painting, they look more like an airline or executive jet rather than a government agency

[Shadowmage]

Have been doing a ton of thinking on logistics of the engine plugin module, and the more I think on it the more I see that it might not be a good idea in the long run. While I'm pretty sure I could get it all implemented to work fine with stock, trying to make it play nicely with nearly anything else will likely prove highly problematic. Scaling is just the start of the problems. Most of the patch-based engine stuff would simply fail, as I would be constantly overwriting the engine stats and/or completely rebuilding the module. Adding anything like engine ignitors would simply be not possible (that I think of, without explicit built-in support). The sheer number of different mount/adapter models that I would need to create to do it properly is simply staggering, and possibly more than I could reasonably accomplish without burnout.

However, as I have several engine models, lots of ideas, and several hundred mb of research data, I do intend on continuing development on the engines - both finishing those I have started, and adding a few more variants. I also still intend on making pre-built engine clusters from those, as that is the entire reason I was looking to make engines in the first place (part-count reduction through pre-built engine clusters).

I'm still investigating one more configurable plugin-based option geared more towards one part per engine type, but it is looking like it would still run into some of the same issues as expressed above. Mostly - scaling would still be a large problem, and playing nicely with other mods would still be difficult.

My last resort, which I will do if I can't get other options to work (which is seeming very likely), is to simply follow the standard setup. Create one part per engine per cluster setup, but with a much reduced selection of cluster setups for most engines. These would mostly be the iconic / historic setups, and would be different on a per engine basis. All should be available in a single-engine mount as well for general purpose use.

Mounts will not be stack-size specific, but instead be engine size specific, which will allow for much greater range of scaling. They would all come with procedural engine fairing module with configurable top and bottom radius, and possibly a second procedural fairing module to set up the stack-size adapter plate. Hopefully using that simple layout and module combination should still allow for patching, rescaling, and generally playing nice with others. Moving to a single-part-per cluster setup also re-presents the opportunity for optional custom shroud setups using a simple mesh-switch plugin. It also allows much greater room for customization of the mounts and their layout/spacing on a per-engine setup.

I'm already designing all engine models to use a common (rescaled) mounting system, so this greatly simplifies the creation of the initial set of parts; I merely need to design and compile a single mount model and a single engine model, and the rest is taken care of through MODEL nodes in the config. In the beginning many of these will be little more than pre-welded engine clusters (though, ones that actually function as intended) -- initial releases will likely have no shroud options and all engines would share the same rescaled mounting bracket model. Many of these can/will be upgraded over time to include customized mounts and shroud options.

One of the more interesting/mundane/overkill details that I haven't mentioned yet regarding the engines is that I am designing them all with realistic gimbal mechanics, as far as possible. The gimbal position on each motor is where it would be on the real article, is/will be modeled after real gimbal and mechanics, and each will have (seemingly) functional mechanics driving the gimbal movement (really just some transform constraints...). Each motor will have different parts that move and flex as the engine is vectored, at least as close to the real-world mechanics as I could replicate (some of the fuel lines IRL have many articulation points; these will likely only have 1).

Anyhow, still tons to think on, and many engine models to finish.

[riocrokite]

I see that things going in the right direction so I'll just stuff more pics of prospective engines, it seems that there's now a mini tech race between SLS-BF4/SpaceX/Russians to build new launchers using methalox engines.

RD-0164 vs RD-180MC (methane-cryogenic) chart:

rows:

- thrust (in tf so x10 for kN) SL

- thrust vac

- isp SL

- isp VAC

- throttling ability (%)

- length

- diameter

- mass

RD0164 = Fuel Rich Staged Combustion

RD-180 = Oxidizer Rich Staged Combustion

* = Maximum dimensions in the plane of the cut nozzles

source: http://forum.nasaspaceflight.com/index.php?topic=32161.40

I did a brainstorm for possible future stuff to account for if you're developing your custom engine code, if not you might as well disregard it:

=====

I've read some stuff about spacex engines and 'overthrottling' ability'. So for example future spaceX raptor and merlin 1D could be throttled to about 133% to reduce gravity losses and then reduced to 100% to reduce wear and tear.

Maybe it could be a good idea to introduce this ability to some of the engines, so they could burn like 20-30s with a thrust above 100%.

This could potentially open up interesting field for other mods, so for example the more experience you have with one engine (let's say an older type) the higher you can overthrottle it at start. This simulates advances and small tweaks in engines that you do when you use them a lot. So the older designs (i.e. RP-1/LOX) could still compete with new technologies (methalox) on some fields provided you used them extensively in the past.

Also from design perspective having ability to squeeze more thrust from an engine could result in new interesting designs (less engines-more droppable tanks;)), something like in the picture below. You can notice in the design on the left how your modular tanks could be used perfectly with their custom cap shapes

source: http://www.3dnews.ru/920173

========

Other thing worth considering would be to expose your engine stacks to reliability issues (exposing to potentially another mod). So for example one engine failure in a stack would decrease stack thrust by that engine if the engine in question was in the center. If it was in the 'outer ring' or in symmetry with other, the 2 would shut down automatically to keep the center of thrust. So player would be enticed to go with 4x 1.25 engines that he flew extensively in the past and gained like 95% reliability per engine on crucial flights than using single new 2.5m engine that has 80% reliability (so it's good for less critical missions until player through launches gets its reliability up to reasonable level:P)

========

separate modes for landing for stacks (so if you have 4 you can use just 2 for landing); similar to what spaceY mod does with stacked engines.

========

Edited October 23, 2015 by riocrokite

[Shadowmage]

I see that things going in the right direction so I'll just stuff more pics of prospective engines, it seems that there's now a mini tech race between SLS-BF4/SpaceX/Russians to build new launchers using methalox engines.

RD-0164 vs RD-180MC (methane-cryogenic) chart:

http://forum.nasaspaceflight.com/index.php?action=dlattach;topic=32161.0;attach=1059438;image

rows:

- thrust (in tf so x10 for kN) SL

- thrust vac

- isp SL

- isp VAC

- throttling ability (%)

- length

- diameter

- mass

RD0164 = Fuel Rich Staged Combustion

RD-180 = Oxidizer Rich Staged Combustion

* = Maximum dimensions in the plane of the cut nozzles

source: http://forum.nasaspaceflight.com/index.php?topic=32161.40

I did a brainstorm for possible future stuff to account for if you're developing your custom engine code, if not you might as well disregard it:

=====

I've read some stuff about spacex engines and 'overthrottling' ability'. So for example future spaceX raptor and merlin 1D could be throttled to about 133% to reduce gravity losses and then reduced to 100% to reduce wear and tear.

Maybe it could be a good idea to introduce this ability to some of the engines, so they could burn like 20-30s with a thrust above 100%.

This could potentially open up interesting field for other mods, so for example the more experience you have with one engine (let's say an older type) the higher you can overthrottle it at start. This simulates advances and small tweaks in engines that you do when you use them a lot. So the older designs (i.e. RP-1/LOX) could still compete with new technologies (methalox) on some fields provided you used them extensively in the past.

Also from design perspective having ability to squeeze more thrust from an engine could result in new interesting designs (less engines-more droppable tanks;)), something like in the picture below. You can notice in the design on the left how your modular tanks could be used perfectly with their custom cap shapes

http://www.3dnews.ru/assets/external/illustrations/2015/09/14/920173/Ill2-16.jpg

source: http://www.3dnews.ru/920173

========

Other thing worth considering would be to expose your engine stacks to reliability issues (exposing to potentially another mod). So for example one engine failure in a stack would decrease stack thrust by that engine if the engine in question was in the center. If it was in the 'outer ring' or in symmetry with other, the 2 would shut down automatically to keep the center of thrust. So player would be enticed to go with 4x 1.25 engines that he flew extensively in the past and gained like 95% reliability per engine on crucial flights than using single new 2.5m engine that has 80% reliability (so it's good for less critical missions until player through launches gets its reliability up to reasonable level:P)

========

separate modes for landing for stacks (so if you have 4 you can use just 2 for landing); similar to what spaceY mod does with stacked engines.

========

I love the ideas for time/use based 'upgrades'. However that seems like it belongs as its own generic module to be patched/applied to all engines, rather than something specific to my engines. Love the idea though, and will likely add something similar onto the features /todo list (if I don't find another mod that has done it first). Using this method seems to make the most sense for a career based game, allowing you to squeeze a little bit extra out of the lower-tech engines and possibly allowing them to see later-game use (similar to how we are -still- using engine designs from the 60's...RL-10 anyone?).

Implementing some sort of 'engine out' or failure mechanics again seems like it belongs in another separate mod/module rather than being tied to my engines. I appreciate the mechanics and opportunities (rather the 'oh @#%^' moments) that this feature would add, and it might make the LAS actually useful, but I'm not sure it is something that I personally want to implement. I believe there already are a few mods out there that simulate random part failures and reliability stats (never used it, but DangIt! comes to mind).

However, implementing some sort of engine cluster control where you can shut down specific engines might be on the board. This capability could be used by another plugin/module to simulate engine failure as well. Could certainly be interesting to have some asymmetric failures as well for those clusters where balanced control is not available (e.g. 3).

And as I'm back on working on engines (spent 4-5 days this week thinking/trying to figure out the mounting system...*sigh*), here is the most recent progress:

Updated RS-25 (SSME) with basic plumbing (WIP, still more stuff to add...)

And the first of the 'custom' engines - the RS-69 (based on RS-68, with many changes to make it more compact and increase performance slightly).

This engine also has a vacuum-customized variant (not shown) with an extendible nozzle that increases both thrust and ISP, at the cost of added mass and height (when extended). Intended to be used as a -heavy- upper stage engine, as a possible replacement for clusters of RL-10's.

Edited October 23, 2015 by Shadowmage

[blowfish]

as a possible replacement for clusters of RL-10's.

I find this mildly amusing ... IRL a vacuum variant of the RS-68 would probably have about 4000 kN of thrust ... so a replacement for a cluster of 35 RL10s? Maybe more a replacement for a cluster of 3-4 J2-X?

[Shadowmage]

I find this mildly amusing ... IRL a vacuum variant of the RS-68 would probably have about 4000 kN of thrust ... so a replacement for a cluster of 35 RL10s? Maybe more a replacement for a cluster of 3-4 J2-X?

LoL, yes, replacement for J2s / J2X would probably be more accurate. I keep forgetting how puny output on the RL-10 is compared to how large it is.

Mostly I was going for an RS-68 variant that could be easily clustered (the regular RS-68 has problems due to the exhaust/thrust vector nozzles sticking way out the sides), and also saw an opportunity for another extendable nozzle engine. Currently it is just a concept and rough model; it may or may not make it much further than that - will depend on if there is actually a need for it or not.

[JoseEduardo]

Shadowmage, two ideas I just got:

1 - instead of a fairing generated from the engine mount, what about a procedurally made interstage that looks like KW's but can be resized/extended/retracted at will? the borders, with more details, could be kept the same mesh, while the inner part could be stretched, having a texture, bump and/or mesh that doesn't look off when procedurally manipulated, something like Saturn/SLS/Jupiter interstages

simply add two decoupling nodes for the staging action (I'm pretty sure FASA and KW does that) and allow it to be adapted to match the engines and the mount

one piece, two rabbits gone

If you add optional ullage motors (useful in stock aswell) then 3 rabbits would be gone with one piece (in this config the top node could be disabled for staging, and instead separated through manual decoupling through right clicking or action groups)

2 - an(other) idea for future mod expansion - alternative SM like the early Orion with round solar panels and the one that resembles Apollo (there was one depicted in one of the Jupiter/DIRECT pics some pages back)

Edited October 23, 2015 by JoseEduardo

[Sudragon]

A few more weeks/revisions and this will probably replace KW Rocketry for value per footprint.

[Shadowmage]

Shadowmage, two ideas I just got:

1 - instead of a fairing generated from the engine mount, what about a procedurally made interstage that looks like KW's but can be resized/extended/retracted at will? the borders, with more details, could be kept the same mesh, while the inner part could be stretched, having a texture, bump and/or mesh that doesn't look off when procedurally manipulated, something like Saturn/SLS/Jupiter interstages

simply add two decoupling nodes for the staging action (I'm pretty sure FASA and KW does that) and allow it to be adapted to match the engines and the mount

one piece, two rabbits gone

If you add optional ullage motors (useful in stock aswell) then 3 rabbits would be gone with one piece (in this config the top node could be disabled for staging, and instead separated through manual decoupling through right clicking or action groups)

2 - an(other) idea for future mod expansion - alternative SM like the early Orion with round solar panels and the one that resembles Apollo (there was one depicted in one of the Jupiter/DIRECT pics some pages back)

Having an interstage fairing as a separate part works against my 'low-part-count' goals. That said, I already have the procedural interstage payload adapter that could easily be repurposed to create a procedural interstage fairing (I believe the changes could all be done config side, as the support already exists in the plugin... been awhile since I worked on it though).

Ullage motors -- I've been trying to think of a good way to work these in with some of the other parts, but I haven't run across any good opportunities yet. Also been trying to find the best way to work vernier engines in, but again have not found a good place yet.

Alternative SMs -- I've been contemplating doing a few other service modules; though they would be geared more for general use than towards any specific capsule. Mostly they would be useful as they would have solar / rcs / batteries / engines / sas / docking port? all in a single part. Ideally these would be available in most stack sizes, with perhaps a few different variants per size (e.g. light/med/heavy). Some of this functionality will also be worked into the customizable upper-stages when I get to them.

In general news, should likely have an updated test release here in a few hours. Won't have anything too special in it... couple bugfixes, and some additional fuel tank sizes. Should also have some prototype engine clusters for feature testing.

- - - Updated - - -

Well, that didn't take as long as I thought (to finish/clean things up)....so...

Updated test release is available:

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

Please note that the engines/clusters that have been included for this release are not final, and are only for preliminary testing and concept development purposes.

[Rho-Mu 34]

Wait a sec, are you pulling the plug on the Series C? Why?

[davidy12]

An interstage I don't think is necessary, just use procedural fairings.

Though I would like a Stockalike apollo CM or SM. (I know about the stock mk2 capsule is used often but it has two up top and one on bottom I'd like three in line. Don't know what I'm talking about look at FASA's CM seating).

- - - Updated - - -

PS: In my opinion, I didn't really like Series C. I like realism or near future parts, but not like future colony landers.

[riocrokite]

Updated test release is available:

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

Please note that the engines/clusters that have been included for this release are not final, and are only for preliminary testing and concept development purposes.

cool stuff,

just a couple of observations:

- 6.25m tank hasn't got matched end caps (5m)

- one of the bottom adapter for all tanks (I think) doesn't have attachment point (5-2.5m / 2.5m-1.25m)

- no textures on new engines (probably intentional); nevertheless they look great

- holy moly 5 x F1 stack! we might actually need 7.5m tank version to fit them underneath

Edited October 25, 2015 by riocrokite

[JoseEduardo]

but the Interstage could be used instead of the decoupler, so it wouldn't add to the part count, it could be a tweakable interstage with decoupling nodes in both ends, thus not needing to use the decoupler

here's an example with FASA:

btw, taking FASA as an example the stripes in it would allow for rescaling with no or minimal texture deformation

[davidy12]

I think you made the F-1s too over powered.

- - - Updated - - -

I still have a 10 TWR when on max 6.5 tank length.

PS: Why not cluster 5 RS-68s for Ares?

- - - Updated - - -

Also, why 6.25 and not 7.5m diameter tanks?

[JoseEduardo]

I think you made the F-1s too over powered.

- - - Updated - - -

I still have a 10 TWR when on max 6.5 tank length.

PS: Why not cluster 5 RS-68s for Ares?

- - - Updated - - -

Also, why 6.25 and not 7.5m diameter tanks?

Please note that the engines/clusters that have been included for this release are not final, and are only for preliminary testing and concept development purposes.

these are unfinished engines, they are for testing purposes....

[Shadowmage]

Wait a sec, are you pulling the plug on the Series C? Why?

There are some things that I do not like about it at the base design level, and a few parts that really could have been done better (like the CM). I will be fielding a new line of parts that will fulfill the same/similar functions (horizontal lander, orbital freighter), with better initial design allowing for application of the new plugins/modules - such as variable-length cargo bays and fuel sections.

I could certainly leave them in the releases for the time being, but they will likely see no further updates to the parts in their current form.

An interstage I don't think is necessary, just use procedural fairings.

Though I would like a Stockalike apollo CM or SM. (I know about the stock mk2 capsule is used often but it has two up top and one on bottom I'd like three in line. Don't know what I'm talking about look at FASA's CM seating).

- - - Updated - - -

PS: In my opinion, I didn't really like Series C. I like realism or near future parts, but not like future colony landers.

If I do any more capsules in the near future would likely be the Soyuz line, or space-x capsules. Though, if its just the IVA seating you don't like on the stock capsule, it is certainly possible to patch other IVAs in place of the stock ones (yes, even entirely different models.

One of the first sets of parts I did was an Apollo CM and SM, though they have been retired/archived for awhile now. No IVAs either, was long before I had learned how to make them (it just used the stock 2.5m capsule iva).

cool stuff,

just a couple of observations:

- 6.25m tank hasn't got matched end caps (5m)

- one of the bottom adapter for all tanks (I think) doesn't have attachment point (5-2.5m / 2.5m-1.25m)

- no textures on new engines (probably intentional); nevertheless they look great

- holy moly 5 x F1 stack! we might actually need 7.5m tank version to fit them underneath

Cap scaling - noted; apparently I forgot to change the scale while I was updating volumes and stuff. Will be quite easy to fix, def. available with the next release.

Missing attach node - hmm... will look into that one as well, likely missing the config definition or has it otherwise misplaced. Have opened an issue and will get this with the next update

Lack of textures - yep, was just testing the fuel line and gimbal stuff, and the dynamic engine positioning (those engines are all positioned through plugin, and can be changed through patching).

F1 cluster - thats what the 6.25m tanks are for (10m @ 64%= 6.4m... I just rounded them down a bit). The thrust on all of the engines is also absurd (its their real world thrust), as I just threw some numbers in to test the patching (the F1 clusters were created entirely through MM patch)

I'm adding mounting type selection to the engine clusters, so you'll be able to pick between various mounts for those where models are available. Got most of that worked through today. Still going to investigate if I can get dynamic switching of cluster types through the plugin as well; but that will likely run into problems with other modules and patch-ability. Making progress now though, and should be able to move on to finishing up engine models / texturing stuff here before too long.

but the Interstage could be used instead of the decoupler, so it wouldn't add to the part count, it could be a tweakable interstage with decoupling nodes in both ends, thus not needing to use the decoupler

here's an example with FASA:

http://i.imgur.com/XRYurCY.jpg

btw, taking FASA as an example the stripes in it would allow for rescaling with no or minimal texture deformation

Hmm.. perhaps something like that could be worked out, might even be able to use parts of the existing tank textures. Would be a bit of a strange part though, requiring right-click options to operate some of the staging stuff. Will probably look into tackling this when I am working on the radial SRB decouplers.

[riocrokite]

nice,

- F-1 stacks: KER in editor shows some weirdly high TWR ratios, however upon launch TWR is displayed correctly. I also like their isp tweaked for low atmosphere Maybe tweaking SL isp and thrust a bit downwards (-10%?) would bring it closer to reality and balance them against stock. And that gimbal movement is awesome.

==== potential another mod rant, not relevant for this thread ===

With those kind of engines and 5-6.25m tanks one can see, that switching from liquid fuel to lqdMethane can actually have sense (liquid fuel alone for the biggest 6.25m tank costs more than 100k:))

Interesting stuff about methane too:

Methane (CH₄) and RP-1 are roughly equivalent in realizable performance. As previously mentioned by other posters, CH₄ has slightly higher impulse – about 370 s in vacuum vs the 360 s – at the same chamber pressure of 7 MPa. But, this is counterbalanced by its lower bulk density of about 830 kg/m³ vs about 1030 kg/m³. Bulk Density is the density of the combined Fuel and Oxidizer load in their appropriate ratios. Even though Methane is "only" 430 kg/m³ it is burned with 3.5 parts oxygen compared to 2.1 parts for RP-1, hence a CH4 rocket will be carrying more oxygen and less fuel by weight. Oxygen is pretty dense at a little over 1140 kg/m³ which is denser in fact than RP-1 (about 810 kg/m³). If we assume that chamber pressures and engine cycle efficiency will be equal, RP-1 outperforms CH₄ simply because a 20% larger tank will impose weigh penalties that slightly outweigh the 3% increase in specific impulse. However, the RP-1 advantage is contingent upon operating at an equal chamber pressure which may not be the case. And, Methane (CH₄) has additional advantages that are applicable in specific scenarios.

The reasons CH₄ is a front runner for SpaceX's Raptor can probably be attributed to four factors:

1. Methane does not coke (polymerize) at the operating temperatures of a rocket engine – it's coking point is roughly twice as high. This makes it easier to make an engine reusable and re-usability is a key SpaceX objective.
   
2. Because Methane does not coke, it is also easier to implement a full-flow stage combustion (FFSC) cycle where all the fuel and oxidizer flow goes through the pre-burner. Compared to contemporary Russian partial flow stage combustion engines higher chamber pressures are attainable resulting in a total impulse advantage of about 30 seconds, or 9%. This eliminates the performance deficiency of CH₄ compared to RP-1.
   
3. If SpaceX intends to use the same fuel in all the stages, CH₄ can be considered a better upper stage fuel and a worse lift-off fuel, even without enabling higher working pressures. This is because upper stages are typically 1/8th to 1/10th the size of the 1st stage, and here impulse is more important than density. Using Methane with the aforementioned FFSC cycle means that SpaceX can potentially get equivalent 1st stage performance and better upper stage performance.
   
4. Even though it is, IMHO, somewhat dubious that early Mars mission will use in-situ fuel production. If that ever becomes an applicable practice, Methane can be produced from water and CO₂ while RP-1 cannot.
   

Other than that, there is the non-factor that somewhat favor Methane, such as regular grade Natural Gas being good enough and not having to highly refine the fuel from regular kerosene to RP-1 to achieve low coking characteristics and consistent densities. I say it is a non-factor, because fuel cost is such a negligible part of launch costs that it really doesn't matter if fuel cost a few times more or less. Fuel is typically only about 0.3% of the cost of flying a rocket to orbit, so fuel cost really doesn't matter – Not even when you compare highly expensive propellant combos like Hydrazine/Tetroxide to the relatively cheap Kerosene/Oxygen.

source: http://space.stackexchange.com/questions/3161/why-is-spacex-considering-methane-as-fuel-for-their-next-engine-the-raptor

So yah all in all advanced methalox engines could be 6-7% more efficient than LFO engines (taking heavier tanks into account). They also seem to have a nice potential for thrust boost (133% for spacex raptor).

I'll post in Community Resource Pack thread since LqdMethane cost appears to be way too high compared to stock Liquid Fuel.

=======================================================

- RS-68, gimbal range is astounding, this certainly helps keeping the course/maneouvering heavy ships even with a small amount of thrust. I love it especially that you can limit it manually (if needed)

[JoseEduardo]

Hmm.. perhaps something like that could be worked out, might even be able to use parts of the existing tank textures. Would be a bit of a strange part though, requiring right-click options to operate some of the staging stuff. Will probably look into tackling this when I am working on the radial SRB decouplers.

Actually, both the KW and FASA interstage fairings decouple on both nodes through staging

If you take the suggestion of adding a ullage motors variant they could also be staging controlled, but then the top node could be disabled from staging, needing to be right clicked, if it remained as a stageable action bad things could happen, turning the ullage motors in retro motors to slow down the lower stage could do the opposite, with the bottom node remaining attached and decoupling just the top one, so technically it would be 4 parts in one (decoupler, interstage fairing, ullage and retro)

[Rho-Mu 34]

There are some things that I do not like about it at the base design level, and a few parts that really could have been done better (like the CM). I will be fielding a new line of parts that will fulfill the same/similar functions (horizontal lander, orbital freighter), with better initial design allowing for application of the new plugins/modules - such as variable-length cargo bays and fuel sections.

Glad to hear this. Series C overall concept has a lot potential, especially in conjunction with reduced partcount and smaller memory footprint.

[Shadowmage]

So... have hit a decision point in the engine cluster development.

I have already decided that each editor-list-part will be a specific engine type. This solves so many problems, it is almost a no-brainer. It removes problems of manipulating fuel/resources types for each engine and allows for much easier patching / interaction through other mods.

What I am not entirely decided upon is if each part should allow for multiple clusters through mesh switching/etc. It is a bit of a tough decision, mostly because I'm unsure on some of the long-term fallout from it. So, I'm going to throw out the PROS/CONS that I'm aware of currently and see if you guys have any other pro/con points, or any other opinions/feedback on which would be more desirable.

The features listed below should be present regardless of if cluster-switching-through plugin is used or not

Current Feature List:

1.) Use mesh-swapping to allow for different mount options for each cluster layout. These can be anything from a generic per-engine mount, to a custom mount created for the entire cluster.

2.) Engine and mount scaling are independent. So you can scale up/down engines to whatever your game scale is, while scaling the mounts to match whatever stack-sizes are in use.

3.) Engine layouts may be changed on a per-cluster or per-engine or per-part setup. Want two different layouts for 5-engine clusters? Sure. Want a different spacing for the same layout? No problem.

4.) Engine layouts defined in external config file, can be easily added to by users or patches. They are a simple mathmatical definition of raw position, which is then adjusted on a per engine/part basis by their specific config settings.

5.) Where applicable (and doable) engines will have realistic functioning gimbals and fuel baffles. Not really a huge deal, but the aesthetics of watching everything move is kind of neat.

6.) Engine clusters are built entirely through plugin; no need to figure out exact positions/etc for the models - the plugin takes care of all of that for you; merely give it an engines specifications (height/etc) and a layout to use and it will position/calculate everything else appropriately.

7.) Ability to cluster stock engines, and potentially any engine from any mod, including removal of stock ModuleJettison fairing models/transforms (and/or any other transform you need to remove from the original model).

Cluster selection through plugin (bigger pros/cons in bold):

PRO

1.) Far fewer parts in the editor parts list -- this is really the biggest reason. Using a custom editor-group might alleviate this/make it a non-issue (if I can figure out how to implement those; though KIS/KAS/MKS could likely give me the implementation details)

2.) Fewer files to patch; instead of one-patch-per-cluster, it would be one-patch-per-engine-type

3.) Would allow for most/all cluster combinations to be available for all engines without overloading the editor parts list.

CON

1.) Requires plugin-based manipulation of ModuleEngines(fx), ModuleGimbal and ModuleSurfaceFX to alter the number and location of thrust transforms. Very doable for stock modules.

2.) Will run into compatibility issues if anyone ever changed the engine, gimbal, or surfacefx module that was in use. Basically, these parts would be limited to stock PartModules (or derived classes), as those are the only ones that I can do run-time manipulation on (without adding a full mod dependency).

3.) Configs would be a bit more complex to setup.

4.) Stock drag considerations -- drag cubes complicate this a bit more; will need to update drag cubes whenever layout changes. Could have issues with FAR/etc with regards to drag computation.

5.) Interaction through other modules that cache ThrustTransforms will be error-prone, as I will be constantly changing/removing/adding thrust transforms. Unless the module is one of the stock ones listed above (gimbal, engines, surfaceFX), there is no clean way to get them to play nicely.

6.) Patches -- this could be a big one; patches might be much more difficult to set up.

7.) The engine-cluster-module will be manually setting the mass of the part at runtime. This will conflict with any other mods that do the same/similar. The only proper way to change the mass would be to patch the engine definition in the config file.

Hmm... if I could get a few volunteers to help me do some extended compatibility testing I will consider writing up the engine-cluster-switching code this week (likely tonight/tomorrow) and put together a release pack with some engine clusters for more extensive compatibility testing. The main things I'm curious about will be interaction with other PartModules.

Another good question -- would making a custom category for SSTU engines actually alleviate the editor-part-list-bloat concerns and allow me to skip the dynamic plugin stuff? As really that is the only functional difference it will make; removing editor-part-count. Doing a custom editor-category would be -by orders of magnitude- easier to implement than the engine cluster switching. Edit -- on this note, the single engines could still be available in the stock 'Engines' category, while moving just the pre-built clusters down to a custom 'Engine Clusters' category.

Thoughts, ideas, concerns?

Edited October 26, 2015 by Shadowmage

[blowfish]

1.) Requires plugin-based manipulation of ModuleEngines(fx), ModuleGimbal and ModuleSurfaceFX to alter the number and location of thrust transforms. Very doable for stock modules.

2.) Will run into compatibility issues if anyone ever changed the engine, gimbal, or surfacefx module that was in use. Basically, these parts would be limited to stock PartModules (or derived classes), as those are the only ones that I can do run-time manipulation on (without adding a full mod dependency).

I know for a fact that ModuleEngines(FX) and ModuleGimbal will correctly detect multiple transforms with the same name. I'm not sure if they handle transforms that are disabled or the child of a disabled transform properly, but if they do, you might not have to do much work here.

As for modded modules, if they intend to replicate or extend stock behavior but don't derive from the stock modules there's not much you can do.

4.) Stock drag considerations -- drag cubes complicate this a bit more; will need to update drag cubes whenever layout changes. Could have issues with FAR/etc with regards to drag computation.

There is a message you have to send to FAR to revoxelize. But if you do that everything should work fine.

6.) Patches -- this could be a big one; patches might be much more difficult to set up.

Set things up through named nodes if possible. Everything is easy to do through MM with named nodes. Avoid firespitter-style comma or semicolon separated lists, those are annoying to work with.

7.) The engine-cluster-module will be manually setting the mass of the part at runtime. This will conflict with any other mods that do the same/similar. The only proper way to change the mass would be to patch the engine definition in the config file.

I have heard from reliable sourcesâ„¢ that there's a chance this will be fixed in 1.1, and that IPartMassModifier will work properly. If that doesn't end up happening I've written a workaround that I'll try and get other modders to use (it only works if everyone uses it).

Another good question -- would making a custom category for SSTU engines actually alleviate the editor-part-list-bloat concerns and allow me to skip the dynamic plugin stuff? As really that is the only functional difference it will make; removing editor-part-count. Doing a custom editor-category would be -by orders of magnitude- easier to implement than the engine cluster switching. Edit -- on this note, the single engines could still be available in the stock 'Engines' category, while moving just the pre-built clusters down to a custom 'Engine Clusters' category.

I'd say just ask the Filter Extensions people for a custom category. I think SSTU has enough parts at this point to justify it

[Shadowmage]

I know for a fact that ModuleEngines(FX) and ModuleGimbal will correctly detect multiple transforms with the same name. I'm not sure if they handle transforms that are disabled or the child of a disabled transform properly, but if they do, you might not have to do much work here.

As for modded modules, if they intend to replicate or extend stock behavior but don't derive from the stock modules there's not much you can do.

Yes, both the stock engine module(s) and gimbal module properly detect multiple transforms. Should be no problem with those. The surfaceFX only supports a single transform (and I haven't checked on if I can do runtime manipulation of that or not), but I will already be looking into manually adding a transform -just- for its use (so it is centered on the part at least). So the surfaceFX one might not even need to be touched.

Any problems that would occur will stem from me adding and removing transforms from the list randomly (I would not be disabling/enabling, but rather adding new objects and removing old to-be-destroyed objects). From preliminary investigation there should be no problem with the stock modules regarding this. The problem would come from any mod-added module that -locally cached- a copy of the engines transform list (as opposed to just referencing it directly); there is no logical reason for them to do this, but I have seen enough 'non logical' code in my life to know that someone somewhere is/will do it. I guess at that point it really wouldn't be my problem to solve (nor could I). Mods that might run into this problem would include MJ/KER and RCSBuildAid (have not looked at their source to see how/where they poll for thrust transforms). Likely other mods as well that I do not use / am unfamilliar with (Throttle Controlled Avionics? a brief look through the code did not reveal anything too worrisome).

This was mostly why I was asking for volunteers -- I simply do not have time to test all of the potential mod interaction conflicts that could arise.

There is a message you have to send to FAR to revoxelize. But if you do that everything should work fine.

Good to know; will look into adding that into the rest of my dynamic model/mesh-swapping plugins as well. Haven't heard any reports of malfunctions yet, but probably no harm on implementing that anyway (as long as I can / does not require dependencies).

Set things up through named nodes if possible. Everything is easy to do through MM with named nodes. Avoid firespitter-style comma or semicolon separated lists, those are annoying to work with.

Yep... is why I have gone with the more-verbose node layout configs so far. They are also easier to read. Take a bit longer to write up in the first place, and results in much larger files in general, but I've found it to be a good tradeoff.

I have heard from reliable sourcesâ„¢ that there's a chance this will be fixed in 1.1, and that IPartMassModifier will work properly. If that doesn't end up happening I've written a workaround that I'll try and get other modders to use (it only works if everyone uses it).

That would be excellent (fixing the stock interface). Currently it is... unreliable at best. I have been unable to figure out how to use it to properly set the mass of the part in the editor -and- in flight, and have resulted to manually setting the part.mass field instead. From looking at others' code, I'm not the only one who has come to that conclusion/solution.

I'd say just ask the Filter Extensions people for a custom category. I think SSTU has enough parts at this point to justify it

[Shadowmage]

Hmm.. and lols...

-- had to take a break from engine geometry stuff for a minute. Decided I would do some investigation. Looks like things will work out for the radial-decoupler-with-sepratrons. Now I just need to write the plugin to rescale the thing and move the mounts/thrust transforms around. -Might- be this weeks 'new feature' (if I get the plugin written), though it may or may not have a finished model/texture.