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.
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.
| Name | Type | * | Purpose |
|---|---|---|---|
ID
|
String
|
Required | Unique system identifier -> Mint_Shock.ExampleSystemUse a DynamicField<String> with the target being the tag on the systems root
|
Version
|
uint3
|
Optional | Semantic Version (major.minor.patch) |
Root
|
Slot
|
Required | Root slot of the system. |
Name
|
String
|
Optional | Human-Readable name of the module. |
ShortDescription
|
String
|
Optional | Human-Readable short description of the System |
ManifestOwner
|
String
|
Optional | Creator / Maintiner of the System |
Requirements
|
Slot
|
Optional | List of requirements of the system, such as dependencies or the manager version |
HasSubsystem
|
bool
|
Optional | If this system has subsystems |
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 separate underlying systems for ease or maintaining and organization. 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 a slot with a identifiable name like "Systems" as a direct child of your Object / Avatar with the "Systems" tag. Note that the name can be different to allow for Slot organization (example: <color hero.cyan>Systems</color>) but the Tag has to be exactly "Systems".
Other Standards may define a specific Standardname/Systems Dynamic variable of type Slot to point to the Systems slot. (See for example Avatar standard)
This Slot will contain all Systems and Subsystems as children.
The simplest possible System consists of a single slot with all required [*] variables present.
ToDo: Requirements Dependencies and Methods?
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