Portal Types (Flags)
Always-on gates are always active; that is to say, they will always display their traversable material.
Activators (buttons or coral) will not automatically be placed for Always-On gates..
Generally, always-on gates are used in spawns and server-builds.
By default, they are available to users with the sg.preset.builder node.
Backwards gates are functionally backwards; when exiting at a backwards gate, users will teleport to the side opposite to the sign.
Generally, backwards gates are used in spawns and server-builds as a way to hide signs.
By default, they are available to users with the sg.preset.builder node.
🧩 Add-on ⛔ Not Yet Implemented
🧩 Add-on ⛔ Not Yet Implemented
🧩 Add-on ⛔ Not Yet Implemented
By default, players using Free gates will not be charged the usageCost specified in the config.
Generally, free gates are used for server utilities.
By default, they are available to users with the sg.preset.moderator node.
🧩 Add-on ⛔ Not Yet Implemented
[H]idden
Hidden gates do not appear on the sign interfaces of networked portals on their network.
Generally, the hidden flag is used on various networks to hide fixed gates or infrequently used portals.
By default, they are available to users with the sg.preset.gatemaker node.
A brand new feature in SG Rewritten, Interserver gates leverage a new protocol to extend normal gate behaviour across your network! i gates work on Waterfall and Bungee proxies, and require a remote relational database to function.
Simply make any portal as you normally would, only this time, include the i flag.
To connect to it, use normal syntax; just be cognizant that i portals will only be able to see other portals if they also have the i flag.
Generally, i portals are used to link server utilities across a network.
By default, they are available to users with the sg.preset.builder node.
🟢 Unused
🟢 Unused
🧩 Add-on ⛔ Not Yet Implemented
🟢 Unused
No-Network gates are normal gates, with normal networks -- the only difference is that the network is hidden on the sign.
n portals used rarely; sometimes in spawns, and sometimes in maze-like minigames.
By default, they are available to users with the sg.preset.builder node.
⛔ Not Yet Implemented
Private gates are gates on your personal network that you, and only you, can see and use.
Other users will not be able to activate private gates; additionally, they will not be able to use them as their destination.
Generally, private gates are used on personal networks for private utilities (farms, bases, etc.).
By default, they are available to users with the sg.preset.gatemaker node.
⛔ Not Yet Implemented
Random gates are similar to always-on gates, except for one key thing; they don't have a fixed (or selectable) destination.
When a user enters a random gate, the gate will choose a random gate on its network to teleport said user to.
Generally, random gates are used for RTP systems, build showcases, and minigames.
By default, they are available to users with the sg.preset.moderator node.
⚠️ Deprecated
Previous versions of stargate hid fixed gates from network lists; the S flag would force such gates to show up on said lists.
Currently, this flag will force private gates to show up on network lists that such gates would otherwise be hidden from.
Note that users will still be unable to access these private gates, and as such, this flag is purely visual at present.
S gates are rarely used, and are kept solely for backwards compatibility.
By default, they are available to users with the sg.preset.builder node.
⛔ Not Yet Implemented
⚠️ Deprecated
Before the i protocol was developed, old versions of StarGate took a much simpler approach to interserver teleportation.
The u flag is very antiquated, and uses a completely different sign format that is disparate to all other flags and gates in this plugin.
u portals can be made with the following sign formatting.
Note that they can not connect to any other stargate portal, with the sole exception being another u gate.
Portal Name
Destination Portal Name
Destination Server Name
FLAGS
u gates primarily exist for reverse compatibility reasons; legacy imports will keep existing bungee gates and transform them into this format. Apart from that, u gates are sometimes used for their simple protocol; they can be used without the need for a remote relational database.
By default, they are available to users with the sg.preset.builder node.
🧩 Add-on ⛔ Not Yet Implemented