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

[Shadowmage]

15 minutes ago, Jimbodiah said:

Just keep it in the same folder and make it possible for people to delete the directory of parts they don't need. Keep unique textures with the part, all the shared on in one folder (=take it or leave it). Don't make more work unless it;s really necessary. I can see landers being a seperate package, unless it will share engines etc with Shipcore.

LanderCore will eventually be sharing engine, RCS, and 'general' models/textures (landing gear, modular swappable part stuff) with the rest of the part packs.  Even the fuel tanks will be redone to be a more generic setup (more on that below).  About the only unique parts that it will have would be the pods.

The eventual plan for that set of parts is to rework the lander-core fuel tanks into a single-part modular tank setup (similar to the MFTs), with some additional support for the module/model swapping that it currently uses (and will likely be adding some module swap to the other tanks as well... so that you could add landing legs, retro rockets, parachutes, etc to the MFTs as needed).  Those are long-term plans though, still have a few things to figure out regarding the module swapping (plan on working on that as soon as the 1.1 update is finished and the mod starts to have 'stable' releases).

Things will becoming even more interlinked and integrated in the future.  So, considering the extra work-load that would be required, and 1.1 coming (hopefully) with 64-bit support -- probably not the best idea to split the mod up (and certainly not easy to manage it even if I did).

What I can do though, is provide a list of what each model/texture is for (documentation) -- which would make it easier for people to decide what they needed to keep when they were trimming things out.  Would likely just be an excel file (or just plain text...) with a list of model/texture names, and what parts they are used in.

[JoseEduardo]

so... is there any good reason to split the pack at all? from what you describe it seems that there is no good in splitting it other than reducing part list...

[tater]

Yeah, do what is easiest for you to deal with, but if it is possible to have a shared textures folder, then people can simply delete the SC-e folder if they don't want Shuttle, etc.

[Jimbodiah]

Textures aren't loaded unless a cfg calls them, isn't that right? What would there be to gain if there are unused textures in the SSTU directory? You only need to remove the part's cfg file to not load it into KSP.

[Sudragon]

<shrug> I've started chopping squad parts to help SSTU fit. 

[Jimbodiah]

gheghe... What squad parts?     I dumped almost every stock engine in tank, only the Nerv and the Thudder left.

Edited March 10, 2016 by Jimbodiah

[Shadowmage]

50 minutes ago, JoseEduardo said:

so... is there any good reason to split the pack at all? from what you describe it seems that there is no good in splitting it other than reducing part list...

Yah, the more I think on it, the fewer reasons I can find to actually do it; and none of them compelling or useful to me personally.

There was only ever two reasons to do it
1.) Part-list count bloat (mostly from the engine clusters, which is no longer an issue).  Not a problem in 1.1 with its search feature.
2.) Memory use reduction from fewer textures/models being loaded.  -Mostly- not a problem in 1.1 with 64-bit, though that also depends on if they use dynamic gfx texture uploads or just upload them all (hopefully the former).

 

14 minutes ago, Jimbodiah said:

Textures aren't loaded unless a cfg calls them, isn't that right? What would there be to gain if there are unused textures in the SSTU directory? You only need to remove the part's cfg file to not load it into KSP.

Textures are loaded regardless -- all textures and models in GameData are loaded whether they are referenced by a part or not -- otherwise I could not use the tank texture variants or the decal variants for the shuttle, as only a single one of each is referenced by a part.

 

 

 

On a bit of good news -- I've finally squashed the longest standing bug from the issues list:
#10 - Procedural Modules - Stock part highlighting works inconsistently (shadowmage45 opened this Issue on Sep 4, 2015)

With a bit of insight from xEvilReeperx on a workaround for the stock coding, I now have some code in place that will fix the in-editor highlighting for modular parts when you change models. 

So the MFT tanks, MUS tanks, engine-clusters, and procedural decoupler should all now have proper highlighting in the editor   (already worked in flight).

 

[tater]

Is there a reason not to set maxAmount = for Ablator higher for the reentry modules? I mean for the mod in general, as I have done this on my own copy. The part then still defaults to your stock-balanced version, and should anyone bump up the value in the VAB, they do pay a mass penalty. This makes the mode friendly to the sub-RSS rescales.

Edited March 11, 2016 by tater

[Jimbodiah]

[Shadowmage]

Updated testing release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.3.29-pre11.2

Mostly bug-fixes and enhancements, as usual see the link for full change log and downloads.

Edit -- found and squashed a game-breaker involving the highlight fixer and symmetry parts (always the symmetry causing problems...); will be uploading a ninja-patch shortly.  If you have downloaded the above version prior to my next post, please re-download.

Edited March 11, 2016 by Shadowmage

[Shadowmage]

Ninja-patch re-release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.3.29-pre11.2

Fixes part-breaking bug with highlighting fix, also fixes MFT symmetry parts having duplicate models in the editor.

Edited March 11, 2016 by Shadowmage

[RedParadize]

Looks cool. 

Quick question, how to tweak heatsheild value to work in 64k? Is there a easy way to multiply values?

Edit:
hehehe SSTU-E-WL have a rescaleFactor = 18 !

Edit 2:
Geting NullReferenceExeption spam with a Shuttle FSX. First time when I was building it. Restarted and it did it again after reverting to hangar. After Null spam, RCS are active in VAB.

Edited March 11, 2016 by RedParadize

[StickyScissors]

ahhhg, this mod just keeps getting better and better! I cant wait for 1.1 to come out, and this mod to "settle down" after the first actual release so i can finally be let loose with all the designs i've been drawing

[Shadowmage]

One more quick fix:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.3.29-pre11.2

Fixes the scale factor for the SC-E-WL

1 hour ago, RedParadize said:

Looks cool. 

Quick question, how to tweak heatsheild value to work in 64k? Is there a easy way to multiply values?

Edit:
hehehe SSTU-E-WL have a rescaleFactor = 18 !

Edit 2:
Geting NullReferenceExeption spam with a Shuttle FSX. First time when I was building it. Restarted and it did it again after reverting to hangar. After Null spam, RCS are active in VAB.

 

Logs ?

Edited March 11, 2016 by Shadowmage

[Shadowmage]

1 hour ago, RedParadize said:

Looks cool. 

Quick question, how to tweak heatsheild value to work in 64k? Is there a easy way to multiply values?
 

No idea if it is possible to scale a FloatCurve with MM; I've always replaced them wholesale.  I know you can do it for vectors (recent feature addition), but have never tried curves.

I'll consider putting in a 'scale' modifier in the plugin itself.... but I have no idea how heat actually scales with rescale factor.  Is it linear, exponential, logarithmic, ???  Would need to have good info on this to know how to best implement the scale value.

[blowfish]

1 hour ago, RedParadize said:

Quick question, how to tweak heatsheild value to work in 64k? Is there a easy way to multiply values?

Just turn down re-entry heating.  It's simpler than trying to make a patch that works with every rescale mod.  Stock heating is scaled way up to make it work in a tiny solar system anyway.

[Sudragon]

Mage, could you look at the Radial Booster Decoupler? the code controlling the maximum diameter seems to be a little bent. All the other adjustable parts are correctly maxing out at 2.5 m, whereas the decoupler seems to be stuck at 1.25m 

[blowfish]

21 minutes ago, Sudragon said:

Mage, could you look at the Radial Booster Decoupler? the code controlling the maximum diameter seems to be a little bent. All the other adjustable parts are correctly maxing out at 2.5 m, whereas the decoupler seems to be stuck at 1.25m 

https://github.com/shadowmage45/SSTULabs/issues/258

[Sudragon]

Ah, right. sorted then.

[MrMeeb]

7 hours ago, RedParadize said:

Looks cool. 

Quick question, how to tweak heatsheild value to work in 64k? Is there a easy way to multiply values?

Edit:
hehehe SSTU-E-WL have a rescaleFactor = 18 !

Edit 2:
Geting NullReferenceExeption spam with a Shuttle FSX. First time when I was building it. Restarted and it did it again after reverting to hangar. After Null spam, RCS are active in VAB.

I found using RealHeat makes the stock heat shields work. Seeing as similar values are used on SSTU, I'd give that a go  

[TonyC]

Is it compatible with SMURFF ? Thanks !

[Sudragon]

Hmm, I must have busted something. I have 3.75m tanks (Large Volume Containment) unlocked, and now my radial decoupler can do 1.85m, while all the in-line ones can reach 3.75. It's interesting.

[JoseEduardo]

54 minutes ago, MegaUZI said:

Is it compatible with SMURFF ? Thanks !

AFAIK SMURFF is compatible with anything, the only need for a SMURFF patch is to remove support for it (like Real Boosters, which are already real-sized rockets)

[Shadowmage]

1 hour ago, Sudragon said:

Hmm, I must have busted something. I have 3.75m tanks (Large Volume Containment) unlocked, and now my radial decoupler can do 1.85m, while all the in-line ones can reach 3.75. It's interesting.

Likely that the TechLimits stuff for those has not been tested yet

Will investigate to see what is causing the discrepancy, they should all (currently) have the same diameter limits in career mode.

[Shadowmage]

15 hours ago, tater said:

Is there a reason not to set maxAmount = for Ablator higher for the reentry modules? I mean for the mod in general, as I have done this on my own copy. The part then still defaults to your stock-balanced version, and should anyone bump up the value in the VAB, they do pay a mass penalty. This makes the mode friendly to the sub-RSS rescales.

Each pods' integrated heat-shield has been carefully balanced for its intended purpose regarding heat load and ablator use.  The SC-C should explode if re-entering from Mun/Minmus; the SC-A should be -just- enough for Mun/Minmus but not quite enough for interplanetary. Just upping the ablator amount should -not- make them any more capable of re-entering at larger scale systems -- if it does, then I have failed in my balance of the heat-shield module, and will need to go back over it again.  The lighter pods' shields just can't take the higher heat-load of higher-speed re-entries (they should overheat and explode even though they still have ablator left; simulating burn-through or boundary separation).  Rescale systems will -need- patches to the heat statistics of the heat shield.  The ablator amount should not change unless you are rescaling the enitre pod, where it should maintain a constant mass fraction with the pods new mass.

In short: Upping the ablator resource should do you absolutely no good as far as countering higher heat-loads; all it should do is add more mass to the pod and enable it to take the -same- heat load for a longer period of time (which does no good).  You will need to patch the heatCurve and ablationEfficiency in order to balance those parts for rescaled systems.

 

However, this might be changing a bit in the near future if I can get this modular heat-shield stuff working well; this is the module that will drive the customizable/modular heat-shield parts, but might also be usable on other heat-shield equipped parts.  One of its neat little 'functions' is the ability to change the heat shield type from 'Light' (LKO), to 'Medium' (HKO), to Heavy (kerbin SOI), to 'ExtraHeavy' (Interplanetary) types;  these types all have their own ablation/heat/mass/resource curves so there can be quite a bit of variance between the different types as far as statistics are concerned.  They all use the same visible model (for now)

I'm debating whether or not to add this onto the pods themselves to allow for swapping of the heat-shield types.  Want to use SC-B for LKO and not pay the mass penalty for the 'Heavy' heat-shield?  Swap it for a 'light' one...problem solved   Want to use the SC-C for Mun return (LK?) -- swap it shield type to 'Heavy' and you should be good to go.

 

TL;DR -- Heat shields are not all created equal, and I am attempting to integrate this into the balance of the parts.