Xanadu 3500/E
| Name | Xanadu 3500/E |
|---|---|
| MSRP | L$ 1200 |
| XVS server | xvendor:0 (no longer available) |
| Permissions | copy, modify |
| Land impact | 3 |
| Attachment point | — |
| Function | Distribution server for Companion Xanadu (XPS) packages |
| SKU | 98-1029-C (reassigned to AXSS Xanadu 8600/AX 040) |
| Requirements | none |
| First release | 0.1.2 (2015?) |
| Latest release | 1.1.5 (2017-04-02) |
| Related products | XPS Xanadu 3500/E (predecessor) |
Nanite Systems Corporation
————————————————————————
xanadu 3500/e package server
The purpose of this Xanadu package server is to allow land owners and third-party developers to distribute software for Companion and ATOS/CX. This guide has four sections: 1) server configuration, 2) using drop-add mode, 3) creating packages, and 4) troubleshooting. Read them all.
1) server configuration
————————————————————————
The server gets its name and description directly from its object properties. Names must be lower case, start with an "x" and end with ":" followed by an integer, e.g. "xdata:0". Use different final numbers to indicate servers that have the same general purpose but offer different selections.
The owner of the server may configure it at any time by clicking on it. This allows for toggling group privacy mode ('open'/'restrict') and add-drop mode ('allow add'/'disallow add').
When group mode is enabled, access to the server is restricted to members with an active group matching the server's group, which must be set when toggling group mode. The server will not appear in server lists seen by other units. (Units will continue to see the server if they switch groups, but not connect to it.)
Add-drop mode allows the public to add new packages to the server. If group mode is enabled, this is also restricted. See below.
2) add-drop mode
————————————————————————
When add-drop mode is enabled, users may initiate package installation with a five-step process:
i. Click the server. You must be standing within 10 m of it.
ii. Ctrl-drag-and-drop (or command-drag-and-drop) the package's info notecard (described in section 3) from your inventory into the server. It must be written by you. You may drag in multiple notecards.
iii. Click the server a second time to indicate you have finished adding info cards.
iv. Ctrl-drag-and-drop the package itself, or packages themselves.
v. Click the server to conclude the process.
Add-drop mode is not necessary for the server owner to add packages, and we do not recommend using it yourself.
Old versions of packages will be removed. Info notecards and packages must be paired.
3) creating packages
————————————————————————
A package consists of four key parts:
i. The package object itself. This should have copy permissions, or copy/transfer permissions if you are using add-drop. Put into it the actual programs and data from your package, as well as the items below:
ii. An info notecard, akin to a read me file. This must be uploaded to the server and included inside the package itself. It should be named <name>_<version>_info. This should have copy-transfer permissions.
iii. The _xanadu-package script. This must go inside the package object; it is responsible for installing files. It is included with the server.
iv. A deletion manifest, called ~<name>_<version>. This lists the files inside the package, not including itself, and is used to remove the package if the user no longer desires it.
A sample, hello-world_1.0, is included in the Companion SDK, which is available from the main Nanite Systems store in Eisa. We recommend creating your own package object prim, however, rather than reusing that one. This makes it easier to identify the creator of a package.
Package names should be all lower case. Use hyphens to separate multiple words, e.g. "hello-world" rather than "hello_world".
Versions should be a series of positive integers separated by periods. "m", "a", "b", and "rc" are interpreted as ".-4." through ".-1.", respectively, and any ".0" parts immediately before them are removed. These letter codes stand for "milestone", "alpha", "beta", and "release candidate", and represent the successive steps in a typical development cycle. Do not use any other letters in your version numbers; they will be ignored. For example, "8.4.0a1" is equivalent to "8.4a1". It comes before "8.4a2" but after "8.4m3".
4) troubleshooting
————————————————————————
_xanadu-server script is doing weird things to prim faces on server: Use the copy of "_xanadu-server" that came in the package, not the copy from the 3500/e linkset.
Server does not appear in server list on controllers, or has the wrong name: The controller automatically polls for servers periodically, or on sim change. To force an update, type '@xanadu search'. If this fails, reset the package manager with '@reset xanadu-client'.
Add-drop claims files are missing: The files may have ended up in the wrong prim of the server, especially if you have edit permission. Delete and retry. (If you have edit permission, add-drop may not be necessary.)
Units cannot get packages from the server: Check package permissions, and ensure that the units can rez objects where they're standing.
Other problems: contact support@nanite-systems.com.