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

[Temeter]

Just now, Shadowmage said:

Known issue:  https://github.com/shadowmage45/SSTULabs/issues/362

Yea, stock code completely screwed up the most efficient methods for updating the emissives.  The stock highlighting just loves to come along and overwrite things. 

I've exhausted the 'right' way to do things (stock code still overwrites it), and I'm down to the terribly slow/inefficient methods for keeping things working -- basically I have to force-update the mesh rendering properties every frame whether it needs to be updated or not... ridiculous, and -terrible- for performance.

--This is one of those places where the stock code really needs to be fixed so that it isn't blindly overwriting things.  It -should- pull the existing MaterialPropertiesBlock from the render, update the parameters that need changed, and then re-set the materials block to the material.  What it currently does is clear all properties from the block, set the single property for highlighting, and then re-sets the block to the material (thus overwriting whatever was -previously specified- by the existing block in the material).

Honestly, I did things the way they should be done (as per Unity best practices and examples), and the stock code is simply not doing things properly.  Putting this problem on the 'I'll check back with KSP 1.2.1...' list.

I see, kinda expected it, but just wanted to check back. Did you take a look at the stock pods? They have all lighting now themselves, without any issues. Might be a new method?

[Shadowmage]

3 minutes ago, Pappystein said:

 

Correct me if I am wrong (and I know I probably am at least not right if not straight out wrong,) but couldn't a Realchute integration and a Requires RealChute dependancy, fix most of your issues here?   I mean assuming you are not trying to make your own GUI etc for all the various portions?

 

As far as I'm aware RealChutes requires that the parachute models be built into whatever part it is (which is how the stock parts are done).  My module has a completely detached setup -- the parachute models are completely separate from whatever part they are being added to and are defined entirely through config (models, textures, positions, orientations, scale, and drag are all defined through the text config).  Of course, I've never actually used RealChutes, so could be off on some of that.

Either way -- I need a stand-alone solution that works for my parts without requiring an external dependency.  So RealChutes is simply not an option.

 

4 minutes ago, Temeter said:

I see, kinda expected it, but just wanted to check back. Did you take a look at the stock pods? They have all lighting now themselves, without any issues. Might be a new method?

Will take a look -- as far as I'm aware the stock pods use Animations which are not an option for my parts (they have no animations on them, is all done through the Module and config-defined emissive curves).

Animations, from my understanding, use the same inefficient methods that I would have to resort to (e.g. force-updating the render properties every tick even when not needed).

Will also take a look at what Nertea did to fix his, but those are likely animation-based as well.

[Temeter]

Just now, Shadowmage said:

Will take a look -- as far as I'm aware the stock pods use Animations which are not an option for my parts (they have no animations on them, is all done through the Module and config-defined emissive curves).

Animations, from my understanding, use the same inefficient methods that I would have to resort to (e.g. force-updating the render properties every tick even when not needed).

Will also take a look at what Nertea did to fix his, but those are likely animation-based as well.

Ah, I see.

If you wanna try to give squad a pointer, maybe try the bug tracker? I'd do it myself, but I dont really understand those systems. http://bugs.kerbalspaceprogram.com/projects/ksp/issues

[Nertea]

Those are some beauteous inflatables sir!

2 hours ago, Shadowmage said:

Will also take a look at what Nertea did to fix his, but those are likely animation-based as well.

Yup, they are animations. Honestly you could probably write some code to construct the animations at loadtime (or even when the part is switched) for those parts - it might be a good compromise. You would get the animation method without having the tedium of creating and exporting animations.  I did runtime animation creation for a project of mine in Unity some time ago, so it's certainly possible. 

[Shadowmage]

2 hours ago, Temeter said:

Ah, I see.

If you wanna try to give squad a pointer, maybe try the bug tracker? I'd do it myself, but I dont really understand those systems. http://bugs.kerbalspaceprogram.com/projects/ksp/issues

Yeah, I probably will end up filing a bug report on this one.  There are actually a couple (inter-related) issues at play.

I just tested the stock Mk1-2 pod, and while it is true that the highlighting doesn't break the cabin lights, it is also true that the cabin lights partially break the highlighting on the part.  So the stock code is already breaking other stock code when cabin lights are used.  The outline highlighting still works (as that is using a separate render path), but it breaks the rim-light highlighting.  This can be seen by comparing the highlighting on the Mk1-2 pod to one of the stock fuel tanks.  Note how the fuel tank gets a green outline as well as some green tinting on the mesh.  The Mk1-2 pod only gets the green outline and lacks the rim-highlighting/tinting on the mesh itself.

It seems that the stock module for handling lights (which actually is a config-based module now, ModuleColorChanger) simply overwrites the MPB used by the highlighter.  I'm unable to dig into the stock code, but based on what I'm seeing in the editor and from my own module, the stock module must be updating these properties every frame even when not needed.

As I already have a (mostly) functional Module and configs for these parts I can, at least for the time being, move my update code to update every frame.  ... rather I just have... and as a bonus, it doesn't break the stock highlighting as I'm using the MPBs properly.  Still far from optimal as it shouldn't need to be updated every frame, but I'll have to go with 'hopefully good enough' on this one.

 

Have also just finished fixing the solar panel code up a bit to allow for stuff such as:

Note the orientation of both panels, facing towards the camera.  Have enabled mirror symmetry for the BKT-D/E panels so they no longer face opposite directions when placed with the stock symmetry tool.  It does enable some skylab type setups to be created... but has some odd issues in general use (hard to control panel orientation, it flips whichever way it wants and there is no manual way to fix it).  Unsure if I'll be keeping it in place or moving to a custom solution that is a bit more controllable.

 

[Temeter]

1 hour ago, Shadowmage said:

Yeah, I probably will end up filing a bug report on this one.  There are actually a couple (inter-related) issues at play.

I just tested the stock Mk1-2 pod, and while it is true that the highlighting doesn't break the cabin lights, it is also true that the cabin lights partially break the highlighting on the part.  So the stock code is already breaking other stock code when cabin lights are used.  The outline highlighting still works (as that is using a separate render path), but it breaks the rim-light highlighting.  This can be seen by comparing the highlighting on the Mk1-2 pod to one of the stock fuel tanks.  Note how the fuel tank gets a green outline as well as some green tinting on the mesh.  The Mk1-2 pod only gets the green outline and lacks the rim-highlighting/tinting on the mesh itself.

It seems that the stock module for handling lights (which actually is a config-based module now, ModuleColorChanger) simply overwrites the MPB used by the highlighter.  I'm unable to dig into the stock code, but based on what I'm seeing in the editor and from my own module, the stock module must be updating these properties every frame even when not needed.

As I already have a (mostly) functional Module and configs for these parts I can, at least for the time being, move my update code to update every frame.  ... rather I just have... and as a bonus, it doesn't break the stock highlighting as I'm using the MPBs properly.  Still far from optimal as it shouldn't need to be updated every frame, but I'll have to go with 'hopefully good enough' on this one.

Interesting! I've noticed the limited lighting on certain parts, and was wondering why that happened. But I think it's worth it; lighted modules, especially in the darkness when overshadowed by planets or in deep space, make craft feel much more lived in and less dead. One of those small details that make a difference.

On a positive note, if it is stock functionality, then there is a higher chance of it getting fixed in an official patch! Otherwise I did not notice larger performance issues when using stock capsules (even though doing something once per frame sounds incredibly wasteful).

Edited October 27, 2016 by Temeter

[Jimbodiah]

Spoiler

click to enlarge

@Nertea's NF trusses, radiators and reactor, @RoverDude's USI MKS airlock and cupola, @CobaltWolf's BDB Apollo and SSTU for everything else.

Edited October 27, 2016 by Jimbodiah

[tater]

`Other than looking really cool, are there any advantages to spherical tanks?

I made a kerlox tank in both the standard and spherical types at the default size.

The MFT-A has a dry mass that is 13.045% of the total mass.

The MFT-S dry mass is 13.040% of the total mass. 

Light tanks makes MFT-A and MFT-S both 10.11% dry mass.

Seems odd.

[Shadowmage]

10 minutes ago, tater said:

`Other than looking really cool, are there any advantages to spherical tanks?

I made a kerlox tank in both the standard and spherical types at the default size.

The MFT-A has a dry mass that is 13.045% of the total mass.

The MFT-S dry mass is 13.040% of the total mass. 

Light tanks makes MFT-A and MFT-S both 10.11% dry mass.

Seems odd.

Nope, no advantage.  They are different for looks/aesthetics only.  Theoretically they should have a much lower 'tankageVolumeLoss' compared to cylindrical tanks.  Also they haven't really been balanced, I'm not even sure I got the volumes set up on them properly.  Either way I wouldn't expect the mass ratio to change.

 

Bit more work on inflatable textures.  Added some shading and more definition to the paneling sections, but I think it is overdone a bit.  Wanted some 'depth' to it, but ended up looking a bit dirty.  Not terrible, just...a bit dirty.  Still on a pretty good course to have these textures wrapped up in the next few days.  Models are mostly ready for exporting, configs are mostly done. 
WARNING -- the finished hab parts will have different naming from the existing prototypes, so existing craft using the prototypes will need to be recreated (not unexpected, shouldn't be surprising, but thought I would mention it).  They also have different geometry than the prototypes (lengths, diameters), so they wouldn't really have been compatible even if the naming were unchanged.

[tater]

I agree on the stripes being a little overdone.

Is the render above different than this?:

Cause it might be the difference between in game and a regular render (cause this image in orbit looks pretty nice).

[Shadowmage]

10 minutes ago, tater said:

I agree on the stripes being a little overdone.

Is the render above different than this?:

 

Cause it might be the difference between in game and a regular render (cause this image in orbit looks pretty nice).

Yea, the in-orbit img was taken a few days ago -- had zero shading or AO on the textures, and was missing the specular mask (is why everything is so shiny).  The render posted above has added AO as well as some shading on the panel sections.  Probably will lighten up the shading on them a bit -- I want them defined and bubbly, but not 'striped' looking.

 

Edit: Updated render incoming that I think looks much better... only change was to turn down the shading on the paneling to 50% of what it was. 

Might still tweak things a bit further, but looking much closer to what i had intended.

Edited October 27, 2016 by Shadowmage

[tater]

Nice. It's clearly a pretty delicate balance, I "get" exactly what you are looking for since there is no greeble possible on those otherwise smooth surfaces, this is where all the texture will come from that makes it not look "plastic" (in the sense of hard, shiny, plastic).

If the inflated part was translucent with algae in a void between the outside and the inner, hab membrane those would be "arklets" from Seveneves.

[Shadowmage]

Updated in-game screen with the latest textures -- looking pretty good, and about ready to call them finished.  Few more little touch-ups/details to go..

That is all 10 inflatable modules; 2.5m capped/uncapped, 3.75m capped/uncapped, and 1.25m uncapped.

The 1.25m do look a bit comical... going to do a bit of testing to see how usable they are... but I'll likely end up making them 1.875m in the end (when deflated).

 

Edit:  They may look a bit comical, but I suppose that is the Kerbal Way(tm).  Also, they do look quite appropriate when used on the SC-A-SM:

Edited October 27, 2016 by Shadowmage

[mechanicH]

Wow those look great mage.   For some reason I have an urge to make a balloon animal in orbit with those lol. 

Amazing work sir! I applaud you. 

[JoseEduardo]

when inflated, do they have twice the diameter of when deflated?

[Duski]

Just updated to 1.2 for this mod finally after my break of KSP. Anyone else not able to see any of the station core parts and some other parts from this mod?  Can't see their preview on the part list and not visible in the VAB.  

[tater]

2 minutes ago, Duski said:

Just updated to 1.2 for this mod finally after my break of KSP. Anyone else not able to see any of the station core parts and some other parts from this mod?  Can't see their preview on the part list and not visible in the VAB.  

That's the first 1.2 release, it had a boo boo. DL the current version.

[Duski]

5 minutes ago, tater said:

That's the first 1.2 release, it had a boo boo. DL the current version.

Aha, Will do that right now  

Well I am on the latest version, if that is 0.5.33.127.

[tater]

That same issue was with the first version for 1.2. Works fine for me now.

Do you have MM installed latest version?

[Duski]

14 minutes ago, tater said:

That same issue was with the first version for 1.2. Works fine for me now.

Do you have MM installed latest version?

Pretty sure I do, I just put the module manager on that comes with every mod usually.

Checking now, but my KSP keeps crashing on startup due to runtime errors. :/

Edited October 28, 2016 by Duski

[Pappystein]

44 minutes ago, Duski said:

Pretty sure I do, I just put the module manager on that comes with every mod usually.

Checking now, but my KSP keeps crashing on startup due to runtime errors. :/

@Duski

Based on your statements it sounds like you have a Borked Mod or Install.   I would suggest UN-Installing KSP,  Deleting any directory that remains after un-installing and then install KSP 1.2 again.   I am running close to 60 mods on the KSP-X64 and other than a minor mod interaction issue that causes phantom forces at certain altitudes, All mods including SSTU are working great!

You need mod manager 1.7.1,  If you have OTHER Module manager DLLs in the GameData folder problems will ensue.

[blowfish]

@Pappystein @Duski ModuleManager is designed to detect other versions of itself and only use the newest.  Deleting older versions never hurts though.

If you're getting errors on startup though, the only way to find out what's causing them is with logs.

[tater]

Can't wait to play with the new stuff, it's looking really awesome.

[Duski]

1 hour ago, Pappystein said:

@Duski

Based on your statements it sounds like you have a Borked Mod or Install.   I would suggest UN-Installing KSP,  Deleting any directory that remains after un-installing and then install KSP 1.2 again.   I am running close to 60 mods on the KSP-X64 and other than a minor mod interaction issue that causes phantom forces at certain altitudes, All mods including SSTU are working great!

You need mod manager 1.7.1,  If you have OTHER Module manager DLLs in the GameData folder problems will ensue.

Well did a complete reinstall of KSP now but not currently for this, trying to get the debug menu to work but it's not working. D: Will do this asap.

EDIT: Fixed console, now gonna start working my way around this. I think it could be from installing SSTU Nova but not too sure.

Edited October 28, 2016 by Duski

[JoseEduardo]

44 minutes ago, Duski said:

Well did a complete reinstall of KSP now but not currently for this, trying to get the debug menu to work but it's not working. D: Will do this asap.

EDIT: Fixed console, now gonna start working my way around this. I think it could be from installing SSTU Nova but not too sure.

I didn't update that yet, so it's not officially working in 1.2 (so far only the max diameter is broken), but.... I'm using the very same version as the last release in 1.2 right now and I have all the parts from the last SSTU release working...