###UserStory:
As a developer it’s indescribably yucky and painful to listen for when a team gains/loses a player.
###Explanation:
It’s impossible to listen for when a team gains/loses a player. I have to, in a roundabout way, hook a Team change event into every player in the game, check to see if the team is one I care about, and then act on that. But wait! There’s more! Not only do I have to listen to every player’s Team change event, but I also have to listen to PlayerAdded to detect when more players are added to the game and listen to their events too. Here’s what the current solution we have available to us is:
local teamsICareAbout = {...}
local playerTeamChangeEvents = {}
local playerAddedEvent
function startListening()
local oldTeams = {}
local function playerAdded(player)
oldTeams[player] = player.Team
playerTeamChangeEvents[player] = player:GetPropertyChangeSignal("Team"):connect(function()
local oldTeam = oldTeams[player]
local newTeam = player.Team
if teamsICareAbout.contains(oldTeam) then
teamLostPlayer(oldTeam, player)
end
if teamsICareAbout.contains(newTeam) then
teamGainedPlayer(newTeam, player)
end
end)
end
for _,player in next,game.Players:GetPlayers() do
playerAdded(player)
end
playerAddedEvent = game.Players.PlayerAdded:connect(playerAdded)
end
function stopListening()
playerAddedEvent:disconnect()
playerAddedEvent = nil
for _,event in next,playerTeamChangeEvents do
event:disconnect()
end
playerTeamChangeEvents = {}
end
###A solution:
Team.PlayerAdded and Team.PlayerRemoving. The above code simplifies to:
local teamsICareAbout = {...}
for _,team in next,teamsICareAbout do
team.PlayerRemoving:connect(teamLostPlayer)
team.PlayerAdded:connect(teamGainedPlayer)
end
and I don’t have to manually disconnect the events because that happens automatically when I destroy the teams, rather than them being tied to players and continuing to fire.
There are some features that aren’t currently possible due to the optimizations of other features (e.g. per-voxel terrain colors), so we’d see a decrease in performance if those optimizations were disabled to allow that feature, but this isn’t one of those. There would be no performance decrease from adding Team.PlayerAdded/PlayerRemoving.
Okay, out of curiousity, is this how roblox’s events work?
Every time you make a change to a property in a script, you are calling some parent/main function that will do it for you
That function will do the work, and, if any event exists for this circumstance, the function will call a bindable for both the server and client which will cause the event to occur in scripts watching for it?
You’d have to ask an engineer for specifics of the implementation of events, but the events themselves are very cheap. You usually won’t run into performance issues unless the function you’ve connected to the event has issues itself, but that’s not related to the event. There are, however, some cases where the information an event needs isn’t readily available which would require some heavy calculations (e.g. lighting changed in voxel), but generally you won’t run into these.
should be playerremoved not playerremoving because they should be out of the team incase we want to find out what team they were switched to, and rather than adding an argument it’d be easier to tackle if we just did playerremoved.
Yeah, ideally with both we’d be able to get the old/new team. The naming convention was more out of habit of Players.PlayerAdded/PlayerRemoving, but I’m fine with anything.
I kind of like this idea. This could make things a little easier for me and a couple of my friends. Then we don’t have to make conditional statements to give teams certain things.
It is likely waiting to be shipped to all platforms (iOS app review can take ~2 weeks for instance) before being enabled. You’ll just have to wait until then to be able to use them.
