After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 530797 - Only winner can get high score
Only winner can get high score
Status: RESOLVED OBSOLETE
Product: tali
Classification: Applications
Component: general
3.11.x
Other All
: Low normal
: ---
Assigned To: Mario Wenzel
Tali maintainer(s)
Depends on: 745492
Blocks:
 
 
Reported: 2008-04-30 20:46 UTC by Simon McNeilly
Modified: 2018-05-22 12:28 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20


Attachments
High score for people who don't win is also recorded if they score high enough. (991 bytes, patch)
2014-09-07 13:04 UTC, Sahil Sareen
reviewed Details | Review
High score for people who don't win is also recorded if they score high enough. (4.95 KB, patch)
2014-09-07 18:56 UTC, Sahil Sareen
none Details | Review
High score for people who don't win is also recorded if they score high enough. (3.17 KB, patch)
2014-09-08 06:21 UTC, Sahil Sareen
reviewed Details | Review

Description Simon McNeilly 2008-04-30 20:46:57 UTC
Please describe the problem:
Only the winner of a game is entered into the high scores, even if the runner up beat the previous best they aren't recognized for the top ten.

Steps to reproduce:
1. Clear high scores (or play a game with nice easy to beat scores)
2. Play a game with multiple human players
3. Each player gets a score that is high enough to get on high score table.


Actual results:
Only the absolute winner gets entered on the high score table.

Expected results:
Each player that got a high score should be entered on the high score table.

Does this happen every time?
Yes it does.

Other information:
Comment 1 Michael Catanzaro 2014-02-03 23:22:36 UTC
I agree that even if you lose, you should be entered into the high scores if your score was high enough.
Comment 2 Sahil Sareen 2014-08-21 15:41:25 UTC
Can I take this up?
Comment 3 Mario Wenzel 2014-08-21 15:59:03 UTC
Sure, it's up for grabs.
Comment 4 Sahil Sareen 2014-09-07 13:04:30 UTC
Created attachment 285612 [details] [review]
High score for people who don't win is also recorded if they score high enough.
Comment 5 Michael Catanzaro 2014-09-07 15:36:33 UTC
Review of attachment 285612 [details] [review]:

Looks good, thanks!  There's a few small things that need fixed before I can commit this, though.

Be sure to set your email address with 'git config --global user.email YOURADDRESS'.

Also, please use a more descriptive commit message. Take a look at our rules for formatting commit messages: https://wiki.gnome.org/Git/CommitMessages (Ignore the section "linking to bugs" at the end -- I will add a link to the bug when I push your commit.)

This patch does add the winner into the list of high scores, but it doesn't bring up the scores dialog. You should always open the scores dialog if the player made the top ten (indicated by the return value of games_scores_add_plain_score).

::: src/gyahtzee.c
@@ +161,3 @@
   gint pos;
   gchar *message;
+  int total;

Since this variable is only used inside the scope of the for loop, you should declare it inside the loop instead.

@@ +183,3 @@
+  /* add high scores for humans that didn't win */
+  for (i = 0; i < NumberOfHumans; i++) {
+    total = total_score(i);

In GNOME code we always leave one blank space before the opening parenthesis of a function call: total_score (i).

@@ +184,3 @@
+  for (i = 0; i < NumberOfHumans; i++) {
+    total = total_score(i);
+    if ( i != winner && total != -winner) {

And we never leave a blank space after an opening parentheses: if (i

What is the && total != -winner condition for?  It looks like winner is the ID of the player who won, so -winner isn't any meaningful value, right?
Comment 6 Sahil Sareen 2014-09-07 18:56:05 UTC
Created attachment 285616 [details] [review]
High score for people who don't win is also recorded if they score high enough.

Fixed review suggestions by mcatanzaro.
Comment 7 Mario Wenzel 2014-09-07 19:36:41 UTC
Can you please squash your changes and rebase them against the current master. There's much unneeded clutter in this latest patch.
Comment 8 Michael Catanzaro 2014-09-07 19:52:03 UTC
Wow, you confused our review tool, good job!

The patch you attached is actually two separate patches combined in the same file. Can you fix that please?
Comment 9 Sahil Sareen 2014-09-08 06:21:05 UTC
Created attachment 285632 [details] [review]
High score for people who don't win is also recorded if they score high enough.
Comment 10 Mario Wenzel 2014-09-08 15:27:15 UTC
Update on this issue:

If you have a few players that reach the high score table then their scores should be entered with the playername they set up in the tali player settings or the dialog should be pre-filled with their names.

We will wait with merging this patch until the scores library supports this.
Comment 11 Michael Catanzaro 2014-09-08 15:49:38 UTC
Review of attachment 285632 [details] [review]:

Hm, Mario, we forgot that 3.12 doesn't allow multiple players in the high scores... that's coming back with libgames-scores, though.

I'll try to update tali and this patch for libgames-scores soon. Thanks Sahil!
Comment 12 André Klapper 2015-02-06 23:43:45 UTC
(In reply to comment #11)
> I'll try to update tali and this patch for libgames-scores soon. Thanks Sahil!

Michael: ping - Any news?
Comment 13 Sahil Sareen 2015-02-07 06:06:47 UTC
I can re-do any code changes if required.
Comment 14 Michael Catanzaro 2015-02-07 14:26:02 UTC
libgames-scores still needs a couple days more work to get ready, which I can't devote right now. :(  Probably for the next cycle....
Comment 15 Sahil Sareen 2016-05-07 11:50:52 UTC
How are we doing here?
Comment 16 Mario Wenzel 2016-05-07 11:53:55 UTC
We wanted to finalize libgames support during the 3.22-cycle. Maybe we should meet up (monday evening?) and draw up a schedule and a rough outline of what's to be done.
Comment 17 Michael Catanzaro 2016-05-07 14:11:13 UTC
(In reply to Mario Wenzel from comment #10)
> Update on this issue:
> 
> If you have a few players that reach the high score table then their scores
> should be entered with the playername they set up in the tali player
> settings or the dialog should be pre-filled with their names.
> 
> We will wait with merging this patch until the scores library supports this.

Hm, I forgot about this, we hadn't considered it when designing the API for the library; in other games, we just decided not to save high scores when there are multiple human players.

Currently we have an add_score function that opens the score dialog automatically if the score is determined to be a high score, with the pre-filled name for the score matching the current UNIX user account ("Michael Catanzaro"). We can add the ability to configure the pre-filled name by exposing an add_score method that takes a Games.Score object instead of a long, then you'll be able to set the player name on the score object in advance.

If we want to allow saving multiple scores with one run of the scores dialog, though, that would take more work. Currently you can only add one score at a time, and the high scores dialog will open exactly once for that score. I guess we could add a function that stores a whole list of scores all at once. The signature might be:

public async bool Games.Scores.Context.add_scores (Gee.List<Games.Scores.Score> score, Games.Scores.Category category, Cancellable? cancellable) throws Error

Not sure when I'll have time to work on this, but it should be an easy project if anyone wants to take it up.
Comment 18 GNOME Infrastructure Team 2018-05-22 12:28:26 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/tali/issues/3.