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

[Shadowmage]

46 minutes ago, JoseEduardo said:

it's not because I asked for them, but the no-cap versions look really cool

btw, Mage, what if you made the endcap and the inflatable parts two separate mesh, and have the different versions managed through a config file, one "hiding" the endcaps and one "showing" them? sorta like the tanks

Would be 6 models either way, but more config work if I broke them up.  So, will be keeping distinct models for most of them; the only models that would be shared/rescaled would be the no-end-cap versions.

 

22 minutes ago, RedParadize said:

Does the super small inflatable with only one end cap and node still exist? I realise it had very limited use but I liked it.

Sadly, no.  Casualty of the increased number of parts (went from 4 inflatables to 10; had drop something somewhere, and that one was an easy choice to drop as it would have required all new textures, and textures are by far the most time consuming part of modeling for me).  Yes, I'm taking the 'easy/fast' path on these parts... far to many other things need to be done, compared to spending another week on textures for a single part.

Instead you'll be getting some 1.25m or 1.875m sized standard inflatables (not sure yet what size; the 1.25m is really close the the existing HAB-D, but seem a bit comical when viewed next to the large ones; 1.875m would allow for using the SC-A-SM as a ferry/delivery tug).

 

Will be keeping the mesh/model around in my dev repository to revisit it in the future, probably for some more planetary-base oriented parts.

[RedParadize]

All good, it was nice but not a must have. I would rather have the rings done then that. I am excessively curious to see what you decided for the large one.

[Shadowmage]

10 minutes ago, RedParadize said:

All good, it was nice but not a must have. I would rather have the rings done then that. I am excessively curious to see what you decided for the large one.

Me too   (Curious as to how I'm going to do the large torus/centrifuge parts; it might end up being 'not a doughnut' but something else entirely...... but there will be at least a couple doughnuts).

[Jimbodiah]

The large H one looked really really nice, I hope that one will make a return with the new texturing.

[RedParadize]

My personal opinion on this is that largest centrifuge are late game, by definition they fall a bit into si-fy. You can go crazy and and have some fun with the design. If you want you could also pick existing si-fy design.

Edit: btw, did you look at Bonus Eventus centrifuge? Quite intresting.

Edited October 25, 2016 by RedParadize

[acolangelo]

The recent builds have dropped certain textures (examples: blue tank with white intertank, all white cylindrical engine shroud). Are those some of the textures you were referring to with the “Other texture sets are temporarily unavailable until they can be reworked for the new shaders.” comment in the 0.5.33.126 release notes?

Inflatables are looking amazing! Great work. I would love the capless inflatable option, as long as supporting them wouldn’t add significant development overhead. I always support your decisions to take the path that leads to less overhead.

[Shadowmage]

Textures are very much WIP, but they are already looking fairly nice in game.

 

[Jimbodiah]

+1 for textures

-1 stock docking ports  

[tater]

The docking ports got me thinking. I have tended to just used the SSTU ports all the time now, even if it means unwanted parachutes. Could that be an option, or does the parachute module need to always be there?

[Jimbodiah]

If you don't use it, what does it matter?

[JoseEduardo]

AFAIK you can remove it from the .cfg file

[tater]

My thought would be a mass adjustment based on it being selected or unselected.

The small SSTU is 0.02 (same as clamp-o-tron jr, but small chutes are 0.1), and the larger one has a mass of 0.5---large stock chutes are 0.3, and the clamp-o-tron is 0.05.

So the small one is a huge bonus, actually (with chute the mass should be closer to 0.12), and the larger SSTU port is heavy @ 0.5 vs 0.35.

So if it was possible to toggle the existence of chutes, I'd set no chute version masses as 0.02 and 0.05, and the chute versions as 0.12 and 0.35 respectively.

 

That or dump the chutes from them and set the masses to the same as stock docking ports.

[Jimbodiah]

0.15 tons, that's negligable for dV. I actually stack a port on top of the LCs to get chutes back on my lander. Weight is a non-issue imho.

[tater]

I largely play upscaled to 6.4X, so mass makes more of a difference. Besides, it just makes sense for them to make sense.

Sorta like the new, stock relay antennas. The biggest one is 600kg. A similar sized antenna in RL, plus the low gain and all radio gear masses 100 kg (Voyager). The whole spacecraft is 800kg, with rigs, propellants, all instruments... the 500kg makes no difference in stock, I admit... but I still think I'll rebalance all of them in their cfg files.

[Jimbodiah]

Myeah, stock weights aren't really based on real world values but to balance game play. The dishes are not balanced as they are unusable on small satellites (200kg for the satellite with ion drive, then add a 600kg dish). @akron had the same values on his dishes, but recently balanced them out a bit on his Probes+ mod. It has really nice antennas and other satellite parts, check it out, it compliments SSTU nicely.

[Shadowmage]

13 hours ago, acolangelo said:

The recent builds have dropped certain textures (examples: blue tank with white intertank, all white cylindrical engine shroud). Are those some of the textures you were referring to with the “Other texture sets are temporarily unavailable until they can be reworked for the new shaders.” comment in the 0.5.33.126 release notes?

Yes, that is pretty much what that bit in the patch notes was about.  Sounds like they will be returning in the (near?) future through one of Jose's expansion packs.  No real ETA, but I don't think it is too far out.

 

10 hours ago, tater said:

My thought would be a mass adjustment based on it being selected or unselected.

The small SSTU is 0.02 (same as clamp-o-tron jr, but small chutes are 0.1), and the larger one has a mass of 0.5---large stock chutes are 0.3, and the clamp-o-tron is 0.05.

So the small one is a huge bonus, actually (with chute the mass should be closer to 0.12), and the larger SSTU port is heavy @ 0.5 vs 0.35.

So if it was possible to toggle the existence of chutes, I'd set no chute version masses as 0.02 and 0.05, and the chute versions as 0.12 and 0.35 respectively.

 

That or dump the chutes from them and set the masses to the same as stock docking ports.

'Finishing' the modular-parachute module has been on the long-standing TODO list (for at least 6 months now).  Originally I was awaiting updated GUI stuff that was supposed to come with Unity 5+, sadly that turned out to be a royal PITA to implement and use.  It was intended that it could be enabled/disabled, and have the #, types, and sizes of chutes adjusted (toggle drogues and mains, adjust size of drogue and mains independently, select what textures and models were used).

Could be done.  However it is not high on my priority list as nothing is exactly 'broken'.  One of those 'not enough time' things.

 

 

11 hours ago, Jimbodiah said:

+1 for textures

-1 stock docking ports  

Yea, haven't gotten the time to add the radial attach geometry to the SSTU docking ports yet... another one of those things on the TODO list (yes, it is a very large list...and growing constantly).  Hopefully this one will be making it into the next release; it has been awaiting an updated/simplified generic ModelSwitch module to toggle the attach point mesh (will probably just be a rescaled fuel tank model w/ gray texture).

 

 

 

[Jimbodiah]

Your ports attach radially, I use them regularly.

[Shadowmage]

2 minutes ago, Jimbodiah said:

Your ports attach radially, I use them regularly.

Yes, they do... but they have a gap on them when used against a round tank.  They need some sort of protrusion on the rear like the stock ports have (which will be a toggled mesh through a ModelSwitch setup, once I can finally get to it).

[Jimbodiah]

Ah, I get what you mean now.

[JoseEduardo]

there's the stock radial attachment point.... it's 1.25m wide, so it fits your DP

[Temeter]

Btw, Shadowmage, if you didn't already now: There is a bug with the (window-) lighting of the capsules (craft and lander). Appears normally when you press the light button, but as soon as you mouse over and the part highlighting appears, the windows go (and stay) dark again.

Edited October 26, 2016 by Temeter

[Jimbodiah]

Mage, is it okay if I do a PR to add a radiator module (no models, just functionality) to the DOS parts, equivalent to four small panels? All but the A version have radiators on the outside, would be cool to have them be functional. I have it running in my own SSTU patch file now, but don't know if you have custom functionality planned for this.

And what Temeter said, inside lights turn off when you switch to other craft or go out of focus. This is 1.2 related as other mods had similar issues with lighting. I know Nertea fixed it, maybe check with him what was wrong.

Edited October 26, 2016 by Jimbodiah

[Shadowmage]

11 minutes ago, Temeter said:

Btw, Shadowmage, if you didn't already now: There is a bug with the (window-) lighting of the capsules (craft and lander). Appears normally when you press the light button, but as soon as you mouse over and the part highlighting appears, the windows go (and stay) dark again.

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.

 

2 minutes ago, Jimbodiah said:

Mage, is it okay if I do a PR to add a radiator module to the DOS parts, equivalent to four small panels? All but the A version have radiators on the outside, would be cool to have them be functional. I have it running in my own SSTU patch file now, but don't know if you have custom functionality planned for this.

I have never used a radiator aside from for aesthetic purposes.  Do they actually serve a purpose (radiators in general in KSP)?  Are the DOS parts overheating for some reason?

Nothing against it per-se, but I don't see a use for it either.  Thermals have never been a problem for me except for during re-entry (where they are not a problem either, fully expected and merely need to be accounted for).

As long as it is just Modules and won't require any changes to the models or cause any other problems with the parts, then sure, go for it.  Hopefully it doesn't add yet-more-lines to the right click-menu either.

[Jimbodiah]

It's mainly when you start using small reactors like from NearFuture or USI, or even an ISRU or some KSPI receivers. And yeah, it adds two lines; an activate button and a cooling % status, so I'll keep it in my own mm patch file for now  

[Pappystein]

6 hours ago, Shadowmage said:

'Finishing' the modular-parachute module has been on the long-standing TODO list (for at least 6 months now).  Originally I was awaiting updated GUI stuff that was supposed to come with Unity 5+, sadly that turned out to be a royal PITA to implement and use.  It was intended that it could be enabled/disabled, and have the #, types, and sizes of chutes adjusted (toggle drogues and mains, adjust size of drogue and mains independently, select what textures and models were used).

 

 

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

 

Edited October 26, 2016 by Pappystein