Humanoid:TakeDamage(damage, attackingPlayer) and Team.AllowTeamKilling

Feature Requests Engine Features
#1 
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:
[ul]
[li]Both attacker and victim are on the same team[/li]
[li]The AllowTeamKilling property of teams is true[/li]
[/ul]
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.

Thoughts?

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.

12 Likes
[Rough Draft] Easy Damage, it's for... well... easy damage! [OPEN SOURCE]
#2

I fully support this idea, somebody could do with making a module in the meantime though since I don’t imagine we’ll see this anytime soon. It’s well thought through and makes a lot of sense.

2 Likes
#3

These changed methods could advance the game making ability of many users! They could make my life easier too! :smiley: :imagine:

1 Like
#4

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]

1 Like
#5

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.

1 Like
#6

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.

#7

I personally think AllowTeamKilling should be a property of the Teams service.

3 Likes
#8

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
end

#9

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.

Then it uses :TakeDamage() on the end result.

:smiley:

#10

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.

[quote]
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.

#11

Thinking through everything I like the idea.

It’s a bit specific for my taste, but the upside is big enough for it to be worth it.

#12

the whole creator tag thing was always confusing cus there was never documentation for it
this would solve that

#13

Honestly, I just prefer my own kill tags. Since I use FE, I have to pass the damage through the server, so I just do:

damageRequest.OnServerEvent(invoker, target, weapon)
table.insert(playerData[target].Hits, invoker, stats.weapon.Damage)

while wait(1) do
for players do
–heal damage and remove damage from oldest damage stored in playerData

playerDied
assign points to damagers

#14

[quote] Thinking through everything I like the idea.

It’s a bit specific for my taste, but the upside is big enough for it to be worth it. [/quote]

I think it’s more a case of some things could do with being more consistent.

On another note, we could also do with some way to switch of KOs/WOs website communication.

#15

The main downside of having “AllowTeamKilling” be a property of the Team class and not the Teams class is that, in a game with no teams, it would be impossible to disable team killing.

On the other hand, if it’s a property of the Teams class then it can’t be configured on a Team-by-Team basis.

Edit: Merely pointed out that if there are no teams, there is no reason to disable team killing. I disagree somewhat because of collaborative zombie games.

1 Like
#16

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.

Use cases:
[ul]
[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]
[/ul]

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 end

#17

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.

2 Likes
#18

Why not a member of Player of Humanoid if they can team kill? It could also work and seems to cover both situations.

#19

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.

1 Like
#20

For one, every single game would have to write a boilerplate script to set this property based on the player’s team. At the very least:

game.Players.PlayerAdded:connect(function(player)
	player.CharacterAdded:connect(function(character)
		character:WaitForChild("Humanoid").AllowTeamKilling = true
	end)
end)

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:
[ol]
[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]
[/ol]

Merely posted a thread in C&G asking about this, and everyone preferred per-team customization: http://www.roblox.com/Forum/ShowPost.aspx?PostID=144082449

2 Likes