[MRP Suggestion] Team Damage

[Lex_ 506]

38 minutes ago, Alex Conway said:

Not to mention the immense lag of constantly checking this function, you realize, every time someone fires a bullet it would run this command/function? People already think HitReg is unreliable. 

 

3 hours ago, Torch said:

This would NOT affect performance in any significant way as 2/3 of it is already happening.

 

51 minutes ago, Torch said:

I know I'm not explaining in full detail here, but I don't want people to believe something that isn't true. My original response (given changes in the pseudo-code to how the addon is actually setup) would work just fine. There would be no major performance hit, if any at all.

I'm not sure why I originally stated that there may potentially be a burden on performance since there actually wouldn't be. My first response has the code that is already similar to how team damage is handled except it is using PlayerShouldTakeDamage instead of EntityTakeDamage and only checks if the player is on the same "team" or not. Moving to the other gamemode function and adding the extra checks isn't going to tank performance whatsoever. In reality, it is already being run constantly whenever anybody takes any type of damage.

 

I think the method I proposed may be a better implementation than completely enabling friendly fire. As I've explained in my initial response, it gives people time to recognize friendlies, and if they accidentally open fire on someone they don't kill them right away. It doesn't scale damage when dealing with yourself, so nading or rocketing yourself would actually kill you (and still be FailRP, self-damage is against the rules anyways). Balances out both gameplay and realism.

[AlexConway 1,166]

13 minutes ago, Torch said:

 

 

I'm not sure why I originally stated that there may potentially be a burden on performance since there actually wouldn't be. My first response has the code that is already similar to how team damage is handled except it is using PlayerShouldTakeDamage instead of EntityTakeDamage and only checks if the player is on the same "team" or not. Moving to the other gamemode function and adding the extra checks isn't going to tank performance whatsoever. In reality, it is already being run constantly whenever anybody takes any type of damage.

 

I think the method I proposed may be a better implementation than completely enabling friendly fire. As I've explained in my initial response, it gives people time to recognize friendlies, and if they accidentally open fire on someone they don't kill them right away. It doesn't scale damage when dealing with yourself, so nading or rocketing yourself would actually kill you (and still be FailRP, self-damage is against the rules anyways). Balances out both gameplay and realism.

It will significantly impact damage because the function must be ran everytime a bullet is fired to check 10 different variables, most guns in CQC are Automatic, this would be horrendously laggy. The secondary point of disabling Anti-Team kill is to cut down on functions to improve hitreg and lag.

 

You're veering off topic. Please stay on topic thank you. And keep your answer to a +1/-1.

Edited December 18, 2019 by AlexConway

[Lex_ 506]

30 minutes ago, Alex Conway said:

It will significantly impact damage because the function must be ran everytime a bullet is fired to check 10 different variables, most guns in CQC are Automatic, this would be horrendously laggy. The secondary point of disabling Anti-Team kill is to cut down on functions to improve hitreg and lag.

 

You're veering off topic. Please stay on topic thank you. And keep your answer to a +1/-1.

I'm not being off topic? I'm saying that I personally feel your suggestion is incomplete, explaining why I feel that way, and providing an alternative solution that may work better. And I can guarantee that there would be almost no difference (the different would be too minor to even notice) with the current method of disabling friendly fire, the method I'm proposing, and what you are suggesting.

Also not cool devaluing both my opinion and knowledge publicly in OOC chat.

[huskaii 586]

-1

would cause too many issues in war

[Aparh 383]

Huge -1, this could severely impact a war. Lets say a mass rdmer gets banned, sure now hes banned but he also wiped out all of the forces on the cap point which easily allows the other side to get it. I feel like this could just cause confusion, annoyance, and more of a chance to break rules.

[Cuddles 1]

+1/-1

It would be horrible for the fact that it gives people an excuse to kill their teammates i shouldn't have to give an example because the situation is easily guessed

on the other hand it would be very nice because ive seen many rpgs and people with nades just blowing anything and everything up with no precaution so it would encourage them to be a little more smart about their tactics.

[KingOfCoochie1993 274]

3 minutes ago, Cuddles said:

ive seen many rpgs and people with nades just blowing anything and everything up with no precaution

If you see someone throw a grenade or shoot an RPG and self damage themselves say in staff chat they should check logs on that person to see if they self damaged. If they do self damage then it’s a FailRP warn

Edited December 19, 2019 by RegretAlt

[VBSA 106]

My heart says +1 but my brain says -1

So its -1.
Although it seems like a good idea in terms of role-playing, the harm/benefit scale seems to be more of a harm.
 

[Cuddles 1]

8 hours ago, RegretTheManEater said:

If you see someone throw a grenade or shoot an RPG and self damage themselves say in staff chat they should check logs on that person to see if they self damaged. If they do self damage then it’s a FailRP warn

see but i mean they have shot near their teammates 

[Nutter 15,193]

Unfortunately, all these theoretical "will create RP" reasons are made up. In reality we'll just have more privates RDMing in spawn/killing teammate unintentionally because they cannot yet recognize the playermodels of enemy forces. Explosive team-damage might be a thing if I can implement it soon.