<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
There's something else in opensim that adds to the confusion:
ScenePresence, which seems to be a composite between client, agent, and
avatar. Specifically, ScenePresence is the thing that makes agents
become root/child. ScenePresences are created when new clients are
created.<br>
<br>
As far as I can tell, ScenePresence is being treated as Avatar, but I'm
not sure this is conceptually correct. When a scene presence is
associated with a child agent, there is no avatar.<br>
<br>
Stefan Andersson wrote:
<blockquote cite="mid:BLU134-W145AA1D6C66633E772FBC1D5080@phx.gbl"
type="cite">
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>Another take;<br>
<br>
User - information about the real life meatspace user. This information
is oftenly pulled from a non-opensim source (like a CMS, directory
service or intranet) and should ideally only concern information needed
by opensim.<br>
<br>
Agent - the software that is used to upload stuff and interact with the
world. (if you think about it, it's not the 'user' that uploads an
asset or modifies inventory, from the servers point of view - and a
user can have two viewers running...)<br>
<br>
Avatar - information about the users representation in-world.<br>
<br>
I love that this thread is still alive, +1 on cleaning the whole thing
up (the confusion harks back to a time when the only four people
actually coding was rather confused themselves, and to a certain degree
of rapid-development laziness)<br>
<br>
Also, +1 on separating them more. I have posted several times to this
effect - in anything but an SL-grid, the one-to-one-ness is a mess.<br>
<br>
Actually, I would go as far as to say that there should be another
separated entity;<br>
<br>
"Authentication" or "Membership" - since a user can actually use
several authentication schemes to authenticate his agent, and there
might not be any RL user at all (as in the case with services).<br>
<br>
Also, consider the potential relationships and permutations between
these entitites. A user can have an avatar, but no agent. Or we can
have an agent with no user but several avatars (NPC bot services) et c
et c.<br>
<br>
Yays, cheers, whoots et c.<br>
<br>
Best regards,<br>
Stefan Andersson<br>
Tribal Media AB<br>
<br>
Join the 3d web revolution : <a moz-do-not-send="true"
href="http://tribalnet.se/">http://tribalnet.se/</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
<hr id="stopSpelling">
<br>
Date: Sun, 23 Nov 2008 16:56:15 -0800<br>
From: <a class="moz-txt-link-abbreviated" href="mailto:dahliatrimble@gmail.com">dahliatrimble@gmail.com</a><br>
To: <a class="moz-txt-link-abbreviated" href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>
Subject: Re: [Opensim-dev] User/Agent/Avatar (again) and multiple logins<br>
<br>
These are often confusing terms. I'd like to throw out some simplistic
straw dog definitions and hopefully set a path towards a consensus.I
haven't traced through the OpenSimulator code enough to know if these
definitions fit well in this implementation, but rather I am lead to
believe these definitions are somewhat fitting through my experiences
with SL I suspect some will have differing opinions on these
definitions so please reply with any corrections that may help towards
a consensus or better represent their use in the code base.<br>
<div><br>
</div>
<div>User - a person who interacts with the service. A user will
create an account, use the service through the viewer software and web
sites, and possibly eventually delete the account.</div>
<div><br>
</div>
<div>Agent - that which represents the user for simulation purposes.
An agent would need a consistent means of identification while it is
actively part of the simulation and this identification should be able
to link the agent to the user's account so it can be associated with
inventory, assets, and communication. An agent will be associated with
a physics proxy which will be used to model interactions with the
simulated physical environment. An agent would serve as a
communications focal point and relay this communication between scene
chat, group or personal instant messages, and the user's viewer session.</div>
<div><br>
</div>
<div>Avatar - the graphical representation of both an agent and a
user that appears on the viewer screen of those using the service. It
operates in tandem with the agent in that it moves in the scene as the
agent proxy moves in the simulation scene, and it is usually controlled
along with the agent by the user. Software may interact with both the
agent and the avatar, such as in physical movement and collisions, or
it may interact solely with the avatar, such as in appearance or
animation.</div>
<div><br>
</div>
<div><br>
<br>
</div>
<div><br>
<div class="EC_gmail_quote">On Sun, Nov 23, 2008 at 3:52 PM, Diva
Canto <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:diva@metaverseink.com">diva@metaverseink.com</a>></span>
wrote:<br>
<blockquote class="EC_gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi,<br>
<br>
I've been noticing that there is a certain confusion in the code about<br>
the names of methods and fields when it comes to denoting a user vs. an<br>
agent vs. an avatar. That could be cleaned up, eventually, if someone is<br>
up for a little bit of renaming. But there seems to be a deeper<br>
confusion in the data structures themselves, and that's much nastier to<br>
deal with. Specifically, agents take the UUIDs of the users they<br>
represent, instead of having a UUID of their own and pointing to the<br>
user. By doing this, the separation between user and agent is defeated.<br>
Also, AgentCircuitData takes a copy of the first and last names of the<br>
users they represent, and this is a bit fragile when one wants to<br>
process the names of users in interesting ways.<br>
<br>
I really like the conceptual separation of those 3 things. I can imagine<br>
situations where it is advantageous for a single user to be logged in<br>
several times -- e.g. wanting to attend multiple events at the same
time.<br>
<br>
Is this "id collapse" being done for optimization? Or is this one of<br>
those things that made it to the code and never got challenged? Or is<br>
this a well-known TODO?<br>
<br>
This is not urgent, I'm just wondering what the story is.<br>
<br>
Crista<br>
<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a moz-do-not-send="true" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a moz-do-not-send="true"
href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</blockquote>
</div>
<br>
</div>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>