Updated OpenSim and Even Faster Worlds

We upgraded Kitely today to an enhanced version of OpenSim 0.9.2.2. Our version of OpenSim includes hundreds of proprietary stability and performance improvements that we’ve developed for OpenSim over the years. This long-awaited update includes many changes and improvements, including ones that speed up world startup times. This is in addition to our system-wide upgrade a few weeks ago that doubled world performance.

The biggest new feature in OpenSim 0.9.2.2 is that the scripting system has changed from XEngine to YEngine. While using YEngine offers many benefits, there are also a few downsides to this change:

YEngine is designed to more closely follow the LSL script syntax. This makes it easier to port scripts that were designed for Second Life into OpenSim. However, this change can also cause some scripts that worked on XEngine to break. If you encounter scripts that have stopped working properly then you’ll need to fix, replace or remove them from your Kitely worlds. You can read more about these script changes here.

In addition, the change from XEngine to YEngine caused all of the scripts to reset to their initial state. That’s because the state files where OpenSim stores script state have changed their format, and YEngine can’t use state files that were created by XEngine. So if you used any scripts that need configuration after they’ve been rezzed then you’ll need to configure them again.

And finally, switching script engines requires our system to recompile all the scripts in your worlds. This happens the first time each world is entered following today’s update. This means that each world will take longer than usual to start the first time anyone enters it after this update. This is just a one-time delay, and the next time anyone enters that world it will start faster because its scripts will already be compiled.

We hope you enjoy this upgrade! If you encounter any problems then please let us know here.

Better Mesh Uploads and Other Improvements

Over the past few months we’ve made some major improvements to our backend and website. And today we’ve updated Kitely with a few usability improvements and bug fixes.

When you upload a mesh, usually the mesh includes some textures, and they are automatically uploaded as well. Previously, the uploaded textures were placed in the top-level Textures folder. Now, they are placed in a subfolder of Textures that has the same name as the uploaded object. This makes it easier to find them, and to keep the Textures folder organized.

We fixed a bug that prevented Estate Managers from making some changes to parcels in the estate. For example: Subdivide parcel, Join parcels, Eject user, etc. (This bug didn’t affect Estate Owners, so it wasn’t very noticeable: it only affected additional Estate Managers that had been added to the estate after the Estate Owner.)

We’ve improved some OpenSim error messages to make them easier to understand.

We’ve made many other improvements in the past few months, which we haven’t mentioned in our blog until now (we only talked about them in the weekly Kitely community meetings). One of the biggest changes is a huge improvement to our mobile website; check it out if you haven’t already! (Visit https://www.kitely.com from your mobile). We also overhauled our desktop website to make it more modern and easier to navigate. There have also been some major backend improvements, such as upgrading to MySQL 8, switching to a different and more modern Linux distribution and improving our internal system monitoring capabilities.

Environmental Enhancements and Improved Scripting

We’ve updated Kitely today with several big improvements. We now support the Environmental Enhancement Project (EEP), which allows changing the world’s environment: its sky, water, etc. We’ve also added the option to sell EEP settings in Kitely Market. And finally, we’ve added support for many new and updated scripting functions, in both LSL and OSSL.

A Note About OpenSim 0.9.2

Kitely runs the latest stable release of OpenSim, which is currently OpenSim 0.9.1.1 (along with over 600 proprietary improvements of our own). Most of the changes in today’s update were taken from OpenSim 0.9.2, which is currently in development and isn’t finished yet. We value stability, so normally we wouldn’t integrate code from an unreleased version of OpenSim. We prefer to wait until OpenSim’s bugs have been ironed out through testing on other grids. However, in this case we had good reasons to integrate some features from OpenSim 0.9.2 even though it hasn’t been released yet.

The reason we added the Environment Enhancements is that the previous environment system (WindLight) doesn’t work with modern viewers anymore, so it was important to provide a replacement.

We added the new and modified scripting functions from OpenSim 0.9.2 for two reasons. First, some of these functions are required in order to work with the Environment Enhancements. Second, some of you have asked us to add the new scripting functions so that you’ll be able to start using them.

We want to take this opportunity to thank Ubit Umarov for his continued work on improving OpenSim: he wrote the vast majority of these features, and he’s working hard on getting OpenSim 0.9.2 finished and released.

Environment Enhancements

You can now use the new Environment system in your worlds. If you look at your Region or Parcel settings, you’ll see that the Environment tab has changed: instead of showing Windlight settings, now it shows EEP settings. The world has an overall environment, and optionally parcels can override that environment. You can also create a private environment just for your avatar.

Another change is that OAR files now include the region and the parcels’ environments. (OAR files did not include Windlight settings, so this is a big improvement.)

Kitely now supports a new type of asset, called Settings (short for “Environment Settings”). This asset has three sub-types: Day Cycle, Sky and Water. You can add items of this type to your inventory, and you can also include them in products that you sell in Kitely Market. If you want to sell standalone Settings assets then we’ve added a new category for this purpose: Landscaping and Plants > Environments.

Migrating from Windlight to EEP

If you have Windlight settings in your regions then they will be converted to EEP automatically.

If you have Windlight settings in your parcels then they will not be converted to EEP automatically. That’s because unlike region settings, the parcel settings aren’t stored on the server. Instead, they are stored in XML files on your PC. In order to migrate them to EEP you will need to do the following:

1. Identify the Presets used in your parcels. For example, suppose that you have a parcel that has the following line in its description:

/*Windlight Sky: "[TOR] BIG SUN - Awwyeah" Water: "[TOR] Watermelon juice"*/

This means that the parcel is using the preset called “[TOR] BIG SUN – Awwyeah” for its Sky, and the preset called “[TOR] Watermelon juice” for its Water.

2. Locate these presets (as XML files) on your PC. There are two directories that can contain Presets: in Firestorm, and in your local settings.

The Firestorm presets are located in the following directory:

  • Windows: C:\Program Files\FirestormOS-Releasex64\app_settings\windlight
  • Mac: /Applications/FirestormOS-Releasex64.app/Contents/Resources/app_settings/windlight

In the example above, both of the presets can be found in the Firestorm directory. However, if you don’t find the presets in this directory then look for them in your personal presets directory, which is at:

  • Windows: C:\Users\YOUR_NAME\AppData\Roaming\Firestorm_x64\user_settings\windlight
  • Mac: ~/Library/Application Support/Firestorm/user_settings/windlight

If you can’t find the Presets in either of these locations then they never worked, because the viewer wouldn’t have found them either.

If you do find the Presets then convert them into the new Settings assets. This requires Firestorm 6.4.13. Select from the menu: World > Environment > Bulk Import, and then select the specific type of asset that you are importing. This adds Settings items to your inventory, in the “Settings” folder. You can then use these items to set the parcels’ environments.

Scripting Changes

This update includes many scripting changes. In some cases these changes are very significant because they don’t affect only the scripting functions (in LSL or OSSL), but also how OpenSim works at a basic level. The next few sections describe these changes.

Most of the new functions may be called by anyone, i.e. they don’t have a Threat Level.

New Environment Functions

The following functions allow working with the Environment, or with related aspects (such as the current time).

Other New Functions

Deleted and Deprecated Functions

The following functions shouldn’t be used anymore.

  • osSunGetParam / osGetSunParam
  • osSunSetParam / osSetSunParam
  • osSetEstateSunSettings
  • osSetStateEvents

Changed Behavior

The following functions have changed their behavior.

  • llTarget, llRotTarget – the events at_target and not_at_target used to be sent to every script in every prim in the object, but now they are sent only to the script that called llTarget or llRotTarget.
  • llGiveInventoryList
    • The items must have Copy permission. They also need Transfer permission if they’re being given to a different avatar.
    • The destination object must be Moveable.
    • The destination object must allow receiving incoming items.
    • Can’t give scripts to other users (but you can give them other types of items).
    • The script now sleeps a bit whenever this function is used: 3 seconds when giving to a user, or 100 ms when giving to an object.
  • Changing a prim’s scale (using llSetScale, or one of the functions like llSetLinkPrimitiveParamsFast) didn’t show the scale change until the object was selected, or manipulated in some way. This has been fixed.
  • If an LSL or OSSL function encounters an error then the script sleeps for 1 second
  • llStartObjectAnimation, llStopObjectAnimation – you can now specify one of the system default animations (vs animations in the object’s inventory)
  • llStartAnimation, llStopAnimation, llStartObjectAnimation, llStopObjectAnimation, osAvatarPlayAnimation, osAvatarStopAnimation – you can now specify the system default animations by their name instead of by their UUID
  • osOwnerSaveAppearance, osAgentSaveAppearance, osNpcSaveAppearance – added an option to specify whether to save HUDs in the notecard or not
  • llList2Vector, llList2Rot – now they automatically convert string elements into rotation and vector
  • llList2Json – fixed a bug that occurred if any of the elements in the string was an empty string
  • llPassCollisions – when used with the parameter “2”, now it doesn’t pass collisions (previously it did)
  • osInviteToGroup – doesn’t send an invitation if the user is already a member of the group (returns 2 in this case)
  • osInviteToGroup, osEjectFromGroup – improved the check for whether the user has the necessary group powers (Invite or Eject). Previously only the specific user’s powers were checked, but now we also check the powers that belong to the user’s Roles.
  • llGetLinkKey – support parameter LINK_THIS 
  • llBreakLink, osForceBreakLink
    • Allow breaking the prim that is hosting the script
    • Automatically stand up all avatars that are sitting on the object
  • osStopSound – supports parameters LINK_SET, LINK_ALL_OTHERS, LINK_ALL_CHILDREN
  • llXorBase64 , llXorBase64Strings, llXorBase64StringsCorrect – fixed their implementation
  • llLoadURL – can’t be called from group-owned prims
  • llGetEnv – supports new parameters “whisper_range”, “chat_range” and “shout_range”
  • osSlerp – added a new variant that accepts vectors instead of rotations
  • osTeleportObject – works on phantom prims

Other Changes

We increased the number of products that are displayed in each Kitely Market page to 24 products (previously we showed 15 products).

We’ve fixed the following bug: put a script in a prim; lock the prim; restart the viewer; unlock the prim; and try to view the script. Previously you couldn’t view the script, but now you’ll be able to.

Showcase for Kitely Market Stores

We’ve updated Kitely with several features and bug fixes that were requested by our users. The biggest improvement is to the Merchants Showcase area in the Kitely Welcome Center, and how it allocates free advertising signs to Kitely Market stores.

Merchants Showcase

Kitely Welcome Center is the most popular entry point to the Kitely grid, and is visited by hundreds of people each week. It contains an area called the “Merchants Showcase”, which provides free advertising for some Kitely Market stores. Each store gets a sign that displays some of its products, and visitors can click on the sign to view these products on the Kitely Market website. Thanks to this world’s popularity, the showcase is a great way to let people learn what’s available in Kitely Market.

The stores that get this advertising are selected by their rank. A store’s rank is determined by the amount of money that the store’s owner pays for their monthly Kitely subscription.

A store’s rank can also be improved when other people who have a Kitely subscription use their rank to promote that store (instead of promoting their own Kitely Market store). For example, this is useful when a group of users share a store. A user that wants to promote a different store can do so by entering that store’s name in their Account Settings:

Each store’s sign displays four of the store’s best-selling products (chosen at random from the store’s top ten best-selling products).

Optionally, the store owner can control which products appear in this sign by creating a Products Group called “Merchants Showcase”, and adding products to it. If this group exists then it will only be used to determine which products appear in the Merchants Showcase; it will not be used for the “Related Products” feature (which is the usual way that Product Groups are used).

There are a few caveats for appearing in the Merchants Showcase. First, only products with a maturity rating of General or Moderate are displayed. Second, only a store that has at least four eligible products can get a sign (since we don’t want empty squares in the signs).

The Merchants Showcase is automatically updated once per day. When that happens the list of stores might change, as well as the products that are displayed in each sign.

Sort Items in a Product

Items and folders that are included in a Kitely Market product are now sorted alphabetically. Previously they appeared in reverse creation order, but alphabetical order makes more sense. (This change only affects products that are created or updated from this point on; it doesn’t affect any existing products.)

Enabled Land Sales and Improved Terraforming

We’ve updated Kitely today with several highly requested features for land sales and terraforming. You can now sell parcels to other users; upload and download terrain RAW files quickly; and easily create Ocean worlds.

Selling Land

After we introduced huge Mega Worlds a couple of weeks ago, we received new requests to enable selling land in Kitely. We’re happy to announce that it’s now possible to sell parcels in your worlds to other users. This lets Kitely users become landlords.

If you’re a world owner, here’s how to make a parcel available for sale (click to enlarge this image):

And here’s how to buy a parcel:

Land sales are only available in Advanced Worlds and Mega Worlds. This page explains how this works.

Land Rentals

Land rentals aren’t a feature that OpenSim or Kitely provide: instead, rentals are implemented using scripts.

Land sales are the only way to transfer ownership of a parcel to another user, which is important for implementing rentals. There are already a few rental scripts in Kitely Market, but since land sales hadn’t been possible in Kitely until now these scripts may need to be modified to take advantage of this new functionality.

Download a World’s Terrain

OpenSim supports uploading and downloading a world’s Terrain from the viewer. But these features are extremely slow for the large worlds that Kitely supports (up to 8×8 regions, or 2048×2048 meters). So we’re now introducing replacements for these features, which work much faster.

When you click Download RAW terrain, we now provide you with a URL for downloading the terrain file. This is much faster than the standard OpenSim method for downloading the terrain.

Replace a World’s Terrain

When you click Upload RAW terrain, we explain that this feature now resides on the Kitely website, through the Replace World feature. Previously this feature only worked with OAR files, but now you can give it terrain files, too. If you upload a terrain file then we’ll replace only the world’s terrain, and leave its objects, parcels and region information unchanged.

For example, I wanted to replace my world’s terrain with terrain #016 from this page. The terrain is supposed to look like this:

To do this, first download the terrain file to disk. Then go to your “My Worlds” page; click on the “Manage” link for your world to open its Manage World dialog; switch to the “Files” tab in that dialog; select the RAW file on disk; and click “Replace World”. This screenshot shows the terrain file being uploaded to Kitely:

Replace World will inform you of the progress of the operation.

Once the process was complete, my world looked like this:

Please note that the world will be updated immediately with the new terrain, but the World Map may take between a few minutes to a few hours to get updated.

Tips For Working With Terrains

If you want some free terrain options then take a look at this page, which includes RAW files for islands in various fun shapes.

L3DT is a utility for editing terrain files. This page and this page explain how to use it.

The OpenSimulator wiki has a bunch of information about terrains, as does this article by Kitely user Graham Mills.

If you created a good terrain, why not share it in the Kitely Forums?

Ocean Worlds

Some users want to create worlds that are mostly ocean, with a little land thrown in. This is useful for sea-based activities such as sailing, or to provide room for aquatic creatures to frolic.

Until now creating such worlds was a chore, because by default Kitely worlds contain land in their entire area. This required users to manually terraform their world using the viewer tools, which can be a long and tedious process.

Now there’s an alternative: when you create a new world, we’ve added an option to create an “Empty Ocean” world.

There’s another way to get mostly-ocean worlds: if you resize a world and make it bigger, then you can now choose whether the new area will contain Land or Ocean.

Support for 6×6 Mega Worlds

As mentioned previously, we’ve recently introduced Mega Worlds, which can be up to 8×8 regions in size. But some users have asked to use an intermediate size of 6×6 regions, so we’ve now made this option available.

(If you want your own Mega World then get it now, because we are only offering them until November 30!)

Hosting Large Events in Kitely

We’ve spent the last six months developing features that improve the performance, robustness and scalability of our system. Today we’re proud to announce that Kitely can be used to host large multi-world virtual events.

Creating Large Events

You can now use Kitely to easily create and manage large events that support thousands of users, who are split across dozens of worlds.

We’ve added many features that are needed in order to support large events. These features are only visible to Kitely admins, but we describe some of them below in order to explain how large events work.

Events use a special type of organization called a Prime Organization. The biggest difference between a Prime Organization and a regular organization is that a Prime Organization owns its worlds. In contrast, regular organizations don’t own their worlds: the worlds are owned by some Kitely user, who assigns them to the organization. The benefit of having the organization own its worlds is that this allows for fast creation and deletion of worlds without having to deal with the per-world payment procedure that is used for user-owned worlds.

A large event requires many identical worlds: each world holds a subset of the total number of visitors. We’ve therefore added a feature that takes a World Archive and automatically creates many worlds out of it. This is much faster and more convenient than manually copying a world many times.

When an event begins, all of these worlds should be up and ready to go. However, regular Kitely worlds don’t work that way: they are kept offline until someone tries to enter them, and then they are started. Therefore, we’ve added a feature that ensures that all of the event’s worlds will be started ahead of time, and kept active even if there are no users inside them. The worlds terminate only once the event ends.

A key feature of an event is how users enter the event’s worlds. Normally, users that login to Kitely in the viewer need to specify which world they want to enter (or they can revisit the last world they had visited). But this won’t work for events, because users don’t know which world they should enter (they don’t even know the names of all of the worlds that have been created for the event). A primitive solution to this problem would be to assign users to worlds in advance (say, using an Excel spreadsheet), and then to inform each user which world they should enter. But that’s a lot of work, and users are very likely to make mistakes. So instead, we added an automated Event Manager that automatically sends users to the appropriate world. The Event Manager’s algorithm works in two phases:

Phase 1 – Fill up worlds. The event organizer tells us in advance how many users they would like to have in each world. For example, if the event is a company-wide “Escape Room” game, then six users per world is ideal. During Phase 1 we fill up each world with users until it gets to this number, and then we start filling the next world.

Phase 2 – Round-robin between worlds. After we have finished filling up each world to the desired number of users (six in this example), we add any additional users one at a time to each world. I.e., first we get all of the worlds to seven users; then we get all of the worlds to eight users; etc. (Of course, if we have enough worlds created then we might never get to Phase 2. This is just a safety measure in case more users than anticipated arrive for the event.)

After users have entered the event world that they’ve been assigned to, they can choose to teleport to a different event world to join their friends. If this happens then the Event Manager will automatically assign the next users that enter the event to the world that was just vacated.

We’ve also made some low-level improvements that allow large events to work well. For example, regular Kitely worlds always run on the same type of server. But for events we have the flexibility of choosing a custom server type. The type of world that the event uses dictates which server type will work best. For example, some events want to have as many people as possible in each world, so they will want to use beefy servers. Other events might use a lot of physics and require a lot of CPU power; or perhaps they use many scripts and need a lot of memory.

Contact us to learn more about how Kitely can be used for your own virtual event.

Showing World Maps in an Organization

All Kitely worlds have a world map, which is usually viewed in OpenSim. But the world map can also be viewed in Kitely’s website. This is useful in order to differentiate between multiple worlds that you own.

For regular Kitely worlds, you can view their world map by using the “Resize” feature. You don’t actually have to resize the world: this just shows you the world map.

For worlds in an organization, we now show the world map in the world’s page in the organization:

In addition, the organization web console now also displays the world map of World Archives. This makes it easy to choose which World Archive to use when you want to create a new world.

Increased Max Script State Size

When an OpenSim region shuts down, it stores the state of its scripts in state files. When the region is next started, the script states are loaded from these files.

OpenSim has a limit on how large a script state file can be. This limit used to be 0.5 MB, but following user requests we’ve increased the limit to 5 MB. Note that only scripts that use a lot of memory will ever hit this limit. Most scripts use only a handful of variables, so they won’t come anywhere near this limit.

Performance Improvements for Large Events

Lately we’ve been working on improving the experience of having many avatars in-world at the same time. This is particularly important for hosting large events. We updated the system today with many performance improvements related to this goal.

The following is a video of a load test we performed on a copy of the Kitely Welcome Center running on an Advanced World, using 80 bots controlled from a remote server. The video was taken after all the bots completed their login process. The CPU usage for this world remained at around 60% while the video was taken.

Each bot simulated all of the network activity that a real viewer performs, including asset downloads, terrain downloads, uploading the avatar’s own baked textures and downloading other avatars’ appearance, and all network activity from the time the client begins the login process until it is inworld. Once logged into the world each bot started walking around randomly in straight lines, circles and jumps. Bots also sent instant messages to local chat at a combined rate of one chat message every two seconds (you can see the chat button flashing each time such an IM was received).

Downloading Assets from CloudFront

The biggest change we made was to our assets system. OpenSim viewers such as Firestorm download most assets (specifically, textures and meshes) using a protocol called HTTP. Previously, these assets were downloaded from Kitely’s servers. But this could be slow if many users entered a world at once, and they all tried to download the world’s assets at the same time. In order to eliminate this bottleneck we’ve moved these assets to a service called CloudFront. CloudFront is Amazon’s CDN, or Content Delivery Network. It’s a worldwide collection of very fast servers whose only purpose is to serve HTTP files. CloudFront has practically unlimited bandwidth, and it has servers in many cities around the world (see this map), so it can serve assets very quickly to an unlimited number of users.

This improvement is going to make a big difference when many users enter a world at the same time. Individual visitors might not feel much of a difference, because viewers such as Firestorm have an artificial limit on how quickly they download assets. If you want, try increasing this limit and see if it makes worlds appear faster. This setting is called “Maximum bandwidth”, and it’s set to 1500 Kbps by default in Firestorm.

CloudFront is quite expensive, so in order to limit our costs we’re only using the CloudFront edge servers in the U.S., Canada and Europe. This accounts for the vast majority of Kitely’s users. Users in other countries are still going to get a performance improvement from our switch to CloudFront, but not as much as users in the aforementioned countries.

Optimized UDP Packets

Most communications between the viewer and OpenSim are done using UDP packets. In the past we’ve already done many rounds of optimization on UDP packets, and we’ve optimized them even more in this update to reduce network lag during periods of high network activity.

Eliminated a Source of Lag

Sometimes OpenSim needs to perform maintenance work on regions. Users in worlds that are currently undergoing such maintenance can experience server lag. In order to prevent this, we’ve created a mechanism a few years ago called Shadow Worlds. A Shadow World is a copy of a real world, but it doesn’t allow visitors: it’s only used to run maintenance work. For example, we’ve been using Shadow Worlds to update the World Maps. We’ve now eliminated maintenance-related server lag by moving additional types of maintenance work to the Shadow Worlds.

Centralized Logging and Metrics

This feature is not something users can see, but it helps us a great deal in finding performance problems and fixing them. All of Kitely’s servers now send very detailed metrics (performance measurements) and logs to a centralized location. This is useful in many ways. For example, if we get a report about a world that was behaving slowly then we can look back and see what activity was taking place in the world, right down to how many UDP packets of each type were being sent and received. This will help us further optimize our system and assist us in addressing any issues that are reported to us.

Other Improvements

Today’s update also includes a couple of features that were requested by our users.

We’ve fixed a bug related to searches in the World Map; see this forum post for discussion. The bug happened if the search used a full SLURL (vs just a world name), and there were multiple worlds with similar names.

We’ve also added three fonts that you can use in LSL scripts. Their names are: Noto Sans, Noto Serif, and Architects Daughter.

Upgraded Database, and Improved Uploading Models

We’ve upgraded our system today. The biggest change is that we’ve upgraded our database in order to support big events with thousands of users.

We’ve also implemented a feature that was requested by our users: In OpenSim 0.8, when users uploaded Models the system would also create inventory items for the Textures used in the models. This behavior was disabled in OpenSim 0.9, but now we’ve re-enabled it.

Kitely Market Payouts in KC

We’ve updated our system with a couple of improvements that were requested by our users: Kitely Market merchants can now convert their cleared USD earnings to Kitely Credits (KC); and you can now more easily share your worlds to Facebook. We’ve also added a feature to Organizations that allows users from one organization to visit the private worlds of another organization.

Kitely Market Payouts in KC

Kitely Market merchants can choose to sell their products for USD. These USD aren’t transferred to you immediately: we accumulate them, and once you have at least $10 (USD) in cleared sales we schedule them for the next weekly payout (sales are cleared once they pass the PayPal 45-day dispute period). This minimum payout amount exists because of PayPal’s transfer fees, which make transferring smaller amounts uneconomical.

Some merchants sell mostly in KC, so it can take them a long time to earn 10 USD. Previously this money was “stuck”, waiting until the merchant earned enough USD for a payout to PayPal. But now we’ve added a new option: you can convert any cleared funds your store has earned to KC, even if you have less than $10 cleared. The KC will be converted at a rate of 200 KC per 1 USD and will be added to your Kitely account balance immediately. You can then use those KC to pay for world hosting, buy items from Kitely Market, etc.

If you’re a Kitely Market merchant in this situation then you’ll see a new option in your Manage Store page:

This merchant has two options:

  1. They currently have only $5.20 in cleared USD. If they wait, then eventually the rest of their money will clear. Then they’ll have a total of $18.80 in cleared USD, and we’ll automatically transfer it to them.
  2. Alternatively, they can get their earnings immediately by clicking on the link in the highlighted box. The $5.20 will be converted to KC and added to their Kitely account balance. The other $13.60 will remain withheld until enough time passes for it to clear the PayPal dispute period (at which point it will start accumulating for a payout to PayPal as usual).

Better Facebook Sharing

The Kitely website has buttons for sharing stuff to Facebook. You can share worlds, Kitely Market products, or Kitely itself (from the homepage). We’ve switched to a new style of sharing, which lets you enter your own thoughts about what you’re sharing. (Previously you could only “Like” something, without entering your own text.)

Shared Groups in Organizations

Organizations can control who may visit their worlds. They can choose to make some worlds available to everyone (including users that aren’t members of their organization), and make other worlds available only to specific groups in the organization.

But what if an organization wants to make a world open only to some external users? (“External users” are users that don’t belong to the organization.) To address this need we’ve created a new feature, called Shared User Groups, that lets organizations cooperate: users from one organization can visit specific private worlds the belong to another organization.

For example, suppose there’s an organization called “Acme University”, and another organization called “The Egyptology Center”. Acme University wants its students to visit Egypt-themed worlds that belong to The Egyptology Center. These worlds are not open for public visits, so Acme University has to ask The Egyptology Center to allow its user group Students to visit these worlds:

Once The Egyptology Center agrees, the user group “Students” becomes shared. This means that it appears in the groups tree of The Egyptology Center, and the admins of that organization can give the group permissions: e.g., permission to visit some of the organization’s private worlds.

This feature is explained in more detail here.

Kitely API Beta and Custom Viewer Login Page

We updated Kitely today with a couple of important improvements for Organizations (virtual grids). You can now set up a custom viewer login page for your organization. You can also apply to join our Kitely API private beta.

Kitely API Beta

We’ve created an API that enables Organizations to automate their operations. The API allows you to programmatically create and delete users and groups; change their permissions; and replace the contents of worlds.

Kitely API is currently in private beta, and is being used by select organizations. If you have an organization and would like to use Kitely API then please contact us.

Custom Viewer Login Page

The Viewer Login Page is what appears in Firestorm when you select a grid you wish to log into. Kitely Organizations are virtual grids, and as such they each have a Viewer Login Page.

Previously, each organization’s Viewer Login Page was automatically created by Kitely, and just displayed the organization’s name and some links. This is still the default Viewer Login Page, but it’s now possible for organizations to specify their own Viewer Login Page URL instead. This enables better branding and customization.

Setting a custom Viewer Login Page is only available for Standard Organizations and above.