Jump to content


Our community blogs

  1. Linden Lab
    Latest Entry

    By Linden Lab,


    "I remember the first time I went to Wales. While I had heard the jokes about Wales and sheep, nothing prepared me for just how many sheep I seen in every field I drove past from the ferry to the place I was staying. Thankfully they stayed in the fields and not run  down the village street because I am sure it would not look as easy as  the picture above looks catching them."

    <Click here to read more on the Just Stuff blog>

  2. Linden Lab
    Latest Entry

    By Linden Lab,


    Today's Second Life pic of the day is "Dark Emperor" by TheEmperor*

    To submit your image for Second Life Pic of the Day consideration, login to Second Life, snap some pics and add them to the Official Second Life Flickr Group.

    Be sure to check us out on social:

  3. Linden Lab
    Latest Entry

    By Linden Lab,

    Happy Friday!

    Our new auctions system has now been live for awhile and we wanted to give you an update on how it’s working. We’ve been very pleased with our Linden-run auctions and judging from your response, so have you. Our team of land experts will be continuing to offer those daily. 

    Our Resident to Resident auctions need a little more work. Effective the morning of October 14, creating new Resident to Resident auction listings will no longer be possible, while we take them back to the drawing board. All existing auction listings will be allowed to complete as originally scheduled.

    Any additional requests for abandoned Mainland can always be made via support ticket and we will continue to evaluate whether they are eligible for direct sale.

  4. Knock knock
    Who’s there?
    Boo who?
    Don’t cry!

    You have not missed out yet on the chillingly spook-tacular prizes and events taking place all over the Grid.


    The Swaginator Hunt ends Nov 4th - so be sure to explore this trick-or-treat style hunt for free, limited-edition treats and prizes. Everyone can collect the incredible gifts, but the first rule of horror movie survival is NEVER SPLIT UP - so grab your friends and head out for some swag grabbing!

    Our own Xiola and Strawberry Linden took on the hunt on last week’s Lab Gab - and had a blast!


    This year’s Creepy Crawl is going to be epic! 

    The second rule of horror movie survival is to make sure you stay in public, highly-populated areas! On October 31st - Halloween - from 11 am to 2 pm SLT - we’re going to venture around the Grid in costumed celebration. Jumping from spot to spot, dancing, and hanging out for Halloween.

    There is still time to submit your venue for consideration for a spot on the crawl. 



    The third rule of horror movie survival is at some point, you will need to face your fear head-on! This haunted ride is filled with horrors, chills, thrills and much much more. Proceed with caution, but be sure to make time to visit. Hop in a coffin, and brace yourself for a ride through terror!


    The fourth rule of horror movie survival is to use your environment and surroundings to your advantage and understand what you’re up against. There’s a good chance you’ve seen some of the television shows where they hunt ghosts. Become your own paranormal investigator and explore the growing number of haunted locations in Second Life. The Destination Guide has an assortment of full-sized snacks in the candy bowl for you - just visit the Haunted category of the Destination Guide.  


    The fifth rule of horror movie survival is to ward off the evil spirits with pumpkins and decor. Are you a Premium member? If so, you won’t want to miss the newest Premium Gift that is now available at one of the many Premium Gift Collection kiosks in Second Life.  Note that this premium gift goes well with the additional gifts available in the Swaginator Hunt - a match made in Halloween heaven!

    Stop by one of the Premium Gift Collection spots to grab your gift pack! 


    Have fun, check your treats for danger before you eat them, and put your new-found horror movie survival skills to the test. See you on the Grid - but you might not see us - BOO!

  5. Linden Lab
    Latest Entry

    By Linden Lab,

    Happy Monday!

    We’re writing today to remind everyone that we’ll be holding our monthly Web User Group meeting on Wednesday, Oct. 2nd at 14:00 SLT in our usual meeting place, and also to highlight for the community at large some of the things that our Web team has been working on for the last month, and wow, there sure is a lot to choose from!

    First, we need to acknowledge that a large portion of our time has been spent making on-going back-end changes that our Residents may never notice directly, but which will provide a much more secure and pleasant experience for all going forward. For example, we’ve already completed a full-scale migration of multiple web services away from our dedicated hardware colo and into the cloud. Others have been moved from third-party vendors to an in-house implementation. Still, others have been decoupled from their previous dependencies into stand-alone services. This is all part of our long term plan to move all of our services, from the web properties to the Second Life grid itself, providing us greater reliability, flexibility, and security across the board. We’ll let you try to guess which services have already been migrated - we’re betting you’ll never know the difference!

    Second, we’re extremely pleased to say that in the last month we’ve made significant progress in laying the foundations for the long-awaited Name Changes feature.  All of our teams have been working hard on preparing the grid and all of our systems to accommodate account name changes, both first and last. We’re not quite ready to release all the details yet, but suffice to say that if you’ve ever wanted to change up your account name for whatever reason (and we know you have!) STAY TUNED.

    Finally, our continuing dedication to improving the Marketplace experience continues. Last month we were very excited to release the new Store Managers functionality. And this month, we’ve been refining that experience, as well as adding more new features for Merchants such as in-world messaging when an item is sold. But we haven’t forgotten the most important part of the Marketplace, the customers! For them, we’ve added a “Gifts Received” page with details about what the items are, who sold it, who bought it, any gift message, with much-requested options for self-service redelivery! 

    All of this on top of our usual laundry list of bug fixes, quality of life improvements, security updates, and general troubleshooting. Whew! 

    It’s been a heck of a September, and this post is only scratching the surface of what we’ve done and what we’re planning for October through the end of the year, so come on by the Web User Group meeting this Wednesday at 14:00 SLT to share your thoughts and to hear ours!

  6. As part of our ongoing efforts to improve script performance, we recently made changes to how scripts are scheduled and events are delivered.  Unfortunately, we found that those changes caused some widely-used scripts to break, which led to the grid rollback last Saturday. (We were apparently unlucky in how few of those scripts were on the Release Candidate regions the previous week). We have now made further improvements that should prevent most of those problems, but even with those fixes there will be some changes in the timing and order of how scripts are run. On the whole, those changes will improve performance, but there are some scripting best practices which you should be using.  These will help you avoid being dependent on any particular ordering or timing of event delivery and script execution.

    One common cause of problems is communication between objects immediately after one creates the other. When an object rezzes another object inworld using llRezObject or llRezAtRoot, the two objects frequently want to communicate, such as through calls to llRegionSayTo or llGiveInventory. The parent object receives an object_rez() event when the new object has been created, but it is never safe to assume that scripts in the new object have had a chance to run when the object_rez event is delivered. This means that the new object may not have initialized its listen() event or called llAllowInventoryDrop, so any attempt to send it messages or inventory could fail. The parent object should not begin sending messages or giving inventory from the object_rez() event, or even rely on waiting some time after that event. Instead, the parent(rezzer) and the child(rezzee) should perform a handshake to confirm that both sides are ready for any transfer. 

    The sequence for this process is:

    1. The parent registers a listen event using llListen on a channel.
    2. The parent calls llRezObject and passes that channel number to the new object in the start_param.
    3. The child creates a listen event using llListen in their on_rez handler on the channel passed as the start_param.
    4. The child performs any other setup required to be ready for whatever communication it will need with the parent.
    5. The child sends a “ready” message using llRegionSayTo() on the channel to the parent.
    6. The parent transfers inventory or sends setup commands via llRegionSayTo to the child.
    7. The parent sends a “done” message to the child and may now shut down the communications channel.
    8. The child receives the “done” message and may now teardown any setup it did to enable configuration (such as calling llAllowInventoryDrop(FALSE).) 

    You can find sample code for both the parent and the child below.

    It's worth noting that this communication pattern has always been the best way to write your scripts. Even without the scheduler changes, the ordering of when scripts execute in the new object and when the object_rez event was delivered to the rezzer was not deterministic. It does seem to be true that making the scheduler faster has made this race condition somewhat less predictable, but making all scripts run with less scheduling overhead is worth the ordering being slightly less predictable, especially since it wasn't assured before anyway. We hope these new changes help everyone’s world run just a little smoother! To share your thoughts on this, please use this forum post.

    // Rezzer script.
    //	Rez' an object from inventory, establishes a communication channel and
    //  gives the rezzed object inventory.
    integer COM_CHANNEL=-17974594; // chat channel used to coordinate between rezzer and rezzee
    string 	REZZEE_NAME="Rezzee";
    key 			rezzee_key;
    	touch_start(integer count)
    		state configure_child;
    // rez and configure a child
    state configure_child
    		// where to rez
    		vector position = llGetPos() + <0.0, 0.0, 1.0>;	
    		// establish rezzer's listen on the command channel
    		llListen( COM_CHANNEL, "", "", "" );	
    		// rez the object from inventory.  Note that we are passing the 
    		// communication channel as the rez parameter.
    	object_rez(key id)
    	{	// the object has been rezzed in world.  It may not have successfully 
    		// established its communication yet or done anything that it needs to 
    		// in order to be ready for config. Don't do anything till we get the signal
    		rezzee_key = id;
    	listen(integer channel, string name, key id, string message)
    		if (message == CMD_REZZEE_READY)
    		{	// the rezzee has told us that they are ready to be configured.  
    			// we can sanity check id == rezzee_id, but in this trivial case that is
    			// not necessary.
    			integer count = llGetInventoryNumber(INVENTORY_NOTECARD);
    			// give all note cards in our inventory to the rezzee (we could 
    			// do scripts, objects, or animations here too)
    				string name = llGetInventoryName(INVENTORY_NOTECARD, --count);
    				llGiveInventory(id, name);
    			// And now tell the rezzee that we have finished giving it everything.
    			llRegionSayTo(id, COM_CHANNEL, CMD_REZZER_DONE);
    			// And we can leave configure child mode.
    			state default;
    // Rezzee
    integer com_channel = 0;
    key parent_key = NULL_KEY;
    	on_rez(integer start_param)
    		com_channel = start_param;
    		state configure;
    state configure
    		// Get the key of the object that rezzed us
    		list details = llGetObjectDetails( llGetKey(), [ OBJECT_REZZER_KEY ] );
    		parent_key = llList2Key(details, 0);	
    		// establish our command channel and only listen to the object that rezzed us
    		llListen(com_channel, "", parent_key, "");
    		// Our rezzer will be giving us inventory.
    		// finally tell our rezzer that we are ready
    		llRegionSayTo( parent_key, com_channel, CMD_REZZEE_READY );
    	 listen( integer channel, string name, key id, string message )
    	 { // in a more complex example you could check that the id and channel 
    		// match but for this example we can take it on faith.
    		if (message == CMD_REZZER_DONE)
    		{	// the parent has told this script that it is done we can go back to 
    			// our normal state.
    			state default;
    	 {	// turn off inventory drop.  
    		// We don't need to clean up the listen since that will be done automatically 
    		// when we leave this state.



    Hello Residents of Second Life!  

    Over the last few days, Residents using certain email providers may have noticed that they are not receiving all email notifications for events such as Marketplace purchases and Offline Messages.  

    Email has come a long way since it was first introduced to the world in the 1960s. There are many factors that affect the deliver-ability of a message, and algorithms which affect it are constantly being updated.  Sometimes things go awry despite best intentions - such as certain phrases being flagged as indicative of spam, or the volume of messages sent in a certain time frame.

    Second Life is a complex beast and not all our email sending practices are as good as they could be. We are re-examining these practices and we’re going to do better to make sure our Residents are able to get the information they need.

    There are some things you, as the recipient, can also do to better ensure deliver-ability, such as having email filters, white-listing certain contacts, checking your spam folder and marking legitimate messages “Not Spam,” and even contacting your email providers about certain emails.

    If you are experiencing issues receiving emails from us, you may also want to consider updating your email temporarily to a different provider (for example if @yahoo emails are failing, try a @gmail account), verifying your email address with us (offline IMs, friendship offers, auctions, etc all require a verified address), and white-listing (add sender to contacts) Second Life messages to ensure you receive them in the future. It’s always best to use an email account that is only accessible by you.  

    We sincerely apologize for the inconvenience caused and will provide updates once available.

  • Create New...