SQLMatches/API

Issue with custom team names during overtimes - how to determine the winner?

borzaka opened this issue · 4 comments

I'am trying to figure out a problem with custom team names pairing with the winning team. Recently I have added saving custom team names to the db with my PR. Basically it saves the mp_teamname_1 and mp_teamname_2 cvars to the db, which is working fine.
mp_teamname_1 is for setting custom team name for the CT team, mp_teamname_2 is for the T team.

The problem is;
During the whole match, these cvars stays the same, not switching during halfs.
So, if you start as a CT, and win a match as a T, which cvar should be used? Always the opposite team one? And what about overtimes? How could we know which custom team name won?

I guess the main problems is with overtimes. If you start as a CT, and win as a T, your custom team name is come from mp_teamname_1 (the team you started in).

In the database, team_2 score means T score, team_3 score means CT score by the end of the match.

I tried GetTeamName() but it's just returns a TERRORIST or a CT string.

Goal: get the winning team name. Or get the winning team starting side.

Unfortunately my PR is not fixing this issue :( It's still present.

Or you don't want to deal with overtimes? If we could count the halftimes, it would be very helpful.

Issue is it depends on a lot of factors.
Some commands will change team names at half to the appropriate name.

The plugin should just store the team name at the end of the map depending if they are CT or T.

mp_teamname_1 is always the starting CT team name, mp_teamname_2 is always the starting T team name.
During halfs (including overtime halfs), the team names are switched, but not these cvars, they always stay the same no matter how many half was in the match. This is problem, because you don't know the starting team on which side won the match if overtime occurs.

But forget about team names. There is a possibility that the score will be recorded to the wrong team if overtime occurs.

I'am just trying to help.

Starting rewrite soon, this issue will be resolved in that version.