Kitely restructures subscriptions, payment options and more

July 17th. Kitely has today announced extensive pricing restructuring which has come about in part as a result of requests from users asking that they be able to spend more time in-world rather than receiving additional Kitely Credits (KCs).

New Subscription Options

Under the new subscription system, monthly KC awards are abolished and in-world times revised. This means the basic Bronze level subscription now provides 30 hours in-world per month (up from 25 under the old system of combining free minutes and awarded KCs), with the Silver plan now providing 120 hours in-world, up from the 100 hours offered under the old minutes + KCs model. With both Bronze and Silver plans, the number of supplied regions remains unchanged (two and 10 respectively).

The old Kitely subscription model (top) and the new (bottom)

The biggest changes are at the top end of the subscription model, with the Platinum plan being completely abolished and the Gold plan reduced in price from $50 a month to $35 a month. Gold does also sees a reduction in the number of offered regions (down from 30 to 20), but Gold plan users now get unlimited time in-world.

The new subscription plan comes into effect for Bronze and Silver subscribers from August 1st, 2012. Gold and Platinum subscribers have the option of continuing with their old plans if they wish, or swapping to the new system.

There is also a small change to the free plan: new users signing-up to this now receive six hours of free in-world time during the month in which they create their account. After this (i,e, at the start of the next month), their free usage reverts to 2 hours a month.

Further pricing Updates

In addition to this:

  • The costs for setting-up and/or storing additional regions (over and above the free allocation of regions within each subscription plan) has now been increased. The one-off cost of establishing an additional world increases from 1KC to 10KC, while  the cost of storing a region similarly rises from 1KC to 10KC per day
  • Users can now buy up to $500 USD of KCs at any one time (up from a maximum of  $50 USD in a single purchase), options rising in $100 USD increments from $100 onwards
  • It is now possible to pay for a subscription plan using Kitely Credits as well as PayPal at the start of each month. Three options are available:
    • Via PayPal: as per the current system
    • Via PayPal, or Kitely Credits whenever possible: providing your account has sufficient Kitely Credits, payment will be made via KCs at a rate of 300 KC per $1. Otherwise, your PayPal account will be billed
    • Using KCs only: this option is only recommended for those who purchase large amounts of Kitely Credits and / or who prefer not to use PayPal for their subscription payments. If there are insufficient KCs in an account when payment is due, the plan risks cancellation (a warning e-mail will be sent out in advance of cancellation).
Setting your preferred subscription payment option

Setting a Price for Visiting Region

Until now, users have only been able to decide whether they pay Kitely for the time others spend visiting their worlds (effectively making the region “free” for visitors), or whether they pass the charge onto visitors. In either case the rate was 1 KC per minute a visitor spent visiting a region.

These options continue unchanged, but as from July 17th, users are able to charge visitors directly for the time they spend in a region; KCs earned can then be used towards subscription plan payments, for example (subject to the notes above). Further, the new functionality allows region holders to pay others for the time they spend visiting the region.

Pricing can be defined in terms of group access and is calculated on the basis of minutes spent visiting the world.

Changing options for visitors to a region

This approach offers a tremendous flexibility of use, including:

  • The ability to charge different amounts on the basis of the group a visitor is in. For example, a RPG region could charge one rate for all members of the associated RPG group and a slightly higher rate for people visiting the region out of curiosity
  • The ability to automatically pay others for visiting your world – the blog post uses the example of paying performers for their time performing in a region
  • The ability to initially have a region set, for example, to free access ahead of an event (allowing people to come and sample it), and then turn on the additional pricing as the event is about to start; users are then presented with an pop-up dialogue asking them to confirm their willingness to pay or to be disconnected from the region if they do not
  • Payment options can be mixed within a single region, so it is possible to charge visitors for their time in the region while also paying performers.

All charges applied to a region are in addition to the basic rate of 1KC per minute. Furthermore, Kitely charge a 10% commission on all Kitely Credits that are earned using these monetization options (i.e. so if you charge 10KC per minute to visitors, you will receive 9KC; if you pay a performer 10KC a minute, they will receive 9KC). This commission  does not apply to any of the other ways users can transfer KC to one another.

Related Links

SL Server roll-outs: creator tools and pathfinding

Update July 18th: The Magnum RC roll-out has been delayed until Thursday July 19th. Oskar may supply a reason on the deployment thread in the forums – keep an eye on that for updates (with thanks to Wolf Baginski).

Main Channel Release

Tuesday 17th July sees the a roll-out of LSL functions related to the Advanced Creator Tools. This release will see the addition of three new LSL functions (comments taken from the release notes):

  • llAttachToAvatarTemp(integer attach_point): Follows the same convention as llAttachToAvatar, with the exception that the object will not create inventory for the user, and will disappear on detach, or disconnect. It should be noted that when an object is attached temporarily, a user cannot ‘take’ or ‘drop’ the object that is attached to them. The user is ‘automatically’ made the owner of the object. Temporary attached items cannot use the llTeleportAgent or llTeleportAgentGlobalCoords LSL functions
  • llTeleportAgent(key agent_uuid, string lm_name, vector landing_point, vector look_at_point): Teleport Agent allows the script to teleport an agent to either a local coordinate in the current region or to a remote location specified by a landmark. If the destination is local, the lm_name argument is a blank string. The landing point and look at point are respected for this call. If the destination is remote, the object must have a landmark in its inventory with the teleport agent script. lm_name refers to the name of the landmark in inventory. This function cannot be used in a script in an object attached using llAttachToAvatarTemp
  • llTeleportAgentGlobalCoords(key avatar, vector global_coordinates, vector region_coordinates, vector: Teleports an agent to region_coordinates within a region at the specified global_coordinates. The agent lands facing the position defined by look_at local coordinates. A region’s global coordinates can be retrieved using llRequestSimulatorData(region_name, DATA_SIM_POS). This function cannot be used in a script in an object attached using llAttachToAvatarTemp.

The new LSL functions work with the current runtime permissions system and are precursor to future work with experience permissions. More information about the runtime permission is here:PERMISSION_TELEPORT.

The keen-eyed will note that these are the functions that were rolled-out to the Magnum RC channel in May, and which were subsequently abused for griefing purposes. However, Linden Lab have added a new capability to the functions  – what is described as an “on / off” switch which is available only to Linden Lab personnel, and which allows the functions to be enabled  / disabled (the functions were also rolled-out to the Le Tigre RC on July 11th with the “on / off” switch capability). As the release notes make clear, the functions are disabled by default in the roll-out, and will presumably remain that way until such time as the updated permissions system has been rolled-out.

The release also includes three bug fixes (again, as specified in the release notes):

  • SCR-342: llTeleportAgent() does not fail gracefully when specifying an invalid landmark name
  • SVC-7966: Magnum RC, llTeleportAgent gives a wrong message
  • SVC-7987: llTeleportAgent always points in the positive Y direction on teleport.

Pathfinding release: Magnum and Le Tigre

On Wednesday 18th July, the Magnum RC will get a further roll of the pathfinding code and Le Tigre will apparently get the same code as well. At the time of writing, the actual release note pages on the SL wiki for Magnum and Le Tigre still reflected the releases for July 11th and the forum post announcing the release did not show any specific changes from the forum post relating to the July 11th release. Any alternations which may have been made following the difficulties some initially encountered on the Magnum RC following that roll-out are therefore hard to identify. This ma change prior to the actual roll-out.

Related Links

Singularity 1.7.0

July 16th marked a new Singularity release with a number of updates and new features, namely:

  • Support for multiple clothing layers
  • Region Windlight support
  • New build preferences
  • A new audio display floater
  • Mouselook aiming
  • RLVa 1.4 update
  • Shift-C crouch toggle
  • LSL editor update, including external editor support
  • Radar now indicates gesture/sound/particle/animation spam
  • Sound bugs fixed.

The following is an overview of the key changes to the viewer, and is not intended as an in-depth review.

Download and Install

The Windows installer is some 23.8Mb in size; it is recommended that any prior versions of Singularity are removed prior to installing 1.7.0. The viewer installed smoothly, and did not throw any false-flag anti-virus warnings for me (I use AVG anti-virus)..

Once logged in, inventory download was fast in comparison to V3-based viewers.Granted, I keep my inventory fairly tight and tidy (anything not in regular use gets packed away – particularly COPY items), but by the time I’d rezzed (itself only a handful of seconds), my inventory had loaded; this seemed a lot faster than with other viewers of late.


The ability to wear multiple items on the same layer of system clothing is now pretty much a staple part of most viewers. However, Singularity stands apart from the rest in it’s offering by not only being compatible with the LL multi-wear code, but in also providing a very useful enhancement.

In most viewers providing multi-wear capabilities, adding an item of clothing to the same layer as an item already being worn will currently see the additional item appear to be worn “over” the existing item (i.e. if you are wearing a shirt layer item, any shirt layer item added to your outfit will appear to be worn “over” the item already being worn).

Singularity, however, provides two additional inventory menu options: Move Forward and Move Back, which allow you to change the order in which clothing items worn in the same layer are “stacked”, allowing them to appear to be worn under / over one another, as shown in the images below.

Multi-wear in most viewers: adding an item (in this case a shirt layer bustier) to a layer with clothing already worn will see the new item worn “over” any clothing on the same layer
Singularity’s Move Back and Move Forward inventory options allow the order of clothing items worn on the same layer to be changed relative to one another


  • The menu options are context sensitive and will only be available for clothing items worn on the same layer
  • Which of the options is available for use depends on a clothing item’s position in the “stack” (e.g. if the item is the last item added to a layer, the Move Back option only will initially be enabled, but not the Move Forward option)
  • The options can be used with any number of items worn on a single layer (up to the standard maximum of 5 items per layer)
  • Any changes you make to the order of clothing items in the same layer will be correctly rendered in other viewers.

This should provide a very flexible way of additionally creating “mix’n’match” outfits. Kudos!

Along side of multi wear, Singularity 1.7.0 also provide full support of the Current Outfit folder as well.

Audio Display Floater

Accessed via the Singularity menu (Singularity->Streaming Audio Display), this displays a floater listing the artist and track name for any active media.

Audio display floater

Mouselook Aim / Zoom and Shift-C Crouch

Those into combat are likely to appreciate these additions – although they are not exclusively for such environments.

  • Mouselook aim / zoom: when in Mouselook, depressing the right mouse button and using the scroll wheel on a mouse, can zoom in / out of the direction you are looking
  • Pressing SHIFT-C will now toggle your avatar into a crouch until such time as you press SHIFT-C again, allowing you to move and do other things without having to hold down the C key yourself.

Build Preferences

The Build tab in PREFERENCES->SYSTEM has been extensively updated, as per the images below, offering users the ability to set global defaults on prims as they are rezzed and used (i.e. default texture type, permissions set against them, etc).

New Build Preferences


Running Singularity on my home platform (370m) with lighting and shadows off, Singularity rolled along at an average of 39-40 fps. With lighting & shadows active and sun/moon + projectors enabled, this dropped to 12-13 fps. On the ground on my home sim, these rates dropped to 7-8 fps with lighting and shadows, etc., on and around 17-18 fps with them off. Again, and while totally arbitrary, the tests were carried out on my usual system and with all other settings as defined in the panel on the right of this blog’s home page. Overall, the performance wasn’t far behind what I’ve seen on the new home sim with recent V3.2 viewers.


As with the last release of Singularity (1.6.0), this is a long-awaited and tidy update. Feature changes may appear small – but they are by not means trivial. Much has been done to “future-proof” the viewer, although the Merchant Outbox functionality is still currently lacking.

What I particularly like in this release is the way in which multi-layer system clothing support has been implemented. The ability to alter the order of the clothing on a specific layer is very neat and a step ahead of other viewers – and is something that could prove very popular among users. It will be interesting to see if it appears in other TPVs moving forward.

For credits on the various elements and additions to this release of Singularity, please refer to the release notes (link below).

Related Links