Admin name instead of "scriptadmin" in "ban" script function.

[T-Maxxx]

@volkv requested to add ability to log admin name if ban function has been invoked. I think it'll be enough to move actual ban functionality in seperate function and add script method called ban so we can use something like level.admins[i] ban(level.players[j]); and it'll log level.admins[i]'s name/guid/steamid/etc.

[volkv]

👍

[D4edalus]

i think the Plugin API Plugin_BanClient does that. adminname is also part of the baninfo_t struct.

are we talking about the plugin functions, the server command or the gsc script interface?

[volkv]

its about to run something like
self exec("permban id...")
which will pass admin id (self) to banlist

[D4edalus]

that will not work obviously, you are misusing a command for a script function. the admin is infered in that case from the caller. i.e. somebody writing $permban in chat to execute the command.

what you should be using in this case is the respective script function called "ban"

CoD4x_Server/src/scr_vm_functions.c

Line 2093 in 1e9b93b

void GScr_BanClient()

however, that implementation does not look very functional and should perhaps be extended.
SV_AddBanForClient is used in that implementation, but that function seems to be designed for usage in commands, as it determines the banning admin by the invoker of the command.

i believe we should replace SV_AddBanForClient by SV_AddBan at this point, and parse all the parameters (to fill baninfo_t) from the parameters given to the script function

CoD4x_Server/src/scr_vm_functions.c

Line 2111 in 1e9b93b

SV_AddBanForClient(cl, -1, "Banned by scriptadmin\n");

what do you think @T-Maxxx @IceNinjaman

[T-Maxxx]

About plugin command to ban someone. All the contents of sv_banlist.c is designed to invoke plugin event. It doesn't look like a good idea to invoke plugin command which will invoke plugin event (+loop through all loaded plugins) and only then make some actions.
About ban functionality. I see there are some kind of temp ban list (16 records). Looks good. But permanent ban system is maintained by various plugins so core game can ask plugin if player banned or invoke actions like add and remove ban record.
The way how @volkv using ban functionality (script command which executes console command, brr) is weird. So I suggest to add ban script method (the one with scr_entref_t in argument list) and rewrite ban script function. They should act the same except part of detecting invoker name (self's name or scriptadmin). And only then the banning callback will invoke plugin event.

[volkv]

@D4edalus yep sure self exec is bullshit. just a stupid example of what Iam trying to achieve.
The main reason of this request is that Iam using ingame gsc menu which admins are using to ban players (choose reason and player from playerslist). It is smart, got unified reason text and ban length (it also doubles the length in case of repeated violation) so admins dont use console at all.

So Iam looking for a solution of how to record this bans from caller admin, not from 'scriptadmin'

for now I see couple of possible solutions:

1. plugin which will wrap standard ban function with adding self->client
2. adding a ban method into cod4x (as Max suggested)
3. execute $permban from client by server request (as I know there is 'nicetohave' thread about it already)

[D4edalus]

It doesn't look like a good idea to invoke plugin command which will invoke plugin event

actually, i think its perfectly fine that Plugin_BanClient is calling the plugin callback for banning a player. that way bans can be issued by any source (gsc scripts, other plugins, commands, etc) and still be recognized via the plugin callbacks to be persisted.

So I suggest to add ban script method (the one with scr_entref_t in argument list)

since void GScr_BanClient(scr_entref_t) needs to be a separate function anyways, i guess we dont even have to worry about breaking old code, great.

void SV_AddBanForClient(client_t* cl, int bantime, const char* banreason)
i think can work fine if we add a parameter to specify the caller.

parameters to the script function would then look as follows
admin ban(player, duration, reason)

[T-Maxxx]

I meant we can ban player using script, chat and console (+rcon). Why you still want to add it to plugins too?

[D4edalus]

for example the "warn" plugin is using it to ban a player when the number of warns exceed a certain amount. other plugins may use it to stay compatible to the command/script way of banning as i mentioned. e.g: the sourcebansplugin currently just checks the database and uses dropclient to get rid of players. these bans could as well be persisted through the plugin api function, and furthermore persisted by the respective plugin callback. if done so the commandline version of bans could be used to ban as well i think and persist bans via sourcebans. i hope that explanation was not too confusing :D

the performance concern is in my opinion negligible.

also: the plugin function is there already