SV_Invisible_To_Client (Anti-Wallhack)

I'd like to point out, as a former clan player in Quake, that flick turns require that the other entities are already networked

And that's in a lan environment....

Online, people can turn around 180 degrees in 200ms and still be behind their ping, if their ping is that high.

So as a rule, do not apply FOV culling on the server.

I played during the dialup days and had a couple of unusual binds like the 180 turn one (which people STILL use on DM6 to double teleporter without being vulnerable to attack), so don't get me wrong but 200 ms ping shouldn't be mainstream.

And I'm not sure abnormal accommodations should be made where the balance of scale works like this:

1. Cripple cheaters with radar
2. Or don't cripple cheaters with radar, accommodate the rare dialup or trans-Atlantic guy who more than likely isn't going to be able to hang with the pack. And if it is a team game, you don't want him on your team.

Of course, in live testing of this very much theoretical idea --- provided it worked to everyone's satisfaction which is no sure thing --- (decided to not finish sentence).

(New sentence ...)

I wonder if this could be used somehow to rather effectively detect bots. Hmmm.

So as a rule, do not apply FOV culling on the server.

I played during the dialup days and had a couple of unusual binds like the 180 turn one (which people STILL use on DM6 to double teleporter without being vulnerable to attack), so don't get me wrong but 200 ms ping shouldn't be mainstream.

Ahem, I was just yesterday playing on an east coast server at 160-200 ping. On ADSL2+ 16mbit with 1.5mbit upload.

For me, servers tend to START at 100ms and go up from there with distance, 60-80ms is rare, and 160-200 is very common.

But the problem I described on LAN comes in to play because the server typically runs at either sys_ticrate 0.05 (20fps, where for 50ms you don't see someone as you're turning around) or sys_ticrate 0.1 (10fps, where for 100ms you don't see someone), this is less of a problem at sys_ticrate 0.013338 (default in darkplaces) but of course that requires a low bandwidth network protocol and/or rate limiting to pull off effectively, and the ping time is still on top of that.

Also note that a few rare people play with panquake (which can see 360 degrees, with glquake rendering), or exceedingly rarely fisheyequake (which also can, but is software), and fov 120 is very common as well (as are 130, 135, 140), or playing widescreen on 3 monitors in darkplaces (AMD Eyefinity technology on a single card or NVIDIA SLI Surround Vision), which means that about the only FOV that is "safe" to impose (and still annoy the panquake and ultra-widescreen players) is 140.

So I really do not advise this approach.

private intercontinental games with the server on one side's dsl connection can easily reach 300ms.
UK vs Austrailia and 250ms is kinda expected.
this is with quakeworld's higher tick rates.

someone that's cunning would just change their bot/radar to spin periodically if there's no players nearby, which you can do without affecting movement. all you gain is a new generation of cheats, comic movement, and the better/laggier players getting annoyed that they have to wait after hearing teleport sounds behind them, while the person that teleported in has a free kill.

you get a lot of snap reflexes in reaction to sounds.

someone that's cunning would just change their bot/radar to spin periodically if there's no players nearby

Good point.

With the extra functionality I added to R_LightPoint to collide against submodels, I have to say that in general that function works better for this purpose than the existing anti-wallhack functions at least that I have tried and that are in this thread.

I have been doing stuff with "ghost players" and I don't want the ghosts to pass out-of-sight, not even beyond a door or a lift or platform -- otherwise it looks "dumb".

/Just filing this info here. I'm primarily referring to code I've wrriten in my FitzQuake Mark V project. The function I use to determine if something is really visible is R_SurfacePoint_Begin (which is essentially my replacement for R_LightPoint). This function work reliably but is mildly imperfect in a way that isn't material for this purpose, but most of the Q1 collision stuff is inferior to, say, better functions in DarkPlaces (it is mostly small inaccuracies that generally don't matter but in I have "tool_texturepointer" that selects surfaces and it is annoying when I see, say, a backface selected which tells me the collision for some dumb reason didn't hit the front face.)

This function work reliably but is mildly imperfect in a way that isn't material for this purpose, but most of the Q1 collision stuff is inferior to, say, better functions in DarkPlaces (it is mostly small inaccuracies that generally don't matter but in I have "tool_texturepointer" that selects surfaces and it is annoying when I see, say, a backface selected which tells me the collision for some dumb reason didn't hit the front face.)

If you recurse biased bsp planes you get those weird glitches, darkplaces recurses the bsp planes exactly (the same fraction is used for the near and far side recursion), and only biases the result (the trace fraction gets nudged off the plane that was hit).

The main case this is obvious in quake physics is in the episode 4 hall in start, where sliding along the wall will get you "stuck" when it meets the angled wall, but there are many many other examples if you look hard enough for these sort of convex edge cases.

The other optimization in the darkplaces bsp plane recursion is that it recurses both sides and returns a result and detects a collision when a node has EMPTY on front and SOLID on back, rather than doing a hull point check on the far side of every plane, this was a massive speed gain.

However do note that this is largely responsible for all the monster-fall-out-of-level and item-fall-out-of-level oddness in darkplaces which took a lot of workarounds and fixups to address.

However do note that this is largely responsible for all the monster-fall-out-of-level and item-fall-out-of-level oddness in darkplaces which took a lot of workarounds and fixups to address.

I'll keep this in mind as I mine for gems in DarkPlaces that solve things I hate (often solved in 8-10 years old DP versions )

Thanks for the explanation and the heads up for potential problems.

/While acknowledging your point it really sucks that almost every fix is assured of breaking something unusual.

LordHavoc: is it the bias shift that's causing the falling entities, or the not calling the hull point check? QF has both those optimizations and that problem too, but otherwise QF's trace function returns the same results as id's (I have a test harness to make sure of that ). Even with a bit of post-processing of the trace, it would be good to fix that problem.

taniwha, I would assume it would be because of precision issues. following the world slightly differently means you find slightly different leafs and in different orders, despite the actual coord being the same. remember that quake uses an epsilon to decide which side to impact upon, while a more accurate routine will only use an epsilon for the final plane.
personally I'd just make droptofloor jiggle about a bit horizontally. I don't really see any other solution.

LordHavoc: is it the bias shift that's causing the falling entities, or the not calling the hull point check? QF has both those optimizations and that problem too, but otherwise QF's trace function returns the same results as id's (I have a test harness to make sure of that ). Even with a bit of post-processing of the trace, it would be good to fix that problem.

The hull point check is definitely a screwy thing - there are a lot of thin wedge cases that could fail the hull check, or even trigger it (thin wedges are also unkind to portals, but they sure do occur in the bsp tree).

The lack of biasing is the reason for the falling out of levels though, I'm 100% sure of that, when I worked on Torque code it had some extremely careful bias handling that was better behaved in the "exactly on a plane" case.

A lot of the things that fall out though, are legitimately deep in a wall (monsters in ceilings, items in walls), which is why darkplaces has a lot of intentional sticking code for that (particularly special handling in droptofloor).

I also have some jitter code in there for unsticking all entities (but it only triggers if their trace_startsolid is TRUE in the MOVETYPE_TOSS/BOUNCE/FLY/FLYMISSILE/BOUNCEMISSILE and such code).

Ah, ok. I suspected it was the biasing. I'll look into what you've done when I get a moment. Thanks.

LH Torquecode? WHAT? My eyes are bleeding@!!

You forgot to define offsetrandom.
Also using 64 traces is exceedingly slow - DarkPlaces uses only a few and simply renews a timer in the edict_t whenever one hits the entity, as long as the timer is in the future it shows the entity, the timer has to be set low (like 0.2) to prevent wallhacks from being useful, but it's much lower cpu usage.

oof talk about diggin up an old post I added a tracetimer to the edicts but after all this time i found a bug in doing that.... ANYtime an entity was SEEN by any OTHER entity, the seen entity's timer got set into the future. So, it wasnt 100%

in progs.h, in the edict_s structure.

  Code:

float         tracetimer[16];   // track a visible time for each of the other players.


then in sv_main.c here's the new routine.

  Code:

qboolean SV_InvisibleToClient(edict_t *viewer, edict_t *seen)
{
   int i;
   trace_t   tr;
    vec3_t   start;
    vec3_t   end;
   extern trace_t SV_ClipMoveToEntity (edict_t *ent, vec3_t start, vec3_t mins, vec3_t maxs, vec3_t end);
   extern qboolean CL_Clip_Test(vec3_t org);
   int it;
   int vi;

   vi = (int)viewer->v.colormap - 1;

   if (seen->tracetimer[vi] > sv.time)
      return false;

   it = (int)(seen->v.items);

   //R00k: DM players want to see the Quad/Pent glow. Dont cull them at the moment...(fixme)
      if ((strcmp(pr_strings + seen->v.classname, "player") == 0) && ((it & IT_QUAD) || (it & IT_INVULNERABILITY)))
   {
      return false;
   }   

   if (sv_cullentities.value == 1)    //1 only check player models, 2 = check all ents
   {
      if (strcmp(pr_strings + seen->v.classname, "player"))
         return false;
   }

   if (seen->v.movetype == MOVETYPE_PUSH )
    {
      if (sv_cullentities.value == 3)   
      {
          if (CL_Clip_Test(seen->v.origin)== false)
            return false;
      }
      else
         return false;
    }

    memset (&tr, 0, sizeof(tr));     
    tr.fraction = 1;

    start[0] = viewer->v.origin[0];
    start[1] = viewer->v.origin[1];
    start[2] = viewer->v.origin[2] + viewer->v.view_ofs[2];

    //aim straight at the center of "seen" from our eyes
    end[0] = 0.5 * (seen->v.mins[0] + seen->v.maxs[0]);
    end[1] = 0.5 * (seen->v.mins[1] + seen->v.maxs[1]);
    end[2] = 0.5 * (seen->v.mins[2] + seen->v.maxs[2]);           

    tr = SV_ClipMoveToEntity (sv.edicts, start, vec3_origin, vec3_origin, end);

   if (tr.fraction == 1)// line hit the ent
   {   
      seen->tracetimer[vi] = sv.time + 0.2;
        return false;
   }

    memset (&tr, 0, sizeof(tr));               
    tr.fraction = 1;

   //last attempt to eliminate any flaws...
    if ((!strcmp(pr_strings + seen->v.classname, "player")) || (sv_cullentities.value > 1))
    {
        for (i = 0; i < 8; i++)
        {
            end[0] = seen->v.origin[0] + offsetrandom(seen->v.mins[0], seen->v.maxs[0]);
            end[1] = seen->v.origin[1] + offsetrandom(seen->v.mins[1], seen->v.maxs[1]);
            end[2] = seen->v.origin[2] + offsetrandom(seen->v.mins[2], seen->v.maxs[2]);

            tr = SV_ClipMoveToEntity (sv.edicts, start, vec3_origin, vec3_origin, end);
            if (tr.fraction == 1)// line hit the ent
         {
             //Con_DPrintf (va("found ent in %i hits\n", i));
            seen->tracetimer[vi] = sv.time + 0.2;
            return false;
         }
        }
    }
    return true;
}

basically every entity NOW has a timer in relations to each player, as it's only players looking at other entities not a nailbox looking at a health pak
16 is hardcoded as the server only allows 16 players max... i know lazy !

oof talk about diggin up an old post I added a tracetimer to the edicts but after all this time i found a bug in doing that.... ANYtime an entity was SEEN by any OTHER entity, the seen entity's timer got set into the future. So, it wasnt 100%

Actually this is super-timely and super-relevant. A few hours ago I was going to look for this ...

For a different reason ...

I want to optimize sv_cullentities to work on all entities in maps with 1500-2500 entities to reduce network traffic, per player (like as in coop). But not overwhelm itself with calculations.

I am also thinking that at larger distances from the player, less checks should be done. Maybe one generic center of the entity check. Maybe even a max distance cutoff?

Many questions ... I haven't thought this through very far ...

Add:

Probably adding just a bit of intelligence into this might help. If the player didn't move, why check entities that haven't moved (again).

There have to be some common sense ways to reduce the load here.