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

[Shadowmage]

7 minutes ago, tater said:

I did a version of your experiment with the cupola on my laptop at lunch (mk1-2/medium tank/cupola). It blew up. Tried it with both directions. I did the same with stock engines upside down. Blew up. Tried the stock cupola alone. It blew up.

Your engines bounce.

I'm not seeing it stock. 

Strange, as I was able to duplicate the problem on my install with many stock parts; any of them that had multiple colliders.  Will do some more investigate when I have time on a bit more of a stock-only install (my dev setup has KJR + various other SSTU dependency/integration mods for testing purposes).

Either way, this problem is -still- caused by the stock bug of only using a single collider per-part, and -only- if that collider was present on the part during prefab construction.  That problem -needs- to be solved in stock; and I will not be 'fixing' it any further until the stock bug is cleaned up.

Edited May 9, 2016 by Shadowmage

[tater]

Cupola (glass down or up) blows up in impact at 28 m/s, stock (drop from highest clamp)

I had KJR as well, so I yanked the folder and the cupola still blows up for me.

 

So what collider is it using that is indestructible? In general, KSP is too forgiving on impact anyway, IMO, so is the fix t set the colliders lower in impact resistance on parts like tanks, engines, etc?

The LEM engine bell typically ended up maybe 10-20cm off the lunar surface. In at least one case, overpressure from the engine operating near the surface for a second actually damaged the engine bell. Landings of the LEM were very gentle by KSP standards...

Maybe the engines need all colliders set way lower than 6.

[tater]

For the cupola, it need to hit the pad at over 17 m/s. I got a blow up at 17.9 m/s, and low 17 was OK... hard nail exactly.

Stock engine does as well at this much shorter drop.

Tried SSTU engines. Bounce.

Tried apollo orbital version on the nose... it blew up! On the bottom, it blew up.

MUS-CB, bounced at this lower drop (~18 m/s), and also at closer to 30 m/s.

Same with the large tanks, they bounce.

It is not all parts, just those where the shape transforms?

Edited May 9, 2016 by tater

[Shadowmage]

5 minutes ago, tater said:

Cupola (glass down or up) blows up in impact at 28 m/s, stock (drop from highest clamp)

I had KJR as well, so I yanked the folder and the cupola still blows up for me.

 

So what collider is it using that is indestructible? In general, KSP is too forgiving on impact anyway, IMO, so is the fix t set the colliders lower in impact resistance on parts like tanks, engines, etc?

The LEM engine bell typically ended up maybe 10-20cm off the lunar surface. In at least one case, overpressure from the engine operating near the surface for a second actually damaged the engine bell. Landings of the LEM were very gentle by KSP standards...

Maybe the engines need all colliders set way lower than 6.

Are you using 1.1.2/latest (this is a recent change that was not present in 1.05, did not check any of the other pre-releases, though it seems it was added in for a 'fix' to wheel issues in a recent release)?  Also note the cuppola needs to drop -straight- on its top; if it comes down at even a slight angle then the bottom cylindrical collider will hit the pad and trigger the explosion.  Also try using -just- the cuppola module; other parts may interfere with the testing.

What collider is indestructible -- any collider that is not set to the part.collider field; it only supports collisions for a single collider, and only if that collider was present on the prefab part.  As my modular parts are all setup in the editor, there is no collider on the prefab part, and as such they don't even have that single collider that will trigger explosions.

No, the impact resistance field does not effect this issue; setting it to 0.001 will not change the fact that the collisions are simply not being handled by the part.  In order for the impact resistance to matter the collision must first be passed to the part.handleCollision() method (which is where it checks impact velocity).  Sadly for these parts the part.checkCollision() method is returning false; meaning it does not think it needs to handle the collision.  As near as I can tell this is caused by it only checking for collisions vs. a single collider; the collider that is set in the part.collider field; any other colliders are ignored/rejected in the part.checkCollision method.  This is stock code that I cannot change.  Until that bit of code is fixed I'm afraid the modular parts will be indestructible.

I'll do more testing on the cuppola/stock parts when I get home tonight.  When I was testing it on Friday/Saturday though I could drop the cuppola on its bottom and it would explode; but if I dropped it from the same height onto its top it did not explode.  When I added a debug module that monitored the explosions (to tell me what collider/impact velocity), I could tell that the collision -was- occurring, but the part was rejecting it for internal handling.

So basically, to fix this issue, one of two things need to happen to the stock code (preferably both...):
1.)  Remove the single-collider restriction.
2.)  Do not rely on the prefab part to have colliders on it; set the part.collider field from the part once it is active in the flight scene.

3 minutes ago, tater said:

For the cupola, it need to hit the pad at over 17 m/s. I got a blow up at 17.9 m/s, and low 17 was OK... hard nail exactly.

Stock engine does as well at this much shorter drop.

Tried SSTU engines. Bounce.

Tried apollo orbital version on the nose... it blew up! On the bottom, it blew up.

MUS-CB, bounced at this lower drop (~18 m/s), and also at closer to 30 m/s.

Same with the large tanks, they bounce.

It is not all parts, just those where the shape transforms?

No its not all parts; its only the modular parts, because the stock code does not setup their colliders properly.  Even if it did, it would still only respond to collisions with that single collider that is referenced via the part.collider field.

The command pods are setup mostly like normal parts; thus the stock code sets up their collider (mostly) properly.  They also only use a single collider; so there is not really any chance for problems.

 

Anyway, you are arguing a moot point.  It is a known issue, and it is already fixed in dev code (or at least as fixed as I will be able to get it given the silly stock stuff going on)(will be available whenever I post the next update); any further fixes will need to come from stock code.

[tater]

Gotcha, had it loaded up, so I figured I would test. On the cupola tests I set SAS on so it would stay as level as possible. I'm pretty sure my KSP and SSTU are the latest. I have SSTU-0.4.31.108.

Not really arguing, just trying to "get" what is going on.

Edited May 9, 2016 by tater

[Shadowmage]

2 minutes ago, tater said:

Gotcha, had it loaded up, so I figured I would test. On the cupola tests I set SAS on so it would stay as level as possible. I'm pretty sure my KSP and SSTU are the latest. I have SSTU-0.4.31.108.

Not really arguing, just trying to "get" what is going on.

No problem;

The most basic explanation is:  "Stock code has fubar'd collision handling so that it only uses a single random/arbitrary collider from each part to determine if it should explode, ignoring other colliders;  additionally it does not handle modular parts properly and does not use -any- colliders from them to determine explosions."

So really its a manifestation of a combination of two (closely related) problems with stock code that would rarely/if ever be seen on stock parts due to their simplicity.  This is all code that was added/changed in the 1.1+ updates as this problem did not exist in 1.05;  in 1.05 ALL colliders properly triggered explosions, which is how it -should- still be (and needs to be).  (Really, this is not a problem that I should need to fix, or deal with, or even hear about; it is a problem with the stock implementation of colliders and needs to be fixed on their end; so if I sound frustrated... that is why... it is not my problem to fix).

I'll still do some more investigation this evening to see if I can duplicate your results with the cuppola, provide some screenshots to show how the colliders are set up for many stock parts, and provide the logs/debug output to show how it is simply not handling collisions at all for colliders that are not the single collider that it is expecting.

 

In other more positive and far less frustrating news, I think I'm working towards some decent 'tutorial' images for the modular parts (... just the fuel tanks so far);  very much a WIP -- have posted the album rather than specific images as I'll likely be updating the images more throughout the day.  Will likely make up a similar set for the Modular SRBs and Engine Clusters tailored to their customization options.   Yes, the lighting is a bit off between the nosecones/tanks/adapters -- I'll likely have to setup a more consistent lighting environment in the various files and re-render them all before I'm done.  Will also be adding cropped screenshots of the part right-click menus with callouts/information on what each option does, and linking those in with the images below for a bit more of a comprehensive setup guide.

Have contemplated trying to set these up as KSPedia pages, and may still do so in the future; having them accessible in-game from the built-in help system is probably a good idea

 

[The-Bean]

 

The sheer amount of options in this mod is amazing. And even better it looks amazing, no matter the design.

Built this monstrosity earlier. Would have built it taller if not for the VAB height limit:

https://i.imgur.com/0lMzcv2.jpg

https://i.imgur.com/mDBKoW1.jpg

EDIT: VAB height removed with the Hangar Extender mod: 

https://i.imgur.com/Zvyym5r.jpg

https://i.imgur.com/DMeAFWb.jpg

280 tons to LKO using 64k. Reusable first stage w/ 9 F1B engines. Landing it is tough, but fun, with FAR tearing it apart XD.

Edited May 10, 2016 by The-Bean

[Jeb-head-mug kerman]

This is exactly what i wanted!

[Shadowmage]

Okay, so, tons more investigation into the collider issues last night.

The fact of the matter is precisely as I had stated yesterday; stock only responds to collisions for each part for a single collider for that part.  This is the collider that is referenced in the part.collider field.  With higher impact velocities you will often see 'punch through' for other (non-exploding) colliders where the part.collider will still make contact and register an explosion.

But, at the range of velocity below that needed for punch-through, these parts will simply not explode if they collide using the collider(s) that are not referenced in the part.collider field.  This is why the cuppola will -sometimes- explode at >~17 ms/; the 'base collider' will still impact the launch pad.  Below ~17m/s only the top collider is involved and you can easily see that it is -not- triggering an explosion properly.  If none of this makes sense, please go read up on video game physics engines to see how velocity is integrated and how collision checks are done (hint: it is because of discrete update 'ticks' or 'frames'); it -will- make sense when you are done learning.

This can only be seen on a handfull of stock parts; all other parts have only a single collider:

• Cuppola; this is the only one with a low enough impact velocity that it actually matters in-play; all others have a high enough impact velocity that they will always 'punch-through' and have their part.collider trigger explosions
• Mk3 cockpit -- the top window area on the cockpit will not trigger explosions (50m/s impact tolerance; punch through always occurs at these speeds and it will still explode)
• Mk2 Cargo Bays -- doors will not trigger explosions (50m/s impact tolerance; punch through always occurs at these speeds and it will still explode)
• Mk3 Cargo Bays -- doors will not trigger explosions (50m/s impact tolerance; punch through always occurs at these speeds and it will still explode)
• Service Modules -- doors will not trigger explosions (high impact tolerance; punch through always occurs at these speeds and it will still explode)

 

As you can see the cuppola impacts the pad but does not explode at ~32m/s impact speed as long as it lands on the top.

Now, this does not happen 100% of the time; this is due to a complex interaction of velocities, impact speed, and the precise physics update sequence.  Sometimes the 'base' collider for the cuppola will still impact the pad and trigger the explosion (known as punch though; well technically the top collider is punching through...).  But -- if only the top collider is involved it will -not explode-.

 

[LOG 17:40:23.891] On Collision Enter for part: cupola
[LOG 17:40:23.892] part.collider = collider_base (UnityEngine.MeshCollider)
[LOG 17:40:23.892] Collider Hit: Launch Pad (UnityEngine.MeshCollider)
[LOG 17:40:23.893] Contact  Colliders: collider_top (UnityEngine.MeshCollider) :: Launch Pad (UnityEngine.MeshCollider)
[LOG 17:40:23.893] Collision speed 16.02857
[LOG 17:40:23.894] Part check collision: False

The 'important' part of that log is the last line -- 'Part check collision: False' line;  this means that I manually passed the collision data to the part and it rejected it as 'not colliding' (or at least should not trigger an explosion) even though the impact velocity is obviously higher than the parts crash tolerance rating.  Note how the cuppola collider involved in the contact point info is not the collider in the part.collider reference.  THIS is the root of the problem.  If I manually pass the collision data to part.handleCollision (bypassing the part.checkCollision() method) the part will properly explode; this is how I know that the issue is in the part.checkCollision method, and that it is for some reason rejecting valid collisions.

 

Now, as a workaround, I have added a generic collision handler to SSTU parts that will properly trigger a collision/explosion regardless of what collider is involved.  However, please not that this is a stock problem with their implementation of collisions and only allowing a single collider for any part to trigger explosions, and that this solution is a hacky workaround at best.  Until the issue is fixed in stock there may well be some... oddities... involved.  Nothing further that I can do about it;  please post any additional relevant information you may have to the stock bug report on the issue:  http://bugs.kerbalspaceprogram.com/issues/9695#change-44017

[Shadowmage]

Updated testing release is available:

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

A few bug-fixes (such as collision handling) as well as cleaning up the AVC stuff (it works now..), updated TWR on the Merlin engines; see the link for change-log and downloads.  AVC and Github have both been updated with the latest relevant information for each.

[GoldForest]

@Shadowmage I don't know if this has been asked before or not, but any plan to add multiple nodes to the mounts for the fuel tanks? I would love to stick five 9-clustered Merlin engines on a Saturn V mount.

[blowfish]

@GoldForest All the engines are surface attachable.  I think that would cover your use case.  Trying to add unique node setups to all the mounts in addition to everything they already have would probably be excessive.

Edited May 11, 2016 by blowfish

[GoldForest]

14 minutes ago, blowfish said:

@GoldForest All the engines are surface attachable.  I think that would cover your use case.  Trying to add unique node setups to all the mounts in addition to everything they already have would probably be excessive.

I know, but due to the colliders, it's kind of difficult to place the engines in the right place.

[blowfish]

Just now, GoldForest said:

I know, but due to the colliders, it's kind of difficult to place the engines in the right place.

Just offset them?  That's always worked for me.

[GoldForest]

Just now, blowfish said:

Just offset them?  That's always worked for me.

Oh yeah, I keep forgetting about that tool lol.

[Mate_fin]

So I got tired of RSS/RO due to all the problems I had (probably just my fault) but I love this mod. So is there a stock configs one or do these work fine in stock already without overkill?

[Jimbodiah]

Work fine in stock. But if you make life-like scaled rockets they are overkill. A Saturn V can take you to basically any planet.

You could run Kerbin 365, which is a Kepernicus mod that scales up the planets (4.2x) and distances (6.4x) so that real-scaled rockets actually do what they originally did. You need about 2.5x the dV for every burn. I quite like this scale and still works with stock part settings with exception to ablators (make a 2x patch and you are done), so no need for endless .cfg tuning or RO hassles.

Edited May 11, 2016 by Jimbodiah

[Shadowmage]

1 minute ago, Mate_fin said:

So I got tired of RSS/RO due to all the problems I had (probably just my fault) but I love this mod. So is there a stock configs one or do these work fine in stock already without overkill?

1.)  The RO Patches for SSTU have not been updated for 1.1+ yet; so trying to use this mod in RO is likely an exercise in frustration and not going to end well.

2.)  Yep, this mod is fully intended to be used in a stock-scaled solar system (in fact, I do not support RO/RSS).  Simply install it, and you should be good to go.  FAR is not recommended and may actually cause problems for a few parts, as the FAR patches have not been updated for 1.1 (mostly these just adjusted center of mass).

 

However as Jimbodiah points out, trying to use a replica rocket in the stock solar system -is- overkill; there is nothing reasonable I can do about it, it is caused by the size of Kerbin and the low orbital speed.  However it works fine if you design KSP lego-rockets.

[Mate_fin]

7 minutes ago, Shadowmage said:

1.)  The RO Patches for SSTU have not been updated for 1.1+ yet; so trying to use this mod in RO is likely an exercise in frustration and not going to end well.

2.)  Yep, this mod is fully intended to be used in a stock-scaled solar system (in fact, I do not support RO/RSS).  Simply install it, and you should be good to go.  FAR is not recommended and may actually cause problems for a few parts, as the FAR patches have not been updated for 1.1 (mostly these just adjusted center of mass).

 

However as Jimbodiah points out, trying to use a replica rocket in the stock solar system -is- overkill; there is nothing reasonable I can do about it, it is caused by the size of Kerbin and the low orbital speed.  However it works fine if you design KSP lego-rockets.

ok that is a relief to know this mod works in stock *clicks download repeatedly* 

[Jimbodiah]

19 minutes ago, Shadowmage said:

there is nothing reasonable I can do about it, it is caused by the size of Kerbin and the low orbital speed.  However it works fine if you design KSP lego-rockets.

You can still make reasonably looking rockets, just not the same proportions as the real ones. Using LH2 instead of LFO also increases tank sizes, so ships look pretty realistic. It's not THAT bad.

You could ofcourse add 30 tons of ore to the payload so you need more fuel/thrust, haha.

[CobaltWolf]

There's also a lot of system rescale mods out there. Not full RSS but there's like 3x rescale, etc to keep stock balance but make the player's rockets less OP. IMO it's easier than trying to scale rocket parts down.

[Shadowmage]

General development update:

Spent a few hours last night (okay.. so most of the evening) figuring out the KSPedia setup process.  Quite a convoluted, painful, illogical, and inefficient process.  But at the end of it all I had a few new blank pages displaying in the KSPedia.

Now I just need to come up with the content for them.  Current intent is to use the promo/tutorial stuff that I had posted earlier in the week (cleaned up of course) for several of the pages.  Will have brief tutorials explaining the functions of the MFT/MUS tanks, engine clusters, and a few of the other modular parts.  A few pages will be dedicated to details for the ship-core parts, lander-core parts, and other XXX-core stuff as it becomes available (station, base, probe, rover).

How detailed should I get with some of this information?  For example, should I create a separate page for each engine detailing its stats and intended purpose, or just leave that up to the currently available in-editor part tooltip info?  How much data is needed regarding the ShipCore parts?

Anything else you guys would like to see added in for tutorials or informational pages?

Should (hopefully) have the first of these pages available with this weekends' update.

 

On the subject of upcoming updates:

I'm hoping that this weekends' update will mark the transition into the 'public stable' release branch.  The number of bug reports coming in is pretty low, and they are mostly cosmetic or interface enhancement bugs, so I feel that the mod is in a pretty good state currently.  The balance is mostly where I would like it;  I might take another look at the ShipCore part stats (mass/delta-v) and make them a bit more 'sane' for stock setups... but honestly any large changes there would merely diverge them further from 'scaled stats' (e.g. you would end up with huge and heavy parts with very little fuel in them);  they are pretty good at their 40% mass scaling factor, though of course they seem overpowered compared to the massively overweight stock parts (srsly, why does the mk1-2 pod have a mass > 4t ? did they use lead for the bulkheads?).

If/when I switch over to the 'stable' releases I'll start up a second branch on the repository for the future dev/testing/pre-release builds and will start using the save-upgrade-process to hopefully maintain compatibility with prior 'stable' builds whenever possible (sometimes things will still get broken, but should be much less often).

For a few weeks after the initial stable release is available I'll be doing maintenance and bug-fixing only;  I've got a bit of a project on my hands regarding creating a new wheel collider component which I expect may take a few weeks/month or so before it is even usable.  Have been putting it off for a couple weeks now so that I could wrap things up with SSTU, but need to start working on it in earnest.

[Drakenex]

Do you plan to add the umbilical port to the Orion capsule?

 

 

Just a suggestion, don't be mad! thanks!

[Shadowmage]

13 minutes ago, Drakenex said:

Do you plan to add the umbilical port to the Orion capsule?

 

Just a suggestion, don't be mad! thanks!

Nope; in fact I had it on earlier versions models (from KSP 0.90->~1.02) and removed it.  It renders the models visually incompatible with any other use; and as the parts are intended to be compatible for generic use (e.g. build your own service module, or use the service module as a supply delivery vehicle, or use the capsule for other purposes/other launch vehicles), I saw the umbilicals as a 'bad thing'.

Edited May 11, 2016 by Shadowmage

[Drakenex]

1 minute ago, Shadowmage said:

Nope; in fact I had it on earlier versions models (from KSP 0.90->~1.02) and removed it.  It renders the models visually incompatible with any other use; and as the parts are intended to be compatible for generic use (e.g. build your own service module, or use the service module as a supply delivery vehicle, or use the capsule for other purposes/other launch vehicles), I saw the umbilicals as a 'bad thing'.

Ok! comprende. Thanks for the quick response!