SMAC Development Thread
 

I've restarted development here, starting from the last kac rev at the time of writing.

Code repository: https://bitbucket.org/psychonic/smac
Bug tracker: https://bitbucket.org/psychonic/smac/issues
Wiki: https://bitbucket.org/psychonic/smac/wiki/

Let's use this thread to discuss further development.

Re: SourceMod Anti Cheat (v1.2.1.7) - (Formerly Kigen's Anti Cheat)
 

Nice! I see you're making changes already. :up:

What direction do plan on taking this project?

Re: SourceMod Anti Cheat (v1.2.1.7) - (Formerly Kigen's Anti Cheat)
 

I can't guarantee that I will have time to continue to maintain it, but I figured it would be easier for someone else to get started if I get the ball rolling. I can happily provide source hosting and a bug tracker if wanted, or the existing repo can be pushed to a new gcode project.

The only thing that I had left on my list, without digging through more source, is converting the translations to using SM's standard translation system. I cannot remember why he felt the need to write his own, but if there's any issue with SM's, I would rather it be exposed so that we can fix it upstream. (though I have a feeling that it's fine).

I have this partly done, but it's a slow, tedious process.

Re: SourceMod Anti Cheat (v1.2.1.7) - (Formerly Kigen's Anti Cheat)
 

Pretty decent of you.

Re: SourceMod Anti Cheat (v1.2.1.7) - (Formerly Kigen's Anti Cheat)
 

One thing I like about Google Code is that the code and issue tracker are both in the same place, but other than that I think what you have is fine.

Should be a lot easier to manage the translations after this is done.

A quick glance at this part:
Knowing that SourceMod already keeps track of this internally: Are the native calls really that taxing?

Re: SourceMod Anti Cheat (v1.2.1.7) - (Formerly Kigen's Anti Cheat)
 

I personally don't care for google code's issue tracker (and typically use redmine in place of it even when the rest of the project is on gcode), but to each their own. I'm willing to help out whatever whomever decides to lead it feels is best.

I'll have to look at the code closer to see if anything else can be done, but kneejerk response is that every bit of speed helps with the intensive anti-wallhack code. Part of the frame action is to loop over all ingame clients. At least the caching of ingame state and isfake save 2-130 native calls per frame, depending on MaxClients.

SMAC Development thread
 

I've started making some changes/additions, and I had a few questions for anyone else working on this plugin:

1. There are many places that use Plugin_Stop instead of Plugin_Handled. Should this be changed?

2. Should we be using AddCommandListener instead of RegConsoleCmd? In the documentation it says it may not be supported on all games. That's the only reason I can think of to not use it.

3. Should we just get rid of the whole "status" module?

Re: SourceMod Anti Cheat (v1.2.1.7) - (Formerly Kigen's Anti Cheat)
 

I also looked over the anti-flashhack module you added, GoD. I haven't test it yet, but I likely will soon. Have you done any tests? It looks cool. I just wish I could think of a way that would make it work for flashes that don't leave a player 100% blind, since you certainly can't take away the enemy positions at that point.

1. In these situations, are there future hooks that need to be prevented from being called for the same action? It apparently works the way it is, so there must not be any important hooks after the current places where Plugin_Stop is used.

2. From the documentation, it appears RegConsoleCmd should be used in situations where we're creating a new command while AddCommandListener should be used if we're creating new commands, but since I of course don't know either in which games it's supported, that should be determined first. Alternatively it could be made conditional, using AddCommandListener when it's available, or if it returns false, using RegConsoleCommand.

3. Yes. The status of the various modules can just as easily be found with "find smac_" in console, although this information would not be available to admins without RCon or SM's cvar access, but I don't see that as a problem, since it's a config issue anyway and not really important info for admins without that access. The cvars_status and net_status information is also not very useful except for debugging, so it can likely be removed, replaced by simply logging any failures at checking a specific player.

Re: SourceMod Anti Cheat (v1.2.1.7) - (Formerly Kigen's Anti Cheat)
 

It works, but so far I've only tested it with bots and a separate plugin to simulate a no-flash hack. Some real gameplay testing would be needed as well as optimizing it a bit. It's probably better to use timers instead of calling GetGameTime() over and over.

If you get a good flash off, the player can be fully blind for 3-4 seconds. Effectively disabling any no-flash and aimbot during that time.

Maybe that's the proper way to do it, but then we would need two callbacks for each command to handle this condition. I'll leave it until it's decided.

Yea that's what I was thinking too. Unless these status commands have helped troubleshoot problems in the past, I don't think they're necessary. It's even worse that each one needs it's own translatable phrase, which causes some bloat as well.

From where I stand, I would prefer to only deal with contributions without having to manage or distribute. :)

Re: SourceMod Anti Cheat (v1.2.1.7) - (Formerly Kigen's Anti Cheat)
 

I agree. It's overly complex and largely unnecessary.

I am in the same position.

I'll have more code-related feedback later in response to you and Mister_Magotchi.

As you can see, I've done a bit of thread surgery. It is in the works for SMAC to just takeover this subforum.