izaaksulka / overwatch-2-stats

Collects stats from Overwatch 2 games. Currently using tesseract to read the stats from screenshots of the scoreboard at the end of the game.
0 stars 0 forks source link

Help me use this to feed an API #1

Closed BrLyes closed 2 years ago

BrLyes commented 2 years ago

Hello i'm working on an API that stores player stats and an application that displays them, it's still very early in the developpement so i do not wish to share it public yet. If possible can this code be modified so it sends stats at the end of each game ?

Please Can we collaborate on this ? i can share more details just contact me here: lyes.brouri@gmail.com

izaaksulka commented 2 years ago

That is definitely possible. It sounds like the API you're talking about will be hosted on a server? And you want to automatically collect the stats when the game ends, and send a web request to your server so that it can update a database and insert a new instance of game stats? If that's about the right idea, this is a something we wanted to do eventually anyway, so we'd be interested in collaborating on it.

As for modifying the code, it wouldn't be that hard to make it send the data to an API. Here's some info:

Right now this repo only has 2 python modules, and they each do something pretty simple.

  1. Screenshot parser. All it does is define a function that can take a screenshot of a scoreboard from an OV2 game and return a big json object with all the data it could find. If you want to call it from the command line, it an be run standalone.
  2. CSV builder. It imports the screen shot parser module to use the parsing function. Then it just takes some directories that have screenshots in them and parses all of them, then exports a single CSV file with all the data. We use this so we can analyze the data in spreadsheet software.

Based on that, I think you probably only care about the parser module. You could pass a screenshot to it, and the objects that come out of it can be sent to your API. I think you don't want to modify the code so much as make a new python module that calls the parse function and sends the results to the server.

Some problems that need to be solved:

  1. Right now you need to manually screenshot the end of game screen and save it somewhere. (We are exploring making a program that runs in the background and takes a screenshot every time you press tab, then uses the last one for stats, or possibly all of them to have 'stats over time' throughout the course of a game).
  2. The screenshots don't say anything about winning of losing (or at least it's not guaranteed, sometimes you can see it in the background). Right now we just save the screenshots to a 'wins' directory if you won, or a 'losses' directory if you lost.
  3. If we made a program that runs in the background and watches the screen to collect stats, it needs to have a way of detecting when a new game begins. It might be possible to just watch the game time in the screenshots for when it resets.
  4. The data is pretty dirty right now. Tesseract does an alright job, but seems to struggle with the italicized names. Also, when a field is missing (usually because it's 0) the output often has random characters in it instead of numbers. Some kind of data sanitation needs to happen and I haven't figured out the best way to do it yet. This is a very solvable problem though.
  5. The only screenshot size supported right now is the one I play on (2440x1440). Adding more resolutions to the parser should be trivial, but it will be a little tedious.

Let us know what you're thinking.

BrLyes commented 2 years ago

Hello, thank you for your response, it's great to hear that we can collaborate on this!

Yes the API i'm working on is hosted on a server, it's not documented yet and only support a limited number of stats but i have plans to expend it. For now it has two parts the API and the application, the API is basically handling the backend stuff while the application offers rendering.

To the list of problems i will add the following: 6- The API requires authentification so the Screenshot parser (SP) needs to send a token with the request to store new stats for the player. 7- The API stores stats by character, it needs the character name to be sent with the payload. 8- Each stat is attached to a game within the API and each game requires a match_date in UTC, i do not know much about python but can it get the user timezone and the offset ?

Regarding potential solutions to problems: 2- The API does not store win/loses yet either so we can leave that aside for now 4- The API can validate the data if that helps. 6- Can we attach a config file with the SP like a config.json that contains (among other things) the auth token, later on we can use to also store the user screen resolution for 5. (maybe).

I do not know much about Python so i doubt i'll be of big help when it comes to the source code but i'll see what i can do.

I'll send you and invite to the private repos so you can take a look at the API and the App.

mcdona64 commented 2 years ago

Hello!

Sorry I am a bit late to the party here. A config file with auth tokens would not be bad at all. I was thinking we would probably compile our python into a windows service using win32serviceutil or similar. It would be fine and secure to bake the auth key into that service. I took a quick look through your repo and it looks cool. Love the idea and we were thinking of doing something similar. I know you said you are not super strong in python but I might recommend looking into django. It can do what you are trying to do nicely and is easy to integrate with vue.js. I might work on it a little in our repo too. (I use it for work and need practice lols). Let us know if you need and or want anything from our repo. Also sorry if progress at least from me is slow. I am a lazy dev 😜.

Thanks and excited to collaborate with you!

On Sun, Oct 23, 2022 at 4:03 AM Lyes BROURI @.***> wrote:

Hello, thank you for your response, it's great to hear that we can collaborate on this!

Yes the API i'm working on is hosted on a server, it's not documented yet and only support a limited number of stats but i have plans to expend it. For now it has two parts the API and the application, the API is basically handling the backend stuff while the application offers rendering.

To the list of problems i will add the following: 6- The API requires authentification so the Screenshot parser (SP) needs to send a token with the request to store new stats for the player. 7- The API stores stats by character, it needs the character name to be sent with the payload. 8- Each stat is attached to a game within the API and each game requires a match_date in UTC, i do not know much about python but can it get the user timezone and the offset ?

Regarding potential solutions to problems: 2- The API does not store win/loses yet either so we can leave that aside for now 4- The API can validate the data if that helps. 6- Can we attach a config file with the SP like a config.json that contains (among other things) the auth token, later on we can use to also store the user screen resolution for 5. (maybe).

I do not know much about Python so i doubt i'll be of big help when it comes to the source code but i'll see what i can do.

I'll send you and invite to the private repos so you can take a look at the API and the App.

— Reply to this email directly, view it on GitHub https://github.com/izaaksulka/overwatch-2-stats/issues/1#issuecomment-1288072794, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADK52FZLTNEZYPWH5R6FCE3WEUEO3ANCNFSM6AAAAAARKMOUHY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

izaaksulka commented 2 years ago

Comment on this: 7- The API stores stats by character, it needs the character name to be sent with the payload. Right now, our end of game stats don't know anything about the character. We could add coordinates to the parser for where it appears on the scoreboard. This will only get the character name for the character the player taking the screenshot is playing though.

We didn't do this yet because if the player changes characters partway through the game, their stats don't reset, so they would be all wrong.

mcdona64 just added a class to automatically take screenshots whenever the player presses tab. We might be able to use this to continuously record stats throughout the game, and use the timestamps to know which stats apply to which character, with a little leakage between characters.

BrLyes commented 2 years ago

Sorry for the delay,

Hello! Sorry I am a bit late to the party here. A config file with auth tokens would not be bad at all. I was thinking we would probably compile our python into a windows service using win32serviceutil or similar. It would be fine and secure to bake the auth key into that service. I took a quick look through your repo and it looks cool. Love the idea and we were thinking of doing something similar. I know you said you are not super strong in python but I might recommend looking into django. It can do what you are trying to do nicely and is easy to integrate with vue.js. I might work on it a little in our repo too. (I use it for work and need practice lols). Let us know if you need and or want anything from our repo. Also sorry if progress at least from me is slow. I am a lazy dev 😜. Thanks and excited to collaborate with you! … On Sun, Oct 23, 2022 at 4:03 AM Lyes BROURI @.> wrote: Hello, thank you for your response, it's great to hear that we can collaborate on this! Yes the API i'm working on is hosted on a server, it's not documented yet and only support a limited number of stats but i have plans to expend it. For now it has two parts the API and the application, the API is basically handling the backend stuff while the application offers rendering. To the list of problems i will add the following: 6- The API requires authentification so the Screenshot parser (SP) needs to send a token with the request to store new stats for the player. 7- The API stores stats by character, it needs the character name to be sent with the payload. 8- Each stat is attached to a game within the API and each game requires a match_date in UTC, i do not know much about python but can it get the user timezone and the offset ? Regarding potential solutions to problems: 2- The API does not store win/loses yet either so we can leave that aside for now 4- The API can validate the data if that helps. 6- Can we attach a config file with the SP like a config.json that contains (among other things) the auth token, later on we can use to also store the user screen resolution for 5. (maybe). I do not know much about Python so i doubt i'll be of big help when it comes to the source code but i'll see what i can do. I'll send you and invite to the private repos so you can take a look at the API and the App. — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADK52FZLTNEZYPWH5R6FCE3WEUEO3ANCNFSM6AAAAAARKMOUHY . You are receiving this because you are subscribed to this thread.Message ID: @.>

No worries and i'm also very happy to work on this with you guys! i'll look into Django in this week

So i've been thinking around how we can integrate the SP and i think it would work best if we make it downloadable through the app i'm working on so that users dont have to fiddle too much around and instead of having the SP sends the data directly to the API i can work on a small electron app, Stats Sender (SS) that watchs for changes in a folder and reads the output of the SP (CSV, json format or something readable) and then sends it to the API, this way we can decouple complexity of this and you don't have to worry much about the auth i will handle it within SS.

If this approach is okay, here is what i need from the repo:

The Other approach is that the SP needs to handle submitting the data to the api endpoint and support a way to configure the auth key of the user. In this approach here is what i need from the repo:

The SP will need to :

Pardon my limited understand of windows services but will this make the SP:

This approach does expose one vuln that users can fake their stats but later on maybe we encrypt them or something...

Comment on this: 7- The API stores stats by character, it needs the character name to be sent with the payload. Right now, our end of game stats don't know anything about the character. We could add coordinates to the parser for where it appears on the scoreboard. This will only get the character name for the character the player taking the screenshot is playing though.

This is perfect, i only need the character name of the player taking the screenshot.

We didn't do this yet because if the player changes characters partway through the game, their stats don't reset, so they would be all wrong.

I just tested in game switched from an Ashe to Orisa and did more tests in custom games and my stats got reset each time, they also seem to save if you go back to a previous character. In what game mode or what characters did it not reset for you ? that might be a bug within Overwatch 2.

mcdona64 just added a class to automatically take screenshots whenever the player presses tab. We might be able to use this to continuously record stats throughout the game, and use the timestamps to know which stats apply to which character, with a little leakage between characters.

Based on my reply above this sounds the best, the latest timestamps should be the latest stats for a specific character!

Sorry again for the time it took me to reply i had alot of thinking around it and i hope i kept things clear, do you guys have discord ? it will make things easier to keep each other in the loop and discuss it in a voice chat here is my discord tag: Beermarket#9113

BrLyes commented 2 years ago

So after trying to modify the script and make it read more data, i finally understand how difficult it is so implement a fullproof OCR for score board... i dont know if this is the right way or i should try to catch and decrypt packets... i will pause this for now thank you both for your help i have learned quite alot of things from this experience :)