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

[Burning Kan]

2 hours ago, Jimbodiah said:

Has anyone gotten this to work for LH2

maybe he?

or :

@PART[*]:HAS[@MODULE[LaunchClamp]]
{
    @MODULE[ModuleGenerator]
    {
        @OUTPUT_RESOURCE[LqdHydrogen]
        {
            @rate = 100 //1 is normal
        }
    }
}

when that not worked, then the direct way into the cfg:

MODULE
    {
        name = ModuleGenerator
        isAlwaysActive = true
        isGroundFixture = true
        OUTPUT_RESOURCE
        {
            name = LqdHydrogen
            rate = 20
        }
    }

 

Edited April 10, 2018 by Burning Kan
mm-cfg+part cfg

[Jimbodiah]

The way to patch it is not the issue, as I have it working for Ec and supplies as per my example. It is LH2 that for some reason will not generate/fill.

[Starwaster]

@Jimbodiah Don't just look at the base configs, look at the final result in ModuleManager.ConfigCache both for the clamp and for the resource definition.

[Jimbodiah]

@Starwaster   It shows up there as well.


Problem solved... I need to enable crossfeed on the MFT tanks; it is disabled by default.     

@Shadowmage  Is there any input on ModuleToggleCrossfeed that will allow me to set this to true in a patch?

Edited April 11, 2018 by Jimbodiah

[Starwaster]

40 minutes ago, Jimbodiah said:

  Is there any input on ModuleToggleCrossfeed that will allow me to set this to true in a patch?

@crossfeedStatus = true

[Jimbodiah]

Thanks!!!  I'll try it out.  Where did you find the info for that btw?

[Shadowmage]

7 minutes ago, Jimbodiah said:

Thanks!!!  I'll try it out.  Where did you find the info for that btw?

The API docs:

https://kerbalspaceprogram.com/api/class_module_toggle_crossfeed.html

You can browse the public fields for any of the part-modules.

[Jimbodiah]

Hah... never thought to look there. This is a stock module?

Thank you!

[Shadowmage]

3 minutes ago, Jimbodiah said:

This is a stock module?

That particular one is, yes.

You can see a list of all of the stock PartModule classes here:  https://kerbalspaceprogram.com/api/class_part_module.html

Click on the name of any module to browse its fields.  It doesn't look like their API scraping captured the [KSPField] declarations, but any values listed under 'Public Attributes' should be accessible as a config value for that module.

E.G. The stock SAS module lists the following 'public attributes'  -- https://kerbalspaceprogram.com/api/class_module_s_a_s.html

int 	CommandModuleIndex = -1 
bool 	RequireCrew = false 
int 	SASServiceLevel = 0 
bool 	standalone = false
string 	standaloneStateText = "" 
bool 	standaloneToggle = true
 

It is very probably that those are all valid config file entries.

 

In general development news:

More work on cleaning up issues in KSPWheel (dust-effects null-ref log spam), more fixes in TU (transparent materials, flag decals), and finally figured out why some of my config node parsing was returning values in reversed order (changes in stock code that now write-out config nodes backwards). 

That last one has been a head-scratcher for a couple of weeks now, as the problem itself was making debugging it difficult;  the problem was that the configNode.ToString() method would return values in the opposite order they were defined in the config file, and I use that method to 'store' config nodes in text form within some of the part-module classes.  So when the config node is stored into text, the values get reversed.  It is then reloaded from the text form, in the order that it was stored (backwards).  Any attempt to use the ToString() method to debug those reloaded nodes would display the 'proper' order, as it would re-reverse the ordering in the displayed text output.

100% certainly a 'bug' in stock code.  Likely it was someone trying to make an optimization regarding a loop iterator, but in many cases iterating backwards is incorrect -- notably anytime you are iterating a list or array -- ordering is important, and you cannot arbitrarily re-order a list or array (part of the 'contract' of a list or array is that the ordering is guaranteed by the implementation; it is one of the main reasons to use a list or array compared to some other unordered storage method).  Only that is exactly what the stock code is doing -- re-ordering a list of values, arbitrarily and without explicit (or implicit) instruction.  Worse yet -- the code worked fine in previous KSP versions (it iterated values in the proper order in the ToString() method).  This was an intentional and unnecessary change someone made; a change that should have never made it past review and into production code; a change that cost me at least a few nights worth of dev time to track down and hack around.

So, with that figured out and mostly worked around, I can finally get back to actual progress.

[Shadowmage]

As I was working on fixing up some PBR texture sets, I though 'ehh, why not give it a try'.... and enabled basic PBR shaders for all of the lineup of engine models.  Some definitely came across better than others, but the effects aren't bad for a simple shader swap (zero changes to textures), especially considering its really only using half of the texture inputs properly (AO is still baked into the DIFF, no metallic maps at all).

Merlins came across a bit too dark looking.

RD-107/108a came across pretty good.

Conversion of the -0110 was... not so great

Interesting contrasts on the RS-25

F1B Looks pretty good

RL10 needs some changes to the diffuse, spec, and metallic maps for a better look.

The RD-180 series are all far too reflective with the basic conversion.  Will need better specular and metallic maps.  The NRM details on the bells looks pretty good, but the base surface is simply too reflective (too smooth/not rough enough).

If for nothing else than consistency, I'll probably include this basic PBR conversion of engines with future releases.  I still want to create proper PBR textures for all engines at some point, but this quick and dirty patch will likely fill in for the meantime.

[mechanicH]

I Know this is gonna sound silly but i kind of like this shinny look on the engines....but thats just me   

[FrancoisH]

@Shadowmage This is awesome work anyway, I like so much those engines... Can't wait to get rid of my KWR install and get back my SSTU

[Jimbodiah]

Those RD180s would look cool like that if they would be lighter :). My favorite kerolox engines by far, and they just got better

And those Merlins. Mnom mnom mnom!!!!

Edited April 13, 2018 by Jimbodiah

[Norcalplanner]

15 hours ago, Jimbodiah said:

Those RD180s would look cool like that if they would be lighter :). My favorite kerolox engines by far, and they just got better

And those Merlins. Mnom mnom mnom!!!!

I'm a big fan of the RD-181 myself, simply because it's a bit more versatile. Compare it to the Skipper, and the RD-181 is superior pretty much across the board.

RD-180s are good too, but they're a bit too powerful to be used as a second stage in my typical applications.

Edited April 13, 2018 by Norcalplanner

[Jimbodiah]

RD180 for a second stage? What are you launching, asteroids?    haha

[SpaceX]

Me like shiny objects!

[Shadowmage]

Here is some more 'shine' to help your shin object obsessions

Trying out KS3P, seeing how well it works alongside TU and the PBR shaders.  While the default configs on KS3P are perhaps a bit overdone, it all seems to work together properly (minus a bug with one of the features that doesn't load under GLCore).

[Jimbodiah]

So, 1.4 release tomorrow? 

 

[Bonus Eventus]

On 4/11/2018 at 7:36 PM, Shadowmage said:

As I was working on fixing up some PBR texture sets, I though 'ehh, why not give it a try'.... and enabled basic PBR shaders for all of the lineup of engine models.  Some definitely came across better than others, but the effects aren't bad for a simple shader swap (zero changes to textures), especially considering its really only using half of the texture inputs properly (AO is still baked into the DIFF, no metallic maps at all).

Merlins came across a bit too dark looking.

RD-107/108a came across pretty good.

Conversion of the -0110 was... not so great

Interesting contrasts on the RS-25

F1B Looks pretty good

RL10 needs some changes to the diffuse, spec, and metallic maps for a better look.

The RD-180 series are all far too reflective with the basic conversion.  Will need better specular and metallic maps.  The NRM details on the bells looks pretty good, but the base surface is simply too reflective (too smooth/not rough enough).

If for nothing else than consistency, I'll probably include this basic PBR conversion of engines with future releases.  I still want to create proper PBR textures for all engines at some point, but this quick and dirty patch will likely fill in for the meantime.

It’s amazing how much value PBR adds to texture quality. I’ve started to work nondestructively in photoshop so I can more easily export pbr textures when the time comes. This should be part of the stock game. Considering how much effort was put into adapting Squad legacy shaders,  as well as a planned part update, you’d think they would have just went with the standard shader model.

[Shadowmage]

26 minutes ago, Jimbodiah said:

So, 1.4 release tomorrow? 

 

Hehe... if only....

You can try out the KSP141 branch from github if you wanted to see the state of things.  A lot is working, but still a lot to fix / update / finish.

[Shadowmage]

More shiny goodness -- the solar panels look quite nice with bloom enabled:

Edit:  Second shot, more shininess...

Edited April 16, 2018 by Shadowmage

[Jimbodiah]

Show-off!!!!

I am actually waiting for a stable release for 1.4.x first before even attempting to install any mods into it.  1.3.1 is doing fine for now

 

Spoiler

 

[FrancoisH]

I drool all over myself... Can't wait !

[Shadowmage]

More fixes today (one step closer to a 1.4 version) -- Command Pod cabin and docking lights.  The config syntax for the modules had changed on these, so all of the parts needed to be fixed.  They are now fixed up, working, and no longer spamming my log with errors.

More glamour shots...  (KS3P bloom is perhaps overdone.... but the results are highly effective for cinematic shots)

 

(I promise, I'm working on getting everything fixed for 1.4 as fast as I can, and lots of stuff is 'working', but still a lot is very much broken; still going to be at least a few weeks... I'll try to narrow down that timeframe when I know more)

[Jimbodiah]

Are you running stock or rss in that screenshot?