Updates from micheil-merlin RSS

  • Adventures in OpenSim: The Submarine

    Micheil Merlin 1:16 am on March 7, 2010 | 2 Permalink | Reply
    Tags: , ,

    So…I always wanted to build a submarine. Not really a complicated thing for sure. I just never took the time.

    I was standing on a dock one day on one of Ener’s Reaction Grid sims and decided that I’d finally take a few minutes and whip out a sub. There’s lots of open water there and I had the intention of eventually making the sub putter around the bay.

    So, here the sub sits before trying to make it move.

    Submarine
    Submarine at Alta Sea Peninsula

    For Burning Life 09, I’d written a path following script to use to make Nickola’s clown car move and also to float her hot air balloon around the exhibit.  I’d originally intended to use Loki Ball’s Slynergy Commercial Patheditor but needed a little more control than the Patheditor provided.  I did use Patheditor to build the path but created my own path follower so I could more easily make the animated object trigger other things in the exhibit.

    If you’re interested in Loki’s path editor, look him up in SL and check his picks for the location of his store.

    So, now to the Reaction Grid sim. There I stood with no tools…lol. I could manually create the path for the follower script to follow but what a pain that is. Particularly if you want to change it or do more things in the future. So, I created a path builder tool to be able to feed my path follower with. The path builder still needs lots of work but is far enough along to actually record a path.

    Next, I uploaded my path follower script from SL. And, it compiled with no errors. But at runtime I encountered errors with llRotLootAt and llStopLookAt not being implemented. So I replaced them with llSetRot just to get things going and see how the sub would look. I’ve seen some OpenSim blog notes and it looks like llRotLookAt has now been implemented in the code so I assume it will show up eventually as grid operators adopt future OpenSim versions and releases.

    I seem to be eternally rotationally challenged and generally have to mess with things a bit to get objects to face the direction I intended when trying to move them around a path. But anyway, I created a small path and moved a small object (after finding the right rotations) successfully around the path. Moved very smooth. No apparent issues at all. I thought…

    this is going really well :)

    The next step was to try to make the sub move around the bay. I swam out into the bay and placed my little path markers out to build a simple path for the sub to follow. Recorded the path, popped it in a notecard with a few other directives, put it all in a copy of the sub, held my breath and told it to take off.

    Submarine after the first move test
    After the maiden voyage!

    I’m just glad I had copies. :)

     
  • Scripting Tips: Put object description to good use

    Micheil Merlin 8:20 pm on January 27, 2010 | 5 Permalink | Reply
    Tags: ,

    Continuing on a theme beginning with “Mono Bytecode Sharing“, followed by “Does your script need socks“, this is another post describing another method to pass configuration options to scripts.  I really struggled with the title of this one and just couldn’t come up with anything near as cute as “Does your script need socks“.  Oh well…

    To summarize the theme again, being able to configure scripts for multiple purposes has at least two advantages.

    • Scripts that don’t need to be compiled to make small parameter changes support bytecode sharing.
    • Being able to configure a single script to serve multiple purposes potentially makes a script easier to maintain.

    In the last post I described a way to configure scripts by placing clothing items with special names inside the object.  Another way to set configuration parameters is to read them from the object description.

    The object description is a string of up to 127 characters that can be both read and written from the script. Prior to January, 2008, the string used to be at least twice as long. But in order to address a couple of other bugs, LL changed the maximum length to 127. This in turn caused much disturbance within the community. Go take a look at SVC-1394 and related issues for more information.

    The llGetObjectDesc function is what is used to read the description of the object the script is in.  Actually, if the script is in a prim linked to other prims, it will only read the description from the prim containing the script.

    objdesc = llToLower(llStringTrim(llGetObjectDesc(), STRING_TRIM));

    In the example above, I’m saving the object description string in a variable called ‘objdesc’.  I also use the llToLower function to make the string lower case so I don’t have to worry about what case things are in. All compares I do will be in lower case.  And, I use the llStringTrim function to remove any leading and trailing blanks. It’s easy to put a blank somewhere you didn’t intend, so removing any leading and trailing blanks helps somewhat.

    Following the llGetObjectDesc code, the script goes through a series of if and else if statements comparing the string to my special selected settings.  In this case, ‘debug on’ and ‘debug off’.  Finding either of those, the script turns a debug flag on or off.  You can get as complex as you want here as long as you don’t go past the 127 character limit. The object description could hold several keywords to be used to set several options within your script.

    Some peculiarities about the object description.

    • If the description is null and if the object has been saved and taken from inventory, the function will return ‘(no description)’ instead of null or a blank string. So, your script needs to allow for this if it is important to know if the description is null.
    • If the description is null and if the object has not been saved and taken from inventory, the function will return a null string.
    • If you’ve ever typed anything in the description and then tried to remove it, the description may now have spaces. You may need to be aware of this. If you use the llStringTrim function as I have, the string appear as null and you don’t have to worry about how many spaces might be there.
    • If you try to remove the description by deleting characters in the edit gui, it will look like it is gone but is not actually saved as a null when you get out of edit. The string will still be there when you look again. There are a few JIRAs open on this. You can set the description back to null by using the llSetObjectDesc(“”) function.

    A few other notes about the sample script.

    In the “Does your script need socks” sample, I used the changed event to detect the change of inventory and trigger the reprocessing of the options automatically.  There is no way to automatically detect the change of the description so you’ll have to have a way to tell the script to reread the description if you change it or just manually reset the script to make it read the description again.

    In this sample, I put all of the option processing in the readdesc() subroutine and then used the touch_start event to trigger the readdesc() subroutine. Again, this is some sample code to demonstrate the approach and you may not want this to happen when the object is touched.  I also have the readdesc() in the state_entry and that may be the only place you want it in your script.

    In some ways, this approach to configuration may be simpler than the socks approach. I’ve seen many examples of this object description approach in use within SL.  However, it is easy to type the wrong thing or otherwise mess up the object description so you’ll have to decide how much error checking for typos you need to have in your script.

    And now for the sample code. This sample has been tested in both SL and OpenSim.

    // Config Demo - Read Object Desc
    //
    // Script to demonstrate the use of the object description to supply
    // parameters.
    //
    // The object description is checked to see if it says either 'debug on'
    // or 'debug off'.  Set the gDebug flag accordingly.
    //
    // Micheil Merlin/SL - 1/1/2010
    
    integer gDebug = 0;                 // Debug flag.
    
    readdesc()
    {
         string objdesc;             // Object description.
        // Read the description field for the object.
        // Translate to lower case and trim blanks from the end.
        objdesc = llToLower(llStringTrim(llGetObjectDesc(), STRING_TRIM));
        // Look for an object description of 'debug on' in lower case.
        if (objdesc == "debug on")
        {
            gDebug = 1;
        // Look for an object description of 'debug off' in lower case.
        } else if (objdesc == "debug off")
        {
            gDebug = 0;
        // Check for an empty object description.
        // Empty object descriptions could either be blanks or the string
        // '(no description)'.  Earlier, we trimmed blanks from the string
        // so if it was blanks, it is now a null string.
        } else if (objdesc == "" || objdesc == "(no description)")
        {
            llSay(0, "No object description exists.");
        // If the object description is not one of our choices or empty, then
        // say the string.
        } else
        {
            llSay(0, "Object Description of '" + objdesc +
                "' found. We weren't expecting this.");
        }
        llSay(0, "Debug is set to " + (string)gDebug);
        //
        // The object description processing is complete. Other code could be
        // inserted here.
        //
    }
    
    default
    {
        state_entry()
        {
            readdesc();                 // Process object description.
        }
    
        // This event is triggered when the object is rezzed.
        on_rez(integer num)
        {
            llResetScript();            // Reset script when object rezzed.
        }
    
        // This event is triggered when the object is touched.
        touch_start(integer total_number)
        {
            readdesc();                 // Go check the object description.
        }
    }
    
    
     
  • Scripting Tips: Does your script need socks?

    Micheil Merlin 3:15 pm on January 2, 2010 | 8 Permalink | Reply
    Tags: ,

    Earlier I’d written a post on Mono and Bytecode Sharing. In that post, I mentioned that there were several ways that a script could be written to take configuration parameters. Being able to configure scripts for multiple purposes has at least two advantages.

    • Scripts that don’t need to be compiled to make small parameter changes support bytecode sharing.
    • Being able to configure a single script to serve multiple purposes potentially makes the script easier to maintain.

    One way to make a script configurable is to put socks in your object. Yeah, yeah, I know that sounds weird. But it is really a pretty easy way to set simple configuration parameters. And if you don’t like socks you could use any clothing object. The LSL functions that deal with clothing can’t actually tell what type of clothing it is.

    Basically, what you do is place a clothing item with a particular name in the object. Then have the script read the object inventory looking for clothing items. If it finds an item with a name of a keyword that you’ve chosen, then set a flag, flip a switch or whatever you need to do in your script to make it behave differently.

    First you have to create a pair of socks. Don’t worry. This is easy. You don’t have to do anything to them other than name them as their name is all we’re interested in. Open your inventory, select the ‘Clothing’ folder and right click on it. On the menu that opens, select ‘New Clothing’, then ‘New Socks’. If you don’t rename them now, they’ll be called ‘New Socks’. Drag them to the inventory of your object and rename them to whatever you like.

    The llGetInventoryName function is the key to socks approach. It will return the n’th item of the indicated type from the inventory. In this case I specified ‘0′ for the item number so we get the first item.

    socks = llToLower(llGetInventoryName(INVENTORY_CLOTHING, 0));

    In the example above, I’m saving the name of the first item of type INVENTORY_CLOTHING in the variable ’socks’. I also use the llToLower function to make it lower case so I don’t have to worry about what case things are. I’ll do all of my compares in lower case.

    For this demonstration, the assumption is that there is only one clothing item in the inventory. If there are others, the one you want might not be the first one and the code would have to loop through and look at all clothing items.

    In the sample script below, the code immediately after llGetInventory goes through a sequence of if statements to check for various names and sets a flag as appropriate. In this example, I was setting a debug flag. Of course you could just as easily set a ‘left’ or ‘right’ to tell a script to open a door to the left or right. Or a ‘blue’ or ‘red’ to make a particle script spew blue or red particles. You get the idea.

    A few other comments about the sample code.

    I use the on_rez event in most of my scripts to cause an automatic reset when the object is rezzed.

    Also, in this sample, I used the changed event to detect when the object inventory changes. The result is that if you rename the socks inventory item, or change any inventory item, the script automatically resets.

    Then lastly, the touch_start event is just included so you can touch the object and have it report the current setting of the flag.

    And now for the sample code. It doesn’t do anything useful. Just demonstrates the approach. And, it works in both SL and OpenSim.

    // Config Demo - Socks
    //
    // Script to demonstrate the use of socks to set config parameters.
    //
    // The clothing object name in inventory is checked to see if it is
    // a particular keyword of 'debug on' or 'debug off'.  Set the gDebug
    // flag accordingly.
    //
    // Additional inventory objects could be used to set other flags.
    //
    // Micheil Merlin/SL - 12/1/2009
    
    integer gDebug = 0;                 // Debug flag.
    
    default
    {
        state_entry()
        {
            string socks;               // Name of inventory clothing object.
            // Get the name of the first inventory item of type clothing. Any
            // clothing type will work. The llGetInventoryName function does
            // not look for socks specfically.  The llGetInventoryName function
            // is called with a '0' to get the first item of type clothing. It
            // could be called successively to obtain additional clothing
            // items.  If it returns an empty string, there is no more
            // inventory of that type.
            socks = llToLower(llGetInventoryName(INVENTORY_CLOTHING, 0));
            // Look for clothing name of 'debug on' in lower case.
            if (socks == "debug on")
            {
                gDebug = 1;
            // Look for clothing name of 'debug off' in lower case.
            } else if (socks == "debug off")
            {
                gDebug = 0;
            // Check for the existence of the inventory item.
            } else if (socks == "")
            {
                llSay(0, "No inventory of type clothing exists.");
            // If the clothing name is neither, then just say it.
            } else
            {
                llSay(0, "Clothing name of '" + socks +
                    "' found. We weren't expecting this.");
            }
            llSay(0, "Debug is set to " + (string)gDebug);
            //
            // The socks processing is complete. Other code could be inserted
            // here.
            //
        }
    
        // This event is triggered when the object is rezzed.
        on_rez(integer num)
        {
            llResetScript();            // Reset script when object rezzed.
        }
    
        // This event is triggered when the object has changed.
        changed(integer change)
        {
            // If inventory has changed, assume script reset is needed.
            // Adding socks to the inventory or renaming them will cause this
            // event to trigger.
            if (change == CHANGED_INVENTORY)
            {
                llResetScript();
            }
        }
    
        // This event is triggered when the object is touched.
        touch_start(integer total_number)
        {
            llSay(0, "Debug is set to " + (string)gDebug);
        }
    }
    
     
  • Sim Stats - December 09

    Micheil Merlin 2:20 am on December 31, 2009 | 10 Permalink | Reply

    Welcome to the sim stats for December.

    SIM
    Micheil’s Rating
    Dilation
    FPS
    Physics
    Time
    Script
    Time
    Spare
    Time
    Script
    Speed
    Enerville star_08 1.0 45 1.1 14.0 6.2 0.74
    Ener Skerry star_09 0.99 44 0.5 15.8 4.9 0.89
    Ener Passage star_07 0.92 42 0.4 5.1 17.9 0.71
    Ener Strait star_10 0.99 44 0.1 2.4 19.7 1.01
    Enercay Midkey star_10 0.99 44 0.2 6.3 15.5 1.00
    Enercay Westkey star_10 1.0 45 0.5 7.9 12.9 0.98
    Enercity Harbor star_06 0.99 45 0.8 19.8 0.0 0.44
    Enercity Weston star_06 0.99 45 0.4 19.7 0.0 0.56
    Enercity Easton star_06 0.98 44 6.4 13.9 0.0 0.43
    Enercity Square star_09 1.00 45 0.1 12.3 8.4 0.91
    Enercity Shores star_07 0.99 44 1.6 19.0 0.0 0.73
    Enercity Park star_10 0.99 45 0.1 1.0 20.8 1.02
    Selected SL Regions star_06 0.99 45 2.1 17.5 0.0 0.42

    micheilsthoughts

    Two server deploys occurred during December. The first, server 1.34.0.140927, included some fixes and support for the Linden Homes program. The second, server 1.34.1.141394, included an unspecified security fix to address an exploit that could be used for content theft.

    Almost as soon as the second deploy started, reports of #SVC-5150 began occurring. Objects with scripts that request permission to attach to an AV, began to fail. This is an approach used in many vehicle scripts. The problem seemed to be fairly prevalent early on but also seems to have cleared up to a large extent. The issue is still open.

    A handful of other temporary problems also occurred such as TP failures, object rezzing failures and inventory issues. These seem to have settled down to normal levels.

    Out of curiosity, I took my sim timing test scripts over to the Ener and subQuark Reaction Grid venue which runs on OpenSim. I don’t know that I had any real expectations, but did I get a big surprise.

    They ran 30 times faster!!!!

    They are really simple counting and looping scripts. Originally, I played with making them more comprehensive but it seemed that their simpleness worked just fine for comparing SL sims with each other. In any case, you’d need to test and compare a number of common operations to draw real script performance comparison conclusions between SL and OpenSim. And even then, OpenSim implementations occur on a range of software and hardware so comparisons would be specific to one implementation of OpenSim.

    Maybe more comprehensive testing scripts will be a little future project :).


    Some key points regarding Second Life sim performance.

    • A sim frame is 22.2 ms in length.
    • A time dilation of 1.0 means the sim is running at full speed.
    • As frame time gets larger than 22.2, time dilation drops below 1.0 and sim FPS drops below 45.
    • Spare time means there is time in the frame that the sim has nothing to do and is not running at capacity.
    • When busy, the sim will try to avoid increasing the sim frame time by spending less time running scripts.

    The above points apply primarily to full sims. Openspace and Homestead sim stats can be somewhat different, particularly in regard to what spare time means.

     
  • Mono and Bytecode Sharing

    Micheil Merlin 7:32 pm on December 2, 2009 | 4 Permalink | Reply
    Tags:

    Server version 1.24.3 in August of 2008, implemented Mono as an alternate way to compile and run LSL scripts. Mono is a free and open source implementation of Microsoft’s .NET and is sponsored by Novell. This is all pretty old news by now. But there is one feature in the implementation with Second Life that is worth talking about.  Bytecode sharing. 

    So, what’s a bytecode?  And how do you share it?

    The term ‘bytecode’ came into general usage when Sun Microsystems created Java.  But the concept is actually at least as old as 1966.  It was just called other things such as o-code, p-code and pseudo-code.  The idea behind all of these is that a compiler can translate a high level programming language into a hardware independent set of instructions that can either be translated into machine code or quickly interpreted at run time for a specific hardware platform.  This approach allowed compilers to be created that could be relatively easily ported to different hardware platforms or compiled code to be created that was independent of a specific hardware platform.  The hardware specific translator or interpreter would still have to be created for each hardware platform, but this was a far easier task than rewriting a compiler for each set of hardware to directly produce machine code for that hardware.

    And now to the sharing part. The Second Life server will only load one copy of the compiled bytecode for a script, no matter how many times that script occurs in the sim. So, 10 instances of the script use the same amount of memory as one instance of the script, not counting the data. Only the program code portion of the script is shared. Each individual usage of the script gets its own data area. The requirement to support bytecode sharing is that the same script is not recompiled each time it is placed in a new object. For example, each time you want to reuse the same script, either copy the object with the script intact or drag the compiled script from your inventory into each object without recompiling it. If you recompile the script the sim can no longer tell that it is a duplicate copy.

    In reality, this may be a small savings in memory. It is likely that in the 1,000s of scripts loaded in a sim, there may be a small percentage of duplication. And those that are duplicated may be small scripts like your fancy window tinting scripts. But, treating scripts carefully to support bytecode sharing is an easy thing to do and every little bit helps.

    You may have scripts that differ only in the setting of just a few variables. Having to compile slightly different versions of the same script would prevent bytecode sharing in addition to making it a little harder to maintain changes to the script. In future blog entries, I plan to show several methods to allow scripts to obtain different configuration options so that the same script can be used to perform slightly different operations.

     
  • Sim Stats - November 09

    Micheil Merlin 9:57 am on November 9, 2009 | 4 Permalink | Reply

    Welcome to the sim stats for November.

    SIM
    Micheil’s Rating
    Dilation
    FPS
    Physics
    Time
    Script
    Time
    Spare
    Time
    Script
    Speed
    Enerville star_09 1.0 45 0.1 16.7 4.2 0.87
    Ener Skerry star_08 0.99 45 0.2 14.9 6.2 0.82
    Ener Passage star_07 0.94 42 0.6 4.8 17.7 0.65
    Ener Strait star_07 0.96 44 0.1 5.7 16.3 0.72
    Enercay Midkey star_10 1.00 45 0.4 8.0 13.1 1.02
    Enercay Westkey star_10 1.0 45 0.2 11.2 10.1 1.01
    Enercity Harbor star_07 0.99 44 0.6 19.8 0.0 0.68
    Enercity Weston star_07 0.99 45 0.4 20.8 0.0 0.75
    Enercity Easton star_06 0.96 44 8.9 11.9 0.0 0.34
    Enercity Square star_09 0.99 45 0.1 13.1 8.2 0.86
    Enercity Shores star_07 0.99 45 1.6 18.2 0.0 0.72
    Enercity Park star_10 0.99 44 0.1 1.1 20.9 1.00
    Selected SL Regions star_06 0.99 44 0.8 19.3 0.2 0.51

    micheilsthoughts

    As part of the testing that I do, I always try to find a couple of empty mainland regions to run some test scripts in and capture elapsed times. I generally first try the same ones I used during the previous testing unless those regions are no longer empty. I look for regions with no objects and no scripts so the only scripts running in the region are the ones I’m carrying. If possible, I also look for regions that don’t show any child agents. And no, these really aren’t children…lol. In sim terms, a child agent is an AV that can see into your current region. These child agents do impact sim resources to some extent as the sim has to communicate certain information back to these AVs. Information about objects that the AV can see and where they move to, etc. For an empty sim, this extra child agent communication may be so minimal as to not make any difference.

    Anyway, I use these tests in the empty regions as a baseline to see what the best possible script performance could be. Generally, these empty regions test about the same as the best testing iLIVEisl regions. However, this time, several of the iLIVEisl regions actually tested better than these empty mainland regions. What’s up with that? Just when you think you sort of understand things, something changes. lol.

    There have been several more server releases in the last two months. A few more 1.30 releases and a 1.32 release. The release notes for these recent releases are still very slim on details. Either they contain very minor updates or not many of the updates are documented in the release notes. One thing of note, the 1.32 release contains this…

    Added back-end support for improved tracking of script memory usage

    Could that be in support of future script limitations referred to during the open space episode from last year?


    Some key points regarding sim performance.

    • A sim frame is 22.2 ms in length.
    • A time dilation of 1.0 means the sim is running at full speed.
    • As frame time gets larger than 22.2, time dilation drops below 1.0 and sim FPS drops below 45.
    • Spare time means there is time in the frame that the sim has nothing to do and is not running at capacity.
    • When busy, the sim will try to avoid increasing the sim frame time by spending less time running scripts.

    The above points apply primarily to full sims. Openspace and Homestead sim stats can be somewhat different, particularly in regard to what spare time means.

     
  • Burning Life '09

    Micheil Merlin 9:21 pm on October 22, 2009 | 1 Permalink | Reply

    BL09 Exhibit - Image Copyright Nickola Martynov
    The Monkey

    Burning Life is on again. This year’s event started on October 17th (yeah I know I should get this out earlier…lol) and officially ends on October 25th. If you haven’t heard of Burning Life or don’t know what it is, you can go read up on the Burning Life History. But to sum it up, to me it’s lots of art and exhibits. To other people, it’s parties, causes, dancing, music, basically much of the stuff you are used to finding in SL crammed into 34 sims for one week.

    For this Burning Life, I worked on an exhibit with Nickola Martynov entitled “How to Catch a Monkey”. If you know what a Rube Goldberg machine is, just think of that in a circus theme and you’ll have a general idea of what the exhibit is. If you’d like to take a look, go check it out here. And go check out Nikki’s blog for some more information about the build.

    As usual, there are many interesting builds to view and explore. But take your time. With so much content, rezzing is very slow. In fact, if you don’t spend some time walking around instead of flying, you’ll miss 90% of it.

    Here are some builds that I found interesting. When you land at these SLURLs, be sure to turn around and look for the exhibit. You’ll almost never be facing the correct direction after you TP there. And, as noted earlier, take some time and let things rez. It’ll be worth it :)

    The Roof is Gone by Miso Susanowa and Misprint Thursday
    You’ll want to get a notecard at the exhibit and read the hints for the best expierence. Turn on your music and media. Climb around in the exhibit and find all the things to interact with.

    Gulliver’s Travel by Ub Yifu and Copan Falta
    A big Gulliver tied up on the playa.

    Irregularity by Selavy Oh
    This one is a tall one. Make sure your sound is on and then fly around through this exhibit and watch (and listen to) the things that happen.

    !Filaments of Life by Kerryth Tarantal
    Another tall one. And made with fractals. Fractals are so cool :). This one is most impressive when your environment is set to midnight. Back up and take a good look at it then come close and walk around inside.

    Mars Landing by zeusdinne Baroque and Fafner Hoffmann
    Be sure to pick up a free rover out front.

    Primordial Soup by Maerok Westland with assistance from Traxie Ying and Sarita Meili
    Be sure to take a swim in the soup :).

    Among Other Things by AM Radio
    Make sure your media is turned on for this one. When you touch the spray can, you’ll get a link to a website where you can go make graffiti. When you publish your graffiti, it will show up on the side of the train (as long as your media is on).

    Burning Fantasies by Caro Fayray and Eliopod Beaumont
    Go to midnight for this one also. Ride a cloud.

    Candlemania by Arrow Inglewood
    Another one that looks nice at midnight.

    And many, many others….

    Oh, and if you see a Porta Potty, go check it out. Some of them are as good as the exhibits themselves :).

     
  • Sim Stats - September 09

    Micheil Merlin 7:48 pm on September 20, 2009 | 2 Permalink | Reply

    Welcome to the sim stats for September.

    SIM
    Micheil’s Rating
    Dilation
    FPS
    Physics
    Time
    Script
    Time
    Spare
    Time
    Script
    Speed
    Enerville star_07 0.99 45 0.5 20.0 0.0 0.63
    Ener Skerry star_10 1.0 45 0.1 11.0 10.3 0.99
    Ener Passage star_06 0.96 43 4.7 1.8 16.0 0.43
    Ener Strait star_09 0.98 44 1.2 5.2 15.8 0.85
    Enercay Midkey star_09 1.00 45 0.4 14.8 6.2 0.83
    Enercay Westkey star_10 1.0 45 0.6 13.4 7.3 1.00
    Enercity Harbor star_09 0.98 44 0.2 20.7 0 0.84
    Enercity Weston star_07 0.99 45 1.1 19.4 0 0.62
    Enercity Easton star_06 0.98 44 12.9 7.3 0 0.16
    Enercity Square star_09 1.0 45 0.2 10.1 10.8 0.84
    Enercity Shores star_10 1.0 45 0.4 18.4 1.9 0.98
    Enercity Park star_10 0.99 45 0.1 1.1 20.8 1.02
    Selected SL Regions star_06 0.99 44 1.9 16.6 0.0 0.46

    micheilsthoughts

    In the past week, a new server version, 1.30.0.133784, has been deployed. The release notes don’t say much about this version. You may notice that the server version numbers jumped from 1.27 to 1.30. Normally, this would imply some fairly significant changes. Instead, the version number jump just reflects a new version numbering scheme. There is a forum entry from Dante Linden regarding the numbering convention.

    We’re using even-numbered minor release numbers for production releases and odd-numbered minor release numbers for internal, development versions.

    I have noticed just this last week, that the Pump IO statistic under Time Details is now registering some time. Previously, I only noticed Pump IO values over 0.1 for openspace or homestead sims. Open the statistics bar with Ctrl-Shift-1 or by selecting the option on the View drop down menu. Pump IO can be found by expanding Time and then Time Details. What this statistic means does not appear to be documented anywhere that I can find. Since I’ve only seen appreciable values for openspace or homestead sims, my assumption has been that this statistic was related to something that indicated the lost time and resources that a sim thought it should have but actually didn’t have because some other sim on the same processor core was using the resources. This processor core sharing has only been documented to occur for homestead and openspace sims. In any case, I’m now seeing intermittent values above 0.1 in this statistic where I normally saw only 0.0 or 0.1.


    Some key points regarding sim performance.

    • A sim frame is 22.2 ms in length.
    • A time dilation of 1.0 means the sim is running at full speed.
    • As frame time gets larger than 22.2, time dilation drops below 1.0 and sim FPS drops below 45.
    • Spare time means there is time in the frame that the sim has nothing to do and is not running at capacity.
    • When busy, the sim will try to avoid increasing the sim frame time by spending less time running scripts.

    The above points apply primarily to full sims. Openspace and Homestead sim stats can be somewhat different, particularly in regard to what spare time means.

     
  • Prim Twisting

    Micheil Merlin 11:22 pm on September 16, 2009 | 2 Permalink | Reply

    Now there’s a term!

    Depending on your level of building experience in SL you may already be familiar with that term. But even if you are an experienced builder, it’s very likely that you’ll be surprised just how far you can twist a prim. Prims put through this much torture can create shapes that you would normally think would require several prims or a sculpty. All of the shapes in this picture consist of only one prim!
    Twisted Prim Display

    Ayumi Cassini has a complete tutorial on how to create these prims on her blog. Many thanks to her for collecting this set and for her willingness to share these secrets.
    Thanks also to Torley for pointing out Ayumi’s tutorial in one of his Tips and Tricks posts.

     
  • Sim Stats - July 09

    Micheil Merlin 7:44 pm on July 21, 2009 | 2 Permalink | Reply

    Welcome to the sim stats for July.

    SIM
    Micheil’s RATING
    DILATION
    FPS
    PHYSICS
    TIME
    SCRIPT
    TIME
    SPARE
    TIME
    SCRIPT
    SPEED
    Enerville star_09 1.0 45 1.1 12.0 8.4 0.87
    Ener Skerry star_09 1.00 45 0.2 15.4 5.7 0.83
    Ener Passage star_07 0.98 44 0.4 5.9 15.4 0.66
    Ener Strait star_07 0.99 45 1.0 6.4 15.3 0.67
    Enercay Midkey star_10 1.00 45 0.4 15.8 5.1 0.96
    Enercay Westkey star_10 1.0 45 0.6 18.2 2.3 1.01
    Enercity Harbor star_07 0.99 44 0.4 20.1 0 0.67
    Enercity Weston star_06 0.98 44 2.0 17.2 0 0.37
    Enercity Easton star_06 0.99 44 10.9 9.7 0 0.38
    Enercity Square star_08 1.0 45 0.5 14.5 6.1 0.81
    Enercity Shores star_10 1.0 45 0.6 18.6 1.4 1.00
    Enercity Park star_09 1.0 45 0.1 1.1 20.5 0.89
    Selected SL Regions star_06 0.99 44 8.5 12.1 0.0 0.37

    micheilsthoughts
    For those of you counting, you’ll know that there wasn’t a Sim Stats report for June :). June was sort of busy…lol.

    Anyway, over the past month, server version 1.27.0.127440 was rolled out. The major highlight of this release is the LSL HTTP-In facility that allows prims to become mini web-servers. Review the release notes for information about this server version. Details for LSL HTTP-In can be found in the wiki. Before you get too exited about being able to create little web servers out of your prims, there are some drawbacks related to the persistence of the URL used to address the prim. The major limitation is that the URL goes away when the sim is restarted. The limitations make sense when you consider that there has to be some way to clean up unused URLs. Darien Caldwell has published some notes in the forum about how to use Google App Engine to provide a dynamic naming service for use with HTTP-In, that would allow you to maintain a consistent way to contact the prim even after URL changes.

    Even with the limitations, there is some excitement about this feature. Doran Zemlja of the Astria Porta Open Stargate Network, has been busy converting the communication between the stargates to use this new function. And those of you that know me know that I consider stargates to be just about the coolest thing in SL :) and am very fond of the Open Stargates in particular (even contributed textures and sculpties). Previously, llEmail was used to pass information between stargates and there have been some long standing bugs related to email queues getting hung and such. So, Doran has high hopes that the use of this function clears up some long standing issues.

    Now back to the sim stats…

    Things look pretty good this month. In general, the iliveisl sims usually seem better than any average sampling of similar sims. But this month is even better than usual.

    To assist in taking a more objective look at sim performance, I use a simple script to measure elapsed run time. During this month, I noticed that the run time on empty or nearly empty sims seems to be longer than I’ve seen previously. Not by a lot. Up to 45 to 46 seconds for a test that used to be about 40 seconds. I use the run time on several empty sims as a baseline for comparing other sims. I don’t know if this is due to the server version change or something else in the infrastructure. In any case, for this month, I made slight adjustments to the formula that I use to assist with the rating.

    Some key points regarding sim performance.

    • A sim frame is 22.2 ms in length.
    • A time dilation of 1.0 means the sim is running at full speed.
    • As frame time gets larger than 22.2, time dilation drops below 1.0 and sim FPS drops below 45.
    • Spare time means there is time in the frame that the sim has nothing to do and is not running at capacity.
    • When busy, the sim will try to avoid increasing the sim frame time by spending less time running scripts.

    The above points apply primarily to full sims. Openspace and Homestead sim stats can be somewhat different, particularly in regard to what spare time means.

     
  • Second Life 6th Birthday

    Micheil Merlin 9:07 pm on June 27, 2009 | 2 Permalink | Reply

    SL6B

    The celebration of the 6th birthday of Second Life opened on June 23, 2009.  There are 20 SL6B sims filled with the creations of your fellow Second Life residents.  The official celebration runs through June 29th with the last event scheduled for June 30th.  But you can visit the sims until July 6th.

    The sims are set to midnight and most of the builds were created with this in mind. Lots of glow. So, in general, things should look more attractive letting your viewer stay in midnight.

    I was fortunate enough this year to be able to build an exhibit at SL6B with a friend and fellow iliveisl resident, Nickola Martynov. Visit our exhibit at Space is There… in SL6B Uplink. There is a video to watch and things to interact with. Be sure to take the space elevator up to explore the planets.

    The sims this year follow a theme created by Phaylen Fairchild.

    800 Light Years away we are spiraling through outer space on a Meteor discovered by Space Explorer Ghorman Dallier in 2499 while searching for new worlds to inhabit! Although we’re too far away from the sun to see it and any flora has to be kept in an AEC (Artificial Environment Chamber.) we still know how to throw a party!

    Further information. SL6B Wiki and Blog

    The cloning station in SL6B Paradox is a central jumping off point to the infrastructure builds. Click the planet with the name of the infrastructure build that you’re interested in. You can also click on one of the large signs and receive a touring hud along with some other items.

    Catch a tram that tours the SL6B sims. I understand the tour takes about 35 minutes or so. These tram stops are all over the SL6B sims at many road intersections. Press the small button to call a tram or click the sign where it says ‘click’.

    The following are all exhibits that I found interesting. My criteria was mostly interesting things to look at, games to play or interesting things to interact with. If you like causes, culture, etc., those things are there also.

    The OmniPrim by Crap Mariner. This one is interactive and occurs on a schedule. Visit the site to see when the next ‘performance’ is. I’m getting this out so late, there may not be many left. Sorry about that.

    Folding Minds by Kolor Fall. Be sure to locate the obelisk looking thing and draw on it with the mouse. Then watch the blocks move around in the background. There are some instructions at the site.

    Atmospheric Clouds by Caro Fayray.

    Future Games and Leisure by MoutainLion Shinn. Bumper cars. You can have some fun by yourself, but these are probably best with someone else you can bump in to. There are two levels. Find the tunnel that takes you to the 2nd level.

    Synthetic University by MosMax Hax.

    Virtual Sport nexus – Simboarding by Cyphien Heart. Yes, really simboarding on a half pipe.

    Polaris by Sabine Stonebender. Actually, the name might not be Polaris as that is the name of the sim. But it’s the only name I saw.

    Mechatiki Research Public Lab by magggnnus woodget. Little physical robot animals that randomly walk around their enclosure.

    The Wall of Mirages by Robin Moore.

    The Future is Ruth by Manx Wharton and Nestra Careless.

    Your Future Will Be… by Scrap Godenot.

    Dizzy Banjo, Gestural Instrument. This is on public land. The point of interest here is the 3 round objects with Dizzy Banjo’s name on them. Interact with them and figure out what they do.

    sl6b_030

    Space is There

    Flicker set by Ener Hax

     
  • Sim Stats - 05.16.09

    Micheil Merlin 5:13 pm on May 16, 2009 | 2 Permalink | Reply
    Tags: , ,

    Welcome to the sim stats for mid-May.

    SIM
    Micheil’s RATING
    DILATION
    FPS
    PHYSICS
    TIME
    SCRIPT
    TIME
    SPARE
    TIME
    SCRIPT
    SPEED
    Enerville star_06 0.93 42 1.1 19.7 0 0.45
    Ener Skerry star_10 1.00 45 0.1 15.0 6.3 0.99
    Ener Passage star_06 0.98 44 3.4 4.5 14.1 0.35
    Ener Strait star_10 0.99 45 0.1 0.9 21.1 0.98
    Enercay Midkey star_08 1.00 45 0.3 16.6 4.6 0.86
    Enercay Westkey star_10 1.0 45 0.3 2.1 19.7 1.02
    Enercity Harbor star_07 0.99 44 0.3 20.2 0 0.69
    Enercity Weston star_06 0.99 45 1.4 18.8 0 0.42
    Enercity Easton star_06 0.98 43 6.7 15.3 0 0.64
    Enercity Square star_08 1.0 45 0.6 14.8 6.2 0.86
    Enercity Shores star_10 1.0 45 0.3 17.4 2.7 0.96
    Enercity Park star_08 1.0 45 0.2 1.1 20.4 0.87
    Selected SL Regions star_06 0.99 44 1.0 18.7 0.2 0.5

    micheilsthoughts
    Over the past month, server version 1.26.3.118673 was rolled out. The bulk of the changes seem to be geared toward the coming adult content implementation.

    Also, since the last report, Enercay Westkey has been upgraded from a homestead to a full sim.

    The statistics that I collect largely come from the statistics bar in the viewer. You can open this bar by selecting the View tab at the top of the screen, then selecting Statistics Bar. The Second Life Wiki contains some information related to how to interpret some of this statistics. When reading the wiki, keep in mind that the current simulator version is 1.26 and the viewer version is 1.22.11. The release candidate viewer, 1.23.1 (119104), will save the state and screen location of the statistics bar if it is open when you log off and will open it again the next time you log on. Previous viewer versions did not save the state of the statistics bar.

    The simulator divides the work it has to do into time slots generally referred to as a frame.

    In the statistics bar, you’ll see frame referenced in a couple of different ways. The first, under the Basic heading, represents work that the viewer is doing. This is the frame per second (FPS) statistic that relates to how many times per second the viewer redraws you screen.

    The second place you see frame referenced is under the Simulator heading. Here you’ll see Sim FPS and Physics FPS. The Sim FPS and Physics FPS numbers should be very close to the same. In practice, they usually vary from each other just a tiny bit.

    The sim frame represents a slot of time that the sim uses to coordinate and complete its work. Things like accounting for sim weather, updating all the AV’s present with various information, running scripts, handling network traffic, etc. The physics part of the simulator also spends part of this time updating everything related to how physical objects are interacting with each other and other objects in the sim. By design, 45 FPS is the target rate for the sim. That means that each frame should ideally be 22.2 milliseconds (ms) in length. You get that number by dividing 1,000 ms (1 second) by 45.

    So, what happens if there is too much work to do in 22.2 ms? It used to be that this was where time dilation kicked in which means that the frame times get stretched out to be longer than 22.2 ms. But now, the first thing that happens is that the sim devotes less of this time slot to running scripts. So, scripts slow down. In many cases, this can go fairly unnoticed allowing the sim to continue to appear to be running ok.

    When slowing down scripts isn’t enough is when adjustments to the frame time happen. If you expand the Time section under Simulator, you’ll see Total Frame Time. Under load, that number will rise above 22.2 and the Time Dilation number will decrease below 1.0. If the sim is able to keep the frame rate up fairly well by slowing down scripts, you’ll generally see a time dilation of .99 with a frame rate of 44 to 45 and a total frame time of about 22.3 ms.

    One really good indicator of whether or not the sim is busy is the Spare Time statistic. If there is any non-zero number here, then it means that this was the amount of time in the frame that the sim had nothing to do. However, it is not very normal for this number to be something other than zero which probably reflects how much we like scripted objects and physical objects.

    An exception to the spare time ‘non-zero is good’ rule is if the sim is not a full sim and is instead a homestead or openspace sim. In the case of a homestead or openspace, the spare time number can be greater than zero and the sim can still be overloaded. I think this is because homestead and openspace sims share processor cores, they don’t know how busy another sharing sim is and the sharing sim might be taking more than its share. There is also the fact that the whole idea of 22.2 ms frame time is based on a sim having complete access to processor resources and when there are sims sharing processors, that isn’t the case. But, that’s another subject.

    In summary…

    • A sim frame is 22.2 ms in length.
    • A time dilation of 1.0 means the sim is running at full speed.
    • As frame time gets larger than 22.2, time dilation drops below 1.0 and sim FPS drops below 45.
    • Spare time means there is time in the frame that the sim has nothing to do and is not running at capacity.
    • When busy, the sim will try to avoid increasing the sim frame time by spending less time running scripts.
     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
esc
cancel