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

[ComatoseJedi]

6 hours ago, Shadowmage said:

AJ10-190 - Unwrapped/baked/initial color and specular pass -- Still quite a bit to do, but is usable at this point.

 

It took me 2 days to make a simple adapter and here you go making awesome stuff like this......

[stratochief66]

10 hours ago, Shadowmage said:

 

Hmm... now that you mention, I'm not sure if I ever tested that setup as far as thrust gimballing.  Yes, if there is an error it is likely in the model heirarchy.  Will investigate this shortly, and likely have a fix available later this afternoon (with a few other minor bits).

 

Edit:  Indeed, I have the thrust transform parented directly to the SM main mesh rather than the engine bell/gimbal.  Fixing now, will need to re-export/etc after I get home from work.

 

Awesome, thanks for the quick turn around.

I was working on some RealPlumes for RO today. The RL-10 engine with extending nozzles don't seem to accept RealPlume FX, or have stock based plumes of their own?

 

@JoseEduardo explained to me that one of the key differences in the engine module you use to control those engines is that it ensures the nozzle is fully extended before it generates thrust. That is definitely nice!

Unfortunately, it also has two issues. One, it doesn't stop generating thrust when it is throttled completely down (for the RO configs, minThrust does not equal zero) and it doesn't support limited ignitions/ullage. So, I'll probably end up moving the RO configs for those engines over to the standard engine module used for RO, and hopefully that will also solve the no RealPlume allowed issue.

[Jimbodiah]

Check out RoverDude's kontainers (USI Core), there are 1.25/2.5/3.75/5m KIS containers in there that will let you drop up to 60K volume in one cargo container. I tend to usi his MKS Kolonization parts, and drop most of them in those containers.

[Jimbodiah]

Was bored, so decided to run a Constellation mission with my new Ares I and V builds (almost all parts are SSTU). I cloned the J2 into J2X and the RS25 into RS68 versions to get the thursts right (and the actual used engines I think) 

Ares V (EDS and LEM): https://www.youtube.com/watch?v=zIcF8shpZhY 
The main engines are RS68 (RS25 cfg hack) on a Procedural Fairings thrust plate, this way I can get the Real_Plume effects.

Ares I (CM with crew): https://www.youtube.com/watch?v=NAqg3eRWxjs 
Had to run the top tank at around 1/3 filling as it would be too heavy otherwise. Point was to have a realistic looking rocket vs a Kerbaly balanced one, but the J2X can not pull the wait of all that fuel if it were full (RS25 would be needed, but same dV left in the end either way).  

 

Latest version of my Real_Plumes configs: Download .rar file

 

Edited December 23, 2015 by Jimbodiah

[blowfish]

Regarding compatibility issues with the extendable engines @Shadowmage It might make sense to configure the deployable engine as something that runs alongside rather than derives from ModuleEnginesFX.  You just have to set manuallyOverridden=true on the engine module (either in the config or in code) so that it can't activate on staging, and hide some or all of its actions while it's disabled (this is exactly what MultiModeEngine does).  This would allow compatibility with any engine module and would probably get rid of the RP issues.

Edited December 23, 2015 by blowfish

[Shadowmage]

On Monday, December 21, 2015 at 2:36 PM, blowfish said:

Hmm ... now that I think about it, it's possible that the current balance system is unfair to some engines.  Here's why:

*BEGIN LONG WINDED TECHNICAL DISCUSSION*

Hydrolox engines have much higher Isp than kerolox engines, but in real life that comes at a price - you need much larger tank volume and you have to deal with boiloff.  In KSP, neither of those things exist, so using raw, real world I_sp numbers for the comparison is going to make hydrolox engines look very good and kerolox engines look bad.  So I think it might make sense to scale the I_sp based on the mixture before doing the comparison.  KSP engines have I_sp values pretty close to real world kerolox engines (well, actually a bit closer to hypergolics but the difference is only about 5%.  The conversion factor that RealFuels uses to compare I_sp between hydrolox and kerlolox engines is 1.27 (vacuum) / 1.3 (sea level).  Applying a scale of 1.27 would give the RL10 a vacuum Isp of 364s, which is high for stock engines, but not way outside the range (particularly considering how low the thrust is).  If you apply the hypergolic scaling too, you get 346s ... at this point it might be more reasonable to apply the scaling you did to begin with.

My personal view on the KLOX / HLOX rift for stock is this:   Stock -has- LH2; it is just the same density as RP1, offers minimal ISP increase, and just happens to be named 'LiquidFuel' as well.  If I take a look at the stock poodle and LV-909; I have a hard time seeing those as anything but vacuum optimized lh2 engines.  The only real problem with this is that some of the stock RP1 engines creep upwards into LH2 territory a bit too far (ISP wise); if a few could be knocked down 10-15 ISP, this rift in stock engine types would become even more apparent.

This general view places hypergolics/monopropellants in the ~300-ISP range; standard RP1 at ~310, and LH2 at the higher end ~350.

However, I'm not going to say that the balance on my engines is final; its not.  It is mostly a first-pass, with zero manual tweaking (so far).  After I have developed a few more of the 'main' engine variants, I will likely take another good look at the balance and see what needs to be tweaked.  The problem with trying to do it now is that there are some apparent gaps that will be filled by new engines, rather than filling them by re balancing existing engines.

 

 

19 hours ago, Jimbodiah said:

@Shadowmage  Re the RO/Plumes thing: An "easy" fix (in terms of not changing your code) would be to make a modular mount to let us just mount the separate engines on and that has an interstage node should anyone want to use a cluster on a second stage. Jose can implement his RO, I can do my plumes, you don't need to rack his brain, everyone wins with the least amount of effort?

@JoseEduardo Maybe for the planned Station/Satellite series down the road?

It's a shame RaiderNick no longer works on his modules, he basically had an entire run of satellites and those soyuz parts. I am using his US probes pack right now just to have an excuse to launch stuff

Doing as you suggest with the engines goes directly against the reason why I created them in the first place -- to reduce part count.  If you want to set them up as such, go for it; nothing stopping you.  You could certainly make traditional stock-like parts with the engines; they use a regular old .mu model file just like any other KSP part. 

Seriously though, there -is- a way to get those patches working, you just need to figure it out yourself, or -wait- until i can figure it out.  Asking for me to do a bunch more work is -not- the solution.

 

On Tuesday, December 22, 2015 at 4:25 AM, JoseEduardo said:

if the clusters are made prior the engine edit, a new patch will need to be done specifically for the cluster, if the clusters are made after every change has been applied to the single engine they work great

that is why I had to make the RO patches in a way I excluded the original clusters and imediatelly re-created them after all patches have been applied to the single engine, because if I didn't do that I either would have to write a patch to modify a cluster alone instead of just doing the RO patch for the single engine and having the cluster patch multiplying them

I had to do it that way even in the beggining when you released the white F-1 and RS-68 and I was playing around with FASA engines, the FASA engines didn't get their RO patch done without the :FINAL in them, without that they were just copying the original stock engine, after I used the :FINAL even RealPlumes got added to them

like this? http://forum.kerbalspaceprogram.com/index.php?/topic/119951-cormorant-aeronology-dev-thread/

Yep, think I understand what is going on with the patches and stuff; pretty much exactly as you say -- initial cluster patches need to be made -after- all patches have occurred to the base engine.  Will take a day and play around with them sometime over this holiday/weekend to see if I can get it sorted out on my end / figure out what setup is needed.  Pretty sure this is just a matter of figuring out the proper BEFORE / FOR / AFTER block sequence for the patches.

[Jimbodiah]

I'd think you figuring it out and changing the implementation of all current clusters to accommodate external mods would have been more work than just copying the modular tank to length=0 (or just very small) and adding nodes to the bottom. Maybe I was wrong?

[Shadowmage]

13 hours ago, stratochief66 said:

 

Awesome, thanks for the quick turn around.

I was working on some RealPlumes for RO today. The RL-10 engine with extending nozzles don't seem to accept RealPlume FX, or have stock based plumes of their own?

 

@JoseEduardo explained to me that one of the key differences in the engine module you use to control those engines is that it ensures the nozzle is fully extended before it generates thrust. That is definitely nice!

Unfortunately, it also has two issues. One, it doesn't stop generating thrust when it is throttled completely down (for the RO configs, minThrust does not equal zero) and it doesn't support limited ignitions/ullage. So, I'll probably end up moving the RO configs for those engines over to the standard engine module used for RO, and hopefully that will also solve the no RealPlume allowed issue.

Hmm.. the module running those engines is a very-slightly modified ModuleEnginesFX -- it should be fully compatible with anything that works for ModuleEnginesFX (including effects/etc.).   I do not touch thrust, or effects -- if it can be done with the stock ModuleEnginesFX, it should work exactly the same for the SSTUDeployableEngine module; there is zero reason or room for incompatibilities between the two (it IS a ModuleEnginesFX as far as game code is concerned).  I guess this would come down to - does RO/RF use their own custom engine module?

Anyhow, do whatever you need to;  I don't use or personally support RO, so makes no difference to me.  Keep in mind you will need to find some other way to handle the animation on those engines;  the stock ModuleAnimateGeneric -might- work for it.  Could also leave the SSTUAnimateControlled in place, and add an SSTUAnimateUsable as the user-interface module for it (examples of this can be seen in the LanderCore parts for the ladder-extension functionality).  Let me know if you run into problems with the animation stuff, can probably help you get it sorted out.

[Shadowmage]

13 hours ago, blowfish said:

Regarding compatibility issues with the extendable engines @Shadowmage It might make sense to configure the deployable engine as something that runs alongside rather than derives from ModuleEnginesFX.  You just have to set manuallyOverridden=true on the engine module (either in the config or in code) so that it can't activate on staging, and hide some or all of its actions while it's disabled (this is exactly what MultiModeEngine does).  This would allow compatibility with any engine module and would probably get rid of the RP issues.

I would gladly do this if you can find/point out a way to make it event driven (as is the current implementation).  Sadly, this information is only present in the engine module as far as I know, and I would have to check engine state every game tick.  I actively avoid adding Update/FixedUpdate blocks to my modules if I can; no reason to have code run on a per-frame or per-physics-update basis if it doesn't need to.  I could be missing some information though (the state of documentation on the KSP modding API is... I would like to say it is terrible, but I can't... it is mostly non-existent, and those bits that do exist are out of date or completely lacking in useful information); so if you know of something that would let this work, I'm all ears.

[Shadowmage]

1 hour ago, Jimbodiah said:

I'd think you figuring it out and changing the implementation of all current clusters to accommodate external mods would have been more work than just copying the modular tank to length=0 (or just very small) and adding nodes to the bottom. Maybe I was wrong?

What I'm talking about is not changing the implementation of the clusters, merely changing how they are created through patches; mostly this would consist of adding/changing one word to/in the patches.  One. Word.  I wouldn't even need to open an IDE, load Unity, or touch a modeling program to do the change.

The changes you were suggesting (if I am understanding you correctly, basically going the procedural-parts thrust-plate way of things), would require a lot more work in all areas (modeling, config, and plugin-side), in addition to going against the entire reason I'm creating this mod (which is part-count reduction).  That is the main reason I don't have a generic multi-node thrust plate/mount system to begin with;  I believe increasing vessel part count unnecessarily is wrong, at least as long as KSP performance is part-count limited.

You seem to be making a huge deal out of it, when it is not.  The solution will be a very simple patch/setup, and will require no changes to the mod or its overall layout or structure.  You just need to either A: Find someone knowledgeable in MM to set it up, or B:  Wait until I have the time and patience to learn more MM stuff and set it up myself.

(I probably spent more time writing up this post than it would have taken me to figure out and fix the patch system;  sadly, I have used all of my patience for this subject in typing up this post, so will be at least a few days/weeks before I feel like looking into it).

[blowfish]

1 hour ago, Shadowmage said:

I would gladly do this if you can find/point out a way to make it event driven (as is the current implementation).  Sadly, this information is only present in the engine module as far as I know, and I would have to check engine state every game tick.  I actively avoid adding Update/FixedUpdate blocks to my modules if I can; no reason to have code run on a per-frame or per-physics-update basis if it doesn't need to.  I could be missing some information though (the state of documentation on the KSP modding API is... I would like to say it is terrible, but I can't... it is mostly non-existent, and those bits that do exist are out of date or completely lacking in useful information); so if you know of something that would let this work, I'm all ears.

I think it might be doable - I'll take a look if I have time.  Overriding the events is easy ... now that I think about it, action groups might be the hard part.

[Nertea]

On 12/18/2015 at 7:20 AM, Shadowmage said:

Thank you   Truly, that means a lot to me coming from you;  I have always held your work in the highest regard, and the styling and amount of detail in your parts has always been an inspiration to me.

Heh well, it's well deserved. I don't really look at people's threads much these days, but I had to say something when I looked at your galleries. I have to admit, I'm quite jealous at the level of detail in the piping and turbopumps, and will probably be using *you* as inspiration for some things myself!

[Jimbodiah]

Mage, chill out. It was only a suggestion as I don't know what's involved and what you described sounded like a lot of work. Just trying to help.

[Shadowmage]

9 minutes ago, blowfish said:

I think it might be doable - I'll take a look if I have time.  Overriding the events is easy ... now that I think about it, action groups might be the hard part.

Aye, hiding/disabling the GUI actions and action groups is very doable from an external class (as all the Fields/Events/Actions fields are public and mutable).  I just do not know how to intercept an action-group triggered event from an external class; the only way I could find to do this reliably was through subclassing and overriding the method(s) for OnActive (as the engine module action group merely calls that method).

Hmm.. that makes me think a bit.  -If- I set up the external module to act during OnActive, -and- I'm remembering how the engine module is setup correctly, this might be doable purely through the external modules OnActive() method.  I could potentially use some of the MultiModeEngine specific overrides as you had suggested just to make sure the engine doesn't do anything strange / control happens through the external module.

Hmm, and more hmm... things to think on.  Will do some investigation on this tonight if I have time; could potentially be as easy as removing the subclass definition and adding some links to the now-external engine module.

 

[Shadowmage]

Working through finishing up the new docking port geometry (1.25m standard/passive version).  Have added all of 'optional' bits that will be available on the stand-alone docking-port parts (will replace the existing docking port part(s)), and working on the setup of the optional bits for the station modules.

The parachute pouches are... well... for the parachutes.  These are a two-piece add-on that consists of a persistent part and the jettisoned cap.
Docking lights and camera are setup as-per the light/camera setups on the newly redone pods.
The active/status lights will probably only be present on the station-integrated multi-docking-port parts; these will indicate if the docking port is on or off (magnetics activated/ready to dock).

Still not entirely sure that I like the stuff poking out the side of the port so far, but I'm not sure that I'll be able to find any other way to do it cleanly.  Going to do another test on the parachute-pouches where they are more integrated into the side of the port rather than sticking out the side so far; however I want to keep the same base geometry and texture for both the standard and w/parachute variants, so my options are a bit limited.

 

I also intend on making 'active' versions of the docking ports, that will -hopefully- be able to have extendable contact plates; as such I have designed the initial geometry to leave room for the movable plate.  Will require a new texture for the 'active' parts, as there is quite a bit of difference in the geometry.  Also will require some custom plugin work for them, so these will likely be a ways off in the future.  The initial set will be passive only 0.625, 1.25, and 2.5, each with their own geometry, all available in standard and with/parachute variants.  (When I rework the optional-module-swapping code, these will be combined into a single part that has an 'add/remove parachutes option).

For the time being I will be rescaling the 1.25m for use for the SC-A-CM (as a 0.625m port).  In the near future I want to develop a retro-looking probe-and-drogue type port for 0.625m, specifically for use on the SC-A-CM and smaller landers.  The specialized geometry should allow me to make it so a kerbal can visually fit through the port (would have a time with the rescaled 1.25m parts given the size of the door when rescaled).

 

 

[Shadowmage]

Hmm, yah...I think I like the internal cutout for the parachutes rather than the external lumps.  And it will still work fine for the 'active' type ports when I get to them.  Not sure how I'll get it situated on the 0.625m ports (as they will use much more of their internal space/no room for cubbies).

 

Still not sure how to integrate the lights without external stuff.  Hmm..... mayhaps I could make them an animated-deployable bit (that would come out of cubbies on the other 3rds of the model).   Thoughts?
Trying to think a bit more long-term on these docking ports, as I know I want to use the same (or -very similar-/compatible) geometry for the station parts when I get there.

 

And in doing all of this playing around with existing 'finished and textured' geometry for the docking port, I've learned a few techniques that will make it easier to do geometry changes in the future.  Massive changes will still require a re-uv layout and full-new texture, but for -some- things I might be able to rework existing geometry without requiring a full re-do of the part.  No matter what though, any geometry change still requires redoing the AO bake (in part or in full); which for some models might still take many hours to break up the model, do the bake, and re-combine the model.  So... still don't expect me to go about reworking/changing existing finished models too much; but I know have a few tools that I can use in those cases where it really is needed.

 

[Shadowmage]

5 hours ago, blowfish said:

I think it might be doable - I'll take a look if I have time.  Overriding the events is easy ... now that I think about it, action groups might be the hard part.

Thinking more on this; seems like it should all/mostly be doable from an external class.  Have the 'Deploy Animation Module' have its own set of 'Activate Engine' gui and action group methods; during its init pass, go in and disable all of the ModuleEngines own action groups and gui event fields (through the Actions[] and Events[] accessors); from then on you can route all interaction with the ModuleEngines through the 'Deploy Animation Module''s own gui and action group stuff and/or publicly accessible methods.  Basically it would be throwing a wrapper around the ModuleEngines user-interface stuff and routing it through the 'Deploy Animation Module' user-interface and methods first.

It is a bit of a workaround, but it might actually be cleaner implementation-wise in the end than the existing code.  Will likely play around with this tonight after I get the bugfix release cleaned up / packaged / posted.

And one more test of the docking port geometry; with integrated and deployable lights/camera geometry.  Definitely looking like a better setup and implementation, and will likely be sticking with this or something -very- similar.

Heck, the geometry is clean enough that I'll likely only do a single stand-alone version of the docking ports -- with parachutes and docking lights for all! (where if you don't want them, just don't use them!)

 

Edited December 23, 2015 by Shadowmage

[Jimbodiah]

Docking camera, cool!!!

[123nick]

are the adjustable fueltanks n stuff realy nessesary? because theres a mod that does exactly that , procedural parts, has procedural SRBS with adjustable thrust, vaccum oriented or surface oriented ISPs, size, diameter, height, texture, even shape: u can have cone shapped, orb, smooth curve, and more shapes of SRBs.

[Jimbodiah]

Proc Parts is a huge load on my CPU for some reason. Besides that, it has the functionality but not the looks, and if you want a nose-cone or engine mount it will require several parts, vs only 1 in SSTU. There are even tank sections with integrated SAS/RCS, so even more parts saved. I tend to use ProcParts for small probes to hold xenon, or resupply ships with hacked cfg files for TAC or other life-support resources, but they all need several extra parts to make it work over the SSTU modular parts.

[123nick]

Just now, Jimbodiah said:

Proc Parts is a huge load on my CPU for some reason. Besides that, it has the functionality but not the looks, and if you want a nose-cone or engine mount it will require several parts, vs only 1 in SSTU. There are even tank sections with integrated SAS/RCS, so even more parts saved. I tend to use ProcParts for small probes to hold xenon, or resupply ships with hacked cfg files for TAC or other life-support resources, but they all need several extra parts to make it work over the SSTU modular parts.

yeah, i guess both have there pros and cons.

[Jimbodiah]

Procedural Parts and SSTU combined  

[123nick]

Just now, Jimbodiah said:

Procedural Parts and SSTU combined  

looks awesome  

[Shadowmage]

Updated testing pre-release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.3.24-pre5

Mostly improvements to the parachute module, see the change-log for full details.

If no major issues are found, will likely move this to the recommended release in the next day or two.

[ComatoseJedi]

Okay, from the looks of things, everything seems to be in working order. Deployment altitudes are configurable in flight. The chute safety indicator seems to be working as intended. The engine bell warmed up to a nice red glow when hot, a little less red than most of the engines you have (then again i was in the sunlight), but it was real enough to know it was hot, so tuning it down isn't really necessary, at least not on my computer. The only real issue is the staging of the parachute. It -says- it's staged, but it doesn't show it's staged on the stage list icons. I don't know if that's intentional, a minor thing or something that comes with the territory on modifications such as this. 

Another thing that caught my attention is that you have two control options in the gui on the a series pod. I know you were going for a one piece system on this, but couldn't you put a difference in control, like "control from command module" and "control from docking port" to tell the difference? It may of been a silly request, but that's all I seen. But, as far as the parachutes, they work great and nice coloring on the pod chute. that red/olive drab is awesome! Drogues and chutes work as intended. If there's anything I missed, I'm sure Jim will pick it up lol. 

EDIT: The parachute module shows staging and is configurable in the bay and in flight, sorry forgot to mention that. 

Edited December 24, 2015 by lynwoodm