-
-
Notifications
You must be signed in to change notification settings - Fork 72
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
Weird behavior using -r #35
Comments
stat.ink's Though something weird may be going on here – you're saying they're getting uploaded when you're using |
I got the same issue, after run -r it uploaded my first turf war played at 9/9. |
I have only played like 5 regular turf war battles and then I just started playing ranked only (like 450 games). I suppose I can avoid this issue by just waiting for -M mode to catch up before closing it so I don’t have to run -r. |
@fetus-hina let me know if you have any thoughts here, bringing this to your attention just in case |
@Peri0dic That's a good point, when I add in the functionality (soon I hope) to check for remaining battles after you exit I guess you may still get this issue when running |
stat.ink does not do such processing. Note: |
This only happens if you play essentially only TW or ranked and not much of the other mode. For example:
This could be fixed in two ways, as I see it:
|
Stat.ink now (v2.156.0) deployed the feature.
|
Thank you Hina!! The 200->500 change will help reduce occurrence of this error for those using older versions of s3s as well. |
Maybe you could just maintain a cache of 3 ids. One most recent TW battle id that has already been uploaded to stat.ink, one most recent uploaded battle id for Anarchy battle and one most recent uploaded battle for private battle. (Perhaps save them into In this case, every time you fetch the {150} records from SplatNet3, just check wether the cached id exist in the SplatNet3 records. If yes, it means only the battles after the cached id are going to be uploaded. Otherwise, all records from SplatNet3 are fresh and need to be uploaded. p.s. Maybe use the time stamp of each battle instead of battle ids since there may be duplicates as mentioned in previous issues (#29)? |
@CafeAuLait-CC Having to save a ton more information locally on-disk is not ideal. Battle timestamp is also used to compute the UUID. But stat.ink has changed how it works so now this issue should be resolved. |
Cool. Thank you. |
After I uploaded all of my exported matches yesterday -r was working as intended and blocking previous battle uploads. But today it has started re-uploading the only 5 turf war matches I played on day 1, while still skipping previously uploaded ranked battles.
The text was updated successfully, but these errors were encountered: