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

[tater]

Payload fairing mass could also have an upgrade path. Might be interesting to look at fairing mass history for long term vehicles like R-7, Atlas, etc.

Hard to tell for Atlas, fairing actually became heavier for the same shape. Perhaps strength, etc was also improved. KSP can obviously fudge for whatever game balance is desired. Heavier, but cheaper and stronger, or lighter and more expensive, whatever.

[Mike`]

2 hours ago, tater said:

Hard to tell for Atlas, fairing actually became heavier for the same shape.

Did you actually find sources/documents for real fairing weights? Would be interesting to know.

Will open a ticket for those soon, i guess.

[tater]

This had some data:

http://www.braeunig.us/space/specs/atlas.htm

I looked at a few others. 

[Bottle Rocketeer 500]

Where can I download a release (for 1.2.2) of SSTU?

[Shadowmage]

26 minutes ago, Bottle Rocketeer 500 said:

Where can I download a release (for 1.2.2) of SSTU?

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

Was the last release for 1.2.2.

[Shadowmage]

 

Yes you do Thank you. Update here

Excuse the throw-in @Shadowmage

No worries; looking nice, and a quick turn-around on getting that modeled

 

 

My comments about where the early parts are unlocked aren't exactly what you'd call major complaints, they just seemed a bit strong for the same point in rocketry where I'm using the biplane rudder as my rocket fins (silly looking, but they make awesome rocket fins with a relatively large control surface). Particularly the second SRB - the SSTU - SC-ENG - SRB-A - it has a max thrust of 1250, which exceeds everything up to (in the CTT) Heavier Rocketry that is four nodes later at the 160 science level.

I understand about the tank, I didn't realize you had an intentional mode that removes the stock parts, so yes if that's your smallest tank then it needs to be there.

This is what I would do were it mine to do, which it isn't, and again admittedly this is not exactly an issue where lives hang in the balance, so just a suggestion:

1) Like how the Procedural Parts parts limit their diameter/length on their tanks/SRBs, limit the length of the Magic Fuel tank to no more than 1m longer than whatever is the longest stock tank available at that tech level.

2) Leave the SSTU - SC-ENG - SRB-U at the Basic Rocketry intro node but as above, limit its sizes so it's only a bit more powerful than whatever stock has at that point.

3) Move the SSTU - SC-ENG - SRB-A to at least General Rocketry one node later (player already has one very competent SSTU SRB), but preferably to Advanced Rocketry, but limit its sizing to a max thrust of ~750kN. I have most part packs including Contares this time around, and the biggest SRB I see at that node is the Globe X at 614kN, so the SRB-A at that point would supply a reasonable somewhat larger option.

4) As for the Probe Core and its upgrade to 1.875 being in the same node, that looks odd, exactly like you couldn't figure a better plan so just went "fark it" and dumped it there   The simplest solution out of that oddity is to move the 1.875m upgrade to Miniaturization one node later. But I think a more interesting and arguably more logical progression is to make the default part 1.875m and available in the Basic Science node. For miniaturization, you get an upgrade to 1.25m, and in Precision Engineering you get .625m. Remember new designs generally start fairly big, and with lots of experimentation and engineering we make parts that are just as good, only smaller and lighter and therefore cheaper. So starting with a mid-size and having to do engineering to get smaller, lighter versions makes sense.

So I've been taking a bit more of a look over career mode over the past couple of days (in prep for an upcoming career playthough), and have already made a couple of tweaks to part locations / unlock costs.

A few things though are not in the current plans -- 

• limiting fuel tank lengths by tech tree; there are both technical problems that would prevent it, but it also goes against the main purpose of the mod (low-part count).  I hate tank-stacking with a passion.  No thanks.
• Adjusting the thrust of the SRBs -- not likely to the degree you propose.  Their thrust is based on the scaled-down thrust of the 4/5 segment boosters used on the shuttle/SLS; just like all of the scaled engine thrust stats, it uses the same balance scheme as applied to the rest of the SSTU parts (square scaling; x * scale * scale).
  • 45m x 3.71m - 4-segment - 12000kn = ~3000kn/segment
  • 3.71m * 0.64 = 2.374 (round up to 2.5m)
  • 12000kn * 0.64 * 0.64 = 4915kn for a 4-segment 2.5m SRB at 64% scale
  • 4915 / 4 = 1228kn/segment @ 2.5m diameter (which I've actually reduced to 1050kn/segment)
  • 4915 * 0.5 * 0.5 = 1228kn for a 4-segment 1.25m SRB = 307kn/segment
  • They also have a much worse default/starting ISP compared to the stock SRBs (170/195 vs 195/220)
  • Will do a more in-depth comparison vs. the stock parts in the near future.  If they are -waaay- out of whack compared to stock parts, then I will do some adjustments (as long as it doesn't interfere with their intended balance/use at 2.5m scale) (or... more probably I'll just delete the stock SRBs in my patch setup and ignore their poor scaled balance)

A few other balance/cleanup related changes I've made this week:

• The probe-core 1.875m unlock has been removed, as the PPC already starts with 1.875m max diameter (was an omission when the tech nodes were last updated, the extra upgrade was not removed).
• SRB-U is being moved into AdvRocketry node (or similar). The SRB-A is the 'low tech' SRB; the -U model is a late-tech upper-stage SRB; as it includes RCS capability, it should only be unlocked at least the same tier as other RCS parts.
• Fuel Tank modifier types now must be unlocked through the tech-tree -- can't have lightweight tanks/zbo/etc without first doing the research (and paying) for them.  They will be distributed along the tech-tree, with the more powerful options coming quite late in the tree (zbo and lightweight at 550sci nodes).
• Fuel Tank modifier types now influence the cost of the fuel tank.  Lightweight tanks may weigh less, but cost more per dry ton.  Precise balance WIP, but the feature should be in place and working (testing...).
• SRB segment selection can now be limited by tech-tree nodes using the stock part-upgrade/unlock system.  Placement of the segment-unlocks is TBD/WIP. (actually still needs to be tested to see if it even works at all...)

Generally though I've found the early-career balance to be of no consequence.  The last couple of nights I have been doing early-career tests in which I deliberately don't touch the SSTU parts.  The outcome?  Not really any different; sub-orbital on 2nd' flight, orbital on 3rd.  Rocket looks worse with the stock parts and stacked tanks, and the fuel-tank stacking is absurdly noodly (until auto-struts are enabled), but overall no real change in how I would progress in the early career.  Yes, 'abuse' of the SSTU parts (tanks/srbs) could impart some minor advantage in raw dV or thrust -- but that early in career the limiting factors for what can be accomplished are the VAB 18t limit and the lack of other utility parts (solar panels/batteries/probe-cores/antenna).  By the time those other parts become available (and you start doing any sort of real missions), the early-career imbalance is little but a fading memory.

 

 

If I had one request, it would be for something that's a little different from most of your parts, but I'm asking because SSTU parts work better and are better-engineered than any other parts I've seen. I think I've tried every winch + dart, magnet grabber, and the grabber units and claws, and so far I give every one of them maybe 1/5 stars, especially the grabbers, which I have managed to trigger once in eleventy thousand attempts; almost all of the parts they tell me to go get are so light you'd need to be moving fast enough to destroy the part to generate enough impact force to trigger the grabbers.

The real head-scratcher for me is why none that I've seen have a manual trigger. Anyway, I'm sure you could make something better, what made me think of it was the fairly long procedural nose-cone with a smooth ogive. What I was thinking was a very large (compared to others) grabber that opens like an umbrella and then when activated to grab a part, tries to close down to its original long ogive. It could have an auto trigger, but I was thinking more along Konstruction lines where you have a UI for control.That big umbrella isn't meant as the final hold, that is just literally to grab and control the part so you can get it oriented correctly for its final hold. Final hold  would be either magnet, or if you want to get creative, could also use linked KAS pipe nodes, but that requires EVA.

Not something that I'm prepared to get into in the near or medium-term.

I agree though -- I have not been impressed with the usability of any of the claw/grappler type parts either.  The stock claw never seems to attach properly, regardless of speed/angle.  The KIS/KAS harpoons/winches/magnets were about the same last I checked (though using the dedicated 'port' setup worked fine, but requires a kerbal to hook up the line).  And last I tried Konstruction, I couldn't get the magnet parts to do anything.  The only time I've actually used any of those parts have been in my one or two asteroid missions (using the claw), and it was a frustrating experience due to the claw bouncing off of things repeatedly, even though the approach was straight and within the 'acceptable speed range'.

I haven't dug into the code on any of them, but I would imagine the problems all boil down to one thing: Unity physics.  In theory it should be quite easy to do a raycast from the claw/harpoon attach point, see what collider would be hit, and attach using that data (could still allow/disallow attachment based on hit-angle or relative velocities).  But I really don't have the time to dig into it more than that.  Perhaps sometime later this winter or next summer.

[Shadowmage]

@vossiewulf

Re: SRB Thrust balance --- I think this pic sums up the situation regarding the SRB thrust better than I can put into words:

(note the stock 'kickback' thrust and resource quantity; compare vs. the SSTU-SRB thrust and resource quantity;  the stock SRBs are actually -more- powerful than the SSTU parts at the same size, and have higher ISP). 

If you were referring to the 2.5m diameter SRBs having more thrust than any other (1.25m) SRB -- well, yes, that is to be expected.  Unless there was something I was missing / some specific setup you were referring to?  (I'm certainly open to fixing balance problems, but I'm not seeing any with the setups that I'm looking at)

 

More on the subject of early career balance:

A comparison of the early-career first-to-orbit rockets (stock vs. SSTU) (click to zoom), where the limits are set by the tier1 VAB / pad.

vs.

TMIDC (too much info, didn't click...):  The craft balance is very comparable for the given task.  The stock parts actually have higher performance for a roughly equivalent rocket (by size/mass)(stock engines have higher ISPs), but the SSTU parts reduce part count slightly (9 vs 12).

Stock science total - 70

• Basic Rocketry (5) - LVT-45 lower stage engine
• Engineering101 (5) - decoupler (used SSTU decoupler in img, but stock should be roughly equivalent mass/cost)
• General Rocketry (15?) - pre-req for adv rocketry
• Advanced Rocketry (45) - Fuel tanks and -909 upper stage engine

SSTU science total - 20!

• Basic Rocketry (5) - Merlin-1A lower stage engine, decoupler, fuel tank
• General Rocketry (15) - LR-81 'upper' stage engine

Hmm.. so yeah... might be a bit of an imbalance there.  Two minor changes would make them equivalent tech-tree wise: move the SSTU decoupler to engineering (+5), and move the upper-stage engine to adv rocketry (+45).  For a stock setup this will probably be a good solution.  For the trimmed-down setup (no stock engines/tanks) it would leave general rocketry (15) as an empty node;  I had intentionally positioned the LR-81 there as the only other engine I could put in its place was the Merlin-1B, which completely obsoletes the -1A (which was recently unlocked in the previous node). 

(I should note that technically you can do it with stock parts at 10-sci, but it requires using a second LVT-30/45 for your upper-stage and a lot more fuel-tank stacking, bringing part-count and mass up quite a bit; the same could be done with SSTU at 10-science as well, with a much lower part-count)

As the 'optional patches' are, well, optional, it would seem that the solution (at least part of it) would be to re-position the LR-81 and decoupler in their stock configurations as proposed above, and then move the engine back to its current position through a patch in the optional patches.  Probably a few other tech-tree changes that could be made to the default configurations to more closely line up with the stock tech-tree; can patch to move things around for the trimmed down install to fill holes if needed.

[vossiewulf]

 

So I've been taking a bit more of a look over career mode over the past couple of days (in prep for an upcoming career playthough), and have already made a couple of tweaks to part locations / unlock costs.

The "Quote This" function appears to be broken, when I highlight a sentence I get a black dot that looks like it's missing its button text and you can't click it.

Thanks for the detailed response, all sounds good - it was clear you hadn't looked into it extensively, now you are, the outcome is that this very important parts mod will be better-integrated into career mode, whatever decisions you make, and the ones you've mentioned all sound logical. I had noticed the -U seemed more advanced than the -A, but the minimum length of the -U seemed more in line with early rocketry.

Also I was thinking that pretty much everyone uses KJR and with that the number of tank joints you have is much less important, so the extra tank length isn't an undue advantage (I still think it might be in a non-KJR game but hey). And yes I forgot about the founding principle being low-count, not just uber-cool as I had been thinking, so forcing it down the path of high parts count stock doesn't make much sense.

Returning to something I asked about earlier, before I forget again: I love the multiple SRB nozzles, but I'd love them even more if they had different performance characteristics, as I'm sure the real ones did. SSTU SRBs look an order of magnitude better than PP ones, but PP SRBs have one feature you don't, and that is chooseable ASL/Vac-optimized nozzles. I know you handle that function a little differently with SRBs intended from the start as launch or upper stage... but... all those beautiful nozzles are sitting there begging for them to have a least minor differences in burn time or thrust at various altitudes. Basically you're 95% there for another cool functional performance customization available to the players. I'm sure with a little thought like you've just put into the tech tree, you can come up with some interesting characteristics to choose from in the nozzle options and that means more interesting choices for the players.

I understand, the grabber request was a shot in the dark in case it was something you were already thinking about. And Unity physics is the reason I was suggesting a different approach - instead of trying to attach something (particularly with the attached thing attached to something non-rigid), make a cage-type device that never attaches to the part you're trying to capture. Instead we just retain it near the ship non-moving, so a second step (EVA w/KAS, or something else) can get it oriented as desired and firmly attached for reentry.

What I settled on is a central harpoon/winch surrounded by a ring of 6 more harpoon/winches, either also aimed straight or gimbaled slightly outward if the part I'm going after is big. If you get within 10m of your target chances are good more than one will stick, and three action groups let you shoot one half or the other or all of them at once. You'll still come down in a very un-NASA way with stuff flailing around everywhere, but it usually works.

[vossiewulf]

Re: SRB Thrust balance --- I think this pic sums up the situation regarding the SRB thrust better than I can put into words(note the stock 'kickback' thrust and resource quantity; compare vs. the SSTU-SRB thrust and resource quantity;  the stock SRBs are actually -more- powerful than the SSTU parts at the same size, and have higher ISP). 

Having to do this the old fashioned way- I don't think any of the SSTU parts are inherently OP, my only point was that some of them were OP for the tech level they were set at.

 

 

Stock science total - 70

• Basic Rocketry (5) - LVT-45 lower stage engine
• Engineering101 (5) - decoupler (used SSTU decoupler in img, but stock should be roughly equivalent mass/cost)
• General Rocketry (15?) - pre-req for adv rocketry
• Advanced Rocketry (45) - Fuel tanks and -909 upper stage engine

SSTU science total - 20!

• Basic Rocketry (5) - Merlin-1A lower stage engine, decoupler, fuel tank
• General Rocketry (15) - LR-81 'upper' stage engine

Hmm.. so yeah... might be a bit of an imbalance there. 

Yep, that was my point. Your ideas to redress sound good.

[Jimbodiah]

... error on my part... sorry

Edited October 5, 2017 by Jimbodiah

[Jimbodiah]

 

Hmm.. so yeah... might be a bit of an imbalance there.  Two minor changes would make them equivalent tech-tree wise: move the SSTU decoupler to engineering (+5), and move the upper-stage engine to adv rocketry (+45).  For a stock setup this will probably be a good solution.  For the trimmed-down setup (no stock engines/tanks) it would leave general rocketry (15) as an empty node;  I had intentionally positioned the LR-81 there as the only other engine I could put in its place was the Merlin-1B, which completely obsoletes the -1A (which was recently unlocked in the previous node). 

Mage, you are talking about a rebalance for a part in the tree that lasts a single launch. Once you unlock survivability with your first launch, you should be able to unlock 3-4 more nodes with the second launch. This kind of makes it a moot point and is why I put the decouplers together with the respective tank diameters on the previous balance pass.

To go even further; when I played stock I just put an engine on top of the previous stage and that would decouple by blowing up the previous tank due to the heat. Heck my first launch is a four section SRB just stacked on top of each other where each one blows out the previous one on staging so I could get at least 2-3 biomes before splashing down.

You can't get a 100% balanced tree, especially when using other mods; bluedog offers decouplers in the 2nd technodes as well, so anyone using that mod will get an alternative to the sstu decoupler (not even mentioning using tweakscale). When using CTT I remove the SSTU ctt folder as engines are spread out into nodes that are meant for atomic engines or near-future parts: unlocking a J2X when you already have nukes and plasma engines is unbalanced in the opposite direction.

Someone needs to come up with a 100 node techtree so we can make single year development increments to mirror real world progression of technology.


BTW: If you've played careers, you know your second launch will be an orbit mission or very close to it if you miscalculated, the 3rd launch is definitely an orbit mission around Kerbin/Earth with the 4-5th being moon shots already. The early techtree is unlocked in just a few missions. If you take a majority of the available orbital science around earth and the moon, you have unlocked half the techtree already and about 1/3 of the CTT version. Moon landings will get you 3/4 into the stock tree and only CTT will need you to go to Duna/Mars to start unlocking the 1.000+ science nodes.

And I won't even mention using labs to do a complete cheat and get 6x the science, meaning a set of Mun/Minmus landings will unlock the complete stock techtree 

Edited October 5, 2017 by Jimbodiah

[vossiewulf]

I agree that no one ever gets 100% balance in any game more complex than checkers, and I started by saying these were minor quibbles. But at the same time everything I've heard Mage say about what he's going to change qualifies as an improvement, so no complaints either. My guess is his look isn't going to stop at these initial stages, now that he's thinking about it he'll walk through the whole tree, as he said he hasn't spent much time thinking about this subject. The end result should be a markedly better-integrated SSTU for career mode.

And for the other subjects, heck even if he did something simple with the SRB nozzles like one is standard and the other four offer minor thrust and/or burn time increases for increased costs (with costs rising faster than performance increase), that's another interesting customization option that could make all the difference with certain designs.

[tater]

This is really nice, it just needs some SSTU ease of use...

The texture replacer reflections are pretty amazing:

You can see the "Hoyo" lander in the background... Al the tanks are visible inside the descent stage, BTW. These mods are really pretty. I realize that I forgot to put the RCS on the descent module, as well as the airlock/hatch part. Doh!

 

 

 

I used SSTU to get them to the Mun. 

Edited October 5, 2017 by tater

[vossiewulf]

Has this been seen before? I have this guy parked in orbit for a 72 hour endurance contract, switch to him and all I can see is fuel tank. I zoom in and the ship is there and I'm pretty sure it's the right size, but the fuel tank appears to have decided it's 10m. If it's not been seen before will grab logs.

[Shadowmage]

8 hours ago, vossiewulf said:

Has this been seen before? I have this guy parked in orbit for a 72 hour endurance contract, switch to him and all I can see is fuel tank. I zoom in and the ship is there and I'm pretty sure it's the right size, but the fuel tank appears to have decided it's 10m. If it's not been seen before will grab logs.

 

That would be a new problem; likely caused by the plugin throwing an error during initialization.  Logs please; will let me know what/where the problem is, and at least diagnose / start debugging it.

 

8 hours ago, tater said:

This is really nice, it just needs some SSTU ease of use...

The texture replacer reflections are pretty amazing:

 

You can see the "Hoyo" lander in the background... Al the tanks are visible inside the descent stage, BTW. These mods are really pretty. I realize that I forgot to put the RCS on the descent module, as well as the airlock/hatch part. Doh!

 

I used SSTU to get them to the Mun. 

Hmm.... I wonder....  https://github.com/HaArLiNsH/TextureReplacerReplaced/blob/master/Unity/Assets/Shaders/TR_Reflective_Emissive_Alpha.shader

(last I played with reflections... it was... not pretty...)

(More hmm... apparently requires active plugin updating in order to keep the reflections working:  https://github.com/HaArLiNsH/TextureReplacerReplaced/blob/1cdb27411baf644addae3a1b290bf091a68de705/Sources/Reflections.cs#L264-L301 )

Edited October 5, 2017 by Shadowmage

[AcinonyxJubatus]

Hi all.

This is a kind of feature request, but maybe the feature is already there and I haven't unlocked it yet.

I think it would be dead useful to have some modules (typically the reentry modules) serve as experiment storage units. It would allow to move experimental results, and return them to Kerbin/Gael/Earth/Wherever, without having to stick an experimental storage unit on top of the capsule (or in any other unspeakable place), hence disabling the coupler.

Thanks in advance for your reactions...

[tater]

3 minutes ago, AcinonyxJubatus said:

Hi all.

This is a kind of feature request, but maybe the feature is already there and I haven't unlocked it yet.

I think it would be dead useful to have some modules (typically the reentry modules) serve as experiment storage units. It would allow to move experimental results, and return them to Kerbin/Gael/Earth/Wherever, without having to stick an experimental storage unit on top of the capsule (or in any other unspeakable place), hence disabling the coupler.

Thanks in advance for your reactions...

So this would be adding:

		evaOnlyStorage = True // i.e. can nearby regular vessels also do this, or EVA only
		storageRange = 1.3
		canBeTransferredToInVessel = True
		canTransferInVessel = True
		showStatus = True

to the science container.

[AcinonyxJubatus]

9 minutes ago, tater said:

So this would be adding:

		evaOnlyStorage = True // i.e. can nearby regular vessels also do this, or EVA only
		storageRange = 1.3
		canBeTransferredToInVessel = True
		canTransferInVessel = True
		showStatus = True

to the science container.

I'm not familiar with the SSTU science container, I probably haven't unlocked it yet.

[tater]

Well the science container is on the pods (store experiments via right-clicking). I haven't tested the ability to transfer science like the new stock part. You are right, this would clearly be useful functionality that saves a lot of clickfest.

[AcinonyxJubatus]

2 minutes ago, tater said:

Well the science container is on the pods (store experiments via right-clicking). I haven't tested the ability to transfer science like the new stock part. You are right, this would clearly be useful functionality that saves a lot of clickfest.

You mean you can store results from EVA? You can take them from the sensor and store it in the pod with a scientist in EVA?

[tater]

Just now, AcinonyxJubatus said:

You mean you can store results from EVA? You can take them from the sensor and store it in the pod with a scientist in EVA?

Yeah, you can right-click an experiment on EVA, collect it, reset exp if required, the right click pod and store the science. I assumed you meant the auto-collection of all the science attached to the ship with one click.

[AcinonyxJubatus]

1 minute ago, tater said:

Yeah, you can right-click an experiment on EVA, collect it, reset exp if required, the right click pod and store the science. I assumed you meant the auto-collection of all the science attached to the ship with one click.

OK, great. Yes, that's what I meant, but at least I can do that, and I didn't know. Thanks.

[Shadowmage]

14 hours ago, vossiewulf said:

Also I was thinking that pretty much everyone uses KJR and with that the number of tank joints you have is much less important, so the extra tank length isn't an undue advantage (I still think it might be in a non-KJR game but hey). And yes I forgot about the founding principle being low-count, not just uber-cool as I had been thinking, so forcing it down the path of high parts count stock doesn't make much sense.

The low-part count isn't for fixing joint-rigidity (though it does help there), rather the low-part-count focus is for -improved performance-.  Every additional part added to a craft adds an additional Unity Physics Joint component, and these all take a ton of resources to simulate (plus the KSP per-part thermal/aero physics).  More parts = lower FPS.  Low FPS = me unhappy.  Seriously; the entire reason I started modding was because I kept getting yellow frame time on my large stations and bases, to the point that the input was laggy, and hard to actually do anything.  For awhile my solution was the part-welding mod (and then manual part welding) -- but I kept running into limitations in the stock PartModules (hence I started coding), and also in the stock model setups (so I started modeling).  And thus was born the first SSTU part -- the Apollo CM w/ integrated parachutes, docking port, decoupler, and RCS (this was a legacy version that is no longer around; the current model is actually the 2nd revision).

Besides, with the new stock 'auto-strut' feature, KJR is no longer a necessity.  The auto-struts do pretty much the same thing, but allow me to control what parts get strutted to which.  Not without their share of problems, but at least I can opt to turn them on/off.

 

14 hours ago, vossiewulf said:

Returning to something I asked about earlier, before I forget again: I love the multiple SRB nozzles, but I'd love them even more if they had different performance characteristics, as I'm sure the real ones did. SSTU SRBs look an order of magnitude better than PP ones, but PP SRBs have one feature you don't, and that is chooseable ASL/Vac-optimized nozzles. I know you handle that function a little differently with SRBs intended from the start as launch or upper stage... but... all those beautiful nozzles are sitting there begging for them to have a least minor differences in burn time or thrust at various altitudes. Basically you're 95% there for another cool functional performance customization available to the players. I'm sure with a little thought like you've just put into the tech tree, you can come up with some interesting characteristics to choose from in the nozzle options and that means more interesting choices for the players.

Sadly there is really no option for the SRB nozzles to influence anything else.  Thrust is set by the body length/diameter.  ISP is upgraded through part-upgrades.  Can only have one thing editing each stat, or there will be unresolvable conflicts.  So ISP is effected by the upgrades, and the thrust by the body selection / scale.  Nothing else that can really be done about it.  (In theory, and with a metric crapload more plugin code, one could setup the nozzles to vary the thrust/ISP on a per-nozzle basis, but it would be a complex, buggy, and very fragile mess of code.... I avoid getting into those un-maintainable code situations wherever possible)

Edit:  Thinking on it a bit more, it might be possible to add a 'thrust multiplier' to the nozzles, that would be a final multiplier to the thrust calculated from the body length and diameter.  Not sure what it would add though.  Also -- the SRB-U will be having its V-ISP increased to reflect that it is a vacuum optimized variant (though SL ISP will likely be decreased); precise values TBD.

In case you weren't aware, burn time can already be adjusted on the SRBs; both through the stock thrust limiter, and through the SSTU-provided 'thrust curve editor'.  Also, thrust and burn time are inversely related; if you increase one, you decrease the other.

 

14 hours ago, vossiewulf said:

I understand, the grabber request was a shot in the dark in case it was something you were already thinking about. And Unity physics is the reason I was suggesting a different approach - instead of trying to attach something (particularly with the attached thing attached to something non-rigid), make a cage-type device that never attaches to the part you're trying to capture. Instead we just retain it near the ship non-moving, so a second step (EVA w/KAS, or something else) can get it oriented as desired and firmly attached for reentry.

What I settled on is a central harpoon/winch surrounded by a ring of 6 more harpoon/winches, either also aimed straight or gimbaled slightly outward if the part I'm going after is big. If you get within 10m of your target chances are good more than one will stick, and three action groups let you shoot one half or the other or all of them at once. You'll still come down in a very un-NASA way with stuff flailing around everywhere, but it usually works.

I think your 'grabber' part might already exist in the stock game -- the MK3 cargo ramp, mk2/3 cargo bays, and even the service bays can all be used for this purpose.

(though I could be mis-understanding your request.... have any pics for examples?)

Edited October 5, 2017 by Shadowmage

[Shadowmage]

On a more... fun?... note; more testing in career-mode last night.  Apparently the SSTU tanks/mounts can look just fine when used with stock parts with some minor color adjustments (thanks recoloring GUI!).

Took a break between launch 2 (sub-orbital) and launch 3 (supposed to be orbital), and took advantage of the fact that the tourism contracts are limited to your highest accomplishment.  In this case, it was sub-orbital; so every single tourist wanted a sub-orbital flight.  Think I ended up launching this same craft/mission about 6 times (with 4 tourists each), bringing in ~80k funds for each set... which funded my R&D, VAB, and launchpad upgrades very nicely.  I really pushed the tier-1 VAB/pad weight limit with this craft, having only a 0.02t margin

Mission pics in spoiler:

Spoiler

 

After a brief coast to AP, the booster is decoupled, and the crew vehicle begins its re-entry.

Mostly its a long glide down to parachute altitude.  The fins make sure that there is enough lift to bleed of speed and not re-enter nose-first.  Early (unmanned) tests of the vehicle found that it really wanted to lawn-dart (ocean-dart) all the way down, and required some lift capability to ensure a safe re-entry from (often fairly steep) sub-orbital trajectories.

And then its a long slow descent to a splashdown.

 

From there I went orbital; craft was nearly identical to the one I linked a few posts above (2-stage, Merlin-1A lower, LR-81 upper).  So, sadly, now all of my tourist contracts want to go orbital, which is nowhere near as easy (or profitable); returning multiple crew from orbit at this point in career is... not simple or pretty.

 

In general development news:

More work on career balance and cleaning up the optional patches setup.

Have also been working on the LC fuel tank models a bit this week, though has been a bit slow going with work being crazy again.  If anyone had feedback / wanted to comment, now is the time to do so (before I finalize the models); feel free to add your say to the ongoing thread:  https://github.com/shadowmage45/SSTULabs/issues/570

[Shadowmage]

Reflective shader setup testing (the red/blue colors are all 'reflected' from the cube-map; the gray stripe is where the reflection is disabled in the spec/refl texture):

Hmm... and more hmm...

Only took ~4 lines to add reflection support to the existing custom SSTU shaders.  Getting it working with the user-masking setup... would be a bit more work.  Would also require an additional channel in one of the textures to control the reflective amount (probably spec-alpha channel), meaning more ram use for reflection-enabled parts/texture sets.  I'm also unfamiliar with how to best author the reflection textures, and it might well require higher-res textures to be used effectively for some models (NRM maps need to be high-res to get proper 'rough' reflective surfaces).

Same cube with reflections disabled:

 

Lots of stuff to think on.  Not sure that I want to spend the time to rework the recoloring system in the near future, but I'll probably keep the reflective support on the back-burner for awhile as I figure out how it would all be integrated (passing more user-specified channels into the shader setup to control the specular hardness and reflectivity amounts).