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

[Jimbodiah]

The flame might do some damage. I used to put the stock seperatrons inside the of the decoupler (as in not sticking out on the side of the rocket) and they never did any damage, so I think they have damage turned off as well.

A small payloads launcher in action with the new decoupler, and just showing off 

 

And the new Jupiter III, when ya just gotta, wanna, need ta, launch 450 tons into LKO in one go.

 

Decouplers looking fine, Mage! 

The only thing I have noticed is that the texture glitches where it meets the stage above it.

Edited January 14, 2016 by Jimbodiah

[Fury1SOG]

4 hours ago, Shadowmage said:

Hmm.. there might actually be a way to add the LS stuff -- but it would need to be patched into the resource-switch module for those parts (adding the LS resources to the list of resources to be switched to); and I would need to look at them in-depth to explain it further than that.

RCS/SAS - sure, feel free to submit a PR / etc.  Pretty sure the LC pods are just using copy/pasted/placeholder values from something else for those modules.

 

Interstage Decoupler -- how do you feel about the models / geometry for the ullage motors -- is it appropriately sized / shaped for its purpose?  If not, is there any specific references you would like to see it modeled after?  If it is fine, sweet... will unwrap/texture/finish it up today/tomorrow.

Here is the MM config I use to add Material Kits, Supplies and Mulch to one of the LC5 pod variants:

@PART[SSTU_LanderCore_LC5-POD]:NEEDS[SSTU]
{
    @MODULE[SSTUResourceSwitch]
    {
        @TANK,1
        {
            TANKRESOURCE
            {
                resource = MaterialKits
                amount = 500
                fillAmount = 0
            }
            TANKRESOURCE
            {
                resource = Supplies
                amount = 60
                fillAmount = 60
            }
            TANKRESOURCE
            {
                resource = Mulch
                amount = 6
                fillAmount = 0
            }
        }
    }
}

 

By the way, I've noticed that the lander fuel tank variant that uses the SSTUConverter module creates a lot of "lt:xxxxx ct:xxxxxx" messages in the log and causes some lag.

 

I really love to use SSTU landers for my bases! I use them for light transport between the bases and an orbiting space station.

[Jimbodiah]

Mage, noob me... I have multiple branches on Github but have no idea how to merge them into a single PR. If you can find them, delete #8 and use #9-17 (3x pod change, 3x subassy, 2x craft). Else I can make PR out of them, but as Blowfish pointed out, that is just plain old spamming    I'm not touching github right now as I will fubar it.

Edited January 15, 2016 by Jimbodiah

[Shadowmage]

1 hour ago, Fury1SOG said:

Here is the MM config I use to add Material Kits, Supplies and Mulch to one of the LC5 pod variants:

 

By the way, I've noticed that the lander fuel tank variant that uses the SSTUConverter module creates a lot of "lt:xxxxx ct:xxxxxx" messages in the log and causes some lag.

 

I really love to use SSTU landers for my bases! I use them for light transport between the bases and an orbiting space station.

Re the patch -- you can also add those supplies to the other tank-variants as well, so that they are available for both with/without fuel tanks.  Or so I believe (been months since I've looked at those plugins/configs... so a bit rusty).  But yep, thats what I had in mind earlier

 

Log spam -- noted and fixed, will be available with the next update.

 

51 minutes ago, Jimbodiah said:

Mage, noob me... I have multiple branches on Github but have no idea how to merge them into a single PR. If you can find them, delete #8 and use #9-17 (3x pod change, 3x subassy, 2x craft). Else I can make PR out of them, but as Blowfish pointed out, that is just plain old spamming    I'm not touching github right now as I will fubar it.

No worries, I'll help you get it all sorted out over the weekend if you are available.  Can meet up in KSP-irc or something easy and work through it.  Git/github certainly are a bit of a handfull to manage.   I don't have access to your branches/forks by the way, so you'll have to delete those yourself.  Merging -- you would need to use one of the actual programs for it; downloading the fork and all branches, merging the branches into whichever, and then pushing that back to your fork (probably as a new branch so that the commit history is clean).  Can work through all that though if you don't get it figured out.

[Jimbodiah]

Mind if I just make a PR for each? Would be simplest... or just mail you the craft files

[Autochton]

8 hours ago, Jimbodiah said:

Mage, noob me... I have multiple branches on Github but have no idea how to merge them into a single PR. If you can find them, delete #8 and use #9-17 (3x pod change, 3x subassy, 2x craft). Else I can make PR out of them, but as Blowfish pointed out, that is just plain old spamming    I'm not touching github right now as I will fubar it.

You can merge branches together into one relatively easily. Checkout a branch for it (you can make a new one just fine), call `git merge <branchname>` on each of the branches you want in there. Then make the PR from that branch, once you've pushed it.

So for example, if you have a repository with three branches, let's say they're named 'a' through 'c', and you want a branch 'stuff' with the changes in all four. Let's say the below is your git branch structure (asterisks are commits):

     *--* a
    /
*--*--*--* master
    \  \
     \  * b
      * c

You then issue the following commands (the red bits, the parentheses are explanations):

git checkout master (to get the branch to start on master)

git checkout -b stuff (to create the stuff branch and go onto it right away)

git merge a (this, like the other two below, will merge the given branch (here 'a') into the branch you're on, in this case stuff. If there are conflicts, this is where you deal with them.)

git merge b

git merge c

The end result will be a branch named 'stuff' that has all the commits from a, b and c, which should be easily mergeable into master. Push that one to github, and you can do a single PR with everything in it.

[Jimbodiah]

@Autochton  Thanks for the walk through!  I think this is too complicated for what I wanted to pass on, as the work on github is more than the info I am wanting to add. I will just post the links to the .craft files so Mage can download them as I will end up spamming Github with my ineptitude

The LC changes I just sent in three Pull Requests for, and here are the crafts http://kerbal.nl/sstu/sstu_craft.rar

Crafts:
- LC2 2-stage lander for Mun/Minmus/etc
- LC2 2-stage lander for Duna
- LC3 2-stage lander for Mun/Minmus/etc
- LC5 2-stage lander for Duna
- Delta IV Heavy with Orion/ICPS
- Saturn V with Apollo CM/SM and LC2 Munlander (huge!)   Main body courtesy of another contributor, I only added the top section.
- Small Payload Launcher (2-stage 2.5m launcher with new fairings)

Subassemblies:
- Orion CM/SM/LAS with ICPS
- Apollo CM/SM/LAS, 2-stage Munlander and fairings (complete Saturn V top section)
- Munlander with bottom node active for placing in petal adapter 

 

I'll make the SLS block 1 (Orion) later, and an Ares I and Ares V when the engines become available (RS68 clusters and J2X). I have versions with RS25s of the Ares rockets now.

Edited January 15, 2016 by Jimbodiah

[Shadowmage]

Bit of texturing work on the SC-C parts; going for a cloth covered look:

 

And initial geometry pass for RS-68 mount (and some RS-68 texture work that you mostly can't see because of the mount):

Thats actually the first engine I've made that looks like a stock KSP engine, if you don't count all the detailing thats obscured by the shroud.

[Jimbodiah]

That soyuz is starting to look really nice!!!! Is that the new port size as well ?

LOL on the shrouded engine being stock-alike. Yeah, not much detail left when the bell is the only thing showing.

[stratochief66]

I'm back to working on the RO configs, and boy have some things changed!

Some easy things to adapt to included many part name changes (capsules, service modules)

Something has changed about how SSTU generates engine clusters, and/or how MM works. For the life of me, I can't get the stock SSTU engine clusters to go away (previously accomplished like so)

!PART[SSTU_ShipCore_ENG-J-2x5]:FOR[SSTU]
	{
	}

 

Before the new ones (based on our RO/RealFuel modified ones are created by:

+PART[SSTU_ShipCore_ENG-J-2]:NEEDS[SSTU]:FINAL
	{
	@name = SSTU_ShipCore_ENG-J-2x5

I read your post tagging me, including this:

So, for real-plumes (and RO/etc):

change the engine-cluster creation patches to the following starting line (really, just add the :FOR[SSTU_ENGINES] at the end) (i will be doing this with the next release for all engines):

+PART[SSTU_ShipCore_ENG-F1]:NEEDS[SSTU]:FOR[SSTU_ENGINES]

 

But I couldn't get any variation on those arguments to work for deleting the engine clusters.

 

The -only- things I got to delete the original engine clusters was by either deleting the original cluster generating configs (not automatable, or desirable) or modifying the generator line to include this:

 

:NEEDS[SSTU&!RealismOverhaul]:FOR[SSTU_ENGINES]

for instance:

+PART[SSTU_ShipCore_ENG-J-2]:NEEDS[SSTU&!RealismOverhaul]:FOR[SSTU_ENGINES]

Edited January 15, 2016 by stratochief66

[Shadowmage]

4 hours ago, stratochief66 said:

I'm back to working on the RO configs, and boy have some things changed!

Some easy things to adapt to included many part name changes (capsules, service modules)

Something has changed about how SSTU generates engine clusters, and/or how MM works. For the life of me, I can't get the stock SSTU engine clusters to go away (previously accomplished like so)

!PART[SSTU_ShipCore_ENG-J-2x5]:FOR[SSTU]
	{
	}

 

Before the new ones (based on our RO/RealFuel modified ones are created by:

+PART[SSTU_ShipCore_ENG-J-2]:NEEDS[SSTU]:FINAL
	{
	@name = SSTU_ShipCore_ENG-J-2x5

I read your post tagging me, including this:

So, for real-plumes (and RO/etc):

change the engine-cluster creation patches to the following starting line (really, just add the :FOR[SSTU_ENGINES] at the end) (i will be doing this with the next release for all engines):

+PART[SSTU_ShipCore_ENG-F1]:NEEDS[SSTU]:FOR[SSTU_ENGINES]

 

But I couldn't get any variation on those arguments to work for deleting the engine clusters.

 

The -only- things I got to delete the original engine clusters was by either deleting the original cluster generating configs (not automatable, or desirable) or modifying the generator line to include this:

 

:NEEDS[SSTU&!RealismOverhaul]:FOR[SSTU_ENGINES]

for instance:

+PART[SSTU_ShipCore_ENG-J-2]:NEEDS[SSTU&!RealismOverhaul]:FOR[SSTU_ENGINES]

 

The way it is currently setup, is that anything modyfing the engines/clusters needs to be done in a :BEFORE[SSTU_ENGINES] block.  That way all of those patches get applied -before- the clusters get cloned/created.

Aside from that, I'm not really sure; especially regarding deletion of the existing patches clusters... that really should not be necessary and you should be able to modify the engines before the clusters are built (in a BEFORE[SSTU_ENGINES] block), or modify the clusters after they are cloned/built (in an AFTER[SSTU_ENGINES] block).  Granted, I have no idea what is needed for RO or how those patches are normally setup.

 

Edit:

I will take some time to look into this tomorrow prior to the release (in case I have to change anything).  Have been meaning to make an RO setup for awhile anyhow, so might as well get it set up and use it for testing   And knowing more about the setup can aid in development, to help with instances where I may unintentionally make things incompatible/difficult to setup.

 

Edited January 16, 2016 by Shadowmage

[stratochief66]

1 hour ago, Shadowmage said:

 

The way it is currently setup, is that anything modyfing the engines/clusters needs to be done in a :BEFORE[SSTU_ENGINES] block.  That way all of those patches get applied -before- the clusters get cloned/created.

Aside from that, I'm not really sure; especially regarding deletion of the existing patches clusters... that really should not be necessary and you should be able to modify the engines before the clusters are built (in a BEFORE[SSTU_ENGINES] block), or modify the clusters after they are cloned/built (in an AFTER[SSTU_ENGINES] block).  Granted, I have no idea what is needed for RO or how those patches are normally setup.

 

Edit:

I will take some time to look into this tomorrow prior to the release (in case I have to change anything).  Have been meaning to make an RO setup for awhile anyhow, so might as well get it set up and use it for testing   And knowing more about the setup can aid in development, to help with instances where I may unintentionally make things incompatible/difficult to setup.

 

Much appreciated!

Yeah, we probably don't need to delete the existing stock clusters rather than edit them anymore. I was just trying to make the best re-use of @JoseEduardo 's code, since it worked so well until recently.

Now is not the best time to take a look at the state of SSTU in RO, since I just came back around to discover most things are broken, and we haven't even started config'ing the new most recent wave of engines added. But you're more than welcome to try RO out

[Shadowmage]

First pass on RO configs, seems like it shouldn't be too hard to get things straightened out.  There are a lot of part changes and new parts that are just a matter of time to work through to apply the proper scales/naming/etc.  The engines and clusters seem like they shouldn't be too hard to sort out either.

First pass at engine clusters, after disabling the RO-cluster-deltion/creation patch -- a definition such as: @PART[SSTU_ShipCore_ENG-RS-25]:NEEDS[SSTU_ENGINES]:FOR[RealismOverhaul] will allow it to run sucessfully and apply to the default-cloned engine clusters.  The next step would be to run your engine-cluster description / mount size stuff in an :AFTER[SSTU_ENGINES] block (testing this now)

Next to investigate will be the change to the RL10's as I moved them over to use a standard ModuleEnginesFX engine module.  So these should be able to use similar patches to the other engines now.

RealPlumes -- I've added a default real-plumes patch for most parts to SSTU, so there is a choice to make here.  Either I can disable my default configs whenever RO is present (with a :NEEDS[!RealismOverhaul]) and you can use the existing RO configs, or you could run in a :AFTER[RealPlumes] block and modify the plumes that were added through my patches(untested).  RealPlumes patches seem to work fine if defined with :FOR[RealPlume]:NEEDS[SmokeScreen]:BEFORE[SSTU_ENGINES] -- this ensures they get added before the default clusters are created. (actually, as R is before S; you don't even need the BEFORE statement... it will automatically get ran in proper order due to sorting)

Will update shortly with a bit more info.

Edited January 16, 2016 by Shadowmage

[Shadowmage]

Okay, engine clusters were indeed quite easy to sort out:

Example of in-line patching:

https://github.com/shadowmage45/RealismOverhaul/commit/a531dbecd62fa0ac4885f10cb2a2c24b43507a05

This -also- fixes real-plume problems

I believe the :FINAL block is preventing real-plume/etc from adding its stuff properly

I'll see if I can clean up a bit more and perhaps submit a PR with what I have; should at least save you the work that I've already done and tested

 

[stratochief66]

On 1/9/2016 at 10:26 PM, 01010101lzy said:

+Issue

Orion SM (IN REALISM OVERHAUL) separates from the craft before loading into scene, and burns everything below it to explode shortly after loading, reporting debug error showed in pics below.

 

plus another issue in RO:

The SM starts its engine immediately after loading and overheats quickly.

 

You've got an old, out of date TACLS I bet. Old TACLS caused parts with TACLS modules (ie. LOX -> Air, Fuel Cells) to stage the part they were attached to at load. That stopped me from being able to use TACLS for many parts (including some in FASA) but it was fixed in the most recent TACLS release.

Edited January 16, 2016 by stratochief66

[stratochief66]

54 minutes ago, Shadowmage said:

First pass on RO configs, seems like it shouldn't be too hard to get things straightened out.  There are a lot of part changes and new parts that are just a matter of time to work through to apply the proper scales/naming/etc.  The engines and clusters seem like they shouldn't be too hard to sort out either.

First pass at engine clusters, after disabling the RO-cluster-deltion/creation patch -- a definition such as: @PART[SSTU_ShipCore_ENG-RS-25]:NEEDS[SSTU_ENGINES]:FOR[RealismOverhaul] will allow it to run sucessfully and apply to the default-cloned engine clusters.  The next step would be to run your engine-cluster description / mount size stuff in an :AFTER[SSTU_ENGINES] block (testing this now)

Next to investigate will be the change to the RL10's as I moved them over to use a standard ModuleEnginesFX engine module.  So these should be able to use similar patches to the other engines now.

RealPlumes -- I've added a default real-plumes patch for most parts to SSTU, so there is a choice to make here.  Either I can disable my default configs whenever RO is present (with a :NEEDS[!RealismOverhaul]) and you can use the existing RO configs, or you could run in a :AFTER[RealPlumes] block and modify the plumes that were added through my patches(untested).  RealPlumes patches seem to work fine if defined with :FOR[RealPlume]:NEEDS[SmokeScreen]:BEFORE[SSTU_ENGINES] -- this ensures they get added before the default clusters are created. (actually, as R is before S; you don't even need the BEFORE statement... it will automatically get ran in proper order due to sorting)

Will update shortly with a bit more info.

 

I'm still considering changing things from the <Delete Cluster -> Modify Singles -> Recreate Clusters with Modified Singles > process to a <Modify Singles and Modify Clusters> process, but again that feels like it will be a lot of work. I've poked @JoseEduardo a few times to see if he would help with that, since he created the original flow for reasons(?).

I would prefer if you include a :NEEDS[!RealismOverhaul] for the RealPlumes, but either way will probably work fine.

Anything you work out that might be usefully applicable to RO would be much appreciated as a PR.

1 hour ago, Shadowmage said:

First pass on RO configs, seems like it shouldn't be too hard to get things straightened out.  There are a lot of part changes and new parts that are just a matter of time to work through to apply the proper scales/naming/etc.  The engines and clusters seem like they shouldn't be too hard to sort out either.

First pass at engine clusters, after disabling the RO-cluster-deltion/creation patch -- a definition such as: @PART[SSTU_ShipCore_ENG-RS-25]:NEEDS[SSTU_ENGINES]:FOR[RealismOverhaul] will allow it to run sucessfully and apply to the default-cloned engine clusters.  The next step would be to run your engine-cluster description / mount size stuff in an :AFTER[SSTU_ENGINES] block (testing this now)

Next to investigate will be the change to the RL10's as I moved them over to use a standard ModuleEnginesFX engine module.  So these should be able to use similar patches to the other engines now.

RealPlumes -- I've added a default real-plumes patch for most parts to SSTU, so there is a choice to make here.  Either I can disable my default configs whenever RO is present (with a :NEEDS[!RealismOverhaul]) and you can use the existing RO configs, or you could run in a :AFTER[RealPlumes] block and modify the plumes that were added through my patches(untested).  RealPlumes patches seem to work fine if defined with :FOR[RealPlume]:NEEDS[SmokeScreen]:BEFORE[SSTU_ENGINES] -- this ensures they get added before the default clusters are created. (actually, as R is before S; you don't even need the BEFORE statement... it will automatically get ran in proper order due to sorting)

Will update shortly with a bit more info.

 

1 hour ago, Shadowmage said:

First pass on RO configs, seems like it shouldn't be too hard to get things straightened out.  There are a lot of part changes and new parts that are just a matter of time to work through to apply the proper scales/naming/etc.  The engines and clusters seem like they shouldn't be too hard to sort out either.

First pass at engine clusters, after disabling the RO-cluster-deltion/creation patch -- a definition such as: @PART[SSTU_ShipCore_ENG-RS-25]:NEEDS[SSTU_ENGINES]:FOR[RealismOverhaul] will allow it to run sucessfully and apply to the default-cloned engine clusters.  The next step would be to run your engine-cluster description / mount size stuff in an :AFTER[SSTU_ENGINES] block (testing this now)

Next to investigate will be the change to the RL10's as I moved them over to use a standard ModuleEnginesFX engine module.  So these should be able to use similar patches to the other engines now.

RealPlumes -- I've added a default real-plumes patch for most parts to SSTU, so there is a choice to make here.  Either I can disable my default configs whenever RO is present (with a :NEEDS[!RealismOverhaul]) and you can use the existing RO configs, or you could run in a :AFTER[RealPlumes] block and modify the plumes that were added through my patches(untested).  RealPlumes patches seem to work fine if defined with :FOR[RealPlume]:NEEDS[SmokeScreen]:BEFORE[SSTU_ENGINES] -- this ensures they get added before the default clusters are created. (actually, as R is before S; you don't even need the BEFORE statement... it will automatically get ran in proper order due to sorting)

Will update shortly with a bit more info.

I like to include the BEFORE statements so the ordering logic is explicit, rather than implicit (I don't like assuming someone reading the code will be fully aware of the MM ordering of operations including alphabetical order, since I'm not even well aware of all the ins and outs of MM ordering)

[Shadowmage]

@stratochief66

Give me a few hours, and I'll have a PR that sorts out all of the current engine patches.  Will still be lacking the newer engines (aj10-190/rs-68), but at least someone will have a good basis to go on as far as how to set them up.

I'll update realplumes on my end to -not- run when RO is installed... pretty easy for me to do that.  I'm sure the RO plumes have likely been tuned for the specific scales/etc, and its easier all around to only run the single patch on them.  I'll get the RO real-plumes stuff working as well with the upcoming PR. EDIT: Dependant upon the upcoming SSTU update with fixed realplumes patch of course...

Edited January 16, 2016 by Shadowmage

[stratochief66]

7 minutes ago, Shadowmage said:

@stratochief66

Give me a few hours, and I'll have a PR that sorts out all of the current engine patches.  Will still be lacking the newer engines (aj10-190/rs-68), but at least someone will have a good basis to go on as far as how to set them up.

I'll update realplumes on my end to -not- run when RO is installed... pretty easy for me to do that.  I'm sure the RO plumes have likely been tuned for the specific scales/etc, and its easier all around to only run the single patch on them.  I'll get the RO real-plumes stuff working as well with the upcoming PR. EDIT: Dependant upon the upcoming SSTU update with fixed realplumes patch of course...

Oh yeah, absolutely. That will be a Huge help.

Copying your style and adding the new engines will be a ton easier with what you're doing complete.

[Shadowmage]

@stratochief66

PR is up and available;  will be working on getting the updated SSTU release out here in the next couple of hours.  For now, for testing on your side, you can delete/disable the SSTU/RealPlumes patch if you need to.

Hopefully won't take too long, as its mostly going to be a bit of last minute testing and then packaging/posting/updating websites.

Edited January 16, 2016 by Shadowmage

[Shadowmage]

Updated testing release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.3.26-pre4

Several texture updates, a few config fixes/changes, and a few new features and improvements... check out the link for full change-log and download links.

 

Edit: -- Might be another release later today / tomorrow with improvements to the interstage decoupler (dynamic mass and thrust settings, cleaned up effects, maybe an attempt at balancing it versus other current part configs).

Edited January 16, 2016 by Shadowmage

[stratochief66]

The PR looks excellent. You seem to have picked up 95% of what I had been aiming at last night, and fixed it up into the superior style of modifying the original clusters, and extended it to all the engines that had already been RO'd to boot. So, basically what would have taken me a week or so of free time.

I'm be merging it shortly.

[Jimbodiah]

The new C series is not in there

[ComatoseJedi]

3 minutes ago, Jimbodiah said:

The new C series is not in there

I was going to say the same thing, but I figured that it wasn't supposed to be in there. 

[Jimbodiah]

Mage, did you see this thread and how it animates?

http://forum.kerbalspaceprogram.com/index.php?/topic/127810-wip-dangerously-shaded-stock-refresh/&page=2

[Shadowmage]

42 minutes ago, Jimbodiah said:

The new C series is not in there

Noted;  I've removed those lines from the patch notes.  Apparently I left those part config files in my dev folder (which doesn't get copied for packaging)... but no big loss, as they're not finished, and are supposed to be part of the next release version anyways.  Maybe I'll sneak them into the balance update tomorrow.