1-1, 1-N and M-N

Events happening in the community are now at Drupal community events on www.drupal.org.
atate's picture

With Opensim (and Second Life main grid and Second Life Enterprise) we live in an environment where we want our Drupal web portal to act as a location where we can set up and manage groups related to us, but which allow for membership of more than one group or community, and more than one virtual world Opensim grid or service.

I would like to see a robust and extensible solution for Drupal link up with Virtual Worlds that allowed for setup of N virtual world (initially Opensim) personalities rather than a single one. So 1-N rather than 1-1 as in the current SLUser Drupal module. That means making sure that the underlying data base tables allow for multiple entries per Drupal user even if only 1-1 is supported initially.

I would NOT argue for an N-M solution, but woud use diffgerent Drupal log in names if anyone needs that.

Comments

What happened to this project?

gfxguru's picture

I think this project has potential. Anyone working on a release?

I'm 80% there. My enthusiasm

mile23's picture

I'm 80% there. My enthusiasm for this project is waning, however, thanks in no small part to Linden Lab's recent change to the way avatars are named, and having been so lazy about it that now I need to port it to D7 before finishing. :-)

what about your project ?

ssm2017 Binder's picture

hello
i am actually testing a complete revamp of sluser.
i would like to completely rewrite the module to allow it to use multiple grids and in the same time, simplify the code (i am learning drupal dev with sluser :))
in the same time, im wondering if i keep the same name and module or if im creating a new one without sl in the name like vw-avatar....

i can read here that you are building a project.
will it be free/opensource ?
i would like to knnow if this will be a sluser killer, so in this case, i can concentrate on other projects than sluser and if not, i can go on :)

I would suggest a new module nameh

atate's picture

I would suggest a new module name like vw-avatar, rather than fixing SL in the module name itself.

The original plan was to get

mile23's picture

The original plan was to get the bugs out, launch with a web site that might make me a little money, and then open-source it. I don't think that's the plan any more.. :-) Linden Lab's current shoot-self-in-foot business plan took away all the momentum for me. I think the OS 'small-timers' could benefit.

It's a suite of modules on based on secondlife called metaverse. It's pretty much completely re-written, though it can still use what I'm calling the 'secondlife API.' It's stuck in D6 land, and would require a lot of work to get to D7.

I'll open it up... Let me get it into presentable shape.

Also, I really wish I could subscribe to this group on groups.drupal.org. :-)

thanks for interest

ssm2017 Binder's picture

there are good news and bad news...

bad news

  • im sorry about the linden decision for the education sims if that disturbs your business

good news

  • someone is developing drupal/sl/os modules and tells it :)
  • maybe this code will be opensourced
  • opensim will get more interest with the linden decision...

what i see

i dont know your code
i dont know what your modules are doing
the most important thing is that someone is building drupal modules for virtual worlds and agrees to publish code
you are the second one i see (after Kbahey) :)

sluser rewrite

2 days ago, i began to revamp sluser (i have stopped now before seeing your solution to dont loose time with details)
the actual dev code is here : http://github.com/ssm2017/vw-avatar
actually, only these items are enabled :

  • grids
  • terminals
  • users
  • quick registration
  • regkey validation

the old version was based on a layer above the user drupal object....
so this was not simple to manage.... :)
now, everything is node (i had to do it before :) )

  • grids are nodes
  • terminals are nodes
  • users links (called avatars) are nodes

like that, all the output can be build by "views" module and is simpler to maintain/enhance

something else that is changing is that the user key validation can work in both ways :

  • user can get key on the website and enable it inworld
  • user can get key inworld and enable it on the website

there are a lot of things to complete and enhance...

my idea

i am taking care about 2 projects actually : d4os and sluser
about d4os, i will port it soon to opensim 0.7
i need help to build these projects, maybe you prefear theming, maps, database, forms or whatever subject that you can do :)

if your set of modules are extensions for sluser or a forked enhanced version, we can add it to the old sluser branch and make something new with the new code base.

i have not began to use drupal 7
the time is pushing me to use opensim 0.7 and then, when d4os will work for it, i will be able to think about drupal 7

maybe we can merge our competences to make good tools and provide them for free.
these tools can be used for one of your business projects if needed.

Et voila:

mile23's picture

Et voila: http://github.com/paul-m/metaverse

My approach is quite different. Grid and Region are nodes, implemented in metaverse_node, but the rest is handled in database tables.

For users, there is a metaverse_users table which has a grid ID, UUID, and drupal uid. I really have no idea what kind of nightmare it might be to modify this for d4os.

There's a rudimentary autoreg module, similar to yours.

Have at it, hack away, and please send some happiness back upstream. :-)

about your project

ssm2017 Binder's picture

thank you for publishing
the code is well written and commented
the module is simple and efficient
this is very simple
i have made a link to your repository on the sluser project page

i could see that this layer of user info above the $account object is not a good idea to manage the extensions (to add functionnalities)
i think that everything can be stored in nodes
the new system i have began to do is based on a simpler code and separated functions in modules
the terminal module is only registering terminals, that's all
the user module is only linking user between website and a grid
then everything can be extensions like userpoints, etc...
there need a clean on the lsl side (change the menu library) (and also build other interfaces like web on a prim)

if one day, you think that there can be a good idea to use nodes for users, you can tell me and we can work on it

but if you have another idea, dont hesitate to purpose it

Node vs. not-node

mile23's picture

For one thing, the avatar UUID is user information, not node information, so logically it doesn't go in a node. But the more important thing is: Every time you load a node, all of the modules that use nodeAPI or all the node hooks get a chance to use up memory and slow down execution. So if you list, say, 10 users with 15 avatars between them, then that's 15 nodes you load, which means 15 times that you give all the other modules some execution time.

Honestly I'm not as familiar with D7 as I could be, but we hope that its model of 'entities' and baked-in Views should make this debate go away. This is one reason I put the metaverse module project on hold.

Node vs. not-node

ssm2017 Binder's picture

the concept of the node based system is that there is no extra information for the user account.
users stay clean users and nodes stay clean nodes.
the only info linked, is that the user is the owner of the node (the avatar is changing account ? ok, just change the node owner).
this solution gives the ability to use cck, views etc...

but im interested about your idea too.
i dont know drupal 7 even the "entities" module (and to be honest, i dont understand the concept yet :))

i think that i need to concentrate first on d4os update and then see what can be done for sluser.

edit : im reading that : http://www.istos.it/blog/drupal/drupal-entities-part-1-moving-beyond-nodes :)