Massively^™

The finalization of the this week's Second Life server update Thursday morning reinstated the prim-creation size-constraints that prevent larger than normal prims (megaprims) from being created by users. Linden Lab officially confirmed today that it was a bug and not an intentional feature (While Andrew Linden had suggested this at his in-world office-hours earlier in the week, we've been repeatedly advised that statements by individual staff at such meetings do not necessarily constitute or reflect official policy or positions of Linden Lab).

Furthermore, Linden Lab confirmed that account sanctions still apply to users who are using megaprims in mainland simulators, though they are permitted for use in simulators within private estates, except where disallowed by the land covenants or owner.

Between 5AM and 10AM SLT (US Pacific time) on Friday, 16 May, Linden Lab is planning to restart approximately half of the Second Life grid simulators, in order to connect those simulators to a backup asset system. Why only half? Well, the other half got the treatment in this-morning's rolling restart.

The asset system, as you may have noticed, has been plagued with issues since November 2007, and the recent vendor-provided fixes have not improved matters. In fact, there's indications that there may be increased instability as a result.

In a recent post, blogger Cuppycake asked a very prescient question that we thought we would relate to you. What's more important to the long-term success of an MMO title: the quantity of content at launch or a high-level of polish? The way development works these days, developers are often hard-pressed to finish a game on a deadline, and at some point they have to make the decision whether to keep implementing new features, zones, and graphical assets, or go back and refine the content they have to make sure it's perfect. Games like Everquest 2 exemplify that first path - pushing out huge quantities of content from the beginning, but turning off many with their initially slow refinement process. LotRO on the other hand is highly polished, but has to undergo frequent content updates to keep players interested.

With Age of Conan right around the corner, would you choose that it be refined but small or huge and a little buggy?

Linden Lab's published their Second Life service quality metrics for April and the results are about as poor as you'd expect -- April was a poor month for the virtual world service. 630,000 user hours were lost to global failures, and that doesn't count the number lost to assorted subsystem failures (as you may recall) were abundant through the period, and still remain a daily occurrence.

As for the asset system itself, Linden Lab is having problems with some third-party hardware and software (Fortune, apparently passes everywhere), though the late-night asset problems that are being experienced each night may be less related to hardware than they are to processing batches that add load to central database systems.

So far May has been considerably smoother than April, but that is not to say that it is anywhere near trouble-free.

Fury, the maligned combat MMO by Auran Games, has had a pretty rough history. Despite the critical drubbing, the low player numbers, and the loss of a huge portion of its development crew, Auran has managed to stay together with a skeleton crew, working on the problems that made Fury such a target for ridicule.

Well, according to an interview with CEO Tony Hilliam, conducted by australiangamer.com, they've made significant changes to the title and renamed it FuryLeague, which will focus more on the competitive aspects, and less on the MMO features. Additionally, there is the prospect of winning game gold that can be converted to real money, which, because the game is skill-based instead of luck-based, means that it's not gambling and is therefore legal.

The full interview is available, and the Qualifying Season has already begun. Admit it: you're just as curious as we are. Give it a spin and let us know what you think!

[Via Kotaku]

Pretty much everyone knows that "exploit" is a dirty word. An exploit in an MMOG is anything that lets you work outside of the established rules of the game to do something that you couldn't normally do, usually in a way that lets you bypass or defeat content more easily than you're supposed to be able to. Finding a way to jump the fence before Arathi Basin actually starts is an exploit. Purposely glitching trash mobs into walls so that you can walk past them to a raid boss is an exploit. Killing a monster from a position where they're totally unable to hurt you is an exploit. In PvP gameplay, exploits are the kiss of death -- they break the game and make things totally unfun, because one player is cheating at the game.

But is that necessarily the case for PvE gameplay? I'm not so sure. The commonest way to avoid players using exploits to kill monsters is that when a monster decides that a player is jerking it around too much (and is able to damage it without being hurt themselves), the monster just starts evading and goes back to its starting point. It's the virtual NPC equivalent of saying, "Fine, you don't want to play fair? I'm going home." But that mechanic misses an important consideration -- it's kind of fun to find and use ways to exploit mobs.

Lead designer on Star Wars Galaxies, Blixtev, compares going through the old Damage Over Time code to rummaging through your grandmother's attic. "It's loaded with old junk and it sure smells really bad", he says. Still, that's exactly what the SWG developers are doing as they work to revamp Commando abilities for the upcoming Game Update 4. In some posts to the official forums, Blix talks about opening up moldering trunks and tossing aside ancient silverware to get at the DoT code beneath. "The DoT system is one of our oldest systems, and it sure does some wacktacular things. We found 10 different calculations amoungst 5 functions to determine just the value of absorbtion from armor against DoTs. For folks who don't code, that's alot."

He goes on to describe their upcoming plans for the system, which will spread DoTs to two different abilities and substantially change the way they're applied. After the update they're going to stack up to 10 a piece on a single character, a process that could take some time. Because of this change, DoT removal will change as well. Taking long minutes to apply the full 10-stack to a PC shouldn't be automatically negated by a Medic power. Instead, DoT removal will take away part of the stack, and make the recipient immune to further DoT additions for a short period. Meanwhile, the existing debuff will continue to tick down - harming the character with an element type determined by the Commando's weapon.

A later update indicates that these trials are proving very effective in making the Commando a more fun profession to play, a claim we'll be able to put to the test hopefully very soon.

Linden Lab has released the fifth 1.20 Second Life release candidate viewer. Release candidates start counting from zero, so the first one in the series is RC0.

This is a rush-release, as you might notice that the previous RC3 was released only yesterday (Wednesday). Apparently attempting to enter the appearance editor caused an instant crash. Oops. So much for QA.

There isn't a lot else new to speak of in this viewer, except a known issue with terrain textures on MacBook Air notebooks, and that llLoadURL opens in the external web-browser by default, instead of the internal web-browser.

Joshua Linden tells us that the rollout of the new 1.21 simulator code (intended to do a number of things, including supporting the new land store) to one rack of servers has not gone so well (again), after reports came in about attachment failures that were traced back to improper permission checks.

The affected simulators have been rolled back to 1.20.1 pending code fixes that are expected no sooner than tomorrow. We expect Linden Lab is pushing hard at this to get the land store back up and running as soon as possible.

Something is obviously very wrong with the 1.21 Second Life simulator software. For whatever reason it just won't take (maybe it keeps trying to sell itself in the Land Store -- we don't know).

Whatever the reason, Linden Lab is waving off from deploying an update to 1.20, and will instead be deploying an updated version of 1.20. In retrospect, we'd like to apologize for any migraines or confusion that last sentence might have caused.

No one enjoys a memory leak in their favorite game. Perhaps you've reported one in the past, in the hopes of a speedy fix. EverQuest II's technical director Joshua Kriegshauser recently noticed quite a few reports coming in about a possible leak in the zone Veeshan's Peak, and has done a write-up of what it takes to repair these crippling and annoying problems.

Having read through the article, we won't pretend that we understood everything that Kriegshauser has written, but we get the point -- fixing memory leaks is no stroll in the park. For those of you that can keep up with what he is saying, kudos to you. For the rest of us, it opens our eyes to what really goes on behind the little hotfixes we zoom past in the latest patch notes of any given game. In case you don't make it to the end of the article, we'll let you know that he did manage to fix the leak -- we're going to go now and sleep off the headache we got from reading that far.

We're getting hundreds of reports of failures with Second Life, starting about 9:15AM SLT (US Pacific). Problems reported include all transactions, inventory, map problems, profiles, balances, teleportation, sim border crossings, IMs and ... well, pretty much every service. Users are reporting that logins are not only failing, but crashing the viewer.

This includes the Second Life website, which is non-responsive, though the Linden blog is live (it is not hosted with the rest of Linden Lab's equipment).

Update: Linden Lab has spotted the trouble too.

Update: After about 1 hour and ten minutes, the problem has been resolved. No information appears to be forthcoming on the cause or the cure. Thus we do not know if we can expect this to happen again today.

During the afternoon and evening today, a number of new Second Life last-names have appeared in the public account registration list. The names are of the form UnitTest<something> (the something appears to be a random dictionary word). There appear to be as many as a couple hundred of these last names, in addition to the regular list.

The names are apparently intended for internal use by scripts, though now over a hundred users have signed up with these new last names. It seems to be a mistake, and we think we know how it might have happened.

The grid woes seem to be continuing. At present most of Second Life's systems appear to be malfunctioning. Teleports seem to be broken in most regions, sim border crossings have become problematic and asset systems are showing very low responsiveness (if any).

Linden Lab additionally reports that login systems appear to be erratic as well. Login concurrency is falling either due to an inability for users to log in, or due to inworld problems once they are there. Perhaps both. This is a repeat of similar problems over the last 8-10 hours. Perhaps catching up with a good book might be in order.

We are assured that the problem is being investigated. Again.