8 ms·

But distrusting the client doesn’t solve the problem. If a user can see through a wall locally how can ‘distrusting’ anything fix that? What is there to distrus

But distrusting the client doesn’t solve the problem. If a user can see through a wall locally how can ‘distrusting’ anything fix that? What is there to distrust? All inputs are genuine.

Sebb767 5y ago
> If a user can see through a wall locally how can ‘distrusting’ anything fix that? The fact that the client can remove the wall and see something behind it is due to the fact that the client is trusted to do the hiding. An untrusted client would not receive the enemy position until the enemy is visible. This, however, comes with the drawback that the server needs to do the culling - That's why pretty much nobody does it right now. Aimhacks would still be possible, of course, but client-side anti-cheat can't prevent those either.
- chrisseaton 5y ago
  Right it’s not a realistic suggestion as not even the client does it in software!
  - CyberDildonics 5y ago
    Why do you think that? The server needs to at the very least trace a line for a shot. There is nothing difficult or slow about that. Before you say that it is done with a z-buffer or something similar, think about third person camera angles or how older games did the same thing. You might want to pull back on being so certain if you don't have experience with game engines or graphics.
    - chrisseaton 5y ago
      > Why do you think that? The server needs to at the very least trace a line for a shot. There is nothing difficult or slow about that. Before you say that it is done with a z-buffer or something similar, think about third person camera angles or how older games did the same thing. You might want to pull back on being so certain if you don't have experience with game engines or graphics. But... it is done with a z-buffer. If an opponent is obscured behind a nearby pillar or something, that's not going to be culled in software - that's done by the hardware z-buffer as part of the render process. You can see this for yourself if you look at a game being run with wireframe rendering. You'll see it's in the same render node so it's still rendered - it's just obscured by closer geometry. And it's how some cheats actually work - they basically turn the wireframe back on! 'Tracing a shot' is casting one single ray. For example read this article someone else linked https://technology.riotgames.com/news/demolishing-wallhacks-valorants-fog-war https://technology.riotgames.com/news/demolishing-wallhacks-... and look at the last animation.
      - CyberDildonics 5y ago
        You are conflating needing information about player position with visibility of individual polygons. Also you are forgetting that you just said that line of sight was done in hardware and you didn't explain how that would work for a server testing if shots actually hit. > You can see this for yourself if you look at a game being run with wireframe rendering. You'll see it's in the same render node so it's still rendered What does this even mean? What is "it" here and what is a "render node" ? There are hierarchies of transforms and players are going to be separate from the environment. This doesn't actually mean anything. > it's just obscured by closer geometry. And it's how some cheats actually work - they basically turn the wireframe back on! Yes, you are restating the context of what people are talking about, not what is actually being talked about, which is the timing of when the server should send visibility information, which is what your link is actually about. Your link is actually directly contradicts what you are saying since it uses both an expanded bounding box based motion extrapolation and precomputed visibility, neither of which has anything to do with a z-buffer.
        chrisseaton 5y ago
        Look at the last illustration in that article. Can you see how the red outline of the opponent appears while they're obscured behind the pillar? When that red outline appears it's showing that the opponent is now being rendered, and that the z-buffer is being used to obscure them from behind the pillar. This discussion is about how to make the red outline not appear until the opponent is actually visible. The article goes into lots of ways to make the red outline appear later, but it still appears before the opponent is actually visible on screen. That's the issue that people want to solve. Consider an example of an opponent with just one pixel of their gun visible around a corner. How do you send that information to the client without telling them there's an opponent there, so that the user has to actually see the pixel? You'd have to just send that one pixel, right? Now we're talking about rendering server-side!
        CyberDildonics 5y ago
        " When that red outline appears it's showing that the opponent is now being rendered, and that the z-buffer is being used to obscure them from behind the pillar." Yeah, that's game rendering in the engine. That's visualizing something, not illustrating how the server is doing it. Did you actually read and understand your own link? "That's the issue that people want to solve." No it isn't, you misunderstood your own link to the point that you have it backwards. The server not rendering the entire game from each person's perspective every for every player every frame. The problem is being able to see every player walking around all the time. Think for a moment what would happen if the server actually had perfect visibility - by the time you can see them it is already too late. You should be able to see them and then the server starts sending you a position. By the time you know you should see them, you should have already seen them and the other player pops into frame. That isn't even buried in your own link, it's at the very top. "Consider an example of an opponent with just one pixel of their gun visible around a corner. How do you send that information to the client without telling them there's an opponent there, so that the user has to actually see the pixel? You'd have to just send that one pixel, right? Now we're talking about rendering server-side!" This is gibberish and is a lot like Frank Abignail trying to BS pilots. Once again your own link explains why this is nonsense from a lot of different angles, did you even read what you linked or did you just look at the pictures? It explains everything clearly.
- wildbook 5y ago
  Valorant specifically actually does this to a degree, and there was a quick article written by one of their anti-cheat developers that roughly explains their approach. https://technology.riotgames.com/news/demolishing-wallhacks-valorants-fog-war https://technology.riotgames.com/news/demolishing-wallhacks-...
pbhjpbhj 5y ago
Question, why can users see through walls locally, seems like there should be some sort of occlusion? I guess it's too slow to calculate and causes too much server-side processing?
- wolrah 5y ago
  > I guess it's too slow to calculate and causes too much server-side processing? Bingo, game servers need to be as lightweight as possible because whatever calculations they have to run need to run per player per tick. Detailed occlusion calculations would be impractical, so at best it's very rough. And of course you don't want a situation where an opposing player isn't even seen until they've already shot you, so it needs to err on the side of visibility. Every latency-sensitive online game has to make a bunch of tradeoffs between performance and security, and performance is generally more important.
weberer 5y ago
Then the server should never send them information on what's behind the wall.
- chrisseaton 5y ago
  You want to render all graphics on the server? I’m not sure that’s really a tractable suggestion.
  - CyberDildonics 5y ago
    Why would that be necessary? You realize the server already has to do a line of sight calculation to determine if a shot hits right?
    - chrisseaton 5y ago
      Think about many times a second you have to trace a shot. Now think about how many times a second you'd need to trace from every pixel on the screen to every part of the geometry on every opponent in order to check if it was visible or not to see if a player was legitimately able to view any part of their opponent. For example read this article someone else linked https://technology.riotgames.com/news/demolishing-wallhacks-valorants-fog-war https://technology.riotgames.com/news/demolishing-wallhacks-... and look at the last animation.
      - CyberDildonics 5y ago
        If you actually understood your own link you would see that there is no reason to trace every pixel on the screen when you can make a bounding box that covers motion and trace the vertices. Anyone familiar with game engine programming would never consider what you are saying. That link is a more in depth version of what I just said, ray casts are being done on the server for visibility and have nothing to do with rendering the game to do it. It is literally demonstrating that they are already doing what people were wondering about.
        5y ago

But distrusting the client doesn’t solve the problem. If a user can see through a wall locally how can ‘distrusting’ anything fix that? What is there to distrust? All inputs are genuine.

Sebb767 5y ago

> If a user can see through a wall locally how can ‘distrusting’ anything fix that? The fact that the client can remove the wall and see something behind it is due to the fact that the client is trusted to do the hiding. An untrusted client would not receive the enemy position until the enemy is visible. This, however, comes with the drawback that the server needs to do the culling - That's why pretty much nobody does it right now. Aimhacks would still be possible, of course, but client-side anti-cheat can't prevent those either.

chrisseaton 5y ago
Right it’s not a realistic suggestion as not even the client does it in software!
- CyberDildonics 5y ago
  Why do you think that? The server needs to at the very least trace a line for a shot. There is nothing difficult or slow about that. Before you say that it is done with a z-buffer or something similar, think about third person camera angles or how older games did the same thing. You might want to pull back on being so certain if you don't have experience with game engines or graphics.
  - chrisseaton 5y ago
    > Why do you think that? The server needs to at the very least trace a line for a shot. There is nothing difficult or slow about that. Before you say that it is done with a z-buffer or something similar, think about third person camera angles or how older games did the same thing. You might want to pull back on being so certain if you don't have experience with game engines or graphics. But... it is done with a z-buffer. If an opponent is obscured behind a nearby pillar or something, that's not going to be culled in software - that's done by the hardware z-buffer as part of the render process. You can see this for yourself if you look at a game being run with wireframe rendering. You'll see it's in the same render node so it's still rendered - it's just obscured by closer geometry. And it's how some cheats actually work - they basically turn the wireframe back on! 'Tracing a shot' is casting one single ray. For example read this article someone else linked https://technology.riotgames.com/news/demolishing-wallhacks-valorants-fog-war https://technology.riotgames.com/news/demolishing-wallhacks-... and look at the last animation.
    - CyberDildonics 5y ago
      You are conflating needing information about player position with visibility of individual polygons. Also you are forgetting that you just said that line of sight was done in hardware and you didn't explain how that would work for a server testing if shots actually hit. > You can see this for yourself if you look at a game being run with wireframe rendering. You'll see it's in the same render node so it's still rendered What does this even mean? What is "it" here and what is a "render node" ? There are hierarchies of transforms and players are going to be separate from the environment. This doesn't actually mean anything. > it's just obscured by closer geometry. And it's how some cheats actually work - they basically turn the wireframe back on! Yes, you are restating the context of what people are talking about, not what is actually being talked about, which is the timing of when the server should send visibility information, which is what your link is actually about. Your link is actually directly contradicts what you are saying since it uses both an expanded bounding box based motion extrapolation and precomputed visibility, neither of which has anything to do with a z-buffer.
      - chrisseaton 5y ago
        Look at the last illustration in that article. Can you see how the red outline of the opponent appears while they're obscured behind the pillar? When that red outline appears it's showing that the opponent is now being rendered, and that the z-buffer is being used to obscure them from behind the pillar. This discussion is about how to make the red outline not appear until the opponent is actually visible. The article goes into lots of ways to make the red outline appear later, but it still appears before the opponent is actually visible on screen. That's the issue that people want to solve. Consider an example of an opponent with just one pixel of their gun visible around a corner. How do you send that information to the client without telling them there's an opponent there, so that the user has to actually see the pixel? You'd have to just send that one pixel, right? Now we're talking about rendering server-side!
        CyberDildonics 5y ago
        " When that red outline appears it's showing that the opponent is now being rendered, and that the z-buffer is being used to obscure them from behind the pillar." Yeah, that's game rendering in the engine. That's visualizing something, not illustrating how the server is doing it. Did you actually read and understand your own link? "That's the issue that people want to solve." No it isn't, you misunderstood your own link to the point that you have it backwards. The server not rendering the entire game from each person's perspective every for every player every frame. The problem is being able to see every player walking around all the time. Think for a moment what would happen if the server actually had perfect visibility - by the time you can see them it is already too late. You should be able to see them and then the server starts sending you a position. By the time you know you should see them, you should have already seen them and the other player pops into frame. That isn't even buried in your own link, it's at the very top. "Consider an example of an opponent with just one pixel of their gun visible around a corner. How do you send that information to the client without telling them there's an opponent there, so that the user has to actually see the pixel? You'd have to just send that one pixel, right? Now we're talking about rendering server-side!" This is gibberish and is a lot like Frank Abignail trying to BS pilots. Once again your own link explains why this is nonsense from a lot of different angles, did you even read what you linked or did you just look at the pictures? It explains everything clearly.
wildbook 5y ago
Valorant specifically actually does this to a degree, and there was a quick article written by one of their anti-cheat developers that roughly explains their approach. https://technology.riotgames.com/news/demolishing-wallhacks-valorants-fog-war https://technology.riotgames.com/news/demolishing-wallhacks-...

pbhjpbhj 5y ago

Question, why can users see through walls locally, seems like there should be some sort of occlusion? I guess it's too slow to calculate and causes too much server-side processing?

wolrah 5y ago
> I guess it's too slow to calculate and causes too much server-side processing? Bingo, game servers need to be as lightweight as possible because whatever calculations they have to run need to run per player per tick. Detailed occlusion calculations would be impractical, so at best it's very rough. And of course you don't want a situation where an opposing player isn't even seen until they've already shot you, so it needs to err on the side of visibility. Every latency-sensitive online game has to make a bunch of tradeoffs between performance and security, and performance is generally more important.

weberer 5y ago

Then the server should never send them information on what's behind the wall.

chrisseaton 5y ago
You want to render all graphics on the server? I’m not sure that’s really a tractable suggestion.
- CyberDildonics 5y ago
  Why would that be necessary? You realize the server already has to do a line of sight calculation to determine if a shot hits right?
  - chrisseaton 5y ago
    Think about many times a second you have to trace a shot. Now think about how many times a second you'd need to trace from every pixel on the screen to every part of the geometry on every opponent in order to check if it was visible or not to see if a player was legitimately able to view any part of their opponent. For example read this article someone else linked https://technology.riotgames.com/news/demolishing-wallhacks-valorants-fog-war https://technology.riotgames.com/news/demolishing-wallhacks-... and look at the last animation.
    - CyberDildonics 5y ago
      If you actually understood your own link you would see that there is no reason to trace every pixel on the screen when you can make a bounding box that covers motion and trace the vertices. Anyone familiar with game engine programming would never consider what you are saying. That link is a more in depth version of what I just said, ray casts are being done on the server for visibility and have nothing to do with rendering the game to do it. It is literally demonstrating that they are already doing what people were wondering about.
      - 5y ago