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

[Shadowmage]

Updated testing release is available:

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

Mostly bugfixes for RO, and also fix up the LC-pods losing their model-variant setting.  See the link for full changelog and download links.  Github, Curse, and AVC have all been updated for the new version.

[Sudragon]

The TAC-LS MM patch for SSTU, was it in SSTU or over in TAC LS? 

[Shadowmage]

11 hours ago, Sudragon said:

The TAC-LS MM patch for SSTU, was it in SSTU or over in TAC LS? 

It -was- in SSTU, but I'm not sure that I ever re-enabled/included them after the 1.1 update.  Will see about cleaning those up for the next release

 

On Tuesday, May 17, 2016 at 9:29 AM, Brainpop14 said:

Can you add more variations of the AJ-10 engine? I want to be able to make more things, like a Delta II second stage, or maybe a transtage. So can you add more variations of the AJ-10 so I can do that?

Possibly in the future.  Certainly not within the next few weeks/months though, already have quite enough on my plate that needs finishing.  Please keep in mind though that enabling recreations of real-world rockets is not the purpose of SSTU; if the engines do not serve a distinct purpose/need I likely will not be making them.  Edit:  CobaltWolf's BDB mod may have more of what you are looking for; he does more real-world recreation rockets: 

 

Edited May 18, 2016 by Shadowmage

[CobaltWolf]

8 minutes ago, Shadowmage said:

Edit:  CobaltWolf's BDB mod may have more of what you are looking for; he does more real-world recreation rockets: 

@VenomousRequiem can attest to the fact that we have all too many AJ-10s, including Delta II and Transtage.

Edited May 18, 2016 by CobaltWolf

[VenomousRequiem]

3 minutes ago, CobaltWolf said:

@VenomousRequiem can attest to the fact that we have all too many AJ-10s, including Delta II and Transtage.

Don't even get me started 

[Shadowmage]

Updated testing release is available:

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

Several more bugfixes, and adds a ton of new texture-swap options for tanks and engine mounts, courtesy of @JoseEduardo

[ComatoseJedi]

@JoseEduardo

[GoldForest]

Is anyone else having a problem with the right-click menu not updating the propellants/electrical charge/etc when you change its size?

[Acvila]

you need to have another click to see the changes.

[19chickens]

Was just looking for a TACLS patch!

 

[Jimbodiah]

... wrong thread

Edited May 19, 2016 by Jimbodiah

[Qwarkk]

Did the most recent update releases intentionally change the smallest size of certain engine mounts? i.e I used to use a RL-10A-4 engine in five radial configuration and the mount-S-II at 2.5m. Now though it wont size to anything below 3.1250m. Just want to check before updating all my crafts to fit.

[Shadowmage]

10 hours ago, GoldForest said:

Is anyone else having a problem with the right-click menu not updating the propellants/electrical charge/etc when you change its size?

Hmm.. I recently changed some of the resource updating stuff because of some null-reference problems I was running into; there is a chance that this negatively impacted the in-editor updates as well (it was intended to catch cases of newly-launched craft/not crash while initializing the flight scene).

 

20 minutes ago, Qwarkk said:

Did the most recent update releases intentionally change the smallest size of certain engine mounts? i.e I used to use a RL-10A-4 engine in five radial configuration and the mount-S-II at 2.5m. Now though it wont size to anything below 3.1250m. Just want to check before updating all my crafts to fit.

Intentionally, no.  Did the default mount size for that engine/layout change, or only the minimum?  I did change how the minimum mount size for any layout/mount combination was calculated; removed some really silly code and replaced it with some pure math functions, but it shouldn't have had too much of an impact on most engines (it should have only removed sizes that were actually too small).  However if the default size changed, that would likely be an error (and -would- impact the minimum size as well).

The minimum size available should (basically) be the defaultSize - (defaultSize/4) (rounded to next highest increment) (the actual code is quite a bit more complex due to floating point/integer handling)

[Shadowmage]

One thing that I'm planning for this weekends' release is cleaning up the current texture-set mess a bit, moving some of the texture sets into the base distribution and having the rest available as a separate download.  This will keep the release upload/download size to a minimum and will still allow for the installation of the full set of textures as desired.

The question today is:  what textures should be kept in the base distribution?

I'm leaning towards keeping the 'historic' or 'real-world-derived' sets as part of the base pack and moving most of the various colored options into the separate texture-pack.

This would leave:

MFT Tanks:

• SLS (stripe set 1)
• Saturn (stripe set 2)
• Shuttle (orange, only yellow intertank stringers)
• Delta-IV (orange, white intertank/stringers only)
• Gray (for soyuz)
• Green? (alternate soyuz?)

 

MUS Tanks:

• Standard/Original (white/silver)
• SLS/Stripes1
• Saturn/Stripes2
• ??  one or two more, gray or green?

 

Mounts:

• Base/Original (varies; generally black and white or green)
• Orange (shrouds for soyuz 2nd stage, RD-10X, few others)
• Gray

Fairings/Decoupler:

• Base (white/black and white)
• Stripes and checkers (all)
• Gray

 

Any other suggestions/ideas/preferences?

[Akira_R]

9 minutes ago, Shadowmage said:

One thing that I'm planning for this weekends' release is cleaning up the current texture-set mess a bit, moving some of the texture sets into the base distribution and having the rest available as a separate download.  This will keep the release upload/download size to a minimum and will still allow for the installation of the full set of textures as desired.

The question today is:  what textures should be kept in the base distribution?

I'm leaning towards keeping the 'historic' or 'real-world-derived' sets as part of the base pack and moving most of the various colored options into the separate texture-pack.

This would leave:

MFT Tanks:

• SLS (stripe set 1)
• Saturn (stripe set 2)
• Shuttle (orange, only yellow intertank stringers)
• Delta-IV (orange, white intertank/stringers only)
• Gray (for soyuz)
• Green? (alternate soyuz?)

 

MUS Tanks:

• Standard/Original (white/silver)
• SLS/Stripes1
• Saturn/Stripes2
• ??  one or two more, gray or green?

 

Mounts:

• Base/Original (varies; generally black and white or green)
• Orange (shrouds for soyuz 2nd stage, RD-10X, few others)
• Gray

Fairings/Decoupler:

• Base (white/black and white)
• Stripes and checkers (all)
• Gray

 

Any other suggestions/ideas/preferences?

This sounds good to me!

Sorry if this has already been addressed at some point, I'm sure that you have thought of this and there must be a reason why it hasn't been done yet, but hey might as well make sure, is there any way to have a "scroll bar" (like what is used to change mount style) for changing textures? If that's not possible could we at least get a previous texture button?

Really digging the new textures btw. 

[tater]

I tend not to use the colored version very often, your list seems reasonable.

[Qwarkk]

3 hours ago, Shadowmage said:

Intentionally, no.  Did the default mount size for that engine/layout change, or only the minimum?  I did change how the minimum mount size for any layout/mount combination was calculated; removed some really silly code and replaced it with some pure math functions, but it shouldn't have had too much of an impact on most engines (it should have only removed sizes that were actually too small).  However if the default size changed, that would likely be an error (and -would- impact the minimum size as well).

The minimum size available should (basically) be the defaultSize - (defaultSize/4) (rounded to next highest increment) (the actual code is quite a bit more complex due to floating point/integer handling)

As far as i can tell, the default size hasn't changed. And based on that (simplified) calculation, a minimum size of 3.1250m instead of 2.5m would be accurate. 

[Shadowmage]

6 minutes ago, Qwarkk said:

As far as i can tell, the default size hasn't changed. And based on that (simplified) calculation, a minimum size of 3.1250m instead of 2.5m would be accurate. 

Thanks for the confirmation;  Pretty sure I know what is effecting these -- previously I had code that would subtract one additional increment for the min-size, in addition to the size/4 adjustments.

Will see what I can do to clean up that functionality to restore the previously available sizes.  I don't have the code there specifically to limit options/choices, its merely there to eliminate those choices that would not look very good (e.g. mount obviously way too small); so perhaps having it allow a slightly wider range of sizes isn't a bad thing (as long as the default size is calculated appropriately, I'm fine if the user wants to select a non-optimal size).

[Shadowmage]

1 hour ago, Akira_R said:

This sounds good to me!

Sorry if this has already been addressed at some point, I'm sure that you have thought of this and there must be a reason why it hasn't been done yet, but hey might as well make sure, is there any way to have a "scroll bar" (like what is used to change mount style) for changing textures? If that's not possible could we at least get a previous texture button?

Really digging the new textures btw. 

The current GUI setup situation is one caused by evolution:
First, I have to program the GUI controls for texture swapping on a per-module (and sub-part) basis.  Adding a button for a control is like a simple 3 lines of code; adding a text-slider control is closer to 40.  Multiply that out by the number of modules/sub-models that need texture handling, and it'd probably be another 500 lines of code to deal with.  For instance the SRB has three separate texture-swap controls, and each would need its own' copy of the code; the MUS has 5 controls, MFT has 3, engines have 1, fairings/decouplers each have 1 (x 4 different modules) (at least 16 instances that would need new code).  Additionally when I first set up the system, the text-sliders did not even exist (KSP 1.0.x), so they were not even an option; it simply was not a choice available to me at the time.
Second, when the system was devised I did not imagine ever having more than 2-3 textures for each model... where a single button is more than adequate.
Third, time.  Takes <5 minutes to add a simple texture swap button and code, and closer to an hour (per ui control) to do the setup for the text-slider.  Dealing with the sliders requires tons of extra event handling, field validation, and GUI-updating code.  They are really not setup to have their options manipulated at run-time, and cleaning up those issues is a large portion of the extra time and code overhead; it can be done, but is a giant hack that needs to be carefully handled.

I -may- change this out in the (near) future;  I'll have to take a look and see what I can do about reducing the time/code overhead for each one.... I might be able to devise a more generic and usable set of methods so that I don't have to duplicate the code 16 times across the modules and sub-model bits.

[ComatoseJedi]

How hard would it be to have a mylar type texture with one the mft tanks that excludes the piping on the sides?

[Shadowmage]

16 minutes ago, ComatoseJedi said:

How hard would it be to have a mylar type texture with one the mft tanks that excludes the piping on the sides?

Impossible;  the piping is part of the model geometry and not texture -- it would require a completely new set of geometry, models (.mu files), textures, a new part config to use them, and all of the other model-definition config data for their volumes/geometry setup. 

This is already planned (e.g. the MFT-C, for 'cryogenic'; single-fuel, no intertank geometry, various 'foil' textures), however no idea if/when I will be able to get to it; at the current rate of progress I'll burn out long before I get to it (have been trying to get to station parts for what.... like 6 months now?).

[Shadowmage]

Working on adding the LanderCore pods to the life-support patches;  the USI-LS patch wasn't too hard, I'm familliar with those resources.

But the TAC-LS patch is presenting some problems;  notably, I have no clue what the volumes are for those resources.  Specifically the requirements for oxygen seem... ridiculous... at 40 units/kerbal/day if the units are given in liters; and the food/water values also seem... off at 0.39l of food and 0.28l of water per kerbal per day.

I'm... guessing?... that food and water are 5l units, and that oxygen is...??? no clue on that one.  No way that these things can hold 40l of oxygen/kerbal/day... you would end up with larger o2 tanks than propellant tanks for any non-lko manned mission.

 

TL:DR;  anyone know what the resource volumes are intended to be for the TAC-LS resources? (Food, Water, Oxygen, Waste, WasteWater, CarbonDioxide)

 

Edit: Nevermind... CRP has been updated with volume definitions for all of those resources.  Whatever is listed there is what I have to go with.  They still have oxygen listed as 1-liter unit.... so... no clue how to handle that.  The o2 tanks on these pods would be larger than the entire pod.

[blowfish]

@Shadowmage My experience with UI_ChooseOption is that it doesn't really require that much code ... what needs to be done that's requiring you to do so much?

Edited May 19, 2016 by blowfish

[Shadowmage]

3 minutes ago, blowfish said:

@Shadowmage My experience with UI_ChooseOption is that it doesn't really require that much code ... what needs to be done that's requiring you to do so much?

Run-time updating of the current options and current selection.  If the GUI is already open and you update the backing arrays and current field value, the GUI will not update its displayed value without substantial prodding (more precisely it does not automatically update its internal cached 'index' value, which can cause index-out-of-bounds exceptions, so I have to basically force-re-initialize the entire GUI control) ( https://github.com/shadowmage45/SSTULabs/blob/master/Source/Util/SSTUExtensions.cs#L401-L428 ).  More time/code is spent on setting up the callback methods, seating the references to those callbacks, initializing the initial backing arrays and initial field value ( https://github.com/shadowmage45/SSTULabs/blob/master/Source/Module/SSTUModularFuelTank.cs#L387-L394 ).

And with each potential model having its own set of textures, I need to add methods to recalculate the backing arrays every time the model is changed, as well as updating the current GUI selection for the new current value (pulled from the default for the model) ( https://github.com/shadowmage45/SSTULabs/blob/master/Source/Module/SSTUModularFuelTank.cs#L189-L209 ).

Additionally the callback methods for the GUI controls constantly send fake/invalid events.  So, for each field, I have to track the 'previous' state and compare that to the current/'supposedly new' state to know if there actually was a change.  This can be seen, for instance, any time one right-clicks on a part to open the GUI; every GUI control for every module on the part will have its 'on value changed' method called and/or fire editor-ship-modified events even if the value was not actually changed.  This requires even more code to manage tracking and updating of the 'previous' values for the fields (e.g. 'previous' needs to be initialized to 'current' on part load and any time the value is actually changed).

Mostly the time/code is spent in working around those updating problems; if I could just set the value of the field and backing arrays and it all 'just worked', it wouldn't be too much extra code to implement (just the backing array rebuilding).  The rest of the time is spent in the per-module-per-model setup; it is painful and results in massive amounts of (almost) duplicate code... but each module needs to handle its setup slightly differently because of how the various model bits are pulled together to form the finished part (e.g. the MFT module needs to know what transforms are the 'nose', and which is the 'tank'; whereas the MSRB needs to know what is a 'top cap', what is a 'body', and what is a 'nozzle'; etc).

Very little of that is needed for a button.  I merely validate the 'current' value during OnStart (in case it was an uninitialized part/module) and on subsequent model changes, and the rest of it 'just works' from there.  When the button is pressed it basically calls 'currentTexture = modelData.enableNextTexture(currentTexture)'.  No array rebuilding, no hacking-around-gui-stuff to force update the displayed values.

 

If you happen to know easier workarounds to any of those problems, I'm all ears    (or if the problems are no longer problems;  I haven't changed the code much since the early pre-releases and some of them may have been fixed in the stock code by now).
 

[blowfish]

Ah yeah, it does get a lot more complicated when you have to change it dynamically, doesn't it?

The previous value is definitely passed into the on value changed event as a parameter (just as an object but it should be safe to cast). I know there are also (as of 1.1.2) checks in KSP to make sure the event is fired only if the value actually changes, but maybe there are some circumstances under which those checks aren't run. Might have to experiment a bit.