Ulysses Stuff > Suggestions

Temporary user group change

<< < (2/4) > >>

MrPresident:
That would be good for small scale. I don't know what would be more resource intense... running a query on connected players that have temp groups every x minutes or potentially having a hundred timers running at the same time.


I could query the db when a player joins and create a timer for that player only and have it stop when they leave the server. Combining this with checking when they join could keep the timers from needing to change groups while the player isn't connected.

That also brings up another concern... how would I go about detecting if the players group has been changed.. is there is groupchanged hook? lol.. otherwise you could permanently change someone's group while their in a temp group and the script would change their group to whatever you had set it to even though it shouldn't.

JamminR:

--- Quote from: MrPresident on July 01, 2011, 03:05:06 PM ---I could query the db when a player joins and create a timer for that player only and have it stop when they leave the server. Combining this with checking when they join could keep the timers from needing to change groups while the player isn't connected.

--- End quote ---

Just outloud thoughts. One of you geniuses will figure out better/more efficient way.
Store the steamid, original group, temp group, time allotted. (I still prefer text, but sure, have it SQL capable for those 'real' servers)
Run a timer where every 6(?) hours, the server checks and loads the next 6 hours of expirations..load those as timers.
Add 'feature' that if a player joins that is in that table during those 6 hours...the host can have that user warned to go beg for more status/pay more money, whatever.


--- Quote from: MrPresident on July 01, 2011, 03:05:06 PM ---That also brings up another concern... how would I go about detecting if the players group has been changed.. is there is groupchanged hook? lol.. otherwise you could permanently change someone's group while their in a temp group and the script would change their group to whatever you had set it to even though it shouldn't.

--- End quote ---

Not specifically group changed hook, but, extremely useful.
http://ulyssesmod.net/docs/files/lua/ulib/shared/defines-lua.html#UCLChanged

You should also monitor for bans (auto remove), or kicks (allow 'feature' to have temp group removed, optional (in case they have admin kick wars, etc))

If banned, remove from table (and existing timers) entirely (same as with kick if auto remove enabled)
If promoted, if promo group = temp group, remove from table/timers.
If promoted, if not promo group = temp, change "original group" table to 'new/promo group'.

The only challenge I see after that is having your function determine that the UCLChanged hook your running isn't the changes it may be doing itself.
>Heh. We could almost move this topic to Devs corner.

MrPresident:

--- Quote ---UCLChanged

Called on both server and client when anything in ULib.ucl.users, ULib.ucl.authed, or ULib.ucl.groups changes.  No parameters are passed to callbacks.
Revisions
v2.40   Initial

--- End quote ---


this hook just simply is called when something in one of those tables changes. I don't know how this could help me with the specific issue of determining if a specific players group was changed, any ideas?

JamminR:
Now that I look closer, my idea isn't extremely efficient, but, I think it would still work. As always, it's just to build on.
UCLChanged as it stands -

--- Code: ---local function UCLChanged()
ULib.clientRPC( _, "ULib.ucl.initClientUCL", ucl.authed, ucl.groups ) -- Send all UCL data (minus offline users) to all loaded users
ULib.clientRPC( _, "hook.Call", ULib.HOOK_UCLCHANGED ) -- Call hook on client
end
hook.Add( ULib.HOOK_UCLCHANGED, "ULibSendUCLToClients", UCLChanged )
--- End code ---

Bah, I just spent 10 minutes in this post writing logic that ended up looping itself several times.
I nixed it.
It's possible, just lots of checks I couldn't figure out in a reasonable amount of time on my part.

Just monitor ULibPostTranslatedCommand for any 'ulx <command that might change user access>' and act on it accordingly if one of the temp players is in the translated args table.
At least it gets passed some parameters to check, and probably more efficient to find the temp player in it.

Stickly Man!:

--- Quote from: JamminR on July 01, 2011, 08:07:27 PM ---Store the steamid, original group, temp group, time allotted. (I still prefer text, but sure, have it SQL capable for those 'real' servers)
Run a timer where every 6(?) hours, the server checks and loads the next 6 hours of expirations..load those as timers.
--- End quote ---

This works too-- I do the same thing in XGUI for checking when ULX bans expire, except I have a timer that runs every hour that creates timers for bans that expire in under an hour.



--- Quote from: MrPresident on July 01, 2011, 08:53:29 PM ---I don't know how this could help me with the specific issue of determining if a specific players group was changed, any ideas?

--- End quote ---

ULibPostTranslatedCommand on the adduser, removeuser, adduserid, and removeuserid commands works fine, but if a third party makes a ulx command that changes group without calling the ulx commands, you could just add your code to the end of ULib.ucl.addUser and ULib.ucl.removeUser.



--- Quote from: MrPresident on July 01, 2011, 03:05:06 PM ---I could query the db when a player joins and create a timer for that player only and have it stop when they leave the server. Combining this with checking when they join could keep the timers from needing to change groups while the player isn't connected.
--- End quote ---

I'm all for making sure that temp group "demotions" are executed exactly when they need to be-- If I temporarily promote "bob" to superadmin for a day, but then he never joins the server again, weeks later he will show up in the "superadmin" group even though he's really not in that group anymore.

Navigation

[0] Message Index

[#] Next page

[*] Previous page