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

[Shadowmage]

On 1/29/2018 at 12:39 PM, chrisl said:

Have you ever considered adding a slider or something that would allow a fuel tank to have it's center of mass adjusted?

Briefly, on-and-off.  Generally it runs afoul of the ability to exploit it.  In order to prevent exploits a very complex system would have to be put into place to limit the min/max offset for the COM based on the current fuel type(s) selected and the current tank geometries.  Which is really only viable for simple fuel setups, and breaks entirely when using the tanks for complex resource sets.

Certainly it would be doable -- but it is far easier to just use two separate tanks when you need a specific COM.  IOW its not worth it for a part count reduction of 1 (as the largest use of this ability would be for shuttle-alikes, which generally only need one fuel tank).

 

On 1/31/2018 at 6:11 PM, Starwaster said:

It does duplicate those buttons.

Hmm.. probably not a good option for the default configuration then.  Those parts are busy enough without adding duplicate unnecessary buttons to them.  Might be something that could be added to an optional patch set.

Really though -- I'm fine with the status quo.   I didn't really have any problems with it in my most recent playthrough -- but of course, I'm one of those players who has MJ do node burns for me, so loss of direct control only really impacts docking attempts (and yes, I did have to wait 1/4 an orbit during a RV on the back side of the Mun in order to regain control before docking due to loss of connection; next launch was some very high Kerbin relay sats, and had no further problems).

 

 

General development update:

Not much recently.  Between work, real life, and more work, my dev time has been close to zero the past few weeks.

Have started working on the iterative portion of the ModularPart rewrite.  The initial development has been 'done' for awhile, and now it is onto the not-so-fun 'launch-KSP, test thing, close KSP, fix thing, re-launch KSP' cycle; which is also a big portion of why development has slowed down (most of the time that I can devote to development is when I don't actually have access to KSP, and have to code things 'in the blind' as it were).  So at this point I probably have a couple weeks worth of cleanup to do on the existing code (read:  probably only 5-10 solid hours of work, but it will take me at least a couple weeks to find that much free dev time), before I can go on to actually 'finish' things.

If/when it is finished though, is shaping up to be a fairly major overhaul to the fuel tanks (and most other modular parts).  Standard cylinder fuel tanks will be getting all new models + textures to go along with the new module (much higher texture resolution as well; from ~64px/m to ~128px/m).  Have recently rethought how the tank meshes and textures will be put together, resulting in better use of the UV space and more 'modular' appearing textures (which means better looking tank models when multiple sub-models are combined).  The new texture layout will also allow for seamless 'paneled' textures like those on the COS parts (which will be one of the new options when all is said and done).

[Starwaster]

41 minutes ago, Shadowmage said:

General development update:

Not much recently.  Between work, real life, and more work, my dev time has been close to zero the past few weeks.

Have started working on the iterative portion of the ModularPart rewrite.  The initial development has been 'done' for awhile, and now it is onto the not-so-fun 'launch-KSP, test thing, close KSP, fix thing, re-launch KSP' cycle; which is also a big portion of why development has slowed down (most of the time that I can devote to development is when I don't actually have access to KSP, and have to code things 'in the blind' as it were).  So at this point I probably have a couple weeks worth of cleanup to do on the existing code (read:  probably only 5-10 solid hours of work, but it will take me at least a couple weeks to find that much free dev time), before I can go on to actually 'finish' things.

If/when it is finished though, is shaping up to be a fairly major overhaul to the fuel tanks (and most other modular parts).  Standard cylinder fuel tanks will be getting all new models + textures to go along with the new module (much higher texture resolution as well; from ~64px/m to ~128px/m).  Have recently rethought how the tank meshes and textures will be put together, resulting in better use of the UV space and more 'modular' appearing textures (which means better looking tank models when multiple sub-models are combined).  The new texture layout will also allow for seamless 'paneled' textures like those on the COS parts (which will be one of the new options when all is said and done).

What's the damages going to be as far as craft files and save files? 

[Shadowmage]

11 minutes ago, Starwaster said:

What's the damages going to be as far as craft files and save files? 

Total and complete.  Will not be save compatible.  I would expect nothing to survive across the update.  This has been known for awhile now, and I think I first posted about it >1month back.  Will continue to post occasional reminders, and of course there will be a big disclaimer/warning with the d/l on the new versions when they are available.

New part names (and modules) = none of the old stuff will work.  Also most of the models themselves will be changed.  Big part of why I'm holding off on even testing versions until at least KSP 1.4 is released.  Even the ShipCore series of parts will be receiving a full renaming pass in this update (the A/B/C naming has been bugging me for ~year now; time to finally fix it).

Most/all of the existing parts should still be present in the new version, and will be probably as close to an 'SSTU-2.0' update as will ever be done (I also anticipate that plugin/module development should slow/cease after this update, with future development being focused on filling in the part series + more textures).  So should be very stable after this (hopefully last) breaking update.

[Starwaster]

35 minutes ago, Shadowmage said:

Total and complete.  Will not be save compatible.  I would expect nothing to survive across the update.  This has been known for awhile now, and I think I first posted about it >1month back.  Will continue to post occasional reminders, and of course there will be a big disclaimer/warning with the d/l on the new versions when they are available.

I'm sure you did

But I've only just fairly recently started using SSTU

[tater]

I feel a surge of KSP interest coming on about... Tuesday, lol. Either in the "rockets are AWESOME!" sense, or in the "#kerbalexplosions! sense. Godspeed, Falcon Heavy!

[drhay53]

Luckily I've finally started isolating each install of KSP for a stable save situation, so KSP and SSTU updates will mean nothing to me until I decide to let it

[Starwaster]

18 minutes ago, drhay53 said:

Luckily I've finally started isolating each install of KSP for a stable save situation, so KSP and SSTU updates will mean nothing to me until I decide to let it

I've got 34 KSP installations to choose from dating as far back as KSP 0.23....

(some are duplicates for development purposes of various mod combinations)

[Jimbodiah]

If you use mods, you will never go for a new release as almost no mod will work. Personally I tend to wait a month or two before moving any careers, or just play stock with the new version to check out what has changed. 1.4 sounds like a good point to start a new career

[T-10a]

What would the new naming scheme be for the ships? I.e. for the Soyuz spacecraft, would it be named Series-A (like before), Series-S (converting the Series-A to the naming scheme used by the VA), SOYUZ, some other "fictional" or "Kerbalised" name (like Union or something) or is it something else?

In other news, I've tried converting some mods to become a Gemini-like spacecraft (Like TRAILS or the Corvus spacecraft), but keep getting stuck due to a lack of interest in them and end up working on converting the RealEnginesPack by @Alcentar to SSTU-style engine clusters ._.

[Sudragon]

Request for information. I remember an add on for SSTU that added the ability to put USI materials in SSTU tanks via the config containers menu. Is it still around?

[Jimbodiah]

Which USI mod, maybe I can add a patch to SSTU if it's not already there.

[Shadowmage]

8 hours ago, Sudragon said:

Request for information. I remember an add on for SSTU that added the ability to put USI materials in SSTU tanks via the config containers menu. Is it still around?

They were part of my personal patch set.  Still available on the repository, but be warned that it comes with quite a bit of other 'stuff' (and removes most stock parts) and hasn't been tested recently.

https://github.com/shadowmage45/SSTULabs/tree/master/GameData/SSTU-OptionalPatches

[Sudragon]

9 hours ago, Shadowmage said:

They were part of my personal patch set.  Still available on the repository, but be warned that it comes with quite a bit of other 'stuff' (and removes most stock parts) and hasn't been tested recently.

https://github.com/shadowmage45/SSTULabs/tree/master/GameData/SSTU-OptionalPatches

Thanks. downloaded it and took out the bits i didn't need. Thanks.

 

[Shadowmage]

Had a few moments of the weekend (and late Friday) to work on cleaning up some of the past dev-work on the SSTUModularPart module.  It actually works now, and properly loads and positions the main models in the part (nose/upper/core/lower/mount).  It properly validates the current model variant(s) and their allowed model combinations, and positions and scales the models properly for their chosen slot (e.g. a nosecone on top of a 2-1 adapter gets scaled to line up with the adapter).  Overall this will allow for a much wider selection of model variations, especially if/when more non-standard models are added (e.g. truncated cones for N-1 type fuel tanks)

Next up is working on the 'layout' support for RCS and solar panel options.  Not only will the user be able to select the specific model for RCS/solar, but they'll also be able to select the 'layout' for each -- 2x, 3x, 4x, etc.  And the fun bit is that the layouts can be specified on a per-model basis.  So within a single part you might have a specific solar panel that has 2x and 4x options, another with 2x and 3x, and yet another that only supports 4x (same with RCS, with separate selections for upper and lower RCS).  Currently working on developing the best way to specify this information in the part config, as well as how to load the data into the part/model-modules, and ensuring that only valid layouts can be used for any specific model (e.g. if the solar model is changed, but the current layout is invalid, select a valid layout for that solar model).

Alongside the 'layout' work will also be the 'module-slot-parent-module' support -- this will be a bit of code that links the RCS and solar modules to other specific modules in the part -- e.g. the solar module could be parented to either the upper, core, or lower, with a UI slider to choose what its parent slot is (same for RCS).  The allowable slots themselves can be configured in the overall part config, but are global for a part and not model-specific (e.g. if one solar panel option is allowed upper/core/lower as valid parents, the same is applied to all other solar options in a part)  (has to be some limits to the configurability, or else I'll never finish writing the code...).  While the solar/rcs parts will pull their scale data from the current CORE scale, their positioning will scale based on what model-slot they are parented to -- this is to ensure that they are properly 'mounted' to whatever model is in that slot.

If I can keep poking away at it, I should likely have the plugin code side of things finished up in a week or two.  Have been able to make pretty good progress whenever I've had a few free minutes, so hopefully that will keep up.  Still going to have a few days/weeks of config fixing/rewriting after that, along with another week or three worth of updating of tank models and textures.  Might start working towards test releases once I get to the updating-of-models stage; would like to get at least a couple weeks worth of testing done on the updated plugin code and it seems like it would line up well to coincide with the timing of the tank model reworking.

[tater]

@Shadowmage

Clearly SpaceX is using Textures Unlimited.

Edited February 7, 2018 by tater

[Nittany Tiger]

Not sure if I missed this on the original post, but it would be nice if there was a direct link on the OP to the latest version that is compatible with 1.2.2 for us RSS/RO folks that want to use SSTU.  Could keep doing this is as RSS/RO updates since it tends to lag a version behind KSP.

I did find what I think is the best 1.2.2 version of SSTU on GitHub (0.5.34.134), but not totally sure it is.

[Theysen]

12 minutes ago, Nittany Tiger said:

Not sure if I missed this on the original post, but it would be nice if there was a direct link on the OP to the latest version that is compatible with 1.2.2 for us RSS/RO folks that want to use SSTU.  Could keep doing this is as RSS/RO updates since it tends to lag a version behind KSP.

I did find what I think is the best 1.2.2 version of SSTU on GitHub (0.5.34.134), but not totally sure it is.

I linked a big „USE THIS VERSION“ in the Realism Overhaul thread. It hurts that you read this OP but not the RO OP. 

 

[Shadowmage]

1 hour ago, Nittany Tiger said:

for us RSS/RO folks

From the OP --

Quote

RO/RSS - Unsupported.  Take any support requests regarding RO to the RO threads.

 

Seriously, I don't support or endorse the use of RO.  You are entirely on your own with any problems you may encounter.

[Nittany Tiger]

1 hour ago, Theysen said:

I linked a big „USE THIS VERSION“ in the Realism Overhaul thread. It hurts that you read this OP but not the RO OP. 

 

My bad.  Sometimes, we make mistakes, and I forgot to check the RO thread for the correct version.

4 minutes ago, Shadowmage said:

From the OP --

 

Seriously, I don't support or endorse the use of RO.  You are entirely on your own with any problems you may encounter.

No worries.  The version I downloaded works for RO as far as I know.  If it doesn't, I know how to write config files to make it work (or I'll do my best to try to make it work).

Edited February 7, 2018 by Nittany Tiger

[Shadowmage]

17 hours ago, tater said:

Clearly SpaceX is using Textures Unlimited.

No doubt.  Just look at that blue glow / backlighting from reflections.  Pure awesome.  Now just need to find who did their modeling and textures... and have SQUAD hire them

[Shadowmage]

Well, we now have a release date for KSP 1.4 (or at least the expansion?).  Sadly I haven't heard anything about a pre-release / public testing phase.  So chances are it will take at least a few weeks after 1.4 is released in order for mods to get updated.  Even more-so for my mods, as I have to wait for all of their dependencies to update (CRP, MM, etc).

But aside from that, things are still progressing nicely in the development front.  Some work has been done this week to get the model layout support working, and should likely have that bit finished up by the end of the weekend.  From there not much is left for code-side development on the modular-part plugin.  Need to add support/finish implementing the 'model-slot-parent' feature for the solar/rcs module slots, and from there it is just going to be bugfixing/cleanup/refinement.  And of course lots of config work, and a fair bit of work on tank models+textures.  Shouldn't be any problem to get it all done in time, but I'm certainly going to have to keep on top of it all.

 

 

[drhay53]

11 hours ago, Shadowmage said:

Well, we now have a release date for KSP 1.4 (or at least the expansion?).  Sadly I haven't heard anything about a pre-release / public testing phase.  So chances are it will take at least a few weeks after 1.4 is released in order for mods to get updated.  Even more-so for my mods, as I have to wait for all of their dependencies to update (CRP, MM, etc).

But aside from that, things are still progressing nicely in the development front.  Some work has been done this week to get the model layout support working, and should likely have that bit finished up by the end of the weekend.  From there not much is left for code-side development on the modular-part plugin.  Need to add support/finish implementing the 'model-slot-parent' feature for the solar/rcs module slots, and from there it is just going to be bugfixing/cleanup/refinement.  And of course lots of config work, and a fair bit of work on tank models+textures.  Shouldn't be any problem to get it all done in time, but I'm certainly going to have to keep on top of it all.

 

 

I forget which thread I saw it in, but I definitely saw Squad staff confirm that the expansion requires 1.4. So it's safe to assume it will come out before/with the expansion.

[SiriusRocketry]

Is this a high-lag or high part count mod? How many parts does it have and can it run on potato laptops?

[T-10a]

It's the opposite- It's designed to kill part counts on ships to enable (somewhat) more grandiose adventures on weaker computers.

Also, how do you balance part costs and mass Shadowmage? I've been working on my own small collection of parts and I want to see how you've balanced them out so I can easily slip new parts in balance-wise.

Edited February 11, 2018 by T-10a

[falken]

Finally got back into KSP after a very, VERY long hiatus and as always, SSTU is the first to get chucked in.

Can anyone help me with adding the engine cluster code to other engines?