its just how you implied that tribes2 method of sending data to the client somehow made see through wall cheats worthless. they can be useful in close quarters of the base, ie to look around corners and such. NEVER try to imply a cheat will be worthless because of how gameplay is delt with. if there are very few walls to hide behind, naturally a see through wall cheat will be rather worthless, but not because the method of sending data, but more of the fact in essence there are no walls ppl can hide behind.

please explain which popular commercial games at which players would bother trying to cheat at, dont use some form of PVS (potential visible set) system. i would like to be enlightened (seriously, i dont know of any game that does not use this as a bandwidth optimization except for maybe homebrewn games that are done by single person and are in very early stages of development meant for lan play only).

quote:Original post by a person
its just how you implied that tribes2 method of sending data to the client somehow made see through wall cheats worthless. they can be useful in close quarters of the base, ie to look around corners and such. NEVER try to imply a cheat will be worthless because of how gameplay is delt with.

Tribes 2 uses portals, though. If they''re getting zero (or very low) overdraw, then wallhacks would definately not be very useful. Of course, the player could rewrite parts of the rendering pipeline, but then you might as well worry about him writing a whole new client against your network protocol.

ok, so they compare each model to the world geometry before drawing as well? in any case it dont matter, many advanced hacks hook the actually client game dll which recieves the information on where things are (for client side effects that would need this information).

tribes 2 may not be as vunerable to this as hl/quake+ are, but that would mean a less expandable game client side wise (no special radar and such). a hooked client side api gets all the info teh client gets regardless if it actually gets drawn. a

i am not super familar with how tribes handles drawing models, but i am pretty sure the engine does not do checks to see if the model is being blocked by geometry since drawing with the zbuffer would be faster and more accurate. otherwise the engine would have to check at an almost per polygon level to decide whether to draw the model. so when the model gets close to a corner (ie a pixel of the model could be seen) the model or a larget part then that pixel will be sent to the card for drawing. maybe the player wont get the huge advantage as in hl/quake+ but a second or so is ussually enough to give the cheater enough to advert trouble coming arounf a corner. (especially if the person happens to just be camping there waiting). its much more cpu friendly not do try and do all those traces to see if the model is patrially visible or not.

you give the game companies too much credit when they say they get zero overdraw or close to it. they ussually mean for the static level geometry and not the dynamic geometry. if it was so easy to drop dynamic models from view, dont you think valve would have done this a while ago (in fact they said they did and see through wall cheats woudl no longer work). the truth is that they did optimize the model drawing, and you had less of a viewing advantage (though most levels were not even affected to due the inability to complitly remove a model easily from rendering without affecting quality), but not to the point where the cheat became even remotly useless.

btw, early cheats for quake were actually proxies that modified the packets to allow for auto aiming and such. the hackers reversed engineered the packets and were able to figure enough to write such a bot.

ajoling: just becareful the gamer dont find teh algorithm (which they have access to the code) and use it. i suggest at each update changing stuff to help keep ppl guessing. just try not to be too bandwidth intensive with your system.

quote:Original post by a person


i am not super familar with how tribes handles drawing models, but i am pretty sure the engine does not do checks to see if the model is being blocked by geometry since drawing with the zbuffer would be faster and more accurate. otherwise the engine would have to check at an almost per polygon level to decide whether to draw the model. so when the model gets close to a corner (ie a pixel of the model could be seen) the model or a larget part then that pixel will be sent to the card for drawing. maybe the player wont get the huge advantage as in hl/quake+ but a second or so is ussually enough to give the cheater enough to advert trouble coming arounf a corner. (especially if the person happens to just be camping there waiting). its much more cpu friendly not do try and do all those traces to see if the model is patrially visible or not.

Line of sight testing against bounding boxes or hitboxes really isn''t that bad computationally. If you were going to go that route, you could even just draw an arm or something when that''s box peeks around a corner. (Would be easy in tribes, since it uses segmented player models anyway.) Try getting a headshot aimed against a disembodied arm.I don''t know if their engine actually does this, though. Anyway, doing so would cut out driver hacks, though not client code hacking. But I never said that it would.

Client hacking is _always_ a problem, especially if you are going to write a moddable game. If you aren''t going to let players modify the game, though...

If any of you want to take a look at the tribes2 engine, go here:

http://www.garagegames.com/

and buy a license for the source code. It''s $100 and you get 95% of the tribes2 engine, including the entire network component which is the most impressive.

The documentation is VERY poor, almost non-existant, but it''s worth the $100.