Skip to content

Experimental Explosion Rework

Rob Nelson requested to merge pull/3600/Explosion-Rework into Bleeding-Edge

Created by: dylanstrategie

This modifies the way explosions behave by tweaking explosion spread to be progressive depending on what is in the way instead of simply cutting big circles and slapping ex_act on everything

Now added, is an explosion energy system. This uses the old dev/heavy/light system (which is still used to determine the potential of explosives) and turns it into a single value, the energy output of the bomb. This is directly determined via some arbitrary factors on the bomb potential and decays linearly with distance

Due to the glaring lack of any health in 95 % of ex_act()-able items, there's a LOT of arbitrary ex_act() actions, most of which are "if prob(severity) qdel()", which is supposed to simulate ex_act 1. Since energy stacks up very quickly with large bombs, this causes bombs to be FAR more destructive in their inner radius, and far less in their outer radius

And finally, I've made a lot of procs inherit their ex_act(). The main problem is that it would take me an ungodly amount of time adapting every last single gizmo to the new explosion system, so I'm trying to get it into a "it can work for now" state, in hope someone in the future will fix the individual items so that they can use this new explosion system correctly

This also does not seem to have added significant lag on explosion. Small explosions are still lagless, and huge explosions are still causing hangs (although this time, instead of freezing everything for 20+ seconds to delete half the station, it progresses in real time through each layer of tiles outwards)

Note that this pull request is HIGHLY experimental. The base change is functional (aka I tested explosions and they work about as intended) but it acts oddly in some fashions :

  • Due to the use of view() as a very simplified way of calculating penetration, transparent bomb-proof material, isn't. This notably includes windows in all cases. This has minimal impact with ex_act 1 since only walls can hope to stand in the way, and maximal impact with ex_act 3 since reinforced windows can shield it (and maximal impact on reinforced plasma windows in all cases)
  • Since the quality of ex_act procs is hit and miss, this can lead to some items being painfully hard to penetrate or damage, while others just yield too easily. This is still the case even after this massive fucking rework, so if you believe there's a way to improve a specific ex_act() proc, give me the word
  • If an explosion fails to destroy an object, it shields everything "behind it". While we all know 2D view procs can have wonky results with complex destruction patterns, this also allows one single "lucky" rwall or wall (prob() is used far too much in ex_act()) to casually shield everything behind it from ANY kind of following damage.
  • This could be done by changing ex_act output to output a raw, arbitrary "this is how much damage the explosion did" information based on how much ex_act stacks up and using that to see how much damage is done to objects (Done)
  • The explosive power doesn't actually deplete with penetration, it just stops the explosion completely in a certain direction if it fails to penetrate completely. I have no idea how to fix this in particular, since the current system tracks the explosion progress with "range rings", and cannot realistically modify how part of the explosion spreads depending on how much shit is in the way
  • As stated above, bombs most likely destroy a bit too much in the inner explosion radius and too little in the outer explosion radius, or at least damage progression is too quick between "cold hard vacuum" and "just a scratch". Though this coder does testing with 10/20/40 and such to check large-scale damage quickly so that might be that too

Miscalleanous changes :

  • Formatting
  • Change sleep(8) expression to spawn(). This delayed powernet and lightning rebuild, and while the intent is good, it FORCES the powernet and lighting process to freeze for 0.8 seconds for no good reason (which is especially bad with the Goon controller)
  • The above will most likely help to reduce lag during large, intense chained explosion events. This will most likely help during meteor waves notably since EVERY SINGLE METEOR EXPLOSION stopped lighting and power rebuilding for .8 seconds, over and over again. Not suggesting anything
  • A literal hundred of files skimmed through to change their ex_act() procs, which certainly can't cause conflicts or block fucking everything, no sir !

Discuss below. Mostly concerns what should be changed, and any code suggestions

Merge request reports