Home

OpenToySystem is a fork of OpenCollar, which itself is a set of collar scripts for SecondLife. This fork focuses on alterations to make the codebase usable in other devices with out modification, and will have it's own Ruby/Rails based settings and location server. *** First release is not posted yet, will update when it is. ***

Table of Contents Goals Roadmap First Release Later Releases

Goals

As stated above, we wish this fork to work for all attachment type toys with clean communications between attachments and the database.

Roadmap

First Release

• Remove static references to 'Collar', and make that configurable.
  • Add a ~device config notecard that has information about the device. (done)
  • Allow for static device information in the form of _ prefixed settings not sent to the DB. (done)
    • _type, which specifies if the device is a 'collar', 'cuff-set', 'muzzle', 'blindfold', etc.
    • _model, which should be a unique identifier for specific models.
    • _manufacturer, store/company that created the toy. (informational only)
    • _creator, who designed the toy. (informational only)
    • _support, who supports the toy. Should be a SL username or url.
    • _database_base_url, just what it says
    • _database_name, human readable (informational only)
    • _static_content_url, where to get color lists and the like.
    • _online, replaces defaultsetting's online, decides if the device starts up with the database enabled.
• Read the core package card to get the core version. This will be published as _version. (done)
• Make references to the wearer use their displayname.
• Use llRegionSayTo for IMs to remove script lag.
• First pass at using the new memory limit setters to reduce memory consumption. (or apparent consumption)
• Adapt the remote hud and such to work with more than one toy.
• Alter the database to handle three classes of config variables. This will stop this overwhelming of LSL's limited http client on GET _all requests, and allow each toy not to collide with the others. (done)
  • Global settings. These should be limited to just things all toys need to know. Primarily ownership and access related.
  • Toy Type settings. These are things specific to the type of toy, such as a collar.
  • Model settings. These are things specific to a model of the toy. Such as appearance settings.
• LockGuard single script support. It is possible with current LSL to write a single script that manages lockguard through the entire toy. (done)
• LockMeister with minimal scripts. Unfortunately you can't do lockmeister with a single script for most toys. Possible design: a central script with the remote scripts doing nothing more than llSay(), and set to use as little memory as possible. (done)
• Establish a Config channel to pass back and forth Global configuration changes with llRegionSayTo the avatar.
• Establish an inter-toy command language. Probably on the same channel.
• Figure out a good way to figure out what chat commands are going to what toy. Current solution: Add the first letter of the toy type to the prefix with the exception of the collar.
• Rewrite the package manager from scratch to live in the collar.
  • Allow it to grab packages from objects owned by others, with note that this is being done. (done)
  • Keep package versions. (done)
  • Package card format:
    • version: 1.2.3.A4 - MUST be first line.
    • update_url: - not used, future for notification. should return the newest version for the package.
    • scripts: script, script, script, ... script names should be a list seperated by " - ", the first should be the package name, the second the script name. Optional others may include version numbers and other data.
    • items: item, item, item... Non-script items to be delivered.
    • maintainer: not currently used. Should be displayed in the package page.
    • allowed_uuids: not used. If present SHOULD create a warning if you are trying to update a package from an updater not owned by one of the UUIDs listed.
    • description: A SHORT description of the package. Remember, dialog space is limited. A sentence or two.
    • default: required|recommended|optional - Currently only required is parsed, and only in packages already loaded. Prevents removal or turning off.
    • devices: device|all, device, device, ... List devices valid to receive this package. Typically this would be "all" except for packages specific to a toy type. Such as blindfold controls that would not make sense in a collar or cuff.
• Make code not reliant on OpenCollar's static web server. Such as the color module, etc.
• Option to hand out the Master's Remote.
• Menu redistribution: (done in core, each package will need to be touched)
  • Top Level: Stuff that does stuff, and sub menues. Leash, take key, lock, etc.
  • Configure: Configuration tasks. Owners. Setting up leash stuff. Etc.
  • Help/Utility: Misc stuff that does not fit above. Resets, update checking, etc. Basically actions that are not interesting enough to go into the top level.
  • Submissive: This menu is presented when the wearer is locked out of the toy. This is to allow packages to offer some limited functionality such as hiding the toy or accessing a 'lock picking' type module.
  • Public: When public access is unset, and the user is not recognized, this menu is presented. This allows packages to offer some limited functionality, such as someone who wishes their *take key* to be publicly accessible.

Later Releases

• Rethink how owners/blacklist is stored to allow for unlimited lists
• Rearrange menus between functional at the top level, and a Config menu.
• Leash point negotiation to make it easy to pick from the various leash points a sub has.
• New Sub-AO based on latest ZAHO-II MB whatever.
• Run levels for system startup. So that the scripts enter a "listen for config only" mode before actually starting.
• ~packagename_version, containing a version string. So that the updater knows what it's dealing with.
• Make the documentation/support/issues/etc links go somewhere useful.
• Event system, have a standard way of publishing events. This will make plugins able to do a lot more.
• Some sort of lockpicking plugin.