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

[RedParadize]

41 minutes ago, Shadowmage said:

There might however be some bugs with either the thermal values for the part or with the drag cubes that are causing incorrect thermal calcs (will need to dig back in on how stock calculates thermal mass/skin mass)

SSTU heat impact is fine. When I was creating my custom shielded tank I ran many test with standard, lightweight, my custom shielded tank along side stock tank. SSTU might be slightly are more sensitive as they are lighter that stock therefore can't sink as much heat has heavier stock tank. Overall, the difference is neglectable.

 

In other news it has been all but officially confirmed that there will not be the 'rocket-parts-revamp' in 1.2, and with that, no support for PBR shader.  So... yeah...  apparently I get the fun task of writing up some custom shaders.  Not surprising, as they'de been extremely tight-lipped about it.  Still are... haven't even heard any confirmation that it is still being worked on for a future update... only vague statements that don't exclude the possibility of it being worked on in the future.

On the note of updates and updating -- I will be jumping on the 1.2 pre-releases as soon as they become available for testing.  I fully expect SSTU to be massively broken by this update, both in raw code and in actual function of the code.  Likely will be a few weeks to get it working and compatible.

Oh well... If you ask me, PBR would be nice but if you would decide to not do it it would not make me cry. 1.2 update is more important for me as I won't play it without SSTU. I just can't!

Edited September 7, 2016 by RedParadize

[Voidryder]

@Shadowmage  Well that's a bummer about no shader support, but more that you'll have to spend weeks to get SSTU operational again after the release. Guess I'll be flyin' in 1.1.3 until you do. SSTU is just too essential for me.

[falken]

Damn it Shadowmage, you show off these US modules after I've nearly finished my station?  

I'd say handholds would be good.

[tater]

File for future reference (not to sidetrack things, but it reminded me of some of the station parts with a docking port and adapter):

This is sort of a "Base" use (it looked like station parts, hence it peaked my interest (bloody autocorrect)), but as it looks like the SSTU US station parts, and depending on how the IVA is envisioned (even if not made), it could be a way to add such parts with less overhead by refusing existing parts. I just happened across the image, and figured if I didn't post it I'd forget about it, so here it is for your enjoyment.

Radial engines like that could perhaps have the gear built in. As they would be designed to fit your parts of 1 diameter, they could in fact be a single part (with those 4 engines, plus that sort of gear system). Actually, assuming the gear does;t stick out more radially than the rockets, it need not even retract.

Edited September 7, 2016 by tater

[Shadowmage]

Decided that since solar-panel switching is now a thing... to create an entire array of different solar panels.

Quite a few new ones will be available in the next release.  All are (so far) using the same 512x texture (lots of UV sharing, no AO bake, a couple hand-painted shading details).  ISS-styled shown for reference/sizing comparison.  All will be available as stand-alone parts in addition to being used as switch-options on the station parts.  Not nearly finished, still several more new variants to create, but this is what I've done up with far:

Going to make another (perhaps couple) multi-axis-tracking mast types arrays, as well as another line of smaller/probe based panels with a short mast for clearance (e.g. for use on Apollo short SM styled setups).

 

Any -specific- panel types you guys would like to see created/added?  (pics/examples/dimensions needed)

[JoseEduardo]

well.... since you asked....

I don't have dimensions, but I've got this:





the Salyut 7 panels were basically a Salyut 4/6/TKS panel with extra panels to the side of the main panel

also, if possible...


and the ETS Spacelab one, which is basically a doubled version:

I'd also ask for Almaz, but these were the best images I could find:




If I'm not mistaken they would unfold like your Mir Solar Panel, with the two outer layer unfolding from the center

btw, would it be possible to have the Orion SM and Soyuz solar panels as a separate mesh?

EDIT: almost forgot this:

Edited September 7, 2016 by JoseEduardo

[RedParadize]

@tater I would like the Habitat lander thing. Hum, I think I could already do this with as little as 5 existing SSTU part:

1: The hab itself.

2: Rear engine.

3: A Draco engine in a X mount cliping the hab in the middle.

4&5: side mounted radial tank.

6 Optional: a vertical Mechjeb unit for landing.

 

@JoseEduardo Nice reference! There is quite allot of interesting stuff there. I don't see much that would add new functionality over existing stuff. On the other hand I would be grateful if we had for more multi axis panels. There is very few of that on the market.

[Shadowmage]

17 minutes ago, JoseEduardo said:

well.... since you asked....

[snip]

 

Salyut panels -- any references on how those are supposed to fold up?  I tried making some the other day, but there doesn't seem to be a way to get them to fold into the same package/size as the other Salyut-styled panels.

Skylab -- what panels on there are you posting about?  Seems the longer (quad) panels are already done.  The other side panels?  Not really my style, and no clue how those are supposed to fold up?

Almaz panels -- might be doable, though I'm already not a fan of what the rigging will end up being (going to be like 30 different objects in that panel, per side...)

Orion and Soyuz panel separation -- not likely, at least not anytime soon.  Neither of those models were built with removable panels in mind (the solar panels are built into the model as it were; would be non-trivial to separate them from the mesh, as well as massive part config changes would be needed).  I'll keep it in mind if/when I ever do an update on those parts though.

 

[JoseEduardo]

the only Salyut 7 panel I ever found for KSP is the KOSMOS one, here: https://github.com/raidernick/KOSMOS/releases

sadly I couldn't find a video showing them deploying....

about the Skylab, I was talking about the side ones, they would be cool for being placed on the side of tanks

here's an orbiter video of Skylab showing both panels being deployed: 

 

[Shadowmage]

9 minutes ago, JoseEduardo said:

the only Salyut 7 panel I ever found for KSP is the KOSMOS one, here: https://github.com/raidernick/KOSMOS/releases

sadly I couldn't find a video showing them deploying....

about the Skylab, I was talking about the side ones, they would be cool for being placed on the side of tanks

here's an orbiter video of Skylab showing both panels being deployed: 

 

Apparently the salyut expansion panels were added via EVA after the fact.  They do fold up, but are 'add-on' parts, and were not stowed/folded with the rest of the panel.  Sadly, there is no way for me to accommodate the 'added through EVA' bit.

Interesting on the Skylab panels/deployment.  Will take a look at those when I'm working on blanket-style panels (e.g. accordian-folding panels, such as the large ISS panels).

[JoseEduardo]

ah, that explains it then....

I'm so used to the KOSMOS Salyut 7 panel that I never knew they were added later

[Shadowmage]

On Monday, September 05, 2016 at 1:06 PM, tater said:

[snip]

2. Fairing textures---They are anti-aliased along the edges, whereas the stripes on the tank textures are clean edges.

[snip]

That is caused solely by the texture-size of those textures; they are of low-resolution compared to the tanks/other parts.  The only way to fix that would be to double or quadruple the size of those textures, further increasing the memory footprint and distribution size.

You are not wrong though, they are terribly blurry on the edges.

Looking at the existing textures, they are 512x, and use ~5mb of memory.  Increasing them to 1024x would double the resolution and quadruple the memory size (20mb, 15mb increase).  Taking them up to 2048x would result in ~80mb of textures (75mb increase).

[tater]

Yikes. OK, that makes sense, then. The actual fairing parts only allow the solid textures, I think. That's what I end up using on the tank/capsule fairings, anyway.

[Duski]

@RedParadize, Sad thing is, that the AJ10's will only get me 100 m/s of Delta-V. I could very well keep using the external fuel tank to take me there, but it wouldn't be a proper shuttle mission then. And with placing fuel tanks in the rear of the cargo bay, i'll give that another shot. As I have to put fuel ducts so it stops complaining. I tried to put my fuel tanks at the front to balance my CoM, but it wasn't that much better. Gonna have to do lots of experimentation.

Edited September 7, 2016 by Duski

[CobaltWolf]

21 minutes ago, Duski said:

@RedParadize, Sad thing is, that the AJ10's will only get me 100 m/s of Delta-V. I could very well keep using the external fuel tank to take me there, but it wouldn't be a proper shuttle mission then. And with placing fuel tanks in the rear of the cargo bay, i'll give that another shot. As I have to put fuel ducts so it stops complaining. I tried to put my fuel tanks at the front to balance my CoM, but it wasn't that much better. Gonna have to do lots of experimentation.

According to... *drumroll* Wikipedia, the Shuttle OMS had ~300 m/s of dV. Soooo 100 isn't that far off, honestly. I'd say 300 would still be appropriate, since KSP players aren't as efficient as NASA.

[tater]

21 minutes ago, Duski said:

@RedParadize, Sad thing is, that the AJ10's will only get me 100 m/s of Delta-V. I could very well keep using the external fuel tank to take me there, but it wouldn't be a proper shuttle mission then. And with placing fuel tanks in the rear of the cargo bay, i'll give that another shot. As I have to put fuel ducts so it stops complaining. I tried to put my fuel tanks at the front to balance my CoM, but it wasn't that much better. Gonna have to do lots of experimentation.

OK, I have not used the Shuttle in actual play before, and perhaps we need a "configure containers" to balance OMS propellant vs EC...

I threw a tank in the cargo bay (I used the no engines Shuttle, and added the AJ10s and main engines) with ~3000 kg of hypergolics. It gives 280 m/s of dv. The real OMS mains could do 300 with cargo in the bay, but carried some 8100 kg of propellants (which is over 5100 to scale). Scale propellants gives 409 m/s or so, empty. Fill the payload bay, and it gets near 300.

[RedParadize]

Yep. 

 

As I said, You are free to buff it if you want. On my side I added a SSTU container, I us it as KIS container or propelant if needed. Giving SSTU container still add tank mass its not a cheat. Its more like if I had a extra tank in the bay, without the extra part and COM offset. And about COM, tank are not realy good at balancing it, its empty when you reenter... I edited the COL and COM of the engineless shuttle so its a bit easyer to balance. 

[Shadowmage]

Indeed; I thought I had balanced it (the one with engines at least) to have ~400 dV when empty and >300 with a 12t payload. 

This could have gotten skewed at some point though, I really didn't do too much testing when I re-added them... mostly launched a few to make sure nothing exploded (literally or code wise).  Also could be that the stand-alone engines are heavier/have different performance stats than the built-in engines.  If spots any discrepancies on those before I get around to them, please let me know what/where/what the fix is, and I'll do my best to get it fixed

Adding the VolumeContainer treatment to the SC-E is on the TODO list; more important for the no engine variant, but useful for both.  Kind of holding off until I can figure out a suitable 'empty space' placeholder/resource to allow for empty containers. (warning: this will be a craft breaking change when it occurs...)

[tater]

@Shadowmage, what I posted above I did with the empty orbiter (wings, v-stab, elevons, and all engines added). With a tank ~300kg total it's 300 m/s for both AJ10s together. With closer to 5100 (which would be the scale mass of 5184kg), it's about 400.

[tater]

I suppose the "full" version should have ~5100kg of hypergolic propellants for the 2 OMS engines.

[Duski]

8 hours ago, RedParadize said:

Yep. 

 

As I said, You are free to buff it if you want. On my side I added a SSTU container, I us it as KIS container or propelant if needed. Giving SSTU container still add tank mass its not a cheat. Its more like if I had a extra tank in the bay, without the extra part and COM offset. And about COM, tank are not realy good at balancing it, its empty when you reenter... I edited the COL and COM of the engineless shuttle so its a bit easyer to balance. 

Still don't know this mod by the back of my hand, but what are these SSTU containers?

[RedParadize]

5 hours ago, Duski said:

Still don't know this mod by the back of my hand, but what are these SSTU containers?

There are a really good module shadowmage implemented that allow you to chose tanks content. SSTU tank have it. What you could do is add one to SC-FSX. When I get back home tonight I will paste you my config for this if you want. Keep in mind that Shadowmage said he will eventualy add it himself.

[tater]

5 hours ago, Duski said:

Still don't know this mod by the back of my hand, but what are these SSTU containers?

On the tanks (and some other parts) there is a button on the right click in the VAB for "configure containers." This lets you set the tank parameters (lightweight tank, zero boil off, etc), as well as the specific ratio of internal contents for each possible content item.

 

[tater]

Service Module decoupling...

The Soyuz DM works as expected.

The 2 US capsules, OTOH, are very counterintuitive.

Each capsule has two places where a part can be attached on the bottom. So take a capsule, and attach an upper stage to tank to it. If you attach at the lower node with a MFT tank, a fairing is generated to cover the heat shield. If you attach at the upper node, the tank actually clips into the bottom of the capsule.

You would think that the lower node that always generates a fairing would be the "service module" that can be decoupled---but this is not the case, that node attaches the 2 parts permanently. The upper node, where the tank actually intrudes into the capsule is the one that decouples.

Seems exactly wrong/backwards to me.

Edited September 8, 2016 by tater

[Shadowmage]

27 minutes ago, tater said:

Service Module decoupling...

The Soyuz DM works as expected.

The 2 US capsules, OTOH, are very counterintuitive.

Each capsule has two places where a part can be attached on the bottom. So take a capsule, and attach an upper stage to tank to it. If you attach at the lower node with a MFT tank, a fairing is generated to cover the heat shield. If you attach at the upper node, the tank actually clips into the bottom of the capsule.

You would think that the lower node that always generates a fairing would be the "service module" that can be decoupled---but this is not the case, that node attaches the 2 parts permanently. The upper node, where the tank actually intrudes into the capsule is the one that decouples.

Seems exactly wrong/backwards to me.

Nope, working exactly as intended.

The upper node includes a decoupler as it is intended for the specific service module for that part series, and is the 'lowest-part-count' route (hence the 'decouple service module' wording).

If someone wants to use the capsule in a different manner (using the lower node that creates the fairing) they are on their own for decoupler.  They are not using the part how it was intended and so they are responsible for taking care of anything needed for their alternate use.  The other option is to remove the lower nodes and auto fairings from the parts, preventing such alternate uses entirely.

(The solution would be for the stock decoupler module to allow specifying multiple nodes that should be decoupled, so that a single decoupler module could manage both nodes.  Sadly, this is not supported by the stock module, nor do I anticipate it being supported.. ever.)