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

[Shadowmage]

Think I've settled on the overall geometry layout for the DOS modules (there were quite a few changes...).  Generally they are all now based on the core FGB block, with different external bits and accessories.  The FEM is now based on the TKS module, but with a bit of a dome/bubble at the top (which will be covered in windows).  Swapped out the RCS for the 6-port model, added EVA hatches to all parts, finalized solar-panel positions.

I've decided to not do the cloth covered look.  Was a painful modeling process trying to get smooth shading done properly on those shapes, would have been much higher poly count, and I'm not convinced it would have looked very good in the end.

From left to right: PWR - COM - HAB - LAB - STR - FEM - TKS
Retracted solar panels:

Extended solar panels:

 

 

About the only undecided bits on these modules are:

1.) Tanks or covered blocks?  E.g. should I show the tanks underneath the radiators, or make them solid blocks?
2.) Windows?  Each module will likely have at least one opposite the hatch.
3.) Built-in antenna?  (room opposite the hatch on most parts)

(Have been trying to get the DOS modules to a stage where I can start finishing the models; would like for them to be the first 'finished' models out of the Station Core parts, with the COS parts probably being worked on next)

[tater]

1. How much of tanks would actually be seen, anyway?

2. One opposite sounds fine, there is a to going on for these parts externally, and if some brave soul ever decides to mess with IVAs, it means fewer things to have to worry about, right?

3. That sounds fine. 

[Domfluff]

1) I'm a big fan of greebles in general, so the more exposed tanks and structure the better, to my tastes. Obviously that's more work, so feel free to disregard
It's also one of the things that makes the Russian-like modules somewhat distinct from the US-like modules, at least from a distance - the Russian stuff does look like it's designed for function over form in most cases.

2) With regards to "function over form", windows are an extravagance. Some, certainly, but space is a place to work. The ST-DOS-FEM module would be the exception to that, of course.

3) I'd expect at least ST-DOS-COM (since that's intended as a space station core) to have an integral antenna, as well as ST-DOS-TKS (which can work as a space station by itself).
I don't think it's really required for the other parts. How does KSP handle antenna priority at the moment? It would suck if you built something MIR-like, and it tried to use all of them at once...
 

[RedParadize]

That looks nice! As for 1 2 3 question, I am ambivalent.

1: Tanks looks fine, but there might be too much of them on some model. Thats just my presonnal taste.

2: Russian were not big fan of windows... 1 is too many! Seriously, just one will be fine. Or two on each side if there is less tanks. I will be happy regardless.

3: DOS and its variant are mostly multi-purpose habitat. So I would say yes. I suspect that they will often be used as station or small starship first module. They kinda need.

[JoseEduardo]

with built-in Antenna, do you mean something like Priroda


Mir-2 truss


or Antennas like the Igla and Kurs docking antennas?


EDIT: ah, apparently the "Antennas" on Mir-2 aren't antennas actually... apparently they are Solar Gas Turbines... still don't know what they do though...

Edited August 25, 2016 by JoseEduardo

[tater]

Solar gas turbines? Use a parabolic reflector to heat an operating fluid/gas to drive a turbine for electricity.

[JoseEduardo]

so the station basically had two ways of generating power? interesting...

I wonder if there is something similar for KSP

Edited August 25, 2016 by JoseEduardo

[Shadowmage]

17 hours ago, RedParadize said:

I forgot about the EPL thing. Its just that I think EPL is a tad OP... I would have enjoyed if another option would have been available. Like carrying a core part, then transfering X amount of rocket part resource and BAM, you have a huge centrifuge.  Again its all good, at worst it will be a verry challenging lunch! That will be fun.

That is an interesting mechanic, and perhaps simple enough that I could integrate it with the other modules.  A bit of a compromise and a decent gameplay abstraction.  Have been thinking that some sort of 'kit out' function would be appropriate for -all- of the inflatables, not just the larger torus parts, and this mechanic could work well for that (to simulate bringing in the equipment to bring the module fully on-line while/after it was inflated).

I think it would go something like:
1.) Launch the empty 'core' for the inflatable/torus module in its deflated state.
2.) Dock/attach another vessel that contained a container full of RocketParts, or MaterialKits, or whatever resource is chosen to be used for the purpose.
3.) Press the 'construct' button on the inflatable, the needed resources will be consumed, the inflation animation will play, and from that point out the part would be permanently inflated.  The part would increase its mass proportional to the resources consumed in the kit-out/construction process.

This would allow for lower launch masses for deflated parts while still 'simulating' the kit-out/completion process for those parts.  They could be toggled to the 'constructed' state while in the editor and launched complete if the user desired (though they would have the full mass and cost).

So for the largest torus parts you might launch a 20t empty core and ship up 80t worth of resources for its construction -OR- you could launch it fully inflated at its 100t standard dry mass.  The non- torus inflatables would have a much smaller difference in their deflated and fully constructed masses as they would be merely simulating a kit-out rather than full-on construction of the part.

I'll give this a bit more thought and see if it is something that I want to implement/investigate potential problems.  It seems like it would be a good compromise for the inflatable parts while not adding too much complexity or duplicating features from other mods.

[tater]

@Shadowmage, so your mechanism above would effectively use the "core" part to assemble/inflate as an EPL "launchpad" part, with itself as the thing to be constructed (with the "pad" bit destroyed in the process)?

[Shadowmage]

Just now, tater said:

@Shadowmage, so your mechanism above would effectively use the "core" part to assemble/inflate as an EPL "launchpad" part, with itself as the thing to be constructed (with the "pad" bit destroyed in the process)?

Essentially yes; but without any destruction/replacement.  The core would be the same part as the finished article; would just be enabling/swapping some meshes/models (for constructed torus') or playing the inflation animation (for inflatables). 

So you'de press the 'construct' button, the resources would be consumed, and either the module would inflate (inflatables, inflatable torus), or the meshes would materialize (rigid torus)(perhaps even slowly fade-in using some alpha blending).  After that the 'construct' button would disappear, and the part would be permanently in its constructed/inflated state.

Still just a concept/thought though; no idea if it is even doable at this point (might do some investigation/work on it this weekend).

50 minutes ago, JoseEduardo said:

with built-in Antenna, do you mean something like Priroda


Mir-2 truss


or Antennas like the Igla and Kurs docking antennas?


EDIT: ah, apparently the "Antennas" on Mir-2 aren't antennas actually... apparently they are Solar Gas Turbines... still don't know what they do though...

Both, and neither

Similar in form and size to the docking antennas, but functionally used for communication, located on the 'back' of the modules opposite of the hatches.  Might do something a bit larger on the COM module (as it is the command/communication module after all).

[JoseEduardo]

I personally think that a core with basic communication with the planet/satellite network would be the best, needing a dedicated expansion module with a long range antenna to improve communication (like RemoteTech or the planned stock RemoteTech) or perhaps with different funcionality (like that solar gas turbine thing, or scanning perhaps...)

EDIT: speaking of stock RemoteTech, this comes directly from the devnotes: http://imgur.com/l7sEIP3

http://kerbaldevteam.tumblr.com/post/149471502239/devnote-thursday-tweaking-and-turning-gears

apparently RemoteTech DID become stock with some stuff changed though...

Edited August 25, 2016 by JoseEduardo

[Shadowmage]

Here is a comparison of the 'exposed tanks' (left) vs. 'enclosed tanks' (right) geometry on the DOS modules.

After actually putting it together and looking at it... pretty sure I'll be going with the exposed tanks.  The boxed tanks just seem to lack character...

Perhaps some of the models will have -some- of the tanks enclosed/turned into other types of storage compartments (e.g. the STR module), but I really do like the exposed tanks better.

[JoseEduardo]

I'd vote for exposed too, looks a lot better

but I'd cover the small radiators... (the ones bellow the solar panels) and possibly reduce the top of the cover on the tanks, exposing more of them (like those from KOSMOS)

[StickyScissors]

I swear that my finger and the F1 key have some seriously powerful magnets in them. Can't. Stop. Screenshotting! Was testing shuttle stability on reentry (not great), my slightly upgraded Alkaid Reusable Nuclear Shuttle, and gawking at the hab parts and GFX mods.

Spoiler

Space Shuttle Olympus delivering some fuel and a crew of 4 to RNS Zorya, to support a planned surface excursion on the Mun. Landers have already been delivered by RNS Zorya about 30 days previously, before the launch of the hab module

Zorya is fueled up (not entirely) and the crew is dropped off, while Olympus prepares to to Kerbin remotely

What is a shuttle mission without the obligatory overshoot of KSC. Good thing there's no crew, because this thing plowed into the ocean not too long after this shot. It's hard to glide back when, while SAS is on, the shuttle won't stop rolling/overcorrecting at every glance at the keyboard, and with SAS off, it nosedives tremendously even while supersonic

Unrelated: Ahh, great, so this is starting up again. I was wondering why my FPS when from 40 to 15, and i have no idea what a cause could be. It's a wonder that i haven't completely just dropped this game entirely at this point, FPS murdering NRE's i do not enjoy too much.

 

[Shadowmage]

7 minutes ago, StickyScissors said:

I swear that my finger and the F1 key have some seriously powerful magnets in them. Can't. Stop. Screenshotting! Was testing shuttle stability on reentry (not great), my slightly upgraded Alkaid Reusable Nuclear Shuttle, and gawking at the hab parts and GFX mods.

  Hide contents

Unrelated: Ahh, great, so this is starting up again. I was wondering why my FPS when from 40 to 15, and i have no idea what a cause could be. It's a wonder that i haven't completely just dropped this game entirely at this point, FPS murdering NRE's i do not enjoy too much.

 

If you have a log from those null-refs I can take a look at it to see if there is anything SSTU-related that could be the culprit.

[StickyScissors]

13 minutes ago, Shadowmage said:

If you have a log from those null-refs I can take a look at it to see if there is anything SSTU-related that could be the culprit.

Probably not really needed, but it couldn't hurt. A quick glance at the log pops up...a -lot- of this:

NullReferenceException: Object reference not set to an instance of an object
  at GravityTurn.VesselState.ToggleRCSThrust (.Vessel vessel) [0x00000] in <filename unknown>:0
  at GravityTurn.VesselState.Update (.Vessel vessel) [0x00000] in <filename unknown>:0
  at GravityTurn.GravityTurner.FixedUpdate () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

So i'm gonna go ahead and assume that GravityTurn is causing it...even though i wasn't using it, i was using MJ ascent because i -thought- GravityTurn was the reason i was having flippy issues on ascent.

Edit: i guess since i mentioned it, i'm not sure how even MJ is letting the rocket flip on ascent, it's got plenty of gimbal to correct issues but noooope, it keeps on flipping, or i have to keep it pointed where it needs to be manually, which pretty much negates it's use in the first place :/

Edited August 25, 2016 by StickyScissors

[Shadowmage]

1 hour ago, JoseEduardo said:

I'd vote for exposed too, looks a lot better

but I'd cover the small radiators... (the ones bellow the solar panels) and possibly reduce the top of the cover on the tanks, exposing more of them (like those from KOSMOS)

Something a bit more like (on the covered smaller tanks):  ?

Should be doable.  I too thought that having -all- of the tanks looked a bit 'busy'/redundant.  Would clean them a bit to not be quite-so-boxy... but I think it might be how I end up doing them.

 

 

6 minutes ago, StickyScissors said:

Probably not really needed, but it couldn't hurt. A quick glance at the log pops up...a -lot- of this:

NullReferenceException: Object reference not set to an instance of an object
  at GravityTurn.VesselState.ToggleRCSThrust (.Vessel vessel) [0x00000] in <filename unknown>:0
  at GravityTurn.VesselState.Update (.Vessel vessel) [0x00000] in <filename unknown>:0
  at GravityTurn.GravityTurner.FixedUpdate () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

So i'm gonna go ahead and assume that GravityTurn is causing it...even though i wasn't using it, i was using MJ ascent because i -thought- GravityTurn was the reason i was having flippy issues on ascent.

 

Yeah, from looking at the source I don't -think- it is related to SSTU.  Possibly could be still due to my manipulation of models-with-RCS ports in them, but doubtful.

 void ToggleRCSThrust(Vessel vessel)
{
if (thrustVectorMaxThrottle.magnitude == 0 && vessel.ActionGroups[KSPActionGroup.RCS])
{
rcsThrust = true;
thrustVectorMaxThrottle += (Vector3d)(vessel.transform.up) * rcsThrustAvailable.down;
}
else
{
rcsThrust = false;
}
}

The only things in there that could null-ref are the internal state variables (thrustVectorMaxThrottle, rcsThrustAvailable), the KSP vessel, or the vessel.ActionGroups.

Might be best to report that bug to the Gravity Turn repository ( https://github.com/johnfink8/GravityTurn ) and see what the author thinks about it.

[RedParadize]

@Shadowmage Glad you liked the suggestion regarding Core+resources, hope it work. The Reduction of the full industrial complex to a single 3-step-build-everything always have bugged me, at least in a near future context. Core+resources system sound be more "realistic". Its a bit like IKEA pre made setup.

Regarding the box on each sides of DOS, it looks good. Too much tanks looks weird. If you want more details, you could just remove the tanks under the panel and put something else, battery or else. A bit like your semi random box/sphere/tube on engine mount.

Edited August 26, 2016 by RedParadize

[JoseEduardo]

39 minutes ago, Shadowmage said:

Something a bit more like (on the covered smaller tanks):  ?

Should be doable.  I too thought that having -all- of the tanks looked a bit 'busy'/redundant.  Would clean them a bit to not be quite-so-boxy... but I think it might be how I end up doing them.

yep, exactly like that

btw, here's a pic of KOSMOS external tanks, might give you a better idea of what I was talking about reducing the top part of the radiators covering the tanks

[RedParadize]

Its kinda funny, does anyone remember how many part were needed to built whats on that image ? I count 30 but I am probably forgeting some RCS.

Edited August 26, 2016 by RedParadize

[Guest]

30 sounds about right. Seems like ages since I last used that spectacular mod.

[JoseEduardo]

I counted 33, not counting the struts and the parachute on top of the VA  (don't know if it is there, it is also missing the retro-rockets)

now if you get SSTU you can have it in 4 parts... core+TKS+2 docking ports

[Shadowmage]

Updated DOS module render (solar panels not rendered in order to show window placement).

Changes include removal of the STR module (really didn't need a storage/hab module...tons of storage options already exist), alteration of the radiator panels (they are now shorter, exposing some of the tank-ends), and added some preliminary window geometries (hidden behind the solar panel on most of the modules).  Cleaned up the wider side panels to be more box-like, but still with some detail.  Changed the narrow side-panels to include two boxes and one tank (box-tank-box arrangement)... boxes could be batteries or something (might change this to mimic the wide side panels).

This means there are two modules based on the COM (Mir core) geometry, two based on the FGB geometry, and two based on the TKS geometry, which seems to be a nice even/round distribution to me.

 

 

About the only thing left to add on these is the antennas/transmitters.  I'm thinking that -all- of them will have some sort of antenna, but a couple will have larger antenna setups (COM, TKS).

BTW, solar panels, antenna, and RCS are all added through the equivalent of MODEL nodes, so are all end-user configurable if they prefer models from stock or other mods   (EVA hatches may be as well, undecided; they are currently, and I'll likely leave it as such)

 

 

[JoseEduardo]

um.... I forgot to ask this earlier....

we'll be able to add new endcaps later on from other mods meshes, right?

EDIT: btw, looking at KOSMOS now... I think I could make some patches having SSTU and KOSMOS as dependencies, and making them all low-part-count SSTU counterparts.... possibly a new SSTU add-on thread

Edited August 26, 2016 by JoseEduardo

[Shadowmage]

1 hour ago, JoseEduardo said:

um.... I forgot to ask this earlier....

we'll be able to add new endcaps later on from other mods meshes, right?

EDIT: btw, looking at KOSMOS now... I think I could make some patches having SSTU and KOSMOS as dependencies, and making them all low-part-count SSTU counterparts.... possibly a new SSTU add-on thread

Yes.  Setup the SSTU_MODEL config data for the model, and reference that model in the part.

And yes, you could very likely do some low-part-count setups using other mods' parts.  Very few of my plugins/partmodules require any special model setup -- the 'modular' parts simply require that the SSTU_MODEL config be setup for them so it knows how big it is/how to position the models, and from there it should mostly 'just work'.  I would already be doing this myself, except for a.) I really don't want any external mod dependencies, and b.) I'm not a fan of 'stock-alike' textures (which seem quite prevalent with most mods).

I've even setup the SSTU_MODEL loading so that you can load specific -meshes- from models and combine single meshes from different model files.  This was done to support models built for B9/FS mesh-switch modules, but could be used in other ways as well.

Really... many of these modules could be a part-welders wet dream, they just require a bit more manual work and setup than pressing the 'weld' button on Ubiozor.  Part-welding was what got me started on plugin modding... or more specifically the limitations imposed on part-welding by the stock modules (I found it silly that you couldn't weld more than a single solar panel, landing leg, multiple animated parts (in 0.90, layers didn't exist), or parachute... so I fixed those problems).