Tag preconditions

[Ozzypig]

Tags are often used to indicate component-like behaviors on instances. However, such behaviors may only be applicable to certain instances, and those instances might require additional data, like certain properties or other requirements. To help facilitate the communication of such requirements, tags should be able to define preconditions. Furthermore, the Tag Editor should be able to assist with satisfying these preconditions, or save the user from ignoring them altogether.

User Stories

• As a programmer, when I create a new tag that carries various preconditions to it, I want the Tag Editor to inform/warn/restrict users applying tags whose preconditions are not satisfied.
• As a builder, if I want to apply a tag that has preconditions, the Tag Editor should satisfy the preconditions for me where possible.
• As a programmer, when I add preconditions to a tag, I want the Tag Editor to check the game for any newly-unmet preconditions. I also want options for addressing such unmet preconditions, such as removing no longer valid tags.
• As a builder, I want to be able to ignore preconditions when I know it is safe to do so.
• As a programmer, I want satisfaction of tag preconditions to be optional, required or recommended so that the Tag Editor's behavior can adhere to the safety of my code.
  • In other words: If the code breaks when a tag is applied to an instance of the wrong class, I want the Tag Editor to enforce this precondition strictly. However, if my code can safely ignore this precondition, I want to configure the Tag Editor to simply warn the user instead.

Proposed Tag Preconditions

• The instance must (or must not) be of one or more classes.
• The instance must contain one or more instances of a specific class, or tagged instances.
• The instance must be a descendant of an object of a specific class, or tagged instance.
• A property of the instance must satisfy some condition.
  • A Model's PrimaryPart must be non-nil.
• An attribute of the instance must satisfy some condition, such as:
  • The attribute must be of a specific type.
  • The attribute value must satisfy some precondition:
    • Number attributes must be whole, or fall within a range, or represent a timestamp in the future
    • String attributes must match that of an EnumItem, or adhere to a certain length (non-empty or shorter than a certain length)

Example Scenario

• I create a tag Deadly, which is meant to be applied to only BaseParts with the Damage attribute, a positive number.
• A builder on my team wants to add some new deadly parts to a map they are creating:
  • If the builder mistakenly attempts to tag a Model, the plugin informs them the class is incorrect and only BasePart may be tagged.
  • Upon applying the deadly tag, the plugin realizes the new part is missing the Damage attribute and automatically adds it to the part. The plugin informs the user that it added the attribute.
    • The builder later decides to make the part no longer deadly, so they remove the tag. The plugin prompts the user if they would like to remove the relevant tag attribute preconditions, or keep them.

As a hierarchy checking tools

Tag preconditions can go beyond the scope of compatibility with code. By adding preconditions to tags, the Tag Editor can become a powerful hierarchy-checking tool. Here's some examples or use cases to that end:

• RequiresPrimaryPart - Apply to models whose PrimaryParts must be set (a common mistake)
• LowZIndex/HighZIndex - Apply to GuiObjects to ensure that important/interactive UI elements render on top and prevent layering mistakes
• PointParticleEffect - Apply to ParticleEffects to indicate it is designed to emit from within an Attachment, instead of the volume of a BasePart)
• MustBeJumpable - Apply to BaseParts to indicate they should be short enough for the player to jump on them.
• MustBeOpaque - Apply to BasePart, Decal or Texture objects which cause rendering issues if made non-opaque/transparent
• StreamedAsset - Apply to objects which must should be within ServerStorage at edit time, as they may be streamed manually during run time.
• DoNotLoop - Apply to Sounds which are not stopped after being played, and therefore should not be looped.
• Certain properties of Workspace control the behavior of Roblox features that may be incompatible or problematic with a game. By applying a preconditioned tag to the Workspace, the Tag Editor can warn the user that modifying the feature may cause issues.
• Some games require that humanoid names not be visible. Creating preconditioned tags for instances like StarterPlayer or Humanoids can help deter mistakes which could negatively affect gameplay.