You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An add-on in Hubs Client is small programs to add one or set of features in Hubs Client. An add-on consists of Components, Systems, Inflators, Prefabs, Network schemas.
One of the good things of systems is the order of systems execution is controllable and managable. For example, we can ensure that a system that requires updated world matrices can run after the world matrices are updated (by the Hubs Client Core). The second unsigned integer argument is to specify the order, the systems with small numbers run earlier. (Systems with the same order number may be out of order, or first-registered first-run in them.)
Potential advanced APIs
We may add am API to allow to know the order number of a registered system for, for example, to ensure a system runs before or after another certain system, like
App.getSystemOrder=(system: System)=>number;
Example: Ensure fooSystem runs before the built-in textSystem
An add-on in Hubs Client is small programs to add one or set of features in Hubs Client. An add-on consists of Components, Systems, Inflators, Prefabs, Network schemas.
Refer to https://hubs.mozilla.com/docs/dev-client-gameplay.html and https://hubs.mozilla.com/docs/dev-client-networking.html for the details.
Ideally Hubs core (built-in) and user custom features should be implemented as add-ons.
Unfortunately right now we don't have clear APIs to register add-ons and we require hand-edit some Hubs core files.
This issue is to propose new APIs to register add-ons.
Purpose of the new APIs
Allow custom client developers to add their own custom add-ons without editing the Hubs Client core files.
Process of add-on creation
If you want to add a new add-on, you need to do
If you want networked (synced with remote clients) components, you need additional two tasks
Then, the APIs we need are to register Systems, Inflators, Prefabs, and Network schemas.
APIs proposal
Add register APIs to App.
Register System
Example:
One of the good things of systems is the order of systems execution is controllable and managable. For example, we can ensure that a system that requires updated world matrices can run after the world matrices are updated (by the Hubs Client Core). The second unsigned integer argument is to specify the order, the systems with small numbers run earlier. (Systems with the same order number may be out of order, or first-registered first-run in them.)
Potential advanced APIs
We may add am API to allow to know the order number of a registered system for, for example, to ensure a system runs before or after another certain system, like
Example: Ensure fooSystem runs before the built-in textSystem
And we may add an API to deregister system for, for example, replacing a built-in system with a custom system.
Example: Replace a built-in foo system with a custom bar system
Register Inflator
Example:
jsx
andgltf
in the first argument object are keys for JSX and glTF inflators map respectively.Register Prefab
Example:
Register Network schema
Example:
Custom add-on Example
Expected Hubs Client Core (built-in add-ons) setup implementation
The text was updated successfully, but these errors were encountered: