Convert teams to be a class

[NullEntity]

Teams should be treated as a class like Players and remove the team library. I think the current method doesn't fit very well. Most functions seem to use Get/Set. I would expect to be able to get a player's team by calling Player:GetTeam() and have a team object there.

For example: MsgN( ply:GetTeam():GetColor() )

[Lexicality]

You would have to be very careful to break as few gamemodes as possible, presumably using the existing team library as a compatibility layer.

On 1 October 2013 05:11, Bryce notifications@github.com wrote:

Teams should be treated as a class like Players and remove the team library. I think the current method doesn't fit very well. Most functions seem to use Get/Set. I would expect to be able to get a player's team by calling Player:GetTeam() and have a team object there.

For example: MsgN( ply:GetTeam():GetColor() )

— Reply to this email directly or view it on GitHubhttps://github.com/Facepunch/garrysmod-requests/issues/101 .

[robotboy655]

Well, ALL team based gamemode will be broken. I don't think any of them are using player classes as teams, without using the team library. For example,setting player class on spawn according to players team.

[Lexicality]

Not necessarily all - As far as I'm aware most gamemodes that call ply:GetTeam() immediately pass it to team.Get. So if you replaced the team.Get functions with wrappers you could probably ease through only breaking gamemodes that start throwing ints around.

[NullEntity]

Robotboy is correct. It would probably have to wait until another gmod 13-style update where Garry did all the major updates. If anything, GetTeam could be added along side the current team system.

[Acecool]

Well, actually, we could write a new team class that handles teams differently with new features. It could be made to be reverse-compatible. Below is untested, and could be a class system of doing it while retaining backwards compatibility. Then, we'd just need to pass the large chunks of data which form a class through to the new system which creates a new instance with each team.

It's possible to do, but why do you think this is better?

I mean, you'd have to player_manager.RegisterClass( "player_acecool_dev", PLAYER_CLASS, "player_default" ) or call team:New( ) ( which actually looking at it should probably be renamed to RegisterClass to stay within naming guidelines ) with the object in question in addition to adding the String* identifier, the PLAYER_CLASS is just the array/object which is built in already, and then we'd need a way to reference those with a GAMEMODE.__Teams = { } so we can build off of a base....

As for calling PLAYER:GetTeam( ), it's currently PLAYER:Team( );

I can code it, it wouldn't be hard at all, but tell me why you think this is better than the system which is currently in place?

For example how I'm doing my cards class with stuff renamed:

if ( !team ) then
    team = { };
    team.__index = team;
    --cards.__DecksUsed = nil;
end

//
// Create a new instance of this class.
//
function team:New( object ) // This would become team.SetUp
    local __class = object or { };
    setmetatable( __class, self );
    self.__index = self;

    self.__Vars = { };

    return __class;
end

function team:SetID( _id )
    self.__Vars.TeamID = _id;

    return self.__Vars.TeamID;
end

function team:GetID( _id )
    return self.__Vars.TeamID;
end

//
// Reverse compatibility functions
//
function team.SetUp( _id, _name, _color )
    local _newTeam = team:New( );

    // Populate the data.
    _newTeam:SetID( _id );

    return _newTeam;
end

[robotboy655]

Why? What's wrong with current system?

[Acecool]

That's what I'm asking. I'm saying it's possible and I could code it, but I want to know why he wants it. The request doesn't make much sense unless he comes up with a ridiculously good reason for it!

It wouldn't be hard to add it in, and I could maintain backwards compatibility, I just want to know why he wants it.

[Lexicality]

@robotboy655 Well, for one the current team system is procedural and relies on passing around IDs while the rest of GMod is now heavily object orientated. If you want to store information about a team you have to do it in a table index via said ID rather than - for instance - storing it on the team's global object.

[robotboy655]

There are A LOT more stuff like that - bodygroups, sequences, etc. And there are even more inconsistencies.

[Lexicality]

This is true, but bodygroups aren't persistent data structures. Teams actually are stored as objects in the library - so why are we passing around IDs?

[Acecool]

So, essentially you'd want a system that's easily expandable without having to create your own structure wrappers?

I kind of know how that feels, I have to pass around a table for each "Job" as I have 6-ish teams, and over 30 jobs, career paths to follow and more.

Tell you what, I've been recoding quite a lot of things and turning them into classes ( quite fun actually, just finished up my fileio class, playing cards class, and a few others ) so I may work on something like this, and give it a few default hooks / functions. If no one else is wanting to do it, I'll try to get to it. Personally, I need a solid way to identify teams, and those teams can never change ids once they're created. Like-wise, the jobs can never change ids. The path can, but the ids can't as they will be stored via MySQL and contain info such as experience in that position, and a lot more!

Give me an idea of some of the things you want to see with this class.

[NullEntity]

I think with the next major update Garry should work on fixing all of these inconsistencies. They're pretty frustrating.

[Kefta]

This should just be implemented gamemode wise and not as a Garry's Mod wide feature