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

[JoseEduardo]

3 hours ago, Domfluff said:

Thinking about usi-ls support some more, and doing a bit of research - the DOS modules had a mission duration of 90 days, which with a crew of two implies a total of six seats (30 days per seat, divided by two kerbals) - this would mean that the station itself would have two available seats, with no bonuses on hab time. I think this is fine, since these  are low-tech stations, more sophisticated hab modules would perform better. The other four seats come from the soyuz capsule itself.

In terms of supplies, 500 supplies is enough for one kerbal/month, therefore the station needs to hold 3000 supplies, with no need for recycling (low tech). The early Salyuts had no resupply, so this puts a fairly hard limit on the station lifespan. Salyut 6+ could dock a Progress vehicle for supply, and judging by the mission logs, it looks like one Progress could supply the full ninety day duration. This implies that the Progress can hold 3000 supplies, or three tons of cargo. Since that mostly matches the real world, that's pretty straightforward. I'll write a basic mm patch when I'm in front of a pc, and see if that causes any other problems.

Mir and ISS modules would require some more thought/research, as would inflatables or anything more sophisticated. Going the other direction, a MOL-like station would require minimal supplies and perhaps only one seat (for the lab) to match it's forty day mission duration.

regarding max crew size on DOS cores, let's not forget that they had Intercosmos missions visiting the crew during a mission, which would leave Salyut 6, 7 and Mir with 5 people on board for a short time

I wonder how they managed the Mir when the Shuttle was docked and how many astronauts went to Mir for each Shuttle-Mir mission....

[Domfluff]

Spoiler

// Progress unmanned pod USI-LS and KIS patch

@PART[SSTU-SC-A-SMX]:HAS[@MODULE[SSTUVolumeContainer]]:NEEDS[USILifeSupport]
{    
    @MODULE[SSTUVolumeContainer]
    {
        @CONTAINER,1[*]
        {
            resource = Supplies
            resource = Mulch
        }
    }
}

SSTU_RESOURCEVOLUME
{
    name = Supplies
    volume = 1
}

SSTU_RESOURCEVOLUME
{
    name = Mulch
    volume = 1
}

//duplicate and adjust the electricCharge definition;
//done as a copy because NEEDS blocks apparently do not work on regular definitions?

+RESOURCE_DEFINITION[ElectricCharge]:NEEDS[KIS]
{
    @name = SSTUKISStorage
    %flowMode = ALL_VESSEL
    %transfer = PUMP
    %isTweakable = false
    %isVisible = false
    %volume = 1
    %density = 0
    %cost = 0
    %hsp = 0
}

//add the dummy resource to the given containers and tanks
@PART[SSTU-SC-A-SMX]:NEEDS[KIS]
{    
    @MODULE[SSTUVolumeContainer]
    {
        @CONTAINER,1[*]
        {
            resource = SSTUKISStorage
        }

    }
    !MODULE[ModuleKISInventory]{}
    MODULE
    {
        name = ModuleKISInventory
        maxVolume = 0
        externalAccess = true
        internalAccess = true
        slotsX = 4
        slotsY = 4
        slotSize = 50
        itemIconResolution = 128
        selfIconResolution = 128
        openSndPath = KIS/Sounds/containerOpen
        closeSndPath = KIS/Sounds/containerClose
        defaultMoveSndPath = KIS/Sounds/itemMove
    }
}

Going to be a silly question. I'm testing the above patch at the moment. This works fine... except that the container that's being modified is always the fuel tank of the Progress vehicle, not the cargo storage (which has the space available).

I assumed this was the "@CONTAINER,0[*]" reference, and this tied to the baseContainerIndex of the part(?) (starts at 1 for this part), but trying this for 0,1 and 2 doesn't seem to make a difference, so I assume I'm missing something basic here.

Redefining the whole module (or altering the part cfg) itself has this working as expected, but I'd like to maintain the MM patch as an optional extra, rather than tying this in hard.

Edited July 22, 2016 by Domfluff

[StickyScissors]

I really hope these station parts work out in one way or another, SSTU not having station parts ^{and swapable Dragon capsule variants...} is pretty much the only thing holding me back from nuking my install/save, and starting fresh with just SSTU, some essential Q.O.L mods and all the graphics enhancements my GTX 960 can take.

[Shadowmage]

7 hours ago, Domfluff said:

  Reveal hidden contents

// Progress unmanned pod USI-LS and KIS patch

@PART[SSTU-SC-A-SMX]:HAS[@MODULE[SSTUVolumeContainer]]:NEEDS[USILifeSupport]
{    
    @MODULE[SSTUVolumeContainer]
    {
        @CONTAINER,1[*]
        {
            resource = Supplies
            resource = Mulch
        }
    }
}

SSTU_RESOURCEVOLUME
{
    name = Supplies
    volume = 1
}

SSTU_RESOURCEVOLUME
{
    name = Mulch
    volume = 1
}

//duplicate and adjust the electricCharge definition;
//done as a copy because NEEDS blocks apparently do not work on regular definitions?

+RESOURCE_DEFINITION[ElectricCharge]:NEEDS[KIS]
{
    @name = SSTUKISStorage
    %flowMode = ALL_VESSEL
    %transfer = PUMP
    %isTweakable = false
    %isVisible = false
    %volume = 1
    %density = 0
    %cost = 0
    %hsp = 0
}

//add the dummy resource to the given containers and tanks
@PART[SSTU-SC-A-SMX]:NEEDS[KIS]
{    
    @MODULE[SSTUVolumeContainer]
    {
        @CONTAINER,1[*]
        {
            resource = SSTUKISStorage
        }

    }
    !MODULE[ModuleKISInventory]{}
    MODULE
    {
        name = ModuleKISInventory
        maxVolume = 0
        externalAccess = true
        internalAccess = true
        slotsX = 4
        slotsY = 4
        slotSize = 50
        itemIconResolution = 128
        selfIconResolution = 128
        openSndPath = KIS/Sounds/containerOpen
        closeSndPath = KIS/Sounds/containerClose
        defaultMoveSndPath = KIS/Sounds/itemMove
    }
}

Going to be a silly question. I'm testing the above patch at the moment. This works fine... except that the container that's being modified is always the fuel tank of the Progress vehicle, not the cargo storage (which has the space available).

I assumed this was the "@CONTAINER,0[*]" reference, and this tied to the baseContainerIndex of the part(?) (starts at 1 for this part), but trying this for 0,1 and 2 doesn't seem to make a difference, so I assume I'm missing something basic here.

Redefining the whole module (or altering the part cfg) itself has this working as expected, but I'd like to maintain the MM patch as an optional extra, rather than tying this in hard.

For my patches on the LC-POD parts, I used a slightly different syntax (notably I had no name qualifier and used index only):

		@CONTAINER,0
		{
			@defaultResources = MonoPropellant,50;ElectricCharge,600;Supplies,292,1;Mulch,292,0
			resource = Supplies
			resource = Mulch
		}

 

For the use on the SC-A-SMX, you would probably specify it as:

		@CONTAINER,1
		{
			resource = Supplies
			resource = Mulch
		}

That should leave the propellant container untouched, but add the supplies and mulch to the secondary storage container (you can also add fertilizer in the same manner, and might be appropriate for that part).

 

The baseContainerIndex in SSTUVolumeContainer merely specifies what the 'main' container for the part is for GUI interaction and should not effect how patches or other modules interact with it.

[Domfluff]

Spoiler

// Progress unmanned pod USI-LS and KIS patch

@PART[SSTU-SC-A-SMX]:HAS[@MODULE[SSTUVolumeContainer]]:NEEDS[USILifeSupport]
{    
    @MODULE[SSTUVolumeContainer]
    {
        @CONTAINER,1
        {
            resource = Supplies
            resource = Mulch
        }
    }
}

SSTU_RESOURCEVOLUME
{
    name = Supplies
    volume = 1
}

SSTU_RESOURCEVOLUME
{
    name = Mulch
    volume = 1
}

//duplicate and adjust the electricCharge definition;
//done as a copy because NEEDS blocks apparently do not work on regular definitions?

+RESOURCE_DEFINITION[ElectricCharge]:NEEDS[KIS]
{
    @name = SSTUKISStorage
    %flowMode = ALL_VESSEL
    %transfer = PUMP
    %isTweakable = false
    %isVisible = false
    %volume = 1
    %density = 0
    %cost = 0
    %hsp = 0
}

//add the dummy resource to the given containers and tanks
@PART[SSTU-SC-A-SMX]:NEEDS[KIS]
{    
    @MODULE[SSTUVolumeContainer]
    {
        @CONTAINER,1
        {
            resource = SSTUKISStorage
        }

    }
    !MODULE[ModuleKISInventory]{}
    MODULE
    {
        name = ModuleKISInventory
        maxVolume = 0
        externalAccess = true
        internalAccess = true
        slotsX = 4
        slotsY = 4
        slotSize = 50
        itemIconResolution = 128
        selfIconResolution = 128
        openSndPath = KIS/Sounds/containerOpen
        closeSndPath = KIS/Sounds/containerClose
        defaultMoveSndPath = KIS/Sounds/itemMove
    }
}

Perfect! The above works great, and it fits the requirements for a 90 day Salyut (more or less), including the supplies on the Soyuz capsule. Without any additional storage on-station that's 65 days and 90 days hab time. If the station can hold about 1000 supplies then that's up to spec.

I suspect that might be all that's required to make the Progress-like capsule useful.

Edited July 22, 2016 by Domfluff

[Shadowmage]

After much thought on how to best handle the modular station parts as far as the DOS variants are concerned, I've come to grips with the fact that 3/4 of what I had planned simply is not possible with the limitations of lack of module-switching.  As such I've had to scale back the plans for those parts a bit (was a single part, now will be multiple distinct parts, with much reduced modularity and customization options ).

The lack of module-switching functionality has led to the following reduction in capabilities from what I had originally wanted/intended for the parts.

• They cannot have integrated docking ports or else the end-cap selection will have to be limited to adapters for that chosen docking ports size, greatly limiting the possible integration opportunities for the part.
• They cannot have multiple solar panel options due to no ability to add or remove the modules to manage them.  So only the 'core' of the model will have solar panels.
• They will have a single 'core' model for each part.  No ability to add/remove the lab module means I cannot readily have multiple core variants.
• Each 'core' will have to become its own distinct part with various module/config settings to differentiate them.  Some will have more storage, some more lab capacity (or none),
• Only a single pre-set crew capacity and IVA for each part; no 'core' switching means that switching of IVAs and crew setup is unnecessary.

So.. with the removal of all of that, what is left that they will have for features?

• Ability to select the top and bottom adapter caps; 1.25m and 0.625m caps will be included by default, as well as the 1.875m VA adapter and possible a short flat-topped 1.875m adapter.  Top will also include an optional 'hub' multi-adapter (1.25m x 5 nodes).  They will not include docking ports or solar panels unfortunately.
• Integrated RCS (as part of the core model)
• Integrated Solar Panels (as part of the core model)
• Integrated OMS (orbital engines) -- small low thrust hypergolic thrusters for orbital adjustment and rendezvous.  Integrated into the 'bottom cap' adapter.  ALL of the DOS based modules will have this capability.
• You still get the VA capsule (and its SM and LAS)... so that's something.  1.875m, 3-man re-entry pod.  This will actually become ShipCore: Series-D when it is completed.  It will be situated somewhat later in the tech tree, likely around the stock 2.5m capsule.
   

They will be able to function as 'low part count' stations with the addition of a couple of docking ports of your choice; everything else should be taken care of (rcs, engine, power generation, storage).  Most, or perhaps all of them, will come with some sort of lab capacity; the crew count and storage for the lab will vary with the 'core' model, though I haven't settled on any particular balance yet.

Nowhere near as grand of a concept as I had originally, but should still greatly reduce the part-count needed for creating these types of station modules (down from ~12 to 3.. so still substantial part savings), while still allowing for some variation and customization of the parts to better integrate them into various designs.

 

Most of the other part concepts that I had planned should still be possible.  The large multi-axis solar truss parts are definitely still doable, as are the inflatable module parts.  Welding docking ports should still be a thing.  Multi-docking hubs would still work but they would likely be limited to a single set of models for the ports (e.g. could be no port-size switching; -might- be able to work around this a bit, but unsure if I want to).

Still going to give this all a bit more thought before I commit to anything on these parts.  I'm really not happy with the limitations to the (now not very) modular station core parts, but I cannot currently fathom any way around them.

Regarding the USOS styled station parts -- I'm really not sure there is anything that I can do to improve on those that other mods' already offer.  I can't integrate docking ports, and they already have a built in 'adapter' on them, so there is no need for top/bottom adapter switching (or is there?).  At this point I'm not sure that I'll be doing any USOS styled station parts, it seems unnecessary given that other mods' already have those parts in the appropriate sizes.

[Domfluff]

I've said before, but one of the hurdles that I've certainly found in careers (with USI-LS) is the lack of decent habitation parts. Having single-piece (or near-single piece Almaz and Salyut-style stations would be great for that, since it gives you a nice early game space station for early rendezvous and orbital science processing.



Of the above (DRM5), SSTU makes the propulsion bus and crew transfer vehicles extremely easy to replicate, but we are seriously lacking in good and capable options for the hab module. These kinds of modules are pretty much interchangeable with station parts, so anything of that ilk would be extremely useful.

It's a shame that you can't be as high concept as you'd like with the station parts, but any work in this direction would be massively appreciated - space stations are where part counts get silly very quickly, so every integrated solar panel, radiator and RCS nozzle knocks this down significantly.

[JoseEduardo]

If I understood it correctly, the "core" will be the main part, which should have switchable top and bottom endcaps like the MFT?

if so, if you make solar panels a separate part you'l only need something based around the Salyut 1/4 main body for the DOS core with a common IVA, as they all revolve around that design

I'm talking about this specific area:

[Shadowmage]

30 minutes ago, JoseEduardo said:

If I understood it correctly, the "core" will be the main part, which should have switchable top and bottom endcaps like the MFT?

if so, if you make solar panels a separate part you'l only need something based around the Salyut 1/4 main body for the DOS core with a common IVA, as they all revolve around that design

I'm talking about this specific area:

 

 

Solar panels are integrated where applicable (well, basically added through model nodes); but otherwise yes, each of the DOS core variants have top/bottom adapter switching (or that is the current plan), a set crew capacity, and a single IVA.  Due to the other limitations in place each variant is its own stand-alone part, which has its good and bad points.  It is a bit of editor part-list bloat, but it gives an excellent chance to differentiate the setup of the parts a bit; perhaps one has more lab capacity, or no lab, or one comes with built-in science experiment packages, or (thinking ahead) one has better/integrated life-support systems or greenhouse.

Currently I have 6 core variants (including the TKS body), 6 top adapters (including the VA and hub adapters), and 4 bottom adapters (soon will be at least 5).  They can potentially use any of the other top/nose options from the MFTs or SRBs, however the bottom adapters have built-in engines so the selection is more limited (the alternative that I'm considering is building the engines into the core, greatly simplifies the module interaction code and is actually where some of the modules had their engines).

 

Speaking of which... this mess of modules sits at 23 parts (28 if the blank hub was covered in docking ports).  That count is including an SC-A-SMX, a full SC-A OM/DM/SM, and a full VA/TKS spacecraft, so the station itself is only 14/19 parts (of which more than half is docking ports).  If I can make some workable multi-docking hubs, that count could be even further reduced.  The use of welding docking ports between the modules could also reduce the part count (though I'm unsure on the clearance if the stock ports were removed; I may make additional longer adapter options for use with the welding ports).  (only prototype/testing parts, and only about half-way working so far.... still lots to do, and at this point I'm still figuring out what will or will not work)

 

[Kerbal01]

Would you be down to making a cylinder probe core (tweakable size) that has SAS and parachutes on the edges? I want to do S-1C recovery for my Saturn V M(Saturn v with F1-B and J-2X engines for modern lift ability

 

[Shadowmage]

On Saturday, July 23, 2016 at 9:20 AM, DarthVader said:

Would you be down to making a cylinder probe core (tweakable size) that has SAS and parachutes on the edges? I want to do S-1C recovery for my Saturn V M(Saturn v with F1-B and J-2X engines for modern lift ability

 

Had a few requests for a procedural probe core, so I've gone ahead and made one up for the next release.  It re-uses the procedural mesh generation and textures from the ProceduralDecoupler part (with all the explodey bits removed).

Parachutes are -not- included.  However, if you were intending this for use with StageRecovery it doesn't matter either way, as SR does not support SSTU Parachutes (and stock parachutes cannot have multiples in one part, nor can they be dynamically adjusted as would be needed).

Reaction wheels are not included.  Feel free to patch them in yourself if you want them;  I find they are an acceptable compromise for command pods, but utterly cheating for any other use.

ElectricCharge / battery capacity -is- included, though not huge amounts, nor does it scale with model size (set capacity).

 

Will be available with the next update, whenever that is (probably next weekend).  Will also be including some prototypes of some of the station parts (DOS modules, Welding Docking Port, Inflatable Hab #1), which is why it won't be available until next weekend -- much of that stuff is still in too rough a shape for external testing.

 

But, I can offer you this preview video of the 'Welding Docking Ports' in action (with new prototype model):

 

And also this pic of the SC-E, because it looked so epic (okay, so really its just Scatterer that is epic looking...the shuttle just happened to be in the shot):

Edit:  ^^ I'm bringing back the SC-E parts, minus landing gear.  The rest of it still works okay, so no real reason to hold it back; the stock landing gear work fine with it even if they do look a bit odd.

 

 

Edited July 24, 2016 by Shadowmage

[ComatoseJedi]

I like the *pOOf* and I literally said "ta-da". 

"One man's magic is another man's technology"

 

[Shadowmage]

And... one more concept validated -- the multi-solar-panel truss segement, with dual-axis tracking.  Yes, those are 64% scaled ISS sized solar arrays.  Freaking massive things compared to all others available (they even dwarf the largest Near-Future panels by quite a bit).  Note the rotation of the core piece relative to the panels between the two images;  the central core rotates, as well as the individual panels rotating around their pivots.  I may or may not make other variants of this part with different core sizes and solar panel options; undecided at this point.  This part is modular in so much as that it will have selectable top and bottom adapters (same as the other station parts).

 

 

This leaves the only concepts to be validated from my original parts list being the multi-docking hub (already partially validated), and some sort of a modular torus structural/storage part (not a centrifuge) (not even started yet; unsure how to get the resizing to work without procedural generation or tons of prebuilt models).

 

Also a heads up that I will be migrating away from Imgur througout the next few days/weeks.  The site has done nothing but lost features over the past two years and at this point is nearly unusable for my purposes. Between the removal of features (such as album layout selection), the constant site 'updates' (which really just remove more features; such as the ability to auto-upload into an album), and the recent breakage of albums on the forum... its time to move on to something new (or old in this case; but at least old and working rather than new and busted).

Images will be moved to being hosted on the SSTULabs - Github-Wiki (or perhaps github pages... undecided; really don't feel like writing any HTML).  This means that albums will be gone entirely, and that many older links will simply be broken and not fixed (I'll fix recent links, but anything more than a few days/week old is going to remain broken).

[ComatoseJedi]

13 hours ago, Shadowmage said:

Freaking massive things compared to all others available (they even dwarf the largest Near-Future panels by quite a bit).

No such thing as massive or "freakin' massive". If this concept comes to fruition, keep em big. Because, I'll either use the massive solar panels or flat panels that I've always used when size matters. Then again, size really doesn't matter to me, either. I put stock XL's on small probes, because I don't believe in moderation. But, you're not the first one to come up with massive solar panels. I constantly used Behemoth solar arrays when I came back to KSP.

Spoiler

Yeah. no such thing as freakin' massive.....

 

[Shadowmage]

13 hours ago, ComatoseJedi said:

No such thing as massive or "freakin' massive". If this concept comes to fruition, keep em big. Because, I'll either use the massive solar panels or flat panels that I've always used when size matters. Then again, size really doesn't matter to me, either. I put stock XL's on small probes, because I don't believe in moderation. But, you're not the first one to come up with massive solar panels. I constantly used Behemoth solar arrays when I came back to KSP.

  Reveal hidden contents

Yeah. no such thing as freakin' massive.....

 

 

LoL

Leave it to you guys to find something even more ridiculously massive.  Shows how much chance I get to play around with other mods =\

 

 

Last night/today was more work on getting the prototype parts laid out and 'working'. 

All of the DOS modules are in-game with some slight variations between them (still working on it).  Apparently the stock science-lab doesn't support any sort of 'max crew', so any kind of lab-equipped part is an all-or-nothing affair (no way to set crew capacity to 3 and lab capacity to 1); not exactly what I wanted, but... oh-well, it'll still work.  Reduced the number of new adapters to be created by using the existing MFT adapters where appropriate; the new ones entail a 4-1 aspect ratio (flat/short/long), 3-1/3-2 extended (extra-long), and 1-1, 1-1-ext, 2-1, 3-1, 4-3 styled 'hubs'.  Moved all of the engines to be part of the core model rather than the bottom-cap adapter; this means that they can now use the full range of bottom adapters that are available on the MFTs/other parts (potentially even the engine mounts).

Started work on the placeholder COS modules (these are the USOS equivalents); initial thoughts are for 6-9 module variants with S/M/L sizes for each Hab, Lab, Storage.  Currently using the stock hitchhiker and science lab modules for these, but may put together a couple prototype models before the weekend.

Created two more sizes of inflatable hab modules for a total of three, so now there are 2.5m, 3.75m, and 5m cores for them (they expand to double that size when inflated).  These have modular end-caps the same as the DOS/COS/MFT parts.

Created initial prototype geometry for three different sizes of DOS module solar panels; the TKS will get the shortest/smallest size, but unsure on which modules will get the other two.  This brings the total solar panels available with the StationCore parts up to 4 variants, with potentially a couple more to come.  These will all be available as stand-alone parts as well as being integrated into the various modules where applicable.

Created two new RCS pod variants, 6 and 8 port angled; these re-use the textures/geometry from the SC-GEN-RCS-4F-T upper-stage RCS blocks.  Moved from having the rcs built into the DOS models to having them added through MODEL nodes; simplifies model creation and makes it easy for others to replace the RCS blocks if they wish (and for me to replace them later if I wish).  These RCS pods will also be available as stand-alone parts.

Still left to work on prototypes for are the toroidal parts (inflatable centrifuge based on Nautilus-X, rigid centrifuge, static docking ring/storage torus), proper COS module prototype models, and the multi-docking hubs.  Seems likely that they'll have the same limitations as the other station parts -- single non-resizable core model with modular end-cap/adapter selection.  This means that there will be one distinct part per-model created, without any user-selectable rescaling; the only 'options' will be for the end-caps.  I'm imagining 5 multi-docking hub variants (0.625m, mixed 0.625/1.25, 1.25, mixed 1.25/2.5, and 2.5).  Likely will end up with 6 different torus parts, two each for the different types (inflatable, centrifuge, static).

 

Updated DOS modules with changed main-engine setup/location/geometry (solar panels not shown, and apparently I missed the RCS on the far left module in this render; adapter selection has also changed since this render, but it is mostly to show the engine changes anyhow):

 

 

Updated selection of inflatable modules (top to bottom, 2.5m, 3.75m, 5m core diameters; double those sizes for inflated diameters).  Note that these will all likely have a short cylinder cap on them so that I can add a hatch to each part; the modular adapter will sit on top of that hatch section.

 

And, most of the current prototypes assembled in-orbit (sorry, forgot to get a part count... but it is pretty low); mostly was just testing to see if any modules were mis-behaving and making sure that all of the engines and RCS worked as expected (VA capsule and engine are from another mod; Tantares I believe... they just happened to be the proper size / fully compatible)

[ComatoseJedi]

2 hours ago, Shadowmage said:

Leave it to you guys to find something even more ridiculously massive.  Shows how much chance I get to play around with other mods =\

LOL.. well, to be fair, that was a couple of years ago. I don't even use that mod anymore. While it was fun to make stuff with it, the sizes were truly massive to be effective for anything but lifting things. At the same time, the solar arrays were from 5 meters to 10 meter diameter "containers". But, yeah, it's true that users of mods play more than the people who make them. It's the nature of the beast, so to speak. 

Those modules are looking fantastic, by the way. Can't wait to see what I can do with them. 

[Shadowmage]

9 minutes ago, ComatoseJedi said:

LOL.. well, to be fair, that was a couple of years ago. I don't even use that mod anymore. While it was fun to make stuff with it, the sizes were truly massive to be effective for anything but lifting things. At the same time, the solar arrays were from 5 meters to 10 meter diameter "containers". But, yeah, it's true that users of mods play more than the people who make them. It's the nature of the beast, so to speak. 

Those modules are looking fantastic, by the way. Can't wait to see what I can do with them. 

Indeed

I'm -hoping- to get all of the prototypes finished and ready for testing by this weekend.  This will mark the transition into the 0.5.xxx releases (sadly, still no 'stable' releases as I'm still waiting on wheels).  Note that for a few releaes these parts will be prototypes only; simple models, no textures, but should be 'feature complete' and the overall shape and size of the models should be about right.  Ideally you should be able to transition from using the prototypes to using the finished parts with little to no side-effect (just prettier models); fair warning though, there might be a few parts that will have geometry changed, and might be a few module/config changes as well (mostly based on feedback on the prototypes).

Doing the entire set as prototypes before I start any real/detail work on even a single part.  Have had a few cases where parts don't mesh well together previously and feel that putting the entire set out there while things can still be changed should give an opportunity to spot and fix these problems before they are too difficult/time consuming to fix.

So, if all goes well you should be able to start playing around with them soon.  Won't be very pretty initially, but all of the function should be there.

 

 

On a different note; does anyone have knowledge of how the ISS solar arrays deploy the central truss?  From watching some videos of them being deployed the truss just magically keeps streaming out from the base container (~35m long truss comes out of a ~2m long container).  I was expecting some scissor-like deployment of the truss... but it appears to come out of the container fully assembled.  Obviously there is some sort of folding going on for the truss inside of that container, but I've not been able to locate anything on it.

Does anyone have any information on the mechanism they use for folding / compacting the truss for storage?  (I'm probably just going to 'fake' something, but am curious for knowledge sake)

[ComatoseJedi]

1 hour ago, Shadowmage said:

Does anyone have any information on the mechanism they use for folding / compacting the truss for storage?

This is what I found. 

P3/P4 Truss Unfolding

Seems like the wiki states the solar arrays were stored in an unpressurized cargo container and attached to the rotating joint, then unfolding in the manner in which you see in the animation. Kinda makes you wonder just how fragile those solar arrays really are?

"Major P3 and S3 subsystems include the Segment-to-Segment Attach System (SSAS), Solar Alpha Rotary Joint (SARJ), and Unpressurized Cargo Carrier Attach System (UCCAS). The primary functions of the P3 truss segment are to provide mechanical, power and data interfaces to payloads attached to the two UCCAS platforms; axial indexing for solar tracking, or rotating of the arrays to follow the sun, via the SARJ; movement and work site accommodations for the Mobile Transporter. The P3/S3 primary structure is made of a hexagonal shaped aluminum structure and includes four bulkheads and six longerons. The S3 truss also supports EXPRESS Logistics Carrier locations, first to be launched and installed in the 2009 time frame."

Honestly, I cannot find anything quickly on this subject as far as how it got on there to begin with. Unless you can read the entire engineering schematic (or understand it), looks like you're going to have to fake it. I am sure there's more people out there that know more than I do on the subject. 

EDIT:

Thinking on the texturing for the inflatables. I don't know how hard it would be to pull off a "hab canvas white", but that'll do. Unless you want to subject them to the tank textures, which will be fine. It could be pink and purple polka dotted for all I care. 

Edited July 26, 2016 by ComatoseJedi

[StickyScissors]

@Shadowmage I think i asked this a while ago but never got a response, but would you be against integrating solar panels into the lander fuel tanks? Maybe using the same ones that are already on the Orion SM, but only 2 of them instead of 4. Or maybe multiple types that can be swapped out?

[ComatoseJedi]

1 hour ago, StickyScissors said:

@Shadowmage I think i asked this a while ago but never got a response, but would you be against integrating solar panels into the lander fuel tanks? Maybe using the same ones that are already on the Orion SM, but only 2 of them instead of 4. Or maybe multiple types that can be swapped out?

I think he's not going to touch the lander core until the stock landing/gears get fixed. And, I think he did address this, because he was very upset at the fact that his work on the integration switching for the landing core parts (solar, RTGs, landing gears) didn't work on U5. And he also mentioned it was a big hack to make it do that anyways. So, I am going to guess "no", unless Shadowmage says otherwise. 

[JoseEduardo]

18 hours ago, Shadowmage said:

LoL

Leave it to you guys to find something even more ridiculously massive.  Shows how much chance I get to play around with other mods =\

 

still waiting for a death star, a star destroyer and a super star destroyer mod to fight the rebel scum, I'd probably go with the 2nd or 3rd one as these weren't blown up by that blond jedi-wannabe brat or by indiana jones...

btw, in a possibly related question... Mage, do you have any adapter that goes from 5m to 1.875m or 2.5m to 0.9375m? I don't use them often so I don't remember if I saw one....

[Shadowmage]

53 minutes ago, JoseEduardo said:

still waiting for a death star, a star destroyer and a super star destroyer mod to fight the rebel scum, I'd probably go with the 2nd or 3rd one as these weren't blown up by that blond jedi-wannabe brat or by indiana jones...

btw, in a possibly related question... Mage, do you have any adapter that goes from 5m to 1.875m or 2.5m to 0.9375m? I don't use them often so I don't remember if I saw one....

No I don't currently have any of that setup, that is a very strange ratio.  And I don't use or support 0.9375m at all.

As far as I can tell it would only be useful for that one size (5->1.875), and have no other uses in a stock/SSTU game.  An 8-3 ratio really doesn't lend itself to re-use very well; the other applicable size in the supported range being 10m->3.75m.

I -may- make one up, but I can't guarantee it.

[JoseEduardo]

Just now, Shadowmage said:

No I don't currently have any of that setup, that is a very strange ratio.  And I don't use or support 0.9375m at all.

As far as I can tell it would only be useful for that one size (5->1.875), and have no other uses in a stock/SSTU game.  An 8-3 ratio really doesn't lend itself to re-use very well; the other applicable size in the supported range being 10m->3.75m.

I -may- make one up, but I can't guarantee it.

I asked for it because of Cx's APAS, which is 0.9375m but also has a 1.25m version, and since I saw you using the tank mounts for the TKS it got me wondering if there was such size for the mounts, so don't worry about it

[_Augustus_]

20 hours ago, Shadowmage said:

LoL

Leave it to you guys to find something even more ridiculously massive.  Shows how much chance I get to play around with other mods =\

 

 

Last night/today was more work on getting the prototype parts laid out and 'working'. 

All of the DOS modules are in-game with some slight variations between them (still working on it).  Apparently the stock science-lab doesn't support any sort of 'max crew', so any kind of lab-equipped part is an all-or-nothing affair (no way to set crew capacity to 3 and lab capacity to 1); not exactly what I wanted, but... oh-well, it'll still work.  Reduced the number of new adapters to be created by using the existing MFT adapters where appropriate; the new ones entail a 4-1 aspect ratio (flat/short/long), 3-1/3-2 extended (extra-long), and 1-1, 1-1-ext, 2-1, 3-1, 4-3 styled 'hubs'.  Moved all of the engines to be part of the core model rather than the bottom-cap adapter; this means that they can now use the full range of bottom adapters that are available on the MFTs/other parts (potentially even the engine mounts).

Started work on the placeholder COS modules (these are the USOS equivalents); initial thoughts are for 6-9 module variants with S/M/L sizes for each Hab, Lab, Storage.  Currently using the stock hitchhiker and science lab modules for these, but may put together a couple prototype models before the weekend.

Created two more sizes of inflatable hab modules for a total of three, so now there are 2.5m, 3.75m, and 5m cores for them (they expand to double that size when inflated).  These have modular end-caps the same as the DOS/COS/MFT parts.

Created initial prototype geometry for three different sizes of DOS module solar panels; the TKS will get the shortest/smallest size, but unsure on which modules will get the other two.  This brings the total solar panels available with the StationCore parts up to 4 variants, with potentially a couple more to come.  These will all be available as stand-alone parts as well as being integrated into the various modules where applicable.

Created two new RCS pod variants, 6 and 8 port angled; these re-use the textures/geometry from the SC-GEN-RCS-4F-T upper-stage RCS blocks.  Moved from having the rcs built into the DOS models to having them added through MODEL nodes; simplifies model creation and makes it easy for others to replace the RCS blocks if they wish (and for me to replace them later if I wish).  These RCS pods will also be available as stand-alone parts.

Still left to work on prototypes for are the toroidal parts (inflatable centrifuge based on Nautilus-X, rigid centrifuge, static docking ring/storage torus), proper COS module prototype models, and the multi-docking hubs.  Seems likely that they'll have the same limitations as the other station parts -- single non-resizable core model with modular end-cap/adapter selection.  This means that there will be one distinct part per-model created, without any user-selectable rescaling; the only 'options' will be for the end-caps.  I'm imagining 5 multi-docking hub variants (0.625m, mixed 0.625/1.25, 1.25, mixed 1.25/2.5, and 2.5).  Likely will end up with 6 different torus parts, two each for the different types (inflatable, centrifuge, static).

 

Updated DOS modules with changed main-engine setup/location/geometry (solar panels not shown, and apparently I missed the RCS on the far left module in this render; adapter selection has also changed since this render, but it is mostly to show the engine changes anyhow):

 

 

Updated selection of inflatable modules (top to bottom, 2.5m, 3.75m, 5m core diameters; double those sizes for inflated diameters).  Note that these will all likely have a short cylinder cap on them so that I can add a hatch to each part; the modular adapter will sit on top of that hatch section.

 

And, most of the current prototypes assembled in-orbit (sorry, forgot to get a part count... but it is pretty low); mostly was just testing to see if any modules were mis-behaving and making sure that all of the engines and RCS worked as expected (VA capsule and engine are from another mod; Tantares I believe... they just happened to be the proper size / fully compatible)

When will those inflatables be available?

Also, why not do a 1.25m inflatable like the Russian inflatable habitat? 

[Shadowmage]

12 hours ago, StickyScissors said:

@Shadowmage I think i asked this a while ago but never got a response, but would you be against integrating solar panels into the lander fuel tanks? Maybe using the same ones that are already on the Orion SM, but only 2 of them instead of 4. Or maybe multiple types that can be swapped out?

I have no problem with the concept; I would in fact love to have parts setup like that.  Sadly, as was seen recently with the station parts debacle (that almost made me quit modding), stock code does not support PartModule switching which would be needed to make this work properly/generically.

Its not impossible to implement without module-switching, but any implementation would be a bit hacky and prone to failure/breakage.  Basically it would require a very low-level integration between the fuel tank managing code and the solar panel managing code; and I really don't want all my fuel tanks to carry around solar panels / the code to manage them.  The other option is a custom fuel tank module just for the lander-parts that has the solar-panel integration; but that is a ton of work for only a few fuel tanks.

I -might- at some point in the distant future (when I am reworking the lander-core parts as is scheduled) be willing to write a custom module to manage it, but certainly not in the near future / for the next few months.