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

[tater]

The SC-C-CMX cfg has:

INTERNAL
{
	name = SC-B-CM-IVA
}

 

[Shadowmage]

On Sunday, September 11, 2016 at 3:33 PM, RedParadize said:

I don't build much station. But the solar panel structure seem like a good application for WDP. If I may ask, I would be pleased to see some pics of your construction operation.

@Shadowmage There is a tipo in the SC-C-CMX config:

INTERNAL
{
    name = SC-B-CM-IVA // should be SC-C-CM-IVA
}

 

 

On Sunday, September 11, 2016 at 4:05 PM, Shadowmage said:

Thanks, noted and fixed

 

8 minutes ago, tater said:

The SC-C-CMX cfg has:

INTERNAL
{
	name = SC-B-CM-IVA
}

 

 

[tater]

I missed @RedParadize's report and your answer, lol. I was worried it related to welding, and retested.

Edited September 13, 2016 by tater

[Shadowmage]

On Monday, September 12, 2016 at 9:09 AM, tater said:

I'm thinking we need a Be-4 engine...

Could use it for Vulcan... or other things:

 

Indeed it is already on the engine stats list.  Very little information is available on it however (or was last I searched, ~8 mo ago).  Need at least a couple of good diagrams and a solid list of stats for it.

 

14 hours ago, StickyScissors said:

@Shadowmage Would it be easy to add a toggleable cylinder to the bottom of docking ports, to remove the need of using structural fuselages to move them away from tanks?

Radially mounting them now creates the problem of having them sunk in too far to look good an be usable, or they are far enough out to be usable, but the majority of it isn't touching the tank.

[...]

Yea, I've been contemplating how to solve that now that station parts are a thing -- there is more use to docking ports than just on the nose/tail of a ship.

I'll look into using the SSTUModelSwitch for it (the same that controls the LC-POD fuel tanks).  Seems like it should work for the purpose, I just need to make sure I didn't hard-link it to any of the VolumeContainer stuff (don' think I did... but can't remember, been awhile since I messed with that module).

 

11 hours ago, tater said:

I was messing with a CSM to build a station, and decided to take it home after a while, though I left the crew in the station (I had a couple CSMs docked at that point, and needed the docking port). So I separated the SM. The empty CM was doing fine, and since it was sandbox, and I didn't care, I switched to the SM to watch it blow up. A very small 2.5m MFT A tank, and I used 2 of the new SM solar panels on it (like those Apollo Block V images up the thread, but with your cool new panels). Anyway, the panels were extended, and they survived reentry.

 

EDIT: OK, I welded a few things. So far, so good, they stuck together.

 

Thanks for the help in testing the welding port.  I haven't gotten much of a chance to play with it as I've been too busy doing dev work on other stuff, but wanted to at least make sure it was working before I did too much work on the modeling/texturing end of it.

Solar panels -- assuming you are talking about stand-alone solar panels?  Might be some thermal stats I need to setup/change on those, or something drag-cube related (stock unfortunately uses drag cubes for more than just drag =\).  Will put it on the list of things to investigate.

(Which, if anyone was ever wondering, can be found here: https://github.com/shadowmage45/SSTULabs/issues/203 -- I try to keep that issue mostly up-to-date with the smaller enhancements and bug-fixes, things that don't need their own ticket)

[tater]

2 minutes ago, Shadowmage said:

I
Solar panels -- assuming you are talking about stand-alone solar panels?  Might be some thermal stats I need to setup/change on those, or something drag-cube related (stock unfortunately uses drag cubes for more than just drag =\).  Will put it on the list of things to investigate.

(Which, if anyone was ever wondering, can be found here: https://github.com/shadowmage45/SSTULabs/issues/203 -- I try to keep that issue mostly up-to-date with the smaller enhancements and bug-fixes, things that don't need their own ticket)

Yeah, this was the DSP-SMA-S I think.

[Shadowmage]

Point of discussion regarding the MFT fuel tanks --

I've recently considered adding a method for sub-variant handling in the MFT tanks.  More importantly for the cylinder tanks.  Do we really need 4+ parts for cylinder fuel tanks? (MFT-A/B/C/CF/K).  I don't think so.

As a solution I would propose to roll them all into the same part in the editor.  One additional GUI slider would be added that would control the 'tank variant'.  So you would first select your tank length, just as it currently is.  After that you could scroll through the options in the 'tank variant' slider that would change between the MFT-A/B/C/CF/K models of the same length.

I'm also wanting to do this for other mod integration, specifically for the Near-Future trusses.  I had started making a patch set for them, but ran into the problem that I would have needed a separate part for each 'style' of truss (solid, hollow, saddle, support, fuel, etc).  With the above proposed 'sub-type' support they could all stay as a single part that merely allowed for swapping of the variants for each length selection.  (Yes, I will likely release some of these mod-integration patches at some point; but I need to finish writing them first, which requires time that I can actually sit down and play).

For reference the exact same functionality can be accomplished right now by merely adding the alternate definitions to the existing tanks.  But then as you pressed the tank length >> button, you would get the next tank style of the same size until no more styles were available, where it would give you the next length (so it would go MFT-A-3, MFT-B-3, MFT-C-3, MFT-A-4, MFT-B-4, etc...).  Basically the proposed change from above would merely clean up the interaction on the tanks a bit and reduce the editor part-list clutter even further.

-IF- I make the change (and I'm really leaning towards 'yes'), it'll likely happen during the transition for the 1.2 update as it has the possibility to be save breaking (okay, WILL be save breaking for anything using the MFT-B or MFT-K; the MFT-A will likely survive).

[tater]

I like that idea a lot. I differentiate between the A and B for hydrolox tanks, basically, but a "variant" would work perfectly well, and I really like the idea of cleaning up the menu. I just DLed 

 

and I'm thinking of hiding most all of the stock parts.

[RedParadize]

1 hour ago, Shadowmage said:

For reference the exact same functionality can be accomplished right now by merely adding the alternate definitions to the existing tanks.  But then as you pressed the tank length >> button, you would get the next tank style of the same size until no more styles were available, where it would give you the next length (so it would go MFT-A-3, MFT-B-3, MFT-C-3, MFT-A-4, MFT-B-4, etc...).  Basically the proposed change from above would merely clean up the interaction on the tanks a bit and reduce the editor part-list clutter even further.

I didn't trough you would revisit your tank.

It would be more convenient to have two slider, one for the style and one for the size, if possible. Scrolling among too many variant can be sometimes painful, on tanks engine+adapter on the same slider is limit too much. It would be good to have them on separated slider as well, it would allow to have a mount on top of a adapter. Would it be possible? It would look a bit like your station part where you chose adapter and docking port separately on both end. It would be good to be able to have mount on top as well.

My slider wish list:

1: top mount (include docking port?)

2: top adapter (include adapter that go larger?)

3: main tank style

4: tank section length

5: tank length adjust

6: bottom adapter (include adapter that go larger?)

7: bottom mount (include docking port?)

Might be a little over engineered, but it would also make them the ultimate fuel tank!

Edited September 13, 2016 by RedParadize

[Shadowmage]

If I reworked the tanks they would have the following controls:

Diameter Selection
Top Adapter Selection
Core Length Selection
Core Style Selection
Bottom Adapter Selection
Vertical Scale (V.Scale)
Top Texture
Core Texture
Bottom Texture
Fairing Controls (interstage node toggle, fairing toggles, fairing texture selection, fairing opacity, fairing sections) (I really want to remove the integrated fairings from the standard tanks; they don't make as much sense as they used to)

So, the only real change compared to the current system would be the addition of the 'Core Style' selection.  It would use the same GUI widgets as the 'tank length' selector, but would switch between the available variants for that length.

No, I will not be adding extra mount/docking port selections to tanks.  The swappable docking ports is a hack at best and I would prefer to only use it where it is -really- needed (at least until such a time as stock code truly supports run-time module switching and it becomes less of a hack).  And any sort of secondary adapters also run into problems of sizing (e.g. 'top-lower' adapter has a top diameter of 1.25, but 'top-upper' has a bottom diameter of 1.875; and now the top of your rocket looks terrible due to mismatching adapters).  -Could- be solvable through code but would be a giant headache compared to the limited functionality it would add (easier to just add a second tank if you really need that many different adapters/sizes on it).

On a separate note -- adapters that go to from small -> large (tank they are mounted on being the 'small' end) -- already doable, but requires creating second SSTU_MODEL definitions for each and every adapter to be used in this manner.  Would also double the number of adapters in the list, which is already quite long.  (This is the reason why they do not currently exist on tanks; I really don't feel like scrolling through 97 adapters to find the one that I want; scrolling through ~20 is already painful enough)

And on the 'Too many adapters for the UI' end of things, I've also been contemplating trying to come up with some sort of adapter/mount selection GUI that could be used for the modular parts... but that is about as far as the idea has gone.  Its an idea / desire, and nothing more.  Suggestions or further ideas on the concept are welcome.  I do feel like this would be a worthwhile addition to the modular parts system, even more-so as additional adapter types are added and that list of adapters grows ever-longer.

[tater]

Given that the engines have "mount" available, do the tanks really need them? Is it merely for stock compatibility? Maybe I'm being dumb here, or it could literally be that I now never use the stock engines. Ever. 

Regarding size-changing adaptors, I find that a common use is linking a command part (say Orion) to a station part to create a large, interplanetary vessel. I have used the petal adapter for this. A Station Core part that is just an adaptable crew passage might be a cool part. To give it multiple use, add in a volume of tankage equal to the difference between a 1.25m passageway and the outside shell volume (assuming it can do this easily). Basically "structural fuselage," but with variant top/bottom diameters. 

Edited September 13, 2016 by tater

[Shadowmage]

1 hour ago, tater said:

Given that the engines have "mount" available, do the tanks really need them? Is it merely for stock compatibility? Maybe I'm being dumb here, or it could literally be that I now never use the stock engines. Ever. 

[...]

Yep, the mounts and fairings exist on the tanks solely for interaction with stock/other mods' parts.

As I no longer really use stock parts (esp.. not the engines), all of this stuff may likely be going away during the 1.2 update.

 

1 hour ago, tater said:

[...]

Regarding size-changing adaptors, I find that a common use is linking a command part (say Orion) to a station part to create a large, interplanetary vessel. I have used the petal adapter for this. A Station Core part that is just an adaptable crew passage might be a cool part. To give it multiple use, add in a volume of tankage equal to the difference between a 1.25m passageway and the outside shell volume (assuming it can do this easily). Basically "structural fuselage," but with variant top/bottom diameters. 

Already doable, you don't even need me for any of that.  Create a new part, add the station-core module, and add the relevant model bits for how you want it setup.  (Or use the MFT module if you don't need docking ports, which would allow for diameter scaling on the part as well)

Will I add something like that?  Maybe.  I don't see the point on it currently, but then again, I haven't been able to sit down and play KSP for nearly a year now.  I get about to the point where I would start doing stations and interplanetary craft, and then run afoul of stock problems (part count, wheels, landing legs) that have prevented me from -effectively- going any further.  I got about 10 hours into 1.05 before I ran into memory limitations crashing my game every few minutes/scene changes (and OPM/Kopernicus had a terrible bug in it too at that time).  I think I managed to play for a total of about ~5 hours since 1.1 has been released; entirely disappointing as finally the memory limit was lifted, only to be replaced with entirely broken wheel/leg physics that made any sort of landers or bases an exercise in futility.

So.. will know more about if I will make any 'crewed structural' parts sometime after 1.2 and I've had a chance to do some actual playtesting.  If I find it is a part that I need for my builds, yes I will include it.  Otherwise you are free to make it yourself with the existing plugins and models.

 

 

Speaking of 1.2 -- sounds like the pre-release is in final testing now and might be available for public testing later this evening.

As I've not done anything substantial as far as bug-fixing goes this week I'll likely move the current/last posted release into the '1.1.3 final' status, and any future releases will be built and intended for 1.2.

Also note it may take me a week or two to get things cleaned back up and working in 1.2.  Also will be having to take some time to work on the wheels stuff (it has been in limbo waiting for a Unity 5.3+ based KSP version, of which 1.2-pre is the first available).

[RedParadize]

Humm. Given how much work you have ahead with 1.2. I say reworking tanks is not something I would put on the top of the list. Specially of you no more have time to play the game. For me the worst case scenario is you rage quitting KSP. I would be willing to sacrifice all future improvement for a long term maintenance of what we already have, if it came to that...

[Jimbodiah]

4 hours ago, tater said:

and I'm thinking of hiding most all of the stock parts.

Check halfway down the page for prefab catagories and (a.o.) sstu patches.

Edited September 13, 2016 by Jimbodiah

[RedParadize]

Damn, I deleted most of stock part!

Thanks @Jimbodiah !

Edited September 13, 2016 by RedParadize

[Shadowmage]

So, initial 1.2 thoughts regarding compatibility -- might not be too many problems after all.  All compile-time code errors have been fixed, and the code is almost ready for testing.  51 of 55 of those errors were merely the API change of part.findAttachNode to part.FindAttachNode.  The other few dealt with resources.  Will be compiling and testing a bit later this evening. Edit: can only do testing if module-manager still works/has a 1.2 dev version available.

First though, I'm going to play around a bit in stock 1.2 and see what all has changed / fixed / currently bugged / etc.

 

Edit2:

Few further thoughts after a bit of poking around --

The new part-upgrade system seems like something that I can use, if it is working like I think it is.  This will allow for tank diameter upgrades or other features to be made tech-dependent much more easily.  Will know more after I get to do some testing.

Comm system -- Seems well integrated and simple enough to use.  I'll likely give it a try on my next career game.  Various new options for transmitters, including a 'no transmit science' flag.  GIves a purpose to the transmitters I was integrating into all the pods.

KerbNet -- Finally the ability to set custom waypoints, no more searching for KSC on the dark side of the map.

Fairing interstage stuff -- erm, I was excited; until I saw how it was implemented.  At first glance it doesn't appear to be anything I can use... don't think I can even support it on my resizable fairings that use the stock fairing module.  Will need to poke at the new modules a bit to see how they work, and look at the models to see how that is all setup as well.

Wheels -- Have not tried out the stock ones yet.  Even if they are fixed it still doesn't help me as the limitations I'm encountering are in Unity (wheel must be rigidbody aligned).  Hopefully the stock landing legs are a bit more stable though.

 

 

Edited September 14, 2016 by Shadowmage

[StickyScissors]

1.2 drops the day i planned to start my serious 1.1 save, wonderful (ノಠ益ಠ)ノ彡┻━┻

Looks like i won't be doing anything until development ceases for good it seems ^{only half-serious..}, Maintaining a 50+ mod install takes juuust long enough to be stable in time for the next big, break-everything update

-

Edit: In other news, i've never had such detailed space stations with such high FPS before, my meager FX-6300 is jumping with joy!

Edited September 14, 2016 by StickyScissors

[tater]

I wonder if the new upgrade functionality could be useful for otherwise very similar engines (Merlins, for example)?

[StickyScissors]

18 hours ago, Shadowmage said:

[...]

And on the 'Too many adapters for the UI' end of things, I've also been contemplating trying to come up with some sort of adapter/mount selection GUI that could be used for the modular parts... but that is about as far as the idea has gone.  Its an idea / desire, and nothing more.  Suggestions or further ideas on the concept are welcome.  I do feel like this would be a worthwhile addition to the modular parts system, even more-so as additional adapter types are added and that list of adapters grows ever-longer.

Would it be possible to open a flag-selection menu clone when you click a button in the menu, and have some thumbnails of the caps with maybe some basic dimensions/stats overlayed on the images? Obviously the code will have to be different, but the flag menu layout is easy enough to navigate.

Edited September 14, 2016 by StickyScissors

[Shadowmage]

So.. last night consisted mostly of de-Module-Manager-dependency'ing the mod. 

I changed my module-config-loading system to no longer rely on a cached list of part configs; each module now stores its config data internally -- a bit wasteful memory-wise (as in a few hundred k / maybe a few m), but will be more reliable in the long run as there is no ambiguity when trying to load a config for a module.  Although, still won't be compatible with the upgrade system unless they merge that data back into whatever is passed into the OnLoad() method (and only if OnLoad() is called in the editor).  Haven't gotten to play around with it yet due to lack of ModuleManager (as I still need it for other purposes).

Haven't figured out how to rework the engine cluster module to not rely on having the part config; seems like there is no real alternative -- I need the config specified values for thrust and thrust multipliers (only this won't work with the upgrade system... what a quandry).  Going to attempt to grab them off of the engine as it is initialized in the editor (before the thrust is updated from the cluster #)... this will hopefully give me the post-upgrade values for thrust which I can then multiply as needed to derive the cluster's thrust value.

Today/tonight will likely consist of more of the same; removing dependencies on ModuleManager and replacing them with temporary workarounds so that I can actually get things to load in game (and THIS is why I do not want hard dependencies on other mods; end up stuck waiting for them to update before you can do anything).  I -think- I can hack the rest of the dependent methods into working through one stock event or another, so should hopefully be able to do actual testing tonight.

The good news is that the things that were not broken by lack of module-manager seemed to still work.  Which.. well.. wasn't really much... but at least some things were not broken

The initial list of 'changes that will break your saves' consists of:
1.) Fuel tank changes.  B+K variants will be removed.
2.) Lander-Pod changes to ModelSwitch.  May potentially lose model-switch data.
3.) SC-E getting VolumeContainer added to fuselage parts.
4.) Potentially some part-name changes for a few things; undetermined exactly which parts yet, but likely at least the ST-HAB parts.

More -will- be added to that list as I work through the changes and KSP API updates.

Will update with more information as it becomes known.

 

 

 

[tater]

I tried to test 1.2 stock last night... and did for a while, but you've ruined me, @Shadowmage. Everything was so... ugly. I can deal with the mk1 pod (particularly the new one Porkjet has shown, though I did not put those in game), but literally every other part is so horrid I could not interest myself in making anything.

[Shadowmage]

11 hours ago, tater said:

I wonder if the new upgrade functionality could be useful for otherwise very similar engines (Merlins, for example)?

Not really, all the PartUpgrade stuff does is change stats in the PartModules -- it doesn't mess with models/meshes/geometry at all.

You might be able to hook into it to affect some model changes as well from mod-code, but I'll need one of the devs' to tell me how all the backend stuff works first (lifecycle stuff).  Already have some questions posted over in the 1.2 modding discussions; we'll see what kind of info turns up.

 

2 hours ago, StickyScissors said:

Would it be possible to open a flag-selection menu clone when you click a button in the menu, and have some thumbnails of the caps with maybe some basic dimensions/stats overlayed on the images? Obviously the code will have to be different, but the flag menu layout is easy enough to navigate.

Pretty much yes, would be something like that.  Probably more of a linear-scrollable list though with the stats off to the side.  Will give it a bit more thought after I have the initial update/port for 1.2 done.

[falken]

It's a good thing I renamed my Kerbal space program directory "KerbalspaceprogramCURRENT" so I can continue on with 1.1.3, as I've got the game exactly the way I want it. All my parts, my ISP and thrust changes etc are intact.

Some of the new porkjet parts are really really ugly, but I'm so spoiled by SSTU. 

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.

On that subject, some screenshots: (click to make big and stuff)

Edited September 14, 2016 by falken

[Duski]

On 10/09/2016 at 2:21 AM, Shadowmage said:

Thanks, and welcome to the forums

Spaceplanes -- thanks for the suggestions.  I'm not personally very interested in doing any spaceplane type parts for KSP due to its inability to handle complex/welded part setups for aero.  The shuttle/SC-E was a bit of an experiment to see if it would work out well... and it failed pretty terribly (should have been a single part, ended up being 10....).  Perhaps in the future if stock ever incorporates FAR type functionality I'll take another look at the spaceplanes and aero end of things.

I wouldn't say It failed pretty terribly, 10 parts is still pretty low. Hope that you keep developing the shuttle. By the way, will you do the Dragon 2 and 1 capsule? This would be absolutely awesome for your mod. I know there are other ones out there like the LazTek SpaceX pack, but that was last updated for 0.90 and is incompatible with 1.1+. There is also the Tundra Exploration pack but that seems a bit too stock-alike for me. 

5 hours ago, falken said:

It's a good thing I renamed my Kerbal space program directory "KerbalspaceprogramCURRENT" so I can continue on with 1.1.3, as I've got the game exactly the way I want it. All my parts, my ISP and thrust changes etc are intact.

Some of the new porkjet parts are really really ugly, but I'm so spoiled by SSTU. 

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.

On that subject, some screenshots: (click to make big and stuff)

If that's an SLS, it looks pretty darn cool.  

[RedParadize]

A bit sad we don't have the new shader in 1.2, but there is good improvement there. Mainly, the fuel priority selector will allow me to built what I wanted for a really long time: replaceable lateral booster. Also, I don't know if its because I have no mod installed but its damn quick. I will have to clean up my stuff. 

And yes, I feel horribly naked without SSTU. I do not remember how to play without it now...

Edited September 14, 2016 by RedParadize

[Shadowmage]

Progress update:

Initial porting is done.  Module-manager code-side dependencies have been temporarily moved over to stock Events.  Plugin compiles, parts load, all part functions tested so far seem to work.  Had to fix a quite nasty crash bug regarding highlighting that wouldn't even spit out a stack trace; but the good news is that I can actually get proper highlighting on the modular/procedural parts now (after I figured out what was going on... which took a bit without any logs).

Custom shader is quite broken at the moment.  Spits out an error about being compiled under the wrong Unity version, which is true.  The problem with that is there are no PartTools compatible with 5.4 yet, and those are needed to compile KSP-compatible AssetBundles.  The current 5.2 PartTools don't work properly with 5.4 for some reason.  I can potentially solve this though as I can write my own AssetBundle compiling script, I merely need to figure out what encoding/platform setup is used.

Symmetry parts with modified resources is also borked, they don't serialize properly to the copied parts and throw out-of-bounds exceptions.  Stock bug report filed ( http://bugs.kerbalspaceprogram.com/issues/11476 ).  Will have to wait for that one to get fixed.

Otherwise... so far so good.  Fuel tanks seem to work.  Engine clusters still working.  Next up is more testing and fixing/updating of any problems I find and can fix.  Will likely move on to working on figuring the ins-and-outs of the PartUpgrade system after that or finishing integration of the custom shader stuff.