Stargate Mechanics

Caution

This documentation pertains to an official module.
Features described herein are NOT part of the core.

Introduction

Stargate Mechanics is an official module that introduces a variety of new portal types and mechanics to the game.

These features are cool, convenient, and useful, but many of SGM's flags and mechanics either run contrary to the Dinnerbone Principle or change gameplay design in ways that run counter to the core's theme/style.

As such, SGM is recommended for administrators seeking to use Stargates for use cases not accounted for in the core plugin, or as a means through which to introduce novel gameplay mechanics to users.

Installation

To install SGM, simply download the latest release from here and drag/drop it into your instance's plugins folder as you would any other plugin. SGI will take care of importing all existing stargate data, and will create a StargateMechanics subfolder containing a config.yml.

config.yml

By default, the SGM configuration file should look like https://raw.githubusercontent.com/stargate-rewritten/Stargate-Mechanics/main/src/main/resources/config.yml; included within it are comments explaining all fields.

We feel that most of the fields in this file are self evident, but nonetheless wish to draw your attention to a few specific toggles.

gates.generation.agressiveGateGeneration

When generating new portal structures is required (as is often the case for the J and G flags), Stargate Mechanics will try to use spots filled solely by air or water (i.e. will try not to break blocks). Sometimes, this can result in portals placed relatively far from their intended destination.

This feature will allow Stargates to break blocks when generating; they will still try to be considerate of existing structures, but will break blocks if not doing so would mean the portal would end up too far from the intended destination.

gates.generation.gateformatSelectionMethod

It should be noted that, for this method, "ruined portals" refers to these vanilla structures.
Instead of building a new portal, generative portals will opt to repair and use one of these structures as a Stargate when this config setting is set to RUINED.

gates.generation.defaultJGateDestination

When a new J (jump) gate is generated within the world, this setting will be used to determine it's destination.

• When this is set to FixedReturn, this means that generated portals will be fixed portals returning to the origin portal (the portal with the J flag that caused the destination gate to be generated).
• When this is set to OriginNetwork, this means that generated portals will be networked (non-fixed) portals pointed to whatever network the origin portal was a part of. In practice, this usually means that it allows users to scroll to all jump gates on generated on the same network (notwithstanding potentail use of the D flag, or the jumpGateGenerationBehaviour config option).
• When this is set to SpecifiedNetwork, this means that generated portals will be fixed portals returning to the portal specified under the specifiedJGateDestination configuration option.
• When this is set to NONE, this means that generated portals will be dummy portals consisting solely of a gatefile frame and not initialised to go anywhere.

Features

New Gate Types

Stargate Mechanics implements the following new gate flags:

$$ D, E,G,L,V $$

Respectively, these are Destruct, Electric, Generative, Library, and inVisible gates.

The following gates from the legacy ecosystem were also moved here due to infrequent usage:

$$ H, N, Q, S $$

Respectively, these are Hidden, NoNetwork, Quiet, and forceShown gates.

Documentation for all gate files may be found here.

New Vanilla+ Mechanics

Total Interface Replacement (TIR) Component

Caution

The entirety of this component HAS NOT YET BEEN IMPLEMENTED

Warning

This component is not enabled by default.

This OPTIONAL component (not enabled by default) completely eliminates all sign-programming mechanics from StarGate, instead replacing them with Vanilla++ mechanics.

• Candidate portal frames have an automatically generated name, which may be changed through the use of a nametag item.
• For Fixed portals, destination selection occurs by right-clicking the origin portal with a compass loaded with (right-clicked on) the destination portal.
• For Networked portals, network selection occurs by right-clicking the origin portal with either:
  • A compass clicked on a player (for a personal network), or an existing portal of the target network (for custom/default networks); OR
  • Subject to an additional permission, a renamed recovery compass (which will create the network if needed).
  • For Flags, specific items are associated with each portal type. Right-clicking on the origin portal with specific items will add/remove the applicable flag from the portal.
    • Alternatively, specific control blocks (for example a chiselled bookshelf) automatically force a certain flag's presence (in this case, the L flag)

Additional Interface Mechanics (AIM) Component

Caution

The entirety of this component HAS NOT YET BEEN IMPLEMENTED

• Right-clicking an Echo Shard on a portal binds the echo shard to that portal; right-clicking an Echo Shard will then teleport the player to the portal was bound to, consuming the shard in the process.
• Right-clicking a Bundle or Shulker Box full of certain items (dyes, glowstone, glowsquid ink, etc.) will customise the colour scheme of a sign, consuming the items in the process.