Class Humanoid : Instance
Function void Humanoid:TakeDamage(float amount, Player attackingPlayer = nil)
Event Humanoid.Died(Player killerIfAny)
I propose that a second optional parameter be added to Humanoid:TakeDamage to indicate which player is causing the damage. This would supercede the confusing and unreliable “creator” tag system.
Additionally, the Humanoid.Died event would fire with the player object responsible for the death. It would no longer be necessary to search the humanoid for an child named “creator”. Internally whatever fires the Humanoid.Died event would have to fall back on creator tags for backwards compatibility.
With these changes in place, this property could be added to the Teams class:
Class Teams : Instance
Property bool Teams.AllowTeamKilling
If a call is made to Humanoid:TakeDamage where:
[li]Both attacker and victim are on the same team[/li]
[li]The AllowTeamKilling property of teams is true[/li]
Then the call would be ignored and not cause any damage. This would make it easy for non scripters to configure whether or not team killing is allowed, instead of having to edit every single gear in a place. Of course explosions don’t fit within this system so they would cause team killing regardless, but I think this would be a good first step.
Edit: Teams.AllowTeamKilling should probably default to true to support backwards compatibility Edit 2: Just for clarification, calling TakeDamage with a player object specified would internally create a creator tag and parent it to the given humanoid, so as to be compatible with existing leaderboard scripts. The point is going forwards we have a nice facade hiding the details of creator tags from scripters.
I totally agree with this idea because it makes it a LOT easier for people who don’t know how to script. The only issue I have is that I’m pretty sure some certain old gears* actually set humanoid.Health, which would override the AllowTeamKilling property.
And how would ROBLOX prevent explosions from dealing team damage when this property is true?
[size=2]* old gears being things like the original linkedsword and rocket launcher.[/size]
To be honest, adding on to what you have said, it’d be great to get better leaderboard support too, the systems seem to be similar at the moment, probably created by the same person at around the same time, and that could do with an update too.
Note that: This does have different behavior than the current tag system.
Under the current tag system, a lot of tags stick around for a couple of seconds, that means that if you’ve been damaging someone a bunch, and then someone else kills them, :FindFirstChild(‘creator’) is going to find the old creator tag first, and thus award the person who was doing damage recently the kill.
Under this system, presumably the last damager would be the one who always “gets” the kill. This would alter the preferred strategy in some places quite a lot.
I have a feeling that if you put it there, new players would tick that and think “Oh, all of my guns and whatnot that use player.Health = player.Health - 10 won’t TK now!!” If you have it as an argument of :TakeDamage(), it’ll be more clear. Less people use :TakeDamage() than you think – I remember seeing code from a not-new-scripter that was:
if not character:FIndFirstChild(“ForceField”) then
character.Humanoid.Health = character.Humanoid.Health - 10
I have an interesting system where NONE of my scripts do :TakeDamage()
Instead, I insert a numbervalue called “Damage” into the creator tag, along with a configuration named “Traits” with different bools inside them.
Things like “Sharp”, “Impact”, “Heat”, “Wood”, “Metal”, “Crush”, etc.
I have a script inside humanoids which use .ChildAdded to look inside the creator and detect for Damage and Traits. If it finds Traits, it runs through folders in the humanoid named “Vulnerabilities, Weaknesses, Immunities”
It determines whether to double the damage, allow damage even if the player is immune to one of the traits, or negate/ not allow damage altogether.
Seranok’s use case for having AllowTeamKilling as a property of each Team is that you might want to have a “Raiders” team be able to kill each other, but not the “Defenders” team. I’m not sure that this makes sense.
I have a feeling that if you put it there, new players would tick that and think “Oh, all of my guns and whatnot that use player.Health = player.Health - 10 won’t TK now!!” If you have it as an argument of :TakeDamage(), it’ll be more clear. Less people use :TakeDamage() than you think [/quote]
It’s understood that a lot of scripts use .Health or :BreakJoints(). The problem with having “allowTeamKilling” as an argument of TakeDamage is that you have to modify every script in all the tools in your game if you want to toggle teamkilling on or off.
We should use the existing behavior for kill tags.
The advantage of this system is that it cuts away a lot of the boilerplate code in gear that deals with killer tags and checking if the player is on the same team.
I also propose:
Class Player: Instance
Function bool Player:CanDamage(Humanoid human)
There are numerous gear that freeze, push, or affect the targeted humanoid without dealing any damage. This method would be useful for determining if a given humanoid can be targeted with a given weapon.
[li]I have a sniper rifle and when you mouse over a humanoid, I want to show a green icon if the target is on my team, and a red icon if the target is not.[/li]
[li]I have a seeking rocket and I only want to allow it to be fired at non-teammates.[/li]
[li]I have a freeze ray gun and I only want it to freeze enemies. It should ignore teammates.[/li]
[li]I have a grenade and I want the body forces to only push away humanoids that are not on my team.[/li]
Right now I have to do the the following:
if humanoid and humanoid.Parent and (game.Players:GetPlayerFromCharacter(humanoid.Parent) and game.Players:GetPlayerFromCharacter(humanoid.Parent).TeamColor ~= myPlayer.TeamColor) or (not game.Players:GetPlayerFromCharacter(humanoid.Parent) then
--or statement is to account for NPCs
--attack is valid
Merely, your proposed Player:CanDamage(humanoid) method is decent, but I don’t think it’s worth it. The name “CanDamage” is not an accurate description. What it does is return false if the two players are on the same team AND the team has AllowTeamKilling set to true. Otherwise it returns true. What about cases like a humanoid having a forcefield? Would it return true in that case? Again, very confusing and an unnecessary addition.
I believe Merely’s proposed TeamKill-Able property in Teams would work.
Searnok’s example case does have valid points, but we can still code that on our own. The guns aimed at the zombies should be able to easily check if theyre shooting at an NPC zombie or their teammates.
This negates the whole point of this proposal, as the feature is inaccessible to non-scripters. And before you suggest that this Humanoid.AllowTeamKilling property be set by the Team.AllowTeamKilling property, think about how obfuscated your idea is. The AllowTeamKilling property doesn’t even apply to all humanoids, just humanoids of players. >_>
[quote] I believe Merely’s proposed TeamKill-Able property in Teams would work.
Searnok’s example case does have valid points, but we can still code that on our own. The guns aimed at the zombies should be able to easily check if theyre shooting at an NPC zombie or their teammates. [/quote]
Being able to configure team killing on a per-team basis is an extremely common use case:
[li]You want to prevent team killing for players on the Lobby team, but not players on the Free for All team[/li]
[li]You want raiders to be able to kill each other but not defenders[/li]