I committed a new abstraction layer for the scoreboard that works on top of SetScoreboardData etc.
Why? It scales and is finally usable without hitting your monitor :3
You initialize any columns you want to have in the scoreboard with
The properties in that proplist can be:
If you want a new row in the scoreboard you can use either
or
If you want to set fields in the scoreboard, use:
The title of the Scoreboard can be set using
Note: Init and NewEntry (with the same ID) can be called multiple times without breaking anything.
Enough blabla, examples: (taken from the current repository Scoreboard_Death)
And yes, that's it. You don't have to care about where your columns actually are or what actually happens. And it doesn't break if you also include Scoreboard_Kill, Scoreboard_KillStreak etc. which use the same schema.
So if you do stuff with the scoreboard, please use this abstraction layer - because it is simple (yes, really!) and it actually works :3
Comments?
Why? It scales and is finally usable without hitting your monitor :3
You initialize any columns you want to have in the scoreboard with
Scoreboard->Init(values)
, where values is an array of proplists.The properties in that proplist can be:
key: string; needed, unique identifier to refer to that column later
title: string/id; headline of the column
sorted: bool; whether the column will be sorted
desc: bool; if sorted, whether descending
default: any; default value for entries in that column
priority: int; priority of the column (column with highest priority will be left)
conditional: function; if needed: function to modify values shown in array
If you want a new row in the scoreboard you can use either
Scoreboard->NewEntry(int ID, string title)
with a unique ID an a title for that rowor
Scoreboard->NewPlayerEntry(int player)
which is a wrapper for NewEntry in case you want to add a row for a player (because I heard that happens :])If you want to set fields in the scoreboard, use:
Scoreboard->SetData(int ID, string key, any to, int sort_parameter)
where ID is the unique ID of the row, key is the key you used to create the column, to is the value and sort_parameter is the value used for sorting if you don't want to use to.or Scoreboard->SetPlayerData(int player, string key, any to, int sort_parameter);
which is a wrapper for the above.The title of the Scoreboard can be set using
Scoreboard->SetTitle(string to);
.Note: Init and NewEntry (with the same ID) can be called multiple times without breaking anything.
Enough blabla, examples: (taken from the current repository Scoreboard_Death)
func Initialize()
{
score_death_list = [];
Scoreboard->Init(
[{key = "deaths", title = Scoreboard_Death, sorted = true, desc = true, default = 0, priority = 75}]
);
}
func InitializePlayer(int plr)
{
score_death_list[plr] = 0;
Scoreboard->NewPlayerEntry(plr);
}
func RelaunchPlayer(int plr, int killer)
{
score_death_list[plr]++;
Scoreboard->SetPlayerData(plr, "deaths", score_death_list[plr]);
}
And yes, that's it. You don't have to care about where your columns actually are or what actually happens. And it doesn't break if you also include Scoreboard_Kill, Scoreboard_KillStreak etc. which use the same schema.
So if you do stuff with the scoreboard, please use this abstraction layer - because it is simple (yes, really!) and it actually works :3
Comments?
I like it. It looks like one can actually see what the developer is trying to achieve \o/
"it" is only an abstraction layer that takes care of the general layouting - it does not order your players according to teams on its own.
You can however specify it, should look something like that:
that should do the trick. What does it do?:
It defines that the standard column "title" (which always exists) is now sorted. After creating an entry for a player it resets the "title" attribute of the player and gives that field the
PS:
the whole layer does not impose a lot of restrictions and does not provide a lot of special behavior or treatment. It is really just a wrapper for "I want a row X and the field Y should be Z" plus some behavior of the columns (sorted etc). The only huge difference is that you use the keys instead of indices which make it scalable
You can however specify it, should look something like that:
func Initialize():
Scoreboard->Init([{key = "title", title = "", sort = true, priority = 1000}, otherkeys...]);
func InitializePlayer(plr, x, y, team):
Scoreboard->NewPlayerEntry(plr);
Scoreboard->SetPlayerData(plr, "title", GetTaggedPlayerName(plr), team);
that should do the trick. What does it do?:
It defines that the standard column "title" (which always exists) is now sorted. After creating an entry for a player it resets the "title" attribute of the player and gives that field the
sorting_parameter
team.PS:
the whole layer does not impose a lot of restrictions and does not provide a lot of special behavior or treatment. It is really just a wrapper for "I want a row X and the field Y should be Z" plus some behavior of the columns (sorted etc). The only huge difference is that you use the keys instead of indices which make it scalable
Correction since you can (probably?) not sort the title rows:
this one is even more straight-forward:
This one just adds a team value to the scoreboard and sorts for it. Since all the fields are empty it does not even appear in the scoreboard (at least in console mode)
this one is even more straight-forward:
func Initialize():
Scoreboard->Init([{key = "team", title = "", sort = true, priority = 1000, default=""}, otherkeys...]);
func InitializePlayer(plr, x, y, team):
Scoreboard->NewPlayerEntry(plr);
Scoreboard->SetPlayerData(plr, "team", "", team);
This one just adds a team value to the scoreboard and sorts for it. Since all the fields are empty it does not even appear in the scoreboard (at least in console mode)
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill