Jey123456

you are not wrong on that side, i suppose it come down to realism versus utility at that point. With the new explosion code, if you want to blow a wall you either use a targeted charge (c4) or a bomb that is pretty powerfull. Not that it matters, the current github pull request does not enable the new explosion by default and it include a fix for the server deadlock on the current explosions as well.

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

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.

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)

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

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.

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.

that would be pretty cool to have it not burn the eyes

alright then, sorry, 9 clicks, or if you split the work in 2 and first place all your full window, thats 3 click per window. so for 30 window that 90 clicks, then 1 click to the remaining glass away, 2 click to take out screwdriver and crowbar. then click page up click for every window. For a total of 153 click and 30 page up for 30 window (thats a pretty decent room size). Assume one operation per second, thats still only 3minutes. I know what the rcd is for. But its not here to just plain simply replace actual construction operations.

uh reinforced window (i assume your refering to a grill + 4 reinforced glass applied all around ?) If you prepare your reinforced glass in advance (use autolathe or spam click a bit). Then its only 7 clicks including taking the rod and reinforced glass from your backpack. If you make larger window, its even faster since you only have to do the exterior lining. If you keep the rod and glass in your hands, then its only 5 click for each subsequent one, you can also do 3 window for a tile at the same time

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)

oh for toxin, how about simply making it increase on its own when in your body ? symbolising you becoming weaker from the poison, until critical / death if untreated. Could have the body be able to handle a small amount, but once past that treshold the toxin could simply start increasing slowly.

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

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)

im inclined to agree with that and in that spirit. how about adding a chance to be slowed the higher your toxin gets for toxin damage. as for burn, if in the hands it could make you drop whatever is in your hand once every x minutes, fall on the ground if its the leg etc, trouble breathing for the chest. Unlike broken hand / legs which are very frequent event (the falling / dropping), this would be more like a temporary loss of control due to the pain from the burn or whatever.

i think the target can see the codeword if they check their notes. but most people rarely do so. If only that, a rather visible and large message that you are a syndicate collaborator would help a lot.

yes, to some extent. I'm perfectly fine with how the rcd is now, its powerfull but has its restriction. What i disagree with is adding more options to the rcd, essentially making hand building useless (at which point, why bother with it at all ?)

the effect of brute damage should scale with how much damage the target has taken. I have not checked how its handled in code and i dont fight enough to know off my hand, but it would make sense for bone fracturing and internal damage to only occur once you took a lot of brute damage, not on the first few hits. Maybe also reduce brute damage itself when the target is not hurt, meaning that the damage would scale up the more you hit the target.

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.

i disagree. The rcd is a "cheat" tool, it should not be the goto tool for all construction.

i have no problems with giving a higher capacity RCD to the CE. On the other hand, i do think that adding to the RCD ability / portability would be a mistake. As it is right now, its already ideal for quick emergency repairs / construction, but for proper custom / reinforced works, it should require to be done by hand. RCD being smaller would also mean that it would not be written when put in the backpack anymore, which would stealing / hiding it even easier.

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 ?

Iv'e recently stumbled on paradise station. No clue why google felt it was a good match for the search "dedicated core vps" but it ended up being in the top list . I used to play space station 13, a lot a few years ago but had stopped after my ip was banned due to my friend playing on the same ip as me on a weekend and didnt feel like going trough the trouble of contesting the ban on forum (i was getting slightly bored as well so lets just say i lacked motivation ). Iv'e decided to give Paradise Station a try, and as of yet i was not disappointed so I'll likely stick around for a rather long period of time. Theres to hoping you guys can bear with my rather poor RP style (I try, very hard, I'm just not that good at it !)