When a user creates a Legacy Bungee gate, said gate becomes accessible on their personal network.
When entering a Legacy Bungee gate activated as the destination of a personal gate, it will teleport you to another server.

Environment

Plugin Version: ALPHA-1.0.0.4 (Migrating simulated 1.0.0.2 config, Test Environment unit 2-Spigot-Offline-MigOld-Modern-SQL)
Server Version: 3491-Spigot-b081915-95d233d (MC: 1.18.2) Implementing API Version 1.18.2-R0.1-SNAPSHOT

Description.

I don't understand this issue:

• What is the expected behavior?
• What behavior did you get in comparison to the expected behavior?

Isn't this how a legacy bungee gate works, it always teleport you to another server as put in there in the network part of the sign

When a user creates a Legacy Bungee gate, said gate becomes accessible on their personal network. When entering a Legacy Bungee gate activated as the destination of a personal gate, it will teleport you to another server.

Expected Behaviour:

1. Legacy bungee gates are weird, and probably shouldn't be considered personal gates.
   • As it is impossible to choose a legacy bungee gate's network, it ends up forced to personal (and/or possibly default).
   • This makes no sense as it forcefully pollutes whatever network it ends up on, with no alternatives.
   • A possible alternative is the h flag, but as that has a bypass node, this still makes no sense.
   • Therefore:
     • If I make a networked personal gate, it should not include legacy bungee gates in the list.
     • It should not be possible to access legacy bungee gates through their creator's personal networks.
     • Legacy bungee gates should not care about stargate.*.network.personal
2. Since all legacy bungee gates are weird, they should probably be on their own network.
   • Such a network should be independent; perhaps $bungee$ or something?
     • As a special network, it should be impossible to create normal portals on it (treat it like the terminal network)
   • Some sort of a custom node, like stargate.*.network.bungee would probably make more sense.
3. If, for some reason, a bungee gate is activated as the exit of a networked portal, it should behave as discussed in #169.
   • The user should not be able to enter from the exit.

Observed Behaviour:

1. Legacy bungee gates function on your personal network.
   • If I make a legacy bungee gate, no matter what, it will be on {myName}
   • Legacy bungee gates are accessible on your personal network.
   • Legacy bungee gates check stargate.*.network.personal
2. Networking for bungee gates is far less intuitive than "$bungee$ or something".
3. If you enter a bungee gate after it was activated as the exit from a personal gate, you get sent to another server.

Update: it appears that legacy bungee gates try to take the server name as a custom network. As such, it checks stargate.*.network.custom.ServerName.

if the player does not have permission for said custom network, it falls back on the player's personal network, and thus checks the personal perms.

Update: it appears that legacy bungee gates try to take the server name as a custom network. As such, it checks stargate.*.network.custom.ServerName.

if the player does not have permission for said custom network, it falls back on the player's personal network, and thus checks the personal perms.

I take it that the correct behavior would be to skip all personal network stuff if the portal has the legacy bungee flag?

Update: it appears that legacy bungee gates try to take the server name as a custom network. As such, it checks stargate.*.network.custom.ServerName.
if the player does not have permission for said custom network, it falls back on the player's personal network, and thus checks the personal perms.

I take it that the correct behavior would be to skip all personal network stuff if the portal has the legacy bungee flag?

That would probably be a good start.

That said, I think it may be a good idea to treat legacy bungee networks similar to how we treat the terminal and default networks.
That is to say, by reserving a special network that is only used by such gates (like %bungee% or something).

That way, we can skip both the custom and personal checks and manage checks based on the sg.*.type.u node (and possibly something like sg.*.network.bungee)