SV_Invisible_To_Client (Anti-Wallhack)

[Baker]

[LordHavoc]

[Spike]

[Baker]

[Baker]

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.)

[LordHavoc]

[Baker]

[taniwha]

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.

[Spike]

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]

[taniwha]

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

[r00k]

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

[r00k]

[Baker]

[Baker]

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.