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

[JoseEduardo]

do you plan on making the nosecone and bottom separatrons work with the decoupler?

that looks good already though, no more tense seconds with SRBs very close to the rocket threatening to tear it apart

[Shadowmage]

do you plan on making the nosecone and bottom separatrons work with the decoupler?

that looks good already though, no more tense seconds with SRBs very close to the rocket threatening to tear it apart

It will all be a single piece with UI controls to adjust the scale and positioning of the thrust transforms (which will be indictated through some visual mesh/geometry). It will be up to the user to position the thrust transforms where they want them.

Had to spend most of last night migrating to VisualStudio, as apparently MonoDevelop had some hard-coded system assembly references that was preventing proper compilation of the plugin when it contained the code for adding editor-part groups. Probably a good thing in the long run, as VS is much more powerful, I'm already familiar with it, and I have a full Professional copy from when I was in school (not that it really matters for KSP development).

I guess I'll just throw this out there --

What would you guys rather have done for this weeks update -

Radial Booster Decouplers?

-or-

Lots more work towards engine clusters?

Either one will require quite a bit of coding, modeling, and texturing. I could likely get the radial decouplers finished and working by the weekend (perhaps aside from final texturing). For the engines, if I spend all week working on them I can likely get something 'usable' by the weekend, though models/textures would be nowhere near finished (plugin might be close at that point).

And, as to the radial decouplers specifically -- my current feature-set is:

[h=3]Features:[/h]

• Has scalable and movable geometry to form a surround ring for the booster
  
• Can additionally use mesh-switching to change the mounting type between ring and basic attach-point
  
• Has included SRB-based jettison motors.
  
• Can move thrust transforms for the jettison motors along with the visible model; hopefully to allow positioning into realistic positions for the jettison motors.
  
• Can adjust amount of jettison fuel / force in the VAB (Need to find a good way to do this, currently it is just the stock force, thrust, and fuel sliders).
  
• Everything triggered as one action through staging - no special functions to learn. Use it just like any other radial decoupler.
  
• Works properly with MJ/KER dV calc, and for MJ auto-staging
  

[h=3]Requirements:[/h]

• Custom plugin to manipulate the model and thrust transforms. Could be a very short/simple module, as it is basically just moving around/repositioning/rescaling some already existent transforms/game-objects.
  
• If mesh-switching capability is added, it increases complexity/dev time quite a bit, but still fairly simple all-in-all.
  
• Need to investigate why stock was removing thrust transforms from the model when it was activated. Might need to manually re-parent thrust transforms to visible mesh objects (as if they are unparented, they get deleted)
  
• Needs custom model(s) created (geo/ao/uv/tex)
  

[JoseEduardo]

I vote SRB separation because that seems the closest to finishing, leaving the remaining time for the engines

[riocrokite]

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)

I've recently tried to make an icon for my own mods, however due to noobness in coding I failed (even though I've just copy-pasted code from other mods), here's relevant code (I think) taken from 4 different mods, I think USI mods take icon from research and development node icons, while KIS and IR somehow load their own icon:

http://pastebin.com/ZKW5skBz

Less parts in editor is always better, however I think that engines tab isn't overloaded (compared to utitlities or construction tab unless someone use big number of mods). On the other side with growing number of different cluster setups it might get crowded, so yah;) (still non issue for me however custom cluster mod would be more elegant).

----

I would add one more pro to the list: simplified colliders - doesn't seem like much, however for example with heavy clustering of small engines for big tanks (like 9 or 27 per column) one could think of a significant physics cost.

Quick example; let's say I have spacex heavy setup - 27 small engines, 9 per column. With separate engines you have 27 mesh colliders which are expensive. If you use simplified colliders for stacks of 3+ (for example capsule or even sphere colliders - 2 for the engine - it will be enough so the stack holds rocket stable on the ground) you might get away with greatly improved performance for multiple engines.

Sphere colliders in unity are like 2-4 times faster than box/capsule colliders which in turn are much faster than mesh colliders. I wouldn't worry too much about aerodynamics (usually are at the bottom so don't create any drag) and then sphere colliders should behave ok even if aerobraking facing the planet.

This would even get better for even bigger stacks like below;)

The downside to this implementation is that 1 or 2 engines are unstable and rocket couldn't stand on them if they use sphere/capsule colliders. What is nice about those colliders is that they 'should' work nicely with aerodynamics since there are no hard edges or likes. However I don't know this topic well so this might not be the case.

And of course this might be complicated to implement from the plugin point of view, so just an idea.

---

Another thing (to complicate your planning even more ). What about having an option for inline stacks (even without a fairing it could be useful; 1st use case, someone I think earlier on posted here a pic of mars direct rocket that had inline stacks of 3-5 engines I believe; 2nd use case - my mod in development -> I'm currently using 2 inline stacks of 3 1.25 engines: http://i.imgur.com/XEZGQT7.png).

Of course this is no biggie, since 98% of designs I guess will be using standard rounded stacks.

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.

I'll try to help as long as I carve out some spare time from trying to push forward my mods

edit: yah, booster separation thing should be easier and faster to finish so my vote for it too

Edited October 27, 2015 by riocrokite

[Shadowmage]

I've recently tried to make an icon for my own mods, however due to noobness in coding I failed (even though I've just copy-pasted code from other mods), here's relevant code (I think) taken from 4 different mods, I think USI mods take icon from research and development node icons, while KIS and IR somehow load their own icon:

http://pastebin.com/ZKW5skBz

Less parts in editor is always better, however I think that engines tab isn't overloaded (compared to utitlities or construction tab unless someone use big number of mods). On the other side with growing number of different cluster setups it might get crowded, so yah;) (still non issue for me however custom cluster mod would be more elegant).

Got the custom category implemented last night -- just had to change what IDE/compiler I was using. Don't yet have a custom icon for it (just using the R&D - Start node icon for the moment), but as I can use any icon in stock (or create my own), this shouldn't be too big of a concern. Yep, my code was pretty much boilerplate implemented from KIS/USI EditorGroup code. Seems like there is only one way to do it....so that is how it is being done.

I would add one more pro to the list: simplified colliders - doesn't seem like much, however for example with heavy clustering of small engines for big tanks (like 9 or 27 per column) you might have to do with significant physics savings.

Quick example; let's say I have spacex heavy setup - 27 small engines, 9 per column. With separate engines you have 27 mesh colliders which are expensive. If you use simplified colliders for stacks of 3+ (for example capsule or even sphere colliders - 2 for the engine - it will be enough so the stack holds rocket stable on the ground) you might get away with greatly improved performance for multiple engines.

Sphere colliders in unity are like 2-4 times faster than box/capsule colliders which in turn are much faster than mesh colliders. I wouldn't worry too much about aerodynamics (usually are at the bottom so don't create any drag) and then sphere colliders should behave ok even if aerobraking facing the planet.

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

This would even get better for even bigger stacks like below;)

http://www.astronautix.com/graphics/z/zmarsdir.jpg

The downside to this implementation is that 1 or 2 engines are unstable and rocket couldn't stand on them if they used sphere/capsule colliders. What is nice about those colliders is that they 'should' work nicely with aerodynamics since there are no hard edges or likes. However I don't know this topic well so this might not be the case.

And ff course this might be complicated to implement from the plugin point of view, so just an idea.

Colliders are part of the model; so they will use whatever collider the model is compiled with (I will -not- be doing runtime manipulation of those...just too much PITA). Currently they are using simple box colliders, two per engine (one for the top/unmovable section, another for the bell). Will likely stick with either box or simplified mesh colliders (8-12 sided cylinders/cones). I need flat bottoms so that engine clusters can stand on their own, and they have to be compiled with the model, so spheres and capsules are out.

Another thing (to complicate your planning even more ). What about having an option for inline stacks (even without a fairing it could be useful; 1st use case, someone I think earlier on posted here a pic of mars direct rocket that had inline stacks of 3-5 engines I believe; 2nd use case - my mod in development -> I'm currently using 2 inline stacks of 3 1.25 engines: http://i.imgur.com/XEZGQT7.png).

Of course this is no biggie, since 98% of designs I guess will be using standard rounded stacks.

I'll try to help as long as I carve out some spare time from trying to push forward my mods

edit: yah, booster separation thing should be easier and faster to finish so my vote for it too

Cluster layouts -- a big part of the plugin/module is that you can define your -own- layouts; and do so quite easily. So, while I might not ship 3-inline/4-inline/super-large clusters, there will be absolutely nothing stopping you from making them yourself -- it will be fully supported and doable (with my engines, stock engines, or even other mods' engines). You don't need to know modeling, texturing, or any of that... just need to setup the actual layout definition, and create the part config -- the rest is handled through the plugin.

Let me state that again (for others' benefit, because people keep asking for specific layouts) -- YOU CAN MAKE YOUR OWN ENGINE CLUSTER LAYOUTS, YOU DON'T NEED TO BOTHER ME FOR ANY SPECIFIC DESIGNS.

I will ship an initial selection of prebuilt layout definitions for most common/historic layouts, but will not have all engines available for every layout. If you wanted to enable a specific layout for an engine that was not currently enabled, see below. You can also use any existing model in KSP for the mounts; so if you have a favorite stack-adapter or other mods' pre-built engine mount that you want to pre-fill with engines, that can be done as well (pretty sure I saw a Saturn-V lower stage/F1 mount from some mod).

For example, here is the MM patch I used to create one of the F1 engine clusters:

+PART[SSTU_ShipCore_ENG-F1x1]:NEEDS[SSTU]
{
    @name = SSTU_ShipCore_ENG-F1x5
    @title = SSTU - SC-ENG-F1x5
    @description = SSTU - SC-ENG-F1x5
    @mass *= 5

    @MODULE[SSTUEngineCluster]
    {
        @layoutName = FiveCross        
        MOUNT
        {
            name = BigShroud
            scale = 1.25            
        }
    }
    @MODULE[ModuleEngines]
    {
        @maxThrust *= 5
    }
}

Exmple definition for the engine mounts (this was for a S-V styled lower-stage mount)

SSTU_ENGINEMOUNT
{
    name = BigShroud  //name referenced by the engine cluster module
    modelName = SSTU/Assets/SC-ENG-MOUNT-5   //model to load.  This can be literally anything
    verticalOffset = 0   //correction factor for the mount, to place its top at 0/origin.  The top node for the original part is a good value to use.
    singleModel = true  //if true, only a single mount model will be used;  if false, the mount model will be duplicated and rotated for each engine in the cluster
    height = 1.6   //the height of the engine.  Used to determine how far to offset engine model and attach nodes
    fairingTopOffset = 0    //how far from the top of the part should the fairing start at?  this would be for mounts that include some full-stack-sized geometry at the top (E.g. SC-B-ENG3 mount, or similar)
    fairingEnabled = false  //should the auto-node fairing be allowed for this mount?  defaults to 'true'
    defaultSize = 5m  //information only , not used by the plugin; this is so -you- know what scale to specify in the engine cluster definition
}

And the entirety of the layout definition for that engine cluster:

SSTU_ENGINELAYOUT
{
    name = FiveCross
    POSITION
    {
        x = 0
        z = 0
        rotation = 0
    }
    POSITION
    {
        x = 1
        z = 0
        rotation = 0
    }
    POSITION
    {
        x = 0
        z = -1
        rotation = 90
    }
    POSITION
    {
        x = -1
        z = 0
        rotation = 180
    }
    POSITION
    {
        x = 0
        z = 1
        rotation = 270
    }
}

A simple 3-inline cluster would be defined as:

SSTU_ENGINELAYOUT
{
    name = ThreeInline
    POSITION
    {
        x = 0
        z = 0
        rotation = 0
    }
    POSITION
    {
        x = 1
        z = 0
        rotation = 90
    }
    POSITION
    {
        x = -1
        z = 0
        rotation = 180
    }
}

Pretty simple, eh? The layouts are based on a 1m scale. Whatever positions defined in the layout will be scaled by the engineClusters mountSpacing value. Rotation values are applied to the models KSP-space Y axis (standard lengthwise axis for engines/most parts). When per-engine mounts are used, the same spacing and rotation is applied to them. You could even define the layout in the same file as your part (for custom layouts), or though MM patch.

I'm mostly settled on the one-part-per cluster setup, so I've skipped past the need for the investigatory testing, but I do appreciate the offer (I know firsthand how busy modding can keep you ). There were just too many issues to work around trying to do dynamic swapping of the # of engines. Doing a single-part-per-cluster also opens up a lot more opportunities for per-part variation and customization.

Aye, seems likely that I will be making the Radial Booster Decoupler the focus for this week. It is something that I'm fairly certain I can get -done- by the weekend. And I've still got some things to think through on the engines before I go too much further (like how best to manipulate the fairing stuff).

So... any preferences on the Radial Decoupler geometry? I'm thinking that I'll likely be making two sets of geometry for it; the full ring style, and something more resembling the stock radial decouplers. Should I include some geometry for the jettison motors? I can, but I'm unsure how well it would scale, or how good it might look for certain uses. Perhaps I'll put it as a mesh/geometry variant as well.

[JoseEduardo]

I would vote for adding a mesh variant for the decoupler with a nosecone with separatrons at the top, and the separatrons (that are already modeled in the SRBs) in the bottom, then you would attach the SRB with a flat top to the bottom of the nosecone, so it can always be at the same position given a certain height config

the meshes for these are already there, so nothing new to be modeled

@engines: already planning a few configs for RO

btw, the only Saturn V mounts I know (there might be more) are from KW (comes with engines), FASA, DECQ's and DennyTX's... I've seen others that are look alike though...

one question, will it be possible to make the aerodynamic shroud in the bottom engine for the Saturn (and maybe others you make that might have this) a separate controllable mesh? just so we can play around with the mount

[riocrokite]

cool, thx for the throughout explanation,

engine stack code is looking awesome,

and yah 2 box colliders per engine is perfect:)

As for the radial decoupler I'm assuming you're making them as a separate parts (not integrated into boosters). So they could be used both for tanks and boosters. One thing that comes to my mind is their height, the higher the better visually (imho), however they should fit your shortest tanks/boosters so that's probably the length limit:)

What about including a probe core and some EC in it? In case of not solid boosters this would help with reusability (so just a tank, engine, decoupler with a probe core and some optional radial parachutes:))

[Shadowmage]

I would vote for adding a mesh variant for the decoupler with a nosecone with separatrons at the top, and the separatrons (that are already modeled in the SRBs) in the bottom, then you would attach the SRB with a flat top to the bottom of the nosecone, so it can always be at the same position given a certain height config

the meshes for these are already there, so nothing new to be modeled

@engines: already planning a few configs for RO

btw, the only Saturn V mounts I know (there might be more) are from KW (comes with engines), FASA, DECQ's and DennyTX's... I've seen others that are look alike though...

one question, will it be possible to make the aerodynamic shroud in the bottom engine for the Saturn (and maybe others you make that might have this) a separate controllable mesh? just so we can play around with the mount

No, I will not be including nosecones in the decouplers; there is no clean way to get the nosecone into exact proper position for every booster. Nor would a nosecone be applicable to every booster. It will be mostly what I posted yesterday; a top + bottom attach point both with thrust transforms (both movable) + a central attach point (where the physics attach/where the actual joint is located). As I stated earlier, it will be up to you to put the thrust transforms wherever you want them to be located. If you want them in the nosecone, great... slide the booster or decoupler around until it is in the nosecone.

The engine mounts/shrouds are already separate meshes. And optional. And switchable. And scalable. And defined entirely through config (patchable). And they vertically position the engines automatically based on your mount selected/its config. You can do whatever you want with them. Change them to new models, not use any models, scale them bigger/smaller. The procedural fairing (SSTUNodeFairing) is optional as well. And configurable on a per-mount basis (for enabled/disabled/position offset). So yes, you will be able to use whatever you want for the mounts, just as I said in my previous post.

Basically I've tried to make it a functional engine-cluster welding tool (as normal part-welding with engines fails miserably). There is no way I can do all of the different engine layouts that people have been requesting (just not enough time in the day; not with having to work, sleep, have a life, etc). So, I've given -you- the power to do it yourself (or rather, -will- give you that power, as soon as the coding is done).

cool, thx for the throughout explanation,

engine stack code is looking awesome,

and yah 2 box colliders per engine is perfect:)

As for the radial decoupler I'm assuming you're making them as a separate parts (not integrated into boosters). So they could be used both for tanks and boosters. One thing that comes to my mind is their height, the higher the better visually (imho), however they should fit your shortest tanks/boosters so that's probably the length limit:)

What about including a probe core and some EC in it? In case of not solid boosters this would help with reusability (so just a tank, engine, decoupler with a probe core and some optional radial parachutes:))

Yes, they are a separate part. A replacement for the stock radial decouplers. Should be usable on any SRB or LRB, or anything you want radially attached with jettison capability. They will have sliders/buttons to adjust the height of the separators/attach rings. There will also be a slider/buttons to set the scale of the attach points/rings (as if I use a ring-shaped model, it will need to line up with the radius of the booster). The thrust transforms will move with the attach rings, so you can essentially set the locations for the separation motors (the rings/mounts are mostly just there for visual cues of where the separation motors will be located). Of course, it will still only be physically attached in one place, in the center (due to KSP joints/tree structure), but you'll be able to adapt the decoupler to fit whatever booster you are making.

At this point it looks like I will be making two separate parts, one with rings (like in the SS posted yesterday), and one that more resembles the stock decouplers -- because I don't feel like writing yet-another-mesh-switch plugin just for two models, and because of the very special model setup needed for these restricts use of the existing mesh-switch plugins and vastly complicates trying to do any kind of mesh switching. Both will have configurable height / thrust transform locations.

Probe core -- certainly possible, but that is more of a config/patch thing that you could setup yourself. I personally have no need for probe cores in my decoupled stages (and if I do, I'll just slap a MJ case on the side).

[JoseEduardo]

Basically I've tried to make it a functional engine-cluster welding tool (as normal part-welding with engines fails miserably). There is no way I can do all of the different engine layouts that people have been requesting (just not enough time in the day; not with having to work, sleep, have a life, etc). So, I've given -you- the power to do it yourself (or rather, -will- give you that power, as soon as the coding is done).

strong candidate for best mod ever

[Shadowmage]

strong candidate for best mod ever

If I have time I will try to add in some examples of some of the crazy stuff it can do for the next release. Stuff like re-using existing models for the mounts, strange layouts (dual-offset-3-inline), asymmetrical layouts (like the 3 of 4 Jupiter/DIRECT engine layout), and crazy-big clusters.

Seems like I will have most of the decoupler stuff wrapped up today (at least the coding side of it); so I should still have a few days this week to work on refining/finishing up the plugin end of the engine clusters as well.

[JoseEduardo]

from top to bottom:

Jupiter 120, Jupiter 232, Saturn C-3B and Saturn C-4B

I've also got untested configs for DIRECT V3 Jupiters (tried three inline instead of asymmetrical) due to lack of standalone RS-25 on my KSP and a 6 engine circular config that I must find out what messed it up (second in the part list)

I'll also try using FASA's F-1 to make a cluster for RO, I'll let you know how that went through PM though

Edited October 27, 2015 by JoseEduardo

[Shadowmage]

Updated radial decoupler, with height setting ability, and more properly oriented thrust transforms.

The SRB has had its fuel removed for demonstration purposes, to more closely simulate a real SRB at jettison.

- - - Updated - - -

from top to bottom:

Jupiter 120, Jupiter 232, Saturn C-3B and Saturn C-4B

I've also got untested configs for DIRECT V3 Jupiters (tried three inline instead of asymmetrical) due to lack of standalone RS-25 on my KSP and a 6 engine circular config that I must find out what messed it up (second in the part list)

I'll also try using FASA's F-1 to make a cluster for RO, I'll let you know how that went through PM though

Very nice

A note when you are re-using other engine models -- I had to create a new part.cfg file for the 4xNRV cluster, as I could not find a clean way to A.) Remove the exiting model node+insert the empty proxy model, and B.) Insert the engine cluster module -before- the ModuleEngines in the final patched output. If you know how to get those working, you should be able to just use patched copiess of the stock/original engine to make your clusters from (as I did with the F1 and RS-68).

Edit -- Oh, I also think I have figured out how to clean up the symmetry bugs with regards to the fuel tanks. Hopefully I'll get that cleaned up for the next release as well.

More preview goodness, yep, they work good in practice too, though could probably use some tweaking on the thrust transform directions and locations:

Edited October 28, 2015 by Shadowmage

[JoseEduardo]

had to share this

YEEEEEEEHAAAAAAAAAW

14xF1

(before anyone asks, these are not from the SSTU pack, I merely got FASA's F-1 and used the SSTU plugin as a proof of concept)

Edited October 28, 2015 by JoseEduardo

[davidy12]

Hey Shadow, why'd you get rid of 65m tanks?

[Shadowmage]

had to share this

YEEEEEEEHAAAAAAAAAW

14xF1

(before anyone asks, these are not from the SSTU pack, I merely got FASA's F-1 and used the SSTU plugin as a proof of concept)

Awesome

Glad things are working out for you, and that other mods' engines will work in the clusters (I had guessed/assumed/designed it as such, but had not been able to test it yet).

Looks like this should be a fun little plugin for general part-count reduction for many designs.

Hey Shadow, why'd you get rid of 65m tanks?

I never had 65m tanks, or even 6.5m tanks, so I'm not sure what you are referring to?

I have not removed anything from the mod in recent releases; it has all been additions, updates, and changes.

In general news, some of the coming 1.05 features could be extremely useful. The new IVA shader will be a massive time-saver for creating IVAs, and cut down on texture use (depending on how it works). I'm very interested to find if the same/similar process could be done with the other shader setups as well; the only reason most of my textures are unique/per part is because of the shading/AO maps. If I could just use those in a smaller/grayscale texture (srsly, I don't need 1024x for AO bakes, 256x or 512x would be fine for most larger parts), it could seriously cut down on texture use -and- increase how fast I could get parts created (being able to share textures would be... F()#@$^ AWESOME!).

I have a -dev testing- release available for some testing on the prototype (S)RB Decouplers. If you are interested in providing feedback on those, let me know and I will send you a link (its just set up in dropbox, so pretty easy to copy from). Looking to get some feedback regarding general layout, usability, and probably most importantly the thrust transform locations and orientations. I need these parts to work for any reasonable use case. They looked good to me last night for general booster-decouplers, but I know there is still room for improvement in the transform orientations at least.

[davidy12]

Oh nvm. Confused with ro.

[davidy12]

Speaking of IVAs, are you still working on the lander IVAs?

[Shadowmage]

Speaking of IVAs, are you still working on the lander IVAs?

Actively working on - no. There is only one of me, and I can only do so many things at once.

Still on the 'todo' / unfinished stuff list - yes.

Will they get finished at some point - maybe. I honestly have no desire/motivation to do IVAs. I don't use them, and from my perspective, for my games that I get time to play, it is just a waste of my dev time.

You are more than welcome to texture them yourself though; nothing stopping you. I mean... really... do you expect me to do -all- of this myself (before the end of the century)? I'm about to that point with many subjects.... you want it so bad, you do it. Because I neither want it, nor want to do it. Neither is it fun doing texturing; even less fun when it is something you don't care about/don't want to be doing. At that point it becomes 'work'... and I generally only do 'work' when I'm getting paid.

Edit -- If I sounded upset or angry in that post, I apologize. It is just a bit frustrating trying to manage all of the different requests while keeping things moving forward. Also I very much do appreciate the work that others have already contributed to the mods' development - time spent testing, feedback, balance, suggestions, and features/patches.

So, in case I haven't mentioned it before... I would like to express a big 'Thank You' to everyone participating in the thread. Your ideas and suggestions are providing most of the direction for where the mod is headed; it certainly wouldn't be where it is currently without your input.

With all that said - yes, I do intend on getting back to the IVAs (both texture, and geometry for the LC5-POD). However it will certainly be waiting until after 1.05 / the new IVA shader/texture setup is released. If I could actually just re-use textures for those parts, it would make it much less painful and time intensive, and I would be far more motivated to work on them. Would likely only take a couple of hours per part if I could do texture sharing, rather than the current 2-3 days per part.

Edited October 28, 2015 by Shadowmage

[riocrokite]

Yah, the things and pace you're developing here are both brilliant. Feel free to ignore whatever request / suggestions you feel aren't comfortable for you to not let your motivation go down We all (I hope) understand how difficult development of this stuff is - especially that you invest a lot of your quality free time into it. And it's not the paid job.

Once again amazing job, ignore stuff/people that cause your motivation to go down and keep it up It's totally awesome:)

As for pod IVAs, they are already cool. I also feel that finished/textured IVA's aren't priority and offer to less compared to the time invested in doing them. Time invested in finishing one IVA can get a lot of other more important things done.

Oh yeah, Shadowmage, feel free to drop me link and let me know what to test, I'll try to do it tommorrow.

[davidy12]

Actively working on - no. There is only one of me, and I can only do so many things at once.

Still on the 'todo' / unfinished stuff list - yes.

Will they get finished at some point - maybe. I honestly have no desire/motivation to do IVAs. I don't use them, and from my perspective, for my games that I get time to play, it is just a waste of my dev time.

You are more than welcome to texture them yourself though; nothing stopping you. I mean... really... do you expect me to do -all- of this myself (before the end of the century)? I'm about to that point with many subjects.... you want it so bad, you do it. Because I neither want it, nor want to do it. Neither is it fun doing texturing; even less fun when it is something you don't care about/don't want to be doing. At that point it becomes 'work'... and I generally only do 'work' when I'm getting paid.

Edit -- If I sounded upset or angry in that post, I apologize. It is just a bit frustrating trying to manage all of the different requests while keeping things moving forward. Also I very much do appreciate the work that others have already contributed to the mods' development - time spent testing, feedback, balance, suggestions, and features/patches.

So, in case I haven't mentioned it before... I would like to express a big 'Thank You' to everyone participating in the thread. Your ideas and suggestions are providing most of the direction for where the mod is headed; it certainly wouldn't be where it is currently without your input.

With all that said - yes, I do intend on getting back to the IVAs (both texture, and geometry for the LC5-POD). However it will certainly be waiting until after 1.05 / the new IVA shader/texture setup is released. If I could actually just re-use textures for those parts, it would make it much less painful and time intensive, and I would be far more motivated to work on them. Would likely only take a couple of hours per part if I could do texture sharing, rather than the current 2-3 days per part.

I understand, as long as your not giving up on them and you plan to do them eventually in the near future (by near I mean (NOT giving you a deadline nor did I mean to offend) around a year). I didn't take any offense also, I like the SLS parts and the decoupler.

[falken]

So, I used SSTU parts to make a Duna Descent + Ascent Vehicle or DDAV.

So, basically it gets sent to Duna and aerobrakes itself into LDO, waiting for whatever interplanetary ship I design. Once crewed, the engines in the trans-duna stage will initiate a braking burn, putting it into a long aerobrake.

Said aerobrake.

Dispensing with the heatshield and aeroshell.

- Need to add lateral sepatrons as the heatshield nearmisses the DDAV when it slows down

- Might include braking motors to help slow the craft down whilst keeping the heatshield in place

Drogue chutes deploy circa 13000m

- Need to add "cut chute" action group when on final descent. Craft oscilates slowly

Landing successful.

- Realised that the ladders are on the wrong side of the ship

- Fuel was ridiculously marginal

Already bored, time to go home.

- Realplumes is ridiculous, can't see a damn thing!

1st stage of ascent module burning nicely.

1st stage fuel depleted.

2nd stage fires up, bringing the DDAV crew module to a stable orbit.

- Will make the tank the hollow-2.5 version, have 1000m/s DV left. This will help with fuel margin for descent stage

Nosecone detaches to reveal docking node

- I thought this was so cool, but just only realised right this second that there would be no way to dock with the mothership for crew transfer prior to the ground mission. Will change to a shielded docking port of some description

It would be cool to have a conical shaped landing pod shaped like this, but with no ablator etc etc, but I'm happy enough!

Without SSTU parts (particularly fiddling around with the hollow tanks and tweakables), this would not have been possible (or at least, not look quite so awesome).

[JoseEduardo]

I'm pretty much settled on my launcher list with Vostok and Soyuz for light stuff, Jarvis for medium payloads, SLS and Saturn V for heavy and Saturn MLV for the insane stuff.

with current SSTU release I have SLS, and some bits for Jarvis and Saturn, can't wait to be able to have full Jarvis and Saturn using SSTU

here's something I threw together quickly (KW, FASA, SSTU and Procedural Fairings):

Javascript is disabled. View full album

[davidy12]

So, I used SSTU parts to make a Duna Descent + Ascent Vehicle or DDAV.

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

So, basically it gets sent to Duna and aerobrakes itself into LDO, waiting for whatever interplanetary ship I design. Once crewed, the engines in the trans-duna stage will initiate a braking burn, putting it into a long aerobrake.

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

Said aerobrake.

http://i.imgur.com/87LdP4il.png

Dispensing with the heatshield and aeroshell.

- Need to add lateral sepatrons as the heatshield nearmisses the DDAV when it slows down

- Might include braking motors to help slow the craft down whilst keeping the heatshield in place

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

Drogue chutes deploy circa 13000m

- Need to add "cut chute" action group when on final descent. Craft oscilates slowly

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

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

Landing successful.

- Realised that the ladders are on the wrong side of the ship

- Fuel was ridiculously marginal

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

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

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

Already bored, time to go home.

- Realplumes is ridiculous, can't see a damn thing!

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

1st stage of ascent module burning nicely.

http://i.imgur.com/9DgMZODl.png

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

1st stage fuel depleted.

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

2nd stage fires up, bringing the DDAV crew module to a stable orbit.

- Will make the tank the hollow-2.5 version, have 1000m/s DV left. This will help with fuel margin for descent stage

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

Nosecone detaches to reveal docking node

- I thought this was so cool, but just only realised right this second that there would be no way to dock with the mothership for crew transfer prior to the ground mission. Will change to a shielded docking port of some description

It would be cool to have a conical shaped landing pod shaped like this, but with no ablator etc etc, but I'm happy enough!

Without SSTU parts (particularly fiddling around with the hollow tanks and tweakables), this would not have been possible (or at least, not look quite so awesome).

How'd you get Realplume effects?

[PugzInSpace]

This is what I always wanted from stock KSP. And from what I can see the config balancing is perfect for me.

[VenomousRequiem]

Well, Shadow, and anyone else who's interested:

The joints on the new decouplers are a little wonky... but other than that they look fine. I hope soon you finish textures and everything so everyone else can get this neat little doodad!

Also, another quick note about heat.

I'm no rocket scientists(Professionally anyways) but the gases are cooling down as they're shot out of the engine bell/nozzle. So shouldn't the engine get that sweet sweet red hot glow around in the green circle rather than the red one? The little bottle neck is what gets hottest in real life, as the gasses are closest to their hottest.

Some neat reference I found~

Edited October 29, 2015 by VenomousRequiem