So certain permissions are assigned to the npc_action context, then when the player interacts, the player will be put into the npc_action context (and grants the certain permissions) and the commands will be executed.
#Use LuckPerms Context for player_command_as_op action
final narwhal
now wait a minute, that's quite genius
although only for servers using LP, which isssss most but yeah
loud jungle
Servers that don't use LP are those kind of servers still using Citizens anyway
(nah actually I have no idea about popular permissions plugins)
final narwhal
PowerRanks... 😓
though I've seen so many servers use LP and Citizens, somehow having the courage to recommend FancyNpcs instead 👏
left trail
powerranks ew
ocean heron
Good idea, but how would you figure out what permissions player need to run the command?
final narwhal
Hm
ocean heron
Maybe we could then remove run_command_as_op altogether and add another action named grant_temporary_permission which grants permission temporarily and remove it once action chain completed?
final narwhal
I thought Oliver's idea was for a player to manually add the permission to the npc_action context
ocean heron
Yeah that'd work best I think
though there's no point of having player_command_as_op then, just player_command.
final narwhal
Yeah true, but we don't want player_command_as_op anyway 😃
ocean heron
Yes, but logic should be kept for backwards compatibility. Just disallow creation of new actions like that and add a metric for amount of servers using it. Once there's none, we can remove it.
final narwhal
Right
ocean heron
Also my grant_temporary_permission action don't make sense now that I read LuckPerms' docs again. So player would set these permissions in LuckPerms directly. Even better tbh.
final narwhal
Yeah
ocean heron
I imagine context like npc-action:<npc_name> would be better just to isolate it even more.
(and if possible, maybe make the npc-action (without a name specified) to be applied globally, for those that are lazy)
Also important note: this context should work only for when player_command action is executed, not for the whole chain. Otherwise it'd be possible for user to run the command multiple times eg. during the execution of wait action.
final narwhal
I also thought of that tbh
ocean heron
I imagine with this implemented and player_command_as_op disabled, we would need to improve docs to make this setup clear.
Because otherwise A LOT of people will ask questions. (Even if docs for that existed, but then we can just link)
final narwhal
Yeah I think the tricky part is going to be npc_action / npc_action:... contexts
Wave of new questions for us to answer in #npcs-questions 😄
Now, I'm not sure if we can remove it as I don't think all servers use LuckPerms, probably 90% at best
ocean heron
If we don't disable the op action, then nobody will use the new one.
That's because server owners don't care how it works, but how easy is it to setup. They would reflect on that only after they misconfigured it and some player would have exploited that on their server. (and would probably still put the blame on us 😛)
I guess we can still provide run_command_as_op but it should be completely removed from command completions.
Well we have a warning now so maybe we can keep it... Up to Oliver at this point. I'm all for removing this janky impl, but that's my opinion.
left trail
Maybe we could then remove `run_command_as_op` altogether and add another action...
maybe could do smh like check what permission a command needs n grand it for run_command_as_op
much more safe than giving op for a split second
ocean heron
Well it'd work until someone wants to use a sub-command. I believe only "root" (base) commands have attached permissions. So eg. /fancynpcs -> fancynpcs.command.fancynpcs but /fancynpcs reload -> ???