The indestructible variable does not work as expected

[silencer-pl]

Testmerges

3088,#3271,#3284,#3303

Description of the bug

This variable seems not to work as expected, at least on structures and objects like it. Tried it on a crate and it was consistently destroyed by explosions of any type I threw at it. I strongly suspect some funny instance where this is only processed for specific object types or something, but I was not able to determine the cause myself.

What's the difference with what should have happened?

As it says in the description of the variable, I would expect that an item with indestructible set to 1 does not get destroyed by explosions. Currently it gets reduced to sheets of metal.

How do we reproduce this bug?

1.Place a crate. 2.Plant C4 on a nearby wall, throw a grenade, use the drop bomb command, drop an ob, blow yourself up, blow someone else up, the possibilities are endless. 3.See entropy in action.

Issue Bingo

• [X] Issue could be reproduced at least once
• [X] Issue happened in a recent (less than 7 days ago) round
• [X] Couldn't find an existing issue about this (https://github.com/cmss13-devs/cmss13/issues)

[Huffie56]

can confirmed this doesn't work as expected. changing var to true doesn't do anything and stuff that can't be destroy don't have is var TRUE.... their is also another var called breakable in the code seem very similar.

[Huffie56]

this seem to only work for structures?

[silencer-pl]

We already found the issue, its because the obj/structure does not consider the variable in its ex_act and even if it did, most of its child objects do not refer the parent ex_act anyway. There is an extremely good chance that making this all consistent will break something horribly. With some discussion it may be more prudent to create a separate object type for what I want, but I mean this can stay open for when someone with the strength to tackle it can.

This is part of a bigger issue where ex_act across object categories is all over the place in how it considers immunity to explosions, but thats over the scope of this issue.

[Drulikar]

Since I had already researched it some, for the 174 implementations of ex_act: /obj/structure/machinery/camera instead checks src.invuln /obj/structure/machinery/computer/ex_act instead checks exproof /obj/structure/machinery/door/ex_act instead checks unacidable /obj/structure/window/ex_act instead checks not_damageable /obj/structure/window/framed/ex_act instead checks not_damageable /obj/structure/machinery/computer/shuttle_control/ex_act instead checks unacidable /obj/structure/machinery/computer/teleporter_console/ex_act instead checks unacidable

/obj/structure/machinery/cm_vending/ex_act does check indestructible /obj/item/ex_act does check indestructible /obj/structure/ex_act does check indestructible /obj/effect/alien/weeds/ex_act does check indestructible /obj/structure/droppod/container/ex_act does check indestructible /obj/item/hardpoint/ex_act does check indestructible

Every other implementation is either not a obj so doesn't have that value at all, always ignores the explosion, or always takes into the account the explosion. So if anything the norm is to just override the ex_act for it to do what you want it to do for all of that type (or subtype). A major rework to standardize this would have significant implications and likely introduce a fair bit of bugs. But if you were to do so, you'd need to ensure everything that already has indestructible TRUE should since in most cases the variable had no effect.

[fira]

Yes it's a very old issue. We untangled a couple such cases in the past but the main ones remain. Unfortunately the ramifications of normalizing it are a bit hard to foresee due to varied usage.