Beacon Permissions

Don’t know if I understand you right here, but that’s the current model I guess. Place a lock on a block next to whatever you want to lock. Locks don’t lock the block it is placed on. But the block should not be removable from villagers, since the block is necessary for the lock.

Well as I said, my simple system is sufficient for me. If i would have villagers, no villager would have different persmission to others. There is no reason coming into my mind, which would justify different permissions. Either I want him as my villager or not.

What might be different, if we talk about dozens of people. But then it’s more like a guild. Then i’d prefer also to create different groups with give and take permissions. But till now I understood, there will be a difference. Maybe we can set still our private beacons (where my system is still sufficient for me) and - when created a guild - guild beacons. Here hierarchy can (and imo should) be very individual… There definetly is necessarity to say who is allowed to do what. Beginning from setting / deleting beacons to taking and placing items in guild storages.

sorry i tough you men’t that entire building gets locked with that 1 lock so villager can’t destroy your building and get inside

will there be guild beacons? if so then normal beacons should be as simple as you say’d for only the ones your trust and guild beacon for building an empire with random people with strong permissions (with something similar i suggested).

Thanks guys. There’s some useful feedback there.

I’ve read through it all, but I need some time to digest it. Don’t expect a quick fix in this area, but we will do another pass on the beacons and locks and get to a better system.

7 Likes

Don’t forget to take a look at the ‘vertical reserving’ of plots while you are at it :wink:

1 Like

My Opinion.

Do you want to be able to allow people to build in your beacon without being able to interact with your plinths, storage etc?
-No, I would not want people to interact (or destroy) with my “intractables”, or each others, only their own.

If so, would you be happy that they could not place or break any intractable blocks / props?

-I would like them to be able to place their ownand interact with their own, and as a mayor be able to interact and destroy those “interactables”.

Can you think of other things you would want to allow people to do, or prevent them from doing in your beacon?

Along these lines… Have the option of banning specific blocks (i.e. Lava blocks) in the plot as mayor, this will allow the mayor to have good control of their city.

2 Likes

Hello, did you guys made any plans for this matter yet? Or still apply suggestions?

Hello,

The current thinking is to have a single “Owner” of the beacon who is initially the person who placed it. The Owner can break, place and interact with anything in the beacon, as well as being able to add and remove plots and change the permissions on the beacon. There are two other roles people can be given: “Builder” and “Worker”. Someone can be one, or the other, or both of those things. Builders can place and break non-interactive blocks and props, but not interact with anything. Workers can interact with things, and place and break interactive objects, but not place or break anything else. We may decide to allow both workers and builders to interact with doors.

That should give you most of what you need, and then when Guilds come along there will be more control with that system for collaboration (for example allowing more than one person to add and remove plots).

11 Likes

I’ve just been reminded by another thread that I meant to post something meaningful here about a potential permissions limitation with this system. It might be worth revisiting with a view to incorporating a permission for interacting with interactive blocks, but not destroying/placing them.

Frustratingly, I think I get why the distinction has been made where it has, and it’s a pretty elegant solution. You’re separating blocks by functionality to provide two permissions which don’t overlap and can still tidily be used in conjunction. I don’t know what better solution there may be, but if it isn’t too complicated, sub-dividing the Worker permission into one with the ability to break/place interactive blocks, and one able only to interact with them might be enough.

Granted, there is then some unwanted overlap (A person with the ability to place & remove interactive blocks could in many cases destroy the block to access it’s contents, circumventing the companion permission), but I think the ability to allow new players access to machines without allowing them the ability to pick up and run off with them would be a positive move for the community.

If it’s awkward to do, or impractical, perhaps there’s something that can be done with locks… Maybe a way to lock an interactive block (or group of them) from being removed, but leave it open to be accessed?

2 Likes

I agree with the potential limitations here.

From a “role” standpoint, it seems that builders would be limited to being handed crafted blocks personally in order to build. Without the ability to interact with machines, or storage blocks it sounds like builders may be forced to run back to their own plots to craft blocks with which to build on a shared plot. More than anything, I feel as though some level of permission should grant for interaction and not the ability to place/remove the blocks being interacted with.

suggestion: Add an option for “builders” to access only the completed items from a machine, so processed blocks could be easily obtained and built with. Potentially another machine add-on like a hopper.

suggestion: Add functionality to allow mayors to subdivide permissions between different plots. e.g. machines in some plots could be interacted with while other plots may have higher permission thresholds. This could allow workers to place and use machines in plots being built upon by builders furthering the interaction between the two roles while preventing rogue workers from maybe stealing the machines in a mayor’s personal plot.

suggestion: If the goal is to add many roles, than this one certainly wouldn’t fit, but combine the two roles into a form of laborer role that can access interactive objects and place non-interactive blocks, and add another tier of citizen that would act as an elder ring with the ability to place interactive blocks (potentially without the ability to access them), dole out certain permissions, etc.

1 Like

I think the most elegant solution is to require a person to have both builder AND crafter permission to be able to remove an interactive object. Builders can still gain access to approved tools via low cost or free plinths (much as we do already) and crafters don’t need the ability to remove interactive blocks in the first place- just work with them. You wouldn’t allow a grocery store clerk to take off with the shelves- just restock them. But you would allow the manager (whom you trust far more than the clerk!) to do what ever they need to with the store- they’ve proven their reliability before you promoted them to manager, right?

7 Likes

@olliepurkiss Can you confirm this?

I just want to say that I wasn’t really intending to open this up a thing that needs an overhaul, just a slight tweak. I think Havok’s suggestion (and possibly even the way it is intended to work that just got lost in it’s translation from english to Marrash) seems pretty good, and covers all the basic needs for personal beacons.

I’ve posted on this in the other thread, before reading this.

I think it’s a neat solution to need both permissions, but it might not be crystal clear to people. I’ve proposed the addition of a third permissions type:

2 Likes

I agree that subdividing will be wanted within a big build (your middle suggestion). I’ve always thought that the way to do that though is to allow people to split new beacons off from an existing beacon, and then each beacon can have its own permissions. That seems to be the simplest way of doing it conceptually.

7 Likes

Colour coded beacon controls!? :smiley:

7 Likes

This class based permissions are the plan for 1.0 too? What about a checkbox-category system?

Like at the beacon control you have the permissions menu, where you can see the permission categories (like interactables), and within each category there are 3 checkboxes: ‘only me’, ‘add player/guild’ and ‘everybody’. The ‘only me’ is the default in each, and if you check the ‘add player/guild’ from the 3, there you can add players and guilds to access that category. ‘Everybody’ is obvious.
And the categories could be: (everybody can interact with non-locked doors and non-locked trading plinths, they are not on the list)

  • Interact with locked doors
  • Interact with locked trading plinths
  • Access to non-locked trading plinths (so can put/withdraw items and coins, not just trade with it)
  • Access to locked trading plinths
  • Interact with non-locked machines
  • Interact with locked machines
  • Interact with non-locked storage
  • Interact with locked storage
  • Interact with portals (can fuel, close/open it)
  • Warp in/out (so can build warp inside the beacon)
  • Place/break non-interactive blocks and props
  • Place/break interactive blocks, props and locks
  • Interact with beacon control (who have permission in this, can access the permissions menu too)
4 Likes

I like the idea of a checkbox that allow anybody to fuel beacon and portals without getting access to anything else, and without have to be added to the beacon.

So like an ‘- Add fuel’ permission category not listed above? Which allows the checked persons to access the beacon and portals fuel tabs but they can only add fuel to it and cant withdraw? If it is possible it could be default, so we dont need the checkbox category for it, cause who dont want free fuel? :smiley: But if its not possible, with my categories only those could fuel a portal whose can defuel, and open/close, redestinate it, and only those could fuel the beacon whose can defuel it and have access to the permissions menu too. So if this is the case only trusted people can fuel portals/beacons, cause they could defuel it too.

I mean, if i see a nice builds or a portal that soon run out of fuel, i can fill it without to be added to any beacon, or even know who it belong to.

5 Likes

Sure thats why (only) adding fuel to beacons/portals should be open to everyone, if its possible (from developer side).

5 Likes