gemidyne / microtf2

A custom gamemode for Team Fortress 2 - Players compete against each other to get the most points by playing a series of rapid fire microgames in order to win the round!
https://www.gemidyne.com/projects/microtf2
GNU General Public License v2.0
32 stars 17 forks source link

sv_cheats should not have to be enabled #168

Closed sappykun closed 4 years ago

sappykun commented 4 years ago

This is less of an actual issue and more of a general question, but I feel it warrants discussion here.

I recently installed this plugin on a server for a long-running TF2 community. It works without issues, except for the fact that the security system prevents us from using certain commands like sm_noclip. Rather than just blocking the command, it forcibly kicks the player who obtains noclip.

This makes me wonder why sv_cheats is even activated in the first place. I tried turning it off manually when playing a few rounds, and other than the times where it was re-enabled, I did not notice any issues with the gamemode.

Why is sv_cheats necessary for the gamemode to function? If it's not a necessity, can the security system be disabled?

safalin1 commented 4 years ago

Hi, Thanks for creating an issue regarding this topic.

The reason sv_cheats is currently enabled server-side is for allowing host_timescale to behave correctly. When it was originally tested, if cheats was set to 0, lag and stuttering would be encountered when host_timescale is not 1.0. This caused the speed events to make the gamemode unplayable and a decision was made to enable sv_cheats, but try to blacklist all cheats where possible.

However, lag & stuttering may no longer occur now with cheats off - I will need to check this and get back to you. If this is a possibility, then the security system currently in place could be removed.

I agree with your point in that invoking cheats should not kick the invoker if used, and instead just be blocked. From looking at the code, there is a hardcoded check to see if any player is using noclip and to kick if this is the case. If I remember correctly I may have had issue blocking the noclip client command due to it not being sent to the server - I may be wrong however, and there may be new ways of preventing such commands from being used.

Many of the decisions made with the security system were made many years ago, prior to the gamemode going open-source on GitHub - I am open to improving the security of the gamemode and looking into the possibility of keeping cheats off whilst still support host_timescale.

I will get back to you on what can be done in regards to sv_cheats.

safalin1 commented 4 years ago

Just some initial comments on sv_cheats being 0 - it looks that the stuttering still occurs and gaps between music occurs. Player movement does not speed up accordingly either. I am still looking into solutions - some people have chatted about this exact thing over on AlliedModders forum: https://forums.alliedmods.net/showthread.php?t=284202

safalin1 commented 4 years ago

Short answer: Cheats need to be on for host_timescale to work properly, and is used for the Speed up & speed down events. Noclip causes a kick because anyone can just input "noclip" in console and begin noclipping. I can add in a check so SM admins are exempt from this and force non admins back to walking so they cannot noclip.

Long answer: I think the only options we have here are:

I am not sure what else can be done to work around this. The speed up & speed down events are a main part of the gamemode and removal of this would make the gamemode less fun - I do of course understand the risk of having cheats on for you as a server operator. That is why we do try to have a security system in place to prevent unauthorised cheats from being used, and as soon as the gamemode is no longer running we turn cheats back off immediately.

I have emailed the TF Team about the possibility of host_timescale correctly working with sv_cheats off, but I doubt they will acknowledge or action on this. However if they do, that would solve the problem entirely.

worMatty commented 4 years ago

I think there is an entity in other games like L4D and Portal 2 for controlling host timescale. It would be nice if the TF team imported that.

Matty

On Tue, 28 Apr 2020 at 13:43, Steven notifications@github.com wrote:

Short answer: Cheats need to be on for host_timescale to work properly, and is used for the Speed up & speed down events. Noclip causes a kick because anyone can just input "noclip" in console begin noclipping. I can add in a check so SM admins are exempt from this and force non admins back to walking so they cannot noclip.

Long answer: I think the only options we have here are:

  • Making sv_cheats only turn on server side if the speed of the gamemode is not 1.0 (for slowmo special round and speed events). This only brings a little bit of security but still does not solve the problem that is having cheats enabled in the first place.
  • Further blacklisting cheat commands & convars where possible.

I am not sure what else can be done to work around this. The speed up & speed down events are a main part of the gamemode and removal of this would make the gamemode less fun - I do of course understand the risk of having cheats on for you as a server operator. That is why we do try to have a security system in place to prevent unauthorised cheats from being used, and as soon as the gamemode is no longer running we turn cheats back off immediately.

I have emailed the TF Team about the possibility of host_timescale correctly working with sv_cheats off, but I doubt they will acknowledge or action on this. However if they do, that would solve the problem entirely.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gemidyne/microtf2/issues/168#issuecomment-620581900, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPRJKQUHIVFHMWX3XQINTTRO3FNTANCNFSM4MRNO5XA .

safalin1 commented 4 years ago

https://developer.valvesoftware.com/wiki/Logic_timescale Oh yeah that'd be amazing if it could be ported over!

Reading through the docs for it, that is exactly what we need haha. If only we had a contact at the TF team that would talk to us about this..

worMatty commented 4 years ago

I've had some apparent success in the past by emailing the TF team using the email form on the Valve site. One idea I sent was implemented and some bugs fixed but I didn't get any acknowledgement. I think if there's a good enough reason for something to go in they will do it if they can.

safalin1 commented 4 years ago

Ok I see - I did use that email form on their website to request this. Guess time will tell if they add it in.

sappykun commented 4 years ago

Thank you for looking into this. I was updating an old Source 2007 server install and noticed that we had this plugin: https://forums.alliedmods.net/showthread.php?p=600521 Perhaps the baked-in security system could be toggled on or off using a cvar so an external plugin can be used to replace it. It would save rewriting the system from scratch.

bakugo commented 4 years ago

@stevu236

The "weird lag and stuttering" you mention is caused by clients ignoring the timescale value when cheats are off, so server and client run at different speeds. You can actually fix this by fooling the client into thinking cheats are on without actually turning them on. Freak Fortress 2 uses this method for the slowmo ability, you can go look at that but I'll explain it here too.

To do it, grab handles to sv_cheats and host_timescale with FindConVar. When you want a timescale other than 1.0, change host_timescale normally with SetConVarFloat, then you must run SendConVarValue(client, handle_to_sv_cheats, 1); on each client to make them believe cheats are on and accept the custom timescale. This will not allow clients to run server-side cheat commands such as noclip. It will allow them to use some clientside cheats such as mat_wireframe (which was already possible with the current version of this plugin), you can kick for that if you want but I don't think it's too big of a deal in this mode. You can also use SendConVarValue(client, handle_to_sv_cheats, 0); when the timescale goes back to 1.0 and those cheats will be automatically disabled on the client.

There is a caveat to this though: the method only works on Linux servers. Windows srcds has a weird engine difference that makes it so host_timescale doesn't work server side if cheats aren't enabled (resulting in desync again). However, it's possible to work around this with a small plugin that patches the engine code responsible, I created a plugin for this a while ago for my own use. I can share the code with you if you want to implement it into your plugin, or I can publish it on alliedmodders and you can make it a requirement for windows servers.

Also: I took a look at the current security code and there's a lot of stuff that doesn't really make sense. For example, the plugin blocks all types of noclip at all times which disables any non-cheat sources of noclip as well, wouldn't just blocking the noclip command be enough? It also creates timers to kill all point_servercommand entities, for each client, which also doesn't make much sense. How can point_servercommand even be abused here? There's also this weird loop here which never goes past the first iteration.

safalin1 commented 4 years ago

Thanks for the info - sounds interesting, I'll give it a go.

If you could share your engine patch code too that'd be great (I test on Windows SRCDS). I'd probably integrate it directly into the gamemode - however if you want to publish it on AM so others can use it too, that's totally fine and I can make this gamemode dependant on that plugin.

The only reason for needing that SecuritySystem.sp file is because sv_cheats are turned on serverside. If we can get cheats off for good, then that solves everything :)

And yeah I know haha, the security code is ancient and looking now I don't really have a full understanding of it working. I'd prefer to remove it, as its just trying to mask a bigger issue.

bakugo commented 4 years ago

I've posted it on AM: https://forums.alliedmods.net/showthread.php?t=324264 Feel free to copypaste it into your plugin, it's a relatively simple fix.

safalin1 commented 4 years ago

Thanks! We just ran a small testing session and it worked perfectly. We are making the host_timescale fix plugin a mandatory dependency for running the next stable version of the gamemode going forward.

I have also removed the security system completely as it is no longer required and sv_cheats on the serverside is always 0.

Thanks again for your help guys! This has solved everything :)

bakugo commented 4 years ago

The plugin is only necessary on windows servers, there's no need to require it on linux servers (which are the majority)

In tf2 you can check if the current server is on windows with FileExists("bin/server.dll")

safalin1 commented 4 years ago

Ah I see - I didn't think of doing it that way, thanks again. (Updated dev branch to use that)