Notes |
|
(0009020)
|
Dusk
|
2014-06-10 22:03
|
|
I tried to implement this once but realized that this should instead be some form of SBARINFO extension. Not sure about exact details though. |
|
|
|
Maybe if we could switch HUDs not only for small/big HUD, but also by some event like round end, we could code custom scoreboard and whatnot using already existing features. |
|
|
|
Requesting extra developer review as this is a massive undertaking. |
|
|
(0009531)
|
Blzut3
|
2014-06-16 20:36
|
|
Can you provide the specifics of why you want to do this? Some of the points like scrolling make sense, but they're independent of being able to customize it from a mod. You mention your project, but no details on why your project needs it. |
|
|
(0009534)
|
Watermelon
|
2014-06-17 00:47
(edited on: 2014-06-17 00:49) |
|
I think this covers a majority of my reasons:
- My project requires a custom ACS table to work around the endgame score screen. I had to set the timelimit and pointlimit to 1 ahead of what they were, then create an entire new screen in ACS. it was really tedious.
- Access to things that would be nice to have on the scoreboard that aren't, or expansion to the scoreboard (ex: kills, points, defenses...etc, rather than being locked into a basic one)
- ACS means it has to be puked, and can only happen at certain times. Putting this data into the scoreboard means the client can read it at any time by the click of a key, rather than binding a key to turn the 'what would be scoreboard' on and off.
- Can extend past what scoreboards allow (ex: we can count defenses now for flag defends, whereas it would have to be hardcoded). This allows for abstraction so different game modes don't have to be hard coded. Mod authors can include what they want.
Now, some of my ideas in retrospect look like not the best idea (ex: having the scoreboard be replaceable by an ACS script should someone want it), but extension to the scoreboard system through a new lump would be interesting.
I understand this is not some small project as well.
I'm trying to see if there's also any flaws I could run into which would make this ticket not feasible.
Ex: Should we force always displaying users? times? pings? etc
|
|
|
(0009537)
|
Blzut3
|
2014-06-17 02:34
|
|
Having some ACS scoreboard manipulation functions may not be the worst idea. Just not a hook to do the drawing manually. It might be decent to have a way to turn on/off score columns in the game mode lump and have a way to set the value in ACS (I would just say show a global array as a column, but we don't sync globals since it's not trivial to do so without over sending). Likewise a way to put some kind of game status above the score board could also be added.
I'm not entirely convinced that something along the lines of SBARINFO is needed. It would be overkill (and given the need for an expression evaluator, much harder to do).
Leaving the presentation of the score board up to Zandronum does have some benefits including being able to add the scrolling you suggest. |
|
|
|
Perhaps it could be a combination of compiled script + mapinfo? So different scoreboards could be specified e.g. for survival, or ctf, etc by using gameinfo or another block (or in the map definitions themselves if needed).
This could also open the possibility of overwriting scoreboards or removing them entirely. |
|
|
|
Making the scoreboard customizable in the sense that a lump can be used to define which columns are shown in which gamemode sounds fine to me. To handle new types of columns I would introduce one (or a few) custom counter(s) for each player, that can be manipulated by ACS, i.e. Get/SetPlayerCustomCounter (similar to SetPlayerLivesLeft, also handling the server->client update) and displayed in the scoreboard. The labels of the columns should also be configurable with the lump. |
|
|
(0009624)
|
Dusk
|
2014-06-21 16:31
|
|
IMO the scoreboard is horrible as it is and should be rewritten from the ground up... |
|
|
|
Are you interested in doing so? |
|
|
|
I wouldn't mind being part of this. I planned to start on it tomorrow actually. |
|
|
(0009632)
|
Dusk
|
2014-06-21 21:26
(edited on: 2014-06-21 22:06) |
|
I can help with this endeavor, just grab me on IRC.
|
|
|
|
But why you can't/don't want to use SBARINFO and it's underlying code for that? |
|
|
(0009654)
|
Torr Samaho
|
2014-06-22 13:45
(edited on: 2014-06-22 15:42) |
|
Dusk, Water, if the two of you want to rewrite the whole scoreboard drawing functions, feel free to do so. I have no interest in completely redesigning the drawing code myself. BTW: I just remembered that Thomas started to work on a customizable scoreboard and IIRC he had a working prototype. If you can get hold of his code, that may help to get started or at least give some ideas.
ZzZombo, look at Blzut3's explanation: 0001829:0009537.
|
|
|
|
No, I don't get the line about expression evaluator. Does it suggest to reinvent the wheel and create SBARINFO for scoreboard instead of using already existing? |
|
|
(0010284)
|
Watermelon
|
2014-09-22 02:47
(edited on: 2014-09-22 02:49) |
|
So far I've implemented the basic parser in GAMEINFO as discussed on IRC. There's a few things I need clarification with.
So far it would look something like this:
gameinfo
{
...
scoreboard
{
key = value(s)
}
...
}
The following key/value pairs are what I have in mind. Please debate on whether they are needed, should be extended/removed, what else I'm missing:
VALUES:
alignment = left, right, center
customcolumn1..5 = <string>
headercolor = <integer enumeration for color, like CR_RED>
order = POINTS, FRAGS (KILLS), DEATHS, NAME, TIME, PING, MONSTERS_KILLED, CAPTURES, LIVES_LEFT, WINS, CUSTOMCOLUMN1/2/3/4/5
sorting = POINTS, FRAGS (KILLS), DEATHS, NAME, TIME, PING, MONSTERS_KILLED, CAPTURES, LIVES_LEFT, WINS, CUSTOMCOLUMN1/2/3/4/5
truncatenames = <boolean>
DESCRIPTION:
1) alignment
Where the board aligns. Left means it aligns on the left hand side (plus some buffer), center means it lines up always from the center, right means it aligns from the right, with preference given to whatever is on the left of the 'order' key (since those are considered important fields)
2) customcolumn1, customcolumn2, customcolumn3, customcolumn4, customcolumn5
The custom columns that users can set with data via ACS. Any changes are sent at the end of the gametic (to save bandwidth/stop spam) to the clients. They will render this data if it is present. The header of the column is the provided name
Ex: customcolumn1 = "mana" would render a column with the header 'mana'
3) headercolor = <integer enumeration for color, like CR_RED>
Sets the header color to be something else, default is Red as per normal.
4) order = [list of items]
Order is how the columns will be rendered from left to right.
Ex: order = kills, name, ping
Would draw kills on the left, then name, and then ping. All possible values are in the above code box.
5) sorting = [list of items]
Like order, left to right determines the priority of sorting.
Ex: sorting = kills, deaths
That means that people will be sorted by kills, in the event of ties... then deaths. If two have the same death, it then sorts by default with the player number. This is the bottom case for every sorted list.
I chose this because its deterministic, right now on the scoreboard people change positions for no reason (thank you Carn).
NOTE: Spectators are always sorted by player index only.
6) truncatenames = <boolean>
Since people use low resolutions, sometimes obnoxious names screw up the table, like a name called asdoijsadid1j289dnmjdo9nas.
This will truncate any names longer than 16 chars with a '...', color codes do not count to name length
Ex: MyNameIsReallyLong -> MyNameIsReall...
Pseudo code: If name > 16 chars and truncatenames = true, write chars 0-12, and append '...'.
NOTE: This board supports scrolling if the number of names goes off the screen.
I am unsure if this should be some hardcoded key, or some bind players can press.
Also while were at it, can we have a persistent scoreboard button? It's annoying holding it down. Especially since we want support scrolling and not having to do weird reaches with our fingers.
I also need input on
- thoughts on the buffer space in the board
- thoughts on keeping it only to the common doom font? Do we want to allow custom fonts for headers and stuff?
- thoughts on red highlights or something for the player with a key item like the terminator ball?
IMPORTANT: I have not thought about how this will be handled over multiple team modes. For example, what if the user declares Points but it's just deathmatch? Is the column not written? Some of them do not have a place in some gamemodes...
|
|
|
(0010285)
|
Blzut3
|
2014-09-23 20:59
|
|
What does alignment affect? The position of the scoreboard on screen or alignment of text in column (which column?)?
As far as appearances go (fonts, etc) I think you should start by not providing anything there. Again, it's not that I'm against customization, but we may be better off here leaving presentation to Zandronum. I believe both Odamex and ZDaemon use a custom, common, included font for their scoreboard for example.
As for your questions on columns not relevant to certain modes. I do believe that can be handled by only displaying columns given in order. Then you can provide scoreboard definitions for the built in modes. I suppose the trickiest part there is backwards compatibility. |
|
|
|
I'd also like input about handling the 'data off the screen' button. Is there a way to do that? Now that we've had 64 players in a server, smaller resolutions have an information overflow. |
|
|
|
Column ideas:
typedef enum
{
SCOREBOARDTYPE_KILLS = 0,
SCOREBOARDTYPE_DEATHS,
SCOREBOARDTYPE_DAMAGE,
SCOREBOARDTYPE_POINTS,
SCOREBOARDTYPE_LIVESLEFT,
SCOREBOARDTYPE_FLAGDEFENSE,
SCOREBOARDTYPE_WINS,
SCOREBOARDTYPE_PING,
SCOREBOARDTYPE_TIME,
SCOREBOARDTYPE_VOTE, // (Yes) or (No) column
SCOREBOARDTYPE_ISREADY, // If the player is ready to go on
SCOREBOARDTYPE_NAME,
SCOREBOARDTYPE_CUSTOM_0, // Custom fields set by ACS
SCOREBOARDTYPE_CUSTOM_1,
SCOREBOARDTYPE_CUSTOM_2,
SCOREBOARDTYPE_CUSTOM_3,
SCOREBOARDTYPE_CUSTOM_4,
SCOREBOARDTYPE_MAX
} e_ScoreboardScoreType;
|
|
|
|
|
|
|
|
|
|
Since the scoreboard now allows for customization with the SCORINFO lump, in addition to custom CVARs to alter the aesthetics of the scoreboard, this can now be marked as resolved. Great work, Kaminsky.
If anyone wishes any additional features, they should make separate requests for them. |
|