AliasAlreadyTaken reports: If a jailed person logs out, t ... #3048
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
ugh/petz
ugh/QA main
ugh/QA NOK
ugh/QA OK
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: your-land/bugtracker#3048
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:
fixed in
1ed10bc9dc
Upon login:
playername instead of playerobject problem ;)
Fixed in
839945c653
Still not fully fixed. Now if a jailed person logs out and then logs in again, they are sent into the jail channel: OK
But now when they are unjailed, they do not get their privs back. They stay invincible and jailed
there were a couple checks that were missing. i've reworked it a bit and tested that privs are kept.
i do think "jailed" shouldn't be a "privilege", it's basically the opposite of one :) but that's another topic.
Unfortunately true. /grantme all -> boom, jailed.
From a datastructure point of view, where should such a metadatum reside? Clearly with playermeta.
Unfortunately playermeta cannot be accessed from the outside or when a player is not logged in.
What CAN be accessed while a player is not logged in? mod storage or some file of our own.
We must not store any playernames in modstorage, the way it is layed out makes it pretty heavy and unsuitable to access a player-metadatum in there. Worst example. party mod, it stores ALL playernames in modstorage.
We cannot outsource a lot of metadata as privs, this will soon get pretty cluttered, especially when we want to store more than a boolean decision (is jailed/ is not jailed)
That leaves us with some file of our own, read yl_settings. Until then, we'll need to abuse the privs.
The "correct" solution to this problem would be to make the core devs allow access to playermeta from the outside, like privs are. yl_settings is only a means to go around the shortcomings of the engine at this point.
i tried to write some code that prevented staff from granting themselves the "jailed" priv, but it resulted in a stack overflow no matter what i did, and i'm not sure why, but making it not a "privilege" is probably the better solution.
yeah,
minetest.get_player_meta(player_or_name)
should be a thing. is there an issue about that?https://github.com/minetest/minetest/pull/9164
and
https://github.com/minetest/minetest/pull/9177
and
https://github.com/minetest/minetest/pull/4155
When a jailed player leaves the server:
Btw, should we post followup issues like this in a new issue?
this is due to a botched fix, so it should stay here. i never encountered this because there's no "Service" account on my test server w/ the right privilege, so smart_chat gave up earlier.
fixed it again:
2421c3a8c0
This works as expected now :)
Cooool!
this is live