ORIX Concepts

There are two classes of ORIX compatible items: ORIX Cores, and ORIX Devices.

ORIX Cores
An ORIX Core is the main control system for a robot avatar. It provides information about the robot's state, and accepts commands intended for the robot. It probably interacts with the avatar (called a "unit" or "robot") though chat, dialogs, one or more HUDs, RLV, and so on - ORIX is not concerned with that. ORIX is concerned with how other devices communicate with a Core so as to control or gain information about the unit it controls.

ORIX Devices
An ORIX Device is something that will use information about the robot's state as provided by an ORIX Core, and/or send commands to an ORIX Core. Some ORIX Devices will be owned by and attached to the same avatar as the Core - for example, control panels, batteries, and indicator lights. Others may be owned by other avatars, such as remote controls, robot detectors, interference generators, and so on.

ORIX Commands
The first part of the ORIX specification is a list of ORIX Commands. A Device can send one or more commands to a Core, asking the Core to perform some action. That action can be to respond with some information about its state, to impose some restraint on the unit, or anything else. There is a small number of commands that every Core must support a few things in order to call itself an ORIX Core. However, most will go well beyond this and offer other features in addition. Some of these features will take advantage of optional ORIX messages. Others may use unique messages not specified by ORIX in order to take advantage of the unique features of a particular Core or Device.

All ORIX Cores must listen for ORIX Core messages on channel -15180924. (Optionally, it may also listen for messages on channel 9360. If so, messages received on either channel should be treated identically.)

ORIX Messages
The second part of the ORIX specification is a list of ORIX Messages. Messages are how a Core provides information to a Device. ORIX Messages are generally sent on channel -15180925 (though a Core and Device may agree to use a different channel), usually using llRegionSayTo (for replies to a single Device's command) or llSay (to make information available to any nearby Device). ORIX devices may listen on this channel generally, to receive Announcement messages from any nearby ORIX Core (for example, a robot detector); they may listen to a specific Core (for example, an access panel listens only to the Core of the robot it is installed in); or they may listen only when sending a query so as to receive the Response.

In general, a Core should only send messages when they have been requested by a Device, and only to the Device(s) that have requested them. However, once a Device has requested information from a Core, the Core may provide more information to that Device than it requested.

ORIX Device Control
Some ORIX Devices may allow themselves to be controlled by other Devices. For example, a Workbench might be able to adjust or reconfigure an Access Panel. Generally speaking, all such access is controlled by the Core.

A Device that wants to access another  Device connected to a Core sends to find out what devices are connected to the Core, then  to request a connection to the desired Device using specified channels. If the Core agrees to provide the connection (it does not have to), it sends to the Device, informing it that the other Device wants to connect to it. If the Device agrees to provide the connection (again, it does not have to), it begins listening to the Device and sends it  a message. Further communication then occurs using the ORIX Device Control protocol.

Some ORIX Devices may also provide other forms of access.

ORIX Power Protocol
The ORIX Power Protocol is a very simple protocol for allowing Power Sources and Power Supplies to communicate, allowing a Power Supply to be recharged by a Power Source.

Trust
Naturally, with an open protocol, it is possible for people to take advantage by creating malicious devices. To combat this, ORIX Cores may refuse connections from Devices created by unknown creators. Unfortunately, LSL provides no easy way to do this directly - it can verify that a Device was created by a trusted person, but it cannot verify that the script running inside the Device was created by a trusted person - which is what really matters.

ORIX device creators may make a single no-mod trust script available to Core owners. A Core owner who trusts a device creator simply places that trust script into their Core. The trust script does one thing: it accepts a string, and returns a judgment as to whether that string was provided by the creator of the script. ORIX Cores may require that any or  command include a trust parameter containing a string that one of its trust scripts will recognize as valid, and refuse to accept commands from any Device that does not provide such a recognized trust key. See trust script for more information about how this works.