Category: Viewers

Making an Ascent on Second Life

Posted on by Inara Pey

While Phoenix remains by far the most popular of the Third Party Viewers on offer for use with Second Life, a new arrival in the last couple of months is beginning to show some promise – particularly when it comes to implementing features from the Viewer 2.x stable – and which again, like Phoenix and Imprudence, does not require the initial installation of either the “official” 1.23.5 or Snowglobe Viewers as a prerequisite to its use.

Ascent has probably caused some eyebrows to rise, given it is apparently based on the Inertia Viewer code base. Inertia was a non-TPV compliant Viewer that was developed by the infamous “Hazim Gazov” – who was by turns, banned from Second Life by Linden Lab, the “whistle-blower” who first started to “reveal” genuine concerns around the Emerald Viewer (while also sharing in the rumour-building) and who was the target of Phox’s failed (and idiotically suicidal as well as moronically childish) DDoS attack which was in part responsible for Emerald being “banned” as a Second Life Viewer. Ascent is now maintained by one Charley Levenque, aka Charlotte Wirtanen, an unknown quantity in both cases, although in the latter guise, has been around since 2006.

Now to the Viewer itself. The setup EXE downloaded smoothly. It did cause a raised eyebrow, however, as it came in at almost twice the size of the likes of the Phoenix, Imprudence and other 1.23.5 Viewers – although I’ve been informed this is often the case with Viewers based on the Snowglobe code, which apparently forms the foundations for Ascent. An anti-virus scan revealed nothing untoward in the EXE (not entirely unsurprisingly) so I went ahead and ran it. As one would expect from a TPV of this nature, the overall installation was quick and clean, ending with an option to run Ascent at once.

The splash screen showed the Ascent download page, and was in the “official” blue skin display. Logging-in revealed the familiar 1.23.5 UI – but with the ADVANCED menu already listed on the menu bar, so no need to press CTRL-ALT-D.

At first glance, Ascent looks little different to the likes of Phoenix, Imprudence and others: the menu bar and toolbars along the bottom of the screen are largely unchanged, the in-world View is obviously the same – but just a little digging reveals that thought has been put into making Ascent not only different to other TPVs – but potentially more useful.

Clicking on COMMUNICATE, for example reveals several new features. At the top of the CONTACTS list is a CONTACT SEARCH box. Enter the first few characters of a name here, and a list of matching contacts is displayed. Type in a full name, and just display that avatar. Above this is a CONTACT GROUP drop-down, although functionality for this appears to be awaiting implementation. Replacing the Import / Export buttons found in the CONTACTS list of some Viewers is a count of the number of Contacts one has (and the number actually online), and a count of the number currently highlighted within the list. The Search function I can see being very handy for those with massively long Contacts lists – such as store owners – who need to contact someone quickly.

The RADAR (Avatar List) window offers the same functionality as most of the TPV’s that now include this function ported originally from Meerkat. However, unlike Phoenix, Ascent still includes the majority of avatar functions as a series of buttons at the bottom of the display, rather than moving them to a context menu displayed when right-clicking an avatar’s name in the list. When originally introduced into Emerald, this latter functionality caused divisions among users: people either accepted it, or demanded the return of all the buttons. Phoenix has something of a compromise, in that some of the buttons are back at the bottom of the screen; however, I find the context menu just fine, and personally think that Ascent has taken a step backwards here: the Avatar List is a useful tool in many ways, but Ascent’s simply takes up too much screen real estate.

BUILD incorporates functionality found in other TPVs, albeit relabelled. For example: the ability to OPEN the Group profile for a selected object is called VIEW. A nice touch on the Build menu is that when editing linked parts of an object, the “Selected Objects” count common to some other TPVs is replaced by a “Link number” display, as shown on the left. This functionality can be found in “Experimental” releases of Imprudence, but of the standalone installation TPVs, Ascent is the first to offer it in a “full” release.

For people utilising scripts that handle primitive counts to set a specific prim to a specific display (say, lettering on a scrolling prim notice), this strikes me as a useful little feature, and one I’d like to see pop up in other viewers.

INVENTORY offers pretty much the standard fayre for good TPVs, including the ever-handy RESTORE TO LAST POSITION option in the event you TAKE a linkset back to inventory, only to find you’ve missed linking a couple of prims. God knows, *I’ve* needed it enough!

Preferences

As with the majority of TPVs it is in the Viewer Preferences that Ascent shows clear differences. All the usual tabs are there: General, Input & Camera, Network, Web, Graphics… and so on. Two two unique tabs here are ASCENT SYSTEM and ASCENT VANITY.

ASCENT SYSTEM offers a number of additional tabs – less than the likes of Phoenix – each with either a less confusing array of options, or with options that have been better-organised. In summary:

  • General: offers a subset of functionality found in the TP/Login tab from Phoenix and others (double-click teleport, always allow fly, always rez under land group when available, as well as several Ascent-specific functions:
    • Enable Power User functionality: “unlocks” the ability to set an animation priority up to 7, rather than the usual limit of 4. How this is reflected when said animations are used in other Viewers is unclear.
    • Destroy Objects: anything you have the power to DELETE is deleted permanently, bypassing the Trash can.
    • Explode Objects: temporarily renders an object physical and then delinks it.
  • Chat/IM: neatly combines the more welcome elements of the IM and CHAT tabs again found in other TPVs, providing access to options such as allow MU* poses and auto OOC actions in chat; turning off the typing sound for chat, use vertical IM tabs, toggle the announcement of incoming IMs. This tab also includes the very useful Auto-response option for IMs, and (for some reason) includes options to display the time in either 12- or 24-hour notation and the date in US or European formats.
  • Performance: captures the progressive draw distance option from other TPVs, although without the slider bar to adjust. It also includes:
    • An option to turn off the annoying wind howl, pulled up from the Windlight settings and made easily accessible
    • The ability to turn off the Classic Cloud layer (the one that exists at around the 200m level) at log in, rather than having to twit around and find the option in your Windlight settings. I’m very in favour of this, as it does lead to a nice little performance boost.
  • Command Line: sees a subset of the text short cut commands available through the likes of Phoenix continued in Ascent.
  • Security: gathers together the more innocuous options from Emerald’s infamous “shield” options, presenting the user with a degree of privacy without going too far in the direction of impinging on the privacy of others.
  • Building: offers a subset of options originally found in the Emerald Build tab.

ASCENT VANITY gathers together the kind of settings one might like to set for one’s various avatars (if you happen to have more than one), and includes options to set tag and map colours to highlight friends, etc., as well as turn things like the teleport screens on/off or set breast and other dynamics.

Ascent does away which much that has in the past been looked at as controversial in some Viewers: IM encryption, for example is not present, nor are some of the more intrusive options to bounce in on people. It does have a couple that some may yet object to, although in the scheme of things, they are trivial. The first is the ability to fake your AWAY status – when active, AWAY will say visible in your tag even while you are camming around or engaging in IMs with others, etc. The second is the ability to see how long the people around you have been inactive.

Elsewhere, the pie menus have been reordered somewhat. Imprudence did this as well, with the aim of rationalising the pie menus and making them flow more logically – and it succeeded. It also offers the option of reverting to the more familiar pie menus if people have trouble getting their heads around the reordered versions. Ascent both reorders and adds functionality. I had no problems with the pie menus, but I can see those who want “all the latest but leave it as it is” bemoaning the pie menus at times.

Viewer 2.x Functions

As one would expect, Ascent includes Viewer 2.x’s Alpha Mask and Tattoo layer support – so no surprises there. What is a very pleasant surprise, however, is the inclusion of the Viewer 2.x multi-attachment support for prim attachments. This means that you can now wear multiple items on the same attach point (multiple rings on one HAND, for example)  – and have them render correctly in all Viewers. This is a major step forward when compared to the likes of Phoenix and Imprudence – and the work in getting it into Ascent is largely down the Henri Beauchamp. With multiple clothing layer support also promised (i.e. wear 2 jacket layers at the same time), this puts Ascent head-and-shoulders above other TPVs of its kind.

Beyond this, Ascent has the welcome inclusion of a client-side AO, the ever-useful Area Search functionality, and just about everything else that has proven useful in other TPVs. If it lacks anything at all, it is potentially that the Radar / Avatar List doesn’t include the additional listing fields found in Henri’s CL Viewer and, more to the point for many within SL, RLV/a support is lacking at the moment (although it is on the “to do” list) – which seems to be an odd feature to miss out.

There are a couple of functions I don’t entirely understand – such as using the “Ascent System Inventory”, which adds a couple of additional folders to the Inventory window whose precise function is unclear to me. Are they intermediary way points for uploads, located on Ascent’s own servers? The option to upload temporary textures suggests this – in which case, I have to admit to being leery of the functionality. I’ve searched the Ascent wiki for further information here, but have drawn a blank. “Downloading Inventory in the background” also seems to be an odd option. How is this different to the usual inventory caching, which is already dynamic and a background task?

Performance-wise Ascent feels a lot more stable than the likes of Phoenix, and certainly comparable to the “full” release of Imprudence. For me, it scores over the latter in having a wider range of skin options, and also retaining the more usable “large” Avatar List. Although it does miss out in not having a spell checker.

Ascent also appears to run somewhat faster (for me) than the official 1.23.5 Viewer, Imprudence and Phoenix. In comparison with the latter, my preferred Viewer at the moment, Ascent runs at around 10-12 fps faster on a “busy” sim and about 15 fps faster on a “quiet” sim. I have no idea if Ascent is SSE optimised, but overall the performance is good.

I have noted a couple of very minor issues, and given I’ve only been fiddling with it for 24 hours will doubtless find things that will niggle me – but currently, the fact that the Tp screen still momentarily flashes up, despite my setting the option to disable it and relogging after – does cause a frown, if nothing else.

Overall, Ascent is a commendable effort; I’m not qualified to look under the bonnet, so to speak, but from a pure user perspective, I have to say that it has the potential to become a Viewer of choice when certain other functionality has been added. That said, I would prefer to see higher visibility where the developers are concerned before I committed to a full jump to Ascent – and again, kudos to Jessica over at Phoenix in this regard. Nevertheless, providing no unpleasantness emerges around Ascent (one feels there should not be any, but the pedigree of  the Inertia viewer hovers in the background), Ascent could come to easily rival Phoenix in the TPV environment. It is already off to a very good start.

Viewer 2: Finally starting to show promise

Posted on by Inara Pey

Viewer 2.2 is now out and available – and it is finally starting to look like something many people can live with.

The ability to customise the interface has long been a bugbear in all iterations of the Viewer; and while we still cannot reasonably expect to be able to fiddle with things to the Nth degree, the ability to re-order things like the on-screen buttons is a step forward. We don’t all work the same way, we don’t want to do the same things – we’re not all right-handed or left-handed, much less all left-, or right-brain dominant – so this is going to help many reorganise things into a way that they feel is more logical and easier to use when it comes to their needs. Kudos, at last.

Similarly, the ability to float options away from the sidebar is a good step forward – although it seems from comments that the sidebar still remains the focal-point of the “new” Viewer, and not the in-world view; so my personal pet peeve with the Viewer remains.

It’s also nice to see the promised two-way “dialogue” between TPV developers and LL start to yield fruit, with tools we’ve seen commonplace in several TPVS – texture alignment, Google-powered translation, etc., – finally entering into Viewer 2; may snowstorm result in much more of this – and in both directions.

It’s also nice to see some major idiocy in the Viewer finally disappear, seemingly despite LL’s repeated refusal to initially listen and then simply drag their heels after admitting the problem(s). That parcel icons are now on by default is welcome news so is the ability to turn off scripted lighting and particle generators. Given the amount of resistance shown by LL to do the former, I wonder who took Esbee or someone outside and gave them a firm talking-to?

The reaction to the new Viewer has, overall, been positive in the comments following Esbee’s post, and there have even been some very good suggestions put forward for future improvements. I would hazard a guess that, unless said suggestions find their way into a TPV from a third-party – such as Kirstenlee’sS20, which still outstrips Viewer 2 and offers a (largely) genuine pleasure of a Viewer experience – and thus potentially into Snowstorm, I seriously doubt that they’ll be taken anywhere by Esbee et al.

Are these change enough to get me to jump ship from 1.23.5? Well, to be honest, no, not quite yet. I am curious to see if Marine updates her initial cut of the RLV-enabled version of Viewer 2 she put out on the 10th Oct, and which appears to be based on the Viewer 2.2 code as it stood then; whether changes were made to the base code between the 10th and yesterday’s release is beyond me. If she does, I’ll give things another look; but I’m still very attached to Phoenix – not just because of RLV, but because it still offers capabilities that are extraordinarily handy when keeping an eye on sims and tenants. These far outweigh the bells and whistles offered by Viewer 2, such as media-on-a-prim (which itself seems to have fizzled out like a wet firework rather than illuminating Second Life like a night-time space shuttle launch). As to the really useful features of Viewer 2: Alpha Masks, Tattoo Layers – they are already in the majority of TPVs, and so are hardly an encouragement to make the jump elsewhere.

So where is my incentive to move? Multi-attach / multi-wear? Very nice, but not actually essential, given how long I’ve lived without them – and certainly not worth a trade-off with that bloody sidebar barging out onto my screen without me cluttering-up world-view real estate with minimised windows torn off from it. And then we have the biggie: does search actually work in Viewer 2 now? I’ve honestly lost track of that situation.

Which really means my personal analysis of the latest release is really, “Congratulations, LL on getting a new usable Viewer out there for people. Pity you opted to push the code through the door eight months premature; you’ve still left yourselves a big mountain to climb in the eyes of the more cynical as a result of that mistake. But – well done, all the same, for keeping to your promise vis Snowstorm”.

The Green goes

Posted on by Inara Pey

Linden Lab have sounded the death knell for Emerald.

Well done, Phox (I wonder if that was an infantile play on “pox”). I sincerely hope a real lifetime ban follows for you, and Fractured Crystal. Not that I begrudge you anything, you understand, its just that – well, SL will be a lot more savoury without you.

For those panicking about their favourite Emerald features – fear not and look here. The future is bright. The future is winged….

Phoenix has now cleared self-certification (and do I ever wish some people would understand that term does not mean “approved by Linden Lab” or even “approved”!), and is now listed on the entirely voluntary TPV Directory.

So – onwards and forwards!

Addendum

Within 12 hours of appearing on the TPV Directory listing, Phoenix had achieved some 50,000 unique logins to Second Life. While a portion of these are going to be people running alts and potentially “bots”, the vast majority are going to have been unique users. As such, this is an extraordinary figure to hit in a so short a period. And without wishing to stir the Viewer 1.23.5 vs Viewer 2.x debated, one has to admit that it does show how loyal established users (who are the most likely to be aware of the entire Emerald debacle) remain to the older Viewer, despite LL’s best efforts at enticement, cajoling and denial.

Rising from the ashes

Posted on by Inara Pey

As Phox/Fractured leads those who listen into self-immolation, a new Viewer rises from the ashes in the form of Phoenix.

As Jessica Lyon announced:

My name is Jessica Lyon. My goal during my time with the Emerald Project, was always to give the users what they want. That goal has never and will never change. I’m very happy to announce, it continues…

A few days ago, I assembled a team of developers to work on a new viewer. Some who were originally Emerald developers, some who were not. All are respected reputable residents in the SecondLife Community. The goal was simple, to provide users with what they want and do it transparently.

I’m am very proud to announce the launch of the Phoenix Viewer. This project, has started off simple, with it’s initial release of a safe clone of the Emerald viewer. Users want Emerald features, you shall have them. We have big plans to expand to the Snowstorm project as well. We have already applied for the TPVD, to which we have no doubt we will be accepted in a timely fashion. We have already started making in world groups for support, (Phoenix Viewer Support), beta testing etc. There is much more to do… however…

This Viewer is ready for use by you, right now!

For this project, I insist on, and everyone on this team insists on 100% public transparency in EVERYTHING we do. We have already established a public IRC Dev chat, public repo and are working on much much more.

Our developers are; (in alphabetical order), Dakun Flux, Dimentox Travanti, Jessica Lyon, Kitty Barnett, LordGregGreg Back, Techwolf Lupindo, Tonya Souther, Vortex Saito, Wickman Gibbs, with more to come.

Our Lead Developers are: Dimentox Travanti, LordGregGreg Back, Techwolf Lupindo, Tonya Souther.

Ed Merryman will be leading our support team: Aleia Sapphire, bee Baroque,  Damian Zhaoying, Ed Merryman,  Marybeth Oceanlane,  Mindy Spiritor,  Nisa Maverick, PixelProphet Lane,  Toy LaFollette, Vortex Saito, Whirly Fizzle, Wolfspirit Magic.

Our website is still in progress, however we have up the required links.
Downloads.
I am very pleased and excited about this project, and I hope that you will be too.

Sincerely,

Jessica Lyon and the Phoenix Viewer Development Team.
My personal blog: http://jessicalyons.wordpress.com

This is potentially momentous news. Phoenix looks to incorporate some worthy individuals: Jessica, LordGregGreg Back and Kitty Barnett of RLVa fame.

As Jessica’s note explains, this is an initial release, based on “safe” Emerald code. The current iteration lacks many of the options that can already be found in LGG’s Emergence, but doubtless these will come in time as Jessica states. Most interestingly, the group are stating they’ll be looking to work with the Snowstorm project.

Currently, Phoenix is not on the TPV List, but the paperwork has been submitted and there are also some issues around the code repository that need to be resolved – the links don’t currently work (20:00 BST, 3rd Sept). However, for all those worrying about the future – given that, despite what has happened, Emerald did have a highly-effective list of functions – it would appear a Viewer of equal capability is now available.

I, for one, wish it every success and a drama-free future!

Out with the globe, in with the storm

Posted on by Inara Pey

Note: Following this post being published, Esbee Linden made a formal blog on the subject on August 17th

In his address at SLCC 2010, Philip made mention of “standardising” the viewer platform. At the time I was curious as to what this might mean and asked a speculative question or two. Later, during SLCC 2010, Q Linden (whom I hope makes a full recovery from his stroke) and others gave more insight into what is going to be happening, and Oz Linden posted an announcement on the opensource dev list (thanks to Argent Stonecutter for the link).

Q’s opening of the SLCC presentation was somewhat enlightening, in that it confirmed many people’s views that Viewer 2.x proceeded along a development path that was simply far too rapid. In fact he candidly admits that it was developed and rolled out to meet a given schedule, rather than when it was “ready” (in November, for example, a meeting was held in which the “to do” list of outstanding work on the Viewer was cut down to a list of things that could be done in the remaining time frame prior to the release of the Viewer.

He also admits that Linden Lab erred when preparing the ground for Viewer 2, in that they didn’t create sufficient use cases to reflect how the Viewer is actually used in-world (that LL needed to “invent” user types in order to build the use cases in the first place also surprised me. After all, what are we out here, if not users?). The upshot of this is an admission that the overall capabilities of Viewer 2 are too narrowly focused.

This may sound like a “well, duh!” statement – but I think it fair to say that such an admission from the development team is somewhat refreshing. It’s not often the Lab or its employees own up to mistakes, and Q’s comments do add up to a strong admission of  having erred, and a hint that the lesson has been learned internally, “For marketing reasons we felt we wanted to keep it secret and we wanted to release it in a kind-of ‘ta-da!’…I think you won’t be seeing any more of that sort of behaviour from us any more! Yes, I hear the applause, thank you!”

Following this, Esbee went over the new methodology for Viewer development – Project Snowstorm, which has the core aim of rapid, effective deployment of new features and functionality. Essentially, and as hinted at by Philip, this will be achieved through meeting three goals:

  • Weekly, visible progress on the Viewer – which not so much is focused on weekly releases per se (although that is something Philip indicated he’d like to see), but more a case of making the development process more visible too all, including users being able to attend development meetings
  • Improving the user experience – hitting Philip’s requirements of Fast, Easy, Fun (a slogan I *still* loathe, but there you go)
  • Revitalising the open-source community

It is this last point that is the most interesting and – if carried through  – marks a radical change in Viewer development; one that would seem to have many potential benefits – and not just for Linden Lab.

The core of this new approach is that Viewer development will be somewhat streamlined, with LL themselves working on specific elements of the Viewer while leaving things open so that third-party developers can engage directly with the LL team and take on development of a given aspect or function within the Viewer, and developers with existing fixes or functions that could benefit the Viewer can deposit their work with the team for potential integration into the Viewer.

This effectively means the end of Snowglobe, the open source “version” of the Viewer code.  To quote Oz Linden, “The main Linden Viewer is now completely open source…the source code is available on a public repository…NOW!” What is more is that this repository is to be the central “integration repository” where all code from Linden Labs will go prior to integration into the Viewer.

Alongside of this is the re-licensing of the code from GPL to LGPL – which, if I am understanding things correctly, means that it will be both easier to incorporate the Viewer code into other Viewers (I assume those that can be used on OSGrids and the like) and – particularly from LL’s point of view – will make the licensing of the code for use in “closed” third-party Viewers significantly easier, potentially attracting other professional organisations towards developing their own Viewer systems without the “stigma” of being associated with open source code. Again, given LL’s stated desire to drive SL onto more mobile platforms – tools such as the iPhone, Droid, the iPad, etc. – this would seem to be a good move, as it will allow third-party organisations with the expertise LL lacks to develop the kind of functionality such tools will require if people are to use to them to access SL and use it for more than just chat and IM.

It’s not just developers who have the chance to be more directly engaged with Viewer development either. AS Esbee said, users will be able to get involved as well: iterative releases will be available bi-weekly or us to use and feed back upon, and even daily releases, or “project releases” covering specific features under development will be made available and user feedback encouraged.

From a non-technical perspective, this does seem to be a logical approach, and in some respects, it is a shame that, when they opened the Viewer code to the community, LL didn’t show foresight and put these measures in place then. Of course, the devil will be in the details – and there is much that will serve as either proof of the pudding or still needs to be addressed  / clarified. In listening to the presentation, a number of points occurred to me, some of which were echoed by others in the Q&A session.

One issue that springs to mind is who will, in the final analysis, determine what is “right” for integration into the Viewer, and will other agendas overrule the core goals – such as making SL Fast, Easy, Fun? “Linden knows best” has been very much a part of the Lab’s culture and has been seen time and again, particularly with the arbitrary closure of JIRAs or the turning of a deaf ear to valid user requests.  With the best will in the world, cultural behaviour is the hardest thing to fix in an organisation.

An extension of this concern comes down to user input actually being heard and acted upon. Q openly admitted at the start of the presentation that LL erred with Viewer 2 in not creating enough user cases on which to model the viewer. Now they seem to be swinging to the opposition end of the pendulum swing: seeking too much user input. There are – as Q and Esbee acknowledge – many diverse uses for SL, and as such diverse sets of users have diverse needs. Some are going to apposite in their aims, others opposite. How are filters going to be applied to stop all these calls simply swamping Snowstorm with the result that the individual internal dev teams beyond them simply cherry-pick or (again) turn a deaf ear?

So where does this leave the current crop of TPVs? Oz was pretty unequivocal on the matter: the Viewer 1 code base will not be developed any further by Linden Lab (Q also touched on the need to depreciate 1.23 in the future, simply due to security issues). Therefore, with the Viewer 2 code base becoming publicly accessible, the view seems to be that TPVs will be encouraged to continue – as well as give input to the new project – but will be expected to migrate to the Viewer 2 code base.  Certainly, there doesn’t seem a move on hand to proactively “shut down”  TPV development, but it is going to be interesting to see how this moves forward and who engages through Snowstorm as is intended, and who simply continue to work on their own Viewers utilising the now-available Viewer 2 code.

Overall, this move strikes me as positive. *IF* LL can carry through on this with the necessary internal cultural changes and if we all, developers and interested residents alike, engage with Snowstorm and LL constructively, positively and openly on our own part, then there is no reason why this project should give birth to something very worthwhile and which benefits us all.

Emerald: unfortunate developments

Posted on by Inara Pey

I’ve supported Emerald. I’ve been happy to use it for around 18 months. In that time a lot has been made about it being a malicious viewer, with many, many claims going around that it does everything from raiding your L$ balance to spying on your granny while she’s having a bath…and they all remain pretty unsubstantiated. Emerald has also come in for more than its share of people misrepresenting its capabilities (such as making your avatar “invisible” allows you to run around griefing people. If you’ve ever used the “invisible” function, you’ll appreciate how ludicrous these claims are).

However, there comes a time when one is forced to sit up and take notice of what is being said – and that time is when it is being said by one of the Emerald developers.

LordGregGreg Back is not someone I classify as an SL friend or even an acquaintance. Our dealings have always been at a distance, via IMs usually. BUT…throughout the time I’ve been using Emerald, I’ve never found him to be anything less than honest in his dealings with people. It has been because of his involvement (alongside that of Chalice Yao) that I’ve remained an Emerald user. Yes, both at times have had to do *some* verbal acrobatics when being pushed to defend the antics of others, and in doing so have potentially harmed their standing in the eyes of others. But just because they have, does not, and has not meant their efforts and work with regards to Emerald have been anything less than honest.

So when Greg up and publishes his own misgivings about Emerald, I admit I sit up and take notice.

The crux of the matter is the manner in which a .dll is being used – in this case emkdu.dll – which is related to texture loading and which allowed a viewer’s title bar and executable path to be broadcast in an obfuscated manner (and possibly recorded by other in-world devices). Despite promises the issue had been fixed, made to both Greg and Emerald support manager, Jessica Lyon, it wasn’t. Instead, encryption was used to further obfuscate what was going on, and further requests for the code to be cleaned up only increased the degree of encryption being applied.

The worrying this here is that the encryption meant that the code could not longer be properly vetted and verified – Greg’s role in the Emerald team. This, as Greg explains, undermines trust. Encryption  / obfuscation is suggestive of malign intent, whether or not it is in fact the case. So why do it? Probably because the individual responsible cannot help but jerk an immature middle finger at his detractors at the thought of them scrabbling around trying to prove the code is in fact malicious, then giggling himself to sleep at night.

But in doing so, the individual concerned pretty much jabs a finger vertically at the rest of the Emerald team with the result that those with a conscience feel they have no option but to gradually bow out. And this is a shame, as it lessens the value of Emerald while simultaneously enabling a further round of accusations and drama.

More than this, it leads to an undermining of faith in Emerald as held by existing users. After all, one developer is actively seeking to mask what the code is doing from his fellow developer and placing active barriers in the way of ensuring the code is properly verified as “clean” – so why on Earth should any of us continue to trust and use Emerald?