User:SignpostMarv Martin/MMOX/SL actions

From Second Life Wiki

Second Life Wiki > SignpostMarv Martin/MMOX/SL actions
Jump to: navigation, search

Contents

Residents

Movement

Residents, via their avatars, can move via locomotion or teleportation. objects and scripts can also affect the location of a Resident's avatar.

Locomotion

  • walk/run
  • fly

Residents can walk/run via their avatars, although access can be restricted by:

  • Parcel access control
  • Region access control
  • Solid Objects obstructing direct access
    • obstructions can be bypassed by achieving sufficient velocity to force their avatar through the obstruction
      • Usually requires flight to be enabled on the parcel
      • Usually requires script-assisted flight
    • obstructions can be bypassed by causing the avatar to sit on an object, then modifying the position properties of said object, alighting from the object once the obstruction has been passed.

Teleportation

Residents can move from place to place, unassisted by assets, without appearing to occupy the space between each place in the process.

  • Teleportation can be triggered manually (action evoked by the Resident via the UI)
  • Teleportation can be triggered by scripts via llMapDestination
  • Teleportation can be triggered by system override (God Summon)

Teleportation can be deliberately prevented in a few ways:

  • destination Parcel access control
  • destination Region access control
  • system override of inter-region teleportation (Resident does not have ability/permission to leave region)

Although not technically teleportation, Residents can move between parcels and regions by terminating their session (logging out), then causing the user agent (SL Viewer) to use a different location (Home, Previous Location, Secondlife:// URL scheme, and manual input of a region & co-ordinates). Since the session is terminated to achieve this method, it is not considered a form of movement, but is still considered an action a Resident can take.


Asset Transfer

Residents can, via the UI, initiate the transfer of all types of assets (so long as they own the asset in question) to some Entities:

  • Other #Residents
  • #Objects (adding an asset to the object's inventory)
  • #Groups
    • via Group Notices
    • L$ have to be given to a Group via an object owned by the group.

Although Residents can "rez" certain assets in the 3D environment (#Regions and thus #Parcels), the Resident still "owns" the asset.

#Events are the only entity that cannot receive assets.

#L$ are transferred to enable commerce.

Asset Modification

Most kinds of assets can be modified by Residents, so long as the system permits them to do so.

The 3D environment of Second Life, avatars and aspects of the UI (HUD attachments) are altered by modifying the properties of assets.

  • Terraforming can be achieved by modifying the Red and Green values of the terrain asset.
  • Buildings are constructed by modifying the properties of primitives to create link sets, altering the scale and appearance to create the end result.
    • Vehicles are created in much the same way, except that a script asset is needed in order to provide the object with locomotive capabilities.
  • L$ cannot be modified, though L$ amounts can be exchanged.

Asset Creation

Residents can, via the UI, create most asset types.

Upload Only

Some assets can only be created by uploading a file from the Resident's computer:

UI Only

Some assets can only be created via the UI:

External Services

  • L$ cannot be "created" by Residents, though they can be purchased via external services from other Residents.
  • The services involved in the generation of the map images can create texture assets.


Communication

In addition to text and voice communication, the availability of #Asset Transfer created an emergent behaviour of using simple #Primitives, complex #Objects, #Textures, #Notecards, or any combination of transferable assets to convey a message. Usually such messages concern an invitation to an event (either a formal #Event or an informal one).

Text Communication

Residents can, via the UI, communicate with:

  • other Residents
    • via Instant Messaging
    • via #Group Chat
    • via conference (equivalent to an informal group chat facility, invoked by selecting multiple Residents in the UI)
  • #Primitives via #Scripts, using the listen event handler.

Prior to the advent of voice communications in Second Life, text-based communications were commonly referred to as "speaking", with interactive objects that react to text chat being referred to as "voice activated"

Voice Communication

Residents can use voice facilities to communicate with other Residents in two ways:

  1. Spatial voice chat
  2. Non-Spatial voice chat

Non-Spatial voice chat functions identically to contemporary VOIP conferencing systems such as Skype.

Spatial voice chat uses server-side processing of the incoming audio streams to give the illusion that the Resident's voice is originating from their avatar.

With the exception of the limited "voice level" triggers found in #Gestures, there is no facility built into the platform to any asset or entity react to a Resident's voice.

Other Methods

The platform does allow for other, non-verbal forms of communication such as:

  • semaphore, via animations
  • sign language, via either animations or Puppeteering
    • The inefficiency of the existing systems to use sign language via avatars would likely make parcel media streams from the Resident's webcam a better tool to sign with.


Real Estate

Although the feature does not exist in the UI, system or vernacular of Second Life, the term "deed" will be used in the scope of this article for purposes of brevity when referring to ownership of a parcel or region

Resident can, via the UI and external services, use either the L$ micro-currency or a real-world currency to attain "ownership" of virtual real estate- #Parcels and #Regions.

  • Parcel deeds can be exchanged between Residents for no cost, though the system requires L$0 amounts to be used.
  • External services such as Linden Lab's land store use USD to attain the deed for an entire region- the region can then be divided up into parcels which can be resold or rented by Residents for L$.
    • This facility is likely not built into the system, it is more likely an API is used to create a new region at specified co-ordinates and set the owner to a given Resident.

Renting

Renting can be described as the emergent behavior presented when the parcel deed owner permits one or more Residents to occupy a Parcel, usually paying a regular L$ amount to retain this permission. Renting is an "emergent behavior" because it is not explicitly supported by the system.

  • Group-owned land can be used to rent parcels, using the ability to eject a Resident from a Group to revoke the permission to occupy the parcel.
  • Region/Estate-owners can use the ability to reclaim a parcel to revoke the permission to occupy the parcel.

Deed-owner Abilities

Regions
  • Access Control (Residents and Groups)
  • Assign other Residents as "Estate Managers"
  • Modifying various properties of the Region such as:
    • Allow/Deny terraforming facilities
    • Allow/Deny flying
    • Enabling the system-supported avatar "health" system (damage)
    • Inhibit the use of llPushObject
    • Allow/Deny deed transfer
    • Allow/Deny parcel sub-division
    • Block parcels within the region from appearing in the search facility
Parcels

Modifying various parcel properties such as :

  • Access Control (Residents only)
  • Configure parcel media streams
  • Altering parcel name & description
Personal tools