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

[RedParadize]

9 hours ago, Shadowmage said:

in the SSTUVolumeContainer, add:

subtractMass = false

Humm, if I put this, the container get bugged. 

[Shadowmage]

5 minutes ago, RedParadize said:

Humm, if I put this, the container get bugged. 

It works fine for the LC-POD parts;  how exactly is it getting bugged out?  (There could be a problem somewhere, as the LC parts also use a ModelSwitch setup that controls the mass directly)

Example from LC2-POD:

MODULE
{
	name = SSTUVolumeContainer
	volume = 250
	baseContainerIndex = 1
	subtractMass = false
	CONTAINER
	{
		name = Internal Tank
		percent = 100
		tankageVolume = 0
		tankageMass = 0
		ecHasMass = false
		defaultModifier = standard
		defaultResources = MonoPropellant,1;ElectricCharge,12
		resource = MonoPropellant
		resource = ElectricCharge
		modifier = standard
	}
	CONTAINER
	{
		name = Ascent Fuel Tank
		percent = 0
		tankageVolume = 0.15
		tankageMass = 0.15
		defaultModifier = standard
		defaultFuelPreset = LFO
		resource = LiquidFuel
		resource = LqdHydrogen
		resource = Oxidizer
		resource = MonoPropellant
		resource = Aerozine50
		resource = NTO
		resource = ElectricCharge
		modifier = standard
		modifier = lbo
		modifier = zbo
		modifier = light
		modifier = structural
	}
}

 

[RedParadize]

Oh... What I had is this:

Spoiler

    MODULE
    {
        name = SSTUVolumeContainer
        volume = 24360
        enableContainerEdit = true
        enableFuelTypeChange = true
        baseContainerIndex = 0
        CONTAINER
        {
            name = Main Tank
            percent = 100
            tankageVolume = 0.15
            tankageMass = 0.15
            defaultModifier = standard
            defaultFuelPreset = LFO
            resource = LiquidFuel
            resource = LqdHydrogen
            resource = Oxidizer
            resource = MonoPropellant
            resource = XenonGas
            resource = Aerozine50
            resource = NTO
            resource = ElectricCharge
            resource = Lithium //custom stuff, works fine.
            resource = XenonGas //custom stuff, works fine.
            resource = ArgonGas //custom stuff, works fine.
            resource = Food //custom stuff, works fine.
            resource = Oxygen //custom stuff, works fine.
            modifier = standard
            modifier = lbo
            modifier = zbo
            modifier = light
            modifier = structural
            modifier = standard2 //custom stuff, works fine.
            modifier = standard3 //custom stuff, works fine.
            modifier = standard4 //custom stuff, works fine.
        }
}

 

so do I need to remove "enableContainerEdit = true" or "enableFuelTypeChange = true" ? Or is it "baseContainerIndex = 0" that need to be set "to =1" ?

Edited July 13, 2016 by RedParadize

[Shadowmage]

4 minutes ago, RedParadize said:

Oh... What I had is this:

 

so do I need to remove "enableContainerEdit = true" or "enableFuelTypeChange = true" ? Or is it "baseContainerIndex = 0" that need to be set "to =1" ?

No, those lines should be fine as you have them above; they determine if the 'configure container' button shows up and if the 'fuel type' slider/buttons are available.  The baseContainerIndex is used mostly by the ModelSwitch module to determine what container to edit; you can safely (and should) leave it set to zero ('0') for your purposes (as you only have a single container anyway, index = 1 would throw an index out of bounds exception if it were used).

 

Adding the subtract-mass field to your config, it should look like:

 	MODULE
    {
        name = SSTUVolumeContainer
        volume = 24360
        enableContainerEdit = true
        enableFuelTypeChange = true
        baseContainerIndex = 0
		subtractMass = false
        CONTAINER
        {
            name = Main Tank
            percent = 100
            tankageVolume = 0.15
            tankageMass = 0.15
            defaultModifier = standard
            defaultFuelPreset = LFO
            resource = LiquidFuel
            resource = LqdHydrogen
            resource = Oxidizer
            resource = MonoPropellant
            resource = XenonGas
            resource = Aerozine50
            resource = NTO
            resource = ElectricCharge
            resource = Lithium //custom stuff, works fine.
            resource = XenonGas //custom stuff, works fine.
            resource = ArgonGas //custom stuff, works fine.
            resource = Food //custom stuff, works fine.
            resource = Oxygen //custom stuff, works fine.
            modifier = standard
            modifier = lbo
            modifier = zbo
            modifier = light
            modifier = structural
            modifier = standard2 //custom stuff, works fine.
            modifier = standard3 //custom stuff, works fine.
            modifier = standard4 //custom stuff, works fine.
        }
} 

 

Literally the only thing that config setting does is to tell the module to zero out the config-specified mass or not:

		public float GetModuleMass(float defaultMass, ModifierStagingSituation sit)
        {            
            return subtractMass ? -defaultMass + modifiedMass : modifiedMass;
        }

(and wow, the tabs on those quotes/code blocks are horrible.... thanks forum software, always nice working with you...)

 

How exactly is it getting 'bugged out'?

[RedParadize]

Damn, sorry I posted this while I was trying to figure out what was wrong. It had subtractMass = false. like this:

 

Quote

        name = SSTUVolumeContainer
        volume = 72600
        enableContainerEdit = true
        enableFuelTypeChange = true
        subtractMass = false
        baseContainerIndex = 0

 

Let me try again, I don't want to waist your time. 

[RedParadize]

The bug is still there. If its the first part created0 I get Fueltype set to "custom" and I can't change anything. As a second part, I can't attach it. Represented in this log:

 

Spoiler

(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

[Crew Assignment]: Part OPT L Space Shuttle Cockpit holds 10 crew, but only 4 are available. Auto-hiring is disabled or not allowed at this point.
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

Module SSTUVolumeContainer threw during OnStart: System.ArgumentException: An element with the same key already exists in the dictionary.
  at System.Collections.Generic.Dictionary`2[System.String,SSTUTools.SubContainerDefinition].Add (System.String key, SSTUTools.SubContainerDefinition value) [0x00000] in <filename unknown>:0
  at SSTUTools.ContainerDefinition..ctor (.ConfigNode node, Single tankTotalVolume) [0x00000] in <filename unknown>:0
  at SSTUTools.SSTUVolumeContainer.loadConfigData () [0x00000] in <filename unknown>:0
  at SSTUTools.SSTUVolumeContainer.OnStart (StartState state) [0x00000] in <filename unknown>:0
  at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

deleting part l.8m.cockpit
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

Module SSTUVolumeContainer threw during OnStart: System.ArgumentException: An element with the same key already exists in the dictionary.
  at System.Collections.Generic.Dictionary`2[System.String,SSTUTools.SubContainerDefinition].Add (System.String key, SSTUTools.SubContainerDefinition value) [0x00000] in <filename unknown>:0
  at SSTUTools.ContainerDefinition..ctor (.ConfigNode node, Single tankTotalVolume) [0x00000] in <filename unknown>:0
  at SSTUTools.SSTUVolumeContainer.loadConfigData () [0x00000] in <filename unknown>:0
  at SSTUTools.SSTUVolumeContainer.OnStart (StartState state) [0x00000] in <filename unknown>:0
  at Part.ModulesOnStart () [0x00000] in <filename unknown>:0 
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

l.6m.crew added to ship - part count: 2
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

NullReferenceException: Object reference not set to an instance of an object
  at SSTUTools.SSTUVolumeContainer.updatePersistentData () [0x00000] in <filename unknown>:0
  at SSTUTools.SSTUVolumeContainer.OnSave (.ConfigNode node) [0x00000] in <filename unknown>:0
  at PartModule.Save (.ConfigNode node) [0x00000] in <filename unknown>:0
  at ShipConstruct.SaveShip () [0x00000] in <filename unknown>:0
  at ShipConstruction.CreateBackup (.ShipConstruct ship) [0x00000] in <filename unknown>:0
  at EditorLogic.SetBackup () [0x00000] in <filename unknown>:0
  at EditorLogic.<SetupFSM>m__101 () [0x00000] in <filename unknown>:0
  at KerbalFSM.RunEvent (.KFSMEvent evt) [0x00000] in <filename unknown>:0
  at KerbalFSM.updateFSM (KFSMUpdateMode mode) [0x00000] in <filename unknown>:0
  at KerbalFSM.UpdateFSM () [0x00000] in <filename unknown>:0
  at EditorLogic.Update () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

 

And here is the full MM patch, just in case I mess up!

Spoiler

@PART[jl_3m_adaptor,jl_7m_adaptor,l_3m_bicoupler,l_6m_cargo,l_6m_crew,l_6m_fuselage,l_7m_cargoTail,l_8m_cockpit,]
{    
@mass *= 0.5 
    MODULE
    {
        name = SSTUVolumeContainer
        volume = 24360
        enableContainerEdit = true
        enableFuelTypeChange = true
        baseContainerIndex = 1
        subtractMass = false
        CONTAINER
        {
            name = Main Tank
            percent = 100
            tankageVolume = 0.15
            tankageMass = 0.15
            defaultModifier = standard
            defaultFuelPreset = LFO
            resource = LiquidFuel
            resource = LqdHydrogen
            resource = Oxidizer
            resource = MonoPropellant
            resource = XenonGas
            resource = Aerozine50
            resource = NTO
            resource = ElectricCharge
            resource = Lithium
            resource = XenonGas
            resource = ArgonGas
            resource = Food
            resource = Oxygen
            modifier = standard
            modifier = lbo
            modifier = zbo
            modifier = light
            modifier = structural
            modifier = standard2
            modifier = standard3
            modifier = standard4
        }
}

 

Edited July 13, 2016 by RedParadize

[Shadowmage]

3 hours ago, RedParadize said:

The bug is still there. If its the first part created0 I get Fueltype set to "custom" and I can't change anything. As a second part, I can't attach it. Represented in this log:

 

 

And here is the full MM patch, just in case I mess up!

 

 

You have XenonGas listed twice, causing the 'duplicate key' error that is occurring in your log;  try removing one of those entries, and see if that cleans it up  

(I should probably change the code to log the error and handle it more gracefully; but at least it lets you know when the config has errors... just need to know how to read the source to figure that bit out =\)

[rasta013]

Maybe I'm missing something as it's late, I'm exhausted and only skimmed the last 2 pages of posts....

Couldn't you hard code the crew capacity and have the IVAs appropriate to the chosen part?  For instance, a 1.25m habitation only allows space for say 2 kerbals.  If you move it up to 2.5m it becomes 4 and 3.75 becomes 6.  With the IVAs they would be grabbed and used as appropriate according to which size is chosen for the part.  Basically the idea would be to restrict the sizing to fairly standard versions and allow nothing in between.  How many and which sizes could be figured out fairly easily but this would at least give some variety in station making that isn't available right now.  I don't know if this is viable or not but it was something that occurred to me...

EDIT:  Hell, it might not even be advisable because I'm not even sure how this would work out in part reduction since the models wouldn't be procedural in really any sense of the word...I don't know...

Edited July 13, 2016 by rasta013

[Domfluff]

Might be worth pointing out that Roverdude's upcoming "Konstruction" mod (which may or may not be the next iteration of UKS) is also going to have "welding" added to the stock docking ports.

[Domfluff]

20 hours ago, Shadowmage said:

Any other types of parts that are severely lacking in availability, or any other part-reduction type parts that could be made?  Pictures/examples for any suggestions would be extremely helpful.  In the end the goal is to enable nice and coherent looking fully functional stations, with a lower part count (and CPU overhead) than could be accomplished with stock or other mods' parts alone.

My career modlists almost always begin with most of Roverdude + Nertea's mods. SSTU has recently joined that list, after some wibbling over whether I was happy including the procedural parts. (Thank you!).

Aside from Welding being something that Roverdude is releasing soon (so, potential conflicts), the main thing I've been lacking are habitation modules, ideally inflatable ones. The ones in Ven's stock revamp are fine, but a little overpowered in some regards (you can stick them anywhere, and they compress to a ridiculous degree). Porkjet's are rarely up to date with the current KSP build for obvious reasons, and the 1.25m end nodes can make them a little awkward to use.

I do think it's sensible to keep to 2.5m as the standard module size. KSP Shuttles tend to use the Mk3 cargo bay, which is ideal for 2.5m parts.

I really like the idea of rigid torus sections - there's no really good way to do this right now, and with welding this would be excellent. I do think this would be sensible if there was (in addition) a non-EPL way of managing these - perhaps something to increase the mass limits for manually attaching via KAS? (e.g., the manipulator pods from 2001 - if this was inside the KAS range for attachment, this limit would be increased significantly, or perhaps the pod itself could act as a really strong Kerbal for KAS. No idea if that's possible. If that *was* possible, then this is also a property that a Canadarm-like part could have - rather than trying to actually animate it as per Infernal Robotics (etc.), if it's possible to design for effect, and use a nearby arm to increase KAS range/mass limits then that would make a lot of sense to me, I think.)



One option would be to have the ability to convert (through an Engineer) modules on the fly somewhat - possibly as a Wet Workshop or similar. This could be important earlier in the tech tree than later ISS-like or Von Braun Wheel-like stations.

Integrating science modules is a thing. Whether this is just the stock modules or including some of Dmagic Orbital Science's modules, having a single 2.5m part with multiple experiments would decrease part count by quite a bit, as would integrating antenna with a science lab.

Stations in KSP have a few uses - they are good for research labs, as propellant depots, and in orbital construction (all-up, or just as a staging post for holding a stage or two for a while). UKS is going to push a few of these further, especially as far as logistics is concerned, but full details aren't available on that quite yet, but Roverdude has hinted that he wants his own EPL solution at some point, and I'm fully expecting that propellant depots will end up being automated in a similar manner that Planetary Resources are currently. With 1.2 they will presumably also be good as relays for comms networks, however that mechanic will actually pan out.

This means that the main parts to develop would be those that help construction, store fuel, transmit data and science. Since you're not trying to make a "gameplay" mod so much as a "parts" mod, this means you are limited in some of the things you can do.

One major part that I haven't seen anyone build is a zero-boil off propellant depot, with a deployable sun shield:



In terms of having this make sense in KSP terms (since you already offer ZBO tanks) - perhaps these have a lighter tank structure than the ZBO versions, but they only offer zero boil-off when the shroud is deployed? They could also be lighter on the EC use (therefore fewer batteries needed for the trip through the dark side).


Atomic Rockets has a link to this paper: http://mikesnead.net/resources/spacefaring/tech_paper_architecting_rapid_growth_in_space_logistics_capabilities.pdf

Which proposes a logistics/orbital construction station looking like this:

The hangers are there for (apparently) Dreamchaser-sized spaceplanes and capsules, allowing for unloading cargo in shirt sleeves (so, quickly).

Edited July 13, 2016 by Domfluff

[Domfluff]

Last thought - if the structural girders could either all have ladders integral, or just be climbable like ladders, then that would improve building minor things on EVA as well with KAS.

[Shadowmage]

22 hours ago, RedParadize said:

About IVA limitation, A work around could be to have the IVA as a completely separated part:

1- A single Pressured hull part : A basic frame that have nodes on its side to attach IVA, one or more depending on its size. Size, and some external option and feature can be changed, like what you have with SSTU tanks, plus some extra option that work the same way than mount, like external experiment, storage etc.

2- multiple IVA parts: Attachable only to node. In VAB its a simple hatch or window, with a red or green cylinder that represent the volume of the interior once attached to Pressured hull. Its red if it clip, its green if it doesn't. Whats good about this is that it would allow in orbit modification using KAS.

Its more part, but its customizable, and its not limited to Station It also works for interstellar spaceship and possibly for deployable part and spaceplane. What do you think?

 

19 hours ago, RedParadize said:

Thinking a bit on the Idea of separated IVA, There is some mechanics that would garantee IVA fit in a given presured hull without being too complicated (to play with at least!). 

Say Hulls length can be adjusted by section of 2m. Player chose to have a 8m long hull with two attachment node on its side. One at 3 meters from the top, one at 1m of the bottom. The one at 3m from the top would allow "deployment" of IVA that are shorter than 6m, could still be 2m or 4m. The one meter from the bottom would only allow 2m. Again, IVA could be storage as well, and they would use the same mechamics as a regular tank, when switching to transparent, you would see the 6m IVA plus a 2m tank.

Now say you can have multiple diameter hull. Say 1.25 and 2.5m for a start. In VAB, Player decide to have a hull 8m long hull, a section that accept a single full size 2.5x4m IVA and another that accept four small 1.25x4m IVA. Player can chose to decide to have a lab plus 4 experiment, storage etc... Or say a hab with a comune room and 4 individual bed.

A bit like Universal Storage, but with a potentialy larger scope. Again, these are simple suggestion. I have the tendancy to trow them at every modder around. Sorry about that...

About atomic rocket website, I feel realy sorry for you if you never visited it. Realy, its cover everything related to space and Si-Fy in the best retro format possible.

What you are describing would be an excellent solution if KSP's performance was not part count limited.  I would ideally do modular parts in such a fashion; a 'core' part that is mostly structural, and plug-in additional parts to add functionality and fill in the module slots in the core part.  This is the way KSP is designed to work, and I would absolutely love to be able to set things up like that.

Sadly, as every additional part you add to a vessel decreases performance in a non-linear fashion... I simply cannot endorse any such methods currently.  Would it be a cool mechanic?  Yes, it could/would be awesome.  Would it turn already poor-FPS on large stations into absolute slideshows? Yes again.

I would rather have slightly fewer options and actually be able to play the game at reasonable frame rates than have super-cool features that play at a crawl.  <60 fps bugs me; it is why I build my own computers and use fairly high-end components for them; it is the reason I started this mod in the first place.  With other graphics limited games it is often easy enough to lower a few of the graphics options to achieve smooth framerates.  This does not work in KSP as it is already graphically simple and all of the 'lag' comes from the physics/CPU end of things (where even my highly overclocked CPU can only go so far to alleviating the problem).  The situation has improved in 1.1 quite a bit compared to 0.90/1.0.x, but not nearly enough that I could endorse modularity at the part-level.

 

 

12 hours ago, rasta013 said:

Maybe I'm missing something as it's late, I'm exhausted and only skimmed the last 2 pages of posts....

Couldn't you hard code the crew capacity and have the IVAs appropriate to the chosen part?  For instance, a 1.25m habitation only allows space for say 2 kerbals.  If you move it up to 2.5m it becomes 4 and 3.75 becomes 6.  With the IVAs they would be grabbed and used as appropriate according to which size is chosen for the part.  Basically the idea would be to restrict the sizing to fairly standard versions and allow nothing in between.  How many and which sizes could be figured out fairly easily but this would at least give some variety in station making that isn't available right now.  I don't know if this is viable or not but it was something that occurred to me...

EDIT:  Hell, it might not even be advisable because I'm not even sure how this would work out in part reduction since the models wouldn't be procedural in really any sense of the word...I don't know...

Would work, sure.  But it removes all of the 'pros' from modular parts; which for me as a developer is 'fewer things to model'.  Having to create a distinct model (and part config) for each variant is... very time consuming.  I may make one or two variants or different size options for some of the parts, but I won't be doing much more than that.

 

 

4 hours ago, Domfluff said:

Might be worth pointing out that Roverdude's upcoming "Konstruction" mod (which may or may not be the next iteration of UKS) is also going to have "welding" added to the stock docking ports.

Funny you bring that up... I actually got the initial 'push' to do the welding docking port after seeing RD's initial prototype setup (back in Jan or so I think?). 

From what I can tell though, we are going about it in different fashions; his method leaves extra parts in place / replaces the docking ports with dummy models/trusses.  Mine removes them entirely.

-If- his method can fully remove the docking port parts, I may look into using it/supporting it.  However, the code for mine is already written and functional, and only really needs the proper models and their animations to be created (the prototype models I made do work, but are nowhere near production quality and were just good enough to test the concept).
 

 

3 hours ago, Domfluff said:

My career modlists almost always begin with most of Roverdude + Nertea's mods. SSTU has recently joined that list, after some wibbling over whether I was happy including the procedural parts. (Thank you!).

Aside from Welding being something that Roverdude is releasing soon (so, potential conflicts), the main thing I've been lacking are habitation modules, ideally inflatable ones. The ones in Ven's stock revamp are fine, but a little overpowered in some regards (you can stick them anywhere, and they compress to a ridiculous degree). Porkjet's are rarely up to date with the current KSP build for obvious reasons, and the 1.25m end nodes can make them a little awkward to use.

I do think it's sensible to keep to 2.5m as the standard module size. KSP Shuttles tend to use the Mk3 cargo bay, which is ideal for 2.5m parts.

I really like the idea of rigid torus sections - there's no really good way to do this right now, and with welding this would be excellent. I do think this would be sensible if there was (in addition) a non-EPL way of managing these - perhaps something to increase the mass limits for manually attaching via KAS? (e.g., the manipulator pods from 2001 - if this was inside the KAS range for attachment, this limit would be increased significantly, or perhaps the pod itself could act as a really strong Kerbal for KAS. No idea if that's possible. If that *was* possible, then this is also a property that a Canadarm-like part could have - rather than trying to actually animate it as per Infernal Robotics (etc.), if it's possible to design for effect, and use a nearby arm to increase KAS range/mass limits then that would make a lot of sense to me, I think.)



One option would be to have the ability to convert (through an Engineer) modules on the fly somewhat - possibly as a Wet Workshop or similar. This could be important earlier in the tech tree than later ISS-like or Von Braun Wheel-like stations.

Integrating science modules is a thing. Whether this is just the stock modules or including some of Dmagic Orbital Science's modules, having a single 2.5m part with multiple experiments would decrease part count by quite a bit, as would integrating antenna with a science lab.

Stations in KSP have a few uses - they are good for research labs, as propellant depots, and in orbital construction (all-up, or just as a staging post for holding a stage or two for a while). UKS is going to push a few of these further, especially as far as logistics is concerned, but full details aren't available on that quite yet, but Roverdude has hinted that he wants his own EPL solution at some point, and I'm fully expecting that propellant depots will end up being automated in a similar manner that Planetary Resources are currently. With 1.2 they will presumably also be good as relays for comms networks, however that mechanic will actually pan out.

This means that the main parts to develop would be those that help construction, store fuel, transmit data and science. Since you're not trying to make a "gameplay" mod so much as a "parts" mod, this means you are limited in some of the things you can do.

One major part that I haven't seen anyone build is a zero-boil off propellant depot, with a deployable sun shield:


In terms of having this make sense in KSP terms (since you already offer ZBO tanks) - perhaps these have a lighter tank structure than the ZBO versions, but they only offer zero boil-off when the shroud is deployed? They could also be lighter on the EC use (therefore fewer batteries needed for the trip through the dark side).


Atomic Rockets has a link to this paper: http://mikesnead.net/resources/spacefaring/tech_paper_architecting_rapid_growth_in_space_logistics_capabilities.pdf

Which proposes a logistics/orbital construction station looking like this:

The hangers are there for (apparently) Dreamchaser-sized spaceplanes and capsules, allowing for unloading cargo in shirt sleeves (so, quickly).

Thanks for the resources and suggestions.

Sun shield -- perhaps; it would make sense for a propellant depot, and could be balanced to be lighter / more efficient for those uses.  Would need to find a way to integrate the functionality into the boiloff plugin though, which may be difficult as they would be residing on separate parts.

Shipyard -- I kind of liked their long/linear shipyard concept.  No idea if it would work with EPL's model setup though (I believe it expects vessels to be constructed at one end of the part with lots of clearance on every side).

Wet workshop -- has been suggested a few times.  Mostly it runs afoul of KSPs module-swapping limitations; there is no way to have a part be distinctly a fuel tank for some of its life and distinctly a hab/lab part for the rest -- the modules would have to be always present and somehow hacked to be disabled/unusable while the part had fuel in it.  In short... would be a ton of code for not much return.  I also highly doubt that I would ever use them in my games, so the likelihood of me making them is minimal.  I would much rather have proper station parts even if they require a bit more rocket below them to get into orbit.

Integrating science experiments -- could be done, but cannot be done in a modular fashion (KSP module swapping limitations/inability to handle it).  So a part would always have the experiments on it.  Would also limit the availability of said station parts until the stock experiment part had been unlocked as well; which I'm not fond of.  I've even thought on how to make a multi-experiment science package that improves as you unlock the other experiments in the tech tree; but again, it runs into the limitation/inability to dynamically add modules to parts.   (Note:  Most science parts are physics-less parts which have little to no impact on CPU use; they are for most purposes considered to be part of whatever they are mounted on; so integrating them into other parts does little towards performance improvements)

Torus' -- would not be segments, but would be a single fully complete torus part.  This is not intended to be launched into orbit, and is solely meant to be constructed through a bootstrap station while already in orbit.  Segmented torus' would simply be too many parts from a part-count perspective.

 

1 hour ago, Domfluff said:

Last thought - if the structural girders could either all have ladders integral, or just be climbable like ladders, then that would improve building minor things on EVA as well with KAS.

Maybe;  I'll have to investigate how big of performance hit 'Trigger colliders' are (which is what is used by hatches and ladders).

At least the crewed parts would come with integrated ladders, and some of the other parts where appropriate.  For the purely 'structural' bits though, I'll be relying heavily on Nertea's Near-Future Octo-Trusses, and they do not come with ladders.  Nothing (simple or easy) that I can do to solve that.

 

 

In other news, I did some investigation / poking around with PorkJet's Hab pack last night.  Apparently dynamic crew capacity can work, but has a few issues (such as not showing properly in the editor), and I've not yet tested the IVAs to see if they can be swapped around successfully.

It -might- be possible to have a single modular part with multiple crew options and model switching.  However this still does not remove the problems associated with scaling a crewed part -- window and hatch sizes and IVA size/position in relation to the exterior model.  So modular, maybe.  Scalable, no.

Have also started playing around with how to animate inflatables.  Have some tests tonight to do to see if I can get ShapeKeys/BlendShapes working in KSP, but I have my doubts (last I heard they work fine in Unity, but PartTools does not export them/import them properly into the game).  They do make some very nice looking inflation animations though, perfectly suited for inflatables.  Would be a shame if they don't import/work, and would leave me searching for other methods to do them....

[RedParadize]

14 hours ago, Shadowmage said:

 

You have XenonGas listed twice, causing the 'duplicate key' error that is occurring in your log;  try removing one of those entries, and see if that cleans it up  

(I should probably change the code to log the error and handle it more gracefully; but at least it lets you know when the config has errors... just need to know how to read the source to figure that bit out =\)

 

Mea Culpa... I do to much change at the same time, I took for granted that resource were configured right. Don't doubt your code because of a error prone user like me!

[tater]

You could have a linear shipyard, but with a platform on one end (the "bottom"). The simple dynamic in the VAB might be that you can build in the Z direction (up), in the +X direction (towards the door), or +-Y direction (left and right, while looking at the door), but not the -X direction (away from the door) any more than a radius of 7.5 meters (I have no idea if those are the actual directions, I'm stating it for clarity). 

 

In this case it's constrained on just the one side (I built the girders on the "inside" side of the VAB. It's a central 2mx2m plate part with 3 more radially outwards. The SSTU tank is 10m.

Edited December 19, 2017 by tater

[cxg2827]

34 minutes ago, Shadowmage said:

It -might- be possible to have a single modular part with multiple crew options and model switching.  However this still does not remove the problems associated with scaling a crewed part -- window and hatch sizes and IVA size/position in relation to the exterior model.  So modular, maybe.  Scalable, no.

A possible option that can allow modularity (and possibly scalability) would be to develop the internal habitable spaces is a fashion such that the different size variants utilize common IVA features. With this you can make objects such as viewports, bulkheads, hatches, corridors, etc. as props.

[RedParadize]

About the Separated IVA idea, I understand completely, I am convince what you will come up with will be fantastic. Its just a shame there is no mechanics in KSP to simplify calculation when the part count is too large. About that, is it the phisics that drain frame rate the most? If yes, I wonder if they would be a way to have part that are physicsless, like adding part mass to its parent...

[tater]

Given the odd nature of using the VAB for EPL stuff, perhaps a simple method to ensure ease of building would be to provide the deployed dock, or a cartoonish analog, as a single VAB part. You can then place that part, and the default direction when you select the part is how it will be relative to the craft in space. Attach it to the bottom (or top, whatever your system requires), and if your craft doesn't hit the framework, it's good in space.

[blowfish]

33 minutes ago, RedParadize said:

If yes, I wonder if they would be a way to have part that are physicsless, like adding part mass to its parent...

KSP does support this, but it generally only works for very small parts.  For instance, when heat shields were first introduced, they did this, but it caused pods to be unstable on re-entry because the CoM was in the wrong place.

[Shadowmage]

Test / preview of BlendShapes based inflatable animation (this is not indicative of the parts I will be making, merely a test as I learn how to use the different animation systems):

[rasta013]

2 hours ago, Shadowmage said:

Would work, sure.  But it removes all of the 'pros' from modular parts; which for me as a developer is 'fewer things to model'.  Having to create a distinct model (and part config) for each variant is... very time consuming.  I may make one or two variants or different size options for some of the parts, but I won't be doing much more than that.

Yup.  Those are the kinds of ideas I get after a 39 hour day on 5 hours of sleep.  After waking up from 11.5 hours of sleep I realized exactly what my idea would entail time wise for you.  Not a good solution...

[Shadowmage]

Good News (potentially very good if it pans out):  A basic test of a new MODULE switching setup seems to be working.  This is a non-hacky setup that... should? work with any/all PartModules (compared to my previously hacky implementation used on the old LanderCore fuel parts).  For those wondering why this is a big deal... umm.... its hard to explain... but basically this means that I -CAN- alter functionality of parts while in the editor.

Now, this is only a preliminary test that worked, I haven't yet started on any actual implementation.  But I was able to add a module at runtime that does not exist in the parts .cfg file, alter persistent data for that module, and have it persist across game reloads, without spamming the user about 'suchandsuch module is missing..blahblah'.  So far that is a major win, and more than I had expected to be able to accomplish (which is why my plans so far have excluded any module switching).

If it works out this would mean that modular parts could have a lot more 'modularity' to them, opening up a whole new level of customization to parts, and enabling many previously dismissed concepts to potentially be realized (or at least re-examined). 

 

On to the bad news:
BlendShape based animations are not supported by KSP's .mu model format.  Sad.  Disappointing.  Not unexpected or surprising.

Spoiler

[LOG 16:45:05.317] InflatablePrototype1, , blendShape.Key 1, UnityEngine.AnimationCurve
[ERR 16:45:05.319] File error:
(null)
  at (wrapper managed-to-native) UnityEngine.AnimationClip:SetCurve (string,System.Type,string,UnityEngine.AnimationCurve)
  at PartReader.ReadAnimation (System.IO.BinaryReader br, UnityEngine.GameObject o) [0x00000] in <filename unknown>:0
  at PartReader.ReadChild (System.IO.BinaryReader br, UnityEngine.Transform parent) [0x00000] in <filename unknown>:0
  at PartReader.ReadChild (System.IO.BinaryReader br, UnityEngine.Transform parent) [0x00000] in <filename unknown>:0
  at PartReader.Read (.UrlFile file) [0x00000] in <filename unknown>:0

[WRN 16:45:05.321] Model load error in 'F:\KSP11\GameData\SSTU\Assets\ST-HAB-Test.mu'

 

That (null)/blank spot is supposed to be a Type/class name, and in this case it should be a SkinnedMeshRenderer

I should probably log that as a bug on the SQUAD tracker as I'm sure there are a few others who would make use of BlendShapes type animations.

But... I've got a couple ideas to look into on how to fix it/work around it for now.  As far as I know the vertex data for the skinned mesh-renderer setup is transferred properly, but I'm not sure if the BlendShapes keys are loaded into the binary model data or not, or even how they are stored in Unity.

If the BlendShapes keys are stored properly in the model data, I should be able to manually reconstruct the animation through a custom plugin, add it to the necessary models/transforms as a standard animation component/animation clip setup, and reference that animation in a regular animation module.  This will likely be my next bit of investigation, hopefully will have updates a bit later.

[RedParadize]

Pockjet could not implement his new inflatable torus for that reason I believe.

[Shadowmage]

Indeed, that is unfortunate.

Even through custom plugin, the data simply doesn't exist; the loaded mesh in-game contains no BlendShape keys, so cannot be even manually animated with them.  Seems like it would require an update to PartTools just to export the data, and further updates to the KSP model loading code to import that data (and I'm not even sure it can be done, it almost seems that there is no manual access to blendshape data through the Mesh class, so no way for them to recreate the data from file).

I have one more avenue of exploration - AssetBundles.  I'm moderately familiar with them from working on the KSPedia stuff, but have no clue how they relate to loading model and texture assets.  When they were initial 'advertised' as being supported it was stated that they would load any component that Unity recognized, but I'm really unsure on how to access them from in-game to load the models, etc.  Will let you know if I find out more...

 

Progress update:

Have figured out how to access/load AssetBundle data from in-game, but it is a bit weird.  It appears to load asynchronously, so I'm going to need to somehow ensure that I can get the models loaded prior to them being needed on prefabs (or else have placeholder models for prefab icon display).  And have just verified that the BlendShape keys do import properly this way.  Have not yet managed to get the model to display or animate in-game, but that shouldn't be too difficult of a thing to accomplish now that I can get the models to load.

So... I've got a few things to think over/investigate regarding how best to handle the model-loading for asset-bundle based models.  I -might- be able to start them loading at the point where ModuleManager finishes its database loading; hopefully this would give them time to load so that I could inject them into the GameDatabase loaded models list so that they can be used as any other model.  But as my head is pounding from digging through obscure KSP API stuff, that investigation will have to wait for another time / tomorrow.

Sounds like that's two major features needed for the station parts that I've got sorted out now.  The next to investigate will be dynamic IVA swapping;  a brief look indicated that most of the fields/methods that look like they would be needed are all public and accessible, so there may yet be some hope for that as well.

Edited July 14, 2016 by Shadowmage

[ComatoseJedi]

Unless you are really opting in for the inflatable habitat market, I would just start off with cylindrical habs, first. See how well you can make them and move onwards from there. Think of the Mars D.I.R.E.C.T project. The hab was, in fact, a landable can with a heatshield on it. Granted, it was supposed to be 2 stories tall, to accommodate 4 humans (I'd say you can put 6 Kerbals in one of those with room for piddly things, like air, food, water, pet goldfish). But, with one of those attached to your cargo truss system, I'd say you'd had the beginnings of a fairly strait forward IPV. I know the Copernicus IPV concept did have an inflatable hab, but all the same and as always, I leave that up to you. 

[Qwarkk]

Having an issue with the parachutes on the SC-B-CM rentry crew pod. They wont deploy during my re-entry, saying it is unsafe (even at around 200m/s?). Doing simple tests (launching a ship straight up and activating parachutes) they work fine, so it must be the speed/unsafety that is causing them to not deploy. I have checked and I have deployment altitude set to maximum for both parachute types. Am i doing something wrong / does it matter when I activate staging for them to open?

It may be worth noting that I'm using the crew pod's parachutes to re-enter a 20 tonne lander. Could this be the issue?

Here is the output log in case it helps.