AliasAlreadyTaken reports: Add a chatcommand for staff an ... #4261
Labels
No Label
1. kind/balancing
1. kind/breaking
1. kind/bug
1. kind/construction
1. kind/documentation
1. kind/enhancement
1. kind/griefing
1. kind/invalid
1. kind/meme
1. kind/node limit
1. kind/other
1. kind/protocol
2. prio/controversial
2. prio/critical
2. prio/elevated
2. prio/good first issue
2. prio/interesting
2. prio/low
3. source/art
3. source/client
3. source/engine
3. source/ingame
3. source/integration
3. source/lag
3. source/license
3. source/mod upstream
3. source/unknown
3. source/website
4. step/approved
4. step/at work
4. step/blocked
4. step/discussion
4. step/help wanted
4. step/needs confirmation
4. step/partially fixed
4. step/question
4. step/ready to deploy
4. step/ready to QA test
4. step/want approval
5. result/cannot reproduce
5. result/duplicate
5. result/fixed
5. result/maybe
5. result/wontfix
source/testserver
ugh/petz
ugh/QA main
ugh/QA NOK
ugh/QA OK
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: your-land/bugtracker#4261
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
AliasAlreadyTaken reports a bug:
Player position:
Player look:
Player information:
Player meta:
Log identifier
Profiler save:
Status:
Teleport command:
Compass command:
which privileges? is this something more than the basic_privs privilege/setting?
Yes, that's about areas, creative and similar. Some staff have privs they do not want to be active all the time, they need a way to enable and disable them.
The yl_roles mod defines roles, singular privs and what takes precedence, this way it is cached who has what priv and can happily enable / disable with a chatcommand
I gave my fast priv back to Alias for some reason. Ok, this special problem was solved in the time between, but to decide about witch priv should be active or not is an option I would prefer.
fast, fly and noclip have keys they can be enabled and disabled with, but areas and creative and the others I mentioned you either have or have not.
makes sense now. i think a mechanism similar to basic_privs would work, but call it "staff_privs"? i guess that doesn't allow for managing players w/ different privilege sets though.