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

[TheNickmaster21]

Make the AllowTeamKilling property a member of the team object?

[Aurarus]

Make the AllowTeamKilling property a member of the team object?

This seems like the most simple and intuitive way of doing it.

[GollyGreg]

Make the AllowTeamKilling property a member of the team object?

This seems like the most simple and intuitive way of doing it.[/quote]

for some reason this is what I had going in my mind

[litozinnamon]

Also have it automatically tag the humanoid so that it counts as a profile kill for the killer when the humanoid health reaches zero using the Player attacker argument?

So many creators neglect to do this creator tag thing on many fighting games today that I don’t see the point of getting deaths in the game when my kills on the game mean nothing. (I like getting kills that count to my profile stats so it feels like I achieved something at least)

[woot3 (Woot)]

Ideally, it’d be nice if KOs could be awarded for AI kills too, I feel like that’s something we should consider. Not trying to derail the thread though.

[MerelyDupe (Nathan Dean)]

Ideally, it’d be nice if KOs could be awarded for AI kills too, I feel like that’s something we should consider. Not trying to derail the thread though.

Not profile KOs. Right now those require an actual player death to earn. If you could earn them for NPCs, you could write a bot that would increment your knockouts to 100000 in 5 minutes.

[Sharksie]

Ideally, it’d be nice if KOs could be awarded for AI kills too, I feel like that’s something we should consider. Not trying to derail the thread though.

Not profile KOs. Right now those require an actual player death to earn. If you could earn them for NPCs, you could write a bot that would increment your knockouts to 100000 in 5 minutes.[/quote]
You can already do that with real players though.

[woot3 (Woot)]

Ideally, it’d be nice if KOs could be awarded for AI kills too, I feel like that’s something we should consider. Not trying to derail the thread though.

Not profile KOs. Right now those require an actual player death to earn. If you could earn them for NPCs, you could write a bot that would increment your knockouts to 100000 in 5 minutes.[/quote]

Totally understand that, but technically if you can kill a bot that’s been coded to act like a player than you should be able to receive credit for it. What I have done in the past was upon killing an NPC I chucked a creator value in a non-dead player to give them credit for the kill when they died.

Understand the issue with exploiting, however it’s possible to cap it if there is no other player present to even as low as 2 a minute.

[Seranok]

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.

I think it would make more sense for Humanoid:TakeDamage to return a bool indicating whether it succeeded or not. So it would return false if the player had a ForceField or the attacker and target were both on the same team.

[mew903]

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.

I think it would make more sense for Humanoid:TakeDamage to return a bool indicating whether it succeeded or not. So it would return false if the player had a ForceField or the attacker and target were both on the same team.[/quote]
I disagree. I can see many cases where getting the knowledge of whether or not you can damage the humanoid beforehand would be much more useful than knowing if TakeDamage did anything (and it would most likely work in any case where what you’re suggesting would work too). What also concerns me about that is that it seems it would turn TakeDamage into a YieldFunction (right? we’re waiting for a response) which could potentially slow down code when it doesn’t need to.

What Merely said would probably be the best in this case, because there would be no (major?) yield in the response for the function to tell if the Player can damage the humanoid, whether it’s TeamColour, MaxHealth, Forcefield, etc. All of those might be a bit of a stretch, but it’s a start.