[psychonic]

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.

[GoD-Tony]

Originally Posted by psychonic And for next time this happens, in case nothing else is set up before then, here is a mirror. http://hg.nicholashastings.com/kac

Nice! I see you're making changes already.

What direction do plan on taking this project?

[psychonic]

Originally Posted by GoD-Tony Nice! I see you're making changes already. What direction do plan on taking this project?

Originally Posted by thetwistedpanda Psy, feel free to trash this topic and create one specific to your version of the plugin haha.

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.

[sinblaster]

Pretty decent of you.

[GoD-Tony]

Originally Posted by psychonic I can happily provide source hosting and a bug tracker if wanted, or the existing repo can be pushed to a new gcode project.

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.

Originally Posted by psychonic 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.

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

A quick glance at this part:

//- Global Variables -//
new bool:g_bConnected[MAXPLAYERS+1] = {false, ...}; // I use these instead of the natives because they are cheaper to call
new bool:g_bAuthorized[MAXPLAYERS+1] = {false, ...};    // when I need to check on a client's state.  Natives are very taxing on
new bool:g_bInGame[MAXPLAYERS+1] = {false, ...};    // system resources as compared to these. - Kigen
new bool:g_bIsAdmin[MAXPLAYERS+1] = {false, ...};
new bool:g_bIsFake[MAXPLAYERS+1] = {false, ...};

Knowing that SourceMod already keeps track of this internally: Are the native calls really that taxing?

[psychonic]

Originally Posted by GoD-Tony 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.

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.

Originally Posted by GoD-Tony A quick glance at this part: //- Global Variables -// new bool:g_bConnected[MAXPLAYERS+1] = {false, ...}; // I use these instead of the natives because they are cheaper to call new bool:g_bAuthorized[MAXPLAYERS+1] = {false, ...};    // when I need to check on a client's state.  Natives are very taxing on new bool:g_bInGame[MAXPLAYERS+1] = {false, ...};    // system resources as compared to these. - Kigen new bool:g_bIsAdmin[MAXPLAYERS+1] = {false, ...}; new bool:g_bIsFake[MAXPLAYERS+1] = {false, ...}; Knowing that SourceMod already keeps track of this internally: Are the native calls really that taxing?

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.

[GoD-Tony]

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?

[Mister_Magotchi]

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.

[GoD-Tony]

Originally Posted by Mister_Magotchi 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.

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.

Originally Posted by Mister_Magotchi 2. [...] Alternatively it could be made conditional, using AddCommandListener when it's available, or if it returns false, using RegConsoleCommand.

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.

Originally Posted by Mister_Magotchi 3. [...] 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.

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.

Originally Posted by thetwistedpanda It is still being discussed as to best handle to management and distribution of the plugin, be it given it's own sub forum or a post such as this.

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

[psychonic]

Originally Posted by GoD-Tony 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.

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

Originally Posted by GoD-Tony From where I stand, I would prefer to only deal with contributions without having to manage or distribute.

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.