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

[vossiewulf]

All this great progress and stuff, but the probe core STILL doesn't have any indicator of where it's pointing, at this point if you send me the graphics I'll be happy to make new ones, and give you some options other than plain white or the stripes..

Seriously, the TV networks on Kerbin are beginning to openly mock me for numerous inadvertent polar launches. "Wrong way launch day", etc.

 

Edited July 8, 2019 by vossiewulf

[Shadowmage]

16 minutes ago, vossiewulf said:

All this great progress and stuff, but the probe core STILL doesn't have any indicator of where it's pointing, at this point if you send me the graphics I'll be happy to make new ones, and give you some options other than plain white or the stripes..

Seriously, the TV networks on Kerbin are beginning to openly mock me for numerous inadvertent polar launches. "Wrong way launch day", etc.

 

Pretty sure it does include indicators of orientation, baked into the texture.  Should be indicators for 'front' and 'top' on the respective sides, which should be enough to determine orientation during construction.

https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Assets/SC-GEN-DC-DIFF.dds

Note that these text indicators are on the 'top' and 'bottom' of the probe core / decoupler parts; once it is in a stack there should be no visible orientation markers on the external cylinder portions of the model.

The issue with allowing any kind of indicators on the side-panels is due to the procedural nature of the texture and UV mapping; any potential indicators would end up squashed, stretched, warped, and distorted dependent upon the currently selected 'height'.

You can try it out for yourself if you would like, and see if you can come up with anything acceptable.  Edit/replace the texture linked above with your alterations.  The top half of the texture are the cylinder caps, and the bottom half of the texture is the side panel.  Might only need to create new mask textures ( https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Assets/SC-GEN-DC-MASK-A.dds ) rather than the base diffuse, as the part is fully recolorable.  Simply create some masks that include your desired indicators

[vossiewulf]

Sigh yes they're on top, sorry, my blindness. That said, I'll poke at the graphic, thanks, another look or two wouldn't hurt.

[Joker58th]

I'm trying to understand the docking port/welding port snap/snap-angle feature.  So far I don't get it.  It seems that all that is needed is the values need to match on both ports and it doesn't matter the orientation of the ships.  One can be level and the other can level or rotated to any angle and they dock.  If the values are not identical, they don't magnetically attract.  What am I missing?  Or am I misunderstanding what this is for?

Here is my example, I have both welding ports set to 0 SnapAngle and Snap is on for both.

Spoiler

 

[Shadowmage]

23 hours ago, blowfish said:

Blame Squad for not making the solar panel code (and a bunch of other things) more modular.

Yeah, don't get me started...   ^^^ is the entire reason that SSTU exists.  If I didn't need part-modules that would work on welded parts, I never would have started coding plugins for KSP.  Was actually my first bit of plugin code for KSP, IIRC -- a multi-transform capable fixed solar panel module.

What irks me even more is that many of these modules could support multiple transforms/animations/etc with just some very minor edits, generally one-line type of changes, where they could still be 100% backwards compatible with existing uses.  Trying to convince SQUAD of that though has been a futile effort the few times I've tried.

Alternatively they could implement an actual API for these stock systems; e.g. an ISolarGenerator interface one could implement on their part-module.  External mods would then no longer look for the stock solar panel class, but could then interact with ANY module that implemented that interface, regardless of which mod it came from.  Of course, that would mean that someone at SQUAD actually understood and used one of the primary tenants of OO programming, which are most often lost on anyone targeting Unity ('what...? Class hierarchy.... that's what we did in high-school, right?').

...Perhaps I'm just a bit bitter after dealing with exactly these issues for years now, with little movement towards improvement

 

[Shadowmage]

17 hours ago, Joker58th said:

Or am I misunderstanding what this is for?

You and me both

I thought I understood what it was for / how it was supposed to function; but attempts to use it like that (e.g. how you are using it) simply don't work as you would expect.  So, unfortunately, I'm not really able to provide any tips or pointers on this -- it is a stock PartModule, and not my code, so I can't really tell what is going on under the hood.

Is anyone else out there familiar with the stock docking port module's 'angle snap' functionality?  Mind shedding some light on how it is supposed to work?

 

Edit:  You might try setting them to some value > 0.  I believe it means 'they should only attach on increments of X degrees', where 'zero degrees' is not a valid value (X / 0 = NAN).  So, something like 90 degrees on both ports, should allow them to only dock/attach at 90 degree increments.

Also, note, that with the welding docking port, you have to have both ports in the 'retract and arm' state before they will actually dock.  If either port is 'extended' there are colliders that keep them from docking (intentionally; to allow you to fine-tune orientation before permanently attaching things).

Edited July 9, 2019 by Shadowmage

[vossiewulf]

After seeing the mod process up close, my impression of this game is great idea, really poor implementation in most cases. I'm certain it could do well with a ground-up rewrite by developers experienced in building supportable, high-performance code, but there is no one to do that. Chances are that they don't make enough money to hire people like that, most of them are here in Silicon Valley where good new grads walk into 6 figure jobs. The fact is it's not one of those mindless "strategy" mobile games with 20 million players making in-app purchases every other day, they're aiming for a much smaller niche market and they built it as a traditional one-purchase game so the revenue stream is small other than from expansions, which themselves probably don't rake in huge bucks. 

I think they should opt for a free to play + premium subscription to generate better revenue, but someone would have to commit to making a viable "premium" version and they probably don't have the resources. I think the future of KSP is basically whatever modders can make out of it, the next KSP will probably come from elsewhere.

BTW, speaking of solar panels, why is the only selectable part of the SSTU panels the little attachment piece? If you forget to set an action for them, you better not be in a hurry to open them once flying.

[Joker58th]

2 hours ago, Shadowmage said:

it is a stock PartModule, and not my code, so I can't really tell what is going on under the hood.

Oh my apologies,  I thought that was your code.  Thanks for the clarification!  

2 hours ago, Shadowmage said:

Edit:  You might try setting them to some value > 0.  I believe it means 'they should only attach on increments of X degrees', where 'zero degrees' is not a valid value (X / 0 = NAN).  So, something like 90 degrees on both ports, should allow them to only dock/attach at 90 degree increments.

Thanks for the suggestions!  I fiddled with it for about 2 hours last night trying all kinds of values and angles.  The only thing that was consistent was that they had to be the same value or no magnetic attraction.  

2 hours ago, Shadowmage said:

Also, note, that with the welding docking port, you have to have both ports in the 'retract and arm' state before they will actually dock.  If either port is 'extended' there are colliders that keep them from docking (intentionally; to allow you to fine-tune orientation before permanently attaching things).

Yep!  That part worked flawlessly.  And may I also say I really like the animation of them retracting.  Very nice!  Almost makes me wish that all docking ports had that cool animation. 

[Shadowmage]

15 hours ago, vossiewulf said:

BTW, speaking of solar panels, why is the only selectable part of the SSTU panels the little attachment piece? If you forget to set an action for them, you better not be in a hurry to open them once flying.

Specifically because I always hated the stock solar panels with their colliders, always getting broken by... random kerbals?  sneezes?  looking at them sideways?  IDK, they always broke for me from the slightest brush of collision with anything, or sometimes nothing at all (break on being deployed, or on vessel reload).

So the SSTU solar panels simply don't have colliders on the panels.  The only way to destroy one is to destroy that little knob.  (note that they still have code that will destroy them from excessive aero forces; they are not deployable wings after all)

Is this the best way to fix the perceived problem?  Possibly not, but it was the fastest and easiest one I could implement (and also, at the time that module was written, in my early days of KSP modding, I did not have enough knowledge of Unity to properly handle destroying of just the panel meshes and persist that state across reloads). 

I've since learned how to handle such an issue (and collisions could be enabled in the current plugin easily enough) -- but now the problem is that the original models lack colliders.  Some of those solar panels have ~100 meshes that would need to have colliders generated, added to the model hierarchy, positioned, and then imported into unity and individually configured there as well; a massively time consuming project, at best.  This also brings up the issue of '100 colliders on a part' is simply bad for performance; terrible even when using primitives (cubes/spheres). 

To effectively add colliders to these parts I would have to get... creative.  Enable/disable the colliders as part of the animation to minimize the number needed, or have a single/few collider(s) that 'scales up' during deployment that covers the entire mesh (but is not animated accurately relative to the visible panels).

 

15 hours ago, vossiewulf said:

I'm certain it could do well with a ground-up rewrite by developers experienced in building supportable, high-performance code, but there is no one to do that.

Pretty much exactly that.  KSP was started by one guy (HarvesteR), working for what was at the time a marketing firm.  From what I understand he had little knowledge of coding when he started, so the years of 'best practice' knowledge I take for granted, would have been completely unknown to him at the time.  Not trying to be critical of his efforts or accomplishments, everyone is new at some time.

Fast forward a few years and the KSP codebase has grown substantially, but was never taken through the rewrite that it should have been once the original code deficiencies were realized.  Possibly they never were or have been realized -- the issues we encounter in the modding scene simply wouldn't exist in the base code interacting with itself -- they only manifest when trying to interface arbitrary mods with each other without using reflection or compile-time dependencies.

Not a problem specific to KSP either (or even game modding).  When I was doing Minecraft modding there were much of the same issues encountered regarding cross-modding interactions and layers-of-cruft style code.  I also see much of the same with some of the software that I maintain for my employer, layers of bad code covering up more layers of bad code; but as long as it 'functions', there is little motivation to spend the time to rework things.

[Starwaster]

@Joker58th @Shadowmage

angle 'snapping' works fine but there's another field that needs to be set which is captureMinRollDot - how close does it actually have to be to the snapOffset to be considered on target. Specifically it's the dot product between the two and by default it's set to -3.40282347E+38f so by default it's always successful. 

So to get this feature working you have to have these fields:

snapRotation = true
snapOffset = 90
captureMinRollDot = 0.9999984769

first one says (obviously) to use this feature. Second one is our snap angle (has to be 90 degree increments) and finally the captureMinRollDot which if I set that correctly means it has to be within 0.1 degrees. (obtained that value from another page that said to use the cos of 0.5 * radians and that seems to work out)

Optionally there's also

acquireMinRollDot
acquireTorqueRoll

As I understand it, acquireMinRollDot works the same way as captureMinRollDot except that it controls how much roll torque to exert to try to force the ports to roll to their snap points. Works similarly to acquireForce and acquireTorque which personally I hate both of those and my game is always patched to disable them so I don't do the dreaded docking port dance. The roll feature sounds nice and I think I could tolerate it except I haven't got around to trying it out but I believe it works as I described. I think I'll go find out now...

[Shadowmage]

On 7/10/2019 at 12:25 PM, Starwaster said:

angle 'snapping' works fine but there's another field that needs to be set which is captureMinRollDot

Ahh, indeed I do seem to remember having to play around with that a bit at some point, but never saw any documentation about what exactly it was supposed to do.  Your explanation makes sense, thanks .

@Joker58th  I've opened an issue ticket to track this problem and make sure it doesn't get forgotten about -- https://github.com/shadowmage45/SSTULabs/issues/796

I'll update that ticket with more information as things progress.

[Starwaster]

So uh, I'll just leave this here then... this... thing I did to the LC5

	MODULE
	{
		name = ModuleInventoryPart
		InventorySlots = 12
	}

Is that a little too much? Maybe... but the 1.25m part can hold 9 so I think it's ok.

(btw that's for the new Breaking Ground DLC.... adds deployable science inventory slots to the LC5 if you hadn't guessed)

[Shadowmage]

15 hours ago, Starwaster said:

So uh, I'll just leave this here then... this... thing I did to the LC5

	MODULE
	{
		name = ModuleInventoryPart
		InventorySlots = 12
	}

Is that a little too much? Maybe... but the 1.25m part can hold 9 so I think it's ok.

(btw that's for the new Breaking Ground DLC.... adds deployable science inventory slots to the LC5 if you hadn't guessed)

Interesting -- I haven't yet played around with the new DLC inventory, but it seems like a good addition for the crewed parts.  At least a couple of inventory slots on the standard pods, and a slightly higher number on the dedicated lander pods.

[Shadowmage]

Took some time over the weekend to do something I haven't done in ages... actually played some KSP.  Not just quick testing, but actually playing the game   Used a basic install; only QOL, graphics mods, and mods that I do development for (KF, TU, SSTU).  Other mods included Scatterer, MJ, EVE, KAC, MemGraph.  Very basic install.  Essentially 'stock' for most intents and purposes.

After progressing 3/4 the way through career mode, I am happy to say, that the only real issue I encountered with SSTU was, maybe, one of the MRCS blocks not persisting fuel selection properly (changed to MP in editor, did not work in flight).  Thankfully the other ship in that docking operation had functional RCS, so it had no real impact on the mission.

One thing that I did note from a balance perspective (aside from stock tech tree still makes no sense), is that SSTU does perhaps make career mode a slight bit easier with the configurable tanks and increased selection of engines.  Really need to do some side-by-side comparisons though to see how pure-stock craft line up.

The other note that I'm taking away from this session, is that perhaps some of the SSTU parts have been made a bit 'too' configurable.  The UIs on the tanks (especially the MUS) are a bit of a nightmare with all the various controls.  I'm really not sure any other way to do it though while still maintaining the same level of configuration and keeping a goal of 'low part count'; some sort of custom UI might be a viable alternative, but only if creating UIs in KSP was a simpler prospect.

 

I previously had a concern that perhaps some of SSTU wouldn't fit well beside the stock parts due to the mismatch in shaders, but at this point the stock parts are just as mixed up themselves, what with half of them using PBR and half not.  The color palette used on the newer/redone stock parts is also much closer to the SSTU coloring, so the whites/blacks are a much closer match and not quite as jarring as it used to be.  Overall I felt the stock pieces worked acceptably beside SSTU (or vice-versa);  not a perfect match, but not too visibly jarring either.

 

Overall I'm fairly happy with the experience of SSTU in career mode in its current version, for use alongside 'stock' mechanics.  No real surprises, and decent coverage of parts to use for stock game systems.  Possibly could use some SSTU-based ISRU stuff... but I'm going to have to play around with that a bit before I could decide -- I've never made use of the stock ISRU system, so have no basis for SSTU parts or functions.

Anyhow, this is the first of what I intend to be 'balance testing' play-sessions, with each group focusing on a specific mod environment for the purposes of developing integration patches for use with those mods.  My next play-session and mod-set (likely in a week or two) will likely be including a life-support/habitation system (most likely USI-LS) and possibly a couple of parts-mods that I'll be creating patches for.

Pics/mission logs/etc to follow later this evening.

[Cataclism]

And I am fairly happy that you´ve had at least a little time to spend on enjoying all the SSTU´s stuff we use to have fun in KSP! 

[Shadowmage]

As promised, a small collection of screenies.  Nothing too spectacular as far as craft design goes, just some rockets, landers, and an airplane.  No touchups or edits done, only graphical mods are TU, Scatterer, and EVE.

Early career orbital rocket; 2-stage (entire rocket shown).  Second launch of the career.  Stock coloring on the capsule closely matches the SSTU black, giving a fairly unified aesthetic:

First Mun-Flyby-Return probe (includes sample return canister For Science!) (is that Kerbin-shadow on the Mun? IDK):

Playing with the new deployables:

 

More stuff, mostly chronological..:

Example of my craft design process -- fairly plain and simple rocketry:

Dying-light shot of a minmus probe on its way out:

Extremely short-stop science-mining aircraft.  T/O = ~15m/s, can climb vertically, and can land on a postage stamp (stall + flop)

Heaviest launch of the career - secondary module for a station - fully fueled fuel depot segment (~40t)

I don't remember which launch this was, but the lifter uses an unusual triple-engine configuration.

Upper stage from something:

Last few seconds of a suicide-burn landing on minmus.  Basically the same lander design I used for the Mun (with additional solar panels and more science!); grossly over-engineered, and can almost biome-hop the entire planet with one fueling.

 

So.. yeah.... the above I think exemplifies why I don't include any example craft designs in SSTU.  Nothing is standardized, everything is purpose-built-for-mission, and there is nothing really surprising in any of my designs.  Certainly SSTU can be used to make more complicated craft; but are they really necessary? and would they serve as good 'example' craft?  I would personally answer 'no' to both.

[Joker58th]

It's nice to hear your feedback when playing through career.  In general I do like your approach of not stacking parts to make rockets look better and also reduce part count for physics/cpu issues.  I can understand why some might not as it also bypasses some of the early career part limitations which normally takes trade-offs and/or ingenuity to complete a mission.  There is some challenge there.

I have an idea.  Take your procedure tanks for example.  Is there a way to fool KSP in to thinking there are more parts in a single procedural part but only in the VAB/SPH?  Say based on the length of the tank, more parts would be added or removed and be reflected in and subject to the Engineers report limitations.  Once you go to launch, the part number would be the actual parts used.  This way, your parts would fit better into career and yet still be low part counts for cpu/physics reasons when flying.  Maybe tanks would be upgraded at certain levels so that as tech advances, fewer parts per tank are needed.  Possibly corresponding to where larger stock tanks are placed in the tech tree.

Another example would be the engines.  A single engine starts out as two parts, one for the engine and one for the mounting plate.  Each engine would add to the part count from there on but again, only in the VAB/SPH.

Maybe the part count for each procedural part would show up in the PAW as well.

Anyhow, just a high level idea without any knowledge if it can be done and if so, how much work involved.

[Joker58th]

Here are some screen shots of my latest career.

https://imgur.com/a/xq1OSM1

[Starwaster]

Cargo Lander with Lynx Rover. Ramp by Breaking Ground robotics. This was just a proof of concept that I cheated into orbit then put down with MJ. The engine is an RO scale LMDE that I further modded to allow CH4 and LH2 versions via RF's configurable engines.

Very carefully balanced. The ramp has a lot more mass than I expected. It's also too narrow and a bit flimsy but the rover can get down it. Sometimes. Sort of.

[Shadowmage]

15 hours ago, Starwaster said:

Cargo Lander with Lynx Rover. Ramp by Breaking Ground robotics. This was just a proof of concept that I cheated into orbit then put down with MJ. The engine is an RO scale LMDE that I further modded to allow CH4 and LH2 versions via RF's configurable engines.

Very carefully balanced. The ramp has a lot more mass than I expected. It's also too narrow and a bit flimsy but the rover can get down it. Sometimes. Sort of.

Just starting to really play around with the robotics parts myself.  Certainly some interesting prospects become viable that were difficult or impossible previously.

Now, to take that ramp, and add some further leaves to it; both length and width (and somehow balance it all).

 

16 hours ago, Joker58th said:

Is there a way to fool KSP in to thinking there are more parts in a single procedural part but only in the VAB/SPH?  Say based on the length of the tank, more parts would be added or removed and be reflected in and subject to the Engineers report limitations.  Once you go to launch, the part number would be the actual parts used.  This way, your parts would fit better into career and yet still be low part counts for cpu/physics reasons when flying.  Maybe tanks would be upgraded at certain levels so that as tech advances, fewer parts per tank are needed.  Possibly corresponding to where larger stock tanks are placed in the tech tree.

Another example would be the engines.  A single engine starts out as two parts, one for the engine and one for the mounting plate.  Each engine would add to the part count from there on but again, only in the VAB/SPH.

That would be the 'holy grail' of part-count reduction, something that I've termed 'dynamic part-welding' in the past, but is not really possible in KSP due to how some of the rest of the code is structured (expecting one rigidbody-per-part).  It would be exactly how I would do it if I were to write the parts system from scratch, but at this point I don't think it is really possible to retrofit such a system into the existing code.

Might still be workable to some extent, but it would mostly depend on how the stock KSP code treats parts (and rigidbodies) on collision -- there would need to be some method to 'split' the parts prior to collision handling for things that would cause explosions.  And I'm not sure where else in stock code that the PartModules (and/or flight-integrator?) might be expecting one-rigidbody-per-part.

Hmm... might be worth some further investigation at some point.  Really don't think it would work out, but if I could get it working, opens nearly limitless options for extreme craft design.  No more part-count limits due to joint-physics, and instead the upper bounds on FPS would be defined by the number of colliders in use and other KSP 'per-part' systems (aero, thermal).

[Starwaster]

@Shadowmage The main problem with the ramp as I implemented it is that I made it in two halves to avoid a single large piece pivoting around a single point. Not sure if that was good or bad. I still need to try implementing it that way and comparing it to see which is sturdier. And yeah definitely wider.

[Joker58th]

10 minutes ago, Shadowmage said:

That would be the 'holy grail' of part-count reduction, something that I've termed 'dynamic part-welding' in the past, but is not really possible in KSP due to how some of the rest of the code is structured (expecting one rigidbody-per-part).  It would be exactly how I would do it if I were to write the parts system from scratch, but at this point I don't think it is really possible to retrofit such a system into the existing code.

Might still be workable to some extent, but it would mostly depend on how the stock KSP code treats parts (and rigidbodies) on collision -- there would need to be some method to 'split' the parts prior to collision handling for things that would cause explosions.  And I'm not sure where else in stock code that the PartModules (and/or flight-integrator?) might be expecting one-rigidbody-per-part.

Hmm... might be worth some further investigation at some point.  Really don't think it would work out, but if I could get it working, opens nearly limitless options for extreme craft design.  No more part-count limits due to joint-physics, and instead the upper bounds on FPS would be defined by the number of colliders in use and other KSP 'per-part' systems (aero, thermal).

Uhhh...that went straight over my head... and it sounds like I wasn't very clear in my uneducated suggestion.  I'm not really talking about changing serious under the hood parts of the game to reduce part counts for better performance.  Actually I'm talking about adding pseudo part counts to an single part such as the MFT for career balance purposes.  So if you are limited to 30 parts in early career and you are not stacking, its kind of cheaty right?  So if you could somehow make KSP believe that each time you click the Core (maybe Upper and Lower too) to change the length of the tank, it would tack on another part but only while in the VAB.  Once you launch, the tank would behave as the single part it really is.  Does this make sense?  

[Shadowmage]

1 minute ago, Joker58th said:

So if you are limited to 30 parts in early career and you are not stacking, its kind of cheaty right?

I don't believe in the stock VAB part-count limits.  They make zero sense to me, and I would not intentionally handicap a player by artificially adding more parts.  I would be happier if that arbitrary and nonsensical limit were removed from career entirely, especially in stock where 'part stacking' is a mandatory thing.  Its almost like they want to actively punish you for trying to design a well functioning craft.

The mass and size constraints make more sense -- you have a limited size available in your VAB (and its doors/hoisting equipement), and your launch pad can only take so much weight / so large of a rocket.  But logically you should not be prevented from launching a rocket just because you made a fuel tank 2 meters longer (e.g. added a stacked tank, +1 part count), or add a bunch of science bits (+6 part count), but are otherwise still within all other size and weight limits.

[Starwaster]

38 minutes ago, Shadowmage said:

I don't believe in the stock VAB part-count limits.  They make zero sense to me, and I would not intentionally handicap a player by artificially adding more parts.  I would be happier if that arbitrary and nonsensical limit were removed from career entirely, especially in stock where 'part stacking' is a mandatory thing.  Its almost like they want to actively punish you for trying to design a well functioning craft.

The mass and size constraints make more sense -- you have a limited size available in your VAB (and its doors/hoisting equipement), and your launch pad can only take so much weight / so large of a rocket.  But logically you should not be prevented from launching a rocket just because you made a fuel tank 2 meters longer (e.g. added a stacked tank, +1 part count), or add a bunch of science bits (+6 part count), but are otherwise still within all other size and weight limits.

If you use Sarbian's Custom Barn Kit you can remove the VAB limits or customize them.

Install it and use this patch:

@CUSTOMBARNKIT:FINAL
{
	@VAB
	{
		@partCountLimit = -1, -1, -1
	}
}

No more part count limits. In any stage.

[Joker58th]

18 minutes ago, Shadowmage said:

I don't believe in the stock VAB part-count limits.  They make zero sense to me, and I would not intentionally handicap a player by artificially adding more parts.  I would be happier if that arbitrary and nonsensical limit were removed from career entirely, especially in stock where 'part stacking' is a mandatory thing.  Its almost like they want to actively punish you for trying to design a well functioning craft.

The mass and size constraints make more sense -- you have a limited size available in your VAB (and its doors/hoisting equipement), and your launch pad can only take so much weight / so large of a rocket.  But logically you should not be prevented from launching a rocket just because you made a fuel tank 2 meters longer (e.g. added a stacked tank, +1 part count), or add a bunch of science bits (+6 part count), but are otherwise still within all other size and weight limits.

And really, yes, this is the better option.  I will have to think more about this and what it would be like to not use part limits at all.  I think Custom Barn Kit allows this to be changed if I'm not mistaken.