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

[ComatoseJedi]

  On 6/12/2016 at 9:32 PM, Jimbodiah said:

Radial engines would come in handy for dropping rovers

Expand  

very true, but the stock one works just as well, especially if you are using tweakscale. And if I really need to drop something heavy, I can opt for a radial engine mount. 

[chrisl]

  On 6/12/2016 at 9:41 PM, Shadowmage said:

Thanks for the info; I was not aware RealFuels was compatible with base resources in the part.

I'll take a look over the code to make sure the CustomUppperStage module isn't deleting/clearing out resources; it very well might be, and that would explain what you are seeing.

Expand  

Got another question for you.  We are resizing the landers for RO which was easy enough.  But now I'm trying to resize the ascent tanks.  I saw that in Model subsection in SSTUModelSwitch there is a "scale" value.  I used that to resize the tanks which worked fine.  Except that it seems when I use that scale value, it changes the volume as well as the graphic.  I've verified this is what's happening by removing the scale value.  With "@scale = 1.333333" in place, the total volume with the ascent tanks active becomes 5.74kL.  Without that scale change, the volume is correctly set to 3.0kL.  I'm not sure if this is something coming from RealFuels or if SSTU is designed to intentionally have that scale alter the volume.  What I'm really after, though, is whether there is another way to alter the size of the ascent tanks from within SSTUModelSwitch. 

 

EDIT: Ok.  I understand why my resulting volume is changed when I use a scale value.  It looks like ModelSwitchData portion of SSTUModelSwitch.cs is taking scale^3 times the volume.  I'll have to work around that. 

public float volume { get { return Mathf.Pow(scale, 3) * modelDefinition.volume * 1000f; } }

Edited June 13, 2016 by chrisl

[StickyScissors]

  On 6/12/2016 at 12:19 PM, Qwarkk said:

Done more than test a landing, my whole space program is based on it. Works a charm with a 2.5m Falcon-based rocket. You just need to work out a procedure to have sufficient fuel and TWR for a landing burn.

Expand  

After a few hours of testing...i can't figure it out. TWR ends up at about 1.10, resulting in a hoverslam that burns through all of the ~400m/s that i have in a reserve tank.

Adding more fuel lowers the TWR that still burns through it all before slamming into the dirt.

Taking away some fuel increases TWR to 1.14, but lowers DV, still slamming me into the dirt.

How have you managed it? Smaller launcher?

[Jimbodiah]

moar boosters!

[Shadowmage]

  On 6/12/2016 at 10:13 PM, chrisl said:

Got another question for you.  We are resizing the landers for RO which was easy enough.  But now I'm trying to resize the ascent tanks.  I saw that in Model subsection in SSTUModelSwitch there is a "scale" value.  I used that to resize the tanks which worked fine.  Except that it seems when I use that scale value, it changes the volume as well as the graphic.  I've verified this is what's happening by removing the scale value.  With "@scale = 1.333333" in place, the total volume with the ascent tanks active becomes 5.74kL.  Without that scale change, the volume is correctly set to 3.0kL.  I'm not sure if this is something coming from RealFuels or if SSTU is designed to intentionally have that scale alter the volume.  What I'm really after, though, is whether there is another way to alter the size of the ascent tanks from within SSTUModelSwitch. 

 

EDIT: Ok.  I understand why my resulting volume is changed when I use a scale value.  It looks like ModelSwitchData portion of SSTUModelSwitch.cs is taking scale^3 times the volume.  I'll have to work around that. 

public float volume { get { return Mathf.Pow(scale, 3) * modelDefinition.volume * 1000f; } }

Expand  

Indeed; the volume specification is for the unscaled volume for the model.  You should not need to change that from whatever was originally specificed; its a 'calculate manually once, use everywhere' value.  It is intended that you use the value specified by the 3d modeling program here, and let the scaling take care of scaling the volume properly.  The only time this would not work out right is if you are trying to also change the volume unrealistically; in which case you will need to do some backwards conversions to derive the 'unscaled' volume that should be entered for a desired 'scaled' volume outcome.

 

On the note of your other problem, of resources being removed from the part; it does not appear to be coming from SSTU code, but it may well be coming from RealFuels-ModularFuelTanks:

https://github.com/NathanKell/ModularFuelSystem/blob/master/Source/Tanks/ModuleFuelTanks.cs#L144-L162

I have verified that there is nothing in the SSTUCustomUpperStage module that would be removing resources; in fact the -only- place in SSTU code that does it is in the SSTUVolumeContainer module, so as long as that module is being removed it cannot be being caused by SSTU code/modules.

 

[chrisl]

  On 6/13/2016 at 2:45 PM, Shadowmage said:

Indeed; the volume specification is for the unscaled volume for the model.  You should not need to change that from whatever was originally specificed; its a 'calculate manually once, use everywhere' value.  It is intended that you use the value specified by the 3d modeling program here, and let the scaling take care of scaling the volume properly.  The only time this would not work out right is if you are trying to also change the volume unrealistically; in which case you will need to do some backwards conversions to derive the 'unscaled' volume that should be entered for a desired 'scaled' volume outcome.

 

On the note of your other problem, of resources being removed from the part; it does not appear to be coming from SSTU code, but it may well be coming from RealFuels-ModularFuelTanks:

https://github.com/NathanKell/ModularFuelSystem/blob/master/Source/Tanks/ModuleFuelTanks.cs#L144-L162

I have verified that there is nothing in the SSTUCustomUpperStage module that would be removing resources; in fact the -only- place in SSTU code that does it is in the SSTUVolumeContainer module, so as long as that module is being removed it cannot be being caused by SSTU code/modules.

 

Expand  

It's not so much that I am aiming for unrealistic volumes.  It's that I had to resize the tanks to match the resized landers.  And the landers were resized so that the docking port matched the port on the Orion which was in turn resized to match the known size.  After resizing everything, I was then trying to list what the newly sized lander/tanks could carry.  Have it all resolved now, though.  Thank you for the assist there.

As for the RESOURCE thing, ok.  I'll double check that SSTUVolumeContainer is being removed (though it should be since that's happening with your RF.cfg patch) and I'll check with Nathan to see if he has any idea why the RESROUCE isn't working.  Again, thank you for the help.

[Jimbodiah]

Regarding the engine FX showing while eniges are off...  I have the same effect even without Contares (also no RealPlume) that the RS68 shows all three flames as if firing at max power, while it is not firing. Also often times the sound will not play. Want logs?

[Shadowmage]

  On 6/13/2016 at 7:19 PM, Jimbodiah said:

Regarding the engine FX showing while eniges are off...  I have the same effect even without Contares (also no RealPlume) that the RS68 shows all three flames as if firing at max power, while it is not firing. Also often times the sound will not play. Want logs?

Expand  

Seeing as how it is more than likely an error in another mods' RealPlumes patches.... not really.  You'll have to find whichever mod has setup their RealPlumes patches incorrectly and report it to that mods' issue tracker.  There is nothing that I can (or should) do on my end to fix the problem.

If you need help figuring out what mod that is... I might be willing to take a look; but I would need a log that shows all the patches being applied (e.g. launching KSP after deleting the MM cache).

[Shadowmage]

Preferences on skeletal-adapter truss layout/geometry?

Leaning towards the middle one personally; has the parallel trusses at 90' angles which will fit well when put on top of the skeletal bays, and has enough trussing to be 'busy' looking but not 'too busy'.

Any preferences on these (or other alternate layouts?)

Pretty much I just need to figure out the adapter truss geometry, and the skeletal cargo bays will be ready for unwrap/texturing.  Pretty simple/straightforward parts for UV mapping and texturing... really it is just figuring out the initial geometry that will be the 'hard' part.

Might also make a few other skeletal varieties/shapes of trusses/cargo bays... octagonal and hexagonal... though I'm a bit unsure on those yet; not sure if I want to make them geometrically proper, or make them line-up/fit with the Near-Future and USI parts (probably the latter, would rather have compatibility I think).

[Jimbodiah]

  On 6/13/2016 at 7:23 PM, Shadowmage said:

Seeing as how it is more than likely an error in another mods' RealPlumes patches.... not really.  You'll have to find whichever mod has setup their RealPlumes patches incorrectly and report it to that mods' issue tracker.  There is nothing that I can (or should) do on my end to fix the problem.

Expand  

Hmmm, weird as it's never done this before, but have had all sorts of crap with mods this week, maybe some updates... I'll check which mods have RP patches, should not be many.

[Shadowmage]

  On 6/13/2016 at 8:00 PM, Jimbodiah said:

Hmmm, weird as it's never done this before, but have had all sorts of crap with mods this week, maybe some updates... I'll check which mods have RP patches, should not be many.

Expand  

Like I said in my last post; if you want to link a log file that has all the patch-building stuff in it (just delete the ModuleManager cache files and launch KSP), I can probably find out in short order what mod(s) are causing the problem.

Alternatively, you can do the same... merely search in the log file for anything that is using a FOR[RealPlume] patch setup; that will be your culprit.

The only patches that should ever use a FOR block are patches that ship -with- a specific mod.  E.G.  I can use a FOR[SSTU] block safely, because my mod -is- SSTU;  if anyone else uses a FOR[SSTU] setup, it will trick ModuleManger into thinking SSTU is installed even when it is not.

[Jimbodiah]

Found it... Octosat had the only RP patch and it does indeed use FOR. I'll tell him about it, but don't know why I've never seen it before.

[MrMeeb]

I like the middle one!  

[Sudragon]

  On 6/13/2016 at 8:41 PM, Jimbodiah said:

Found it... Octosat had the only RP patch and it does indeed use FOR. I'll tell him about it, but don't know why I've never seen it before.

Expand  

You pulled it and it fixed the problems?

 

[Shadowmage]

  On 6/13/2016 at 8:41 PM, Jimbodiah said:

Found it... Octosat had the only RP patch and it does indeed use FOR. I'll tell him about it, but don't know why I've never seen it before.

Expand  

Yah, it seems common for RP patches to use the FOR syntax... as that it what it (incorrectly) states to do in the RealPlumes tutorial.  So I can't exactly blame those guys... the instructions really need to be fixed to state that you can only use the FOR syntax when you are shipping RealPlumes as a dependency.

[Bruffandino]

I have a problem with the Apollo Docking system. After a quickload, the undock button disappears, and there's no other way to undock. Any ideas? I'm running RO. Let me know if any log might help.

Thanks!

 

Marco

[Shadowmage]

  On 6/13/2016 at 9:41 PM, Bruffandino said:

I have a problem with the Apollo Docking system. After a quickload, the undock button disappears, and there's no other way to undock. Any ideas? I'm running RO. Let me know if any log might help.

Thanks!

 

Marco

Expand  

 

I do not use or offer any support for RO, sorry; you will need to ask in the RO thread for support with RO:

 

[Guest]

  On 6/13/2016 at 7:42 PM, Shadowmage said:

Preferences on skeletal-adapter truss layout/geometry?

Expand  

 

Another vote for the middle one.

[rasta013]

  On 6/13/2016 at 7:42 PM, Shadowmage said:

 

Preferences on skeletal-adapter truss layout/geometry?

 

Expand  

Yah.  Middle one is the winner of those three.  I like the one on the left as an alternative to that one.

[chrisl]

I like the middle one as well.

Got another question about SSTUModelSwitch.  I see that when you switch between models, it automatically changes the quantity of existing supplies.  Is there a way to turn that off so that whatever amount the player sets remains constant when you change models?

[JoseEduardo]

are these just for adapters or can they become semi-procedural interstages like the soviet ones later on?

I like #1 (mainly because it reminds me a bit of N-1 and Proton interstages) and #2

#3 looks kinda fragile

[Qwarkk]

  On 6/13/2016 at 6:51 AM, StickyScissors said:

After a few hours of testing...i can't figure it out. TWR ends up at about 1.10, resulting in a hoverslam that burns through all of the ~400m/s that i have in a reserve tank.

Adding more fuel lowers the TWR that still burns through it all before slamming into the dirt.

Taking away some fuel increases TWR to 1.14, but lowers DV, still slamming me into the dirt.

How have you managed it? Smaller launcher?

Expand  

My designs use gridfins from the launchers mod pack which slow it down (aerobrakes are a good stock alternative), and both use more than 400m/s for landing.

Looking at your earlier post with your falcon 9, i'd recommend that you check whether you really need 9 merlins. (bearing in mind 8 of them only add mass during the landing). If you use Kerbal Engineer, use as many merlins as you need for a TWR of 1.3-1.5 on the pad, no more.

[Shadowmage]

  On 6/14/2016 at 3:04 AM, JoseEduardo said:

are these just for adapters or can they become semi-procedural interstages like the soviet ones later on?

I like #1 (mainly because it reminds me a bit of N-1 and Proton interstages) and #2

#3 looks kinda fragile

Expand  

Just adapters; there is no way to do procedural stuff with these.

I do have plans for a model-switchable decoupler, but it would be a standard decoupler (e.g. no retrorockets), and no idea if/when I'll ever make it.

  On 6/14/2016 at 12:53 AM, chrisl said:

I like the middle one as well.

Got another question about SSTUModelSwitch.  I see that when you switch between models, it automatically changes the quantity of existing supplies.  Is there a way to turn that off so that whatever amount the player sets remains constant when you change models?

Expand  

SSTUModelSwitch doesn't touch resources at all; if you have already removed the SSTUVolumeContainer, then whatever you are seeing is being done by RealFuels/ModuleFuelTanks and nothing that I can control.

^^^ That was one of the main reasons I made my own fuel-switching setup (SSTUVolumeContainer); so that it could handle dedicated tanks for specific resources (e.g. life-support or rcs fuel) while allowing other portions of a parts' volume to be user-configurable (e.g. the rest of the fuel tank).

[JoseEduardo]

  On 6/14/2016 at 2:50 PM, Shadowmage said:

Just adapters; there is no way to do procedural stuff with these.

I do have plans for a model-switchable decoupler, but it would be a standard decoupler (e.g. no retrorockets), and no idea if/when I'll ever make it.

Expand  

np, AFAIK RL truss decouplers doesn't either

if you can add "segments" (i.e. the first one would be a 2 segment decoupler) and diameter scaling that would be enough to have russian/soviet-alike decouplers

[chrisl]

  On 6/14/2016 at 2:50 PM, Shadowmage said:

SSTUModelSwitch doesn't touch resources at all; if you have already removed the SSTUVolumeContainer, then whatever you are seeing is being done by RealFuels/ModuleFuelTanks and nothing that I can control.

^^^ That was one of the main reasons I made my own fuel-switching setup (SSTUVolumeContainer); so that it could handle dedicated tanks for specific resources (e.g. life-support or rcs fuel) while allowing other portions of a parts' volume to be user-configurable (e.g. the rest of the fuel tank).

Expand  

Thank you for the info.  I'll check with NathanKell and see if he has a suggestion.