Kitely offers world-to-world teleports, expanded Viewer support

When I reviewed Kitely, the on-demand virtual world mid-month, I commented on the lack of world-to-world teleports and a couple of problems I encountered with the Viewer plug-in. The ever-vigilant (and ever-helpful) Ilan Tochner from Kitely contacted me to let me know that both a new version of the plug-in and world-to-world teleports were in the pipeline and would be available “soon”.

Little did I realise that by “soon” he meant before the end of the month!

Yesterday, Kitely’s Oren Hurvitz announced that both world-to-world teleports and a new Viewer plug-in, complete with expanded Viewer support had been rolled out. The blog announcement reads in part:

Teleport Between Kitely Worlds

Teleporting between Kitely worlds finally works! If you try to teleport to a world that is online then you’ll be teleported to it immediately. If you try to teleport to a world that is offline then the world will be started; you’ll remain active in the world you are currently in; and once the destination world is ready you’ll be teleported to it automatically.

Teleport options include:

  • Pressing the Enter World button on the World page for your desired destination
  • Clicking on a region in your viewer’s grid map
  • Searching for regions inside your viewer and requesting to teleport to one of them
  • Opening a Landmark from your inventory and using it to teleport to the landmarked location
  • Accepting a teleport offer from another user.

This is an excellent move, and one that many have been waiting for. However, it’s probably fair to say that even more welcome is the news that the Viewer plug-in has been overhauled and provides both new features and expanded Viewer support.

Required Upgrade

The new plug-in is a required update, and the process is very smooth. If a Kitely user hasn’t updated, they’ll be informed they must do so, together with a concise 4-step set of instructions, when they click the ENTER WORLD button on any World page. The steps comprise:

  • Downloading the plug-in
  • Closing all  browser windows
  • Installing the plug-in
  • Re-starting their browser

Simples!

The new plug-in now automatically supports some of the most popular Viewers available:

  • Catznip Viewer
  • Dolphin Viewer
  • Exodus Viewer
  • Firestorm
  • Imprudence
  • Kokua Viewer
  • Nirans Viewer
  • Restrained Love Viewer
  • Second Life Viewer

Firestorm Default

The Kitely default Viewer has also changed. for those who have no Viewer installed on their computer when they attempt to enter a world, Firestorm will now be downloaded, replacing Imprudence as the default. There are very logical reasons for this: Firestorm supports both mesh and media-on-a-prim, both of which are seen as important tools for in-world use. It’s also fair to say that with the latest release, Firestorm offers potentially the most flexible UI of any Viewer, and should sit well with those users who like the V1-style UI (available through the “Phoenix” mode) or a customised V3.2 UI. I spent some

I certainly applaud the team for the move – and for expanding the list of supported Viewers to include the other top TPVs, allowing users a very wide choice which includes potentially the best two Viewers for photography and / or machinima: Exodus and Niran’s.

Change Your Viewer from the Settings Page

Your choice of Viewer can now be easily changed from your Kitely Settings page:

Change Viewer through the Settings page

Accessing Kitely Directly from a Viewer’s Grid Manager

With these updates, it is now possible to start Kitely directly from a Viewer – although you will still have to ensure the world itself is running first via its World page.

Details on configuring a Viewer’s Grid Manager can be found on the Kitely website (which also includes instructions for configuring Viewers without a Grid Manager).  Once this has been done, the steps to enter a world are:

  1. Go to a World Page and click “Enter World”.
  2. Once the world is ready, you’ll be asked to start your viewer.
  3. Start your viewer; select Kitely in the grid manager; enter your login information.
  4. Click “Login” to log-in to Kitely and your selected world.

These changes bring new flexibility and new capabilities to Kitely, and have been warmly received by users.

Related Links

Direct Delivery: Restrained Love and Dolphin with Merchant Outbox

Update April 1st: Dolphin Viewer has been updated to 3.3.1.23706. Percipal updates comprise the Kokua mesh uploader (Nicky Perian), Firestorm’s ability to attach a short message to avatar-to-avatar payments, and some fixes to the gstreamer audio playback and client-side AO.

This week sees the Restrained Life Viewer and Dolphin Viewer gain Merchant Outbox functionality for Direct Delivery.

Restrained Love 2.8.3.1

The V3.2-based standalone version of Marine Kelley’s Restrained Love Viewer is built on the standard V3.2 code, with a number of UI improvements. Marine develops the Windows version, with Kitten Ninetails maintaining the Mac and Linux versions.

As well as the arrival of the Merchant Outbox, this version sees a number of updates and fixes to the Restrained Love capabilities within the Viewer, all of which can be found listed on Marine’s blog. In testing the Merchant Outbox on the Windows version, I found it worked without any problems, while the revision to the position of the draw distance slider helps make this more usable.

Dolphin 3.3.0.27000

This release brings with it support for the Merchant Outbox for Windows, Mac and Linux. In addition, as an added and welcome tweak, Lance has doubled the length timeout on the Outbox so disconnects should be less frequent than may be experienced in other Viewers.

The remaining updates comprise:

  • The “RLV Height offset” slider is now wide enough to be properly functional, and has a reset button.
  • A checkbox to disable rendering of attached light sources has been added in Preferences->Dolphin Viewer 3->Graphics.
  • A fix for scripted sounds from FireStorm has been imported that makes scripted sounds play correctly the first time.
  • Codebase has been updated to official 3.3.1 source from SnowStorm.
  • RLV has been updated to 2.08.03.01.

Performance

Both of these Viewers are using the latest 3.3.1 code release from LL, which has yielded some stunning results on my “regular” system. Together with the latest SL Viewer (3.3.0 (251182)), I experienced the following frame rates on my home sim with 4 others present on the same region:

  • Average fps, no-deferred / no shadows, @ 390m: 45fps
  • Average fps, no-deferred / no shadows, @ ground level: 36fps
  • Average fps, deferred / shadows active, @ 390m: 20fps
  • Average fps, deferred / shadows active, @ ground level: 18fps

While visiting a popular store (Graves main store), with seven other avatars present, my frames rates were: 32 fps with deferred rendering / shadows off, and 14fps with deferred rendering and shadows on. Taken together and in terms of running with lighting / shadows enabled, these figure represent the best results I’ve had for any Viewer running on my PC, and leave me hoping that similar improvements will be seen in other Viewers as they cut over to the 3.3.1 code.

Related Links

Marketplace listing errors: LL needs to speak up

Update April 1st: LL issue revised DD migration deadline and updates on JIRAs related to Marketplace issues. 

For the last several days, there has been a serious issue with the SL Marketplace. I’ve reported, with updates, on the matter – as have others. The problem, which as I’ve noted in my original blog post, includes:

  • Listings on Marketplace stores do not match the actual items
  • Incorrect merchant attribution (products from Merchant X listed as belonging to Merchant Y, despite appearing in Merchant X’s store)
  • Products from one merchant appearing in stores belonging to other merchants
  • Items incorrectly priced
  • Incorrect ratings assigned to products (G-rated items appearing as Adult, etc.).

Note that a full list of JIRA on Marketplace issues is also available via Sera Lok and Sassy Romano.

Advice and feedback from the Lab on the issue has been sporadic at best. On the plus side, we have had a welcome apology for errors in the support team relating to the issue. However, feedback within the forum thread on the issues has otherwise been restricted to an attempt to provide advice on the issue which unfortunately, it doesn’t appear to work. Elsewhere, feedback has been restricted to a brief Grid Status page remark.

And therein lies a problem: many are completely unaware that there is an issue. As a result, we’re starting to see:

  •  Rising levels of accusations of “theft” among merchants as they come across what appears to be their own goods being listed by others
  • Well-intentioned customers raising concerns of product theft with merchants when they see incorrectly listed items
  • Growing concerns and confusion being voice through various product support groups in-world.

Linden Lab are somewhat caught between a rock and a hard place here. They are obviously trying to resolve the situation as quickly as possible, and in a manner that won’t in itself lead to further issues and problems: hence why calls to suspend the Marketplace appear to have gone unanswered. We simply do not know the extent of the issue and it would appear that there are at least as many merchants unaffected by the problem (such as myself) as there are merchants impacted by it. Therefore, it is entirely possible that were LL to suspend the Marketplace, the resultant uproar might be even greater than the upset the issue itself is causing.

However, LL do need to be more proactive in communicating the issue – not all merchants routinely read the Merchant’s forum and not everyone reads the Grid Status pages (unless there is something very noticeable “going wrong” in-world, such as teleports failing, rezzing issues, etc). Hence why the levels of misunderstanding are growing.

If the issue cannot be easily resolved – and this would appear to be the case, then more direct communication on the matter  – via e-mail, through all available channels such as the Land and Business blog, etc., would appear to be of an increasing necessity. The e-mail / blog post doesn’t need to delve into specifics but should at least outline the problem and indicate that the Lab is actively seeking to resolve the issue. Doing so would ensure merchants are informed, and potentially go a long way to stemming accusations of “theft” and / or fear of “copybotting”.

On a broader front, being seen to provide information would also help stem the rising tide of anger being directed at the Lab over this issue. Alongside the calls to suspend the Marketplace have also been calls to roll back the Marketplace database to a prior to this problem arising. There are more than likely practical reasons as to why this cannot be done; however, by not acknowledging such calls and at least outlining why a roll back cannot be done – or why there needs to be further investigation prior to committing to a roll-back if it turns out the idea is feasible – would again so much to lessen the resentment that  customers are feeling towards the Lab at this point in time.

It is again in situations like this where Linden Lab do themselves no favours, something I’ve recently touched upon. There are times when silence simply doesn’t work – yet all too frequently, silence is the main tool the Lab uses in dealing with a situation. It’s also an approach that reinforces the negative attitude many people feel towards the Lab, justified or otherwise.

Linden Lab has channels of communication open to it – and where e-mail is concerned, it’s not as if they’ve not used that channel to reach out to merchants in the past. Given the fact that even now, three days after the initial problem was first noticed, some people are still only just finding out about the problem – and in some cases leaping to the wrong conclusion – an advisory posted to the blog and / or e-mailed to merchants would seem to be a practical step to take, particularly as we are now facing the weekend with absolutely no indication as to whether the matter will be resolved sooner rather than later.

Related Links

Pathfinding: Main grid beta commences

Coming on top of the request for region owners to involve themselves in pathfinding testing on the Main grid (Agni), Linden Lab has announced a broader public beta being commenced on Agni, using fifteen of specially configured sandboxes:

Note that access to the four Snack regions is dependent upon joining the Second Life Beta group.

Looking across Limia and Arowana: suitable for pathfinding vehicle testing on land / water

Pathfinding Viewer

Beta tester will require the Pathfinding Project Viewer, of which two variants are available:

Formal Call to Region Owners

Owners for full regions can still involve themselves in the beta. Those wishing to do so are requested to:

  • E-mail pathfinding-beta@lindenlab.com from the e-mail address associated with your account
  • Include your account name and region you want added to the beta.

Related Links

Another view of Arowana and Limia

Marketplace error – incorrect listings

Update 23:40BST: Sassy Romano and Sera Lok have published a list of JIRA related to this and other core Marketplace issues (including Direct Delivery).

Update 23:20BST: It is still being reported through various forums and blogs that LL have “stopped” supporting Magic Boxes. This isn’t the case; rather, there appears to have been a communications breakdown within LL that has lead to an incorrect Support message being sent out. As a result of this error, which occurred this morning, Commerce Team Linden posted the following assurance at the time:

“We are so sorry for this response. We are reaching out to you directly to help you with this issue and are already working to make sure that everyone in support is aware that we will continue to support Magic Boxes until they are officially retired. Thank you for bringing this to our attention”. [My emphasis]

So, Magic Boxes are still supported, and will continue to be supported, and issues with them should continue to be reported. 

Update 20:15BST:According to current feedback, the scheduled SLM maintenance did not address this issue, although there was no guarantee it would. That the maintenance was initially rescheduled to Monday April 2nd might be indicative that a resolution is in development.

There appears to be a major error with the SL Marketplace.

Merchants are reporting that listings are giving incorrect product attributions, linking to other merchant’s stores, etc.

A JIRA (WEB-4587) has been raised on the issue, which is being looked into as a “top priority” by Linden Lab. If you are merchant with SLM listings, and have not been aware of this issue, it would be advisable for you to check your store listings.

Key issues include:

  • Listings on Marketplace stores do not match the actual items
  • Incorrect merchant attribution (products from Merchant X listed as belonging to Merchant Y, despite appearing in Merchant X’s store)
  • Products from one merchant appearing in stores belonging to other merchants
  • Items incorrectly priced
  • Incorrect ratings assigned to products (G-rated items appearing as Adult, etc.).

Further, it should be noted that:

  • It appears that even if your own listing do not appear impacted, it is possible your products are still being listed in other stores
  • Items previously correctly impacted can be impacted as a result of updates
  • The problem is not limited to Direct Delivery items, but is affecting both items migrated to DD and items still in Magic Boxes

Note: In the course of writing this article, scheduled maintenance for the Marketplace changed from being postponed from today until Monday April 2nd, before again being scheduled for today (Thursday March 29th) at 10:30am PDT

Related Links

Communications: It isn’t always the Lab

I’ve been somewhat critical towards Linden Lab were their overall approach to communications is concerned – although I’ve tried to temper my critiques with practical suggestions as to how things might be improved. I also hope that I’m not backward in coming forward to acknowledge those times when they do go out of their way to make the effort – such as with Oz standing front-and-centre regarding the recent TPV Policy changes.

However, when it comes to communications and impressions, the Lab is only one side of the coin. Whether we like it or not, we, as users can be as much to blame for the poor state of communications; we are quick and loud to anger when the Lab errs – or more particularly – is perceived to have erred, and we are equally slow to forgive.

I give emphasis to the concept of perception deliberately here. While there are times when taking the Lab to task may be justified, equally there are times when it is automatically assumed that whatever has happened, the Lab has acted with malice aforethought in a deliberate attempt to nefariously ruin the Second Life experience. Often in these circumstances, even the presentation of the most reasoned argument to the contrary will not prevent such views being publicly repeated to the point where the act of repetition itself establishes them as “fact”.

This was recently brought home to me once again by three inter-related incidents relating to a single code change that impacted a very specific use-case for RLV.  In all three, which included a wider exchange I had with someone in Tateru’s blog wherein the claim was again made that LL is a malicious entity, people were insistent that the code change was nothing less that “obvious” proof that LL were attempting to deliberately “break” RLV – and any evidence to the contrary was summarily dismissed.

It mattered not that the code change in question was a) limited in impact (one specific use of RLV restricted to two RC channels on the main grid); b) rolled back by Linden Lab at the earliest opportunity following a JIRA being raised; and that c) even if the underpinning issue itself couldn’t be fixed by LL, Marine Kelley (RLV’s creator) reported that it could be circumvented from within RLV. So the issue as a whole was hardly going to “break” RLV; nevertheless, people had made up their minds, and no discussion to the contrary would be heard  – even after the code change itself had been rolled back.

It’s a similar story with the mesh parametric deformer, where rumours are circulating that LL is trying to “kill” the project simply because they do not appear to be working on it; rumours that recently prompted Oz to comment on matters. Here the assumption is that  because Qarl released an alpha version of the code in January but it has yet to appear in the official SL Viewer, then LL must be trying to stop the project. That in the intervening months Qarl himself has been soliciting feedback from the community and refining the code, and has made further releases – any of which could have been adversely impacted by LL taking the code and developing it themselves – makes little difference to those who see LL’s lack of activity on the project as being somehow malicious.

I’ve dealt with the whole “LL is malicious” nonsense in both the recent and not-so-recent past, and I’m not going to re-harsh what I’ve said on those occasions now.  While it is right and proper to be critical of LL when the company does demonstrate poor judgement, it is also fair to say that there is also an onus on many within the community to stop treating every action or comment from Linden Lab as being adversarial in nature and / or intent.

Communications run both ways. While the onus is, as I’ve commented before, very much on LL needing to take the initial steps and start focusing as a company on more open and pro-active communications directly with the user community as a whole; it is equally important that we be prepared to lay aside subjective prejudices and preconceptions and make the effort to meet them half-way. Because if we don’t, then frankly, communications in either direction are liable to remain as dysfunctional as they’ve ever been.