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

When a player with any of the Timebomb effects is killed, the bomb should be exploded anyway instead of disappearing #96

Open
Tiagoquix opened this issue Jan 3, 2024 · 6 comments
Labels
request :: setting Requesting a setting for existing perk

Comments

@Tiagoquix
Copy link
Contributor

No description provided.

@Phil25 Phil25 added the request :: setting Requesting a setting for existing perk label Jan 4, 2024
@Phil25
Copy link
Owner

Phil25 commented Jan 4, 2024

I have a problem with adding this. Usually when people want to configure perks themselves there is a clear visual indicator to how they are configured, but not sure what to add here.

My question is, how to let random players know whether this particular timebomb will explode anyway, as opposed to the default behavior which makes it safe to get up close to destroy it?

@Tiagoquix
Copy link
Contributor Author

Oh, perhaps you misunderstood that I referred to the "Explode" effect (ID 15). In this case, I'm actually referring to the Timebomb effects (IDs 18 and 48).

As far as I know, there is no way to remove these Timebomb effects other than by dying, and the only way to make the bomb explode is through the effect timer.

@Phil25
Copy link
Owner

Phil25 commented Jan 8, 2024

I did refer to Timebomb and Fire Timebomb effects too.

Consider this scenario:
You're playing TF2 and somebody on the other team rolls Timebomb and begins to run at you. Currently, whether you kill the other player from a distance or up close doesn't really matter, you know you're safe as long as you get the kill. However, with this change, server operators will be able to configure Timebomb to explode regardless of the perk timer, meaning that, as a player, you have no way of telling whether you're safe up close and you have to keep your distance just to be safe.

That's generally my problem with this suggestion -- players are unable to tell which setting the server operator went with. And it's crucial for them to know at a glance, because it affects their stategy.

Thinking about this now, I'd approach it like this: if a player with Timebomb is killed, the bomb drops to the ground and runs its time regardless of the owner's death. It explodes normally when it reaches 0.

@Tiagoquix
Copy link
Contributor Author

I understand your point.

Your new way of thinking (dropping the bomb on the ground when killed) is good, but I think it ends up returning to the same problem as the players' uncertainty that you mentioned.

I think perhaps the best way to buff Timebomb perks is to reduce the time until the explosion (reduce effect time), and effect-wise keep it as is. 5 seconds is fine IMO.

@Phil25
Copy link
Owner

Phil25 commented Jan 13, 2024

Your new way of thinking (dropping the bomb on the ground when killed) is good, but I think it ends up returning to the same problem as the players' uncertainty that you mentioned.

I disagree, players seeing the bomb being dropped to the ground with the exact same effects going on is a clear indicator that it's going to detonate regardless of the owner's death, in my opinion.

I think perhaps the best way to buff Timebomb perks is to reduce the time until the explosion (reduce effect time), and effect-wise keep it as is. 5 seconds is fine IMO.

Changing the timer doesn't buff or nerf it in any way. With a shorter timer players can utilize the bomb quicker if the situation allows it, with a longer timer they have more time to wait for a good opportunity and choose to attack themselves. That said, I think 10 seconds is fine as it is.

@Tiagoquix
Copy link
Contributor Author

All right. I think we can continue with your idea of making the bomb fall to the ground, similar to the "Explode" effect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
request :: setting Requesting a setting for existing perk
Projects
None yet
Development

No branches or pull requests

2 participants