• If a user has sg.preset.gatemaker, they can create hidden gates, but can not see hidden gates on their personal network.

  • This is not intuitive; ideally, users should always be able to see their own hidden gates regardless of bypass nodes.

• sg.preset.builder can make gates on the central network, but can not break their own gates on the central network.

  • They should have permission to break gates they created on the central network, but not gates others created on the central network.
  • This is applicable to other nodes in general for custom networks.
    • We should probably add something like sg.preset.<use/create/destroy>.responsible and grant it to all players by default.
      • This allows users to break gates that they created (i.e. are registered as the owner of), regardless of other circumstances.

• On debian, gate names are processed case sensitively.

  • ie. (tHis) is a separate and unrelated network from (this).
  • This is an issue for a variety of reasons, not the least of which being superperms.

• sg.preset.builder has the S node, but does not have perms to make S gates.

• For your first point on sg.preset.gatemaker, should this be a thing only on a players personal network?
• On the first sg.preset.builder point: It does not make any sense to only be allowed to destroy your own gates as it's impossible to know if the gate is yours. Although it would be convinient, I think it breaks the Stargate philosophy: Everything about a gate should be able to be desciphered from the sign
• On the second sg.preset.builder point: I don't see it in the plugin.yml file. Should that be a thing?

True, but I think storing the owner UUID is still a good idea for example if external plugins, like SG_Command want to fetch some information about who created the portal and so on.

I generally don't like the idea of owner UUID's being used for more than that

• it's impossible to know if the gate is yours

The Portal owner has always been, and is still, stored. This directly identifies if a gate is yours. This has broken the philosophy for ages, but if we aren't to use it like this, there shouldn't be an owner stored at all.

True, but I think storing the UUID is still a good idea for example if external plugins, like SG_Command want to fetch some information about who created the portal and so on

I guess you could see it merely as metadata which is available to admins to detect abuse. This does break a lot with legacy though, as owning the Portal bypassed a lot of permissions. And some behavior, like sg.preset.builder isn't possible. You either have full access or no access, instead of being able to destroy what you've created, but not what everyone else has created.

* On the second `sg.preset.builder` point: I don't see it in the plugin.yml file. Should that be a thing?

Yes, see this

As for the other two points, I think all of this stems down to how to deal with owned gates
(assuming they are not on the personal network, which would result in them basically being treated as owned gates anyways).

Legacy broke the philosophy on that one by having some nodes that impacted all created gates, regardless of network.
As an long-time stargate user, I have spent a lot of time on servers with this legacy behaviour.

I can say that this added a lot to gameplay, especially for middle-perm'd users who had access to a custom network, but who were not themselves moderators. In practice, this worked more often than not -- users remember their own portals for the most part.

In principle, this clearly violates the philosophy, but personally, I am in favour of pushing the philosophy back on this one.
Adding owner-specific behaviour nodes opens up a lot of possibilities, and should probably exist in the main.

That said, it is probably best to find a way to incorporate this behaviour within the philosophy.
Ideally, this means some sort of client/user side indicator that the portal in question is, in fact, theirs.

I think a particle, action bar feedback, or something of that sort would probably be the best solution for this.

I think a particle, action bar feedback, or something of that sort would probably be the best solution for this.

The boss bar or the text on screen could work for this (I'm not sure if particles can be displayed for individual players?), but there is a question of what should trigger the display. If it's in the main Stargate plugin, it cannot be a command. And it cannot be too annoying either. It could be triggered when looking at a portal, right-clicking one of its blocks, or when clicking with a specific item. It could also be when getting within a certain number of blocks, but it has to be kind of neutral so it won't annoy the player every time they use one of their own Stargates.

It cannot use only colors or only particles. Colors won't work for colorblind users. Particles can be turned off for potato PCs.

The boss bar or the text on screen could work for this

• I think a boss bar is probably best, although it is probably worth looking into how it will interact with other plugins.
• The boss bar should probably be available for all users and say something like "Gate Created By: Username".
• I think it would probably be best to trigger this display by left clicking the gate's activator block or shift-left-clicking its sign.

I prefer if the sign would change text instead, something like this when you shiftclick the frame of the portal

[Stargate]
Created By:
Username
FLAGS

I prefer if the sign would change text instead, something like this when you shiftclick the frame of the portal

[Stargate]
Created By:
Username
FLAGS

And if it doesn't have a sign?

Then it could show it in the way the portal displays its info, for example in the chat

@Pheotis Can you do a /sg trace for point 3 and send me the file?

I tried reproducing issue 3 and was unable to.
As this relates to quite an old version of SG, I am going to close this with CNR.

If this bug still exists, it will probably get discovered in the next TMS run.