From The Depths - Forum

Full Version: Proximity detonation that works (and an idea on how to implement it)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
So I, and probably plenty of other players would appreciate being able to have shells with a proximity trigger (AA comes to mind). Unfortunately, the current APS proxy fuse is basically worthless. It only works some of the time, and only looks in front of itself. In other words, it will only explode early if it was going to be a direct hit anyway.

I say all of this, but as a (admittedly beginner) programmer, I can understand the difficulty of testing proximity many times per second for god knows how many individual shells, and doing so without bringing the game to a grinding halt.

I do have a thought on how to do it, though. All we do is give shells with proxy triggers an invisible spherical* collision body, the radius of which being determined by the range setting of the fuse. If at any time (after the shell is armed) a block or missile intersects with the sphere, detonate the shell. No raycasting required. Only important bit is to make lasers and other shells ignore the collision body, and only affect the shell on a direct hit.

As for balance and justification in-universe, just say it's an active RADAR sensor, and consequentially make the shell very detectable, seeing as it is essentially shouting its location at all times.



*24 polys. Just subdivide/smooth a cube once, and you're done
That is a very intersting way of adding proxy fuses, that could also be used for missiles, because missile proxy fuse, is also about as reliable as piece of spaghetti
I see other fuse idea to counter close misses: approach speed fuse. This would check if shell's approach velocity to target within set distance went below certain threshold.
I am not certain how well that would fix the problem--FTD tends to lag badly whenever it has to drop into physics mode (e.g. collisions between ships, rather than the simple rectangular bounds-checking/gridcasting used for projectiles). I imagine that collision-checking a large volume of projectiles from a rapid-fire AA gun against a large ship would bring the game to its knees.
My idea is to find closest ship within (whatever range devs decide on) it triggers when approach velocity is lower than certain threshold like 10% of bullets speed
(2018-05-10, 09:02 PM)Blothorn Wrote: [ -> ]I am not certain how well that would fix the problem--FTD tends to lag badly whenever it has to drop into physics mode (e.g. collisions between ships, rather than the simple rectangular bounds-checking/gridcasting used for projectiles). I imagine that collision-checking a large volume of projectiles from a rapid-fire AA gun against a large ship would bring the game to its knees.

I admit I know next to nothing about such things, but I suspect the performance hit may not be as bad as you think. When ships collide, (I imagine) the game is having to calculate all of the damage and physics involved, which is, understandably, very resource intensive.

All that would happen with a proxy shell is that the game goes, "it seems that one or more blocks are clipping with my collision volume. Therefore, detonate." Plus, if there is a performance problem, the shell could always be size-restricted the way smoke rounds are.

Once more, however, I remind you that I admittedly do not know what I am talking about.
(2018-05-14, 03:48 AM)RychschaX Wrote: [ -> ]I admit I know next to nothing about such things, but I suspect the performance hit may not be as bad as you think. When ships collide, (I imagine) the game is having to calculate all of the damage and physics involved, which is, understandably, very resource intensive.

All that would happen with a proxy shell is that the game goes, "it seems that one or more blocks are clipping with my collision volume. Therefore, detonate." Plus, if there is a performance problem, the shell could always be size-restricted the way smoke rounds are.

Once more, however, I remind you that I admittedly do not know what I am talking about.

How do you find the closest block?
If you aren't doing that, will you iterate over every block that could possibly be in range for every shell on every fixedupdate step?

The game already has the easy optimizations in place, IIRC it's an AABB first round followed by gridcasts wherever needed.
Maybe adding a local coordinate BB step after AABB could help when long/thin ships are in play, but bridges/towers still cause lots of duds without block-level checks.
Don't remember exactly how proxy fuse cones are handled but it's very unlikely what you propose is better than the system already in place.


Just a note(and I might remember wrong), collision detection is the thing that causes most of the slowdown.
Calculating damage/forces/resolving overlaps isn't that resource-intensive.
Well, like I said, I don't really know what I'm talking about. Still, it seems (in my mind, at least) that this still would be less taxing than normal collision detection. We aren't concerning ourselves with which block is closest, and we don't need to concern ourselves with detecting anything after the first block.
I guess I sort of assumed that we could just use an ordinary convex collision body. I can't see any reason why this should be any more taxing than the method used to determine that a normal shell has hit a ship directly. The only difference is that we would be substituting a larger shape for the round's collision volume.
IIUC, FTD collision detection just checks for all the possible block/block collisions--Nick has repeatedly argued that merging collision bodies and then dynamically unmerging them upon partial destruction would be worse for performance. I suppose this does mean that a relatively simple collision body vs. a ship could be orders of magnitude faster than collisions between two large ships, though.

Notably, projectile/laser hits in FTD do not use collision detection at all--they use a bounds check and, if that passes, an optimized gridcast that exploits the grid alignment of blocks to identify which blocks are hit without any collision detection. (As I understand, it just uses simple geometry to identify the indices in the vehicle's grid that might be hit and then checks those in order, thus scaling with the target's linear dimensions rather than its block count.)
Approach speed method would not work for head-on collisions but would guarantee close miss detonation AFAIK
Pages: 1 2