Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend protection api to allow for protection from specific actions #2250

Closed
t4im opened this issue Feb 2, 2015 · 9 comments
Closed

Extend protection api to allow for protection from specific actions #2250

t4im opened this issue Feb 2, 2015 · 9 comments
Labels
Feature request Issues that request the addition or enhancement of a feature @ Script API

Comments

@t4im
Copy link
Contributor

t4im commented Feb 2, 2015

Status quo

boolean minetest.is_protected(pos, name)
Currently lacks returning the protection status depending on conditions:
i.e. against what is being protected.

Proposal

I propose a simple backward compatible extension of is_protected, that does not require any code change.

After the decision to make it public api and add to the documentation mods could instantly begin to use it, as it is being directly passed to the protection mods.

boolean minetest.is_protected(pos, name, action)
if action == nil or unknown assume our current status quo, that is permissions to dig or place, which are the most frequent checked actions anyway.

  • Old protection mods will work as-is, assuming these permissions anyway.
  • New protection mods will have to check action for nil and assume the same in that case.
  • New protection + protected in combination can flexibly start making exceptions.

Examples

  • An spawn area might be protected against anything but inventory actions (by simply having that check in the inventory callbacks). This would allow placing public technic machines there for everyone to use without having to fear those machines getting "misplaced".
  • The bucket mod could check for fill allowing players to allow others to fill up that renewable water even in protected areas but not to do anything else.
  • doors could check if the protection mod allows a player, even though he may not change anything, may enter the area through the door
@t4im t4im changed the title extend protection api (backward compatible + no code change needed) to allow for flexible permissions where needed extend protection api (backward compatible, no code change) to allow for flexible permissions where needed Feb 2, 2015
@rdnuk
Copy link

rdnuk commented Feb 2, 2015

This is a brilliant idea :)

@ShadowNinja ShadowNinja changed the title extend protection api (backward compatible, no code change) to allow for flexible permissions where needed Extend protection api to allow for protection from specific actions Feb 3, 2015
@ShadowNinja
Copy link
Member

Seems like a good idea, but it won't be efficient. If we were using Lua 5.2 or above we could use bitops, and with 5.3 we have operators for them, but in the abscence of those it will have to be a table like {dig=true, place=true}.

is_protected shouldn't be expected to be especially efficient though. Some mods can check positions quickly while others might have to look for a specific node nearby and/or read meta.

@est31
Copy link
Contributor

est31 commented Feb 7, 2015

👍

@Rogier-5
Copy link
Contributor

I have another suggestion for an improvement in the protection API.

The current API can be used to prevent users from making changes in areas that are owned by others. However, it is not possible to also grant users additional powers in areas that they do own, powers they can't use elsewhere.

I propose that the API be changed so that is_protected returns two values: whether the player can perform the requested action, and whether it has any special authority over the node at all:

access_denied, area_protected = is_protected(pos, player, action)

For existing users, nothing changes (they still use the 'access_denied' value, which tells them all they need).

Any new mod could use the area_protected value to grant additional powers that the player does not have elsewhere.

@nerzhul
Copy link
Member

nerzhul commented Feb 27, 2015

Could be interesting.
Another interesting change could be a restricted server interact but protection allow interactions in some dedicated areas to player with rights. Instead of a global allow with some interdictions

@neoascetic
Copy link
Contributor

+1

@paramat paramat added the Feature request Issues that request the addition or enhancement of a feature label Mar 31, 2016
@t4im
Copy link
Contributor Author

t4im commented Jun 28, 2016

action Should probably not be a table, since that indeed will lead to many people creating new tables over and over again inline, which is indeed unnecessary inefficient.

I was thinking about strings, which lua interns anyway. So comparisons are done on identity, which should not have a very big performance impact.

action in the proposal could be using varargs, but do we really need to check for several permissions at the same time? Inventory moves, door openings, dig and place etc. won't be checked in the same callbacks anyway. So passing several action requests (varargs, table, bitopts) might not even be useful most of the time, since the results couldn't be cached anyway.

@paramat
Copy link
Contributor

paramat commented Apr 13, 2018

Any core dev interest? Nerzhul expressed possible interest 3 years ago.
@nerzhul

@paramat
Copy link
Contributor

paramat commented Jun 24, 2018

No core dev support or response for 3+ years so closing. Core devs feel free to reopen if you support it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature request Issues that request the addition or enhancement of a feature @ Script API
Projects
None yet
Development

No branches or pull requests

8 participants