User:Mint Shock/System Standard

This is an early draft of this proposal. Please don't use anything in here yet. Everything is still subject to change.

The finalization of the Standard is currently blocked by issue #3148

This causes Subsystems to take on the Values from their parent Systems which breaks the Subsystem.

If you want to see this Proposal to move forward feel free to leave a upvote on Issue #3148 on Github

Standardization is required for collaboration and shared assets. This is a proposal made by Mint_Shock which standardizes a list of Dynamic Variables on the "System" namespace to make systems interoperable and portable and enables users to create systems which can easily be installed onto other objects like tools, avatars, and much more. All without using any developer tools.

Systems are anything that goes on top of a base object. This includes ProtoFlux logic and other assets such as slots, meshes, textures, and much more.

This proposal builds on top of Moduprint/API as an established and proven to work standard.

All variables must be defined including their namespace to avoid them accidentally binding to the wrong namespace: System/VariableName. The namespace must not rely on non-direct binding of variables.

"Systems" Slot

Contains all Systems as direct children. It has the Component:DynamicVariableSpace of "Systems" on itself and the following Dynamic variables:

This Slot will contain all Systems and Subsystems as children.

Name	Type	*	Purpose
Systems/Root	Slot	Required	Root slot of the all Systems.

The "Systems" slot has the "Systems" tag and should have a identifiable name like Systems or <color hero.cyan>Systems</color> .

Structure of a System

A System is a Slot with the direct-binding Dynamic Variable Space "System" defined on itself.

Systems are ALWAYS installed under a "Systems" slot that is a direct child of the Objects / Avatars root.

Dynamic Variables

Name	Type	*	Purpose
System/ID	String	Required	Unique system identifier -> Mint_Shock.ExampleSystemUse a DynamicField<String> with the target being the tag on the systems root.
System/Version	uint3	Optional	Semantic Version (major.minor.patch)
System/Root	Slot	Required	Root slot of the system.
System/Name	String	Required	Human-Readable name of the module. Use a DynamicField<String> with the target being the name on the systems root.
System/Description	String	Optional	Human-Readable short description of the System
System/Creator	String	Optional	Creator / Maintiner of the System
System/Requirements	Slot	Optional	List of requirements of the system, such as dependencies or the manager version
System/HasSubsystem	bool	Optional	If this system has subsystems
System/Core	bool	Optional	Indicates if a System is essential for the functionality of an object. These systems should only be uninstalled if you know what you are doing.
System/Icon	Uri	Optional	Icon of the system. (resdb link to the icon texture)

The system ID is of the format Namespace.System where Namespace is anything uniquely identifying the creator such as the user or group name and System is the identifier of the system. Only one system with the same ID can be installed on the same "Systems"-Slot at any point in time. The ID must only contain letters which are valid for a Dynamic Variable.

Subsystems

Are primarily used to Separate out underlying systems for ease or maintaining and organization. Subsystems are Always direct children of a System. The Systems -> Structure can be seen as a kind of "Folder" Structure. A System can have many Subsystems, those Subsystems can have more Sub-SubSystems and so on. Subsystems aren't special in any way compared to other Systems. A Subsystem has the same Requirements and can have the same Dynamic variables as Systems.

Setup

Create "Systems" slot as described above.

Other Standards may define a specific Namespace/Systems Dynamic variable of type Slot to point to the Systems slot. (See for example Avatar standard)

The simplest possible System consists of a single slot with all required [*] variables present.

Usage

Systems can be installed either through an inspector or a Systems-Manager.

Systems Managers

• Colin The Cat Has a working Tool that exclusively works for Avatar standard compliant avatars.
• Mint Shock is currently developing a generalized Manager that can inspect any Avatar, Object, or World (wip).
  • The Manager is currently in Alpha Testing. Displaying Systems, Transfer-Actions (Eject, Copy, Install) and the Systems Orbs are already functional.
  • Most of it has not been tested thoroughly and there WILL be bugs and issues.
  • There WILL also be Breaking Changes to the Manager, its Subsystems, and its supporting systems. Please, for now, use the Manger "as is" anything interacting with it will likely break in the future until it gets to a stable state.
  • You can Test the Manager yourself by spawning it from the public folder:
    • resrec:///U-1Zj0VcAjHIe/R-98420480D5DD28EBC2306A59639DED9C0D081260C5024C7E158A65E7861951B6
  • To report Issues feel free to make a GitHub Issue on the Systems manager repository
    • https://github.com/Mint-Shock/Systems-Manager
  • For discussion see Systems manager Discord Thread
    • https://discord.com/channels/1040316820650991766/1452682752775422083

Avatar Standard

The System standard is designed primarily as a extension of the Avatar standard. Both proposals are designed to work together seamlessly. Systems can access variables from the Avatar standard by reading variables from the Avatar namespace.

Example: a flight thruster system might need to know the users hand position. Normally you would have to manually find the users hand slots using ProtoFlux. Avatar standard simplifies this by providing Dynamic variable Avatar/BodyNode.HandL and Avatar/BodyNode.HandR of type Slot

Acronym / Shorthand (Optional)

For ease of identification use the SYS-S Prefix to mark Slots containing System Standard related functionality.

"SYS-S" stands for "SYStem Standard".

Examples:

1. A direct child Slot of the system Root with the name of "SYS-S Variables" containing all the System Standard dynamic variables for that System.

Slot name	Purpose
SYS-S Variables	Contains all the System Standard dynamic variables for that System.
SYS-S Functionality	Contains all the functionality for that System.

See also

• Avatar standard
• Moduprint/API