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

[StickyScissors]

9 minutes ago, blowfish said:

Still not enough detail to make an accurate engine I don't think.  Given that it's FFSC, there should be a second, somewhat different turbopump assembly hidden behind there somewhere.

Maybe im confudsing things, as i do not know much about the specifics of rocket engines, but reddit people seem to be saying that the other turbine/pump/pre-burner thingies are on top of the combustion chamber

EDIT: Found this

 

Edited October 3, 2016 by StickyScissors

[blowfish]

It's plausible, I guess.  I can't speak for Shadowmage, but for me, if I were modeling the engine, I'd still want to see the other side.

[Shadowmage]

On Saturday, October 01, 2016 at 10:38 AM, tater said:

BTW, I was looking at the proposed replacement for Progress, and it got me thinking about the docking ports that are available. Is it possible to have one scaled to the same size as the Soyuz ports? It need not be a separate part, just scaled so that it's the same diameter.

I made the GEN-DP-2P by scaling the 1P to 0.75 (it's very slightly large at 75%):

 

Seems like it should be an option for the Russian station modules. I can work a bit on the exact scaling and follow up here if you are interested.

The stock docking ports are odd scale wise... The pass-through on standard docking ports is usually 80cm (Apollo was 81cm). Even if the structure around the port brings the outer diameter to 1m, that would make a kerbal scale port 0.64. So the smallest port is actually biggish (which is good given their heads). The 1.25, OTOH, is huge.

The new IBDM is 1.42m across (outer) with an 80cm passthrough.  The Common Berthing Mechanism outer diameter is about 2m, which to kerbal scale is 1.28---so the larger kerbal ports are CBMs.

I really do not want to make a new size of part/port.  I've talked about this in the past.  If/when stock supports 0.9375m parts/ports, sure.  Until then, sorry -- stock decided that the size was going to be 0.625m.

The problem with doing a new size of part... is then you need a crapload of -other new parts- of the same size to make them useful; new ratios for adapters, new tanks, engines, pods, heat-shields, cargo bays, etc.  Also it would be... painful... to retrofit the new ports onto existing parts (e.g. the SC-B would need a complete model rework in order to fit the larger port).

 

On Saturday, October 01, 2016 at 7:29 PM, falken said:

One thing I was wondering Shadowmage is if you have plans to ditch liquidfuel+oxidiser for something else? I'm really liking using hydrolox and hypergolic fuels.

Also, RCS that fires using hypergolic?

No, and yes.
 

On Saturday, October 01, 2016 at 7:39 PM, StickyScissors said:

All of that is Real Fuels territory, something that shadow has expressed he doesn't want to duplicate if it already exists.

 

Although, he did previously mention potentially making -all- SSTU RCS pods use Aerozone/NTO instead of just the ones integrated into service modules/capsules.

Pretty much exactly this ^^^.
 

On Saturday, October 01, 2016 at 8:29 PM, Jimbodiah said:

LF/O is basically Kerolox, no need to go RF with that.

 

15 hours ago, Nerfclasher said:

Hey @Shadowmage I have a present for you 

 

Thanks, saved for later reference.

 

13 hours ago, StickyScissors said:

Maybe im confudsing things, as i do not know much about the specifics of rocket engines, but reddit people seem to be saying that the other turbine/pump/pre-burner thingies are on top of the combustion chamber

EDIT: Found this

 

Also saved for later reference.

 

10 hours ago, blowfish said:

It's plausible, I guess.  I can't speak for Shadowmage, but for me, if I were modeling the engine, I'd still want to see the other side.

Yep, other side + orthographic view (at least 1) before I'll do any modeling on this engine. 

Nothing popping up on a google-images search at the moment though, might have to let them develop the concept a bit more and have a few more PR releases before we'll get any more pics.

[Shadowmage]

ST-MST-ISS updated renders:

Panels, front-side, diffuse (the actual solar panel side):

Panels, front-side, specular:

Panels, back-side, diffuse (non-generating / radiator side):

 

Panels, retracted:

Sorry, no glow images from Blender; no clue how to make blender use custom shaders, nor if the Unity shaders would even be compatible if it were possible.  Will get some updated glow renders after I recompile the shaders and update the KSP textures.

Only the specular for the panels has been done; the metal bits in the renders above are using mostly flat diffuse -- will be updating those to be a bit more reflective/metallic looking.  Aside from that the textures are... well, being worked on.  Probably not too far off from being called 'done', but not quite there yet.

[tater]

Awesome! I get it on the ports as well, it's entirely aesthetic, and once they are docked you don't even notice anyway.

[falken]

Oh wow, those panels look goooooood.

That's all I can say really.

[tater]

I'm being good and testing vanilla 1.2. It's hard to be interested in doing anything at all... it's so ugly.

[Shadowmage]

Spent today's development time doing some not-so-exciting but needed in the long-run things.  Notably I wrote a .DDS conversion utility that allows for specifying the output format on a per-texture basis.  DDS4KSP works great, but when batch-converting the only option is 'auto', which for some reason flags all PNGs to be converted to DXT5 regardless of if they actually have alpha or not (might be a GIMP problem with the exported .pngs), resulting in textures double the size they need to be (both on disk and in memory).  Either way, the tool has been written... which will make the texture export/conversion process a bit faster/smoother.

 

Also spent a bit of time looking into PartTools customization / re-implementation.  Really sick of having to run two different Unity versions (3 if you need emissive animation support) which don't play nicely next to eachother; also sick of PartTools not supporting .dds textures and lacking a 'don't export textures' option.  Would also be nice if they could support BlendShape animations....

Sadly the API for PartTools is non-existent, everything is set to private/internal modifiers and there is zero room for external interaction with the existing classes.  This leaves me needing to either 1.) Pray that SQUAD updates PartTools properly and in a timely manner, or 2.) Write my own custom model format exporter for the UnityEditor, and a custom loader for in KSP.  I highly doubt #1 will happen (at least in the short-term), and I really don't want to go with #2.  The third option is keeping the status-quo, which, frankly, is driving me crazy with the inconsistencies and workarounds needed for what should be simple operations (such as the need to create, assign, build, and manually copy an asset-bundle just to export a model with BlendShape animations, or the lack of emissive animation support since Unity 4.2.xxx).   (If anyone from SQUAD is reading... you could probably talk me into updating PartTools for you pretty easily...)

 

Still mostly waiting on an updated ModuleManager before I can publish 1.2 testing releases.  Still no word on when that will be available, but it is seeming likely that it won't be out prior to the 1.2 final build.

[blowfish]

Actually, I think 1.2 has an alternate solution for emissive animations.  You can use FXModuleThrottleEffects in conjunction with ModuleColorChanger to do it without an animation.  It does require re-defining the animation curve in a config file, however.

[StickyScissors]

Always have a rescue mission prepared in case of accidental...let's say "sub-optimal, horizontally energetic" landing and subsequent accidental space-bar bump.

Edited October 5, 2016 by StickyScissors

[shizzak]

The orion capsule main chutes have an issue when they fully inflate. They start spazzing out and the altitude goes up and down repeatedly. I am ussing RSS and RO if that answers any pertinent information

[tater]

1 hour ago, shizzak said:

The orion capsule main chutes have an issue when they fully inflate. They start spazzing out and the altitude goes up and down repeatedly. I am ussing RSS and RO if that answers any pertinent information

RO isn't supported, so that's likely the problem.

[Shadowmage]

10 hours ago, shizzak said:

The orion capsule main chutes have an issue when they fully inflate. They start spazzing out and the altitude goes up and down repeatedly. I am ussing RSS and RO if that answers any pertinent information

 

8 hours ago, tater said:

RO isn't supported, so that's likely the problem.

Indeed, at least I don't support RO directly.

Mostly the problem at the moment is that FAR has some compatibility issues, and awaiting a fix on FAR's side of things; PR submitted, merely waiting -- https://github.com/shadowmage45/SSTULabs/issues/346 & https://github.com/ferram4/Ferram-Aerospace-Research/pull/150

 

 

15 hours ago, blowfish said:

Actually, I think 1.2 has an alternate solution for emissive animations.  You can use FXModuleThrottleEffects in conjunction with ModuleColorChanger to do it without an animation.  It does require re-defining the animation curve in a config file, however.

Indeed.  Sadly they added those functions/modules long after I had already created a code & config defined emissive module.  Still a 'problem' with Unity / PartTools setup though that many others face (actually more of a Unity problem for that one).

 

Seems from some of the developments yesterday that yes, I'm going to need to create my own model loader.  As Mu is/has resigned, I highly doubt that PartTools will be seeing any further updating, and almost certainly not for 1.2/in the near future.

 

On the note of custom model exporters/loaders -- realized that I don't really need one, if I don't mind being a bit hacky.  KSP/Unity already supports loading models from AssetBundles (if a bit of an effort to actually do it...), and the only thing stopping me from using those on the Unity end is the absurdly painful export process -- the need to maintain a .prefab of whatever object from the scene I'm trying to export and the asset-bundle building process.

Is anyone aware of a method to make an AssetBundle directly from an object in a scene? 
Barring that (which I don't think is directly workable) I'll likely create a script that does:
1.) Create a dummy .prefab of a GameObject from a scene into a temp directory.
2.) Tag that dummy .prefab for a temp/dummy AssetBundle.
3.) Builds that specific AssetBundle into a temp directory, renaming it to whatever was specified in the export script
4.) Copies the just-built bundle into the specified GameData/XXX/ directory
5.) Clean up the dummy prefab, asset bundle, and garbage files that Unity created while building the AssetBundle.
6.) The original game object still exists in the scene for further modification/re-export, and the newly-created asset-bundle has been copied to the KSP/GameData/XXX folder, ready for use.

From there my existing loader code would take care of loading it in KSP, reassigning textures/materials (as they won't be in the bundle), and adding it to the KSP GameDatabase models list.
 

[shizzak]

Once that parachute issue is fixed, I'd like to make an Orion em-1 cinematic and would love to give your mod the credit it deserves. I haven't found any other mod that has the realistic sequence for parachutes and the service module. Keep up the good work

[Shadowmage]

Custom model exporter most of the way written.  It creates the prefab, packs it into an asset-bundle, and builds the single asset bundle.  Need to rename and move the compiled bundle into the specified/configured GameData directory.  Need to add -optional- texture export.  Working and mostly usable as-is, but still has some work to be done.

 

As the large ISS blanket panels are mostly done I moved on to working on some of the other blanket style solar panels, first up is the folding/deployable dorsal panel from Mir:

 

Will likely make 2-3 lengths/sizes of this panel.  Will also be making one styled after the Skylab panels, in at least two lengths.  Have one other custom blanket type of panel planned as well, though have not started working on it yet.  These will all re-use the same texture sheet as the ISS panels, perhaps with separate AO maps if needed.  May be making a slightly different paneling texture for these variants using the remaining space on the texture sheet (shown using part of the ISS panel textures).

 

Hoping to get things cleaned up for an initial 1.2 testing release this weekend (now that MM is officially available for 1.2).  These next couple releases are likely going to be a bit rough, and I would expect to see a few bugs regarding the new 1.2 features and other changes that have been done, but these should be able to be cleaned up fairly quickly.

[COL.R.Neville]

have you had a chance to check out the radiator glow in 1.2pre KSPI? might be what you are looking for or general direction its pretty subtle not a flourescent glow. dont know if i splained that correctly or not. 

shuttle landing gear? love the shuttle just needs some landing gear. i use mine for the lko rescue contracts with kas winches mounted in the cargo floor to bring stuff back if i need to. 

[Shadowmage]

On Thursday, October 06, 2016 at 11:51 AM, COL.R.Neville said:

have you had a chance to check out the radiator glow in 1.2pre KSPI? might be what you are looking for or general direction its pretty subtle not a flourescent glow. dont know if i splained that correctly or not. 

shuttle landing gear? love the shuttle just needs some landing gear. i use mine for the lko rescue contracts with kas winches mounted in the cargo floor to bring stuff back if i need to. 

Radiator glow is not what I'm looking for for the solar panels.  I was specifically looking for a directionally dependent glow effect that creates a sort of 'back-lit' look to the panels.  What I created with the shader was pretty much exactly what I was looking for.  Yes, they are supposed to glow quite brightly (take a look at the real images of the ISS solar panels).

Landing gear -- The Unity update to 5.x/KSP 1.1 removed any chance of having custom landing gear for the Shuttle.  Sorry, this is a KSP/Unity problem and not anything that I can fix or work around.  The stock wheel system will not work for those wheels/parts, and there are no alternate systems available.  If/when Unity fixes their garbage wheel system -and- KSP updates to that version of Unity these might have a chance of coming back.  However, I would not expect their return, ever (Unity has no interest in fixing the wheel problems).

Will be removing the shuttle from the upcoming 1.2 releases; it will not be returning until Unity/KSP fix the wheel system or a working alternative system is available for wheels.  So, more than likely it will never be seen again .

 

 

Comparison of some of the smaller blanket style solar panels with the larger ISS styled panel:

Have also made a single-section blanket panel (not shown), and am still planning on a few other variants as soon as I can get the geometry sorted out.

[COL.R.Neville]

np i understand too bad that was a pretty nice setup gear problems not withstanding. 

[mechanicH]

@Shadowmage I understand that unity has total garbage for wheels but I don't mind using the stock wheels on the shuttle. Custom wheels are not a necessity more of a luxury  . So if possible could you please, pretty please keep the shuttle in 1.2 even if it doesn't have wheels.  I still love your shuttle design and want to keep using it. Please don't exclude it just because it's missing a simple thing like wheels.  Everything else on it functions perfectly and I'm sure people can work around the wheel problem. Thank you for your hard work as always. I look forward to your mod.  

Edited October 7, 2016 by mechanicH

[mechanicH]

Looks like sarbian came out with another update.  2.7.1. MM. 

[StickyScissors]

@Shadowmage would it be possible to add an optional attatchment node to the top of fuel tanks that have nosecones on them? A particular spaceplane design/system i had in mind requires this

Edited October 8, 2016 by StickyScissors

[Shadowmage]

21 hours ago, COL.R.Neville said:

np i understand too bad that was a pretty nice setup gear problems not withstanding. 

 

18 hours ago, mechanicH said:

@Shadowmage I understand that unity has total garbage for wheels but I don't mind using the stock wheels on the shuttle. Custom wheels are not a necessity more of a luxury  . So if possible could you please, pretty please keep the shuttle in 1.2 even if it doesn't have wheels.  I still love your shuttle design and want to keep using it. Please don't exclude it just because it's missing a simple thing like wheels.  Everything else on it functions perfectly and I'm sure people can work around the wheel problem. Thank you for your hard work as always. I look forward to your mod.  

 

I'll give it some thought.  Tthere are a few other/non-wheel problems with the parts that I haven't been able to fix as well; inertia tensor / moment of inertia (causes the roll instability), RCS/module toggles that need to be re-hidden, 'control-from-here' transform for thrust-line, and the IVA went missing/corrupted at some point.  All of this stuff worked fine in 1.05, sadly each KSP update has broken those parts more and more.  I would like to at least get those problems fixed before I re-introduce the parts.  Most I already have an idea of what the solution will be and merely need the time to sit down an implement them.

 

 

2 hours ago, mechanicH said:

Looks like sarbian came out with another update.  2.7.1. MM. 

Thanks, will update the distro to the newest before I do a 1.2 release  (likely sometime tomorrow afternoon/evening).

 

2 hours ago, StickyScissors said:

@Shadowmage would it be possible to add an optional attatchment node to the top of fuel tanks that have nosecones on them? A particular spaceplane design/system i had in mind requires this

Perhaps...would require some minor code-side changes, adding a new module and node definition to the parts.  I'll see if I can come up with any use-cases for my games, which will be the determining factor in the end.  If implemented it would work the same as the current interstage nodes where it would start disabled and you would need to click a GUI control to enable it.

[StickyScissors]

32 minutes ago, Shadowmage said:

Perhaps...would require some minor code-side changes, adding a new module and node definition to the parts.  I'll see if I can come up with any use-cases for my games, which will be the determining factor in the end.  If implemented it would work the same as the current interstage nodes where it would start disabled and you would need to click a GUI control to enable it.

Perfect! I assume if this gets implemented an interstage would be generated between the the nosecone tip/base and the part connected on top, yes?

Also, my example for a use case: 

Trying to recreate someone else's design of a 100% reusable TSTO spaceplane thing with a lot less parts. Connecting the upper spaceplane uses some weird I-Beam mounted under the nosecone and struts everywhere

[CobaltWolf]

2 hours ago, StickyScissors said:

Perfect! I assume if this gets implemented an interstage would be generated between the the nosecone tip/base and the part connected on top, yes?

Trying to recreate someone else's design of a 100% reusable TSTO spaceplane thing with a lot less parts. Connecting the upper spaceplane uses some weird I-Beam mounted under the nosecone and struts everywhere

Wouldn't that entire problem be resolved by just using a Rockomax Adapter?

[StickyScissors]

12 minutes ago, CobaltWolf said:

Wouldn't that entire problem be resolved by just using a Rockomax Adapter?

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