project-slippi / Ishiiruka

GNU General Public License v2.0
330 stars 142 forks source link

Display rank information on ranked CSS #391

Open walz0 opened 1 year ago

walz0 commented 1 year ago

Paired with slippi-ssbm-c https://github.com/project-slippi/slippi-ssbm-c/pull/8

DAT File Changes:

Adds a new JOBJDesc to slpCSS.dat that contains a TextureAnimation of all of the rank icons (similar to how the game displays stock icons). I'm using RGB5A3 as the image format because CMP was leaving compression artifacts on the images and RGBA8 was producing a very large file (ran out of memory). The current file is 551kb which is small enough that the game runs without any memory issues but it may be a problem in the future if any new files are added to the CSS. Also worth mentioning that using the CMP image format reduces the file size to 239kb.

New slpCSS.dat structure:

Overview:

The game sends an EXI command to dolphin to get the rank info through a curl request. This could be changed to something more efficient that doesnt require a new request each time the user goes to the CSS. Fizzi suggested that the matchmaking service return an expected ELO change which would significantly reduce the number of requests to the server: https://discord.com/channels/328261477372919811/733158076827303997/1060705864878657606 If this is the optimal route it may also be worth returning the opponents rank when a match is found so that it can be displayed in the GamePrep scene (suggested by altf4) https://discord.com/channels/328261477372919811/733158076827303997/1060387305501769809

Currently the only rank information that is displayed is the icon and the rating ordinal. If a user hasnt completed their placement matches for the season (ratingUpdateCount < 5) the question mark icon will be shown with a message telling them how many matches they need to play to get a rank.

User without a rank:

image

User with a rank:

image

Additional Notes

There have been instances where the game has crashed when executing the curl request on the CSS (maybe something to do with running LoadMatchState at the same time?). This hasn't been happening to me recently and I've had a few people testing the build and it doesn't seem to be crashing at all for them. Hopefully someone more knowledgeable can provide some insight and this can be debugged.

rapito commented 1 year ago

😯🙌🏻 looking good!

I know this is a draft but some notes:

The rank thresholds should not be coded in dolphin but instead come directly from the server. If those values change then you will be showing an incorrect badge. (I understand this is not public info, but Fizzi might shed some more light to it)

Furthermore, regarding your crash, I havent seen the asm/c code yet, but you might want to load this up using a proc instead so it is a faux-asynchronous process instead. This might prevent you from getting crashes.

likevin97 commented 10 months ago

Curious why this hasn't been merged? This is an awesome feature that seems to have been sitting for a few months @JLaferri

JLaferri commented 10 months ago

Curious why this hasn't been merged? This is an awesome feature that seems to have been sitting for a few months @JLaferri

I have a few problems with the implementation of this feature and I think there would need to be additional considerations. I discussed one of my issues with Walz here: https://discord.com/channels/328261477372919811/733158076827303997/1139032666818216069

But here are my full list of concerns:

  1. We would likely need a way to turn it off for people that don't want to see their rank changes (ladder anxiety)
  2. If the report is a bit slow (which I actually think will be quite common), this method of fetching the new rating would not work and people would think that their report did not go through.
  3. Additional network requests

The second issue is the bigger problem. One way to fix it is to have the backend tell you before a match the player's next rating both on a win and loss. Then upon a win/loss being detected, you can adjust the rating to the expected value. This method has a downside too though. Considering that p2p reporting is pretty troublesome there are times when reports fail to adjust rating. In this case the client would show that a result happened but the backend would not agree and people would similarly be confused about what happened.

I should also note that the ratings at the start of the match may not necessarily match the ratings at the end of the match. This is because ratings can change mid-set in the case of a late report because of cheating detection. This would cause the rating displayed to be incorrect.