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

[Pappystein]

2 hours ago, tater said:

What's the point of an extra small COS module from a gameplay POV? Given the use of the same textures, etc, could you throw a hatch on it, and treat it as an airlock part? Then we get the nice looking part that also has a hatch (the awesome parts means that my stations are getting bigger, not smaller, anyway  .

If I understand @Shadowmage correctly, the issue is when swapping an end node for the hatch in the Gui.   If that is the case what about a second part that is the Airlock..   we add 1 part and not a lot of additional work for Shadowmage.   Vs trying to rebuild a bunch of code...

 

@tater  I can see several uses for a tiny 1 Kerbal hab (including as a life-boat/emergency escape pod.) 

 

 

[mechanicH]

@Shadowmage I just have a quick suggestion/request. If it is possible and if you have time to create an extendable docking port (small, medium). Something that will protrude 2x or 3x it's own thickness. Basically it's for when you have a docking port too close to another part, it can extend for clearance.  

 

Edit.  I think your sc-e had it. But I can't recall 100%.  

Edited November 4, 2016 by mechanicH

[tater]

He said that if he was unable to make the airlock adapters work, the 1-kerbal version would still be available. My point was that such a hab while certainly nice to have has little use, really, on it's own. He didn't want to add an explicit airlock part, but honestly, if the choice was an additional part that was a 1-crew COS part, or a 1 crew COS part that had a hatch... I'd take the one with the hatch  . You'd still have the utility of a 1-crew part, but it could also be used as an airlock should anyone want to.

Or, of course, he might figure out the mystery of the code making it difficult to have airlock adapters, and we have the best of all worlds.

Edited November 4, 2016 by tater

[tater]

To be clear, my thought WRT the tiny hab unit was that if it happened to have a hatch, assuming the adapter stuff doesn't pan out, then that seems like the ideal solution as it could be used either way---unless a 1-crew COS has a real life analog, and the hatch would be wrong for it.

[RedParadize]

14 hours ago, Shadowmage said:

Well, I built these little bits today (x-short COS module, airlock adapter):

 

Sadly, having airlocks-on-adapters does not seem to work out-of-the-box.  Investigating hacks/workarounds, but it is NRE'ing deep in the stock code, and I have no idea what is null, or really anything about the code.  Going to try digging into it, but unsure if I'll be able to solve it or not.  So airlocks on adapters = a big maybe.

What happens is as you EVA from the hatch, an initial NRE occurs as soon as the Kerbal appears.  The kerbal is uncontrollable and the log is continually spammed with errors.  FlightEVA.onGoForEVA() is where the error is occuring, but as that method doesn't even have any input parameters I have exactly zero information on what the problem is or could be.

 

 

@ShadowmageI might have a work around for you, If you add a fake hatch to the main part, the hatch on the adapter will work too. So, in absence of the airlock adapter, the player will not have access to hatch context menu but could still use the EVA button on the top of kerbal camera. So make sure the fake hatch is blocked, if player try to EVA using kerbal camera it will get the message "hatch blocked".

Its not a elegant solution but it work, thats what I did when I built my lander using your plug-in (page 185) and it worked without NRE message.

(For the rigid centrifuge render I promised few days ago. The quality of what I had was much lower than what I remembered. I will work on it a bit and send them if its not too late.)

Edited November 4, 2016 by RedParadize

[Shadowmage]

Well, shortly before I went to bed last night I stumbled upon the Part.airlock field (Transform).  Haven't quite figured out where it gets set in the stock code, but it might not matter if I'm manually updating it.  Put together some test code that might have fixed the issue, but haven't been able to test it yet. 

Hopefully will know more tonight after more testing, and will let you guys know what I find out.  If the field is what I think it is, then I should be able to manually re-seat the airlock collider transform reference into the Part.airlock field whenever I change core or adapter/mount geometries, and it should 'just work' at that point.

 

14 hours ago, tater said:

What's the point of an extra small COS module from a gameplay POV? Given the use of the same textures, etc, could you throw a hatch on it, and treat it as an airlock part? Then we get the nice looking part that also has a hatch (the awesome parts means that my stations are getting bigger, not smaller, anyway  .

The point was mostly as an appropriate base for the airlock adapter.  But as I made the model and configs already there is no reason to not keep it around (it looks quite 'cute' with the dome adapters on it).

 

10 hours ago, mechanicH said:

@Shadowmage I just have a quick suggestion/request. If it is possible and if you have time to create an extendable docking port (small, medium). Something that will protrude 2x or 3x it's own thickness. Basically it's for when you have a docking port too close to another part, it can extend for clearance.  

 

Edit.  I think your sc-e had it. But I can't recall 100%.  

Doable, sure.  However it would require new models + textures, and is not currently planned, so if I were to make it it certainly won't be for a few months. 

I don't really see the use for it though (for general spacecraft docking at least), and the chances of me making a part that I'll never use are close to zero.  Convince me that I need it and the chances go up substantially (specific use-cases, images/ideas of craft where it would make previously un-realizable designs possible).  Convince me that I -really- need it and I might even be willing to put it into the schedule somewhere.

 

46 minutes ago, RedParadize said:

 

@ShadowmageI might have a work around for you, If you add a fake hatch to the main part, the hatch on the adapter will work too. So, in absence of the airlock adapter, the player will not have access to hatch context menu but could still use the EVA button on the top of kerbal camera. So make sure the fake hatch is blocked, if player try to EVA using kerbal camera it will get the message "hatch blocked".

Its not a elegant solution but it work, thats what I did when I built my lander using your plug-in (page 185) and it worked without NRE message.

(For the rigid centrifuge render I promised few days ago. The quality of what I had was much lower than what I remembered. I will work on it a bit and send them if its not too late.)

Noted, and thanks for the workaround.  Might be a usable setup if I can't find any other method around it.  I thought I had seen mention of that problem and the solution you found, but wasn't able to locate the details in my searching (didn't go back far enough in the thread); stuff often moves too fast in here for me to keep track of it all.

No worries on the renders/previews -- if/when you have time is fine.  I am a bit curious on those designs, they looked interesting.  Would have to work out a few details like crew access tubes while keeping the stowed outer diameter manageable. 

For reference I prefer any station parts to have <= 3.75m outer diameter when stowed; I'm trying to reserve 5m+ for lower stages/lifters, with the largest (SSTU-provided) payloads being 3.75m.  That is mostly for things that are launched on rockets/used as payloads.  For things intended to be constructed in-orbit/in-situ through EPL/etc, there are no real limits for size (and they don't need to be stowable/retractable, so opens up new types of geometry options).

[tater]

9 minutes ago, Shadowmage said:

The point was mostly as an appropriate base for the airlock adapter.  But as I made the model and configs already there is no reason to not keep it around (it looks quite 'cute' with the dome adapters on it).

Cool, I agree it is a fine part---I was merely pointing out that if the airlock adapter stuff ends up giving you fits, it might be a nice and unique COS addition for it to have a hatch on the main part (again, only if adapter hatches are not a thing).

 

[RedParadize]

1 hour ago, Shadowmage said:

Noted, and thanks for the workaround.  Might be a usable setup if I can't find any other method around it.  I thought I had seen mention of that problem and the solution you found, but wasn't able to locate the details in my searching (didn't go back far enough in the thread); stuff often moves too fast in here for me to keep track of it all.

No worries on the renders/previews -- if/when you have time is fine.  I am a bit curious on those designs, they looked interesting.  Would have to work out a few details like crew access tubes while keeping the stowed outer diameter manageable. 

For reference I prefer any station parts to have <= 3.75m outer diameter when stowed; I'm trying to reserve 5m+ for lower stages/lifters, with the largest (SSTU-provided) payloads being 3.75m.  That is mostly for things that are launched on rockets/used as payloads.  For things intended to be constructed in-orbit/in-situ through EPL/etc, there are no real limits for size (and they don't need to be stowable/retractable, so opens up new types of geometry options).

Note that I didn't got to test this in 1.2. I don't see why it would not work.

As for the Centrifuge part, what I have so far is a 2.5m diameter total with a single 1.875m rotating hab. Design wise its fairly efficient, the counterweight contain batteries, water supply and treatment etc. I am not satisfied by its look trough, I still fine the two sided one nicer. It would be mechanically more complex and slightly heavier the split the hab pressure hull in two, but on the other side I am doubtful that enough useful stuff could be stacked on the counterweight for the single hab version, resulting in a really long arm for the counterweight. What do you think?

Edited November 4, 2016 by RedParadize

[Shadowmage]

Working on the initial balance pass of the new inflatable HAB parts.  Really not sure the best way to calculate balance for these parts...

Right now I'm using the existing stock parts as a baseline for mass and volume per seat.  Specifically the Mk1 pod for mass / kerbal, and the hitchiker for minimum volume / kerbal.  Specifically, for inflatables, a base of 0.625t / seat, and minimum of 2.5m^3 / seat.  The inflatables with end-caps get an extra bit of mass added on to account for the caps, propellant tanks, solar and rcs bits (currently 1t, rough guess).  This results in the following (very rough):

name	crew	volume	mass (total)
ST-HAB-A1	4	10	2.5
ST-HAB-A2	6	15.5	3.75
ST-HAB-B1	6	79	4.75
ST-HAB-B2	9	124	6.625
ST-HAB-B3	6	79	3.75
ST-HAB-B4	9	124	5.625
ST-HAB-C1	12	267	8.5
ST-HAB-C2	18	420	12.25
ST-HAB-C3	12	267	7.5
ST-HAB-C4	18	420	11.25

Much of that can, and probably should, be adjusted a bit.  Mass shown is the fully inflated / post construction step (including propellant, battery, and supplies at full values/mass).  The deflated launch mass would be much less.

The other alternative balance method that I had used in the past was calculating raw volume, skin thickness, volume-of-skin, density of skin, and using that to derive the mass (though that leaves the crew capacity uncalculated...).

 

Thoughts/suggestions?

Will probably post up an updated balance table after I get a little further on it, and will try out the skin-volume-density based calculations as well to see where they would put things and how it compares with what is posted above. 

In the end I'm trying to come up with a set of calculations that can be applied to all of the inflatable parts equally, resulting in a consistent balance across all of them (both the HAB and upcoming CFG).  They don't necessarily all need to use the exact same input values for density and such, but would like the same set of functions/equations to be usable for all of them without requiring any 'hand-tuning' of values.

 

 

 

 

[RedParadize]

I think the mass saving per seat should be a bit higher for larger part. Two small should almost never be better than a single large.

I don't know if you remember, but I suggested to add some extra seats to habs not so long ago. The idea was to be eable to increase their number trough config only. This would allow SSTU to work better with kerbalism for example (it use number of seat to calculate comfort). Say you have a module with two beds and be limited to two in config, but would have two more seat around the table.

[Shadowmage]

1 hour ago, RedParadize said:

I think the mass saving per seat should be a bit higher for larger part. Two small should almost never be better than a single large.

I don't know if you remember, but I suggested to add some extra seats to habs not so long ago. The idea was to be eable to increase their number trough config only. This would allow SSTU to work better with kerbalism for example (it use number of seat to calculate comfort). Say you have a module with two beds and be limited to two in config, but would have two more seat around the table.

Re; kerbalism -- that seems like a problem on their balance calculations.  It should not be comfort = totalSeats/occupiedSeats, it should be comfort = habitabalVolume/currentCrewCount.  You should not be 'penalized' for having all of the seats in a part occupied; it was designed for that many crew after all, and should be able to support that many crew at the comfort level that the module was designed for.  (Yes the totalSeats/occupiedSeats is mostly valid for stock parts, but that is because they are designed as transportation parts rather than habitation, the opposite of the route I'm taking).  However since I will not be doing IVAs for these parts, you are free to patch the parts to have whatever capacity you want/need.

 

Personally, I never want to see 20+ seats on a part.  I consider even 8+ to be too many seats for most parts -- I'm not trying to design space hotels or BFR-ITS, but rather long-term habitation modules.  So with that, the mass per seat will almost always be worse on the larger parts.  But the habitabal volume per seat will be vastly higher for larger parts (should = higher comfort / habitability values for larger parts compared to smaller ones).  This will (ideally) be factored into the USI-LS-hab-time balancing as I get to it, where the larger modules will have much longer hab times at their stated crew capacity compared to the smaller modules.

The large centrifuge parts?  Yeah, probably not going to have 40 seats in them (at least not in the default configuration), probably closer to 18-20 for the largest ones.  Rather they will be intended as a complete habitation solution for the listed # of crew (simulating living space, common space, working space, exercise area, spare parts storage, consumables storage, agricultural space/life-support). 

Think the habitation centrifuge section from 2001 (the movie..) -- the crew aren't just crammed in there with seats from wall-to-wall.. they have room to move, work, and -live-.  Contrast that to the transport space-plane from the same movie, which -does- have seats crammed side-by-side airliner style;  essentially I'm trying to design habitats and not transportation.  

Another (more recent) example is the Hermes from The Martian.  They had how many crew in that craft? 6?  And that was not a small vessel.  Using the volume per crew from stock parts, they probably would fit ~40 kerbals in there... but that is not what I'm trying to design.

You may be able to seat 5 people in your car, but how many could comfortably -live- in it?  Probably not even one with a very high comfort level, unless you own a bus.  And even that bus could be made much more comfortable with the removal of all the extra seats in place of stuff like couches, entertainment, and bathrooms.

Is there room for airliner style transportation type parts in KSP?  Sure (especially as you get into the future / sci-fi type gameplay), but those aren't what I'm creating in the HAB and CFG series of parts.  Of course, nothing would stop someone from patching in higher crew capacity to the parts for use for transportation purposes, but that is not what I will be using for the default balancing on them.

 

Sorry for the wall of text, but I figured an explanation of my design intentions for these parts might help with what suggestions are offered as far as balance is concerned.

 

[Shadowmage]

Good news on the airlock adapters -- the part.airlock transform is indeed responsible for the crashes/NREs, and manually force-updating it on model changes will allow for it to work as an airlock.  So those can be a thing now.  Will probably try and make up a few different sizes/variants (such as having the hatch on the tapered adapters), and will be adding those to the ST parts where applicable.

Also made a bit of headway on a problem with the ST docking ports regarding not undocking -- was able to duplicate the issue in at least one case, which will help me track down where things are going awry.  Something in the stock code is disallowing undocking for some ports under unknown circumstances.  But as the problem is in the stock code it really looks like I'll be implementing Claw's docking-port fix into those parts in one fashion or another; I won't be able to fix the problem, and working around it is about the best I can hope for.

Balance work on the ST parts continues.  Using a skin-thickness+density based calculation actually spat out some rather usable figures.  Going to do a bit more tweaking on it and see about posting an updated release hopefully tomorrow.

[tater]

I was gonna mess with this, but realized I don't have all the lengths and diameters inflated I think (forgive me if it's back a few pages). Stuck in Santa Fe right now (daughter has a history project that involves visiting the former seat of government during the Spanish period). Down side is no messing with SSTU during the day, upside is delicious lunch  .

Would you use Bigelow wall thickness as a baseline? Generally I agree with your take on the capacity, btw. To the extent LS mods add in something like habitability, I'd say you apply large positive modifiers with the fewer seats you favor. When usils gets radiation, and perhaps as kerbalism already does, we could assume shielding as part of the reduced number of seats (added volume of water or whatever as shielding).

[Jimbodiah]

That D series ship core, what is that supposed to be in real life?

[tater]

2 hours ago, Jimbodiah said:

That D series ship core, what is that supposed to be in real life?

I'm not home (wife is in a shoe store, kill me), but is that the TKS spacecraft reentry vehicle?

[Jimbodiah]

So you're the guy that stands outside, holding her purse?

Edited November 5, 2016 by Jimbodiah
Spelking

[mechanicH]

34 minutes ago, Jimbodiah said:

So you're the guy that stands outside, holding her purse?

We are ALL "that guy" standing outside holding the purse lol.  Best thing to do is hold it like a dead animal, and what ever you do dont throw the strap on your shoulder.

[tater]

2 hours ago, Jimbodiah said:

So you're the guy that stands outside, holding her purse?

Nah, I sat in the courtyard of La Casa Sena, had a beer, and wrote that post. Besides, she needed the purse, those shoes are expensive.

[Shadowmage]

21 hours ago, tater said:

I was gonna mess with this, but realized I don't have all the lengths and diameters inflated I think (forgive me if it's back a few pages). Stuck in Santa Fe right now (daughter has a history project that involves visiting the former seat of government during the Spanish period). Down side is no messing with SSTU during the day, upside is delicious lunch  .

Would you use Bigelow wall thickness as a baseline? Generally I agree with your take on the capacity, btw. To the extent LS mods add in something like habitability, I'd say you apply large positive modifiers with the fewer seats you favor. When usils gets radiation, and perhaps as kerbalism already does, we could assume shielding as part of the reduced number of seats (added volume of water or whatever as shielding).

Radius, height, and volume for the six sizes of inflatables (and b330 for comparison):

	rad	h or r2	raw vol (m3)
b330	3.35	13.7	483.0143727
a1	1.25	2.5	12.2718463
a2	1.25	3.75	18.40776945
b1	2.5	5	98.17477042
b2	2.5	7.5	147.2621556
c1	3.75	7.5	331.3398502
c2	3.75	11.25	497.0097753

Indeed that is pretty much how I imagined the balance for these would play out -- the larger parts would basically be more capable on a per-crew basis.   Longer duration habitation, more LS resources.

 

21 hours ago, Jimbodiah said:

That D series ship core, what is that supposed to be in real life?

https://en.wikipedia.org/wiki/TKS_(spacecraft)

Specifically it is the VA re-entry pod.  Figured as I was already making all the FGB stuff, I might as well include the TKS/VA.  (which reminds me, I need to work on the models/textures for those parts....)

 

 

Working on a bit more cleanup and should have an updated release here in a few hours.  Not quite at the point that I wanted things, but at a good enough state for now, and will give you guys the new inflatables geometry to play with while the config balance is being finalized.

 

 

 

 

[Shadowmage]

Updated release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.5.33.128

Tons of fixes, changes, and updates.  Please check the link for release notes, and especially check the 'Known Issues' section as there are still a couple outstanding unfixed bugs that are already known about.

 

[Krux]

Nice, thanks for all your work, these HABS are amazing

Also, are you planning to make any of the 2nd stage tanks able to change texture and color, like the first stage one? Sorry if it has been answered before, I couldn't find anything about it. Thanks!

[mechanicH]

http://imgur.com/a/M8AaQ

 

something weird is happen with the texture transparency and the some habs  dont inflate.

Edited November 6, 2016 by mechanicH

[tater]

MFT-A has the "Nose" stuff that includes many of the station adapters, which is great (though I'd love to see the VA adapter added for SMs, I can do that myself  ). The "Nose" selections don not, however, include any of the, well, nose parts---meaning none of the streamlined parts you might use for radially mounted booster tanks. The "Mount" options include those parts that you'd generally think of as nose parts (nosecones, basically). If the nosecones are meant to only be on one side, I'd assume the Nose would be the right side.

I was going to post a github issue on an odd VAB thing, but it seems to have self-resolved. I will wait until I can replicate it for a github. What happened was that the HAB parts were all showing translucent on the inflatable part of the part in the VAB. They were fine when launched---then fine after returning to the VAB, they showed as properly opaque. I will try later (leaving soon for dinner), and see if it happens again before posting to github.

The ratio adapters are nice to have. 1:2 seems like it might not be super useful for 2.5m parts, the 2:3 (up by 1.5X) seems like what you'd mostly use for 2.5m parts, since the only 5m parts (1:2) would be tanks... of course we haven't seen where you are going WRT huge tori  . Only posting this observation in case you decide to pear down options based on size. 1.25m parts would obviously nicely scale 2X to 2.5m, but 2.5m needs the 1.5X scale up (3:2) for 3.75 where the other hab parts all live far more than 2X.

Another part-sorting observation. The stock MPL is under category = Science, once more finalized, is that where the COS and DOS lab parts will reside? The stock hab part is in category = Utility as well, so to match the hab parts would go there I guess... here is observation/discussion bit: seems like some more of your station parts should have the same "probe core" functionality as the command pods and DOS parts. I would add "Command" to the HAB-B/C 1 and 2 parts as you have for the DOS (they have solar and RCS, after all, they seem self-controlling).

This is a great update!

3 hours ago, mechanicH said:

http://imgur.com/a/M8AaQ

 

something weird is happen with the texture transparency and the some habs  dont inflate.

I have seen the transparency in the VAB, but not after launch. Also, the inflatables require "rocket parts" to inflate. This is to represent the need for supplies to "fit out" the interior. So if you inflated them in the VAB, then they launch inflated. If you want to inflate after launch, attach a tank where you have used "configure containers" to add rocket parts.

@Shadowmage Note: It might be nice to add Rocket Parts as a standard choice (with LFO, EC, MP, etc) for Fuel type in the MFT tanks and COS parts.

Edited November 7, 2016 by tater

[mechanicH]

12 minutes ago, tater said:

I have seen the transparency in the VAB, but not after launch. Also, the inflatables require "rocket parts" to inflate. This is to represent the need for supplies to "fit out" the interior.

THANK YOU !!!......

wait  Rocket Parts?   im a bit lost here.

Edited November 6, 2016 by mechanicH

[Jimbodiah]

edit: I gotta read the devnotes before responding...

Awesome to see RP and KIS added to the tanks by the way!

Edited November 7, 2016 by Jimbodiah