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

[blowfish]

For the asset bundles, it might be worth trying the part tools that are included with Porkjet's parts.  I'm not 100% sure they will fix the problem, but I think it's worth a shot

[mechanicH]

Hello all,   just got a quick question, Does anyone get the "NullReferenceException: Object reference not set to an instance of an object"  code spam in the debug when you use the orbital re entry command pod-C. For some reason it does that all the time and hits my fps very hard in the VAB. just wondering if this is normal or if there is a fix for this?.

[Theysen]

56 minutes ago, mechanicH said:

Hello all,   just got a quick question, Does anyone get the "NullReferenceException: Object reference not set to an instance of an object"  code spam in the debug when you use the orbital re entry command pod-C. For some reason it does that all the time and hits my fps very hard in the VAB. just wondering if this is normal or if there is a fix for this?.

FAR installed? 

[mechanicH]

yes  i do have FAR installed. Should i take it out?

[Shadowmage]

4 minutes ago, mechanicH said:

yes  i do have FAR installed. Should i take it out?

Yes;  SSTU is currently incompatible with FAR ( https://github.com/shadowmage45/SSTULabs/issues/346 ).  Fix has been submitted to FAR and is awaiting an updated release; you likely won't see it for 1.1.3 though, seems like the next FAR update will be for KSP 1.2.

Sadly your options at the moment are basically to remove FAR or SSTU.

[mechanicH]

well my option is clear then, i rather keep your mod. bye bye FAR for now. thank you for the quick respond guys, i really appreciate it,  As always keep up the amazing work, and thank you once again.  

[Shadowmage]

23 hours ago, falken said:

[...]
On that subject, Shadowmage do you have plans to make an S1-B mount? You have the engine cluster setup already, but can't see an S1-B mount. Not a huge deal though.

Something I was also wondering, Shadowmage... are you able to make the engine able to throttle down to nearly nothing, beyond what would normally flame out the engine? I have setup a thrust curve for my SRBs that throttles them down to just above the flameout range for a cleaner SRB cutoff with the candles still lit, but when you upscale beyond 1.875, sepatrons are needed around the base of the SRB to stop them overtaking the main launcher.

Again, this isn't a huge issue, I'm just curious.

[...]

S1-B mount?  Isn't it just a straight shroud mount with fins attached?  (the straight shroud already exists; I cannot add fins due to KSP's aero handling code).

SRBs -- Sorry, but no, I don't have any control over when the engine stops producing thrust or its minimum thrust before flame-out -- that is all part of the stock ModuleEngines code that is not under my control.

[RedParadize]

Looks like 1.2 allow AO via vertex colors. Its not new tech but it might allow you to do some of the stuff you want to do. (it won't allow to remove occlusion for pipe/no pipe thing I believe.)

[blowfish]

14 minutes ago, RedParadize said:

Looks like 1.2 allow AO via vertex colors. Its not new tech but it might allow you to do some of the stuff you want to do. (it won't allow to remove occlusion for pipe/no pipe thing I believe.)

I'm not sure if it's a new feature, just that this might be the first time it's actually used.  Note that not all the AO on Porkjet's new parts is done with vertex colors - most of what you see on the engines is baked into the texture - what's done with vertex colors is (1) shadowing the entire engine on the boattail variants and (2) shadowing the tank ends.  Vertex color AO in general has a lot less resolution than baked AO, and the AO from the pipes is really at too small a scale (compared to the mesh) for that to work in this case.

[Shadowmage]

Indeed did a bit of research/investigation on this the other day when I first say that info; it turns out the resolution of vertex-based AO depends entirely on the resolution/subdivision of the mesh.  Most of mine are fairly 'low-poly' in style, lacking any subdivision, and would look terrible with vertex-based AO.

I still think the custom shader will be the 'proper' way to go about getting swappable AO on the meshes.  It certainly has higher overhead than vertex-colors, but is also so much more powerful, and can be even further customized if needed.

Speaking of which... I think I'll d/l U5.4 and see about recompiling the shader and seeing if it still works in game tonight.

[RedParadize]

Yep, the cylinder, unless if you add much more division, will not allow much details. I have worked with vextex color in 2007ish 2009 in unity (Lazy Raiders), on our side we were not just using it for AO but for lighting and color itself, it allow to multiply texture with vertex attribute and induce more variation with less texture. Downside is as a workflow its pretty crappy...

Exemple: You have a AO texture, you use the vertex color/lighting to multiply divide AO when facing light. At least that what I recall...

Edited September 15, 2016 by RedParadize

[Shadowmage]

Okay... so on the note of custom shaders...

It is looking like I may need to build custom shaders for each supported platform (Win, Mac, Linux), or at least Win & Mac/Linux (they should both use OpenGL?).  Then, at load-time, I would load only the shaders tagged for that specific OS/platform/rendering setup (not sure if I need both D3D and OpenGL compiled shaders, or if the compiled shader includes instructions for both where applicable (Windows)).

I build and develop on Windows.  I do not have access to any Mac or Linux pcs to do any testing on those.  Is there anyone with a Mac and/or Linux install who would be interested in helping to test shader compatibility?

The reason the AssetBundle compiler no longer works in Unity 5.4 is due to the Unity BuildPipeline.BuildAssetBundles() method now requiring that a Target Platform be specified as a parameter (previously was optional), which the PartTools currently do not support (even the ones from PorkJet's parts only work in 5.2.4).

This was easy enough to solve though.  A custom script to build asset bundles is actually included as an example in the Unity documentation ( https://docs.unity3d.com/Manual/BuildingAssetBundles.html ) and will work well enough for my purposes after a bit of customization.  It won't build KSP-compatible AssetBundles (with the KSP metadata file), but as I can't actually get KSP's AssetBundle loading code to actually load things, that doesn't matter anyway (I use my own loading mechanisms, KSP never even sees my bundles as potentials for loading).

[RedParadize]

I have a linux at work. I could test it if you want. Do it need 1.2 or 1.1.3?

[tater]

I have a Mac. I have both KSP versions installed still (1.1.3 and 1.2), and I can test on Yosemite and El Capitan (on my daughter's laptop).

 

Edited September 15, 2016 by tater

[Shadowmage]

2 hours ago, RedParadize said:

I have a linux at work. I could test it if you want. Do it need 1.2 or 1.1.3?

 

1 hour ago, tater said:

I have a Mac. I have both KSP versions installed still (1.1.3 and 1.2), and I can test on Yosemite and El Capitan (on my daughter's laptop).

 

Thanks, both of you

Testing will be for 1.2-prerelease.  I likely won't have anything available until at least tomorrow sometime, and even then it will be for just testing the shader stuff (the rest of the updates are still WIP, stock symmetry bug with resources not yet fixed).  I'll post up/PM some links to the testing releases when they are ready.

If anyone else is also interested, feel free to let me know -- won't hurt to have a few more test cases.

 

In general development news:

Spent a bit of time today working on the new MFT 'subtype' system.  The changes needed were mostly minor, and the updated code has fallback paths to still load the old parts/configs (if no TankSets are defined, all tanks get added to a single default set and the 'Set selection' GUI widget is disabled; falling back to the previous functionality).  Will be compiling and testing out this code tonight.

Compiliation scripts for shader AssetBundles have been written for OSX, Linux, Win32 and Win64.  Sucks that I'll have to ship multiple shaders, but apparently there is no way around it (Unity engine limitation).  Thankfully Unity gives pretty concise methods for determining which ones to load, so it shouldn't be too difficult to get the right one loaded for the platform.  From there it should all 'just work'... but we'll see how true that is

If I can get the shaders to at least compile and load for Win I'll also be spending a bit more time finishing up the custom shader support for ModelData based texture-set switching (already working, but needs testing and cleanup).  Also need to adjust the actual shader code a bit to support KSPs '_rimFalloff' stuff which is used for part highlighting.

Edit:  Further discoveries.  Not sure if this is new or not, but apparently there now exists an interface (IContractObjective) where I can specify that a mod-added PartModule meets specific contract requirements.

This means that I can actually fix the 'SSTU Solar Panels won't complete contracts' problem posted a few days back.

Edited September 15, 2016 by Shadowmage

[Pappystein]

4 hours ago, Shadowmage said:

S1-B mount?  Isn't it just a straight shroud mount with fins attached?  (the straight shroud already exists; I cannot add fins due to KSP's aero handling code).

 

From the side the S1B H-1 engine array looks like a Straight Shroud mount.   However like the Russian N-1, the Engines are actually embedded inside the structure (there is a bottom plate and some structural members below the engine attachment points.

Here is a picture of the bottom from SA-209, which is in the rocket garden at Kennedy IIRC.

 

The only Saturn Stage that Had and kept a Straight Shroud like you created for your mounts was the S-II (C or D?) stage for the proposed but never built Saturn II (INT-17,-18 or -19)
   In those cases it was either 7,6,5 or 4 J-2s or HG-3s in an open cavity, the shroud acting like a Cruiser transom on a boat/ship.   The original S-II shape from a stock Saturn V would cause a significant reduction in effective thrust until out of ground effect (~100 meters AGL.)   Due in part to poor aerodynamics around the 5x engine arrangement and partially to excessive drag.

And yes, the H-1s only had 1 axis/direction gimballing.

Outer engines only = Roll Control but only to the left.

Inner + outer engines = Yaw and Pitch control (one inner and one outer engine for each Direction +Yaw, -Yaw, +Pitch, -Pitch)

The whole setup looks complicated but it is actually simpler than a Bi-Directional Gimbal setup for the early computer control.  

 

Edited September 15, 2016 by Pappystein
drag

[Shadowmage]

Sadly mount such as those (with holes cut in them for the engines) are not something I'm really interested in creating, especially when other (visually compatible) options already exist.

This is mainly due to the fact that they cannot be rescaled; so I would have to create the mount at a single specific size, and it would not be usable for any other engines or diameters.  I have made a few exceptions for a few engines where sufficient mounts did not already exist (RS-68, RD-107/8).  But in this case the straight shroud mount will work sufficiently for the purposes.  Is it an exact match?  No.  Is it close enough (for me at least)?  Yep.

Separate gimbal setups within a single-part engine cluster -- this is not something that the KSP ModuleGimbal will support.  It expects every 'copy' of a gimbal transform to have the exact same constraints on gimbal mechanics.  The only way to do this would be to create multiple copies of the same engine part config each with different part names and gimbal setups, and hand-build your engine cluster from those uniquely setup engines.

[tater]

Close enough. I didn't bother to try for the actual 1st stage look, but I could have, though it might add maybe 11 parts (needed a tick more closing up the cluster spacing I see).

I used the vertical control to move the cluster into the tank.

Edited September 15, 2016 by tater

[Shadowmage]

Hmm... what could this thing possibly be?

 

Yes it actually works (so far at least).  Each upgrade diameter comes from a specific tech-node, and each has a purchase cost associated with it.  You can unlock the full 'max diameter' through the game-difficulty options when in sandbox.

The only remaining question is whether I should tie all of the modular parts to the same 'upgrade parts' or give them separate paths.  I'm leaning towards separate paths -- the stock system only allows unlocks from a single tech node for a specific upgrade, and engines (SRBs rather), fairings, and fuel tanks would generally belong in different parts of the tree, and thus so should their upgrades.  As such I would propose that the SRB (and RBDC) upgrades be put into the rocketry path, fairings, petal-adapters and interstage-decoupler placed into the aero path, and fuel tank upgrades follow the fuel tank path.

 

Tank-sets / variants are also in and working.  MFT A+B have been combined into a single part, and the MFT-K tanks will be added to it shortly.  Only adds a single additional editor control and maintains full backward compatibility with old parts/configs.  Good stuff.

 

Overall this KSP update has been far less painful than 1.0 or 1.1.  Only a few code-related surprises.  So far it is looking likely that I'll have something available for public testing as soon as there is an official ModuleManager update (or sometime this weekend, whichever comes last).

Going to do a bit more investigation into the shader stuff next. Working on and hoping to have a 'shader-testing' release available tomorrow evening if all goes well.

 

[tater]

Felt compelled to fix it a little...

[RedParadize]

@Shadowmage Quick question, is there any equivalent to subtractMass but for cost in SSTUVolumeContainer? Like subtractCost ? 

I have bug to report: If you add a KIS container to SSTUVolumeContainer on a pod. It will set seat KIS volume to 0.

Edited September 16, 2016 by RedParadize

[Shadowmage]

23 minutes ago, RedParadize said:

@Shadowmage Quick question, is there any equivalent to subtractMass but for cost in SSTUVolumeContainer? Like subtractCost ?

Yep, exactly that.   subtractCost does the same for cost as subtractMass does for mass.  If set to true the VolumeContainer will zero out the config specified cost (for use in fuel tanks) (defaults to true), if set to false it will -add- the calculated cost onto the config cost (for use in other parts such as pods).

https://github.com/shadowmage45/SSTULabs/blob/master/Source/Module/SSTUVolumeContainer.cs#L41

[RedParadize]

@Shadowmage I should probably dig a bit more in your github code. I am sure I would learn much.

In case you didn't see it, as I edited my post at the same time as you posted.

[Neptunian]

Whats the progress on the I.S.S Textures?

Edited September 16, 2016 by Neptunian
oops, forgot the sauce.

[Duski]

6 hours ago, Neptunian said:

Whats the progress on the I.S.S Textures?

Don't go badgering mod makers on progress of their mods. I believe its's not allowed on the forums. They'll tell you when they do. I know you want to know, but that's just how it is.