[smiley@tf2nerds]

Edit:

I posted this in the wrong forum because I am a noob

When a kind mod has time to move this post can make sure it goes to the sourcemod sub forum?

Thanks

Gameplay Description:

Rewind is a game mod for TF2 where you can rewind time! Players do this by pressing or holding reload. In addition to returning you to an earlier position, rewinding restores the previous state of many weapons, items and status effects.

Technical Description:

Rewind maintains a ring buffer of state for each client as they move forward in time. This state includes client; position, velocity, health, ammo, and various other entity properties. When the client wishes to rewind, this buffer is simply read backwards and the earlier state is applied conditionally as required. For example; if the client is currently in the condition of being on fire, but in the frame they are currently rewinding to they were not on fire, the status condition of being on fire is removed. Rewind makes use of existing sound files to create distinct audio cues for rewinding and being able to rewind. Care has been taken to ensure that cloaked spies are not revealed by these additional sounds. Rewind uses ShowHudText to provide a status bar indicating the current state of the client’s rewind ring buffer in addition to a client’s ability to start rewinding again. Players, who are not cloaked, that are rewinding emit the teleporter trail effect as a visual indication that they are rewinding.

Website:

https://www.tf2nerds.com/rewind.html

Installing the plugin:

1) Download tfrewind.smx to tf/addons/sourcemod/plugins
2) It is recommend that you add rewind to sv_tags however this is optional
3) Restart the server

Compiling the plugin:

1) Download tfrewind.sm
2) Compile tfrewind.sm with tf/addons/sourcemod/scripting/spcomp
3) Copy tfrewind.smx to tf/addons/sourcemod/plugins
4) It is recommend that you add rewind to sv_tags however this is optional
5) Restart the server

Known Issues:

1) Heavy is able to rewind lunchbox items, however, the food hud element does not reflect this.
2) Pyro is unable to rewind the Gas Passer.
3) Players are unable to rewind Vaccinator resistence bubbles.
4) Scout can rewind air dashes in general, however, he cannot rewind the knockback air dash offered by the Force Of Nature.
5) Very rarely is it possible for a client to rewind to state such that, from their perspective, visually they appear to be “stuck in the floor”. This is not unique to rewind but it is capable of inducing this state. Simply jumping should fix the issue.
6) Sometimes undisguised spies don’t emit a teleporter trail effect while rewinding. Disguised spies always emit a teleporter trail while rewinding, of the correct team's colour, unless they are cloaked.

Plans:

Development will continue according to feedback.

Changelog:

Will be updated as new versions are released beyond 1.0.0.

[J_Tanzanite]

Very cool plugin!

However, there is a compatibility issue between this and Lilac, but it's easy to fix.
I won't go deeply into it, but Lilac doesn't just check your angles when checking for aimbot, but also where you aim in relation to others (done via positions); therefore, plugins that teleport players could potentially cause false positives.

There is a simple way to tell the AC to ignore what it found if you happened to be altering player positions, inputs or angles; and it's as easy as adding this:


When a player joins the server:

OnClientConnected( int client ) {
	...
	g_teleport_time[ client ] = 0.0;
	...
}

When teleporting, set a timestamp.

if ( should_teleport ) {
	g_teleport_time[ client ] = GetGameTime();
	TeleportEntity( client, new_origin, NULL_VECTOR, new_velocity );
}

And when the AC detects something, you can easily check if you did recently affect the player, and tell it to ignore it:

/* Defines from Lilac, these won't ever change. */
#define LILAC_CHEAT_AIMBOT  5
#define LILAC_CHEAT_AIMLOCK 6

/* If a detection happened within 5 seconds of a teleport,
 * then block this Aimbot or Aimlock detection.
 * This value is massively overkill, but that's fine. */
#define LILAC_TELEPORT_BLOCK_TIME 5.0

public Action lilac_allow_cheat_detection( int client, int cheat )
{
	/* We teleported the player, tell Lilac to ignore the detection. */
	if ( GetGameTime() - g_teleport_time[ client ] < LILAC_TELEPORT_BLOCK_TIME && ( cheat == LILAC_CHEAT_AIMLOCK || cheat == LILAC_CHEAT_AIMBOT ) )
		return Plugin_Stop;

	/* Otherwise, let it through. */
	return Plugin_Continue;
}

The good news about this fix is that you don't need to include any new headers, it's as simple as just pasting this. I wish I could deal with these things on the AC side, but that would mean keeping track of every plugin that could cause issues, which most servers won't ever use. This is unfortunately the best way to deal with this.

I don't think you have to do this with SMAC, as it doesn't check your aim in relations to other players.

[smiley@tf2nerds]

> The good news about this fix is that you don't need to include any new headers, it's as simple as just pasting this. I wish I could deal with these things on the AC side, but that would mean keeping track of every plugin that could cause issues, which most servers won't ever use. This is unfortunately the best way to deal with this.

This also applies the other way around - does it make sense for every plugin to implement functions for every anti-cheat letting them know if they can do their job? Perhaps it would make more sense to prevent the anti-cheat from classifying behaviour which isn't cheating as such

[DruGzOG]

You also posted this in the wrong section

[J_Tanzanite]

To avoid going off topic, I'm going to keep this short and not too in-depth.
This is afterall, about compatibility.

Originally Posted by smiley@tf2nerds This also applies the other way around

Nope.avi

Originally Posted by smiley@tf2nerds does it make sense for every plugin to implement functions for every anti-cheat letting them know if they can do their job?

It's not every plugin tho... It's only for those who alter inputs or do other funky stuff.
There are only a few known & used ACs out there, and hundreds of plugins that alter player inputs (many of which are obscure). Book-keeping here is not equal, doing this on the AC won't work.
Plus, doing it the way you suggest means the AC would either:
1. Have to disable features entirely for plugins that may only alter input or run every now and then.
2. Or have duplicate code of other plugins to know when it can and can't run.
Neither of these solutions are workable.
The reason why it's done this way with forwards, is because there isn't a clear way to detect when other plugins alter player inputs or do other funky stuff. And then there is plugin load order, which do complicate this further.
Using forwards is the most efficient way to deal with this, which is why SMAC does it as well. And using forwards means that when plugins haven't altered anything, the AC can run its detection without problems.

Originally Posted by smiley@tf2nerds Perhaps it would make more sense to prevent the anti-cheat from classifying behaviour which isn't cheating as such

I don't think you understand how server side Anti-Cheats work.
You write detections for things which are inhuman (or at least very unlikely or rare to happen frequently), and cheat features which are impossible unless a game is modified. Other plugins, can affect this, and SM doesn't have a clear way to detect this.
Lilac also has a few checks which are more complicated than other ACs, so a single forward really is the best option here.

You can choose not to add the forward if you like, tho it would be a shame for other servers if they decide to run both and an error occurs. :/

If you have any questions or want to discuss this further, you can message me on here.