[Opensim-dev] User/Agent/Avatar Was: Question on Avatar Appearance persistance
Michael Wright
michaelwri22 at yahoo.co.uk
Mon Apr 14 18:53:51 UTC 2008
I'm not saying that should be a goal, just saying we should allow it if thats what people want. My focus isn't on games, but on more serious apps and for those I can imagine times when you don't want people coming as whatever avatar they want, but want some control over it. Also, as I said, there will be some applications that don't want avatars. I can think of lots of applications like that.
The bit about the Saudi Arabia region, I don't think can be a case for not supporting the ability for a region to set a avatar. Yes I agree that not many people would want to visit such a region, but there are proper uses for that "feature" so we can't just exclude it as it might be miss used. I think if we thought in those terms we would all have to stop working on the whole of opensim. I actually think a equal argument could be made in favour of regions always setting the avatars of people in them, so no one can bring a offensive avatar into a region. But anyway I understand both points, and just want to make sure we support the ability for people to use opensim in whatever (Legal) way they want to.
I totally agree that opensim needs to be able to support people visiting regions/grids who haven't created a account. By both being able to be set up to support anonymous accounts and to allow people who have a account on another "grid" to visit. I think we most likely just have slightly different ways of looking at this.
I see opensim as being a 3d apache type server, that people take and adapt and build their applications on top of. So the, visiting multiple regions/grids with a shared account, support could be a extra project on top of opensim. Just like openid is used by various websites. I'm not saying that such support won't be directly in opensim. Just saying that opensim by itself is not meant to solve all problems/ case usages.
The one thing I don't want to see is some massive monolithic grid. The concept we have used before is "a grid of grids" with teleportation support between them.
However, I really want to get past the grid concept and think if we come up with a good solution there, then that will solve a lot of these types of problems.
I also think Kurt Taylor is most likely right, in that things will most likely develop in a completely different way to what we think. And at this stage we most likely can't even hope to solve the global credential system or global avatar system. When so many other things aren't even near to being in place yet.
So I just hope we keep opensim open and flexible enough so we can adapt it to whatever the solution might be.
Diva Canto <diva at metaverseink.com> wrote: This is great! 8-) I'm looking forward to OpenSim having these concepts all cleared out, and the decoupling in place. I'm still not convinced that the goal of agents automatically taking different avatars in different grids is a worthy goal, because people can always get accounts in those places if there is a special code there.
...You need to think about the larger consequences of these gaming practices, which make sense for games but can be severe for serious applications. For example, I would simply hate that my avatar would be forced to wear a head-to-toe veil whenever I visit a world hosted in Saudi Arabia... But since that is a super-set of what I'm saying, I'm not going to argue [much]; if OpenSim ends up supporting that kind of thing, I'll simply stay away from worlds that will *impose* anything on my choices for my avatar's appearance or inventory. Unless, of course, I choose to sign up for a role-playing game (and I can imagine some western people looking at the veils and the discriminatory practices in Saudi Arabia as nothing but a role-playing computer game... /me shakes head).
Anyway, the way things are right now, there's enormous value-added in OpenSim already: opening the source is crucial, having the ability to extend region features is extremely important, physics is important, supporting full LSL and beyond is important, etc. etc., but... there's this one feature -- or whatever you want to call it -- that I think is the single most important thing that will make OpenSim the infrastructure that most organizations (around me) will want. We can all live with bugs and incompleteness for a while, but we need to know that we can have visits from people not registered here and let them visit without us having to give them any persistent resources or imposing anything on them (if someone shows up naked to a virtual classroom, the negotiation will happen as it would have happened in the real world -- through a conversation and eventual eject).
Michael Wright wrote: Yup there is certainly division between the various layers , and I think at times we have all got confused about the different terms in opensim.
I think the general layout is something like:
Users - can have a account with authentication and profile data etc. We should offer support for anonymous users too (configurable, if it is enabled or not)
Agent- can be thought of as the connection between the client and a region. So the agent in the region, that contains the user's avatar, is called the root agent. But the client can have child agents in the neighbouring regions. The agent connection is at the region level, so in opensim they "own/have" a ScenePresence that is its entity in the 3d world...
ScenePresence- they are the entities representing the agents in the 3d world, They have a position etc. The root agent's ScenePresence has/is a physical Avatar, so other users will see it. While the child agent's ScenePresence can be thought of ghost entities, that can see other avatars but can't be seen itself.
It is possible that some clients could be created that don't actually have any ScenePresences connected to their agents. And still allow things like textures to be uploaded or inventory to be managed. Or even messages broadcast into the 3d scene. Like maybe region Admin Clients.
I think that there has to be some decoupling between Users/Agents and Avatars. As yes for some cases you want to take the same avatar around everywhere with you but that is not always the case. As I said before some Games or whatever might want to give you a avatar for use in that application. So we just need to make sure we support the different cases. Also some 3d visualisation applications might not want any avatars, just all users having ghost entities.
OpenSim is not about creating one single type of metaverse. It is about creating a 3d multi user platform that various applications, including a global shared metaverse, can be built on top of.
Stefan Andersson <stefan at tribalmedia.se> wrote: .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } Diva,
the division of agent and avatar is definitively therere; you can have 'agents' in neighbouring regions that communicates changes in those regions, but these does not have avatars associated with them. Agents (both child and root) also has a 'camera' that is positioned in the regions.
An agent needs no 'name' at all, but authentication credentials; an avatar needs no credentials, but has a 'name'.
Technically, what a region needs is a (trusted) source to tell it to expect an agent connection with certain properties, then an agent that connects with those properties. It also needs to know where to fetch the information to send to that agent in response to agent requests. As OpenSim evolves, we will probably less and less assumptions regarding how this is organized and communicated.
I was actually not discussing persistence at all; your comment about persistence being a burden is 100% right.
When I say 'grid' I merely use a well-known term for 'resource discovery scope'.
As I mentioned, the 'User' concept, and with it user profile, is (probably) out of scope and best left implemented somewhere else;
but being able to separate agent login credentials from avatar name is definitively within scope.
Also, my note was as a response to the current state of the region and user storage - I was merely trying to get us to take a (relatively) small step towards a more generic model; which would then let us work better with various authentication and naming schema. (For example, the one I'm working with now, which clearly needs separation between login credentials and avatar name)
/Stefan
---------------------------------
Date: Sun, 13 Apr 2008 12:56:13 -0700
From: diva at metaverseink.com
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] User/Agent/Avatar Was: Question on Avatar Appearance persistance
That is a possibility. However, it seems a bit more complicated than necessary: you don't necessarily need to separate the concept of "agent" from the concept of "avatar", a 1-to-1 relation between these is fine.
I'm imagining the interaction of what you propose: I (actual person) sign up to the metaverse with one of many agent credentials, say my verisign credentials; suppose I have another one at yahoo, for example, or even a second one at verisign; then the viewer makes me choose between my many online names of avatars associated with my first verisign agent -- that's the step I think is unnecessary. Since I can have many accounts anyway, I don't need many avatars per agent. -- although I can see what you are saying is inline with the prevalent model of avatars being a grid concept, and therefore being able to change as one goes around different grids with the same agent.
In my view of things, users and agents, along with their credentials, storage and comms, would be served outside of grids, and there would be no *persistent* representation of them at the grid and regions server levels -- although grids might choose to provide that user/identity/agent service too, at least for some people. But this service would be completely separate.
I would like to sign up to the metaverse under one of my accounts and be able to go around many grids. There will be grids that won't allow my account there. That's fine. If I really want to go there, I should get an account with that grid, or with whatever identity service it accepts.
What you're proposing is one step more generic than what I, personally, need. More importantly, wearing my hat of a close advisor to organizations who are interested in developing services in 3D, I think that any persistent user/avatar representations at the grid level are a burden for these organizations. They will want visits from millions of people, and they don't want to store any information about those avatars, other than logging their visits.
The best way of envisioning what I'm saying is to place yourself in the shoes of a university.
Stefan Andersson wrote: .ExternalClass .EC_hmmessage P {padding:0px;} .ExternalClass body.EC_hmmessage {font-size:10pt;font-family:Tahoma;} Ehrm , not to spin off in too many directions at once, but we really should acommodate for a somewhat more comprehensible set of concepts:
"User" : an actual acting person in the real world -
* can have many Agents (consider same person running -multiple viewers)
* has a real name, and an online name
* has a profile with profile data
* has credentials, to be able to be authorized
"Agent" : the informational representation of a user in a world
* has credentials, to be able to be authorized
"Avatar" : the visual representation of an agent in a world (only one per Agent in the SL universe afaik)
* has an online name
* has a profile, with profile data
"Credentials" : data supplied for authentication (user names, keys, passwords, hashes, et c)
One example:
I'm Stefan Andersson in the real world. When I don't want to disclose my full real name, such as in IM lists, I just call myself 'Stefan' (which, in this case, is my chosen 'online name' or 'calling name').
Now, in most user databases, I need a unique login credential, usually, i choose the username 'lbsa71' since that's available more often than 'Stefan'.
Now, of course, I have a couple of avatars in SL, one of them is called "PierreJoseph Proudhon" (first/last construct by SL convention - strictly not necessary)
To choose what avatar I want to join SL with, and at the same time authorize myself, I enter an avatar name and avatar password into the viewer, which then uses it to authorize the agent with which I enter the 3D world.
My point here, is that although this is how SL works, it's not how OpenSim ought to work. The same 'shortcuts' could be the default implementation, but we really should be able to log in with one set of credentials, which would not be tied to the avtar at all. Also, some other viewers or launch methods might let the user log on with his user credentials, and simply CHOOSE his avatar (the web page login method would allow for such a scheme)
I guess we might not even want to consider the 'user' and his credentials, and leave that to various implmentations (like, how each grid has their own user profile) but we should definitively call the Avatars profile data 'AvatarProfile' - and separate "Agent login credentials" from "Avatar online name".
So; awaiting feedback, I propose we work towards the model outlined above.
Best,
Stefan
---------------------------------
> Date: Sat, 12 Apr 2008 08:00:22 -0400
> From: sean at dague.net
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] Question on Avatar Appearance persistance
>
> On Fri, Apr 11, 2008 at 06:09:56PM +0100, Michael Wright wrote:
> > okay will try to make this my last email (before anyone replies) on this. But I think I'm understanding more of what you meant.
> >
> > And while I think there is no reason why we couldn't have
> > AvatarAppearance hanging off UserProfile data. I'm still not convinced
> > there is a need to try to connect all these things. Avatar Appearance
> > is certainly a scene thing. In that every ScenePresence needs a
> > reference to one. But we could move the actual Av atar Appearance
> > class out to OpenSim.framework, or if going with the "Anemic Domain
> > Model" appoach suggested by Stefan then we could have a base
> > AvatarAppearance in the model project. Then in the avatar appearance
> > module fetch the appearance object that was attached to the user
> > profile.
> >
> > But I'm not sure I really see any benefit in this over the module
> > doing a direct request to the user server for the appearance. I
> > actually think its better to decouple things in this way.
>
> By decoupling from the user server, we've coupled AppearanceModule to
> DataMapper, and are managing database connections in a RegionModule,
> which I think is a worse approach.
>
> m_scene.CommsManager.UserService.GetUserProfile(id) seems
> like a much better approach. We could just add .GetUserAppearance and
> friends to it.
>
> > As I said in my last email, there could also be some bots/NPC's that
> > don't have userprofiles. And also I think there is a chance that scene
> > presences are created (and the appearance fetched) before the user
> > profiles are. But can't be sure of that without looking deeper in the
> > code.
>
> If an NPC exists in the environment, I would think it would have a
> profile (it needs that for Name for instance).
>
> > But anyway as long as we went through the avatar appearance factory
> > module concept to fetch the appearance that was attached to the user
> > profile. Then I guess there is nothing stopping it. Just seems a
> > coupling that isn't needed.
>
> Yes, that's probably strictly true. Actually, we don't really need it
> hanging off of UserProfile. What I really meant was that
> AvatarAppearance was an object that existed, and was fetchable/updatable
> from the UserService by UUID.
>
> > I am very strongly of the opinion that we need to keep the factory
> > module concept. So that a different module could be used. Different
> > regions/applications might want a completely different approach to how
> > the appearance of the avatars are handled. Like a game might want to
> > randomly just give each user one of a set of preset avatars.
> >
> > But with this factory module. We can actually fetch the appearance
> > from where ever we want, including the userprofile if it is decided.
>
> If we move the default storage back into UserService, I don't think
> we'll have an issue here. UserService will just support a persistance
> model for appearance, should anyone want to use that. How appearance is
> created remains in the region modules.
>
> -Sean
>
> --
> __________________________________________________________________
>
> Sean Dague Mid-Hudson Valley
> sean at dague dot net Linux Users Group
> http://dague.net http://mhvlug.org
>
> There is no silver bullet. Plus, werewolves make better neighbors
> than zombies, and they tend to keep the vampire population down.
> __________________________________________________________________
---------------------------------
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
---------------------------------
Yahoo! for Good helps you make a difference
---------------------------------
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
---------------------------------
Yahoo! for Good helps you make a difference
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080414/e3043d9c/attachment-0001.html>
More information about the Opensim-dev
mailing list