Open JiaweiWu123 opened 3 years ago
That's an intended behavior. You can always go for memory reading if Riot allows it.
For my case, I am interested in displaying current game stats on a local LCD, and want to have a near real-time display of creepscore (among other stats), comparing it to targets based on game time, and comparing to the opponent CS. Currently, I'm unable to update in near real time since the API only updates every 10 cs as noted.
For spectators, this is even more troublesome as it prevents some abilities for broadcast teams to improve the accessibility of their streams to viewers, both with vision disabilities and also for new viewers learning the game watching the broadcasts. For our collegiate broadcasts, accessibility is very important, especially as we also have a lot of first time viewers not just to League of Legends, but also to Esports in general.
That's an intended behavior.
Do you know why it's that way?
Just Riot being Riot...
It was done out of an abundance of caution. We're adding real time data to an API that potentially provides a competitive advantage if leveraged by third party tools. As an example, knowing a jungler's cs count can lead to estimations of their jungle path and location. We may relax this in the future, but for now we have decided to floor to the nearest 10.
I feel like with the new (correction: not so new) rule that allows memory reading, this restriction is nothing short of an inconvenience for people who don't want to tinker around in the game's memory space since practically anyone with the required skill can acquire this information while staying perfectly within the policies, it's just more work as opposed to using the supported solutions.
It was done out of an abundance of caution. We're adding real time data to an API that potentially provides a competitive advantage if leveraged by third party tools. As an example, knowing a jungler's cs count can lead to estimations of their jungle path and location. We may relax this in the future, but for now we have decided to floor to the nearest 10.
Exact values do not provide an advantage if added to the activePlayer object. Would be a smart solution imo.
It was done out of an abundance of caution. We're adding real time data to an API that potentially provides a competitive advantage if leveraged by third party tools. As an example, knowing a jungler's cs count can lead to estimations of their jungle path and location. We may relax this in the future, but for now we have decided to floor to the nearest 10.
Exact values do not provide an advantage if added to the activePlayer object. Would be a smart solution imo.
I agree with you yet I don't think they will change this behavior anytime soon
Exact values would also be extremely valuable to spectators that are already on a 3 minute competitive integrity delay that again would be extremely helpful for broadcasters to use in their overlays and data displays. I have already noted one such necessary use case for this above in https://github.com/RiotGames/developer-relations/issues/416#issuecomment-790265535 as I would still like to ensure the broadcasts I air are in compliance relevant accessibility guidelines.
For anyone who stumbles upon this issue. It's not just rounded.
At it's current state it can return 70 when the actual creep stat of the person is around 200. I'm not 100% and too lazy to check in depth, but a wild guess that is related to having vision of the person during when they kill creeps
Bug Description
creepScore
updates in increments of 10Problem Description
When using the live client data API to request the player score using either the
GET activeplayer
orGET playerscores?summonerName=
endpoints, thecreepScore
property only updates in increments of 10Expected Result
creepScore
should update in increments of 1 (i.e. reflecting every creep score update)Actual Result
creepScore
updates in increments of 10 (starts at 0, then goes to 10, 20, 30 etc...). If the player has a creepscore in between said intervals, then the response will not update to reflect thatDeveloper Impact
It is difficult to accurately track the live creep score (in my case, I'm more interested to know when the player gets a last hit rather than the total creep score) using the live client data API. I am working around it by diffing the
currentGold
field, which seems to update correctly, however, there are a lot of edge cases to cover when using this method