Stopping Picmip 45234 graphics destruction?

[Baker]

Quake II sends the light level back to the server.

Maybe a random and unpredictable GLReadPixels has to be returned every here and there and if it doesn't match the single pixel of what the server expects ... someone is trashing up their game.

Yeah, some incredible mess of a hack might be able to defeat such a thing, but it would be an incredible burden.

This type of thing could effectively prevent the culture of trashing a game's graphics for an advantage.

[Sajt]

Options:

1. Try to implement a poor man's PunkBuster. (con: totalitarian)
2. Actually use PunkBuster. (??)
3. Stop cultural discrimination. Allow cheaters, burqas, etc.
4. Don't play video games with anonymous strangers.

I prefer the last option, but I'm probably alone.

[mh]

glReadPixels would ruin performance as it needs to stall the pipeline.

[Spike]

or you could just ban all engines which support that cvar (that's all of them, right?).

[Baker]

glReadPixels would ruin performance as it needs to stall the pipeline.

True, but on Windows you don't need glReadPixels

Since ALT + Printscreen "copy to clipboard" works even in fullscreen mode ... meaning you can grab a pixel color right off the dib via Windows API

or you could just ban all engines which support that cvar (that's all of them, right?).

Well that specific feature in modern times should be enabled only with developer 1 running, realistically. Just like how you shouldn't be able to play with r_lightmap 1.

Just thinking ahead

[Baker]

Later today, I'll post a shot of a wonderfully neat DM map that admittedly is rather difficult to see players in some areas.

I remember a Qrack user connecting and using gl_textureless feature and saying "OMG! I can see so clearly now ..." on this wonderful map. (R00k is eliminating that feature from Qrack, btw.)

I was rather upset at this. For me to play the map on an even playing field against that, I'd have to destroy the appearance of the beautiful map to do so.

Alas, I can see ways that this type of protection would be defeated easily. So maybe not ...

[Spike]

yeah, good luck doing that automatically when you don't even know which frame is currently in the DIB. And good luck when the user is in linux instead.
Also, good luck coping with surface angles, original textures, and gl_texturemode nearest.

Seriously, good luck.


QuakeWorld has a 'snap' command which can be used to request a different client take a screenshot and upload it to the server, for the requester to download. Used to detect wallhacks. Its a friggin pcx. Looks ugly as sin.
Tis also an invasion of privacy. There's no guarentee that if your application is covered by another window that you won't manage to take a screenshot of some banking app, or some other sort of personal information.
But so long as they can't replace textures with flat ones, huh.
I'm sure you'd have great fun with r_drawflat in ezquake. I never did manage to figure out how it gave less fps than full texturing, but hey.

[mh]

Nothing to stop the truly malicious from just renaming the cvar to something else then, or using a different cvar for picmipping.

Checking pixel values would also break if someone's 3D card had a different max texture size, they were using external textures, had different gamma values (and were using the old GLQuake style -gamma), etc. There may even be subtle (or not-so-subtle) differences between different drivers or between someone using wqpro, glpro, d3dpro and dx8pro.

Client-side cheat protection is a lost cause IMO. Ultimately someone who really wanted to could just recompile the source code, rename cvars, hard-code behaviour into GL_Upload32, render to two windows with the non-cheating version minimized, or whatever they wanted. You'd be fighting a losing battle.

[Baker]

Actually, there could be something to this for a rainy day in the distant future.

Anyways, something I do think would be cool in Quake ...

True invisibility where the player is only visible when firing or taking damage. No eyes.mdl. And the player entity simply isn't sent to other clients when the player is invisible.

I've always hated the invisibility ring in Quake because it is useless against an altered eyes.mdl.

[Baker]

This kind of thing isn't really a good use of time anyway, I suppose.

I had an idea. I posted it. It has obvious flaws.

And probably isn't worth the time investment.

[Spirit]

Why not simple let people play as they like/can?

[frag.machine]

Why not simple let people play as they like/can?

That's depends of what "people" are you talking about: people who cheats in a 14 year-old game, or people who wants just to play without being hassled by aimbots or wallhackers ?

[Spike]

I think quakeworld players have it right when it comes to aimbots...
Just spam 'nades/rockets at the spawn spots so the aimbotter never even gets a chance to aim.
There's more to a map than just aiming. :)

[Spirit]

That's depends of what "people" are you talking about: people who cheats in a 14 year-old game, or people who wants just to play without being hassled by aimbots or wallhackers ?

I'm talking about people who like to play with high picmip values for some weird reason. I think it looks bad but I also think that most retexture things look bad.

I don't think aimbots/wallhacks are in any way related to this discussion?

[Baker]

Here is the map bsdm7 as it was made.

It is hard as hell to spot players here. Makes it sort of a cat and mouse fight.



Here is EZQuake with r_drawflat 1 as an example.



My theoretical concept, the client has to send back to the server some random pixel from the rendering frame.

The server knows the answer is brown at a certain pixel based on world position and roll, angle, pitch (adjusted for FOV, etc.). Sure gamma and all and settings might affect the RGB values there and there ... but white or blue ain't the answer and the server would disconnect the client.

I'm thinking cheat workarounds might be more annoying than just playing legit. Sure you could have 2 rendering frames and get far less frames per second. Other options might prove to me more annoying to the cheater than they are worth.

Anyways, something for a future day ....

(There could be servers with the feature disabled, because that kind of thing would hate ... say ... replacement textures. But I think reasonable measures to enforce a server's rules that aren't too hard to code may prove to be useful.

The alternate is to have all clients cheat equally. I find that idea unacceptable, really.)

Statistical sampling of rendering. It could be done and wouldn't place any real burdens on game play.