Unified Passwords and a Login Fallback Option

We updated our system today with several improvements that make it easier to login to the Kitely grid.

Unified Passwords

Some Kitely users have two passwords: a Grid password, used to login from the viewer; and a Website password, used to login to the Kitely website. (If you signed up to Kitely using your Facebook or Twitter account then you don’t have two passwords, so this section isn’t relevant to you.)

Keeping track of two passwords can be confusing, and quite a few people had problems logging into the grid because they changed their website password when they had intended to change their grid password. We’ve therefore decided to unify these two passwords: now the same password will be used to login to both the Kitely grid and to the Kitely website.

This change will only affect future passwords; not existing passwords. This means that for existing users, your passwords have not changed; you can keep using Kitely as you usually do. This change will only make a difference if you decide to change your password in the future: at that time, the new password that you choose will be set as both your Grid password and your Website password.

Login Fallback Option

When you try to login to the Kitely grid from the viewer, sometimes the world that you want to enter isn’t available. This can happen if the world was deleted; or if its permissions don’t allow you to visit it; or if the world has been suspended.

Until now, when such problems occurred we showed you an error message in the  viewer’s main screen and prevented you from logging into the Kitely grid. You therefore never got to enter the grid, which is annoying. Today’s update solves this problem: now, when you enter valid login credentials (username and password), we always let you log into the Kitely grid. If you can’t log into your desired destination then we send your avatar to the Kitely Welcome Center instead. Once you’re there you can teleport to other worlds, talk to people, etc.

Other Changes

Based on user requests, we fixed the LSL function llGetWallclock to return the current time in the PST timezone.

Performance Improvements and Bug Fixes

We updated the system today with several performance improvements, and fixed some OpenSim bugs that were reported by our users.

We’ve updated Kitely to OpenSim This is a minor change, after last week’s update to OpenSim 0.8.2.

We improved the performance of our cloud-based inventory system for users with very large inventories. Your avatar’s inventory should now load faster in the viewer.

We fixed a bug that caused regions in big worlds to appear Offline in the World Map. Those regions weren’t really offline; they just looked that way on the map. Now they are properly displayed as being online.

We fixed a bug that, on rare occasions, caused teleports to high coordinates of a big world to result in the avatar being teleported to location (128,128).

One of the most advanced LSL functions is llCastRay. OpenSim now supports two versions of llCastRay: v1 and v3. We’re currently using v1, which is the default. However, we’re considering switching to llCastRay v3. If you’re currently using llCastRay then please join this forum thread and let us know what you think. If you’re a world owner then we can selectively switch your world to use llCastRay v3, if you’d like to test it.

When evaluating the alternatives to llCastRay, please test two aspects: 1) Is v3 faster or slower than v1? 2) Is v3 more or less correct than v1 (i.e., does it identify the hit objects correctly)?

VarRegions, 10x Faster Object Contents, and More Fonts

We updated our system today with several big changes, including upgrading to OpenSim 0.8.2 Release; converting all the big worlds to VarRegions; and 10x faster loading of object contents.

OpenSim 0.8.2 Release

We upgraded to OpenSim 0.8.2 Release. We were already using OpenSim 0.8.2 Dev, so most of the features in OpenSim 0.8.2 have already been included in Kitely. However, there are still a few changes:

The new version of OpenSim has changed the format of compiled scripts. Therefore, all of the scripts in Kitely need to be recompiled. The first time that any world is started after this update, it will spend some time recompiling its scripts. During this time the world will perform slower than usual, and scripts will be slow to start. This will take a few minutes, and it will only happen once.

The value shown for Physics FPS has changed. It used to be around 55 fps, but for a while OpenSim switched to a different way of showing frame rates, which caused the Physics FPS to show around 11 fps. That change has been unpopular so it was reversed, and now OpenSim shows a Physics FPS around 55 again.

In avatars’ inventories, the “# Kitely Market” folder will now appear near the bottom of the inventory instead of at the top. This is due to a change in how OpenSim handles inventory folders.

A new OSSL function has been added: osGetAvatarHomeURI. It returns an avatar’s Home URI, i.e. the address of its home grid.

Converted All the Big Worlds to VarRegions

All the big worlds (worlds with more than one region) are now VarRegions. See our previous blog post for more information.

10x Faster Object Contents

Don’t you hate it when you click on an object to view its contents, and you’re stuck looking at “Loading contents…” for a long time?

Loading Contents

To fix this, we have significantly improved loading the contents of an object:

First, we’ve improved the reliability of this operation, so the “Loading contents…” message should always disappear eventually, and the contents of the object will appear. (Previously, sometimes the contents never appeared, no matter how long you waited.)

Second, we vastly improved the speed of loading object contents. To test this, we created an object with a large inventory (95 items). In regular OpenSim (and in Kitely before today’s update), loading this object’s contents took 16.0 seconds. After this update, loading the contents takes just 3.5 seconds, a 78% reduction!

But wait, there’s more! Viewers have a debug option called XferThrottle, which can be tweaked to get even more speed. The default value of this option is 150000. If you increase it to 500000 then the time to load the object’s contents drops even more: to 1.6 seconds. So in total, Kitely has reduced the time to load the object’s contents from 16.0 seconds to 1.6 seconds, which is ten times faster than regular OpenSim!

Here’s how you can change the XferThrottle option:

  • Start the viewer
  • Make sure the “Debug” or “Advanced” menu is visible (either name might be used). If the menu isn’t visible then press Ctrl+Alt+D to show it.
  • Select from the Debug or Advanced menu: “Debug Settings” or “Show Debug Settings”
  • In the Debug Settings dialog: type “XferThrottle”
  • Enter the value you want
  • Restart the viewer (this is required)

Here’s what the Debug Settings dialog looks like in Firestorm:


Two final notes: First, increasing XferThrottle above 500,000 doesn’t reduce the loading time any more. Second, increasing XferThrottle doesn’t reduce the loading time in regular OpenSim, because it’s too slow to take advantage of this setting.

Other Changes

We upgraded to Mono 4.2.1, which should be slightly faster than the version of Mono we used before today’s update (3.10).

We installed additional fonts on our servers, which you can use in scripts. See this forum thread for more information. Some of the new fonts include: Zapf Chancery, Arial Black, Comic Sans MS, Impact, and the ever-popular Webdings.

We fixed a search bug: if a world name contained a common word such as “of” or “in”, and you searched for the world using that word, then the world wasn’t found. Now it will be found. (To be clear, it’s not possible to search just using such short words. But it’s possible to include them in addition to more substantial words. E.g.: you can search for “state of”, but not just for “of”.)

We changed the default viewer that we offer to new users to Firestorm 4.7.5.

Big Kitely Worlds Will Soon be Converted to VarRegions

Kitely supports worlds that have more than one region. Currently, such worlds can be run in one of two modes (selected by the world manager): Multi-region, or Advanced Megaregion. This will change on December 9, 2015: these worlds will be converted to VarRegions, and the option to run worlds in Multi-region or Advanced Megaregion mode will be removed.

This post explains why we’re making this change, and how it will affect you.

Historical Background

Three years ago OpenSim supported two ways to create big worlds: 1) By placing multiple separate regions next to each other: this is called “Multi-region mode”. 2) By combining multiple small regions into a single big region, called a “Megaregion“.

Multi-region mode suffered from many problems. First, there were slowdowns and errors when avatars and objects (including vehicles) crossed region borders. Second, it was wasteful in server resources, making worlds operate slowly. Megaregion mode was more efficient in using server resources, although still not great. It didn’t suffer from region crossing problems, but it did have other limitations that prevented it from being a good alternative to multi-region mode. Kitely’s solution was to develop Advanced Megaregions, which were both more efficient than regular megaregions, as well as solving many of their limitations.

Two years later, at the end of 2014, OpenSim 0.8 introduced a third option for creating big worlds: VarRegions. VarRegions behaved similarly to Kitely’s proprietary Advanced Megaregions, but they had some important limitations. First, they didn’t support the ODE physics engine, which Advanced Megaregions did support, and that was then (and still is) the most dependable OpenSim physics engine. Second, they required all users to upgrade their viewers, since older viewers didn’t support VarRegions. Third, they were less flexible than megaregions in selecting region settings for big worlds. We therefore decided that it was premature to switch Kitely from using Advanced Megaregions to using VarRegions.

Recently, however,  OpenSim 0.8.2 was released, and it has fixed the biggest problem with VarRegions, by allowing them to use ODE. In addition, OpenSim 0.8.2 has deprecated support for megaregions.

Since Kitely’s Advanced Megaregions depend on a part of OpenSim that is no longer maintained, we were left with two options: either we keep the old code, thus making it hard for us to remain compatible with future OpenSim releases; or we migrate all Kitely Advanced Megaregions to use VarRegions, and thus maintain our ability to remain compatible with the standard OpenSim branch. We chose the second option.

Upcoming Changes

The switch to VarRegions will have the following effects:

(This affects only worlds with more than one region.)

All big Multi-region and Advanced Megaregion worlds will be converted to VarRegions. The option to switch between Multi-region and Advanced Megaregion mode will be removed. This means that even if you didn’t use Advanced Megaregion mode before the upcoming change, your big worlds will still be converted to VarRegions.

Importing an OAR file that contains multiple regions saved in Multi-region or Megaregion mode will result in the contents of the OAR file being automatically converted to use VarRegion mode. Exporting big Kitely worlds will always create a VarRegion OAR file.

The region settings of the root region will now be used in the entire big world. This will happen regardless of whether that big world had used Multi-region mode or Advanced Megaregion mode. These settings include terrain textures, water height, etc. This means that if you had set different region settings for different parts of your big world, then the settings for all of the regions except for the root region will be lost. The settings in the root region will be used throughout your world.

Some landmarks might stop working, although this should be rare. Landmarks that were created in a non-root region of a Multi-region world will stop working, because those regions won’t exist anymore. Landmarks for the root region, as well as any landmarks that were created in an Advanced Megaregion world, will continue to work. Since most big Kitely worlds are using Advanced Megaregion mode, this change should have very little effect on most of the landmarks that people have created in Kitely.

Things That will Remain the Same

All other world management features provided in your Kitely account control panel will remain. This includes the ability to change world sizes, change the physics engine, etc.

What you Need to Do

Most people don’t need to do anything.

If you want to have a backup of your world in Multi-region or Megaregion mode then you need to Export your world before the upcoming change. This will create a Multi-region or Megaregion OAR file. You’ll still be able to export your world after the change, of course, but at that point the OAR file will use VarRegion mode.

Improved Offline IMs and Friend Requests

We updated Kitely today with a few bug fixes that should solve several problems that people reported in our forums.

We fixed a couple of problems that happened when you entered a world through a Transfer Station, but spent only a very short amount of time in the Transfer Station. First, if you had pending Offline IMs then the notification about these IMs wasn’t shown. Second, if you had pending friend requests, then although these requests were shown, clicking Accept or Decline didn’t actually take effect. The reason for both of these problems was that the viewer got confused because you switched worlds too quickly. The fix is that we simply don’t send these notifications while you’re in the Transfer Station anymore: we wait until you arrive at the destination world and only then do we send these messages.

Today’s update also includes a bug fix that should solve the problem that caused Kitely to become unresponsive a few days ago.

And finally, we increased the maximum range in which we show Kitely Market analytics to 3 years. It was originally set at 2 years, but Kitely Market has now been operational for longer than that :)

A Minute of Your Time Can Help Bring More People to Kitely

The website Hypergrid Business is now holding its sixth annual OpenSim grid survey. Please help us attract additional people to the Kitely community by answering this short multiple choice survey.

Last year many of you participated in the survey and, as a result, Kitely came out on top for “Best Technology” with a close-to-perfect score of 4.95. Your support helped Kitely attract more users and keep its position as the leading commercial provider of Hypergrid-enabled regions. It also helped convince content creators to list their items in Kitely Market, and now there are more than 11,000 product variations listed in our marketplace, making it the biggest marketplace serving the Hypergrid. Your continued support is crucial for helping us grow both our marketplace and the Kitely user community.

Please take the time to complete this survey. Thank you!

Maintenance Release

We updated the system today with several bug fixes and features that were requested by our users.

In the previous update, we enabled world managers to monitor world performance and shut down their active worlds by clicking “Stop” in the World Page. We’ve now added a confirmation dialog before stopping the world, to prevent shutting down worlds by accident.

We’ve updated the default viewer that we provide on our website to Firestorm 4.7.3.

We now allow links to YouTube and Flickr in Kitely Market product listings.

We fixed the following bug: if a user had set his or her Home region to a Megaregion, then attempting to go Home from another grid would fail. Now it will succeed. Users who have set their Home region to a Megaregion should set it again. (It’s okay to not do this, but in that case going Home will only work inside Kitely, but not from other grids.)

Monitor World Performance

We added a new tool for monitoring world performance. We also wrote a new guide for detecting and fixing world performance problems, and added an option to manually stop a running world.

Monitor World Performance

OpenSim provides world owners with the freedom to create large worlds with many prims and complex scripts, but this freedom can come at the cost of performance. As a world owner it’s important to make sure that your worlds perform well, because slow worlds cause a bad user experience: the world appears slowly around the user; animations are choppy; and moving in the world is frustrating because the avatar appears to jump from place to place instead of moving smoothly.

You can now check the performance of your world using the Active World panel, which appears in the world’s World Page while the world is active. This panel contains the following information:

  • Active Time – how long the world has been active in the current session.
  • Visitors – the current number of avatars in the world.
  • CPU (Number) – the current CPU usage of the world.
  • CPU (Graph) – a history of the CPU usage.
  • Packets (Graph) – the number of networking packets sent between the world and the viewers that are connected to it.

Active World

The graphs appear shortly after the world has started, and they update automatically every 30 seconds.

  • In both graphs, the horizontal axis shows the time (in the UTC time zone).
  • In both graphs, the left vertical axis shows the number of visitors in the world. This statistic is drawn using the yellow line.
  • In the CPU graph, the right vertical axis shows the CPU usage.
  • In the Packets graph, the right vertical axis shows the number of packets.

These graphs make it easy to see how the number of visitors in the world affects the CPU and bandwidth usage. It’s natural for worlds to use more CPU resources as the number of visitors increases. However, if the world is using a lot of CPU resources even when it has few visitors then the world probably needs to be optimized.

Stop world

You can use the Stop world link to force the world to stop. This is rarely needed, since worlds automatically stop a few minutes after the last visitor has left them. However, sometimes you might believe that the world is behaving badly and you want to restart it, and in that case stopping the world explicitly saves the normal delay that occurs between the time that the last visitor has left the world and when the world is stopped. This also enables you to stop a world even if there are avatars inside it.

Stopping a world is also useful for fixing the rare error of “ghosted avatars”. Avatar ghosting occurs when the simulator fails to detect that a user has closed their viewer. This leaves their avatar in the world, and prevents them from entering it again. Restarting the world removes the ghosted avatar.

After the world has stopped, enter the world again in order to restart it.

A Guide for Optimizing World Performance

We wrote a detailed new guide that describes all the tools available for checking the world’s performance, and how to fix various performance problems. See: Optimize World Performance. The guide contains the information that was included in this blog post, and much more.

If you see that your world is using a lot of CPU then you should consult this guide to find how to make the world perform better, which will improve the experience of your visitors.

New Tools for Fixing Slow Scripts

We updated our system today with several new features. First, we vastly improved the ability to find and fix slow scripts; this has a big impact on world performance. We’ll contribute this feature to the OpenSim project soon. Next, we continued to improve support for items that were obtained in other grids. Finally, we added a few features that improve usability.

How to Fix Slow Worlds

Don’t you hate it when you visit a slow world, where every step you take causes rubber-banding, and chatting is slow and jerky? When worlds are slow, that’s almost always caused by either slow physics or slow scripts. World Managers are responsible for making sure that their worlds are fast and provide a good experience to visitors. But how can you, the world manager, know if your world is fast or slow?

The first thing you need to check is the Statistics panel. You can open this panel by pressing Ctrl+Shift+1 in the viewer. The panel shows many statistics, but the two most important statistics are the Physics Time and Script Time. If they show high values then that tells you that you have a problem that needs to be fixed.


This screenshot was taken in the Kitely Welcome Center, which is a highly optimized world: a Script Time under 1 ms is a good result. However, if you see a high Script Time or Physics Time then the next step is to find which objects are causing the slowdown. In the Region/Estate dialog you can open one of two dialogs: Top Colliders and Top Scripts. The Top Colliders dialog shows the objects that use the most physics time, and the Top Scripts dialog shows the scripts that take the most time. With this information you can decide what to do: optimize the objects, or disable them.

Debug Region

We’ve already improved the Top Colliders dialog significantly in the past, and today we made a similar improvement for Scripts.

Find and Fix Slow Scripts

Until today, the Script Time shown in the Statistics panel was always 0! That statistic had never been implemented in OpenSim. Today’s update, at last, implements the statistic. The “Script Time” value now shows the amount of time spent executing the world’s scripts in the last frame. This value should usually be very low: ideally under 1 ms. Some worlds might legitimately need more Script Time, if they have many scripts or many animations, but usually if the Script Time is higher than a few ms then you should try to optimize some of the slowest scripts in your world.

By the way, the Script Time shown in the Statistics panel is independent from all the other times shown in this panel. That’s because scripts execute on separate threads, outside of the frame processing time. This has two important implications. First, because scripts execute outside of the frame, it’s possible that the frame time will appear to be good, even though in fact the world is operating slowly due to heavy scripts activity. Therefore, if you have a high Script Time then you should optimize your scripts, regardless of what the other statistics show. Second, it’s possible for the Script Time to be very high, in some cases even hundreds of ms, i.e. longer than the frame time.

If you see that your world is using a lot of script time then the next step is to find which scripts are causing the problem. To do this, open the Top Scripts dialog. This dialog has been vastly improved in today’s update. Previously, the values it had shown were practically useless. But now, this dialog shows an accurate list of the slowest scripts in the world, and measures their execution time precisely. The value shown for each script is the total time spent executing that script in the last 30 seconds. (Note that 30 seconds is much longer than a single frame, and therefore the times shown here have little correlation with the Script Time shown in the statistics panel.)

Top Scripts

This screenshot was also taken in the Kitely Welcome Center. The top scripts here are pretty fast: the slowest script took just 5 ms, and remember that this is the total execution time over a 30-second period.

If your world contains slow scripts then they’ll appear at the top of the list in this dialog, and you’ll be able to see that they take much more time than the rest of the scripts. Alternatively, another cause of slow performance is if your scripts are efficient, but you have thousands of them. In that case you should consider why you need so many scripts, and whether you can reduce their number. (Note that this dialog won’t show thousands of scripts, but if you see a hundred identical scripts then you may assume that there are thousands more behind them…)

Once you’ve found the slow scripts, edit them to make them faster. How to do this is out of scope for this blog post; if you need help, try asking in our Scripting Forum. Whenever you save the script, the new version starts executing immediately. Click “Refresh” in the Top Scripts dialog to see if your changes made the script faster. Keep in mind that this dialog shows the total execution time in the last 30 seconds, so it will take some time for your changes to have an effect.

Once you’ve optimized enough of the slow scripts, check the Script Time in the Statistics panel to see if it has dropped significantly.

If you don’t want to take the time to edit the scripts, or you’re in the middle of an event and you need to improve the world’s performance quickly, then you can use the “Return Selected” or “Disable Selected” buttons in the dialog. “Return Selected” removes the selected objects from the world and adds them to your inventory. “Disable Selected” disables scripts and physics on the selected objects. After using either of these buttons, you can immediately check the Statistics panel to see if the Script Time has dropped. If you Disabled the objects then remember to re-enable their scripts (and possibly their physics, if they’re physical objects) after you have optimized the scripts.

We’re very proud of this feature. One area in which OpenSim has lagged behind Second Life is in ensuring a good (i.e., fast) experience for users. Every ex-Second Life user who switches to OpenSim enjoys the freedom to create large worlds with many prims and complex scripts, but this freedom can come at the cost of performance. At Kitely we’ve done a lot of work to make sure that our side of the service is fast, by using powerful servers and optimized asset and inventory systems. But slow scripts can bring any world to its knees, no matter how fast the hardware it’s running on. Today’s update gives world managers the information they need to ensure that their worlds are snappy and enjoyable.

Contributing the New Script Features to OpenSim

After we’ve had some time to test this new feature on Kitely and ensure its quality, we’ll contribute this patch to the OpenSim project. This should improve the performance of scripts everywhere in the Metaverse, to the benefit of the entire OpenSim community.

Other Improvements

We continued improving support for taking items from other grids and having them remain Exportable. This is a continuation of the work described in our last update. If you encountered problems after the previous update then please get the affected objects from the third-party grid again now.

When you view the list of members in a Group, the list now shows for each member whether they’re online, or otherwise the last time that they were online.

The OSSL function osKey2Name now returns the full name (including grid) for HG users. For example, local users return a name such as “First Last”, while Hypergrid users return a name such as “First.Last @grid.example.com:8002”. (Previously Hypergrid users also returned a name such as “First Last”, so they couldn’t be differentiated from local users.)

Improved Item Exchange with Other Grids

We updated the system today with a change that makes it easier to take items from other grids into Kitely, and then take them with you when you leave Kitely to visit other grids.

This update also includes several bug fixes, including a bug that sometimes prevented Hypergrid users from teleporting into Kitely.

Improved Item Exchange with Other Grids

Kitely is a Content-Filtered open grid. Unlike unfiltered open grids, Kitely enables content creators to decide whether the items they create may be taken to other grids, or will be treated as unexportable content. There are two ways that content creators can specify this preference. The first method is used only for items in Kitely Market: such items have an explicit “Export” flag, which determines whether they can be taken out of Kitely. This method hasn’t changed, and will not be discussed in this blog post. For any objects not acquired from Kitely Market, we use the following rule: if the object has Copy + Transfer (CT) permissions then it may be exported out of Kitely. Otherwise, it may not leave Kitely.

If an item isn’t allowed to be exported then users may not:

  • Wear it while teleporting to other grids
  • Store it in their “My Suitcase” folder while teleporting to other grids
  • Have it included in exported OAR files

But what happens if a Kitely user, while visiting another grid, picks up an item that doesn’t have CT permissions? Since that item clearly came from another grid, there’s no reason to prevent it from leaving Kitely. For this reason, we added the “Foreign Grid” flag: if an object came to Kitely from another grid then we turn this flag on, and that allows the object to be exported from Kitely even if it doesn’t have CT permissions.

And now we get to the problem that today’s update fixes. Until today, we had an exception to the “Foreign Grid” rule: if the item already existed in Kitely before the user picked it up in the foreign grid, then we wouldn’t turn on the “Foreign Grid” flag. This meant that the user still couldn’t export the item out of Kitely (e.g., by wearing it), despite the fact that we had already seen the item in a different grid.

The idea behind this logic was that even if the item already exists in one foreign grid, perhaps we shouldn’t allow it to proliferate any further. But this turned out to be a mistake. In the vast majority of cases, it prevented users from taking legitimate free content out of Kitely. It came down to randomness: if a certain common item without CT permissions (e.g., a Linda Kellie item) was first imported directly into Kitely by any Kitely user (e.g., using Load OAR), then we would never allow it to leave. But if the same item first came into Kitely from another grid, then it would be allowed to leave. This made no sense. It also didn’t add much to security, since we still couldn’t prevent items from being taken out using Copybots.

After consulting with our users we decided to change this logic, by removing the exception described above. Now, if we see an item in a foreign grid, then we always enable the “Foreign Grid” flag on the item, even if it already exists in Kitely. This change will make it much easier to pick up items in other grids and be sure that they will be allowed to enter and leave Kitely freely.

Please note that this change won’t affect existing items in your inventory, so if you had any items that suffered from this problem (you couldn’t leave Kitely with them) then you should pick up a new copy of the item from the foreign grid. We’re sorry for this inconvenience, but this will only need to be done once.

A note to Kitely Market merchants: this change doesn’t affect the exportability of products that were bought from Kitely Market. The explicit “Export” flag on such items takes precedence over everything else, so No-Export items won’t be allowed to leave Kitely even if they have CT permissions, and even if they have the “Foreign Grid” flag.

OSSL Permissions

When we recently updated to OpenSim 0.8.2 Dev we changed the permissions of a few OSSL functions, allowing fewer people to use them (e.g., only World Managers vs. Everyone). These changes were originally made in the core version of OpenSim, because the developers have come to consider some functions to be more dangerous than previously thought. We chose to accept these changes in order to maintain security and compatibility with other grids that are using the latest version of OpenSim. We’ve updated the list of Supported OSSL Functions to reflect the new functions and permissions.

Bug Fixes

This release also includes a number of bug fixes:

There was a bug that prevented Transfer Stations from working for users that came in from other grids. This meant that if users on other grids tried to visit a Kitely world, and that world was offline, then the teleport failed. Now the teleport will succeed, and the user will be sent to the Transfer Station while the world is being started. (This is how Kitely had worked up until we upgraded to OpenSim 0.8.2 earlier this month; that’s when this bug started.)

Kitely allows restricting access to Kitely worlds to users who belong to a certain OpenSim Group. Until today, such restrictions only worked for Kitely users. While you could add Hypergrid users to your Groups, they still weren’t allowed to enter restricted worlds. This bug has been fixed, so now Hypergrid users who belong to Groups will be allowed to visit worlds that are restricted to members of those Groups.

It is now possible to visit Kitely from other grids by entering kitely.com:8002 in the World Map. The correct address for Kitely is actually grid.kitely.com:8002, so until today if anyone tried to visit by entering just “kitely.com:8002” then they received an error. But now we allow this address to work. However, we still recommend entering the full address (grid.kitely.com:8002), because foreign grids may cache these addresses and we prefer that they cache the correct address.