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

[blowfish]

47 minutes ago, organikarocks said:

https://www.dropbox.com/s/s39m4sly5l2ondy/output_log.txt?dl=0

Well, for starters you haven't installed CommunityResourcePack, which you definitely need.  Additionally, it looks like you have installed SSTU-OptionalPatches, which has some patches for USI Life Support which will break if you do not have that installed.  You may want to examine the contents of SSTU-OptionalPatches more carefully.

[organikarocks]

8 minutes ago, blowfish said:

Well, for starters you haven't installed CommunityResourcePack, which you definitely need.  Additionally, it looks like you have installed SSTU-OptionalPatches, which has some patches for USI Life Support which will break if you do not have that installed.  You may want to examine the contents of SSTU-OptionalPatches more carefully.

I see, thank you.

[Temeter]

I'm honestly surprised it even started without CommunityResourcePack. My games had a tendency to crash whenever it was missing (not necessarily because of SSTU tho!).

[Shadowmage]

Along with the rest of the tank/texture reworks, I've spent a bit of time finishing off/cleaning up the spherical tank set(s), including a new set of no-frame models and entirely new geometry for the framed models.  Each body set now includes three switchable end-caps/adapters (which will also be available on standard tanks as nose/mount adapters I think).  Will include texture switching and recoloring capabilities for the spherical tanks, with at least two different mask options.

Tank model reworking is all done I believe, as is the actual tank texture work.  Need to finish up all of the config work for the new texture setups, and possibly create a few more masks.  After that will be reworking all of the engine mount textures and creating masks for them.  Lastly will be cleaning up/finishing the recoloring GUI and presets system.  That should hopefully wrap up the recolorable part rework, at least its initial offerings (tanks/adapters/mounts).  I do want to expand it to include some other parts in the future, but those will come over time

[tater]

Those look great!

Now I can think about building the ship in my avatar:

 

 

 

 

Edited July 2, 2017 by tater

[Shadowmage]

Holy cow... after only like 3 months of it bugging me, I finally found a solution to the seemingly misbehaving shaders that would cause white pixels on some edges when anti-aliasing was enabled.  Silly Unity de-normalizes the surface normal when passing it between the different shader functions, which causes problems with the specular lighting calculation, resulting in... bad/ugly stuff as can be seen in the image below.

Now, this is actually a problem with the stock Unity and KSP shaders as well (though nothing I can do to fix those).  I thought I was going nuts, having researched the problem 3-4 times, tried swapping to KSP and other Unity shaders, rewrote my own shaders multiple times, tried different textures, anti-aliasing settings, so many things.  Turns out its just a bug in Unity.  Thankfully the fix is easy to adapt to the existing custom shaders.  Not the most performant bit of code, but I would rather it look good and not have random white pixels driving me crazy.

https://forum.unity3d.com/threads/jaggy-white-pixel-artifacts-on-edges-with-specular-and-antialiasing.320984/

After fixing up the shader code, it now looks like this (even when zoomed out it still looks very much improved):

As a bonus, this also fixes how some smooth-shaded objects had some sort of odd sided bias; they should once again look cylindrical instead of....whatever they were.  The 'silver' tank texture especially benefits from this.  Solar panels and other high-poly parts should also see quite an improvement.

 

[wb99999999]

First I have to say that these engine models are BEAUTIFUL!!!

Secondly, how does the exhaust port real plume config work on engines like RS-68? I was messing around in the file trying to get this engine run the Kerolox plume for a more realistic aesthetics, but whatever I change seems always break the whole thing and cause the main plume, the exhaust port plume, and sometimes both to malfunction and fails...

I understand that there's a bit more in this multi-plume config than the usual real plume ones. Can I get some hint/tips from you guys?

[Shadowmage]

1 hour ago, wb99999999 said:

First I have to say that these engine models are BEAUTIFUL!!!

Secondly, how does the exhaust port real plume config work on engines like RS-68? I was messing around in the file trying to get this engine run the Kerolox plume for a more realistic aesthetics, but whatever I change seems always break the whole thing and cause the main plume, the exhaust port plume, and sometimes both to malfunction and fails...

I understand that there's a bit more in this multi-plume config than the usual real plume ones. Can I get some hint/tips from you guys?

Thanks

I'm not sure how to -patch- the config files for plumes, have never tried.  You would need to find a way to make your patch run after the SSTU patches, but before real-plume does its bit.  Which... I'm not really sure how that would work considering how the existing patches are structured (with merely a BEFORE[RealPlume]).

Editing the existing files however should be quite simple -- find the RS-68 and where it says 'Hydrolox' change it to 'Kerolox'.  Should be as simple as that.  Four places that need changing; two where 'Hydrolox-Upper' becomes 'Kerolox-Upper'; and two where 'Hydrolox-Lower' becomes 'Kerolox-Lower'.  Or.. just change the existing RS-68 patch/config to this (untested):

@PART[SSTU-SC-ENG-RS-68]:NEEDS[RealPlume&!RealismOverhaul]:BEFORE[RealPlume]
{
    PLUME
    {
        name = Kerolox-Lower
        transformName = RS-68-MainFXTransform
        localRotation = 0,0,0
        localPosition = 0,0,2.4
        fixedScale = 2
        energy = 0.6
        speed = 0.6
    }
    PLUME
    {
        name = Kerolox-Upper
        transformName = RS-68-RollExhaust
        localRotation = 0, 0, 0
        flarePosition = 0, 0, 0.65
		plumePosition = 0, 0, 1.0
        fixedScale = 0.25
        energy = 1
        speed = 0.5
    }
	@MODULE[ModuleEngines*],0
	{
        %powerEffectName = Kerolox-Lower
        %runningEffectName = Kerolox-Upper
	}
}

Note, however, that the RS-68 is a -hydrolox- engine, and is configured for the hydrolox plume already.  I'm not sure if the in-game visuals for RealPlumes 'hydrolox' plume match up with the real engine, but it is already 'technically' setup correctly according to the naming.

[wb99999999]

1 hour ago, Shadowmage said:

Thanks

I'm not sure how to -patch- the config files for plumes, have never tried.  You would need to find a way to make your patch run after the SSTU patches, but before real-plume does its bit.  Which... I'm not really sure how that would work considering how the existing patches are structured (with merely a BEFORE[RealPlume]).

Editing the existing files however should be quite simple -- find the RS-68 and where it says 'Hydrolox' change it to 'Kerolox'.  Should be as simple as that.  Four places that need changing; two where 'Hydrolox-Upper' becomes 'Kerolox-Upper'; and two where 'Hydrolox-Lower' becomes 'Kerolox-Lower'.  Or.. just change the existing RS-68 patch/config to this (untested):

@PART[SSTU-SC-ENG-RS-68]:NEEDS[RealPlume&!RealismOverhaul]:BEFORE[RealPlume]
{
    PLUME
    {
        name = Kerolox-Lower
        transformName = RS-68-MainFXTransform
        localRotation = 0,0,0
        localPosition = 0,0,2.4
        fixedScale = 2
        energy = 0.6
        speed = 0.6
    }
    PLUME
    {
        name = Kerolox-Upper
        transformName = RS-68-RollExhaust
        localRotation = 0, 0, 0
        flarePosition = 0, 0, 0.65
		plumePosition = 0, 0, 1.0
        fixedScale = 0.25
        energy = 1
        speed = 0.5
    }
	@MODULE[ModuleEngines*],0
	{
        %powerEffectName = Kerolox-Lower
        %runningEffectName = Kerolox-Upper
	}
}

Note, however, that the RS-68 is a -hydrolox- engine, and is configured for the hydrolox plume already.  I'm not sure if the in-game visuals for RealPlumes 'hydrolox' plume match up with the real engine, but it is already 'technically' setup correctly according to the naming.

Thanks for the advises! In fact, this was exactly what I've been doing with the config: I changed only the type of the plume and nothing else. However, both of my attempt resulted in malfunction, with the first one resulting the two exhaust ports having no plume nor flare whatsoever, and the second one resulting both main nozzle and the exhaust ports having no plume and flare. simply changing the plume type seems to mess with the setup somehow...

Also, my point of using Kerolox plume is largely based on the fact that real life RS-68 has an ablative nozzle, which produces a yellowish-red "dirty" plume with carbon and other heavier molecule, instead of a clean, blue water vapor often seen in SSME and the likes. It kinda looks like the Soyuz's plume if you look carefully...

[DocRockwell]

On 4/18/2017 at 8:30 PM, Shadowmage said:

Holy cow... after only like 3 months of it bugging me, I finally found a solution to the seemingly misbehaving shaders that would cause white pixels on some edges when anti-aliasing was enabled.  Silly Unity de-normalizes the surface normal when passing it between the different shader functions, which causes problems with the specular lighting calculation, resulting in... bad/ugly stuff as can be seen in the image below.

Now, this is actually a problem with the stock Unity and KSP shaders as well (though nothing I can do to fix those).  I thought I was going nuts, having researched the problem 3-4 times, tried swapping to KSP and other Unity shaders, rewrote my own shaders multiple times, tried different textures, anti-aliasing settings, so many things.  Turns out its just a bug in Unity.  Thankfully the fix is easy to adapt to the existing custom shaders.  Not the most performant bit of code, but I would rather it look good and not have random white pixels driving me crazy.

https://forum.unity3d.com/threads/jaggy-white-pixel-artifacts-on-edges-with-specular-and-antialiasing.320984/

After fixing up the shader code, it now looks like this (even when zoomed out it still looks very much improved):

As a bonus, this also fixes how some smooth-shaded objects had some sort of odd sided bias; they should once again look cylindrical instead of....whatever they were.  The 'silver' tank texture especially benefits from this.  Solar panels and other high-poly parts should also see quite an improvement.

 

Bless your autism, good sir. 

[tater]

Saturday morning musings...

The image I posted up thread of the LR-87-7 (aka S-3) on the Titan got me reading up on it. A pretty fascinating engine, actually. The was flown with both hypergolic propellant, as well as kerlox. In addition, a variant was tested (full size) with hydrolox as a concept for what NASA elected to use the J-2 for (as a new design). Had variants from ~650 kN to almost twice that in thrust, too.

I have been messing lately with a rescale. I have planets bumped 4X in size, and the distances 6.4X. I am using SSTU parts out of the box.

My "replica" Saturn V in SSTU easily makes the Mun, and with a ton of dv to spare (about 1000m/s). I then dropped the stage three tank size a little to make it less OP. Still looks good. Replica R-7/Soyuz easily makes orbit with a couple hundred m/s left over (not counting the SM). I shark the upper stage one tick, so it should be better now (and I never scaled S2 to the real length). Tighter designs like Gemini are much harder. I have TRAILS installed, which wants a 1.875m diameter Titan, and even bumping it up to 2m I can't get the thing to orbit, I need about 4500m/s after gravity and drag losses. 

Went back to 1.875m, and replaced all the hypergolic engines with Merlins. Got it to orbit. Woot. 4X planets is pretty nice with SSTU and no other changes. Getting Gemini to orbit is actually non-trivial.

Mercury Atlas works as well, using that technique I posted up thread to fake a half stage. That Atlas-looking mount could be turned into a half-stage with a hollow collider.

The main tank has an upper stage mount (the medium length green cone with helium tanks, etc as greeble). A merlin is stuck to that, and the tank has the interstage node on. I then put a 1.875m decoupler on there, as thin as possible, with hollow collider on. Then I put a double merlin with the atlas looking mount, and adjusted the engine spacing. It was attached to the decoupler. Then, it got a fuel pipe from the main tank to the 2 engines/mount so that they would get fuel. A few times my angle is a little off (not dead-on into the flightpath) and I have the thing take out the center engine. Usually decouples fine though. I waited till the TW looked high, then dumped the half stage (liftoff was at 1.13 TWR for the stack, I shed the 1/2 stage at about 2.7, so that the sustainer would be over 1). The image above is the test, which did not make orbit. I had to make it taller than it should be at the 4X kerbin scale I'm at, but it still made it. I used a petal to be able to fit a retro package on the bottom of the capsule. That assembly I ended up clipping a little so that the decoupler would not float below the heat shield (just moved it till it touched).

PS--silver might be nice for a mount option.

Edited April 22, 2017 by tater

[CVerts]

I have a question for this modpack. What should I do if I only want to use certain packs for my game? For example, if I want to use Ship cores general and Series C and the landers.

[SpaceX]

On 4/23/2017 at 0:43 AM, CVerts said:

I have a question for this modpack. What should I do if I only want to use certain packs for my game? For example, if I want to use Ship cores general and Series C and the landers.

 

Remove the others? Kappa 

- Or just not use the other parts listed there, perhaps using something like Janitors Closet to clean up your parts list if needed. 

[SpaceX]

Apologies if this has been answered/addressed previously: Dose anyone know if this is compatible with SMURFF? I'm currently using RSS with SMURFF, and was wondering if this was viable? Or if there are any plans to make it viable?

 

Thanks in advance!

[tater]

RSS is not supported, but there are people who routinely post in this thread who are using it for that.

[SpaceX]

1 hour ago, tater said:

RSS is not supported, but there are people who routinely post in this thread who are using it for that.

Thanks for the reply!

 

Do we know if it's on the radar of possibility? It seems like such a logical fit. I mean part of me says that because I'm absolutely in love with what this mod brings to the table...absolutely!

 

Thanks again!

 

- Edit - I did some digging through this thread to find that this subject has been hashed out several times before me... apologies for bringing that up again. I know that mod makers are often times on the receiving end of very rude comments and such from the community, and I certainly don't want to put myself in that category.

Thanks for doing what you all do!

- Sincerely,

A KSP enthusiast

OzzyInSpace

Edited April 24, 2017 by SpaceX

[Shadowmage]

50 minutes ago, SpaceX said:

Thanks for the reply!

 

Do we know if it's on the radar of possibility? It seems like such a logical fit. I mean part of me says that because I'm absolutely in love with what this mod brings to the table...absolutely!

 

Thanks again!

 

- Edit - I did some digging through this thread to find that this subject has been hashed out several times before me... apologies for bringing that up again. I know that mod makers are often times on the receiving end of very rude comments and such from the community, and I certainly don't want to put myself in that category.

Thanks for doing what you all do!

- Sincerely,

A KSP enthusiast

OzzyInSpace

The good news on this front is that there might be an upcoming project from someone (not me) consisting of a patch set to be used with RSS (but not RO) that features SSTU being used as the core of its set of parts and feature set (fuel switching, engine clustering, modular parts, etc).  As I understand it, it would be an 'RO-lite' that would be intended as a rebalance for real-scale solar systems (whether RSS or upscaled stock system), featuring real-world stats and model scales for engines and other spacecraft parts (capsules, rtg, solar, etc).

I haven't checked in on it in awhile but last I heard it was making good progress.  I'll try to see where the project stands currently and get a few more details on it.

 

On 4/22/2017 at 11:43 PM, CVerts said:

I have a question for this modpack. What should I do if I only want to use certain packs for my game? For example, if I want to use Ship cores general and Series C and the landers.

This isn't really a 'modpack', but more of a single really large mod.  Due to the use of texture and mesh/model sharing across many of the parts it is extremely difficult to have a clean separation between the different series' of parts.  For example many of the engine models and textures are re-used in the various ShipCore part-series, as are the RCS blocks and docking ports.

If you have a specific list of parts that you do want to keep I can probably give you a quick write-up of what all would be safe to delete/remove.

On 4/22/2017 at 10:50 AM, tater said:

PS--silver might be nice for a mount option.

Mounts will be getting free-recoloring with the next update (along with tanks, nosecones, adapters).  Should be easy enough to include a silver specular map; would use the same diffuse texture merely with a different pre-set base color for the silver texture set.

On 4/20/2017 at 8:24 PM, wb99999999 said:

However, both of my attempt resulted in malfunction, with the first one resulting the two exhaust ports having no plume nor flare whatsoever, and the second one resulting both main nozzle and the exhaust ports having no plume and flare. simply changing the plume type seems to mess with the setup somehow...

I'll try to play around with this next time I'm setting up plumes and let you know what I find out.  Probably something simple in the patches/edits thats getting missed or messed up.  Could also be the known error with the kerolox plume configs/patches in RealPlume itself.

[tater]

I think that my Atlas is actually pretty passable for something not built with tanks that have a "replica" pedigree.

So far, 4X planet sizes works very well with "stock" sstu. 

[RedParadize]

23 hours ago, Shadowmage said:

The good news on this front is that there might be an upcoming project from someone (not me) consisting of a patch set to be used with RSS (but not RO) that features SSTU being used as the core of its set of parts and feature set (fuel switching, engine clustering, modular parts, etc).  As I understand it, it would be an 'RO-lite' that would be intended as a rebalance for real-scale solar systems (whether RSS or upscaled stock system), featuring real-world stats and model scales for engines and other spacecraft parts (capsules, rtg, solar, etc).

Make sense, SSTU have the best customisable engines and tanks on the market and is fairly easy to balance globally. KSP can easily played with SSTU only. 

[tater]

4 minutes ago, RedParadize said:

Make sense, SSTU have the best customisable engines and tanks on the market and is fairly easy to balance globally. KSP can easily played with SSTU only. 

I'm doing that in my rescale now, though in the early game, I have used the mk1 command pod, and then the TRAILS Gemini command pod. I don't like science farming stuff (driving around KSC), so I have not unlocked the Apollo capsule yet (though I just got Soyuz)..

[tater]

I've been doing the Career Evolution Contract pack in my 4X planets, 6.4X solar system. This is my first crew mission to the Mun. I haven't put life support in, but I'm playing as if I have anyway, so I'm not sending 2 kerbals in a Gemini to the Mun for a couple weeks, and I added the earliest inflatable for them. You'll note I don't even have proper RCS, lol, but I needed to dock with the inflatable. I'm suspending disbelief that there would be a crawl-through with that capsule.

 

 

 

 

Edited April 26, 2017 by tater

[ComatoseJedi]

54 minutes ago, tater said:

I'm suspending disbelief that there would be a crawl-through with that capsule.

I believe the real Gemini capsules had a top hatch? The docking system was not hollow, so there was no ability to transfer people or material between the craft; the docking system merely locked two craft together. But, in the Kerbal universe, anything goes. lol 

But, I am guessing you already knew that. This is just for the people who didn't know. 

[CatastrophicFailure]

Yes, some of the ideas floated to get crew from a Gemini into a space station were... interesting, to say the least. 

Like a great big hinge below the capsule so it could pivot around and join the hatches within an inflatable curtain. 

[ComatoseJedi]

I'm sure once they proved they could actually dock in space. As it was explained in the series "From the Earth to the Moon". "You wanna have some fun? You stand in the back yard with a tennis ball and I'll stand in the front. You throw the tennis ball over the house and I'll hit it with a rock". But, I'm sure once the later versions was designed to utilize the docking port as a crew transfer system. And no doubt it was a tricky squeeze. 

[pap1723]

Hi @Shadowmage!

If I haven't said it before, thank you for SSTU and I love all of the work you have done. It is one of my must have mods that I need to play with!

I am using this in Realism Overhaul RP-0 and the way it works, the limits on the tank sizes are not necessary to upgrade like in stock. They should be available from the beginning.

I have messed around with creating MM patches with the TECHLIMITS information, but I CANNOT get the max and minimum tank sizes available from the beginning, can you help me with my stupidity?

Thanks,

Pap