[sawce]

Originally Posted by James Its promising except> Added amb307: amx_addban now caches the last ten connections. This is really annoying, and IMHO wasting CPU time, i stay on my admincmd.sma from 1.76d

The "CPU time waste" is entirely negligible. It simply adds the info to a list after a player disconnects.

I don't see how it is annoying, either. O_o

[James]

@Emp.. you are right ;)
@sawce..: i dont know, it is my personal feeling, i dont like things like this (similiar is in anti-reconnect plugin)..

[The_Ghost]

why don't you add the cshack module in this package too ?

[sawce]

Originally Posted by James @Emp.. you are right ;) @sawce..: i dont know, it is my personal feeling, i dont like things like this (similiar is in anti-reconnect plugin)..

I don't know if you understand it right (it wasn't really explained properly in the changelog).

Previously, amx_addban allowed any user with ban access to ban any steamid, which could go around immunity. Obviously this was bad.

For a temporary measure, 1.76d changed the default access level of amx_addban to require rcon.

Now, for 1.8, admincmd.sma will keep a list of the last 10 connections to the server (cleared at map change). Users with ban access can use amx_addban on any ip or steamid in that list, as long as the matching steamid / ip did not have immunity to it (users with rcon can continue to ban any steamid or ip). Admins can also view this list (to see details of who they need to ban, if someone did something just before they left) with "amx_last".

[BAILOPAN]

The_Ghost: CSHack is a third party module that is against an older version of CS -- the author no longer maintains it and we don't have any intention to either right now.

[James]

Previously, amx_addban allowed any user with ban access to ban any steamid, which could go around immunity. Obviously this was bad.

This can be solved by check, if banned SteamID has immunity or not (via users.ini)..

I still dont get the idea of stack last connections. If is set up to 10 connections for example, cheater join and play. Between calling admin more that 10 players left and join new (because cheater is reason for player leaves). Well, when admin goes to server to check out, and cheater leave, cheater not be in last 10 connections (if i understand it right).

Anyway, i teach every admin on my servers: When are you called to server because cheater (or have suspicious to cheat), the first thing after join (or suspicion) is amx_who (against cheater lefts, and possibility to later unban), and then spectating, if someone cheats... Amx_who left detailed information about players in admins console, so where is a problem?

[sawce]

Originally Posted by James This can be solved by check, if banned SteamID has immunity or not (via users.ini)..

IPs

edit:

Additionally:

I still dont get the idea of stack last connections. If is set up to 10 connections for example, cheater join and play. Between calling admin more that 10 players left and join new (because cheater is reason for player leaves). Well, when admin goes to server to check out, and cheater leave, cheater not be in last 10 connections (if i understand it right).

If the admin that responds has rcon access, he can ban any IP or SteamID - just like it was in 1.76d. This just extends it to the people with ban access and no rcon access by allowing a list of people to ban, and allowing easy lookup of those people.

[James]

Originally Posted by sawce IPs

Maybe I wrong, but

in admin.sma loadSettings(szFilename[]) you can load IP or SteamID from users.ini
; Examples of admin accounts:
; "STEAM_0:0:123456" "" "abcdefghijklmnopqrstu" "ce"
; "123.45.67.89" "" "abcdefghijklmnopqrstu" "de"

In admincmd.sma you can in public cmdAddBan(id, level, cid) compare arg[32] with array of admins IPs/SteamIDs and when it is positive then break ban proces...

[YamiKaitou]

Not everyone uses IPs to load admins. If an admin is defined by SteamID, then you can ban that admin by banning their IP, and vise versa.

[James]

Originally Posted by YamiKaitou Not everyone uses IPs to load admins. If an admin is defined by SteamID, then you can ban that admin by banning their IP, and vise versa.

oh, i got it, finally (i think). In that case would be nice have option to set up both in users.ini: IP and SteamID admins. (one option needed, second optional).

I have no idea to prevent SteamID admin ban through IP except optional IP parameter in user.ini. When admins doesn't have public IP, he could be banned anyway, if they arent in connections stack.

P.S.: My admins doesnt ban themselves so hopefully i have'nt these problemes... (and all have public IP)