Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

C4 distance indicator not correct #1730

Open
Crashington opened this issue Jan 20, 2025 · 18 comments
Open

C4 distance indicator not correct #1730

Crashington opened this issue Jan 20, 2025 · 18 comments

Comments

@Crashington
Copy link

  • Workshop version from Steam

Describe the bug (mandatory)

The indicator that appears when looking at C4 (the indicator that team members can see through walls) does not accurately reflect the kill, damage and no hurt zones of C4. players will survive standing within the "kill distance" taking anywhere from close to lethal (but not lethal) or no damage at all.

To reproduce

Steps to reproduce the behaviour:

  1. Plant a C4
  2. Stand near where "Kill Distance" changes to "Damage Distance"
  3. Wait for the C4 to explode and check the damage dealt

Expected behaviour

As long as the inidcator says "Kill distance" in red, it should actually kill the player.

@TimGoll
Copy link
Member

TimGoll commented Jan 21, 2025

I think I noticed this as well. Probably because the explosion is not as deterministic as I thought

@Crashington
Copy link
Author

Crashington commented Jan 21, 2025

maybe it could be changed from "kill distance" to "sure kill distance" or something, and get the inner bounds of that range variation? and then instead of hurt distance it becomes "possible hurt distance" or something

@TimGoll
Copy link
Member

TimGoll commented Jan 21, 2025

Maybe. When I do the C4 rework, I will look into that as well

@MrXonte
Copy link
Contributor

MrXonte commented Jan 22, 2025

from a quick look at the warning, there is no LoS check in there
Within LoS we do util.BlastDamage in a 1000 unit radius (although i cant find any reference how util.BlastDamage calculates its damage)
Regardless of LoS we also do SphereDamage in a 750 unit radius

Unless i made a grave mistake somewhere, that means we are lethal within LoS for muuuuch further than out of LoS, while the check only checks hard distances. From the warning code we have the following states based on distance:

  • 1000 (>outerRadius): Safe
  • 1000 to 750 (outerRadius to innerRadius): Damage Zone. Only true if we are in LoS
  • <750 (<innerRadius): Kill Zone. Now if i did my math right, that's actually not the case. The calculation for SphereDamage uses absolute numbers (instead of a linear or exponential scaling with a surekill radius) and somehow that means we have a space of about 150 units where we do no/negative damage. This also means that parsing radius to the spheredamage is technically meaningless, the radius is only used to save on damage calculations, but has no impact on damage scaling whatsoever. Currently a kill is only guaranteed below the hardcoded limit of 490 units without a LoS check and a hardcoded falloff of 0.01 * d² after that.
    Image

So we either need to include a LoS check, or have uniform damage distances for LoS and no LoS.

And while Im at it, since radius is meaningless to SphereDamage damage falloff this also means that reducing inner radius here really only makes it a smaller instakill radius without falloff, instead of a proper radius reduction with proper falloff:

Image

@MrXonte
Copy link
Contributor

MrXonte commented Jan 22, 2025

Also, how should C4 deal its damage? Currently its has a reasonable model of more damage range in LoS, but at least in my experience that really doesn't matter. I think I've never seen a C4 sitting in the open, they are always in a vent or something like this where LoS damage is meaningless.

Should we maybe consider switching entirely to SphereDamage, removing util.BlastDamage? And while were at it, add exponential damage dropoff to SphereDamage? If this is the case, I have an implementation ready for linear or exponential damage dropoff that i could adapt for the C4?

Image

@MrXonte MrXonte mentioned this issue Jan 22, 2025
@TimGoll
Copy link
Member

TimGoll commented Jan 22, 2025

First off: Thanks for that throughout investigation!

That is a good question. I fear I don't know an answer to this. I always assumed it has a linear (or inversed square) dropoff in damage. If we'd simplify it to act like this, it would probably be fine.

However, I have no problem with it being a bit more complex though. No matter how we decide, the function that deals the damage should be usable for other weapons as well, maybe in our game_effects library. That way the melon mine could use it as well.

The way we handle C4 damage is a good question to the community imho. Maybe someone else can chime in as well. @NickCloudAT is always very knowledgeable.

@Crashington
Copy link
Author

i definitly always assumed C4 has no difference between LOS and nonLOS damage. It being just a clean radius where you are either in danger or not (regardless of obstacles within that sphere) makes way more sense to me and is closer to the "fantasy" I have for a weapon like C4.

And as MrXonte mentioned, only one of these modes will matter 99% of the time as having a C4 out in the open in any way is just playing the game wrong.

@NickCloudAT
Copy link
Contributor

Not sure if I understood everything in here correctly..

C4 currently has a Line of Sight check? Tbh, I did not even know that and I think it would be better to just.. not have that.
I would say the best "overall feeling" would be achieved if we used an exponential decrease in damage over distance. This, at least imo, would make it feel more accurate to an actual explosion.

Although I might add: Not having a line of sight check is fine for me, but it might feel pretty unfair if the C4 kills you like 4 stories down in a building where many floors are inbetween.. Maybe C4 damage should be calculated differently in vertical space? Just a thought that came to my mind..

But just to clarify: I personally think C4 is a pretty good example of an Item that's just inherently bad (or at least somewhat bad) for TTT as it (imo) solely depends on a few factors if it even is effective:

  • Map size
  • Playercount
  • Well.. Randomness of course

And point one (Map size) is a big discussion point in this I think.. On my server I actually banned the usage of C4 on small maps (eg. Stairs I think that map is called) because it was just way to op.. On the other hand on very large maps it's pretty much useless unless there is a "hot spot" on the map where players tend to stay for a longer period of time..
The most fun with C4 I always had on medium sized maps.

@MrXonte
Copy link
Contributor

MrXonte commented Jan 22, 2025

util.BlastDamage has an integrated sightline check and it does the big radius damage, spheredamage does not check sightlines

Fully agree on the C4 and map size issue,it would be nice to have an option to enable white/blacklisting equipment for certain maps

as for vertical space, it would feel inconsistent again wouldn't it? And the difference between 4 floors and 4 rooms isn't really that much I think (even if people have an easier time with horizontal space). But we could also just make a convar for it, shouldn't be too hrad.

@MrXonte
Copy link
Contributor

MrXonte commented Jan 22, 2025

ill make a PR with a properly scaling sphere damage tomorrow then we can try it out if its ok like that 👍

@TimGoll
Copy link
Member

TimGoll commented Jan 22, 2025

I wonder if there is a way to get the map size and scale the explosion accordingly

@Crashington
Copy link
Author

I think that is gonna have a lot of false positives with spectator rooms, skyboxes, etc which may all be an arbitrary distance away

@MrXonte
Copy link
Contributor

MrXonte commented Jan 22, 2025

getting map size sadly doesnt work, ive been wracking my brain about that a lot. Even finding good points to start measuring is a pain. Authors would need to include a size somehow which is problematic for a game with this much old maps. Sadly I think the best thing to do would be to have a black/whitelist feature, and it would also allow more easy customization (although a default recommendation list could be included)

@TimGoll
Copy link
Member

TimGoll commented Jan 22, 2025

We could populate the whitelist based on the amount of spawns. But that is probably also not correlated with the map size

This was referenced Jan 23, 2025
@MrXonte
Copy link
Contributor

MrXonte commented Jan 24, 2025

Since im gonna tackle the indicators next, what is the behaviour we want from them? We only need to calculate the border between kill and damage zone, Killzone should be the same always.

I think ideally we calculate the boundary to 100 health as Killzone, since this will be it for base TTT (although, how does body armor work with blast damage?) but we could simply also add the damage number for the current distance which would also help Ts to better judge the situation if they are not at full health themselves.

@TimGoll
Copy link
Member

TimGoll commented Jan 24, 2025

I'd keep it simple. Design it as "kill if 100 HP without armor"

If a player has 120 HP, they are left with 20. I think this is fine. Going the extra mile is tricky, because you'd probably have to trigger a fake damage hook to see how addons react to damage. And this could have unwanted consequences.

So I'd say: If you want to make it perfect, use the players HP and armor for the calculation, but ignore everything else. But just using 100HP without armor is fine as well.

Up to you!

@Crashington
Copy link
Author

What if it just said "Damage dealt at this distance: 123" That way, its the most transparent players can make their own calculations against their own health and armor. It would also help giving them a better feeling for how the falloff works,

In my opinion this the best option past the simple one. I think the one where you actually calculate the damage dealt with armor and stuff is too convoluted. you never know what kind of weird addon they have installed that messes with damage taken too

@TimGoll
Copy link
Member

TimGoll commented Jan 24, 2025

I dislike this for two reasons:

  1. It adds clutter, you have to be able to see the value on first glance. The simple traffic light solution makes that possible
  2. The reason you just mentioned. You don't know what add-ons do to your damage. So it will still be wrong, just more complicated to read

TimGoll added a commit that referenced this issue Jan 29, 2025
Now scales C4 damage with radius and gives consistent damage through
walls regardless of line of sight.
Relates to #1729 and #1730 although the calculation for proper Killzone
is not yet included, but the safe and killzones are now 100% correct.

---------

Co-authored-by: Tim Goll <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants