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

[Jimbodiah]

@CobaltWolf No stock parts needed, just use one of the adapters in the MFT tank.

[CobaltWolf]

35 minutes ago, StickyScissors said:

Stock parts though...yuck. And it still isnt a proper aerodynamic nosecone

Who cares? It's *less* aerodynamic right now, since you've got that gap. And correct me if I'm wrong, but do you have any non-stock parts in that screenshot?

[Jimbodiah]

Guess he is waiting on that X20 as well, Wolfy

[CobaltWolf]

1 minute ago, Jimbodiah said:

Guess he is waiting on that X20 as well, Wolfy

Me too... T.T

[tater]

Or a petal adaptor from SSTU?

[StickyScissors]

18 minutes ago, CobaltWolf said:

...but do you have any non-stock parts in that screenshot?

Uhm, did you miss the comment where i said i wanted to reduce part count with SSTU so i dont have to use stock parts anymore?

[CobaltWolf]

Just now, StickyScissors said:

Uhm, did you miss the comment where i said i wanted to reduce part count with SSTU so i dont have to use stock parts anymore?

So you're asking SSTU for a 1.25m > 2.5m adapter. Does it not have one?

[StickyScissors]

15 minutes ago, tater said:

Or a petal adaptor from SSTU?

If the petal adapter can close -completely- after releasing a payload mounted on the top, ill try when i get the chance

[Jimbodiah]

@CobaltWolf There are several integrated into the tanks as a nose-cone options.

Edited October 8, 2016 by Jimbodiah

[StickyScissors]

3 minutes ago, CobaltWolf said:

So you're asking SSTU for a 1.25m > 2.5m adapter. Does it not have one?

Im asking for an actual nosecone that i can attach stuff to the top of. With the pointed/rounded tip of a nosecone(meaning no flat space, like the adapters have)

Edited October 8, 2016 by StickyScissors

[CobaltWolf]

Just now, StickyScissors said:

Im asking for an actual nosecone that i can attach stuff to the top of. With the aerodynamic tip of a nosecone(meaning no flat space, like the adapters have)

Why do you need the top of your booster to have an aerodynamic nosecone? 0.o

[StickyScissors]

Just now, CobaltWolf said:

Why do you need the top of your booster to have an aerodynamic nosecone? 0.o

:-I im making an SSTO spaceplane that i can mount payloads on the tip of and release into space, then i will deorbit and land the SSTO via the wings and wheels approach. Think hard about it

[tater]

Why would it need to close (it can't)?  Also, you can disconnect the top node without opening the petals at all.

1 minute ago, CobaltWolf said:

Why do you need the top of your booster to have an aerodynamic nosecone? 0.o

Yeah, this part makes no sense at all to me. I could see having flat-topped top tank adapters having a node, but not any of the pointed ones at all. 

[StickyScissors]

Just now, tater said:

Why would it need to close (it can't)?  Also, you can disconnect the top node without opening the petals at all.

Yeah, this part makes no sense at all to me. I could see having flat-topped top tank adapters having a node, but not any of the pointed ones at all. 

Spaceplane SSTO with payload monted to the nose

[CobaltWolf]

1 minute ago, StickyScissors said:

Spaceplane SSTO with payload monted to the nose

So you have a payload UNDER the nosecone, and then a spaceplane ON TOP?

EDIT: Also, I thought hard about it. It still makes no sense.

Edited October 8, 2016 by CobaltWolf

[StickyScissors]

5 minutes ago, CobaltWolf said:

So you have a payload UNDER the nosecone, and then a spaceplane ON TOP?

EDIT: Also, I thought hard about it. It still makes no sense.

http://imgur.com/a/355jW

that is what om trying to replicate in a more good looking and lower part count nature. What ive been trying to explaint to you is the connection between those two spaceplanes. If that album doesnt explain it enough, nothing will

Edited October 8, 2016 by StickyScissors

[tater]

You could use a tapering but flat adapter, and put a stock shielded docking port on there. Close it for EDL.

You might consider actually making one with SSTU before asking for changes.

I can think of a few ways, frankly. You could put the petal adapter set to lose the petals with a nose underneath, and the spaceplane on the top node.

It might use several more parts, but it'd still be low parts compared to stock. Everything in your service bay would likely be in the tank part, for example. Your plane would have the majority of the parts.

Edited October 9, 2016 by tater

[madmanjazz]

Recreated a Apollo mission using sstu, overshot the landing at KSC a bit though. Thank you for your amazing mod!

Edited October 9, 2016 by madmanjazz

[Temeter]

Btw, anyone noticed that jimbodiahs avatar looks like an evil version of shadowmages?

[Pappystein]

2 hours ago, Temeter said:

Btw, anyone noticed that jimbodiahs avatar looks like an evil version of shadowmages?

Alter-Ego?  

Just kidding guys but it is a valid observation.  They are so eerily similar yet soo Different at the same time!

14 hours ago, tater said:

You might consider actually making one with SSTU before asking for changes.

It might use several more parts, but it'd still be low parts compared to stock. Everything in your service bay would likely be in the tank part, for example. Your plane would have the majority of the parts.

I would further suggest that not all Stock parts should be eliminated.   I am in the middle of designing my own Rocket based on your design.  I am using the SSTU tank and Pyrios engine fairing with a pair of F-1 engines.   And a 3.75m to 1.25 cone I have with a Shielded docking port.   My parasite transport has a Shielded docking port between the engines.  

 

PS I REALLY like the idea of a 2 stage to Orbit full recoverable and LANDABLE transport for crew.  

[Shadowmage]

Well, I had thought that I was going to be able to post a 1.2 release today.  Sadly I have discovered several new things which the stock code broke in one way or another that I'm not sure on how to solve (or if I even can solve them).

Notably the inflatable modules will no longer update their crew capacity and cause null-refs, the inflatable modules that were using blend-shapes for some reason show up missing their textures / can see through them (except the shadows show up on the mesh...), and I've still got a bit of a mess to cleanup with regards to tank textures/shaders/etc.

Hopefully I'll be able to get the blend-shapes working again.  Well, the animations work, but the textures are just... missing....  It is quite strange.  It flashes pink for half a second when spawned (which usually denotes shader is missing), and they show up fine in the part-icon preview.  Verified that the shaders and materials are all in place, but for some reason they are just not rendering.

 

 

The crew capacity though... that's just borked.  Zero chance of fixing it unless stock fixes the back-end code.  So, we'll more than likely be losing the inflatables.

 

So.. sadly, no release today.  Perhaps next weekend.  Will likely be losing the inflatable modules and torus if I can't fix the crew capacity and rendering issues.  Quite sick of losing parts due to stock breaking stuff and I'm not going to put up with it for much longer (would rather move on to something else than spend time constantly fixing things that I did not break and having previously working features removed without viable replacements).

 

Edit:  Have fixed the shader/material problems for the AssetBundle based models (inflatables).  Apparently Unity 5.4 does not setup the shaders properly when the model is loaded from the AssetBundle so I have to manually re-seat them.  Strangely, they worked fine with Unity 5.2.....

Still have not been able to fix the crew capacity problems however.  Really don't think I'll be able to find any solutions to that one...

 

Further edit:

Crew capacity code is... strange.  It halfway works.  Until stock decides to reset/revert things when you add/remove parts in the editor.  Might be able to get it working with some hooks into the editor events.

Edited October 9, 2016 by Shadowmage

[blowfish]

If all else fails, I'd say not being able to add crew to inflatables in the editor is fine.  When would you want to do that, anyway?

[Shadowmage]

25 minutes ago, blowfish said:

If all else fails, I'd say not being able to add crew to inflatables in the editor is fine.  When would you want to do that, anyway?

The problem isn't that you can't add crew in the editor; I would be perfectly fine with that.

The problem is that there is no way to -prevent- crew from being added in the editor.  If a prefab part has crewCapacity > 0, the crew selection shows up for the part in the editor regardless of that part instance's current crewCapacity value.  The root of the problem is that the stock code is pulling crew capacity from prefab/availablePart/partInfo rather than the actual part instance.  And if you set the prefab/config to specify crewCapacity = 0 it causes problems on initialization of the craft while in flight (deleting the crew...).

Working on some hacks/workarounds for it, but it is going to be quite ugly (from a code perspective).  You can see a bit of the code that I'm working on at the thread linked earlier:

It is partially working so far.  Need to figure out better event-handling / how to detect when the stock code has screwed things up and when to reset them.

[tater]

Not preventing crew in the editor is honestly not that critical. If people want to cheat, they can cheat, right? I'd rather have the part, and have to trust myself not to cheat with it, then to not have the awesome part.

 

[Shadowmage]

Well, the good point of delaying another week is that I can finish up some of the other solar panel models I was working on.  Such as:

I'm quite enjoying the added capabilities that a separate AO map introduce.  Lots easier to re-use textures/geometry, which simplifies things for me in the long run/makes it easier to make up derivative models.

 

Have the inflatable part crew-capacity scaling stuff... mostly... working again.  Apparently there were some recent changes in the stock code that re-enabled manipulation of those values a bit (though is still weird, requiring some extra event-handling to make things 'stick'); had to update my dev environment to the latest pre-release .dll's to see those changes.  Few more things to clean up on it, but looks like I'll be able to keep that feature in place.