Networked A Gates Are Not Persistent
Pheotis opened this issue · 4 comments
Networked A gates do not remain open between server restarts.
For many of the potential applications such gates fulfil (and possibly fulfiled by C gates), this could be a problem.
Might it be possible to remember the last active destination for these portals and reopen them after a restart?
I've mostly implemented this, one question. I have found one issue though.
The destinations that show up depends on the permissions of the activator. We could of course store the uuid of the activator over the database, but there's literally no way to check if an offline player has permission using the bukkit api. We would need to use Vault for that.
So is it fine to just list all destinations, or should we go the more complicated route for this?
The destinations that show up depends on the permissions of the activator. We could of course store the uuid of the activator over the database, but there's literally no way to check if an offline player has permission using the bukkit api. We would need to use Vault for that.
It kind of seems to me that always-on networked gates might as well ignore the activation permission check, as anyone can enter after some player with the right permission (and the player that activated it cannot stop it from teleporting to that destination as part of the teleportaion). What would make sense, to me, is to just store the last destination, and automatically activate the gate to that destination, ignoring any permission checks. Instead of checking activation permissions (at all, really), it should check if any player trying to teleport has access to the destination.
So, to sum it up, I think always-on networked gates should work more like fixed always-on gates. On startup, activate them to the lastly used destination (regardless of which player activated it, and their current permissions), or the first destination in the network (if it has never been activated before). Allow any player to change the destination to any valid destination in the network (ignoring permission checks, but properly removing any destination unavailable because of their flags), and only check whether the player has permission to teleport to the destination when they enter the Stargate.