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

[ComatoseJedi]

33 minutes ago, Jimbodiah said:

Radial engines would come in handy for dropping rovers

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]

2 hours ago, 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.

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]

18 hours ago, 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.

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]

16 hours ago, 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; } }

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]

43 minutes ago, 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.

 

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]

1 minute ago, 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?

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]

20 minutes ago, 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.

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]

5 minutes ago, 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.

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]

18 minutes ago, 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.

You pulled it and it fixed the problems?

 

[Shadowmage]

21 minutes ago, 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.

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]

1 minute ago, 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

 

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]

4 hours ago, Shadowmage said:

Preferences on skeletal-adapter truss layout/geometry?

 

Another vote for the middle one.

[rasta013]

4 hours ago, Shadowmage said:

 

Preferences on skeletal-adapter truss layout/geometry?

 

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 13/06/2016 at 7: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?

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]

11 hours ago, 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

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.

13 hours ago, 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?

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]

Just now, 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.

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]

3 hours ago, 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).

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