Tighter interface with Lua admin suite
Some low level code might require a tighter interface with the Lua admin code.
For example, admins shouldn’t be kicked by ClientInactivityTimer().
Check the code and add a Lua hook if required.
See G_shrubbot_permission calls in etpub mod code.
#3 Updated by Timothy about 3 years ago
Is it also possible to remove some output in existing lua functions? For example et.MutePlayer also gives feedback to the player that’s being muted, which in my opinion doesn’t fit in a lua interface, as it should only do what’s requested and then let lua handle any output. This also solves the issue of formatting, because at the moment I’m unable to style the output.
#4 Updated by Spyhawk about 3 years ago
Vanilla includes Mute, Unmute, Warn, Kick and Ban. That’s the strict minimum for administration.
We should keep these, but move all others commands that have been added to Lua. That includes gib, die, freeze, unfreeze, burn, pip, throw.
RevivePlayer (from vanilla) should probably be moved to Lua too .
#6 Updated by IR4T4 about 3 years ago
When we ship WolfAdmin with installs there is no need for keeping such half implemented commands in qagame.
We need db persistence for bans and mutes anyway and this is given on engine or Lua side. Timo did implement a ban system with ip/ip range bans.
Finally most later/active mods support Lua, WolfAdmin isn’t legacy only and the engine can grab sqlite3 data. Let us simply define game manangement is a Lua task.
#7 Updated by Spyhawk about 3 years ago
!gib is implemented
!die what’s that for?
unfreeze cannot since I cannot modify ps.origin
fling and !launch for the same reason cannot be implemented in Lua only
pip and !pop also need mod-related edits
TODO: ship relevant pk3 files (such as pm.wav) directly with legacy mod. done
#8 Updated by Timothy about 3 years ago
I took the liberty of removing some obsolete shrubbot calls (see 1c0e3ac78752bf3f3a340ae8c3298ec2c28a68ce). I think it is a good idea to decide on the approach we would like to take given the fact that WolfAdmin is able to run standalone and has taken over quite a lot of functionality already. Ideally I would port more of the existing game management functionalities to WolfAdmin, but I would like to leave this up to you. After all, WolfAdmin has to prove itself as a reasonable alternative for what would previously be provided by shrubbot.
At this moment, I am thinking of several routes that we could take. The solutions described in option 1 are a subset of 2, 2 of 3 and so on.
Option 1: bare minimum¶By this I intend to get rid of everything related to game management and keep the bare minimum. This excludes any features related to warns, mutes and bans from the mod code, as well as removing the inactivity checks and possibly even forced team balance. After removing this, the game and mod will only provide some mere hooks/lua functions if needed:
- voting hooks (no voting limit, players immune to certain votes);
- chat hooks (team chat spying);
- entity/world modifying functions (e.g. et.setPlayerVelocity for launch)
Option 2: minimum + vanilla features¶
This option is roughly the same as above, however, in this case inactivity checking and balanced teams can be provided by the mod code to give at least some admin features by default. However, extra hooks may be needed:
- activity hooks (no inactivity putspec or kick);
- team hooks (ignore team balance);
Option 3: basic admin in mod¶
As the name suggests, also provide minimal admin features, e.g. warn, mute, kick as implemented by vote and/or referee commands. This is kind of the same situation as it is now, which is not ideal for rookie admins as WolfAdmin might provide alternatives and confuse them.
Of course, if any of these options is used, we have to decide on how to implement these hooks/features. Currently et.MutePlayer only sets sess.muted (which can also be set using et.gentity_set) and prints some feedback to the involved player(s), which I find a little cumbersome; a Lua function should only do what is necessary, and leave any output to the calling Lua script. I would also like to hear your opinion on this aspect.
All in all, from my perspective option 1 is the ideal situation: no confusion can arise of duplicate features and a minimum of hooks for a Lua interface is needed. This would entirely separate the player/game management from the mod (except for referees/voting?). I would understand that you find this a rather extreme approach, so any combination of the above is also fine with me. I would just like to know the desired route so I can take this into account for the next iterations of WolfAdmin.