Script_PartialRadiusDamage (bricks block explosion damage)

[Rally]

https://leopard.hosting/dl/fzbxw/Script_PartialRadiusDamage.zip

This is a remake of Script_ObstructRadiusDamage that tries to add some extra functionality, like support for vehicles, greater accuracy (checks procedurally up the player's vertical axis as opposed to checking 3 fixed positions), damage based on how much you are in cover as opposed to whether or not you are in cover, and also checking the corners of the player's bounding box as opposed to just the center of their player.

Has some prefs:
$Pref::ORD::PlayerCheckAccuracy
When the system is checking for player visibility it'll start at the feet and move upward overtime until it has reached the top of the player's bounding box. By default it will move up 0.35 units each check.

$Pref::ORD::VehicleCheckAccuracy
Same as above, but for vehicles. The default is 0.5.

$Pref::ORD::AccuracyMode
This refers to which corners/axes the system will check, if it's set to 1 it'll just check the player's center of mass, if it's set to 2 it'll check two opposite corners of the player's bounding box, if set to 4 it'll check every corner, and if set to 5 it'll check every corner and the center. Set to 2 by default, the greater this number is the more costly the calculation (but also more accurate the calculation).

$Pref::ORD::Binary
This restores Script_ObstructRadiusDamage's old functionality, as in, if it detects that the player can be seen from the explosion position, it'll just parent the normal radiusdamage functionality instead of calculating a percentage. Set to false by default.

Sort've a WIP that I'm working on for my explosives add-on, I still want to go through and clean it up and optimize stuff, but it's in a working state so I figured I'd just release it anyway

[Ad Bot]

[thegoodperry]

why would you while loop just to find the point when you already know the points location? the player/vehicle's bounding box returns a scale relative to the center point, just take the scale and the transform and calculate the 3 points and use that to check if the bounding box is visible to the explosion.

Running a while loop like that probably takes an extra fraction of a millisecond but if you have a ton of explosions it'll definitely compound. Its just inefficient when you can run an if or statement on the 3 points. Also a container search is apparently somewhat intensive on its own, im sure using just a regular raycast line to check if the ray between the explosion center and the 3 points is obstructed would be much faster

since its a partial explosion you can just have the number of visible points determine how much damage is negated. it'll return rounded values like 0.5 and 1 but im sure checking what percentage of the player is being blocked exactly isn't really necessary in any scenario

[Rally]

One thing I had a lot of trouble with was determining the height of a vehicle's actual bounding box. I can do it pretty easily with Player objects thanks to Player::getHackPosition but since that function doesn't actually exist for vehicles it posed an issue, meaning that I didn't actually know where the top point of the vehicle was, hence the while loop

using the same method for players is a little less justifiable since I can actually get the height and do a for loop for however many points I want, I really just didn't want to use the 3 fixed points lol

[thegoodperry]

forget i forgot getHackPosition was player only. oh well

still whenever you can you should avoid container searches and while loops that run a lot of routines. most players already get bad performance with over 30 explosions, running while loops and container searches on each explosion will lower performance even more. if i were you i'd optimize the player search one using the 3 point system at least, because most explosions are used with weapons and are used against players.

[Conan]

as long as you just fire raycasts and do math and dont do things like generate projectiles, the game can actually do a stuff ton of those pretty quickly with little lag. worst comes to worst, he can add an upper limit to the scaling and have some safety getRealTime() checks to make sure the game isnt hanging too long, but from my experience unless over 20-30 people are being hit by the same explosion i dont think its going to be a problem.

[thegoodperry]

yeah he added a sentinel into the code at 500ms

[Rally]

I tested it on my server with around 64 bots all being killed by the same explosion, and I didn't seem to have any noticeable drops in performance save for what seemed like some choppy, uh, position updates? as the corpses flew away.

Though I do have vsync enabled and a pretty stable FPS of 60, so someone who has a resting FPS of 60 or lower might notice it much more than I do.