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.)

Groundhog Day 2012, I Got You Babe!

This holiday was very silly when I was growing up, then the movie came out and it became ominous.  The above video showcases the short history of Groundhog Day and how it’s celebrated in the North Americas. The link below takes you to one of the best movies ever, and will make you afraid of being an asshole to people.  Wouldn’t it be nice if every year on Groundhogs Day morally deficient people became stuck in an infinite loop until they learned how do be decent human beings?  I don’t think I’d mind living in a bizzaro universe where we all feared an omnipresent and overlording magic groundhog.

I don’t know a soul who doesn’t like this movie, which means if you DON’T like it, you don’t have a soul.  Watch the amazing full movie with Billy Murray here for free on YouTube.

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.

We live in 2012! Treating cancer with electric fields!

Wow, this is great news!

To summarize the video (which you should watch), there’s a new experimental treatment available for certain cancers. When I say certain cancers, I mean they haven’t finished testing that it works on the other cancers.  The way it works is it prevents cell division in cancer, and while it may take a little over a year to get rid of a tumor, the person under the treatment doesn’t have all the negative effects of radiation treatment or chemotherapy! At the very worst they look a little silly wearing wearing the device, but it is a small price to pay.  It even works on inoperable tumors!

I hope it’s widely adopted soon!  Science is FUCKING amazing!