new explosion code (screenshots added)

[Jey123456]

 

I'm currently in the process of porting some of my old code improvements over to the paradise branch.

 

I did not know where to post this, so feel free to move it if it does not belong here.

 

My first step is my old explosion code since paradise still seem to use the old default explosion and tend to freeze a lot when bombs of medium to large scale are used and mine can deal with bombs that blow the whole station in a matter of a few seconds to a minute (after that, it lag but thats because of other optimizations ill need to port after).

 

My code use an iterative approach with a separate "thread" (its not a thread, but its for all intent and purpose a background process), to calculate the explosion paths and damage, while at the same time actually applying the explosion in a shockwave fashion (from the center to the edge over a few frames, larger explosions obviously are spread over more frames). For a small bomb we are talking about 0.2 seconds before the explosion is completed, for a syndicate bomb scale its about 1 second.

 

This code does not generate identical explosions to the current explosion code, mostly because it tries to emulate how an explosion deal with walls at a low cpu cost (could be a lot more accurate, but for the purpose and limits of byond i kept it oversimplified). Suffice to say, walls actually divert most of the explosion damage if they are strong enough, most of the energy from the explosion will follow the path of least resistance and prefer straight line over turning. This mean blowing a bomb in a corridor will follow mostly that corridor unless its strong enough to destroy the walls or it can find a hole to escape.

 

I will add screenshots in a bit but i do have a question for the admins / community. Due to how my explosion code works, its near impossible to have the same definite "distinction" between heavy impact, light impact etc. Just like a "real" explosion, the damage smooth over with distance and objects encountered.

 

Do we want the explosions to generate similar amount of heavy impact bombs currently do (fully missing tiles) at the cost of much larger impacted area by ligher damage,

or

do we want the explosion to affect a similar area as currently, but at the cost of less intense heavy damage ?

 

Edited January 9, 2016 by Guest

[Fox McCloud]

 

If this is anything like recursive explosions, then, well...that wasn't very good. Recursives dramatically limit the impact of explosives and ended up making a lot of low power explosives do nothing at all (ie: C4 with recursive turned on was laughable).

 

 

I'd want to see the code myself and test it out, but the way explosions currently work is..they already factor in walls and other explosive blocking things (and cache that before performing the ex_act() on things); the vast majority of explosion code lag isn't from the ex_act()'s so much as the massive amount of Del() calls, as far as I remember.

 

[Jey123456]

 

recursive can be modified to obtain similar impact as the default explosion code, but its biggest problem is that on large explosion it spends more time on handling the stacks from the recursion than the explosion itself so the processing power available to actually do the explosion is pretty limited.

 

I use an iterative approach and the actual values are set to simulate the current amount of damage, it simply spread differently. I'm still tweaking it to my taste before i commit it and do a pull request, but once im happy with it, ill add comparative screenshots here.

 

As for the reason why the lag on the default explosion code happen in the delete, is because it reach a critical point in the byond engine, where adding more objects to the delete queue (internally on byond, the memory delete does not actually happen until the next sleep / idle) this cause each subsequent del call to take more and more time until you essentially deadlock, spending multiple seconds for every new object on which del is called. Adding some small sleeps to the default code "fix" the lag, but its not designed to be "rendered" until the proc is over, so you end up with rather weird looking explosion.

 

My code is designed with that very purpose in mind. It handle the explosion in steps, allowing byond to actually flush its delete queue (and gc as well) in between the cycles which result in a much faster all around explosion.

 

[Jey123456]

 

alright, sorry about the delay i had other work to take care off.

 

I finalized the explosion tweaks to be where i feel they should be, here are some screenshots. Feel free to comment its easy to tweak some more.

 

Its important to note that those explosion barely lag the server at all (there are some spikes during the explosion but nowhere near what you get with the default code) and for most of those lag spikes i have other optimizations i need to port that will fix them but i rather do it one thing at a time. Even during a station scale bomb (the kind that once its over there isnt much of the station left at all) you can still move around with a lag spikes of between 0.3 and 0.9sec randomly which most definitely beat the undetermined time freeze that currently occur.

 

Both systems share more or less similar destruction, but youll notice that in my code, explosions tend to react like they would in real life (grossly approximated offcourse). Most of the energy will generally take the path of least resistance, this also mean you can essentially focus a bomb using walls to have it explode in a specific direction.

 

It does have for effect that c4 explosions changed a bit when you plant them on a wall. Since they essentially explode in the hole left by the wall destruction (the c4 first destroy the wall, then explode as far as the game is concerned) it means that most of the energy will shoot out in a straight line out of the hole you just made. It also mean that most of the time youll be safer a tile to the side next to the c4, than 3 tiles away in the line of the blast.

 

I still need to add some fluff to it like flash fire, smoke etc. But all in all im pretty happy with the result. Here are some screenshots

 

C4 - notice how c4 in a wall will only blast in 2 straight line from the hole. C4 on the ground explode normally

 

admin verb drop-bomb using medium bomb in a corner made of reinforced wall. Bomb is dropped directly in the corner.

This one show very clearly what i mean when i say the current explosion code does not care much about walls. The walls themself absorb some explosion yes, but they do not change the shape of the explosion.

 

admin verb drop-bomb using bigbomb

 

code hard limit explosion size (its bigger than this, this one was still in progress, i just did not want to screenshot only empty space so i took it before it completed)

Cant do a compare screenshot on that one since the current code pretty much cannot handle a bomb of that size and just freeze for a very long time (unknown how long)

 

Edited January 9, 2016 by Guest

[pinatacolada]

ayy if this performs as well as you promise, this looks pretty damn nice

[Professor Cupcake]

I gotta chime in here that this looks really sweet. I'd love to see it in motion, though - any chance of a video and/or GIF?

[Jey123456]

 

i plan on posting the code on git very shortly (like in the hour probably), i just want to add the visual effects first. It look a whole lot better when theres fire following the shockwave and smoke settling down behind.

 

My old effect code was not reusable since it relied heavily on zas and we use linda

 

[Jey123456]

 

I gotta chime in here that this looks really sweet. I'd love to see it in motion, though - any chance of a video and/or GIF?

 

there just for you. Altho the effect is still broken and mistimed .

 

on the gigaboomgif one thats a unrealistically large boom so it has to be slow or it would lock the server (the amount of tiles to destroy is too big to do the whole circle in one cycle without bringing wtf intense lag with it) but i still prefer that over a server deadlock and well, other than admins noone can make a bomb of that size , biggest atmo bomb would at most big 4 times the "big" bomb, which while it would spike a bit, would not be too big a deal to handle.

 

Once my other optimizations are ported it can be a whole lot faster tho. Same with the lag spikes on the bigboomgif, those will disappear once my biggest optimizations are ported. but since this include a whole new garbage collector, automated process manager (basically code that manage all the code that is asynched using spawn allowing for priority control and stuff) and quite a lot of other smaller changes. This wont be today

 

bigboom

 

gigaboom (1000,1000,1000 bomb)

 

[Fox McCloud]

 

I'm really not terribly interested in going to anything remotely similar to recursive explosions--it's a gigantic nerf to explosions and results in extremely weird patterns when the bomb actually goes off---furthermore, we already have something that's *similar* to recursives, but isn't resources intensive----called "reactionary explosions" (Keep in mind, you have to have these turned on in the config).

 

I would definitely be interested in seeing what you've done to increase performance though; that is always welcome.

 

[Spacemanspark]

I think it looks really nice.

[Jey123456]

 

I'm really not terribly interested in going to anything remotely similar to recursive explosions--it's a gigantic nerf to explosions and results in extremely weird patterns when the bomb actually goes off---furthermore, we already have something that's *similar* to recursives, but isn't resources intensive----called "reactionary explosions" (Keep in mind, you have to have these turned on in the config).

 

I would definitely be interested in seeing what you've done to increase performance though; that is always welcome.

 

and yet, since i started playing on paradise, ive seen about 6 server freeze due to an explosion. The patterns of the explosion is actually more realist with my iterative explosion code, and as far as nerf is concerned, there are none. If anything theres slightly more damage caused by explosions with it in most situations.

 

[Fox McCloud]

 

and yet, since i started playing on paradise, ive seen about 6 server freeze due to an explosion. The patterns of the explosion is actually more realist with my iterative explosion code, and as far as nerf is concerned, there are none. If anything theres slightly more damage caused by explosions with it in most situations.

 

Explosion patterns being altered in such a way that they behave very similar to recursive explosions is a nerf, no matter how much you slice it--any long time player (who uses explosives) will tell you that recursive has an inferior/less predictable blast pattern than non-recursive.

 

Again, I have zero problems with optimizations to the code; I welcome them any day of the week, I'm just saying it would be better if they were slotted into our current explosion mechanics rather than making them iterate the way recurisve explosions did---again, our explosions already do factor walls and doors into play:

 

 

[Jey123456]

 

they do, they absorb the damage in that direction. But thats not how explosions works. Explosions are pressure wave, and pressure wave follow the path of least resistance. A wall does not only reduce the impact on that side, it reshape the explosion

 

As for predictability, its perfectly true that the recursive explosion was seemingly random and hard to predict, but its not the same algorithm that im using. The explosions my code do are predicteable.

 

As for improving the current explosion so that it does not cause the delete deadlock we currently get. It is not possible, the only way to prevent that is to split the explosion in multiple frame so that the byond engine flush its delete queue. But the default explosion look very very wrong when you spread it out on multiple frames.

 

[Jey123456]

 

there is now a pullrequest on the git for it. Without the config there should be no actual change to the code so its pretty safe to merge in.

 

Heres some gif of it with the effects.

 

this is a c4 explosion, altho in that gif the smoke was still a bit too long lasting on small bombs. This is reduced in the commit but the effect remain similar

 

the corner explosion in gif form with the effects

 

[scrubmcnoob]

I am fine with this as long as it does not eat all the server packets up.

[saywat_the_15th]

 

Looks like the new explosions have a more "clean" result. Current explosions rip walls and everythin down in a more wide radius.

 

Easier for engineering fix stuff.

 

I liek dis

 

[Jey123456]

 

Looks like the new explosions have a more "clean" result. Current explosions rip walls and everythin down in a more wide radius.

 

Easier for engineering fix stuff.

 

I liek dis

 

sadly Fox McCloud doesnt so its highly probable that well just get the slighly modified version of the current explosion code (tweaks that make it happen over multiple frames, which remove the case of multiple minutes long deadlocks from big explosions)

 

[tigercat2000]

It's a much higher probability that no change to explosions will go through.

[Jey123456]

that would make little sense considering the current code has caused at least 6 server freeze since i started playing not long ago. Altho if you test the current version on the git, youll see that it does not actually change much except that it allows for wtf large explosion to not kill the server.

[Plotron]

 

Looks like the new explosions have a more "clean" result. Current explosions rip walls and everythin down in a more wide radius.

 

In other words, bombs just became tactical.

 

[Jey123456]

 

Looks like the new explosions have a more "clean" result. Current explosions rip walls and everythin down in a more wide radius.

 

In other words, bombs just became tactical.

 

i wish since i also much prefer bombs that arent just a circle on the ground. but if anything is getting merged its likely only going to be similar fix for the deadlock on the current explosion pattern

 

[Professor Cupcake]

 

Looks like the new explosions have a more "clean" result. Current explosions rip walls and everythin down in a more wide radius.

 

In other words, bombs just became tactical.

HOOAH

 

[Shadeykins]

 

No.

 

Bombs are used in such a way in many circumstances that you want to breach walls with them.

 

If I place a bomb next to a reinforced wall, I am not trying to blow up all the tiles around it - I'm trying to blow through the reinforced wall.

 

"Oh no the HoP desk has been bombed!!!!"

 

"don't worry guise lol just the maint closet exploded"

 

"oh no nukies bombed the armoury!!"

 

"lol don't worry guise they just blew up some tiles in space lol"

 

[Professor Cupcake]

No.

 

Bombs are used in such a way in many circumstances that you want to breach walls with them.

 

If I place a bomb next to a reinforced wall, I am not trying to blow up all the tiles around it - I'm trying to blow through the reinforced wall.

 

That's... exactly what this new algorithm allows?

[Shadeykins]

 

No.

 

Bombs are used in such a way in many circumstances that you want to breach walls with them.

 

If I place a bomb next to a reinforced wall, I am not trying to blow up all the tiles around it - I'm trying to blow through the reinforced wall.

 

That's... exactly what this new algorithm allows?

 

Look at the gifs.

 

That's exactly what this new algorithm prevents.