Second Life Wiki - User contributions [en]

Linden Lab Official talk:User Groups

2024-05-08T18:44:41Z

Animats Resident: /* Spelling fix needed in link. */ new section

How do you join these groups?

Are there inworld groups for these groups, or are these groups that exist outside the inworld group system?

If there are inworld groups for these groups, what are there exact names?

{{Unsigned|SuezanneC Baskerville|18:49, 20 March 2011}}

:"User Group" is the new (and apparently confusing) name for what previously was known as "Office Hour". User Groups are regularly held inworld come-togethers of Lindens and Residents to discuss certain topics and have (generally) nothing to do with inworld groups. With the renaming came a slightly new concept: Previously, a specific Office Hour was held by a specific Linden. A User Group in contrast is focused on a specific topic, and several Lindens to whom the topic is relevant might attend.
:You don't have to formally "join" a User Group. If you'd like to take part in one (or several), just attend at the announced date and (inworld) place.
:--[[User:Boroondas Gupte|Boroondas Gupte]] 07:52, 21 March 2011 (PDT)

::Suezanne, some of these user groups do have inworld groups assigned with them or use mailing lists. The community tools user group uses a inworld group called "SL Community Tools User Group", founded by Amanda Linden and free to join. The community translation user group will probably use the group "Second Life CT Projects" founded by Lexie Linden as it is required to access Localization Central.
::--[[User:Torben Trautman|Torben Trautman]] 15:41, 21 March 2011 (PDT)

:::I don't know about you but they can call them what they like id still refer to them as Office Hours
:::[[User:SHAMUS Carter|SHAMUS Carter]] 13:35, 1 June 2011 (PDT)

'''Unlisted User Group'''

For some reason this User group has a page but is not listed on the list of user groups. (which is probably why I can never find it)

https://wiki.secondlife.com/wiki/Content_Creation_Improvement_Informal_User_Group
[[User:Darien Caldwell|Darien Caldwell]] 16:20, 20 September 2012 (PDT)

== CalDav URL? ==

Is there still a CalDav for adding these meetings to calendar apps or has that been discontinued? The previous URL I'd been using doesn't work any more. -- '''[[User:Haravikk_Mistral|Haravikk]]''' ([[User_talk:Haravikk_Mistral|talk]]|[[Special:Contributions/Haravikk_Mistral|contribs]]) 07:30, 9 May 2013 (PDT)

== Spelling fix needed in link. ==

[[Governance User Group]], not [[Goverance User Group]]. That's why it's a dead link.

Packet Layout

2024-04-13T19:09:52Z

Animats Resident: Typo

{{OSWikiLearnBox|parent=Protocol}}

==Header (Packet ID)==

<pre width=80>
+-+-+-+-+----+--------+--------+--------+--------+--------+-----...-----+
|Z|R|R|A| | | | Extra |
|E|E|E|C| | Sequence number (4 bytes) | Extra | Header |
|R|L|S|K| | | (byte) | (N bytes) |
+-+-+-+-+----+--------+--------+--------+--------+--------+-----...-----+

</pre>
* Byte 0 Flags
** LL_ZERO_CODE_FLAG 0x80 -- 0's in packet body are [https://en.wikipedia.org/wiki/Run-length_encoding run-length encoded], such that series of 1 to 255 zero bytes are encoded to take 2 bytes.
** LL_RELIABLE_FLAG 0x40 -- This packet was sent reliably (implies please ack this packet)
** LL_RESENT_FLAG 0x20 -- This packet is a resend from the source.
** LL_ACK_FLAG 0x10 -- This packet contains appended acks.
** The 4 least significant bits of Byte 0 are currently unused
* Bytes 1-4: Sequence number as a big-endian unsigned integer
* Byte 5: How many bytes of extra header is available

If byte 5 is non-zero, then there is some extra header information. Clients which are not expecting that header information may skip it by jumping forward 'Extra' bytes into the message payload.

The term "Packet ID" is sometimes used to refer to all 4 bytes and sometimes just the sequence number.

For further discussion of the bits in the header, see [[Messages]] and [[Packet Accounting]]

==Body==
* Bytes (6 + extra) to (6 + extra + (data length))
** Message number. This is a numeric encoding of the message types defined in the message_template.msg file. It may be 1, 2 or 4 bytes in length, depending on the message frequency (High, Medium, Low or Fixed). Multi-byte message numbers (for medium, low and fixed frequencies) are formatted in the packet as big-endian numbers.
*** High frequency messages are assigned (from the template file) numbers 0x01 - 0xFE.
*** Medium frequency messages are assigned (derived from numbers in the template file) numbers 0xFF01 - 0xFFFE.
*** Low frequency messages are assigned (derived from numbers in the template file) numbers 0xFFFF0001 and up.
*** Messages with "Fixed" frequency are really those with fixed message numbers, i.e. the numbers are assigned in the message_template.msg file itself. There are currently 6 of these, 0xFFFFFFFA - 0xFFFFFFFF. Even though all messages have numbers assigned to them in the template file, the Fixed frequency is kept around for legacy reasons.
** Message data. This is different for each message type, and is defined in the message_template.msg file. A message template defines one or more blocks. The block names in the template are for human readers; they are not encoded in the message. If a block is marked Variable, one byte is stored in the message indicating how many times that block has been repeated. For blocks marked single or multiple, no block header bytes are added.

Each packet contains exactly one message. Thus, the length of the message is known before message decoding.

===Extensions for backwards compatibility===
Some features were added in 2023-2024 to allow extensions to the message format while retaining backwards compatibility.

# Messages with excess bytes beyond what the template calls for are accepted and decoded, not rejected as errors. This allows old message recipients to process newly expanded messages.
# Messages with fewer bytes than expected are allowed for a specific special case. If the last block in the message is "Variable", indicating zero or more repeats of the following block, the decoder expects a one-byte count of the number of repeats of the block. If the message body ends just before that byte, the message should be interpreted as a "Variable" block with zero repeats.

An example of such a message is "AvatarAppearance". Compare these versions of the message template:

* Old: [https://github.com/secondlife/viewer/blob/DRTVWR-591-maint-X/scripts/messages/message_template.msg]

* New: [https://github.com/secondlife/viewer/blob/DRTVWR-600-maint-A/scripts/messages/message_template.msg]

Newer versions of the message template entry for AvatarAppearance contain the section
<pre>
{
AttachmentBlock Variable
{ ID LLUUID }
{ AttachmentPoint U8 }
}
</pre>

The first extended parsing rule above allows a reader working from the old template to parse a message generated with the new template, ignoring the new fields. The second rule allows a reader working from the new template to parse a message generated with the old one, treating the new fields as not present.

==Appended Acks==
* Bytes (6 + extra + (data length)) through acks
** Rest of packet is filled with as many acks from previous reliable messages as will fit.
** The last byte of the packet is a count of how many acks are included (if LL_ACK_FLAG is set).

See also:
:[http://lib.openmetaverse.org/wiki/Protocol_%28network%29 libopenmetaverse documentation]
:[[AW_Groupies#Documenting_current_protocols|AW Groupies documentation]]

Packet Layout

2024-04-13T03:09:12Z

Animats Resident: Extensions for backwards compatibility. Documenting discussion at TPV meeting of 2024-04-12. Please check this.

{{OSWikiLearnBox|parent=Protocol}}

==Header (Packet ID)==

<pre width=80>
+-+-+-+-+----+--------+--------+--------+--------+--------+-----...-----+
|Z|R|R|A| | | | Extra |
|E|E|E|C| | Sequence number (4 bytes) | Extra | Header |
|R|L|S|K| | | (byte) | (N bytes) |
+-+-+-+-+----+--------+--------+--------+--------+--------+-----...-----+

</pre>
* Byte 0 Flags
** LL_ZERO_CODE_FLAG 0x80 -- 0's in packet body are [https://en.wikipedia.org/wiki/Run-length_encoding run-length encoded], such that series of 1 to 255 zero bytes are encoded to take 2 bytes.
** LL_RELIABLE_FLAG 0x40 -- This packet was sent reliably (implies please ack this packet)
** LL_RESENT_FLAG 0x20 -- This packet is a resend from the source.
** LL_ACK_FLAG 0x10 -- This packet contains appended acks.
** The 4 least significant bits of Byte 0 are currently unused
* Bytes 1-4: Sequence number as a big-endian unsigned integer
* Byte 5: How many bytes of extra header is available

If byte 5 is non-zero, then there is some extra header information. Clients which are not expecting that header information may skip it by jumping forward 'Extra' bytes into the message payload.

The term "Packet ID" is sometimes used to refer to all 4 bytes and sometimes just the sequence number.

For further discussion of the bits in the header, see [[Messages]] and [[Packet Accounting]]

==Body==
* Bytes (6 + extra) to (6 + extra + (data length))
** Message number. This is a numeric encoding of the message types defined in the message_template.msg file. It may be 1, 2 or 4 bytes in length, depending on the message frequency (High, Medium, Low or Fixed). Multi-byte message numbers (for medium, low and fixed frequencies) are formatted in the packet as big-endian numbers.
*** High frequency messages are assigned (from the template file) numbers 0x01 - 0xFE.
*** Medium frequency messages are assigned (derived from numbers in the template file) numbers 0xFF01 - 0xFFFE.
*** Low frequency messages are assigned (derived from numbers in the template file) numbers 0xFFFF0001 and up.
*** Messages with "Fixed" frequency are really those with fixed message numbers, i.e. the numbers are assigned in the message_template.msg file itself. There are currently 6 of these, 0xFFFFFFFA - 0xFFFFFFFF. Even though all messages have numbers assigned to them in the template file, the Fixed frequency is kept around for legacy reasons.
** Message data. This is different for each message type, and is defined in the message_template.msg file. A message template defines one or more blocks. The block names in the template are for human readers; they are not encoded in the message. If a block is marked Variable, one byte is stored in the message indicating how many times that block has been repeated. For blocks marked single or multiple, no block header bytes are added.

Each packet contains exactly one message. Thus, the length of the message is known before message decoding.

===Extensions for backwards compatibility===
Some features were added in 2023-2024 to allow extensions to the message format while retaining backwards compatibility.

# Messages with excess bytes beyond what the template calls for are accepted and decoded, not rejected as errors. This allows old message recipients to process newly expanded messages.
# Messages with fewer bytes than expected are allowed for a specific special case. If the last block in the message is "Variable", indicating zero or more repeats of the following block, the decoder expects a one-byte count of the number of repeats of the block. If the message body ends just before that byte, the message should interpreted as a "Variable" block with zero repeats.

An example of such a message is "AvatarAppearance". Compare these versions of the message template:

* Old: [https://github.com/secondlife/viewer/blob/DRTVWR-591-maint-X/scripts/messages/message_template.msg]

* New: [https://github.com/secondlife/viewer/blob/DRTVWR-600-maint-A/scripts/messages/message_template.msg]

Newer versions of the message template entry for AvatarAppearance contain the section
<pre>
{
AttachmentBlock Variable
{ ID LLUUID }
{ AttachmentPoint U8 }
}
</pre>

The first extended parsing rule above allows a reader working from the old template to parse a message generated with the new template, ignoring the new fields. The second rule allows a reader working from the new template to parse a message generated with the old one, treating the new fields as not present.

==Appended Acks==
* Bytes (6 + extra + (data length)) through acks
** Rest of packet is filled with as many acks from previous reliable messages as will fit.
** The last byte of the packet is a count of how many acks are included (if LL_ACK_FLAG is set).

See also:
:[http://lib.openmetaverse.org/wiki/Protocol_%28network%29 libopenmetaverse documentation]
:[[AW_Groupies#Documenting_current_protocols|AW Groupies documentation]]

Region crossing

2024-02-11T20:20:01Z

Animats Resident: Fast movement problem

==Introduction==
The Second Life world is divided into square regions 256 meters on a side. Each region is managed by a separate simulator program. Viewers present the illusion of a large, seamless world by communicating with several region simulators simultaneously. Avatars cross between regions via a complex process which requires cooperation between multiple simulators and viewers.

==Overview of a region crossing==
A region crossing is initiated by a simulator when an avatar goes outside the region boundary. The center of the root prim of the linkset must be one meter past the boundary for crossing to trigger. This prevents toggling back and forth for avatars on the edge of the region. For avatars on vehicles, the center point of the root prim of the vehicle triggers the crossing, so that all avatars and the vehicle remain together.

When an avatar or an object crosses a region boundary, its information is sent from one simulator to the next. From the viewpoint of a viewer, it is re-created in the gaining region. When the viewer receives an ObjectUpdate message for the avatar or object in the gaining region, the viewer will re-create the object. ObjectUpdate messages (either full or compressed) are sent for each prim in the linkset.

The viewer then detects that it has a duplicate of an existing object that was in the losing region. Each object in the world has a unique UUID, and the viewer checks for duplicates. Creation of a duplicate causes the viewer to delete the old object. This is almost seamless to the user, although some object flicker can often be seen.

The viewer is informed of an avatar region crossing via the CrossedRegion event, which travels over the event poller channel. This is no longer a UDP message, although it was in earlier versions of the SL system. This message indicates the beginning of the region crossing process. An AgentMovementComplete message from the gaining region indicates completion. It is not guaranteed that those messages arrive in order. This tells the viewer which simulator has control and should receive AgentUpdate messages with mouse and keyboard inputs.

During the movement process, there are some out-of-sync conditions. The avatar object does not cross at the same time that control is handed off. This causes some difficulties if the out of sync condition persists. If it persists for more than a few seconds, the region crossing has failed.

{{OSWikiLearnBox|parent=Protocol}}
=Event sequence diagram for region crossings=
[[File:Regioncross.png|center|750px|alt=Sequence diagram|Region crossing event sequence]]
{{collapse top | Source code for the sequence diagram above.}}
To change the diagram, change this source code, then paste it into this free online chart generator [https://sequencediagram.org/] to generate a new .png image.
Then replace the version of the image above with a new image.
<pre>
title Region crossing

participant "Viewer" as V
participant "Losing Sim" as H
participant "Gaining Sim" as N

activate H
activate N
V-->>H: AgentUpdate
V-->>H: AgentUpdate
rbox left of V: Avatar crosses region boundary
H->N: ServerSide ChitChat
N->H:
V->H: EventQueueGet

H->V: CrossedRegion
rbox left of V: Control of avatar transferred to gaining region
rbox left of V: Sim waits for CompleteAgentMovement
V-->>N: CompleteAgentMovement
N-->>V: AgentMovementComplete
V-->>N: AgentUpdate
rbox left of V: Out of sync until object update from ganing region

N-->>V: ObjectUpdate
rbox left of V: Viewer creates avatar object in gaining region
rbox left of V: Viewer detects duplicate object in losing region and kills it.
V-->>N: AgentUpdate
rbox left of V: Normal avatar operation in gaining region
N-->>V: TerseImprovedObjectUpdate
V-->>N: AgentUpdate
N-->>V: ObjectUpdate
</pre>
{{collapse bottom}}
==Discussion==
This is an event sequence diagram of the essential events that take place as an avatar crosses from one region to another.
It shows the normal case for a simple region crossing.

This is a rather brittle operation. Many things can and do go wrong.

===Double region crossings===
If a second region crossing starts before the first one is completed, results are generally unsatisfactory.
This usually happens at region corners where four regions meet, but can also be caused by very fast movement.
The simulators are not properly interlocked to prevent this.

===Gaining region not yet fully live===
It's possible to cross into a neighbor region which is still in the process of connecting to the viewer. See [[Adding neighbor region sequence]]. This usually works, and will force the neighbor region to become fully live.
===Multiple avatars on a vehicle===
This is not well understood at this time, and tends to be unreliable.

==Notes==
Dashed lines are [[Message|UDP messages]]. Solid lines are events received via [[EventQueueGet]].

This documents the successful "happy path". Error conditions are not yet covered.

This information reflects what has been discovered by third part viewer developers. It is not official and may contain errors.

Region crossing

2024-02-11T20:17:53Z

Animats Resident: Notes on the bad cases

==Introduction==
The Second Life world is divided into square regions 256 meters on a side. Each region is managed by a separate simulator program. Viewers present the illusion of a large, seamless world by communicating with several region simulators simultaneously. Avatars cross between regions via a complex process which requires cooperation between multiple simulators and viewers.

==Overview of a region crossing==
A region crossing is initiated by a simulator when an avatar goes outside the region boundary. The center of the root prim of the linkset must be one meter past the boundary for crossing to trigger. This prevents toggling back and forth for avatars on the edge of the region. For avatars on vehicles, the center point of the root prim of the vehicle triggers the crossing, so that all avatars and the vehicle remain together.

When an avatar or an object crosses a region boundary, its information is sent from one simulator to the next. From the viewpoint of a viewer, it is re-created in the gaining region. When the viewer receives an ObjectUpdate message for the avatar or object in the gaining region, the viewer will re-create the object. ObjectUpdate messages (either full or compressed) are sent for each prim in the linkset.

The viewer then detects that it has a duplicate of an existing object that was in the losing region. Each object in the world has a unique UUID, and the viewer checks for duplicates. Creation of a duplicate causes the viewer to delete the old object. This is almost seamless to the user, although some object flicker can often be seen.

The viewer is informed of an avatar region crossing via the CrossedRegion event, which travels over the event poller channel. This is no longer a UDP message, although it was in earlier versions of the SL system. This message indicates the beginning of the region crossing process. An AgentMovementComplete message from the gaining region indicates completion. It is not guaranteed that those messages arrive in order. This tells the viewer which simulator has control and should receive AgentUpdate messages with mouse and keyboard inputs.

During the movement process, there are some out-of-sync conditions. The avatar object does not cross at the same time that control is handed off. This causes some difficulties if the out of sync condition persists. If it persists for more than a few seconds, the region crossing has failed.

{{OSWikiLearnBox|parent=Protocol}}
=Event sequence diagram for region crossings=
[[File:Regioncross.png|center|750px|alt=Sequence diagram|Region crossing event sequence]]
{{collapse top | Source code for the sequence diagram above.}}
To change the diagram, change this source code, then paste it into this free online chart generator [https://sequencediagram.org/] to generate a new .png image.
Then replace the version of the image above with a new image.
<pre>
title Region crossing

participant "Viewer" as V
participant "Losing Sim" as H
participant "Gaining Sim" as N

activate H
activate N
V-->>H: AgentUpdate
V-->>H: AgentUpdate
rbox left of V: Avatar crosses region boundary
H->N: ServerSide ChitChat
N->H:
V->H: EventQueueGet

H->V: CrossedRegion
rbox left of V: Control of avatar transferred to gaining region
rbox left of V: Sim waits for CompleteAgentMovement
V-->>N: CompleteAgentMovement
N-->>V: AgentMovementComplete
V-->>N: AgentUpdate
rbox left of V: Out of sync until object update from ganing region

N-->>V: ObjectUpdate
rbox left of V: Viewer creates avatar object in gaining region
rbox left of V: Viewer detects duplicate object in losing region and kills it.
V-->>N: AgentUpdate
rbox left of V: Normal avatar operation in gaining region
N-->>V: TerseImprovedObjectUpdate
V-->>N: AgentUpdate
N-->>V: ObjectUpdate
</pre>
{{collapse bottom}}
==Discussion==
This is an event sequence diagram of the essential events that take place as an avatar crosses from one region to another.
It shows the normal case for a simple region crossing.

This is a rather brittle operation. Many things can and do go wrong.

===Double region crossings===
If a second region crossing starts before the first one is completed, results are generally unsatisfactory. The simulators are not properly interlocked to prevent this.
===Gaining region not yet fully live===
It's possible to cross into a neighbor region which is still in the process of connecting to the viewer. See [[Adding neighbor region sequence]]. This usually works, and will force the neighbor region to become fully live.
===Multiple avatars on a vehicle===
This is not well understood at this time, and tends to be unreliable.

==Notes==
Dashed lines are [[Message|UDP messages]]. Solid lines are events received via [[EventQueueGet]].

This documents the successful "happy path". Error conditions are not yet covered.

This information reflects what has been discovered by third part viewer developers. It is not official and may contain errors.

File:Regioncross.png

2024-02-11T20:11:20Z

Animats Resident: Region crossing event sequence diagram

== Summary ==
Region crossing event sequence diagram

Region crossing

2024-02-11T20:05:07Z

Animats Resident: /* Event sequence diagram for region crossings */

==Introduction==
The Second Life world is divided into square regions 256 meters on a side. Each region is managed by a separate simulator program. Viewers present the illusion of a large, seamless world by communicating with several region simulators simultaneously. Avatars cross between regions via a complex process which requires cooperation between multiple simulators and viewers.

==Overview of a region crossing==
A region crossing is initiated by a simulator when an avatar goes outside the region boundary. The center of the root prim of the linkset must be one meter past the boundary for crossing to trigger. This prevents toggling back and forth for avatars on the edge of the region. For avatars on vehicles, the center point of the root prim of the vehicle triggers the crossing, so that all avatars and the vehicle remain together.

When an avatar or an object crosses a region boundary, its information is sent from one simulator to the next. From the viewpoint of a viewer, it is re-created in the gaining region. When the viewer receives an ObjectUpdate message for the avatar or object in the gaining region, the viewer will re-create the object. ObjectUpdate messages (either full or compressed) are sent for each prim in the linkset.

The viewer then detects that it has a duplicate of an existing object that was in the losing region. Each object in the world has a unique UUID, and the viewer checks for duplicates. Creation of a duplicate causes the viewer to delete the old object. This is almost seamless to the user, although some object flicker can often be seen.

The viewer is informed of an avatar region crossing via the CrossedRegion event, which travels over the event poller channel. This is no longer a UDP message, although it was in earlier versions of the SL system. This message indicates the beginning of the region crossing process. An AgentMovementComplete message from the gaining region indicates completion. It is not guaranteed that those messages arrive in order. This tells the viewer which simulator has control and should receive AgentUpdate messages with mouse and keyboard inputs.

During the movement process, there are some out-of-sync conditions. The avatar object does not cross at the same time that control is handed off. This causes some difficulties if the out of sync condition persists. If it persists for more than a few seconds, the region crossing has failed.

{{OSWikiLearnBox|parent=Protocol}}
=Event sequence diagram for region crossings=
[[File:Regioncross.png|center|750px|alt=Sequence diagram|Region crossing event sequence]]
{{collapse top | Source code for the sequence diagram above.}}
To change the diagram, change this source code, then paste it into this free online chart generator [https://sequencediagram.org/] to generate a new .png image.
Then replace the version of the image above with a new image.
<pre>
title Region crossing

participant "Viewer" as V
participant "Losing Sim" as H
participant "Gaining Sim" as N

activate H
activate N
V-->>H: AgentUpdate
V-->>H: AgentUpdate
rbox left of V: Avatar crosses region boundary
H->N: ServerSide ChitChat
N->H:
V->H: EventQueueGet

H->V: CrossedRegion
rbox left of V: Control of avatar transferred to gaining region
rbox left of V: Sim waits for CompleteAgentMovement
V-->>N: CompleteAgentMovement
N-->>V: AgentMovementComplete
V-->>N: AgentUpdate
rbox left of V: Out of sync until object update from ganing region

N-->>V: ObjectUpdate
rbox left of V: Viewer creates avatar object in gaining region
rbox left of V: Viewer detects duplicate object in losing region and kills it.
V-->>N: AgentUpdate
rbox left of V: Normal avatar operation in gaining region
N-->>V: TerseImprovedObjectUpdate
V-->>N: AgentUpdate
N-->>V: ObjectUpdate
</pre>
{{collapse bottom}}
==Discussion==
This is an event sequence diagram of the essential events that take place as an avatar crosses from one region to another.

==Notes==
Dashed lines are [[Message|UDP messages]]. Solid lines are events received via [[EventQueueGet]].

This documents the successful "happy path". Error conditions are not yet covered.

This information reflects what has been discovered by third part viewer developers. It is not official and may contain errors.

Region crossing

2024-02-11T18:22:25Z

Animats Resident: More description

==Introduction==
The Second Life world is divided into square regions 256 meters on a side. Each region is managed by a separate simulator program. Viewers present the illusion of a large, seamless world by communicating with several region simulators simultaneously. Avatars cross between regions via a complex process which requires cooperation between multiple simulators and viewers.

==Overview of a region crossing==
A region crossing is initiated by a simulator when an avatar goes outside the region boundary. The center of the root prim of the linkset must be one meter past the boundary for crossing to trigger. This prevents toggling back and forth for avatars on the edge of the region. For avatars on vehicles, the center point of the root prim of the vehicle triggers the crossing, so that all avatars and the vehicle remain together.

When an avatar or an object crosses a region boundary, its information is sent from one simulator to the next. From the viewpoint of a viewer, it is re-created in the gaining region. When the viewer receives an ObjectUpdate message for the avatar or object in the gaining region, the viewer will re-create the object. ObjectUpdate messages (either full or compressed) are sent for each prim in the linkset.

The viewer then detects that it has a duplicate of an existing object that was in the losing region. Each object in the world has a unique UUID, and the viewer checks for duplicates. Creation of a duplicate causes the viewer to delete the old object. This is almost seamless to the user, although some object flicker can often be seen.

The viewer is informed of an avatar region crossing via the CrossedRegion event, which travels over the event poller channel. This is no longer a UDP message, although it was in earlier versions of the SL system. This message indicates the beginning of the region crossing process. An AgentMovementComplete message from the gaining region indicates completion. It is not guaranteed that those messages arrive in order. This tells the viewer which simulator has control and should receive AgentUpdate messages with mouse and keyboard inputs.

During the movement process, there are some out-of-sync conditions. The avatar object does not cross at the same time that control is handed off. This causes some difficulties if the out of sync condition persists. If it persists for more than a few seconds, the region crossing has failed.

{{OSWikiLearnBox|parent=Protocol}}
=Event sequence diagram for region crossings=
[[File:Regioncross.png|center|750px|alt=Sequence diagram|Region crossing event sequence]]
{{collapse top | Source code for the sequence diagram above.}}
To change the diagram, change this source code, then paste it into this free online chart generator [https://sequencediagram.org/] to generate a new .png image.
Then replace the version of the image above with a new image.
<pre>
title Region crossing - COMING SOON

participant "Viewer" as V
participant "Host Region" as H
participant "Neighbour Region" as N

V->H: EventQueueGet
activate H
rbox left of V: Stood in the region centre\nDraw Distanceis 32m\nno otherregions are visibleV-->H: AgentUpdate(x=128,y=128,Far=32)
V-->>H: AgentUpdate
V-->>H: AgentUpdate
V-->>H: AgentUpdate
rbox left of V: Draw Distance is increased to 200m
V-->>H: AgentUpdate(Far=200)
H->N: ServerSide ChitChat
N->H:
group EventQueueGet<response>
H->V: EventQueueGet([EnableSimulator])
deactivate H
H->>V: EnableSimulator
end
V->H: EventQueueGet
activate H
V-->N:UseCircuitCode
V-->>H: AgentUpdate
V-->>H: AgentUpdate
N-->V: RegionHandshake
V-->N: RegionHandshakeReply
V-->>H: AgentUpdate
group EventQueueGet<response>
H->V: EventQueueGet([EstablishAgentCommunication])
deactivate H
H->>V: EstablishAgentCommunication
end
V->N: Seed
N->V: Seed<Response>V
</pre>
{{collapse bottom}}
==Discussion==
This is an event sequence diagram of the essential events that take place as an avatar crosses from one region to another.

==Notes==
Dashed lines are [[Message|UDP messages]]. Solid lines are events received via [[EventQueueGet]].

This documents the successful "happy path". Error conditions are not yet covered.

This information reflects what has been discovered by third part viewer developers. It is not official and may contain errors.

Region crossing

2024-02-11T18:04:30Z

Animats Resident: Start

Adding neighbor region sequence

2024-02-11T17:52:01Z

Animats Resident: /* Discussion */

{{OSWikiLearnBox|parent=Protocol}}
=Event sequence diagram for adding a connection to a neighbor region=
[[File:Addneighbor.png|center|750px|alt=Sequence diagram|Adding neighbor region connection event sequence]]
{{collapse top | Source code for the sequence diagram above.}}
To change the diagram, change this source code, then paste it into this free online chart generator [https://sequencediagram.org/] to generate a new .png image.
Then replace the version of the image above with a new image.
<pre>
title Adding a new region to viewer comms.

participant "Viewer" as V
participant "Host Region" as H
participant "Neighbour Region" as N

V->H: EventQueueGet
activate H
rbox left of V: Stood in the region centre\nDraw Distanceis 32m\nno otherregions are visibleV-->H: AgentUpdate(x=128,y=128,Far=32)
V-->>H: AgentUpdate
V-->>H: AgentUpdate
V-->>H: AgentUpdate
rbox left of V: Draw Distance is increased to 200m
V-->>H: AgentUpdate(Far=200)
H->N: ServerSide ChitChat
N->H:
group EventQueueGet<response>
H->V: EventQueueGet([EnableSimulator])
deactivate H
H->>V: EnableSimulator
end
V->H: EventQueueGet
activate H
V-->N:UseCircuitCode
V-->>H: AgentUpdate
V-->>H: AgentUpdate
N-->V: RegionHandshake
V-->N: RegionHandshakeReply
V-->>H: AgentUpdate
group EventQueueGet<response>
H->V: EventQueueGet([EstablishAgentCommunication])
deactivate H
H->>V: EstablishAgentCommunication
end
V->N: Seed
N->V: Seed<Response>V
</pre>
{{collapse bottom}}
==Discussion==
This is an event sequence diagram of the essential events that take place as a region discovers and connects to an adjacent region.
This is how the viewer is able to show more than one region on screen.

This is the "happy path" - the way it is supposed to work. In practice, SL simulators sometimes send the '''EstablishAgentCommunication''' message one minute late. This is a bug. It ought to prevent the region from appearing in viewers. However, a workaround in the Second Life Viewer code [https://github.com/secondlife/viewer/blob/60c8b432b3da7c812b1edd2d79afbe82cc4d33bd/indra/newview/llviewerassetstorage.cpp#L488] allows displaying objects in the region by using the asset fetch capability of the region that has the main agent. (Second Life currently uses the same asset servers for all regions. Open Simulator does not. OpenSimulator does not have this bug; sim servers there promptly send '''EstablishAgentCommunication''' after the region handshake.)

This workaround only applies to asset fetching. Until the '''EstablishAgentCommunication''' message arrives, all functions which require capabilities or events are broken. This includes some physically-based rendering features, and may affect VIVOX voice and region crossings.

See also forum discussion at [https://community.secondlife.com/forums/topic/503010-obscure-question-when-does-the-simulator-send-establishagentcommunication-to-the-viewer/page/8/]

==Notes==
Dashed lines are [[Message|UDP messages]]. Solid lines are events received via [[EventQueueGet]].

This documents the successful "happy path". Error conditions are not yet covered.

This information reflects what has been discovered by third part viewer developers. It is not official and may contain errors.

Adding neighbor region sequence

2024-02-11T17:50:33Z

Animats Resident: Discuss problem with EstablishAgentCommunication

{{OSWikiLearnBox|parent=Protocol}}
=Event sequence diagram for adding a connection to a neighbor region=
[[File:Addneighbor.png|center|750px|alt=Sequence diagram|Adding neighbor region connection event sequence]]
{{collapse top | Source code for the sequence diagram above.}}
To change the diagram, change this source code, then paste it into this free online chart generator [https://sequencediagram.org/] to generate a new .png image.
Then replace the version of the image above with a new image.
<pre>
title Adding a new region to viewer comms.

participant "Viewer" as V
participant "Host Region" as H
participant "Neighbour Region" as N

V->H: EventQueueGet
activate H
rbox left of V: Stood in the region centre\nDraw Distanceis 32m\nno otherregions are visibleV-->H: AgentUpdate(x=128,y=128,Far=32)
V-->>H: AgentUpdate
V-->>H: AgentUpdate
V-->>H: AgentUpdate
rbox left of V: Draw Distance is increased to 200m
V-->>H: AgentUpdate(Far=200)
H->N: ServerSide ChitChat
N->H:
group EventQueueGet<response>
H->V: EventQueueGet([EnableSimulator])
deactivate H
H->>V: EnableSimulator
end
V->H: EventQueueGet
activate H
V-->N:UseCircuitCode
V-->>H: AgentUpdate
V-->>H: AgentUpdate
N-->V: RegionHandshake
V-->N: RegionHandshakeReply
V-->>H: AgentUpdate
group EventQueueGet<response>
H->V: EventQueueGet([EstablishAgentCommunication])
deactivate H
H->>V: EstablishAgentCommunication
end
V->N: Seed
N->V: Seed<Response>V
</pre>
{{collapse bottom}}
==Discussion==
This is an event sequence diagram of the essential events that take place as a region discovers and connects to an adjacent region.
This is how the viewer is able to show more than one region on screen.

This is the "happy path" - the way it is supposed to work. In practice, SL simulators sometimes send the '''EstablishAgentCommunication''' message one minute late. This is a bug. It ought to prevent the region from appearing in viewers. However, a workaround in the Second Life Viewer code [https://github.com/secondlife/viewer/blob/60c8b432b3da7c812b1edd2d79afbe82cc4d33bd/indra/newview/llviewerassetstorage.cpp#L488] allows displaying objects in the region by using the asset fetch capability of the region that has the main agent. (Second Life currently uses the same asset servers for all regions. Open Simulator does not.)

This workaround only applies to asset fetching. Until the '''EstablishAgentCommunication''' message arrives, all functions which require capabilities or events are broken. This includes some physically-based rendering features, and may affect VIVOX voice and region crossings.

See also forum discussion at [https://community.secondlife.com/forums/topic/503010-obscure-question-when-does-the-simulator-send-establishagentcommunication-to-the-viewer/page/8/]

==Notes==
Dashed lines are [[Message|UDP messages]]. Solid lines are events received via [[EventQueueGet]].

This documents the successful "happy path". Error conditions are not yet covered.

This information reflects what has been discovered by third part viewer developers. It is not official and may contain errors.

File:Addneighbor.png

2023-09-07T18:41:34Z

Animats Resident: How a viewer connects to a neighboring region. Created by Beq Janus.

== Summary ==
How a viewer connects to a neighboring region.

Created by Beq Janus.

Adding neighbor region sequence

2023-09-07T18:37:19Z

Animats Resident: Begin page.

Login sequence

2023-09-07T02:56:35Z

Animats Resident: Discussion

{{OSWikiLearnBox|parent=Protocol}}
=Event sequence diagram for login=
[[File:Initiallogin.png|center|750px|alt=Sequence diagram|Initial login event sequence]]
{{collapse top | Source code for the sequence diagram above.}}
To change the diagram, change this source code, then paste it into this free online chart generator [https://sequencediagram.org/] to generate a new .png image.
Then replace the version of the image above with a new image.
<pre>
title Initial login to world

participant "Viewer" as V
participant "Initial region" as R
participant "Login server" as L

group Initial login
activate V
V->L: Login request, XMLRPC
activate L
L->R: (region advised login coming)
activate R
L->V: Login reply
rbox left of V: Contains initial region IP, port, seed\nregion handle, agent ID\nbut not avatar location in region.
V-->>R: UseCircuitCode
V-->>R: CompleteAgentMovement
V-->>R: UuidNameRequest
rbox left of V: UuidNameRequest for avatar name.\nProbably unnecessary, but traditional.
R-->V: RegionHandshake
rbox left of V: A 2 second delay here before the reply\nreduces interest list errors.\nRef: BUG-233107
V-->>R: RegionHandshakeReply
V-->>R: AgentUpdate
rbox left of V: This first AgentUpdate has a bogus avatar position.\nViewer does not know where the avatar is yet\nbut must send this to get object updates started.\nCause of some interest list bugs.
V->R: EventQueueGet
R-->>V: ObjectUpdate
rbox left of V: The first object update is usually for the avatar.\nThis tells the viewer where the avatar really is.\nPosition of avatar moves in viewer.
V-->>R: AgentUpdate
rbox left of V: Viewer tells region where the camera is.\nViewer and region are now in sync.
end

rbox left of V: Logged in.\nNormal operation from here on.

R-->>V: ObjectUpdate
R-->>V: ObjectUpdate
R-->>V: ObjectUpdate
R->V: (Various event queue events)
V-->>R: AgentUpdate
</pre>
{{collapse bottom}}
==Discussion==
This is an event sequence diagram of the essential events that take place during a login.

The process starts out with the viewer making a request to the login server. The login server authenticates the user, and determines in which region the user's avatar will enter the world. If the user requested a login to "Last" or "Home", the login server determines the region. The login communicates with the selected region to prepare it to receive the login. If this communication is unsuccessful, usually because that region is offline, the avatar is re-routed to some other region, usually a "safe hub". The viewer can discover this from the SimName field in the RegionHandshake message. Scripted agent controllers should check this, or their bots will pile up at safe hubs.

The login server provides the viewer with the key information needed to connect to a region - IP address, port number, region location (and size for Open Simulator), seed capability (a URL which connects to the initial simulator), plus other useful info. The IP address and port number are used to set up the UDP message circuit. The seed capability is used to establish communications with the simulator over HTTPS, and to locate other servers, such as the asset server system. An HTTPS connection to the [[EventQueueGet]] system is established. A region handshake takes place.

It is the AgentUpdate message that really gets things going. That starts the flow of ObjectUpdate messages that tell the viewer about all objects within view range. There's an implicit sequencing problem in the protocol. The AgentUpdate message from viewer to simulator contains the camera location.
However, the viewer doesn't know the avatar location until it gets an ObjectUpdate with the avatar's UUID. (The login message reply provides that UUID).
So the first AgentUpdate has a bogus avatar position, which will be corrected by a later AgentUpdate. This jump seems to have negative effects on
the correctness of the set of objects sent in ObjectUpdate messages. (Ref [https://jira.secondlife.com/browse/BUG-233107]). Teleports have the same problem.

==Notes==
Dashed lines are [[Message|UDP messages]]. Solid lines are events received via [[EventQueueGet]], except for the XMLRPC call to the login server.

This documents the successful "happy path". Error conditions are not yet covered.

This information reflects what has been discovered by third part viewer developers. It is not official and may contain errors.

Login sequence

2023-09-07T02:21:53Z

Animats Resident: /* Notes */

Login sequence

2023-09-07T02:17:34Z

Animats Resident: Diagram complete resized

Login sequence

2023-09-07T02:06:32Z

Animats Resident: Add diagram

{{OSWikiLearnBox|parent=Protocol}}

(Under construction)

=Event sequence diagram for login=
[[File:Initiallogin.png|left|alt=Sequence diagram|Initial login event sequence]]
==Notes==
==Source code for the diagram
{{collapse top | Source code for the sequence diagram.}}
Source code for the sequence diagram above. To change the diagram, change this source code, then paste it into this free online chart generator [https://sequencediagram.org/] to generate a new .png image.
Then replace the version of the image above with a new image.
<source>
title Initial login to world

participant "Viewer" as V
participant "Initial region" as R
participant "Login server" as L

group Initial login
activate V
V->L: Login request, XMLRPC
activate L
L->R: (region advised login coming)
activate R
L->V: Login reply
rbox left of V: Contains initial region IP, port, seed\nregion handle, agent ID\nbut not avatar location in region.
V-->>R: UseCircuitCode
V-->>R: CompleteAgentMovement
V-->>R: UuidNameRequest
rbox left of V: UuidNameRequest for avatar name.\nProbably unnecessary, but traditional.
R-->V: RegionHandshake
rbox left of V: A 2 second delay here before the reply\nreduces interest list errors.\nRef: BUG-233107
V-->>R: RegionHandshakeReply
V-->>R: AgentUpdate
rbox left of V: This first AgentUpdate has a bogus avatar position.\nViewer does not know where the avatar is yet\nbut must send this to get object updates started.\nCause of some interest list bugs.
V->R: EventQueueGet
R-->>V: ObjectUpdate
rbox left of V: The first object update is usually for the avatar.\nThis tells the viewer where the avatar really is.\nPosition of avatar moves in viewer.
V-->>R: AgentUpdate
rbox left of V: Viewer tells region where the camera is.\nViewer and region are now in sync.
end

rbox left of V: Logged in.\nNormal operation from here on.

R-->>V: ObjectUpdate
R-->>V: ObjectUpdate
R-->>V: ObjectUpdate
R->V: (Various event queue events)
V-->>R: AgentUpdate
</source>
{{collapse bottom}}

File:Initiallogin.png

2023-09-07T01:50:12Z

Animats Resident: Sequence diagram for initial login.

== Summary ==
Sequence diagram for initial login.

Login sequence

2023-09-07T01:48:42Z

Animats Resident: Beginning add of sequence diagrams

{{OSWikiLearnBox|parent=Protocol}}

(Under construction)

===Source code for above diagram===

<source>
title Initial login to world

participant "Viewer" as V
participant "Initial region" as R
participant "Login server" as L

group Initial login
activate V
V->L: Login request, XMLRPC
activate L
L->R: (region advised login coming)
activate R
L->V: Login reply
rbox left of V: Contains initial region IP, port, seed\nregion handle, agent ID\nbut not avatar location in region.
V-->>R: UseCircuitCode
V-->>R: CompleteAgentMovement
V-->>R: UuidNameRequest
rbox left of V: UuidNameRequest for avatar name.\nProbably unnecessary, but traditional.
R-->V: RegionHandshake
rbox left of V: A 2 second delay here before the reply\nreduces interest list errors.\nRef: BUG-233107
V-->>R: RegionHandshakeReply
V-->>R: AgentUpdate
rbox left of V: This first AgentUpdate has a bogus avatar position.\nViewer does not know where the avatar is yet\nbut must send this to get object updates started.\nCause of some interest list bugs.
V->R: EventQueueGet
R-->>V: ObjectUpdate
rbox left of V: The first object update is usually for the avatar.\nThis tells the viewer where the avatar really is.\nPosition of avatar moves in viewer.
V-->>R: AgentUpdate
rbox left of V: Viewer tells region where the camera is.\nViewer and region are now in sync.
end

rbox left of V: Logged in.\nNormal operation from here on.

R-->>V: ObjectUpdate
R-->>V: ObjectUpdate
R-->>V: ObjectUpdate
R->V: (Various event queue events)
V-->>R: AgentUpdate
</source>

Login sequence

2023-09-07T01:32:56Z

Animats Resident: Starting

{{OSWikiLearnBox|parent=Protocol}}

(Under construction)

Protocol

2023-09-07T01:31:04Z

Animats Resident: Fix links.

{{OSWikiLearnBox}}

==Message Formats==
===Binary UDP===
* [[Message Layout]] -- Explanation of message format and the message template
* [[Packet Layout]] -- the layout of the UDP payload.
* [[Circuits]] -- Establishment and common operation of UDP circuits between two nodes
* [[Packet Accounting]] -- how the message system handles packet sequencing, reliability, suppression, throttling, etc.
* [[:Category:Common Messages|Common Messages]] -- messages that are handled by every Indra message system instance.
* [[Xfer Manager]] -- messages used by the <code>LLXFerManager</code> class.
* [[Transfer Manager]] -- messages used by the <code>LLTransferManger</code> class.
* [[:Category:Messages|All messages]] -- an alphabetical listing of all messages in the system

===Capabilities===
The Capabilities system allows viewers to request abilities and be temporarily granted those abilities through a unique URL. The transport format is LLSD XML, and clients can either post new events to CAPS URLs or wait for events to come from the server on the event queue connection the client holds open.

* [[Capabilities]]
* [[Message_System_and_Capabilities]]

Capabilities use the Linden Lab Structured Data system to represent data.
See [[LLSD]].

===XML-RPC===
Older releases of the official viewer used XML-RPC as part of the [[Login Protocol]]. The official viewer now uses a web based authentication protocol, however non-official viewers may still use XML-RPC for login.

See also [[Authentication Flow]].

==Protocol Systems==
===Animations===

See [[Internal Animation Format]].

===Appearance===
See [[Avatar Appearance]].

===Assets===

===Avatars===

===Channels and Versions===

* [[Channel]] - definition of a channel
** [[Channel and Version Requirements]] - Linden Lab policy on the use of channels.

===Directory Searches===
See [[:Category:Search Messages|Search Messages]].

===Estate Tools===
===Friends===
See:
* [[:Category:Relationship Messages|Relationship Messages]]
* [[Mute List]]

===Grid===
===Groups===
* [[Group Messages]]

===Inventory===
* [[:Category:Inventory Messages|Inventory Messages]]
* [[Inventory Capabilities]]
* [[Task Inventory]]

===Agent===
* [[:Category:Agent Messages|Agent Messages]]
* [[:Category:Money Messages|Money Messages]]
* [[:Category:Communication Messages|Communication Messages]]
* [[Buying Land and Currency]]
===Login===
* [[Login_Protocol|Login]]

===Movement===
===Objects===
* [[:Category:Object Messages|Object Messages]]

===Images===
===Parcels===
* [[:Category:Parcel Messages|Parcel Messages]]

===Simulators===
* [[:Category:Region Messages|Region Messages]]

===Sounds===
===Terrain===

===Protocol Sequence Diagrams===
* [[Login sequence]]
* [[Adding neighbor region sequence]]
* [[Disconnecting neighbor region sequence]]
* [[Teleport to distant region sequence]]
* [[Teleport to visible region sequence]]
* [[Region crossing sequence]]

==File Formats==
===Asset Files===
{{All Asset Types}}

[[Category:Assets]]

Category:Sequence Diagram

2023-09-07T01:29:45Z

Animats Resident: Create category

{{OSWikiLearnBox|parent=Protocol}}

Sequence diagrams for major protocol events.

Protocol

2023-09-07T01:28:27Z

Animats Resident: Beginning add of sequence diagrams

{{OSWikiLearnBox}}

==Message Formats==
===Binary UDP===
* [[Message Layout]] -- Explanation of message format and the message template
* [[Packet Layout]] -- the layout of the UDP payload.
* [[Circuits]] -- Establishment and common operation of UDP circuits between two nodes
* [[Packet Accounting]] -- how the message system handles packet sequencing, reliability, suppression, throttling, etc.
* [[:Category:Common Messages|Common Messages]] -- messages that are handled by every Indra message system instance.
* [[Xfer Manager]] -- messages used by the <code>LLXFerManager</code> class.
* [[Transfer Manager]] -- messages used by the <code>LLTransferManger</code> class.
* [[:Category:Messages|All messages]] -- an alphabetical listing of all messages in the system

===Capabilities===
The Capabilities system allows viewers to request abilities and be temporarily granted those abilities through a unique URL. The transport format is LLSD XML, and clients can either post new events to CAPS URLs or wait for events to come from the server on the event queue connection the client holds open.

* [[Capabilities]]
* [[Message_System_and_Capabilities]]

Capabilities use the Linden Lab Structured Data system to represent data.
See [[LLSD]].

===XML-RPC===
Older releases of the official viewer used XML-RPC as part of the [[Login Protocol]]. The official viewer now uses a web based authentication protocol, however non-official viewers may still use XML-RPC for login.

See also [[Authentication Flow]].

==Protocol Systems==
===Animations===

See [[Internal Animation Format]].

===Appearance===
See [[Avatar Appearance]].

===Assets===

===Avatars===

===Channels and Versions===

* [[Channel]] - definition of a channel
** [[Channel and Version Requirements]] - Linden Lab policy on the use of channels.

===Directory Searches===
See [[:Category:Search Messages|Search Messages]].

===Estate Tools===
===Friends===
See:
* [[:Category:Relationship Messages|Relationship Messages]]
* [[Mute List]]

===Grid===
===Groups===
* [[Group Messages]]

===Inventory===
* [[:Category:Inventory Messages|Inventory Messages]]
* [[Inventory Capabilities]]
* [[Task Inventory]]

===Agent===
* [[:Category:Agent Messages|Agent Messages]]
* [[:Category:Money Messages|Money Messages]]
* [[:Category:Communication Messages|Communication Messages]]
* [[Buying Land and Currency]]
===Login===
* [[Login_Protocol|Login]]

===Movement===
===Objects===
* [[:Category:Object Messages|Object Messages]]

===Images===
===Parcels===
* [[:Category:Parcel Messages|Parcel Messages]]

===Simulators===
* [[:Category:Region Messages|Region Messages]]

===Sounds===
===Terrain===

===Protocol Sequence Diagrams===
* [[:Category:Sequence Diagram|Login sequence]]
* [[:Category:Sequence Diagram|Adding neighbor region sequence]]
* [[:Category:Sequence Diagram|Disconnecting neighbor region sequence]]
* [[:Category:Sequence Diagram|Teleport to distant region sequence]]
* [[:Category:Sequence Diagram|Teleport to visible region sequence]]
* [[:Category:Sequence Diagram|Region crossing sequence]]

==File Formats==
===Asset Files===
{{All Asset Types}}

[[Category:Assets]]

User:Animats Resident

2023-09-05T06:19:41Z

Animats Resident: Start user page.

Creator of the Sharpview viewer.