User:Mint Shock/System Standard

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

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 an 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 a 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/ShortDescription	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/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.

Avatar Standard

The System standard is designed primarely 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 identificaton 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 functionaliy for that System.

See also

• Avatar standard
• Moduprint/API