Important SL JIRA issues for April

I decided to skip this report for the month of March because I started this regular article at the middle of February. I have every intention of keeping this going on a regular basis — if only to just keep Linden Lab on their toes.

Important Server Fixes

  • [SVC-114] Meta-Issue: Inventory Loss: issues, fixes, development. Inventory loss has been a long standing problem in Second Life. This JIRA in particular has been open since 2007, but inventory loss has been in existence since longer than I’ve been in SL. It’s less of a problem for me because I try to keep my inventory around 15k items, but I know lots of people with 45k+ who regularly lose things.
  • [Many, many JIRAs] The Second Life Marketplace is a disaster of a rollout. With the introduction of the new Direct Delivery features, many people are upset not only at the rocky transition, but that the Marketplace is very slow — or fails to work at all. Then there’s the problem with the whole rollout schedule, in that many people feel it’s too fast and forced to make changes right away. Right now I think the marketplace database is being hammered so hard because so many vendors are having to update their listings. Still other people report that sales have effectively stopped, while others report that they’re not reviving the money from LL for their sales. A lot of people are having trouble transitioning as well, because of unicode characters in their products.
  • [SVC-7125] Bring Back Last Name Options! A staggering amount of votes have been put on this JIRA.  I remember when last names were removed, and at the time I though that it wasn’t a great idea — but it didn’t affect me so I didn’t care. Display names weren’t adopted as well as LL thought they’d be, because people still rely on actual account names. I can imaging having the last name “Resident”, is a pretty big bummer.  It has been proven in the past that LL can change an account name — perhaps LL should monetize this feature, and give anyone with the last name “Resident” a free use.

Important Client Fixes

  • [VWR-14674] Object Return Function of Region/Estate Menu does not work. A long time ago, these estate tools used to work.  The way they worked is that when you selected a name you could return ALL of the objects across an estate. This function was broken at one point, worked for what seemed a week, then broken again. Linden Lab should fix this post haste because of all the time they’ll save on support if estate managers can take care of their own estate without calling concierge for help. Griefing will be a thing of the past.
  • [VWR-28606] Viewer UI rendering slows to a crawl after extended viewer use, or teleporting. This JIRA is my own filing, and I bring attention to it because I know a lot of people suffer from viewer lag.  I’ve got a pretty beefy machine, and I’ve found out how to reproduce lag that ONLY comes from the UI interface. Ever since Viewer 2/3 came out the FPS in SL has been terrible in comparison to V1.  I think a lot of things can be done to the viewer UI code to improve it, so it may warrant the same treatement as the SHINING fixes for rendering.
  • [VWR-2950] Group Notices and Group IMs Constantly Malfunctioning. This is kind of a repeat of last Februarys. I like to imagine this issue is server side, but client side may also be part of the problem, hence sticking it in viewer issues. Group chat and notices are key to keeping SL great.  The poor performances of these services directly impact user experience.

Important Feature Developments

  • Pathfinding is still being beta’d and worked on.  In The Wastelands we’ve got one region Kronbelt, that is on the pathfinding beta.  A lot of bugs have been filed, and it seems like a good amount of feature development requests are in there too. Given LLs track history of releasing things, I’m pretty skeptical if any of the feature requests get worked on after the initial release. On top of that there’s some pretty serious bugs, such as dynamic objects (things that change shape, or size) can bring a whole regions’ FPS down to two.
  • There’s very little word on the Advanced Experience Tools, things like llTeleportAgent() or forcing attachments on people.  Wish there were an update on that front.

My Wish List

  • I wish that LL would just start over on the rendering engine of SL. It really is pretty terrible and only uses a fraction of my GPU, most everything that’s done for SL is on the CPU nowadays. I understand it’s hard to build a platform that is supposed to support as much hardware as possible, and to a degree you can’t control the viewer lag generated by people, because some people make 2048 resolution mesh eyes. I’m glad for the improvements that have been made, but the majority of everything done is on the CPU anymore.  Even with my Core2Duo overclocked to 3.6ghz, SL rendering seems lacking, and lagging.
  • I was recently forced to try a 3rd party viewer because a work deadline was coming up and the regular SL viewer was on the fritz. I really liked the UI of Nirans viewer, it was just more intuitive. What I really liked is the automatic graphics setting. Having said that I think upon setup LL should test for whatever openGL features are supported by the graphic card a user has, then automate what options are enabled by default.  Currently a list of features is used.  Develop an algorithm guys.

Tip of the Hat

It’d be unfair to critique LL without giving credit when they deserve it, so this new section is for when LL makes changes that are favorable to the operation of Second Life.

  • I previously blogged about llGiveInventory throttles, and while I still disagree with the enforcement of throttles, the throttles have been loosened with a recent server rollout. This may or may not be enough for large businesses.
  • A long standing feature request has been fulfilled. With the addition of llGetAgentList(), you can now get all the keys of all the avatars in a region. This isn’t live yet, but will come to a rollout soon!
  • [SVC-680] is one of those older JIRAs that is finally getting some attention in a future rollout. It increases the http response size from 2k to 16k in mono scripts. I will happily use up every KB in my newer Wastelands game.  No more chain-stitching HTTP responses together!
  • It looks as if llCastRay() may have it’s throttles removed.  HOORAY!

(Editors Note: This article is all just personal opinion of the importance of what JIRAs need to be fixed most. I may not know of other JIRAs that have a bigger impact. If you have suggestions for next month, please leave a comment about them with a link.)

Looking for work? Learn to build and fix machines.

I remember staring at the closet while I was talking to my father through the bathroom door. “If you don’t get a good education, you’ll end up pumping gas at a gas station. What you should think about is fixing robots, that’s where all the jobs are going to be”, he said. This was way back in 1989. As I get older it’s harder to remember the small conversations we had, but certain things really stick in my head. Prophetically he was right — though since we were already very industrialized he had quite a lot of clues. 1989 was still before computers became a household staple, so he couldn’t imagine how exactly right he was.

In the late 1800s and early 1900s industrialization of our planet made taking raw resources and crafting them into a consumer product.  As early as then we’ve been making obtaining the raw materials easier.  Most modern day resource gathering is done on an industrial scale. Now that robots are here to stay, most manufacture operations are done by robots to ensure perfect products. If you think about it, in the last 100 years we’ve obsoleted a lot of manpower for manufacturing and crafting things. Since the year 2000, computers have been taking over what’s left. Nothing is safe anymore, even imaginative jobs are at risk. The fact of the matter is, automation took our jobs through the pursuit of being cost effective.

“Job Creators” as they’ve been coined are usually classified as the people in charge of companies; they have the power to create jobs. But unless the company cares about the welfare of the people they employ, beyond their competition and cost effectiveness — they’re going to be against you. Why would you chose a person over a machine that doesn’t get sick, have disabilities, drama, or need health insurance?

… and I hate phone automation systems.

A History of Half-Assed Features

Rainbow Puke
This is how excited I got for llCastRay()

Linden Lab has a lot of new features in the pipeline right now, and I am very excited for them. Reading this post over at  Dwell On It is a very sobering experience. It’s explaining the new Direct Delivery features coming to SL, when suddenly Linden Lab interjects and clarifies how the newest upcoming feature Direct Delivery isn’t being developed as planned. So I started to wonder if this was ‘on par’ because it seems like every new (or old) feature developed was half done when it implemented. Is LL setting us up for another let down?  Lets examine some of the things LL has done in the past…

Continue reading

Why isn’t Second Life investing in Gift Cards?

My brothers birthday is on the seventh, so I went to shop around for a gift for him over the weekend.  I ended up at Target at one point during the adventure, and I walked pasted the pre-paid game cards. I see gift cards for every online service imaginable on that rack, but no SL.  Why doesn’t SL have gift cards? I’ve wondered about this many times.

When I first started wondering “Why not?”, I could justify why a gift card could be a problem if it was a direct conversion to L$.  But now I don’t see why it couldn’t be a direct account credit. From there a user could pay account fees, or buy L$ on the Lindex. The only justifiable reason I can think of to not work out a gift card setup is because the higher ups don’t consider SL mature enough as a platform. Sure there are problems, but they can be fixed. All things considering, there are three immediate HUGE benefits to issuing gift cards.

The first and most obvious thing is getting the Second Life brand out there. LL seems to be struggling to make SL known, and this is one simple step for almost free nation wide marketing. If consumers see an SL-card on the shelf next to another online game it might garner some interest, especially if you list all the features of being a premium account.  You can sell people on the Second Life experience in a box store when people go to pick up a similar or competing service.

The second benefit is ease of use. I hate to say it, but I know some of my residents still have occasional problems paying for Second Life or buying Linden Dollars. No business should have problems accepting money from their customers, it’s inexcusable.

The final obvious benefit is the simple influx of cash. I know a lot of people who would buy them as gifts because they are… gift cards.  Being more available and visible would ensure more people spend money on SL for themselves or users of Second Life.

Sure, there will be a bit of overhead for billing to deal with when various gift card issues  arise — but if you plan as best you can for it, and do it wisely, it’ll be a great success. You don’t even have to limit it to just flat account credit, maybe even something as simple as monthly, quarterly, and annual premium account memberships. I know you’ve been hankering to get more people on premium, so this is a good solution to that.

p.s. In the end I ordered a gift online for my brother because I have Amazon Prime and it’s free shipping.

A week in the trenches with SLs new pathfinding AI.

It certainly is exciting times in SL!  Pathfinding is Second Lifes newest feature that’s just around the corner. Content developers such as myself have been working on pathfinding for quite some time — but the limitations of LSL have kept all but the simplest pathfinding out of secondlife. For the past week I’ve been spending some time on the beta grid testing out the new things.

Currently, I have buzzards and beetles that crawl across my estate for people to kill and get resources from, but they don’t use this new AI. In the past I’ve had Raiders and Marauders for people to combat, but their slow run-times made them easier targets than I wanted them to be. The cooperation system I had between them wasn’t as good as it could be because they could only make simple choices about nearby environments. They couldn’t plan for traversing a whole region to aid their allies.

The beauty of SL is that people can make whatever they want, and the way they rent the resources to do so is to ‘own’ virtual land. It’s also a double edged sword in that the environment is constantly changing. One of the biggest hurdles for even simple AI is for it to know if it’s okay to go onto a parcel of land, or as I like to call it “Is it okay to step here?”. Because I don’t own all the land in the estate, the simple LSL AI needs to make a lot of decisions about it’s next step. It examines it’s next step with the following in mind, asking if:

  1. Does my next step put me on land where scripts are disallowed for me or the group I am in?
  2. Does my next step allow me to even enter the parcel I am about to cross into, and if not are we of the same group?
  3. If I can cross into the parcel, and scripts are allowed, are there enough prims to host my presence?

If the tiny AI object can’t cross into the parcel, it has to think a few steps ahead and try to plan the shortest route around the parcel.  Usually that’s the big hangup because of script memory constraints of 64kb for any single script. Eventually I started trying to implement a simple potential field in SL to help with navigation but the execution time was terrible. I would have tried again with the improved llList* speed improvements, but…

Right now I am playing with pathfinding in SL. It’s been confirmed that it’s an API extension of Havok-AI (video).  A character (as LL is calling it) can be created in as little as 4 lines of code, and have no script time impact. Having tested myself, I can confirm that in it’s current implementation once a character is defined, it will continue running even on no-script land, though it may be brain dead. That means the physics engine is doing all the heavy lifting, and an objects behavior only changes when it’s told to change by a script. This is great because we get to use the physics engine for more than placing avatars, shooting bullets, or playing jenga.

One of the Moles (a contractor for LL), was on the beta grid getting my feedback, and answering a lot of questions — well as best he could. From what I could gather in order for pathfinding AI to work, content creators will have to set some flags up on their prims to help build a nav-mesh. A nav-mesh is what the AI looks at to determine where it can go.  Floors, stairs, and ramps will need to be flagged as walk-able, while walls and furnishings will need to be flagged as obstacles. Things that aren’t flagged will be ‘ignored’, and my best understanding of this is they’re considered obstacles.  Land owners will be able to bake the mesh for their parcel, and estate owners will be able to bake the mesh for the region.

Currently there are a lot of bugs, but that’s to be expected with any new feature — especially in beta. One of the biggest is that it currently doesn’t check for all the small steps I mentioned earlier.  Sure AI can be aware of their physical surroundings, but they also need to be aware of their system surroundings.  I’ve filed a bug on the JIRA about this, and another issue relating to collisions. One big feature I find lacking currently is the support for flying things, or swimming things. I believe once LL gets done with basic object and terrain walking, they’ll expand the feature to support different types of AI.  Until then come test on the beta grid!

Here’s the full official video from Linden Lab about pathfinding.

Important SL JIRAs for February

Once a month I’ll showcase a few JIRAs that severely impact Second Life. Server fixes are things that can improve or repair the Second Life service, and are usually things that only Linden Lab can fix. Client fixes relate to the bugs or defects in the software you use to access SL, and if you’re a developer you can submit a patch to Linden Lab. Finally, feature developments are cool new things on the horizon! I encourage everyone to “Watch” and “Vote” on these!

Important Server Fixes:

  • [SVC-1509] Error message when starting and posting to a group chat / IM session.  THIS.  This needs to be fixed once and for all. I really don’t know what the fix for this is myself, I just know that SL as a social platform needs to allow people to communicate with each other.  This may be the single most important fix the grid needs to revitalize it.
  • [SVC-3579] Attachments reloaded from stale versions on rewear. Anyone who tries to develop anything in LSL expects their variables to not be reset or rolled back. Especially anything involving transactions, gift card systems, or game stats. People are losing money, having upset players, and a good amount of general frustration. Right now the only work-around to this issue is to not depend on SL as a platform — and make sure you host all of your important stuff on your own server. That is pretty hard to do, and defeats the purpose of keeping things inworld.
  • [SVC-7629] Map tile generator not working.  I am sure there are far more important JIRAs out there, but as an estate owner those inworld maps are pretty important to me! It also really irks me that only two of my thirteen regions show up on the inworld map.  I’m not even going to detail how stupid my landstore looks now.

Important Client Fixes:

  • [SH-2854] Mesh objects stop loading after certain period of time. For the past — I’m not certain — feels like a year now LL have been pushing mesh.  Since Mesh’s release, it’s had a lot untrue rumors that keep people from upgrading to a viewer that supports it.  Last I read mesh enabled viewers are only at 60%.  By fixing this JIRA we can ensure that people who do experiment with viewing mesh don’t have any excuses for not adopting it.
  • [SH-2720] Invisprims are not being rendered while Lighting and Shadows is enabled. While invisiprims are technically a hack, they’re a hack that’s been around since I started SL. Before we could make transparent and alpha’d out clothing, we had to hide our body parts with a tricked out primitive with special textures. A ton of old content relies on this hack and I hate to admit that it needs to be carried over into the newest iteration of viewers, but it does.
  • [SH-2920] Fast Alpha – Alpha Masking – glitching. This one is just a pet peeve of mine, and could be related to the issue above this one.  Things in SL look like crap if there’s a lot of alpha flickering. For new users it may be disorienting to try and navigate a building that’s mostly made of alpha textures.  It’s not common but I’ve seen it.

Important Feature Developments:

  • [NO-JIRA] Linden Realms functionality. Linden realms uses a few new and very secretive functions to help operate it’s game. Features like the ability to teleport avatars to certain destinations and auto-attach HUDs, all of without an avatars expressed permission.  As a person who’s been running games in SL for 5+ years now, these are things I’ve been dying for. I would love to see it expanded into more control over a player. Please, let us play test them and give feedback AS game developers — at the very least on the beta grid.  For those who aren’t into scripted objects having that much control — perhaps it can be an estate flag that’s checked prior to a teleport, letting an avatar choose if they want to go to that destination.
  • [STORM-1716] Mesh Deformer for tailoring mesh clothing. Currently this is the big one everyone is waiting for. I think when mesh initially came out a lot of people expected to have this deformer in place to make more suitable mesh clothing. It took an externally funded project to hire an ex-linden to develop this feature. It’s making good leaps and bounds in it’s progress, and it’s especially nice to have video updates (because people don’t like to read for some reason).

My Wish List:

  • Bring inworld C# back into development.  This was a HUGE project that many programmers in SL were really looking forward to, and then everyone got laid off and it was shelved.  Bring it back, and you’ll have far better interactive content on the grid!
  • Improve Customer Service. (I will rant about that another day)
  • Lower Tier. Seriously, the current pricing structure has been in effect for 5+ years now. On top of that 20% of the people paying for the service are essentially beta-ing it for you, against their will.
  • Custom mesh skeletons and animations for both avatars and objects and related scripting functions to go with them. Perhaps a function like llPlayObjectAnimation(string animation, float priority);

(Editors Note: This article is all just personal opinion of the importance of what JIRAs need to be fixed most. I may not know of other JIRAs that have a bigger impact. If you have suggestions for next month, please leave a comment about them with a link.)

Critique: llGiveInventory Throttles

Recently there was a stealth modification to how the llGiveInventory function works in the LSL Language.  A stricter throttle was put in place to limit the amount of inventory an avatar can offer another avatar through automation. The old way it worked is that if the destination is an avatar, the script sleeps for 2.0 seconds.  In theory that would limit an object to 1800 offers per hour.  Most content creators (myself included) aren’t to thrilled with many of the imposed delays that some functions have. LSL scripts have no capability to multi-task, and a rest period on processing can be hard to deal with. What many scripters/coders do as a work-around is thread out their scripts to avoid these delays, especially for larger projects. These threaded scripts then handle certain events, and communicate with other scripts inside an object via link_message.  llGiveInventory is no exception. With script threading you can give out tens of thousands of updates per hour, keeping your customer base happy!  The new change limits inventory offers to 2500 per 30 minutes, per avatar, per region. Go over that limit, and you will have silent failures.

As a SL user who’s worked on some of the bigger projects in SL, I can say that the current implementation of the throttle is yet another hurdle a coder such as myself must overcome. But the turn around to deal with this stealth limit is a nightmare for any big project already active on the grid.  It’s only going to piss off the customers of the customers who bring in the big bucks for the Lab. Content creators will become further disenchanted with yet another hurdle to overcome in selling products to other users of Second Life — because you know, it’s not hard enough as it is.

Why Linden Lab chose to do this:

llGiveInventory is just another message to send on the backbone of the SL-Grid. Send a million messages an hour, and you’ll slow things down for everyone. To combat griefing, LL chose to silently patch the servers so it wouldn’t be a widely known exploit.

How this affects SL negatively:

Large communities, product lines, games, and just about everything commerce related in SL rely on these previously mentioned work-arounds to distribute content, keep content up to date, and more.  Even the Second Life Marketplace uses it’s Magic Box to distribute purchases from the online website from inworld object to customers. While working on one of my previous contracts, I know for a fact that we had single-handedly brought the SL-Marketplace down when we did a product update. This equates to probably tens of thousands of transactions in less than an hour. It’s not unfeasible to to have products that big in Second Life.  Because SL makes money when it’s content creators make money, you shouldn’t make it more difficult for people to make their products available.

What I think should have been done instead:

Rather than put stricter limit on the function, Linden Lab should ban the avatars involved in attacking the grid in this fasion, and globally delete the offending objects. I know LL has a governance team, and I know they operate in secret. But I can’t for the life of me see them following through on REAL damaging behavior of some residents. This method of griefing is an example, and copybotting is another.

What those affected by the limit can do now:

  1. Log into the SL JIRA link below, click watch and vote on it, then voice your opinion.
  2. The odds are that LL won’t back down from removing this limit. A simple, but pain in the ass solution would be to branch out into micro parcels across the mainland, and use a round-robin method of delivery and updates.

Linden Lab has always hammered home the mantra that they shouldn’t do anything to break existing content, but in their eyes this limit is okay because they’re protecting the grid.  Further discussion about the technical aspects and current woes content creators are facing can be found at this JIRA: SVC-7631.