Ghosting players to counter cheating...

I stopped playing T1 once T2 came out, but I thought I remember a solution to the aimbot/perm iff's being to ghost players around the map. That way the aimbot got the information they were there, but normal players did not see them.

Is this a feasible solution for T:V, or due to unoptimized server and network code, ghosting the data for other players would cause even more server instability?

And is it possible to ghost a single enemy player in front of the current player, ghosting it at various distances so they can't hardcode that target not to be locked on?

hmm... not a bad hack. Maybe.

Well, you "MIGHT" be able to do this with a mutator. Cause it to randomly spawn fake players. The problem is how the bot determines what to aim at. Also, how to make sure the engine doesn't render the fake player, while still giving the location of it. This could all be done client side too, and simply send data to the server when a player fires at the fake player a certian number of times.

i think t1 was old enough where everyones machine could handle having 50 unseen players below the map running around with the flag
in t:v, i'd expect single digit fps

i think t1 was old enough where everyones machine could handle having 50 unseen players below the map running around with the flag
in t:v, i'd expect single digit fps
The thing is, if we can tell the game to not render them, they shouldn't impact FPS very much, except the small amount the added instructions of uscript add, which isnt all that much really.

This method won't do squat. A couple conditionals will make it nothing more than a wasted effort.

Since the aimbots are currently not running on a visualization scheme (i.e. the first aimbots that used colored models) but instead the locations of players, that's where the idea for the single ghost player in front of the player. Ghost the information for a player pretty much where the reticle is, just at different distances from the player.

This method won't do squat. A couple conditionals will make it nothing more than a wasted effort.
eh, yea, but why not try? I mean, I don't see why any one would be against at least trying unless they have something to lose.

This method won't do squat. A couple conditionals will make it nothing more than a wasted effort.

What would those conditionals be?

What would those conditionals be?
Well, if we make this client side, simply have the bot sniff the network data to see if the player on screen is real. Now, we could then add a server side system instead, but that still could be caught by watching the uscript being executed some how to get the name of the fake player, and ignore it.

Well, if we make this client side, simply have the bot sniff the network data to see if the player on screen is real. Now, we could then add a server side system instead, but that still could be caught by watching the uscript being executed some how to get the name of the fake player, and ignore it.

Yeah, I figured it would have to be server side. The problem comes in keeping them from identifying the ghosts. Possibly randomly give the ghost the same name as a player on the opposing team. That would prevent aimbotters from selecting the ghosted name from a list.

Yeah, I figured it would have to be server side. The problem comes in keeping them from identifying the ghosts. Possibly randomly give the ghost the same name as a player on the opposing team. That would prevent aimbotters from selecting the ghosted name from a list.
You have to keep the client from getting confused though, and the fact that the client needs to get a copy of the uscript, although not identical, the bot can use that to its advantage.

Well, if we make this client side, simply have the bot sniff the network data to see if the player on screen is real. Now, we could then add a server side system instead, but that still could be caught by watching the uscript being executed some how to get the name of the fake player, and ignore it.

Don't answer for me, thanks.

you cannot fight code with code when will you people learn. it just isn't at all remotely possible to stop the hacks via any kind of code block or loophole. If you gave john carmack a team of the best engineers in the world and an infinite budget, the best he could do is make an engine that takes 2-3 weeks to be completely compromised.

Well, if we make this client side, simply have the bot sniff the network data to see if the player on screen is real. Now, we could then add a server side system instead, but that still could be caught by watching the uscript being executed some how to get the name of the fake player, and ignore it.

This really makes no sense ;)

This really makes no sense ;)
Well, maybe not to you.

The autoaim executable could just not lock on to players that don't have a velocity. Easy workaround to the fake players right there. :p

What would those conditionals be?

All we're trying to do is distinguish an actual player from a decoy. There are so many differences that could possibly exist, determined only by implementation.

All it takes is a simple offset comparison and bam, you've eliminated this object from being considered.

I used this method to break HaPPyBreaker, some people might recall this from the Tribes 1 days. A simple offset comparison to the object's team asset, and bam, you've distinguished the decoy from an actual player.

The autoaim executable could just not lock on to players that don't have a velocity. Easy workaround to the fake players right there. :p
Then it wouldn't fire at any one that isn't moving. And I never said that ghost players would be standing still, its easy to have some very simple AI in side that tells it to go forward and backward, left and right, etc. Nothing that would actually attack, but just move a little to get attention.

f ucking cheaters