Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add WinnerIndex to OverallType #25

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

a-sink-a-wait
Copy link

@a-sink-a-wait a-sink-a-wait commented Jun 26, 2020

Mainly looking for feedback; am I on the right track here? Don't want to commit any more time if I am way off base.

I've implemented a winnerIndex property from my understanding of just digging through the code. This is in an effort to display the winner in the replays folder of the desktop application.

@a-sink-a-wait a-sink-a-wait changed the title Feature/export winner Add WinnerIndex to OverallType Jun 26, 2020
@@ -67,6 +69,23 @@ export function generateOverallStats(
return overall;
}

function determineWinner(playerStocks: StockType[], opponentStocks: StockType[]) : number {

if (playerStocks.length == 0 && opponentStocks.length == 0) return -1; //unknown winner;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we avoid returning undefined by taking out the if statement and moving the return -1 to the end of the function, will avoid weird edge cases or missing data errors later.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good!

@a-sink-a-wait
Copy link
Author

Updated this. Still need tests and some cleanup. Different approach, need some feeback.

@vinceau
Copy link
Member

vinceau commented Jun 26, 2020

For starters, I'm not really sure I agree with having the winner index as a part of the overall stats object. Since it's not really a stat.

But some comments on the code itself: I think it would be better to export a helper function that gets imported instead of having the winner determination code in the SlippiGame class directly. Additionally you could probably use a reduce instead of a forEach (see here for inspiration).

The key issue with adding the winner (I assume for the purpose of displaying in the desktop app) is that it requires processing the entire file for all the frames getStats() which is not performant. People have already complained about the desktop app being slow already and at the moment, it only loads the metadata. This is the primary reason why winner is not included at the moment and this method of determining the winner will not solve that.

@a-sink-a-wait
Copy link
Author

@vinceau Solid feedback. A reduce is definitely possible. I wanted something working and reviewable.

Is this worth implementing at the moment? Should we hold off?

@vinceau
Copy link
Member

vinceau commented Jun 26, 2020

@a-sink-a-wait I think it would be best to hold off for the time being. Fizzi has talked about potentially adding caching of sorts and pagination which would allow processing entire SLP files to be less costly in the long run. But until then, even if this was to be merged you probably wouldn't see its use in the desktop app because the performance hit would be too costly.

@a-sink-a-wait
Copy link
Author

a-sink-a-wait commented Jun 27, 2020

I know there's this PR as well that aims to improve performance of the desktop App. project-slippi/slippi-launcher#58

Would it be worth trying to combine these two implementations?

@NikhilNarayana
Copy link
Member

I know there's this PR as well that aims to improve performance of the desktop App. project-slippi/slippi-desktop-app#58

Would it be worth trying to combine these two implementations?

It would be worth know what kind of performance we would be getting if combined.

@a-sink-a-wait
Copy link
Author

I'll take a look into this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants