tarber.net

Jim's Rants and Raves
  • Home
  • Business
  • InWorldz
  • Grids
  • Second Life
  • Identity
  • About
RSS

Categories

  • Apple
  • Business
  • Controversy
  • Fun
  • Google
  • Grids
  • Halcyon Development
  • Identity
  • InWorldz
  • Islandz
  • Linden Lab
  • OpenSim
  • Politics
  • Privacy
  • Real Life
  • Second Life
  • Technology
  • Trends
  • Twitter
  • Uncategorized
  • Virtual Worlds

Archives

  • July 2019
  • May 2019
  • February 2019
  • January 2019
  • November 2018
  • November 2017
  • February 2017
  • October 2016
  • June 2015
  • March 2015
  • January 2014
  • November 2013
  • June 2013
  • June 2012
  • May 2012
  • February 2012
  • October 2011
  • August 2011
  • July 2011
  • June 2011
  • May 2011
  • April 2011
  • March 2011
  • December 2010
  • November 2010
  • October 2010
  • September 2010
  • August 2010

Blogroll

  • {Absurdly Newfangled Designs}
  • Arabella's Amblings
  • Ayumi Cassini Does SL
  • Coding Horror
  • Dale Innis's Weblog
  • Daniel Voyager's Blog
  • Dwell On It
  • Ele's Little World
  • Hypergrid Business
  • Inworldz Community Rag
  • Inworldz Immersion
  • InWorldz Tech Blog
  • LordGregGreg's Blog
  • My So-called Virtual Life
  • Netpolitik
  • New World Notes
  • News From the Loft
  • Raglan Shire! It's intense!
  • Search Engine Watch
  • SIZZLING SCRIBES
  • SLOG
  • Socially | Mundane
  • sororNishi
  • Telling: Like it Is
  • TGIB
  • The Alphaville Herald
  • The Ephemeral Frontier
  • The Eternal Sunshine of the Metaverse
  • The Imprudence Blog
  • The Rock Party
  • The Second Life of Marx Dudek
  • Uploads from YYZDez
  • Whiskey Shots
  • Zero to Wonderland – Inworldz

Control Panel

  • Register
  • Recover password

LSL Scripter Heaven: InWorldz To Add Simplified Object Communications and Name Registration

Jun18
on 2013/06/18 at 12:46 am
Posted In: Grids, InWorldz, Technology, Virtual Worlds

Introduction

In response to the enhancement suggestion in Mantis #285, there is a second Mantis #2106 which is a proposal for a series of new name registration functions to be used in combination with the functions described in the first discussion.

This blog posting ties it all together.  I tried to update the InWorldz wiki but the format of a wiki is such that each function gets it’s own page, making the overall proposal less readable.  It’s also difficult to distribute a document to the residents of a virtual online community so in the interest of presenting the proposed interface definitions, I’m just going to blog it below.

Note: At this point, this is still just a proposal.  However, it has already undergone four iterations with Mantis users and among the InWorldz developer team, with significant changes each time, but it is now firming up.  That said, if anything leaps out as inadequate or a problem, feel free to raise it as a concern or suggestion.

Summary

The general idea is that we need to be able to send messages addressed to arbitrary prims anywhere on the grid in a fast, efficient and reliable manner.  We should be able to address the recipient prim by it’s key (UUID), but since a new key is assigned when an object is rezzed, we also need some way to look up the current key for an object by some other identifier that is unchanging.  Most people are familiar with the DNS registrations that translate domain names into IP addresses.  This proposal adds a similar standard built-in registration for name-to-key lookups.

Here is a quick summary of the proposed interface:

IW_SCOPE_REGION  0    // this region only
IW_SCOPE_GRID    1    // grid-wide
iwRegisterName(string name, integer scope)
iwDeregisterName(string name, integer scope) // rarely needed
list iwGetRegistration(key ownerKey, string name, integer scope)
  // Returns: [ regionID, primID, scriptID ]
key iwGetRegistrationKey(key ownerKey, string name, integer scope)
  // Returns: primID
integer iwMessageObject(key object, string message)
integer iwMessageRemoteObject(key region, key object, key script, 
            string message)

iwRegionShout(integer channel, string message)

Detailed Description

Below is a more detailed description of each function, along some examples to show general usage.

iwRegisterName(string name, integer scope)

This function registers the current script context under the specified name (alias). This allows an unchanging name to be used to reference a remote prim, rather than the caller needing to know the key of the prim, and even what region it is in.

A name registration context is defined by the current script, the current prim, the region containing the prim, and the owner of the object.  The owner, prim and script are all implicit in the call, so only name to register is required, along with the desired scope for the registration.

Name registrations are always relative to an owner key, and could be either global to the entire grid, or local to the region where the prim is located, depending on the scope parameter. This can have one of the following values:

IW_SCOPE_REGION – name registered for return by queries in this region only
IW_SCOPE_GRID – name is registered grid-wide for any script that queries the name

Note: There can only be multiple instances of the registered name per user if IW_SCOPE_REGION is used (although still only one per region). This is because any new registration will replace the existing older registration.  A new IW_SCOPE_GRID registration will replace all IW_SCOPE_REGION registrations.

Important: There is no need to re-register at regular intervals, and normally it is not necessary to deregister a name.  The name registration will be removed if an object containing a name registration is deleted or leaves a region. However, if a prim enters a new region, the previous registration will be removed, therefore the script must register again in the new region, so that scripts that query the name can find it in the new location.  That said, if it is desirable to have a remaining prim no longer be found using iwGetRegistration, the script can call iwDeregisterName.

Examples:

The following examples demonstrate the basic usage of iwRegisterName:

iwRegisterName(“Danceball Rezzer”, IW_SCOPE_REGION);
or
iwRegisterName(“Upgrade Server”, IW_SCOPE_GRID);

iwDeregisterName(string name, integer scope)

This function removes the registration that corresponds to the specified name (alias) and scope.  Most scripts do not need to call this function.  It is provided to complete the needs of the script author.

Note: Name registrations will automatically be removed when the script context is no longer valid, i.e. if the object containing the script that registered the name is no longer in the region. This can happen if the object containing the script is deleted, or crosses into another region.

list iwGetRegistration(key owner, string name, integer scope)

This function queries a name registered using iwRegisterName.  Given the owner of the object in question, and the original name and scope, it will return a list containing the information needed for a call to iwMessageRemoteObject.

The following example queries the name registration information in the two example cases in iwRegisterName above:

key region;
key prim;
key script;
list info;
info = iwGetRegistration(llGetCreator(), 
           “Update Server”, IW_SCOPE_GRID);

or

info = iwGetRegistration(llGetOwner(),
           “Danceball Rezzer”, IW_SCOPE_REGION);

Note: The script can query registrations for other owners.  This is useful for a script querying an object of its creator, e.g. after an inventory transfer to another user.  The case above uses an update server as an example of this.

Here is an example of how to extract the information returned from iwGetRegistration:

key region;
key prim;
key script;
list info;
info = iwGetRegistration(llGetCreator(),
           “Update Server”, IW_SCOPE_GRID);
region = llList2Key(info, 0);
prim = llList2Key(info, 1);
script = llList2Key(info, 2);

These three values represent the script context of the name registration, and are the required context for iwMessageRemoteObject.

key iwGetRegistrationKey(key owner, string name, integer scope)

This function queries a name registered using iwRegisterName.  However, unlike iwGetRegistration, this function only returns the key of the prim of the registration context. This is a convenience function for users of iwMessageObject, since it is simpler than retrieving a list and extracting only the second list item.

Given the owner of the object in question, and the original name and scope, this function will return the object key needed for a call to iwMessageObject.

integer iwMessageObject(key object, string message)

This function sends an arbitrary string message to an object in the same region. To do so, the sending script must know the key of the destination prim to send the message to. The object key can come from any of the traditional sources, such as llRegionSayTo, listen events, collision events, sensor replies, etc. It may also come from a call to iwGetRegistration.  The parameters other than the message itself correspond to the three context values stored and returned by iwGetRegistration.

Here is a simple practical example:

key prim = iwGetRegistrationKey(
               llGetOwner(), “Danceball Rezzer”, IW_SCOPE_REGION);
iwMessageObject(prim, “The message.”);

integer iwMessageRemoteObject(key region, key object, key script, string message)

This function sends an arbitrary string message to an object, anywhere on the grid. To do so, the sending script must know the keys of the destination region, the destination prim, and optionally a script to send the message to in that destination prim.  The parameters other than the message itself correspond to the three context values stored and returned by iwGetRegistration.

Here is a simple practical example:

list info = iwGetRegistration(
              llGetCreator(), “Update Server”, IW_SCOPE_GRID);
key region = llList2Key(info, 0);
key prim = llList2Key(info, 1);
key script = llList2Key(info, 2);
iwMessageRemoteObject(gRegion, gPrim, gScript, message);

Note: The region parameter is optional and if NULL_KEY is passed, the current region is assumed.  Similarly, the script parameter is optional and if NULL_KEY is provided, the message will be sent to all scripts in the target prim.  This is less secure than specifying the target script, as it allows a “listener” script to be added to the receiver prim if the object is modifiable.

Important: The examples so far do not use it, however iwMessageRemoteObject provides a non-zero return code on error.  This allows for automatic recognition of errors on sends, and is a sign to query for an updated destination context.

Single-attempt retry logic for iwMessageRemoteObject is fairly simple:

list info = iwGetRegistration(
              llGetCreator(), “Update Server”, IW_SCOPE_GRID);
key region = llList2Key(info, 0);
key prim = llList2Key(info, 1);
key script = llList2Key(info, 2);
integer rc = 
      iwMessageRemoteObject(gRegion, gPrim, gScript, message);
if (rc != 0)
{
    llSleep(5.0);  // short delay before retrying
    info = iwGetRegistration(
             llGetCreator(), “Update Server”, IW_SCOPE_GRID);
    region = llList2Key(info, 0);
    prim = llList2Key(info, 1);
    script = llList2Key(info, 2);
    iwMessageRemoteObject(gRegion, gPrim, gScript, message);
}

It gets a bit more involved if the desire is to provide multiple retries, however the following example is a more production-ready example that includes error handling and retry logic:

// Sends a message to the prim registered with 'destName'.
// Returns TRUE if the message could be sent, FALSE otherwise.
integer SendMessage(string destName, string message)
{
  key region = NULL_KEY;
  key prim = NULL_KEY;
  key script = NULL_KEY;
  integer rc = -1;  // force it into the loop the first time
  integer retries = 5;

  while (rc != 0)
  {
    if (prim != NULL_KEY)
    { // if not the first time through the loop
      rc = iwMessageRemoteObject(region, prim, script, message);
      if (rc == 0)
      return TRUE;  // successfully sent
    }
    if (retries == 0)
      break;  // give up

    if (prim != NULL_KEY)  // message failed
    {
      // back off and wait for the registration to update
      retries--;
      llSleep(5.0); 
    }

    // we need to query the registration for
    // an updated (or initial) value
    list info = iwGetRegistration(
                  llGetOwner(), destName, IW_SCOPE_GRID);
    gRegion = llList2Key(info, 0);
    gPrim = llList2Key(info, 1);
    gScript = llList2Key(info, 2);
  }

  // retries exhausted
  return FALSE;
}

iwRegionShout(integer channel, string message)

The changes in this proposal include fixing local chat operations (e.g. user chat and llSay and its variants) to extend across region borders with the usual chat range rules.  However, sometimes it is useful for scripts to be able to communicate with other objects anywhere in a region, regardless of range. For this reason, llRegionSay was created.

This function extends llRegionSay to have a longer range, just as llShout extends llSay.  In this case, iwRegionShout will be a chat broadcast that can be heard by listeners in the region containing the script or any of its immediate neighbor regions.  In other respects, it has the same semantics as llRegionSay, including the restriction of not being able to use channel 0.

 

Conclusion

These proposed functions would fill a fairly large gap in functionality, and reduce the need for complex solutions developed externally.  It is hoped that these proposed functions might set a new standard for easy and reliable scripting of communications between in-world objects, making it more accessible to novice scripters and making networked products more reliable in InWorldz.

However, it is important to remember that they are subject to change at any time during implementation and may yet evolve before finally appearing on the main grid.  They are expected to be completed over the next week or two and available soon on the InWorldz beta grid.  They are expected to be available on the main grid sometime in the next two or three grid updates.

Comments Off on LSL Scripter Heaven: InWorldz To Add Simplified Object Communications and Name Registration

KFNX Responds – Barbara Espinosa Loses Her Show

Jun22
on 2012/06/22 at 12:41 am
Posted In: Controversy, Politics

You’ve probably heard the story of Barbara Espinosa, who ran a radio talk show with the former Arizona GOP chairman Randy Pullen called “Hair on Fire”, who recently gained international attention when she called U.S. President Barack Obama a “monkey”.  Repeatedly.  She then followed that with “I voted for the white guy.”

Arizona GOP Radio Host Calls Obama First Monkey President

Here is a longer MP3 recording of this mess, which includes the rejection of these comments by another caller, followed by both callers hanging up:

Hair-on-Fire-News-Talk-Radio-030112.mp3

Fortunately, at 1:58 in this recording, the other caller completely rejects Espinosa’s comments.  And that ends that.

I contacted the radio station where the broadcast was believed to have taken place.  They report that the host in question “does not host a show anymore” at that station, and that the show in question may have happened elsewhere since she has not worked there in a month.  However, based on the filename of the recording, which has the suffix “030112.mp3” and would appear to be a date, it would seem that this is a recording of a show that aired months ago, when it would have most likely aired on KFNX.

In their response, the station has clearly moved to distance itself from Espinosa and the controversy:

KFNX no longer has a relationship with Ms. Espinosa, and again certainly does not support her comments. If those comments were made on KFNX, we would have terminated our relationship with her. We certainly apologize for our former relationship with Ms. Espinosa and are deeply sorry she said offensives things.

Here is the full text from KFNX:

Statement from KFNX 1100 RE: Barbara Espinosa (6/18/2012)

KFNX received your email. Barbara Espinosa does not host a show anymore on KFNX 1100, so the information is dated. She has not aired a show at KFNX for nearly a month. She currently hosts an internet show on Blogtalk radio to the best of our knowledge.

KFNX management, staff and sponsors do not endorse or agree with her viewpoints. Ms. Espinoza (like all KFNX Hosts) does have the First Amendment Right to say what she believes, but KFNX Host Contracts includes a clause which prohibits on-air slander of people.

KFNX no longer has a relationship with Ms. Espinosa, and again certainly does not support her comments. If those comments were made on KFNX, we would have terminated our relationship with her. We certainly apologize for our former relationship with Ms. Espinosa and are deeply sorry she said offensives things.

We do not know when the comments were made, but it is possible they were made in the past while airing on KFNX, or maybe could have been said on her current internet show on Blogtalk. We also do not know who posted the YouTube video. It is an edited video (and not dated), so it is unclear what context the improper comments were made.

If you want more information, we suggest you contact Ms. Espinosa (or Blogtalk) directly regarding this.

Again we apologize for any inconvenience.

Sincerely,

KFNX Management

 

2 Comments

Understanding Parcel Rezzing Permissions

May18
on 2012/05/18 at 9:43 pm
Posted In: InWorldz, Second Life

Reports of Trouble

Recently, I have heard reports of InWorldz residents complaining that permissions seem to have become broken, or that objects that used to work no longer do.  In addition to the dance ball rezzer products people buy “no longer working”, prefab home rezzers, furniture with MLP engines that rez balls, and other products can’t seem to rez the items they need to function.

Here’s an example.  I received this message:

Hi ya Jim, do you have any idea what this error message means? My alt gets it when she tries to rez one of my products from its rezzer.  Everything is set to Mod/Copy, permissions look good:

(product): Unable to create requested object. Object ‘(thing to rez)‘ lacks create object permission or parcel full.

What Has Changed

First, let me point out here that the permissions system in InWorldz is functioning properly and also that it is behaving exactly the same as Second Life™ in this regard.

In previous releases however, this was not the case.  InWorldz did not properly check the permissions of objects rezzed by scripted objects.  Now it does.

Also, with the latest release, there is a full implementation of parcel-based, region-wide prim limits.  Thus the “or” in the error message above.  There are two cases for failing to rez a prim from an object within a given parcel now: either the owner doesn’t have enough available prims in that region, or the object doing the rezzing does lacks the require permissions.

Here’s How To Fix It

The prim limit case is obvious enough, and can be checked by looking at About Land to see how many are available.

The more complicated case is rezzing permissions.  The error, in this form, comes from an object: (product) in the example above.  It’s trying to rez an object from its Contents, named (thing to rez) in the example above.

If that is being refused, something is not quite set correctly. Either:

– the land isn’t set to allow everyone to rez, or

– it’s set to allow object creation by group members, but the rezzer isn’t set to the correct group, or

– it’s not set to allow group object creation at all.

It’s actually pretty simple: to rez objects, you have to be the owner of the land (which in the case of group-deeded land would be a group-deeded object), or the object must be set to the correct group to match the land with object creation enabled for group members, or enabled for everyone. So:

  1. Check About Land, looking particularly on the Options tab at the two “Create Objects:” checkboxes.  It’s “normal” to have the first one unchecked (disabled for All Residents) and the second one checked (enabled, for group use).
  2. Then if you want to enable group members to create objects, make sure that the land parcel has a group assigned (see the first tab on About Land).
  3. Then make sure that the rezzer object has its group set to that group.

If you don’t enable object creation for either everyone or group members, then only the owner can rez objects. And that also means that if you have deeded the parcel to a group, then only group-deeded objects can rez other objects.  (Because then the object’s owner (the group) is the same as the land (the group).)

Note that “normally” you do NOT have to deed objects to the group to allow them to rez other objects.  You just need to set a land group, and enable rezzing for group members, then set the rezzer to that group.  You only need the extra step of deeding the object if you have disabled object create for group members.

Comments Off on Understanding Parcel Rezzing Permissions

Unbelievable New Mobile Phone – Everything in One Place

May03
on 2012/05/03 at 6:11 pm
Posted In: Fun, Real Life, Technology

Check out this amazing phone. You won’t believe it.  If you haven’t seen the Pomegranate Phone yet, you better check this out.

http://www.pomegranatephone.com/

As I type this, I’m sitting in my new home in Nova Scotia, Canada, after being away for 28 years. It feels great to be home.

The Pomegranate Phone has solid ties to Nova Scotia, so it makes me proud to see what they’ve done on this web site.  It’s a deep site with lots of content, videos, interviews, etc.

After the intro, there’s a list of features on the right. Check them out!

Tranq will like the coffee-related features. Yes. And everyone will love the projection capabilities.

When you’ve seen enough, check out the Release Date link at the top for more info.

From there, be sure to check out the Surfer Girls link, an example of the content depth of this site. There’s a manager from Cisco in California on that video too.  😉

o..O

1 Comment

Understanding Scripted Region Crossings

Feb29
on 2012/02/29 at 1:50 am
Posted In: Controversy, Grids, InWorldz, Linden Lab, Second Life, Technology, Trends, Virtual Worlds

Over on Inara Pey’s blog posting on region crossings by vehicles, Pussycat Catnip added a comment that asked the question:

Are there really Open Sims that -lack- this ability?  I’d just assumed this was as standard as the ability to rez-in your own avatar… (ie: logging in).

I started to post a reply there, but after seeing the length, I did not want to hijack that blog posting in any way. So here is my answer here:

No, to the best of my knowledge, all OpenSim grids have lacked this ability until now, unless you include InWorldz.  It’s a very significant thing, and was in also a big accomplishment by Linden Lab when they provided this for MONO scripts in Second Life.  But it’s not really anything to do with physics, or vehicles.  It’s about transitioning a running script (in anything) from one region to another.  The explanation is a bit long; my apologies.

The Script Continuation Problem

When SL went with the .NET/MONO runtime environment, they forego the ability to control scripts very closely, since the runtime environment was developed by a third party.  But during a region hand-off, they need complete control.  They need to be able to stop scripts running in one virtual runtime, transmit them to another region, and load them in an object on that region, and not restart the scripts, but rather continue them from where they left off. So it’s just not a matter of re-rezzing a new copy of the same thing on another region; it must restore a copy of that object with the scripts running in the same context as they were when the object hit the region border.  All the active data, the current state of the script’s execution contents, must be restore and continued from where it left off.  For example, before this, in OpenSim, scripts were restarted (from their beginning, losing their current context) after a TP or region crossing.  InWorldz achieved this continuation of scripts with the introduction of the Phlox script engine last summer, but it was not possible in OpenSim until now.

Linden Lab’s Solution

When Linden Lab implemented this before any of the alternative grids, there was no ability to get this execution context from the third-party runtime environment (MONO). So Linden Lab developers effectively had to become MONO developers, and provide significant hacks, er, I mean extensions, to the MONO project.  Which then effectively meant they were running their own variant of MONO.  (I’m not aware of how extensive or localized the changes were from the standard tree.)  It was a lot of hard work, but they eventually provided the hooks in MONO that they needed to pause running code (MONO scripts compile to native code), and to serialize the data into a stream that could them be fed to the next region, deserialized, and reapplied to a copy of the object on the other region.  That was a lot of work and I’m sure when they started, they probably weren’t really sure to what degree their success would be.

InWorldz’ Solution

When InWorldz chose to attack this problem about a year ago, they chose a completely different path. They chose to create their own Phlox Script Engine runtime environment as a virtual machine, providing whatever hooks were needed as an inherent part of the design of that virtual machine.  Then compile LSL (or any language desired) into the intermediate p-code that their own virtual machine understood.  Not only does this keep control of the runtime environment for scripts within the InWorldz development project, but it allows much easier extensions in the future, much MUCH better processor consumption and memory management, and complete control of scripts.

One of the planned side-effects of this Phlox design is direct control of hand-offs between regions.  These can be done *so* efficiently that some naysayers actually complain that videos of crossings (here and here) must have been doctored, or faked in some way.  It’s that good.  Vehicles are just one example of script crossings. Physics really doesn’t play into this much.  If you can walk across regions, you’ve performed complex crossings of physical objects.  The tricky part is having the scripts continue where they left off, uninterrupted, and this includes vehicle scripts (and a lot more).

Avination and OpenSim Milestone

This is why I give credit to Avination for their recent success in the major work item of script state persistence across region crossings.  The vehicle part of it isn’t really the big deal here.  Having true continuation of active scripts on the other side is a Big Deal.  This is also a key part of why I found the “first” claim by Avination to be so outrageous; InWorldz has had vehicle crossings since the Phlox runtime environment came online last summer.  Even in terms of physical vehicle crossings, InWorldz has had ODE physics (same as other OpenSim grids) since before InWorldz was founded.  However due to its ability to cause region crashes, it has been disabled for about a year (out of InWorldz’ 3 year history).  If InWorldz simply turned physical objects back on, physical vehicle crossings would have been possible since the introduction of Phlox; the hard part, and the part Avination just completed, was the persistence of the scripts across the crossings, and that was fully functional and available grid-wide in InWorldz last summer.

However, since the Linden Lab proprietary implementation, another third party developer has provided an implementation of continuations in MONO, which has been available since MONO 2.6.  This provides the context save/restore needed, and Avination has successfully applied that to the OpenSim runtime. That’s great news for MONO-based script engines in OpenSim.

Thinking Ahead

In the long run, I see moving away from MONO as the best (and perhaps the only) way to tame processor and memory use and provide complete control of the runtime environment. Phlox will provide that total control, which means more features. Things like much easier support for new languages, an LSL debugger that can be built-in to the viewers to allow single-stepping through LSL code and examination of variables at each stage, easier control over scripts CPU and memory usage, and many other secondary benefits, such as no need to try to limit script cost artificially and blame script authors for hurting sim performance.

But the bottom line here is that continuing a script in a new region, running on a completely different machine (IP address) is a Big Deal.  Physical objects, a vehicles, not so much, but persisting those scripts, hell yes.  It’s a major accomplishment, and now OpenSim has it too.

14 Comments
  • Page 4 of 10
  • « First
  • «
  • 2
  • 3
  • 4
  • 5
  • 6
  • »
  • Last »

Translate This Page

Recent Comments

  • tarber.net » Update on OAR Exports on Loading exported InWorldz OAR files under OpenSim
  • tarber.net » Update on OAR Exports on Requesting OARs for InWorldz Regions
  • tarber.net » Requesting OARs for InWorldz Regions on Personal Changes
  • Jim Tarber on Focusing Methods – Getting Stuff Done
  • Jim Tarber on Google+ and the Huge Privacy Disappointment

Blogroll

  • Icon The Rock Party

    Close preview

    Loading...
  • Icon Arabella's Amblings

    Close preview

    Loading...
  • Icon Ayumi Cassini Does SL

    Close preview

    Loading...
  • Icon Coding Horror

    Close preview

    Loading...
  • Icon Dale Innis's Weblog

    Close preview

    Loading...
  • Icon Daniel Voyager's Blog

    Close preview

    Loading...
  • Icon Dwell On It

    Close preview

    Loading...
  • Icon Ele's Little World

    Close preview

    Loading...
  • Icon Hypergrid Business

    Close preview

    Loading...
  • Icon Inworldz Community Rag

    Close preview

    Loading...
  • Icon Inworldz Immersion

    Close preview

    Loading...
  • Icon LordGregGreg's Blog

    Close preview

    Loading...
  • Icon The Eternal Sunshine of the Metaverse

    Close preview

    Loading...
  • Icon New World Notes

    Close preview

    Loading...
  • Icon News From the Loft

    Close preview

    Loading...
  • Icon Raglan Shire! It's intense!

    Close preview

    Loading...
  • Icon Search Engine Watch

    Close preview

    Loading...
  • Icon SIZZLING SCRIBES

    Close preview

    Loading...
  • Icon SLOG

    Close preview

    Loading...
  • Icon Socially | Mundane

    Close preview

    Loading...
  • Icon sororNishi

    Close preview

    Loading...
  • Icon Telling: Like it Is

    Close preview

    Loading...
  • Icon The Alphaville Herald

    Close preview

    Loading...
  • Icon The Ephemeral Frontier

    Close preview

    Loading...
  • Icon The Imprudence Blog

    Close preview

    Loading...
  • Icon Uploads from YYZDez

    Close preview

    Loading...
  • Icon Whiskey Shots

    Close preview

    Loading...
  • Icon Zero to Wonderland - Inworldz

    Close preview

    Loading...
  • Icon {Absurdly Newfangled Designs}

    Close preview

    Loading...
  • Icon My So-called Virtual Life

    Close preview

    Loading...
  • Icon The Second Life of Marx Dudek

    Close preview

    Loading...
  • Icon TGIB

    Close preview

    Loading...
  • Icon InWorldz Tech Blog

    Close preview

    Loading...
  • Icon Netpolitik

    Close preview

    Loading...

©2010-2019 tarber.net | Powered by WordPress with Easel | Subscribe: RSS | Back to Top ↑