4 ms·

> This software was able to access information used internally by the Dota client that wasn't visible during normal gameplay, giving the cheater an unfair advan

> This software was able to access information used internally by the Dota client that wasn't visible during normal gameplay, giving the cheater an unfair advantage. I'm curious what this information was - does the Dota 2 client have access to all the game state including players hidden from view?

Festro 4y ago
So, there's a character in the game that has a passive ability that lets it recover HP faster if they are not being observed by the enemy. That ability necessitates a function that checks for enemy vision, from heroes or from static observer wards that you can buy. From an exploit perspective that is a huge boon to use for a variety of purposes. Lately it may have been used to allow exploiters to detect those purchaseable wards so that they can be countered and removed in gameplay.
- FartyMcFarter 4y ago
  Interesting. I would have thought such an ability would be implemented by increasing the HP on the server and then sending the new HP value to the client. But perhaps this is impractical for some reason.
  - Festro 4y ago
    I think it's a matter of network performance, and the visual bugs that you can create without due care in such a fast-paced online game. Valve have commented on this hero's mechanics, and issued fixes relating to client/server-side interactions within the past year in fact. But apparently, the exploiuts still exist. Their comments have been around how redoing such mechanics can cause undue lag between clients that need to be 'caught up with' as quickly as possible. Too long and a client could see something they shouldn't and get a competitive advantage. Valve don't want to have a server updating 10 clients on 10 different network connections if they can avoid it. The compromise is to do more client-side, but that leaves the system vulnerable to such exploits. Considering that the game includes fog of war, and invisibility mechanics, visual bugs from these systems do crop up a fair bit.
    - int_19h 4y ago
      Normally stuff like that would be done both client- and server-side, but the server would have the final say for shared game state purposes (which the client can of course ignore, but then it'll just desync).
  - tikkabhuna 4y ago
    I'm wondering what the client vs server is responsible for. I would have thought the server could have been responsible for adding/removing the buff where necessary. Curious as to how health regen is done in general. The server must have some sort of understanding of what it should be otherwise clients could set it to whatever they want.
brookst 4y ago
Don’t know about “all state”, but consider that the graphics are rendered client side, where the polygons are loaded into the GPU. The GPU checks for occlusion and renders what’s actually visible. The GPU is also responsible for shadows and reflections, both of which can come from offscreen or occluded objects. For that to work, the client needs to know at least where every player / model / polygon is within some range and field of view. As fast as the game moves and as much freedom as players have to change their position and heading, it’s likely that everything anywhere near the player is computed and sent to GPU.
Ekaros 4y ago
Not all state, but very often in networked game the client needs to know information of what is soon to be visible. Say two characters approaching each other with fog of war. For latency compensation it makes game feel better for this to be send to client sometime before client renders the other character.

Festro 4y ago

So, there's a character in the game that has a passive ability that lets it recover HP faster if they are not being observed by the enemy. That ability necessitates a function that checks for enemy vision, from heroes or from static observer wards that you can buy. From an exploit perspective that is a huge boon to use for a variety of purposes. Lately it may have been used to allow exploiters to detect those purchaseable wards so that they can be countered and removed in gameplay.

FartyMcFarter 4y ago
Interesting. I would have thought such an ability would be implemented by increasing the HP on the server and then sending the new HP value to the client. But perhaps this is impractical for some reason.
- Festro 4y ago
  I think it's a matter of network performance, and the visual bugs that you can create without due care in such a fast-paced online game. Valve have commented on this hero's mechanics, and issued fixes relating to client/server-side interactions within the past year in fact. But apparently, the exploiuts still exist. Their comments have been around how redoing such mechanics can cause undue lag between clients that need to be 'caught up with' as quickly as possible. Too long and a client could see something they shouldn't and get a competitive advantage. Valve don't want to have a server updating 10 clients on 10 different network connections if they can avoid it. The compromise is to do more client-side, but that leaves the system vulnerable to such exploits. Considering that the game includes fog of war, and invisibility mechanics, visual bugs from these systems do crop up a fair bit.
  - int_19h 4y ago
    Normally stuff like that would be done both client- and server-side, but the server would have the final say for shared game state purposes (which the client can of course ignore, but then it'll just desync).
- tikkabhuna 4y ago
  I'm wondering what the client vs server is responsible for. I would have thought the server could have been responsible for adding/removing the buff where necessary. Curious as to how health regen is done in general. The server must have some sort of understanding of what it should be otherwise clients could set it to whatever they want.

brookst 4y ago

Don’t know about “all state”, but consider that the graphics are rendered client side, where the polygons are loaded into the GPU. The GPU checks for occlusion and renders what’s actually visible. The GPU is also responsible for shadows and reflections, both of which can come from offscreen or occluded objects. For that to work, the client needs to know at least where every player / model / polygon is within some range and field of view. As fast as the game moves and as much freedom as players have to change their position and heading, it’s likely that everything anywhere near the player is computed and sent to GPU.

Ekaros 4y ago

Not all state, but very often in networked game the client needs to know information of what is soon to be visible. Say two characters approaching each other with fog of war. For latency compensation it makes game feel better for this to be send to client sometime before client renders the other character.