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

[RedParadize]

Thank you allot, really appreciated. 

Fun fact: SSTU is almost always listed first in Dev tread. That show how well you support your stuff I think. It will be a bomb when you release it I think.

[Shadowmage]

Updated testing release is available:

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

Mostly bugfixes and config changes, but includes the prototype of the interstage decoupler part (functional, but no texture and plugin is still missing a few things).  As usual, see the link for the full change-log and download links.

[Shadowmage]

I think I've got the RCS figured out for the SC-C parts -- someone informed me that the skirt RCS are pitch/yaw controls, and point pretty much directly away from the skirt.

So... will probably have those parts available in prototype form for this weekends update.

 

Better yet, I figured out how to get multiple ModuleRCS on the same part to work properly.  So I can retrofit this onto the SC-B-SM to make it much less of a pain in docking/fine manuevers.  Not sure when I'll get that done, but likely soon.

 

[blowfish]

44 minutes ago, Shadowmage said:

Better yet, I figured out how to get multiple ModuleRCS on the same part to work properly.

Is it just transforms with different names, or something more complicated?

EDIT: just saw your thread on this.

Edited January 14, 2016 by blowfish

[Jimbodiah]

Awesome work, Mage!!! will test it tomorrow.

Can't wait to see the new ullage decoupler and the soyuz this weekend. Exciting stuff!!!

[RedParadize]

20 minutes ago, Jimbodiah said:

Awesome work, Mage!!! will test it tomorrow.

Can't wait to see the new ullage decoupler and the soyuz this weekend. Exciting stuff!!!

Soyuz this weekend ?

[Jimbodiah]

The 1.875 C series is a Soyuz.

[Shadowmage]

Indeed:

Doing some in-orbit testing of the RCS setup (which works wonderfully now )

Still working on finishing up some details on the models, and of course they still need uv unwrap/bake/texturing, but they are mostly usable in my dev setup.  So the prototypes will likely be available while I'm finishing up the ullage motors and other WIP stuff. 

[Jimbodiah]

Will it get the LAS as well?

[cy-one]

I'm trying to use a "reduced" package of this (just the LC-parts) and fail miserably in loading the "stock" LC-crafts, because "SSTU.ShipCore.B.DP" is missing.

Tried to find that part for half an hour now... Where the frack do I find that part, so I can install it as well?

[Shadowmage]

16 hours ago, Jimbodiah said:

BTW, will the soyuz get re-entry braking rockets as well?

 

Probably not; they are really not needed in KSP as parachute landing speeds are acceptable.  I've thought about them a bit, and the main problems keeping me from implementing them would be staging/activation of the engine module (unsure if engines can be removed from staging the same way that decouplers/etc can), and there does not exist any stock mechanism for triggering them properly and reliably.

9 hours ago, Jimbodiah said:

Will it get the LAS as well?

Yes

2 hours ago, cy-one said:

I'm trying to use a "reduced" package of this (just the LC-parts) and fail miserably in loading the "stock" LC-crafts, because "SSTU.ShipCore.B.DP" is missing.

Tried to find that part for half an hour now... Where the frack do I find that part, so I can install it as well?

Those craft files are outdated, and that is why they are no longer included with the distributions.

That particular part has been removed / replaced by a new docking port.  If you were -really- intent on getting them working, you could download one of the 0.3.25 releases and grab the parts from there.... but I won't be offering any support beyond those simple instructions.

In short -- this mod does not currently ship any .craft files, and any previous .craft files are out-of-date and are not expected to be usable.

[Shadowmage]

11 hours ago, blowfish said:

Is it just transforms with different names, or something more complicated?

EDIT: just saw your thread on this.

1.) Different named transforms for each module (common sense.. but heh, definitely step 1)

2.) fxPrefix needs to be set to a unique name for each module -- this fixes the thruster effects being grabbed/used by the wrong module

3.) enableXXX fields for the ModuleRCS control what inputs that module responds to.  Can disable any specific rotation or translation input, leaving only those that the particular thruster should be used for.

Pretty simple now that I've worked through all the steps   Also pretty sure that this capability did not exist in <=1.04, as I don't remember seeing most of those fields last I looked through the module definition.

 

This setup allowed me to make the rear-skirt RCS on the series-c only respond to pitch/yaw rotation inputs (as they do in real life), leaving only the mid-section RCS responding to translation and roll inputs.  Overall a much more balanced, and very acceptable, RCS setup.

Will be able to do similar to the series-b service module as well; having the lower RCS blocks only respond to certain inputs.

 

[RedParadize]

that sound insanely usefull. would it not be possible to have toggle in RCS to respond only to specifc axis/trans ingame?

Edited January 14, 2016 by RedParadize

[Jimbodiah]

Mage, want me to maintain some ships for you? Just some basic landers and launchers.

[Nertea]

1 hour ago, Shadowmage said:

2.) fxPrefix needs to be set to a unique name for each module -- this fixes the thruster effects being grabbed/used by the wrong module

 

Does that at all mean that custom FX is possible now?

[blowfish]

6 minutes ago, Nertea said:

Does that at all mean that custom FX is possible now?

fxPrefix is just an integer that assures that all the FX groups have unique indices.  But there is a field specifying the fx prefab name ... I forget exactly what it's called.

[Shadowmage]

5 minutes ago, blowfish said:

fxPrefix is just an integer that assures that all the FX groups have unique indices.  But there is a field specifying the fx prefab name ... I forget exactly what it's called.

fxPrefix is actually a string value, but you could likely use ints/numbers for it

 

13 minutes ago, Nertea said:

Does that at all mean that custom FX is possible now?

I believe so:

[KSPField]
public string fxPrefabName;

Should allow you to specify the prefab;  I've no clue what -type- of fx prefab it uses, but it appears to be possible now.

[Jimbodiah]

That would mean no more 2D rcs plume

But check out WIldBlue DSEV, he had LH2 RCS thrusters with his own custom plumes as well (purple).

[blowfish]

8 minutes ago, Shadowmage said:

fxPrefix is actually a string value, but you could likely use ints/numbers for it

Huh.  I remember seeing that it was added to an index, but I might be remembering incorrectly.

[Jimbodiah]

I'm trying to make a LS patch for the Lander Cans, but the resources do not show up for some reason. Double checked the names, but it's not being added. Any guesses?

[Shadowmage]

18 minutes ago, Jimbodiah said:

I'm trying to make a LS patch for the Lander Cans, but the resources do not show up for some reason. Double checked the names, but it's not being added. Any guesses?

Yep - its not going to work for those parts, as they already use resource swapping to enable the 'ascent fuel tanks' variants -- as such, the plugin driving them overwrites the resources to set it properly for the ascent tanks.  There is no current proper solution.  This is one of the main reasons I've scheduled those parts for a rework.  So, until then, you wont be able to add other resources to them.

[Jimbodiah]

Well I could, but it would be in the file itself and have both patches in each resource config. Yeah, no...

I'm making a few example landers for Mun and Duna based on each pod, if you want to put them in your mod as .crafts. These things are impossible to dock to anything unless the other ship docks to the LC. May I do a PR to change SAS and RCS power levels to tone them down a bit? SAS is huge (15) for such small cans and it oscilates in combination with RCS. It's only until you redo them completely, but it will make them a bit more playable in the meantime.

[Shadowmage]

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.

[Jimbodiah]

Nah Mage, don't worry, that's a lot of text to add for just LS and on temporary basis. Don't stick too much time into it.

The ullage is great, tested it on about 10 flights with some setting and once you get the hang of the GUI (and don't place the decoupler upside down, ahem) then it works as intended so far as I can see. I will test with some light rockets in a bit, trying to make a duna lander and then a new Jupiter III build (also using the decoupler). Will post results when I have done some flights in those. I have an extremely light and and extremely heavy scenario that way.

[Shadowmage]

Good to know regarding the model; will get it finished up shortly.

Re: exploding stages -- yah, I need to 1.) adjust thrust transforms a bit more outwards, and/or 2.) disable damage for the engine module.  I had a few lower-stages get exploded when I used it as an ullage engine, due to the rotational difference in the stages after decoupling (ullage rockets roasted the lower stage).