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

[blowfish]

50 minutes ago, Shadowmage said:

Indeed; I've been contemplating how to best handle this for awhile, and sadly the only thing I can come up with is a separate texture sheet (or lose the AO bake on the existing tank textures).  Lets wait and see if 1.2 really does bring PBR shaders; as it allows for different textures to be used for AO, and would solve this problem quite readily.  I haven't heard much/anything on the subject recently, so I'm not getting my hopes up, but there is a chance.

For what it's worth, I think it would be pretty easy to modify the existing shaders to do this.  The shader source is already available through PartTools, and while I don't entirely understand the shading language, it looks straightforward enough to modify it to subtract another texture from the diffuse texture.  I think the bulk of the work would be in reconfiguring the models to use this.  But its probably worth waiting to see if 1.2 has a built-in solution for this.

[JoseEduardo]

I'm just going to post this here and also ping @CobaltWolf since this also uses his mod...

http://imgur.com/a/cYHX8

RealScaleBoosters for the IU, tanks and interstages (I extended the S-II interstage for J-2X but in this case I was using a regular J-2), DECQ Saturn V for the Apollo payload adapter, SSTU for the Apollo CM and Engines, and BDB for the docking port+LEM

on my first test it went very well until the point where I was going to decouple the LEM, due to some collider weirdness with DECQ's LEM decoupler it blew the descent stage up, and now I need to test without that decoupler and use a stock one instead...

the docking worked flawlessly btw, as shown in the pics I kept the animation and it allowed me to soft-dock with the LEM, and then hard-dock after I retracted it

(oh, and yeah, BDB's DP is part of the CM, not a separate part... I had to make a new BPC for that...)

EDIT: here's a patch to add BDB's docking port to SSTU Apollo if anyone is interested (could be used as basis to add other docking ports through patches as well):

+PART[SSTU-SC-B-CM]:NEEDS[Bluedog_DB]:FINAL
{
	@name = SSTU-SC-B-CM-Apollo
	@title = SSTU - SC-B - CM - Re-Entry Module - Apollo
	!MODEL,1
	{
	}
	MODEL
	{
		model = Bluedog_DB/Parts/Apollo/bluedog_Apollo_Block2_ActiveDockingMechanism
		position = 0, 0.86468, 0
	}
	@node_stack_top = 0,0.90071977,0,0,1,0,1
	!MODULE[ModuleDockingNode]
	{
	}
	MODULE
	{
		name = ModuleDockingNode
		referenceAttachNode = top
		nodeType = apollo
		acquireForce = 3
		acquireTorque = 2
		stagingEnabled = False
		gendered = true
		genderFemale = false
	}
	MODULE
	{
		name = ModuleAnimateGeneric
		animationName = retract
		//isOneShot = true
		startEventGUIName = Retract Ring
		endEventGUIName = Extend Ring
		actionGUIName = Toggle Ring
		allowAnimationWhileShielded = False
	}
}
+PART[SSTU-SC-B-CMX]:NEEDS[Bluedog_DB]:FINAL
{
	@name = SSTU-SC-B-CMX-Apollo
	@title = SSTU - SC-B-CMX - Orbital Module Apollo
	!MODEL,1
	{
	}
	MODEL
	{
		model = Bluedog_DB/Parts/Apollo/bluedog_Apollo_Block2_ActiveDockingMechanism
		position = 0, 0.86468, 0
	}
	@node_stack_top = 0,0.90071977,0,0,1,0,1
	!MODULE[ModuleDockingNode]
	{
	}
	MODULE
	{
		name = ModuleDockingNode
		referenceAttachNode = top
		nodeType = apollo
		acquireForce = 3
		acquireTorque = 2
		stagingEnabled = False
		gendered = true
		genderFemale = false
	}
	MODULE
	{
		name = ModuleAnimateGeneric
		animationName = retract
		//isOneShot = true
		startEventGUIName = Retract Ring
		endEventGUIName = Extend Ring
		actionGUIName = Toggle Ring
		allowAnimationWhileShielded = False
	}
}
+PART[SSTU-SC-B-BPC]:NEEDS[Bluedog_DB]:FINAL
{
	@name = SSTU-SC-B-BPC-Apollo
	@title = SSTU - SC-B - BPC - Launch Abort System - Apollo
	@node_stack_bottom = 0,-3.58187023,0,0,-1,0,2
}

use at your own, neither me or Shadowmage or even CobaltWolf (since this is for his docking port) is responsible for bugs or anyone getting stuck on a fan because of this patch

Edited August 23, 2016 by JoseEduardo

[tater]

The huge torus (H) is large enough to have 2 levels, and is about 2100 m² of floor space, and that's not taking kerbal scale into account, which makes it more like 3300 m² compared to people. Manhattan has a population density such that each resident has ~36m² of space (a small apartment worth of space, but that includes all outside spaces as well for NYC). At that density, the station could hold 93. 

[CobaltWolf]

43 minutes ago, JoseEduardo said:

I'm just going to post this here and also ping @CobaltWolf since this also uses his mod...

http://imgur.com/a/cYHX8

RealScaleBoosters for the IU, tanks and interstages (I extended the S-II interstage for J-2X but in this case I was using a regular J-2), DECQ Saturn V for the Apollo payload adapter, SSTU for the Apollo CM and Engines, and BDB for the docking port+LEM

on my first test it went very well until the point where I was going to decouple the LEM, due to some collider weirdness with DECQ's LEM decoupler it blew the descent stage up, and now I need to test without that decoupler and use a stock one instead...

the docking worked flawlessly btw, as shown in the pics I kept the animation and it allowed me to soft-dock with the LEM, and then hard-dock after I retracted it

(oh, and yeah, BDB's DP is part of the CM, not a separate part... I had to make a new BPC for that...)

EDIT: here's a patch to add BDB's docking port to SSTU Apollo if anyone is interested (could be used as basis to add other docking ports through patches as well):

use at your own, neither me or Shadowmage or even CobaltWolf (since this is for his docking port) is responsible for bugs or anyone getting stuck on a fan because of this patch

That's awesome! @Jso said he encountered structural failures when a LEM was integrated into a launch stage. We are looking into it.

[JoseEduardo]

13 minutes ago, CobaltWolf said:

That's awesome! @Jso said he encountered structural failures when a LEM was integrated into a launch stage. We are looking into it.

with launch stage you mean like inside a fairing Apollo-style? if so I'll upload some logs that can be helpful to you and send you the link (should include 3 failures, 1 with DECQ's adapter, 1 with DECQ's adapter but with a stock decoupler for the LEM and 1 with Mage's Petal Adapter, but I suspect the last one was caused because I left the colliders option on)

Edited August 23, 2016 by JoseEduardo

[CobaltWolf]

Just now, JoseEduardo said:

with launch stage you mean like inside a fairing Apollo-style? I'll upload some logs that can be helpful to you and send you the link (should include 3 failures, 1 with DECQ's adapter, 1 with DECQ's adapter but with a stock decoupler for the LEM and 1 with Mage's Petal Adapter, but I suspect the last one was caused because I left the colliders option on)

I meant to say stack, sorry. Like, integrated structurally into a rocket with the CSM on top. Were all 3 failures at one of the LEM attach nodes? Were you using any struts - moreover, does adding them prevent the failures?

@Shadowmage sorry to hijack your thread.

[tater]

Let me preface this by saying that I have no idea what I'm talking about in this case, and it should be treated with all the care of any other harebrained idea... 

I was thinking about the large torus, and the image of orbital assembly. EPL-like behavior means launching some sort of parts (or delivering ore, etc for ISRU), then, poof, it appears.

I was wondering if there could be something akin to welding where a single unit, say Hab-H, is made, and some other parts are made that are considered sub assemblies. Hab-Ha, Hab-Hb, etc., since that you touch them together, and when the last one is in place (4 parts, 6 parts, whatever it is), Poof! those models are destroyed, and replaced with Hab-H. Ideally they'd snap together in a profoundly easy way, like they get within some decent distance and have super-magnet "docking."

The subassemblies need not be Hab-H quarters, they can be chunks that make sense, and that are reasonable cargos to lift, it's just a stand in for lifting X hundred tons in small packages. For an EPL standpoint, consider them purpose-build part canisters that happen to look like parts of a station.

[StickyScissors]

Finally got my GPU issue sorted out, here's some testing screenshots. They have to do with beautification mods more than anything, but who cares, they -do- at least have one part from SSTU.

 

[Domfluff]

11 hours ago, tater said:

I was wondering if there could be something akin to welding where a single unit, say Hab-H, is made, and some other parts are made that are considered sub assemblies. Hab-Ha, Hab-Hb, etc., since that you touch them together, and when the last one is in place (4 parts, 6 parts, whatever it is), Poof! those models are destroyed, and replaced with Hab-H. Ideally they'd snap together in a profoundly easy way, like they get within some decent distance and have super-magnet "docking."

I don't believe that's possible, but the way I think you'd actually do that (in terms of a functional USI-LS part at least) is to have each section have a part of the eventual hab values - e.g., if the ring had six elements, and each had two crew slots, +5 Kerbalmonths and a hab multiplier of 0.5 (so, 1.5 in effect), then the effective "final" station would have +30 kerbalmonths, a hab multiplier of 1 + (6*0.5) = 4 and 12 crew spaces in total.

(Actually, tempted to teach myself how to mod to do this, since I think this could be useful)

Now, as previously stated, I think I'd prefer a rigid station to be built this way, but if Shadowmage is deciding between a single rigid part or a single inflatable part (which perfectly sensible), then I think I'd much rather go for a massive inflatable, since it should be launchable, for varying degrees of apocalyptic rocket (but still plausible - anything up to a 200 ton payload is probably "fine" from a launchpad.

Obviously, Sea Dragon, Project Orion, etc. etc. are exceptions to this, but then there are good reasons for that.

[tater]

3 hours ago, Domfluff said:

I don't believe that's possible, but the way I think you'd actually do that (in terms of a functional USI-LS part at least) is to have each section have a part of the eventual hab values - e.g., if the ring had six elements, and each had two crew slots, +5 Kerbalmonths and a hab multiplier of 0.5 (so, 1.5 in effect), then the effective "final" station would have +30 kerbalmonths, a hab multiplier of 1 + (6*0.5) = 4 and 12 crew spaces in total.

(Actually, tempted to teach myself how to mod to do this, since I think this could be useful)

Now, as previously stated, I think I'd prefer a rigid station to be built this way, but if Shadowmage is deciding between a single rigid part or a single inflatable part (which perfectly sensible), then I think I'd much rather go for a massive inflatable, since it should be launchable, for varying degrees of apocalyptic rocket (but still plausible - anything up to a 200 ton payload is probably "fine" from a launchpad.

Obviously, Sea Dragon, Project Orion, etc. etc. are exceptions to this, but then there are good reasons for that.

Again this is a harebrained idea, to be taken with a shaker full of salt, not a realistic, crazy request  .

I wasn;t thinking of the parts even being usable at all during construction. It was more like a "no parts" version of EPL. Meaning no special construction facility parts, but that certain, huge constructions might be transported as sub assemblies, then considered assembled once they are all put together (and totally non functional before. You have a 5 part ring on orbit, and when the 6^th and final part is mated, poof, the model is replaced with our 1 part hab ring.The radial parts might be represented by partial construction (like the 2001 image) on the sub assemblies to keep the part narrow enough to put under a fairing the long way.

Alternately, There is a huge "supply pod" that is a sort of generic part container. In this case it might be 5m or even 6m in diameter. It might be textured to match the rigid hab, but again, it's just a cylinder. It masses some fraction of the total hab, and you put X of them together, then the hab appears, instead (same deal, the X containers explode and are replaced with the hab model). EPL is effectively just that, minus the explosion. You'd have to dock the supplies, then when you have enough you build the hab. Dunno which is easier, probably just a minimal parts EPL implementation (the suggested orbital assemble facility).

The only issue with an orbital assemble facility and our rigid torus, is that I worry about having enough room for it to appear.

EDIT: If you imagine the Hab-H forming with the same orientation as the inflatable, then whatever the assembly part is for EPL needs to be at the end of the station such that no other parts are at the same level, or farther so that when it appears, it is effectively docked to the hub. 

[Shadowmage]

Let me start this post by saying that it has always been my intent to have some parts that are needed to be constructed in-orbit (or in-situ on the ground) through EPL.  To me, that is the 'late game' of KSP; start with a small shipyard/station, build a larger shipyard/station, and with that build your super-massive interplanetary craft.  I have no desire to change that; it is how I play, and intend on continuing to do so.  Expect to see other super-large non-launchable (or at least not intended to be launched) parts when I start getting into the BaseCore series of parts.

I have never had a problem using EPL in that fashion.  Its quite simple; you ship up RocketParts to your orbital station (in lieu of modules / parts of parts), and it abstracts away all of the fiddly bits of orbital construction (docking, launching strange-shaped stuff, wonky physics/joints in atmo; not that I mind docking, but we lack the tools for precise alignment).  EPL requires an amount of rocket-parts equal to the dry mass of the vessel being constructed, so its not making it any easier from a total-mass-to-orbit perspective; merely allowing you to split the 'launch' up into however many smaller launches you need, and allowing for a more compact and easier-to-launch form-factor.  You could still put 150t of rocketparts onto a single rocket if you -wanted- to do it in a single launch.  You don't even need to mess with any of the processing or ISRU stuff to use it in this manner; just ship up the RocketParts and build your craft.  It even includes construction time and encourages the use of engineers on the station (requires at least one);  I consider all of those points to be a 'win' from both gameplay and realism points of view, at least for me (and also gives a use to stations after you've unlocked the tech tree and labs become cosmetic).  (This is aside to EPL being used with ISRU; that part I do find to be a -bit- unrealistic, but an acceptable abstraction from a gameplay standpoint.  UKS also helps solve that a bit by requiring a percentage of construction mass come from a 'specialized parts' resource that cannot be constructed through ISRU, so even far-flung shipyards need resupply of the 'technical' bits from Kerbin (think turbopumps, computers, the stuff that would be hard to manufacture without substantial infrastructure))

In regards to the vessel-spawning with shipyards -- I've never had a problem with that with EPL either.  What it does is examine the to-be-spawned vessel's colliders and places the vessel such that it is positioned in a non-colliding manner with the shipyard part (based on a reference transform / direction from the shipyard part).  This does require that the shipyard be at one end of the station so that there is adequate clearance, but I've never found that to be an issue (one of those engineering / craft-design bits, not really a challenge, but part of the game that I enjoy).

Yes I have mostly settled on the largest torus (H) being a rigid/metallic part.  Probably the next largest one as well (G).  With that said... I will -try- to include a 'deflate' option so that you guys can still launch them on rockets; but no guarantees, and even if I do it may be very ugly when deflated (the model for the rigid part might not work well with the scaling/deflating/retracting animation, but should look much better when inflated/deployed than the inflatables could; yes, the need for an animation can constrain how the geometry is done).

 

In regards to USI-LS:  Sorry, I haven't really begun to look into that aspect of the parts very much.  I need to figure out the stock balancing before much/any work can be done towards the LS balance; mass, crew capacity, and intended functionality for the parts all need to be mostly finalized before I can work on LS balance.  However I am trying to keep the LS stuff in perspective when working on the stock balancing.  But, this does not mean that I will be putting 100 seats on something just because USI-LS uses that for extra hab time -- its just as easy to increase the base hab time when I do the patches and keep the crew-counts at reasonable levels (actually easier from a few different points).

On that note I'm fairly certain I'll be going with a 'lower-crew-count but fully-equipped' perspective for most of these parts.  The crew counts I posted in the table yesterday are likely fairly close with what I'll go with;  ~30 crew max for the largest parts, and work down from there.  This means that in a stock game the parts will be a bit heavy from a mass-per-seat perspective compared to some of the other stock parts... but they are also more than just some seats in a can (e.g. the hitchiker and mk3 passenger section), and intended to represent the actual habitation space (sleeping areas, hygiene facilities, recreation areas, meeting/common areas, life-support machinery and storage).

 

In regards to science labs:  Sadly I do not think that any of the larger HAB parts will include science labs.  The stock science-lab module is an all-or-nothing setup; it uses all of the crew in the part, period -- there is no way to specify 'this lab should only use the 4 highest-level scientists in the part'.  I really would like to include labs in these parts, but don't think I can work out a reasonable way from a balance perspective.  Open to suggestions on this point though... perhaps there is some balance mechanism I've overlooked.

 

Updated render of the HAB-A inflatable, with end-caps, RCS, and prototype solar panel (undecided on the integrated solar panels; might be optional stand-alone parts) (switchable end-caps and adapters for these are still in place, they merely sit on top of the built-in end cap):

 

Testing out if I want to do discrete external tanks on the DOS modules, or have them 'cloth-covered' as they are IRL.  Quite undecided on this still; will need to do a bit more modeling work on the 'cloth-covered' to see if I like the finished look.  (Also of note are the mostly finished DOS solar panels in these renders, though only shown in their retracted state)

 

 

[JoseEduardo]

there's no such thing as "super-large non-launchable", you only need a bigger launcher that can launch the thing



and I can do far worse, that's just 61 NK-33 engines, I can get 61 F-1B

[Shadowmage]

23 hours ago, blowfish said:

For what it's worth, I think it would be pretty easy to modify the existing shaders to do this.  The shader source is already available through PartTools, and while I don't entirely understand the shading language, it looks straightforward enough to modify it to subtract another texture from the diffuse texture.  I think the bulk of the work would be in reconfiguring the models to use this.  But its probably worth waiting to see if 1.2 has a built-in solution for this.

Yeah, it may well come to that if PBR is not a thing in 1.2.  I'm decently familiar with GLSL from my stints doing Android game development (its basically a trimmed down C variant).  Shouldn't be too hard to add another texture slot and mix it with the diffuse texture.

Mostly I would be concerned if PartTools can export custom shaders to .mu files, whether KSP can read/load the custom shaders properly, and how much stuff in-game is hard-coded around the KSP shaders (as you've found out regarding the transparency and highlighting bits; they rely specifically on the shader and texture-slot names from the KSP shaders).

 

[tater]

@Shadowmage, parts are looking awesome. I totally get the EPL thing, it is a simplification that I really like, I just never liked the actual parts in that mod... I didn't know about the check for how it spawns the craft, either, which avoids what I thought was a problem (which isn't).

Regarding the science labs, that's too bad, as the large stations would obviously have room. I suppose that there could be small lab parts designed with attachment to the hub in mind. 

Here's an idea. Imagine you make a new adapter shape for the hubs. Call it "Lab-like." It's a cylinder, of the torus hub's base diameter, and a couple meters high. It is not a lab, it does nothing, it's an adapter. Make a copy of the adapter as a stand alone part, it's an actual lab. Give it 2 seats, and lab functionality. The larger the torus, the larger the lab adapter. You slap that on one side, and if you want symmetry, you use the adapter part on the other side. Maybe the -H torus could have a larger hub than even it would with an inflatable, so the lab is even bigger in diameter. The idea is the smallest way to add lab functionality, and larger tori (meaning larger diameter matching lab parts) could have more capability (science storage, etc).

[blowfish]

1 hour ago, Shadowmage said:

Yeah, it may well come to that if PBR is not a thing in 1.2.  I'm decently familiar with GLSL from my stints doing Android game development (its basically a trimmed down C variant).  Shouldn't be too hard to add another texture slot and mix it with the diffuse texture.

Mostly I would be concerned if PartTools can export custom shaders to .mu files, whether KSP can read/load the custom shaders properly, and how much stuff in-game is hard-coded around the KSP shaders (as you've found out regarding the transparency and highlighting bits; they rely specifically on the shader and texture-slot names from the KSP shaders).

Exporting the models should work according to my limited understanding (I don't think PartTools treats the KSP shaders differently than any of the other ones).  Loading into KSP ... I guess I sort of assumed it could be done with asset bundles, but I could definitely be wrong there.

[Shadowmage]

22 minutes ago, blowfish said:

Exporting the models should work according to my limited understanding (I don't think PartTools treats the KSP shaders differently than any of the other ones).  Loading into KSP ... I guess I sort of assumed it could be done with asset bundles, but I could definitely be wrong there.

Yes, would be doable with asset bundles.  I believe those use the Unity based serialization which should work fine for exporting the shader name and material(s) setup (it is intended to work with user-created shaders as far as I know).

However the workflow for using AssetBundles is a bit... inconvenient from my experience (have to keep a separate .prefab file of each model up-to-date (separate from its actual exported bundle file), and it takes custom loaders to get them in-game).  I would much rather stay away from AssetBundles if at all possible for those reasons.

On that note I've been deliberating on making a custom part-model exporter and loader that supports arbitrary shaders, materials, and animation types.  Not that I really want to put that much work into it (and it would be a fair bit of work), but I really dislike the AssetBundle workflow that much, and am getting sick of the incompatibilities and lack of updates for the .mu exporter.

 

[theJesuit]

3 hours ago, Shadowmage said:

Let me start this post by saying that it has always been my intent to have some parts that are needed to be constructed in-orbit (or in-situ on the ground) through EPL.  To me, that is the 'late game' of KSP; start with a small shipyard/station, build a larger shipyard/station, and with that build your super-massive interplanetary craft.  I have no desire to change that; it is how I play, and intend on continuing to do so.  Expect to see other super-large non-launchable (or at least not intended to be launched) parts when I start getting into the BaseCore series of parts.

Yes I have mostly settled on the largest torus (H) being a rigid/metallic part.  Probably the next largest one as well (G).  With that said... I will -try- to include a 'deflate' option so that you guys can still launch them on rockets; but no guarantees, and even if I do it may be very ugly when deflated (the model for the rigid part might not work well with the scaling/deflating/retracting animation, but should look much better when inflated/deployed than the inflatables could; yes, the need for an animation can constrain how the geometry is done).

On that note I'm fairly certain I'll be going with a 'lower-crew-count but fully-equipped' perspective for most of these parts.  The crew counts I posted in the table yesterday are likely fairly close with what I'll go with;  ~30 crew max for the largest parts, and work down from there.  This means that in a stock game the parts will be a bit heavy from a mass-per-seat perspective compared to some of the other stock parts... but they are also more than just some seats in a can (e.g. the hitchiker and mk3 passenger section), and intended to represent the actual habitation space (sleeping areas, hygiene facilities, recreation areas, meeting/common areas, life-support machinery and storage).

In regards to science labs:  Sadly I do not think that any of the larger HAB parts will include science labs.  The stock science-lab module is an all-or-nothing setup; it uses all of the crew in the part, period -- there is no way to specify 'this lab should only use the 4 highest-level scientists in the part'.  I really would like to include labs in these parts, but don't think I can work out a reasonable way from a balance perspective.  Open to suggestions on this point though... perhaps there is some balance mechanism I've overlooked.

You are getting me excited and interested in finally using EPL.  I've only just started using KCT together with Kerbalism in all its own glory.

Glad you've settled on the torus G and H.  If your intention is to build insitu or on an airless body then I would worry about 'deflate' too much.  Deflating might be to rearrange to fit inside a fairing, or to balance on a rocket.

I'm also glad for the lower crew count version.  Hopefully IVA's will spawn the Kerbals sitting on treadmills or gazing at pictures of Kerbin or rockets:)

The science lab balance could be a suggestion as a stock module?

 

Great work!  Peace.

[Domfluff]

Roverdude's Akademy part (UKS) has 12 crew, of which two can be scientists in the lab (and the lab has larger data/science storage, but that's neither here nor there)

No idea how it decides which crew use, mind you.

Part .cfg:
 

Spoiler

PART
{
    name = MK3_Akademy
    module = Part
    author = RoverDude 
    MODEL
    {
        model = UmbraSpaceIndustries/UKS/Assets/MKS_Module_III
        texture = Decal_375_00 , UmbraSpaceIndustries/UKS/Assets/Decal_375_99
    }
    rescaleFactor = 1
    scale = 1
    node_stack_Left = -2.35, -2.08, 0.0, -1, 0, 0.0,1
    node_stack_right = 2.35, -2.08, 0.0, 1, 0, 0.0,1
    node_stack_top = 0.0, 3.4, 0.0, 0.0, 1.0, 0.0,3
    node_stack_bottom = 0.0, -3.4, 0.0, 0.0, -1.0, 0.0,3
    TechRequired = advExploration
    entryCost = 8000
    cost = 35000
    category = none
    subcategory = 0
    title = UKS Training Akademy
    manufacturer = USI - Kolonization Division
    description = A field training center for training your Kerbonauts.  When training is conducted, attendees will gain experience based on the instructors present, and in their chosen field.  Up to one star when used on Kerbin, two stars while in orbit, and three stars if training takes place landed on another planet or moon.
    attachRules =1,0,1,1,0
    mass = 6.50
    dragModelType = default
    maximum_drag = 0.25
    minimum_drag = 0.25
    angularDrag = .5
    crashTolerance = 45
    breakingForce = 2800
    breakingTorque = 2800
    maxTemp = 1700
    bulkheadProfiles = size3

    vesselType = Base
    CrewCapacity = 12

    
MODULE
    {
        name = ModuleScienceContainer
        reviewActionName = Review Data
        storeActionName = Store Experiments
        collectActionName = Take Data
        evaOnlyStorage = True
        storageRange = 3.5
        allowRepeatedSubjects = True
    }
    MODULE
    {
        name = ModuleScienceLab
        containerModuleIndex = 0
        dataStorage = 1500
        crewsRequired = 2
        canResetConnectedModules = True
        canResetNearbyModules = True
        interactionRange = 5
        SurfaceBonus = 0.1
        ContextBonus = 0.25
        homeworldMultiplier = 0.1
        RESOURCE_PROCESS
        {
            name = ElectricCharge
            amount = 10
        }
    }

    MODULE
    {
        name = ModuleScienceConverter
        scientistBonus = 0.25    //Bonus per scientist star - need at least one! So 0.25x - 2.5x 
        researchTime = 7        //Larger = slower.  Exponential!
        scienceMultiplier = 5    //How much science does data turn into?
        scienceCap = 1500        //How much science can we store before having to transmit?        
        powerRequirement = 5    //EC/Sec to research
        ConverterName = Research
        StartActionName = Start Research
        StopActionName = Stop Research
    }    
    

    MODULE
    {
        name = MKSModule
        workSpace = 5
        livingSpace = 0
    }

    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
    }

    MODULE
    {
        name = ExWorkshop
        ProductivityFactor  = 5
    }

    MODULE
    {
        name = SpaceAcademy
    }
    
    MODULE
    {
        name = FSanimateGeneric
        animationName = Lights
        startEventGUIName = Lights On
        endEventGUIName = Lights Off
        availableInEVA = True
        availableInVessel = True
        EVArange = 5
        layer=3
        moduleID=0
        playAnimationOnEditorSpawn = False
    }

  MODULE
  {
      name = ModuleCommand
      minimumCrew = 0
      RESOURCE
      {
          name=ElectricCharge
          rate = 0.02777778
      }
  }
    MODULE
    {
        name = ModulePowerCoupler
    }        
}
 

 

[blowfish]

1 hour ago, Shadowmage said:

Yes, would be doable with asset bundles.  I believe those use the Unity based serialization which should work fine for exporting the shader name and material(s) setup (it is intended to work with user-created shaders as far as I know).

However the workflow for using AssetBundles is a bit... inconvenient from my experience (have to keep a separate .prefab file of each model up-to-date (separate from its actual exported bundle file), and it takes custom loaders to get them in-game).  I would much rather stay away from AssetBundles if at all possible for those reasons.

On that note I've been deliberating on making a custom part-model exporter and loader that supports arbitrary shaders, materials, and animation types.  Not that I really want to put that much work into it (and it would be a fair bit of work), but I really dislike the AssetBundle workflow that much, and am getting sick of the incompatibilities and lack of updates for the .mu exporter.

 

Huh.  I meant I thought that the standard .mu export would work with custom shaders on the model but that asset bundles would be necessary to load the shaders themselves ... is this not the case?

Edited August 24, 2016 by blowfish

[SpaceBadger007]

@Shadowmage was there a change to make everything have a max diameter value of 3.125m in the latest update? this is in sandbox mode.

[RedParadize]

On 22/08/2016 at 11:34 AM, Shadowmage said:

Balance and design on the HAB parts (inflatables, standard and torus).

1.) Should the two largest torus be inflatable or rigid/metallic? (different answers for each is okay)
2.) How heavy should the inflatable tori be? (I'll be basing the other inflatable hab masses off of the bigelow module masses).  The smallest one will likely be ~4 tons (HAB-E), with the next largest one being 6-8 tons (HAB-F).  The G and H models will highly depend on if they are inflatable or rigid.  Other input/suggestions are welcome though.
3.) Any desire for inflatable greenhouse/aerponics versions of the HAB-A/B/C (or even torus?).  These would share external dimensions with the others but include some windows and shrubbery, would still include some habitation space so that they were not useless in a stock game... but in a USI-LS game they would be enabled with converters (fertilizer+mulch->supplies).
4.) Crew capacities of the inflatables.  Should they be usable as space-hotels (>10 capacity), or intended as long-term habitation for smaller crews (e.g. perhaps 10 crew for even the largest torus)?  I'm leaning towards smaller crew capacities per-part.  I rarely use more then 4-6 crew on a mission, and even if I did, I could/would include multiple different habs and other parts with more seats.
5.) Usable storage volume.  Even at <10% storage volume, some of those inflatables will end up with several hundred thousand EC in a stock setup (~500,000 on the largest torus at current balance).  How much of the volume of these modules should be dedicated to storage?

 

I have been trying to answer this for two days but I am been quite busy lately. I hope i didn't miss the bus.

1: I like the idea of largest centrifuge being rigid/metallic. I would have like small rigid deployable centrifuge that are not torus but its all good. Can I suggest non torus for the large part? Cylinder would do, but fancy centrifuge like the 2010 Leonov would be intresting as well. Inflatable habitat might be innovative, but they are not magic, there is plenty of scenario where rigid part are preferable. As a exemple I suspect that your centrifuge will end up on interplanetry ship more often then on station, so there's that.

2: Torus should be relatively heavy compare to their capacity regardless of rigid/inflatable. There is much more surface on a torus than on a balloon like bigalow. If you decide to go for non-torus like cylinder for larger part, then there would be some opportunity to have a lesser mass/volume ratio. So they might still be heavy but give a nice bonus compared to a larger number of smaller part.

3: Yes for greenhouse, but no window please! It doesn't make any sence to have windows on anything in space anyway. About habitat and greenhouse sharing the same part, see the next point.

4: A station/Interplanetary Starship will never have the crew dencity of airliner or luxurious room of a ocean liners, regardless if its a space hotel. they will more likely have a compact barrack or pack of small room and the rest will be fonctionality/labs/storage space. A ratio of space dedicated to bedsroom of about 20% seem resonable, Having said that, Kerbalism use the number of empty seats to calculate confort. I have a suggestion regarding this. If you design a habitat with 6 beds, put extra seats around a table and other utility location. The stock limit would be 6, but it would allow user to tweak capacity and go for a high dencity crew rotation setup if they wish. It would also allow you to design a single IVA that fit multiple custom fonction without looking too weird. 

5: I think small one should have almost none outside of their fonction. Large one should have allot of free space.

 

Thanks for your nice work!

Edited August 24, 2016 by RedParadize

[Shadowmage]

48 minutes ago, blowfish said:

Huh.  I meant I thought that the standard .mu export would work with custom shaders on the model but that asset bundles would be necessary to load the shaders themselves ... is this not the case?

Ohh, yes, I believe you are correct there.  The shaders should be able to be loaded through AssetBundles, or alternatively you used to be able to compile them at run-time through plugin code (and whatever file reading you wanted to use), but I'm unsure if that is still the case.  I've honestly never tried loading a custom shader in KSP and only know the bits of info I've encountered browsing the forums/development threads.

I thought you were talking about needing to load the models-using-custom-shaders through AssetBundles, which is what I was a bit hesitant towards.

 

42 minutes ago, SpaceBadger007 said:

@Shadowmage was there a change to make everything have a max diameter value of 3.125m in the latest update? this is in sandbox mode.

No, but apparently there is a bug where if you load a career game and then go into sandbox mode, the tech-limits from the career game will still be enforced even in sandbox mode.

Try a clean start of KSP and then directly into sandbox mode (if you weren't already).  If the tech-limits are still in-place under those conditions, please let me know as that would be an additional bug that has not yet been reported/encountered.

 

58 minutes ago, Domfluff said:

Roverdude's Akademy part (UKS) has 12 crew, of which two can be scientists in the lab (and the lab has larger data/science storage, but that's neither here nor there)

No idea how it decides which crew use, mind you.

Part .cfg:
 

 

Interesting... I'll have to play around with that a bit.  I always thought that the 'crewRequired' specified the -minimum- number in order to press the 'start processing' button... but could be wrong on that. (the stock lab has zero listed in that field / default for the field is zero).

Thanks for the find... if that works out it may solve a couple of the compromises that I was going to have to put in place.

 

 

4 hours ago, tater said:

@Shadowmage, parts are looking awesome. I totally get the EPL thing, it is a simplification that I really like, I just never liked the actual parts in that mod... I didn't know about the check for how it spawns the craft, either, which avoids what I thought was a problem (which isn't).

Regarding the science labs, that's too bad, as the large stations would obviously have room. I suppose that there could be small lab parts designed with attachment to the hub in mind. 

Here's an idea. Imagine you make a new adapter shape for the hubs. Call it "Lab-like." It's a cylinder, of the torus hub's base diameter, and a couple meters high. It is not a lab, it does nothing, it's an adapter. Make a copy of the adapter as a stand alone part, it's an actual lab. Give it 2 seats, and lab functionality. The larger the torus, the larger the lab adapter. You slap that on one side, and if you want symmetry, you use the adapter part on the other side. Maybe the -H torus could have a larger hub than even it would with an inflatable, so the lab is even bigger in diameter. The idea is the smallest way to add lab functionality, and larger tori (meaning larger diameter matching lab parts) could have more capability (science storage, etc).

Aye, I've never personally liked the _models_ in EPL either -- I've always used the MKS/OKS/UKS replacements.   The code and plugin however are pure awesome; well polished with good and continued support, more stable between updates than many other mods, but still with active development and improved features being added.

Re: science labs -- might be a workable idea; a small selection of add-on lab parts using existing models, configs files are easy enough to put together.  Hopefully the bit of info above ^^^ will make all of that uneccessary though

15 hours ago, StickyScissors said:

Finally got my GPU issue sorted out, here's some testing screenshots. They have to do with beautification mods more than anything, but who cares, they -do- at least have one part from SSTU.

Nice pics

Glad you got it sorted out and hopefully it was just the faulty GPU.  Its never fun having to guess which component needs replaced/fixed or if there some other incompatibility in play, and wait for days/weeks for parts to get there, -hoping- the whole time that it was the right bit you ordered.

[RedParadize]

4 minutes ago, Shadowmage said:

Aye, I've never personally liked the _models_ in EPL either -- I've always used the MKS/OKS/UKS replacements.   The code and plugin however are pure awesome; well polished with good and continued support, more stable between updates than many other mods, but still with active development and improved features being added.

Re: science labs -- might be a workable idea; a small selection of add-on lab parts using existing models, configs files are easy enough to put together.  Hopefully the bit of info above ^^^ will make all of that uneccessary though

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.

[tater]

Given the numerous issues with career mode, a good deal of role play is required anyway. Heck, minus EPL (which I will certainly give a new look to), I'd launch the right tonnage, then hyperedit the torus there, and delete the deadweight tonnage. 

I saw a mod that uses the EPL stuff, but is a parts free version, maybe I'll try that.

Edited August 25, 2016 by tater

[JoseEduardo]

had some fun today trying to make a one part SM, and thanks to @Shadowmage it has integrated working solar panels

http://imgur.com/a/CY6Q4

I mixed the SDHI service module, BDB's Docking light, NearFutureSolar circular panels and SSTU fairing (not shown in the pics), HGA and RCS together, left the engine to be a separate part and added a toggleable interstage node to it just so I could use any engine with it and have the petal adapter attach to the right position, I also arranged the parts so it would resemble the ETS Apollo

had way more fun doing this than my last 20 hours of No Man's Sky

EDIT: here's the part file just in case anyone wants to use it or use it as basis for their own creation: https://dl.dropboxusercontent.com/u/58212317/SSTU-SC-B-SM2.cfg

(I used ubiozur welding at first, but then I had to fix it myself, so this was made importing the .mu files in blender, getting their positioning from there and adjusting manually... in the end there's just the first five lines of the file remaining from the original welding)

Edited August 25, 2016 by JoseEduardo