Plugin System/API Wishlist

From Kokua Wiki
Jump to: navigation, search



The purpose of this page is to create a catalogue of specific useful actions that should be possible through the API. This is not a comprehensive list of features the API will support, merely examples to provide some focus and direction.

Please add or flesh out sections to reflect what you would like to be possible via plugin.

Feature Categories


(Note: "Agent" is the term for a user in the system, or something to that effect. This should not to be confused with "Avatar", which is the visual representation of an agent. But sometimes the line is a bit fuzzy, so go with your best guess.)

It would be useful for plugins to be able to:

  • Get profile details of an agent, by name or UUID.
  • Look up agent UUID by name.
  • Pay money to another agent.
  • Send an inventory item to another agent.
  • Check whether an agent is online (possibly limited to friends list?).


It would be useful for plugins to be able to:

  • Get a list of nearby avatars (within a certain area / radius).
  • Search for nearby avatars by name.
  • Get the position of an avatar (if nearby).
  • Get the position and rotation of the user's avatar. --- Use case: world travels logger
  • Move and rotate the user's avatar. --- Use case: world travels logger, replay / machinima
  • Teleport the user's avatar. --- Use case: world travels logger, replay / scheduled meetings
  • Detect when the user's avatar moves or rotates.
  • Detect when nearby avatars move or rotate.
  • Detect when other avatars hit, shoot, or bump into the user's avatar.
  • Rebake the user avatar's textures.
  • Get a list of attachments an avatar is wearing.
  • Get a list of animations playing for the user's avatar.
  • Play / stop animations for the user's avatar.


It would be useful for plugins to be able to:

  • Create new objects.
  • Delete objects.
  • Retrieve a list of all objects within a certain area.
  • Scan the area for objects by name.
  • Get and set object attributes:
    • Name and description
    • Owner and creator (read-only)
    • Group
    • Permissions
    • Position, rotation, and size
    • Shape parameters (twist, taper, etc.)
    • Features (flexi / light)
    • Texture settings on each face
    • Contents (inventory)
  • Building composite objects --- Use case: procedural construction, and playback of building recipes


It would be useful for plugins to be able to:

  • Create, move, and delete inventory items.
  • Copy inventory items (permissions allowing).
  • Rename inventory items (permissions allowing?).
  • Create, move, and delete folders.
  • Get a list of inventory items matching a search string.
  • Set the search string for an inventory window.
  • Set the filter options for an inventory window.

Graphical User Interface

It would be useful for plugins to be able to:

  • Show and hide floaters (windows).
  • Create a new floater.
  • Add and remove widgets (buttons, sliders, text fields, etc.) from floaters.
  • Change widget properties (shape, location, enabled/disabled, text, etc.).
  • Register to receive notification when a widget is clicked/used.
  • Add, edit, and remove items from menus (global and per-floater menus).
  • Perform reskinning of existing GUI elements.
  • Remap any/all keyboard keys and mousebuttons to existing function handlers, or to plugin handlers.

(See also UI Widgets API,)


It would be useful for plugins to be able to:

  • Render a collection of particles for personal use. (Using the existing particle system rendering method) -- Use case: Particle weather for areas where an existing particle weather system is nowhere to be found. (Ex: When one wishes to make a sunny tropical area filled with rain with WindLight and particle raindrops.)
  • Change objects' appearance locally. -- Use case: Tinting all objects owned by "John Smith" red.

General Requirements

Only a subset of functional requirements and communication types and design styles can be foreseen and addressed using built-in plugin function handlers. To cater for everything else and ensure that plugin development is not held back by the rate of handler development within the viewer, some additional general-purpose requirements are considered important (see this forum thread):

  • Generic resources, generic resource update, and generic event handling should be supported.
  • General Plugin-to-Plugin communications should be provided for other unspecified applications.