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

[Starwaster]

27 minutes ago, tater said:

Yeah, I_sp is certainly one with an actual trade-off as long as boiloff is there. I do much the same, but my common gripe about "career" mode has always been that it doesn't do what it really needs to do, which is to provide a context that informs design choices.

In a (entirely notional) "space race" form of play, with some nonzero chance of failures, for example, you'd have all kinds of forces on you in terms of design decisions. Use a less reliable engine with better efficiency (and hence perhaps more margin), or more reliable type with lower I_sp. Life support also functions as a consideration when you play with that, as well.

 

 

Yeah lifesupport is a must since it forces you to play for logistics

[Qwarkk]

How up to date are the patch files for TAC lifesupport? They add life support resources to the crew pods and service modules with a simple patch along the lines of:

Spoiler

@PART[SSTU-SC-C-SM]:FOR[SSTU]:NEEDS[TacLifeSupport]
{
    RESOURCE
    {
        name = Food
        amount = 1.097                                           // 3 days for 1 kerbal
        maxAmount = 1.097
        @amount *= #$@PART[SSTU-SC-C-CM]/CrewCapacity$
        @maxAmount *= #$@PART[SSTU-SC-C-CM]/CrewCapacity$
        @amount *= 3                                             // blocks of 3 days of supplies
        @maxAmount *= 3
    }

However, resources in these parts are generally handled with the SSTUVolumeContainer module which works in a different way. As a result, the in-game part descriptions recognize the part should contain life support resources, but the parts will launch with no life support resources onboard. For the record, im playing on a 1.5.1 install with compatible versions of both mods.

[Shadowmage]

1 minute ago, Qwarkk said:

How up to date are the patch files for TAC lifesupport?

Like... not at all   

You are correct in both the current situation, and the explanation of the problem.  The TAC patches have not been updated to reflect the fact that nearly all parts use the SSTUVolumeContainer setup now.  I believe some similar issues exist with the USI-LS patches....   shows how often I've been able to actually play recently...

If you would like to open an issue ticket on the SSTU repository, I'll take a look about updating those patches for the next release.  With the new systems in SSTU, I can probably come up with a 'blanket' patch to target all life-support-bearing parts to include a specific number of crew-days worth of supplies.

[Qwarkk]

1 hour ago, Shadowmage said:

If you would like to open an issue ticket on the SSTU repository, I'll take a look about updating those patches for the next release.

Done  

[StickyScissors]

Oh look, ive gravitated back to this game again. Time to spend a billion hours getting an install built and stable, just for 1.7 to jump out and ruin it right as i start a playthrough :v

Edited February 6, 2019 by StickyScissors

[Shadowmage]

11 hours ago, StickyScissors said:

Oh look, ive gravitated back to this game again. Time to spend a billion hours getting an install built and stable, just for 1.7 to jump out and ruin it right as i start a playthrough :v

I know the pain (from the dev perspective).  Just get things wrapped up and ready for use?  Another release drops.  In the middle of a huge project that won't be ready for a few weeks/months?  Of course, another release is posted.

Thankfully, and I have to give them the credit where it is due, SQUAD has been very good about not breaking mods in the recent release (1.4+).  Pretty sure all the mods I had compiled for 1.4 would still work on 1.6 (and likely 1.7).

 

Still... I totally understand the frustration

 

[RaiderMan]

Why else do you think I stayed on 1.3.1 for the longest time? Cause it's a complete hassle to get an install built and stable with mods. Path of least resistance.

[StickyScissors]

Yeah same, when i finally decided to move to a new version the game was broken, critical mod functions broke and never got properly fixed, and i was fed up with the hassle

[Shadowmage]

I've been a bit absent of late, due to, well... life... and all the fun that it entails (mostly work...).  But I haven't forgotten about KSP, nor do I intend on retiring from modding any time soon; I think that KSP still has a bit of life left in it, and several interesting venues still exist that I intend to explore.

The good news is that I've managed to squeeze in a few hours of productive modding time over the past few weeks, concentrating on cleaning up the open tickets on the SSTU repository.  Very productive time   Most of the currently reported outstanding issues have been fixed in the dev code, and I believe I'll be able to get a few more done within the next few days.  Also should mention that all of these fixes are available in the dev branch on the repo now if anyone is so inclined to grab them from there.

Current 'plans' are to continue with the bug cleanup pass this week (time permitting), and take a few more hours over the weekend to recompile/pack/publish an official KSP 1.6.x compatible version of SSTU (at least so far as it can be with TU still being a bit out of date).  At this point there really aren't any enhancements or new features in store for the release -- just a big long list of bugfixes.

[Zophos]

Are the releases backwards-compatible to earlier versions of KSP?  In particular, if I want to add SSTU to a new 1.3.1 install (for RO/RP-1), can I use the latest build, or do I need the last one before it was updated past 1.3.1 (looks like 0.7.39.149)?

Apologies in advance if I failed to turn up an answer already given elsewhere in the thread.  I looked but did not find.

[Shadowmage]

4 hours ago, Zophos said:

Are the releases backwards-compatible to earlier versions of KSP?

The last few versions - yes, or at least it is possible. (1.4, 1.5, 1.6)

Further back than that... I cannot say for certain, but it is likely that it will not work due to changes in the KSP code that SSTUs custom DLLs are compiled against (method signature changes at least; some changes to resource handling).

For example, the Stock-Dv meter.  Required changes to the SSTU code to play nicely with it, as there were new resource-lists that needed to be manipulated when changing resources.  That stock code (the resource lists) does not exist in earlier KSP versions; so I guess the furthest back the current releases will be compatible with would be the first stock release that had the Dv meter.

^^^ So there is your answer.  No.  Current releases of the mod will only work on current versions of KSP.  Stock has changed their code, SSTU had to change to still be compatible, and those two changes entirely break any potential for backwards compatibility.

TLDR:  If you want KSP 1.3, you need to use the mods intended for that version.  You can find a compatible SSTU release here ->   https://github.com/shadowmage45/SSTULabs/releases/tag/0.7.39.149    But keep in mind I offer no support for legacy releases.

[Zophos]

3 hours ago, Shadowmage said:

TLDR:  If you want KSP 1.3, you need to use the mods intended for that version.  You can find a compatible SSTU release here ->   https://github.com/shadowmage45/SSTULabs/releases/tag/0.7.39.149    But keep in mind I offer no support for legacy releases.

I understand, and had no expectation that older releases would receive support.  Putting together an RP-1 install is an adventure in that respect already.

Thanks for the answer.

[wartime]

Is there any possibility to knew how much power will produce sstu solar panel, except launching vessel with it?

[Shadowmage]

22 minutes ago, wartime said:

Is there any possibility to knew how much power will produce sstu solar panel, except launching vessel with it?

Not from in-game that I'm aware of.  Probably should be added to the part descriptions at some point.

Even looking in the part config might not help much, as those configs merely link to a model definition.  The model definition, however, does state the EC output for the panels; but it is not 'simple' to find those files, esp. for something that should be visible in-game.

[Shadowmage]

Updated release is available:

https://github.com/shadowmage45/SSTULabs/releases/tag/0.10.45.157

Tons of fixes, but otherwise nothing new.  Recompiled for KSP 1.6, updated all bundled dependencies.  See the above link for full change log and downloads.

[Shadowmage]

While going through some of my old assets, I ran across some of my first 'Base Core' concepts, which also happened to be some of the first modeling work I did (perhaps even the very first stuff I worked on?).  I don't think any of it has ever been shown before, and certainly nothing was ever published as far as usable parts go.  I think I did have some part configs written up, and the parts were generally usable, but ran into issues with lacking terrain that was flat enough to built out a base comprised of the modules. 

There were 5m/10m/20m domes for various functions -- hab, lab, storage, factory/processing/production.  Though I think I only got the storage and perhaps ag domes had any real work done on them before I shelved the concept.  Last change date on these is... 05-12-2015 

This is the '10m storage dome' concept, in its nearly finished state (props/textures/etc) --

10m 'ag' dome (far earlier in the dev stage)

And the set of 'tubes' to connect the various domes together --

Anyway.... the reason that I'm showing these is that I've recently run into the lack of any sort of base-related parts when I was trying to put together a mission profile to use for regular testing and screenshot/promotional purposes.  Got a few of the craft built out, got to the 'design the surface base' stage, and got immediately stuck on the abysmal selection of stock/SSTU parts that are intended for surface bases.

I do believe a concept such as these could be made to work and be quite usable with the addition of some sort of support mechanisms for the modules that allowed for height-adjustment and use on varied terrains.  Likely in the form of multiple animated (but rigid) support struts that extend from the modules and include some sort of self-leveling function, with height adjustment.  While the BaseCore development might still be quite a ways out, its not too early to start discussion of potential options and figuring out design requirements, especially when those requirements involve solving problems such as 'how to deal with lack of flat terrain'....

[tater]

1 hour ago, Shadowmage said:

I do believe a concept such as these could be made to work and be quite usable with the addition of some sort of support mechanisms for the modules that allowed for height-adjustment and use on varied terrains.  Likely in the form of multiple animated (but rigid) support struts that extend from the modules and include some sort of self-leveling function, with height adjustment.  While the BaseCore development might still be quite a ways out, its not too early to start discussion of potential options and figuring out design requirements, especially when those requirements involve solving problems such as 'how to deal with lack of flat terrain'....

A few things leap to mind. The mechanics of KSP mean that you either have parts that can move and possibly adjust height (and independently on each side to level), or you need something like KIS/KAS to have your astronauts assemble them. That, or you have something where they get constructed in-situ (you design them, then get to place them on the surface where you have a cargo pod that contains them, then you pop them down complete). Sorta like EPL.

I tend to like the idea of structures buried in regolith from a realism standpoint (even if just roleplaying), but the nice thing about the models you show above is that a buried option seems totally possible as a right-click option (greenhouses need the sun, after all).

The usual KSP mechanic in other mods is wheels added. If you are not wanting to use KAS, perhaps the parts could have a very limited self-locomotion, even without wheels? This would be an abstraction of them being constructed. Maybe it could require certain other parts (including kerbals) to be within some range. Imagine the base of one of those parts with a sort of pneumatic bellows that auto-levels the part (maxed out at some number of cm max extension). Would it also be possible to treat them like wheels, with some super slow max speed? Land dome pod. Deploy to dome, then it moves painfully slowly to contact with other parts nearby, and docks?

At higher tech node, I also like the idea of 3D printed habs (like the MASHA concept, among others). The nice thing here, is that you can have the parts be the printer (with different radii), and the printer can then build a hab wherever you place it. If they are small enough, level is not a huge problem (they could print as self-leveled), and connecting 2 spaces might be a flexible tube, so no concerns about perfect alignment. The printer can use "rocket parts," or it could use some other resource that makes use of ISRU (or ideally requires some of each).

 

 

[SpaceX]

I just wanted to take a moment to say THANK YOU for everything you do. This mod is such a must-have for me...it does so many great things. I just can't express that enough...so thank you. 

That is all

 

- OzzyInSpace

[tater]

2 hours ago, SpaceX said:

I just wanted to take a moment to say THANK YOU for everything you do. This mod is such a must-have for me...it does so many great things. I just can't express that enough...so thank you. 

That is all

 

- OzzyInSpace

QFT

[Nightside]

7 hours ago, Shadowmage said:

[...pics...]

Anyway.... the reason that I'm showing these is that I've recently run into the lack of any sort of base-related parts when I was trying to put together a mission profile to use for regular testing and screenshot/promotional purposes.  Got a few of the craft built out, got to the 'design the surface base' stage, and got immediately stuck on the abysmal selection of stock/SSTU parts that are intended for surface bases.

I do believe a concept such as these could be made to work and be quite usable with the addition of some sort of support mechanisms for the modules that allowed for height-adjustment and use on varied terrains.  Likely in the form of multiple animated (but rigid) support struts that extend from the modules and include some sort of self-leveling function, with height adjustment.  While the BaseCore development might still be quite a ways out, its not too early to start discussion of potential options and figuring out design requirements, especially when those requirements involve solving problems such as 'how to deal with lack of flat terrain'....

Awesome. Those look great. I'd be interested in using those as Kerbal Konstructs statics. In fact I think I remember something about Angel125 working on a way to have crafts build Statics in his Pathfinder mod, instead of trying to rely on large buildings that are actually crafts to not start sliding or bouncing around. Unless you've worked out a real KSP miracle with your KSP Wheel work, I don't think crafts can be trusted to load and unload without blowing itself up, especially a massive dome sized structure. 

[Jimbodiah]

21 hours ago, SpaceX said:

I just wanted to take a moment to say THANK YOU for everything you do. This mod is such a must-have for me...it does so many great things. I just can't express that enough...so thank you. 

That is all

 

- OzzyInSpace

OMG!  It's Elon!

[tater]

I finally got around to installing 1.6.1. SSTU works, but the textures are gray/white, etc. Odd. Install looks good, but The only way to install now on Mac without having to open the package contents is to use the Installer, so I just did that, then added Making History and SSTU (figured I might as well put MH back in since I paid for it).

I'll up the log on github.

[Shadowmage]

13 hours ago, tater said:

I finally got around to installing 1.6.1. SSTU works, but the textures are gray/white, etc. Odd. Install looks good, but The only way to install now on Mac without having to open the package contents is to use the Installer, so I just did that, then added Making History and SSTU (figured I might as well put MH back in since I paid for it).

I'll up the log on github.

Thanks for the report, will definitely take a look and see what I can see.

In the meantime, you might try updating TexturesUnlimited from the releases on the Repo ( https://github.com/shadowmage45/TexturesUnlimited/releases/tag/1.3.5.19 ).  Apparently the one that I bundled with the last SSTU release was missing some shader targets (notably, OpenGL on Windows; should have still been present for OSX though).

Will let you know what my investigations reveal...

[tater]

Latest TU release fixes the issue.

 

[Shadowmage]

1 hour ago, tater said:

Latest TU release fixes the issue.

 

Thanks for the confirmation, and glad it is working for you now/again.  I'll try and get a repack done tonight that fixes the published release up (likely a new version#).