User:SignpostMarv Martin/MMOX/SL actions

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

• within a parcel
• within a region
• between regions
• between grids via OGP

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:

• All kinds of textures.
• Sounds
• Animations

UI Only

Some assets can only be created via the UI:

• MMOX/SL assets#Primitives|Primitives]] and objects (rezing objects)
• Notecards
• Scripts
• Gestures
• Body Parts

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.