SSTU - Shadow Space Technologies Unlimited

SSTU - Shadow Space Technologies Unlimited

98.5k Downloads

Modular Parts - Insanely crash resistant

shadowmage45 opened this issue ยท 7 comments

commented

Engines specify ~6m/s crash tolerance, but can easily take 40m/s+ without issue. Many of the modular parts seem nearly indestructible.

Relevant info:
This is a stock bug with anything that has multiple colliders; only the first collider in the model hierarchy will trigger collision handling; all further colliders will be ignored.

commented

Not really sure what is going on with this one. Will likely require implementing a debug script that listens for OnCollisionEnter and see exactly where/why the collisions are not triggering explosions properly.

commented

After quite a bit of research and digging...

There is a field in Part; specifically Part.collider (a -single- collider), and if this object is not set properly then the part will not detect collisions; even when set it will only detect collisions for that single collider.

If I add a debug module and pass the collision info to part.handleCollision it -does- properly handle the collision and explode as one would expect.

Even if this was working properly I think their implementation is extremely flawed as very few parts will have only a single collider. Need to do more investigation as there is no way that setup should even work for most stock parts.

Likely solution will just be to start adding additional collision handling capabilities to the modules that need them (all modular parts...).

commented

Okay... so... more investigation.

Take a stock cuppola module, attach launch clamps. Take it to max height in the VAB. Launch. Trigger claps and let it fall = explosion.

Take that same setup, but turn the module upside down, and you will get no explosion. Same impact velocity, same part; only a different collider on the part is involved in the collision.

The first non-trigger collider that is in the model hierarchy is the only collider that will trigger part->terrain or part-> part explosions; and -only- if that collider was present on the prefab part will it be properly seated into the part.collider reference field in order to trigger the collision handling.

So... really torn on how to handle this; there is obviously a bug in the stock implementation insomuch as that it only uses a single arbitrary collider from the model hierarchy.

Will likely open up a bug report on the squad tracker for now/in the near future and contemplate on how best to hack around it in the interim.

commented

Have added some code to re-seat the part.collider reference for modular parts in the same fashion as stock would have setup the collider in the first place.

Any further issues regarding indestructible parts is purely the stock bug and nothing that I should be responsible for fixing; if/when the stock bug is either fixed or confirmed to be 'functioning as intended', I will re-investigate if any further action is needed.

It -is- possible to properly handle collisions for all colliders in a part through a mod-added-module, but it is something that really should be handled in stock code rather than hacked around through mod code.

commented

I tested SSTU engines vs stock, and the SSTU engines all bounce on impact, but the stock ones don't.

commented

Read the rest of the comments/information I've posted here and you'll understand why.

Either way, I've 'fixed' it as best I can given the dumb stuff that is happening regarding how stock is handling them (again, read the rest of the info).

The 'fix' will be available with the next update; but keep in mind it -still- only uses a single (random) collider from the model; whether this is the largest one/main collider or not is completely out of my control. Will need the stock implementation to be fixed.

commented

Gotcha, I reread the descriptions and it made more sense.

On May 9, 2016, at 11:40 AM, shadowmage45 [email protected] wrote:

Read the rest of the comments/information I've posted here and you'll understand why.

Either way, I've 'fixed' it as best I can given the dumb stuff that is happening regarding how stock is handling them (again, read the rest of the info).

The 'fix' will be available with the next update; but keep in mind it -still- only uses a single (random) collider from the model; whether this is the largest one/main collider or not is completely out of my control. Will need the stock implementation to be fixed.

โ€”
You are receiving this because you commented.
Reply to this email directly or view it on GitHub #305 (comment)