My problems stemmed from the fact my scripts often contain the following statement:

default {
on_rez(integer start_param){
llResetScript()
}

I primarily do this in any script where I use llGetOwner() in order to ensure that any listeners or other functions depending on the users key are set up correctly.  However, resetting the script means that it sets any variables used back to default values.  My work around for this was to store the variables in the description field of a child primitive, a technique known as primitive parameter overloading.

If my objects were just rezzed on the ground, I would of been OK at that point.  But they are not, they are worn attachments.  Attachments don’t tend to easily let you edit there description fields when worn.  If the description is blank, it seems to let you write it once or twice, but not always.  Attachments will revert any object name changes on being un-worn, it looks like the description field gets reverted as well.

However, after a little advice from a friend who mentioned that I was probably doing something fundamentally wrong and I that shouldn’t be using llResetScript() in the on_rez event if I wanted to persist data, I decided to go back and revisit events and how they are triggered.

So back to school for me.

First, lets do some testing.  Lets consider the following bit of test code

integer myValue = 0;

touch_start(integer total_number) {
llInstantMessage(llGetOwner(),"touch_start: "+(string)(++myValue));
}
}

I’ve used llInstantMessage() here because everyone hates spammy debug shouting at them.  I could of used llOwnerSay() but I considered that I might want to test across sim borders (llOwnerSay seems to cover entire regions).  The only downside to llInstantMessage is that it sleeps the prim for a couple of seconds when used.

So drop the script into the test prim, what do you get?

Test Object: state_entry
Test Object: myValue: 0

State entry is called when you script is first put into a prim, because this is the first time it enters the default state. OK, take it into inventory and rez it back out again, note that state_exit never gets called

Test Object: on_rez: 0
Test Object: myValue: 0

First thing to note here, state_entry is not called! This is because the script never left the (current) default state. The on_rez event is always called when the object is rezzed (you might like to try walking away from the prim until it is out if sight and then walking back towards it and see what happens).

Next, touch it a couple of times, take the prim back to inventory and then wear it

Test Object: on_rez: 0
Test Object: myValue: 2
Test Object: attach: 1b61897c-d2ea-4314-bca4-d5d9307c1ba4
Test Object: myValue: 2

Note, the on_rez is called as well as the attach event, taking the object back off gives you

Test Object: attach: 00000000-0000-0000-0000-000000000000
Test Object: myValue: 2

Which is correct.  The null key indicates that the object is being detached.

If I reintroduce llResetScript() into the on_rez, then I start to run into problems.  When I attach the object, because on_rez is being called myValue is reset to declared default.  So instead of the messages above, I get the following:

Test Object: on_rez: 0
Test Object: state_entry: 0
Test Object: myValue: 0
Test Object: attach: 1b61897c-d2ea-4314-bca4-d5d9307c1ba4
Test Object: myValue: 0

Ouch, variables reset, and I get both on_rez and state_entry.  But I can’t simply remove the llResetScript() because that would mean that the object would listen only to me and not the new owner when they purchase it. 

Fortunately a friend had the solution to how it should be done, the following code snippet was suggested to me:

changed(integer change) {
if (change & CHANGED_OWNER) {
llResetScript();
}
}

This makes the items reset when the owner is changed - excellent! This is probably the code that I should also have in all my box unpacking scripts as well.

However, what happens if I don’t want it to reset because it’s a limited use item?  As long as the item isn’t transferable, then this is still OK.  However, if the item is transferable then using this code would mean the person would only have to transfer the item to refresh the usage - not good!

The answer, well that is in the LSLWiki, use a global initiation function in both the state_entry and on_rez events and that should catch all instances:

init() {// do lots of initiation here }
default {
on_rez(integer start_param) {init();}
state_entry() {init();}

This is of course really basic stuff.  But sometimes its the basic stuff that trips you up!

This is also a lesson about relying too heavily on debuggers.  I have of course tested my scripts in LSLEditor first before deploying them.  However, LSLEditors debugger lets you fire off the individual events.  But if you are assuming that events are triggered in situations where they are not - then it can’t correct that mistake.

When I first came into SL in 2006, I remember stumbling across the Cleary region and finding a stargate there.  I took one of their free stargates and placed it at my home in Jsindo.  At the time I was on a 512m² plot and a stargate ate badly into my prim allocation so I removed it and thought nothing more.

The Stargate looks cool and serves as a nice central item for the sim rez point in Abalus.  It also provides a link into a network of other gates.  But does it have any other uses?

Why have a Stargate?

So why have a Stargate?  The gate could be taking anything up to ~200 prims that you could be using for item vendors or product displays.  They are also scripted items that could be adding lag.

However, a Stargate has a potential use as a marketing tool, to understand the reason why this might be, you have to consider how people move around in SL compared with reality.

Too move between two sims you generally do point-to-point teleports.  You would not walk or fly between sims because it would take too long.  Besides, if you are on a single sim island there is nowhere to fly to!  If you are on the mainland there are usually too many obstacles (ban-lines, etc) in the way.  Within a sim, generally most people either walk, ride or fly depending on the mood and distances and obstacles.

This also means there is generally no benefit or disadvantage in being in any one location, because it takes the same effort to get to one sim as another.  In real-life a person is more likely to use a shop that is close to them, then to travel to another town.  Unless the shop in the other town offers some benefit the close one doesn’t (such as prices or range).  There is benefit is being in a specific location that is popular with your target market.

The Stargate has a random function - this allows you to randomly dial another gate without having to know it’s name.  This can effectively link the sims with gates together as an entity.  In some ways it is like having a giant mall where the Stargates are the level escalators.  A person can be at another sim location, dial random, and end up at your location.  If they randomly clicked on the SL main map, the odds that would click on your location is probably fairly low.

So therefore, people who visit a sim with a Stargate possibly might also visit another sim with a Stargate on the same network (assuming they know how to use it).  Those random visitors are likely to explore the surroundings they land in and might go on to buying something.

However, this assumes that there is a high-visitor volume location somewhere on the network from which people can dial from.  This isn’t necessarily the case, I did a number of random dials and the gates I visited where either:

• 6 island sims with private homes (community gates)
• 5 empty nightclubs/malls (ok, I visited in the quiet time, but still…)
• 4 good “feature areas” like the sgc, midway
• 4 gates at high altitude in reception blocks

I only went to about 20 gates (Alteran has over 350 gates), so this isn’t a representative sample.

Vistor Demographics

So who is likely to actually use the stargate?  For a newbie, using a Stargate is not necessarily clear.  Therefore the most likely visitors into your Stargate are going to be existing gate owners or Stargate role-players.

Looking at existing statistics (for Jsindo rather than Abalus), on average there is only 1 visitor a day.  This is probably consistant with a friend using the gate, or another sim owner.  Since both Abalus and Jsindo get a number of random visitors per day (anything from 4-8) it is obvious that these are generally not appearing via the stargate.

One of the issues is that you need to know the command to operate the gate.  I have put a “How To Use” notecard dispenser next to the stargate to get the newbie’s into the network and hopefully that will increase gate usage (although effectively sending my customers away!).

So which Stargate network should you use?

There have been a number of Stargate networks that have popped up in SL, some are small, others are large and I won’t claim to be familiar with all of them.  The original Cleary network still exists and there are two other large (>200 gates) networks also; Alteran and Open.

Unfortunately these networks don’t yet talk to each other and therefore you can’t transparently move between them.  Ideally, I would like to see the day when all the different networks can talk to each other and thus support seamless transporting between networks.  One option you could do, assuming you have space and prims, is to have all gates from all three networks on your land (there are those that provide this “hub” service).

Which gate network to choose comes largely down to personal preference.  You could look at the list of gates on the network and choose one that has sims which you would like to be linked to.  If you are really low on prims, the Open Network does offer a single prim gate and single prim DHD and the Alteran network has a couple of low prim gate designs.

Jsindo is on the Alteran network, mostly because Abalus is on it, but also because I ultimately prefer the design of the gates and the options that come with it.

OK, I got a Stargate, What now?

The obvious stuff, make it a pleasant area to visit.  If a SGC team do visit and you have  gaudy advertising hoardings all over the place they are probably going to dial out just as quickly.  The same actually goes for any selling area, having a nice environment for your customers to visit is as important as price, product and location.  The Stargate creators often also offer advice and guidelines on how to locate a stargate.

Having a Stargate will not guarantee extra traffic and extra sales.  But having one means you have got something that potentially might generate extra traffic, plus, they look cool anyway!

Links

• Alteran Stargate Network
• OS Labs - Stargate Accessories
• Opengate Startgate Network
• Cleary Stargate Network

I don’t have the time or skill to build everything a sim needs, so time to go shopping!

Botanicals

Unless the sim is themed to be a barren wasteland, it needs trees, bushes and flowers.  Abalus has a Mediterranean island type theme.   The whole concept of the area is an old volcano which blew it’s top off many thousands of years ago (and the detritus has settled inside the cone) .

To save on prim allocation, around the outside of the island I have generally used Linden trees; these are 1 prim and generally look acceptable for most people (depending on graphics setting).  But within the Island itself I prefer to use prim trees, especially given the nature of the Linden trees to encroach on buildings (depending on wind and graphics settings).

I favour trees from the Heart Garden Centre, these are well priced (often 299L$ or 399L$ for a multipack of 12 trees) with excellent textures and many trees are 6 prims or less.  I really like the Heart silver birch trees and think those are probably the nicest trees they make.  I have combined these with Mediterranean Pines and Mountain Pine for most of the general areas.  On the dragon beach I have used tropical palms.  Scattered around the Island are also the odd Lemon tree and Olive tree.  Equus has Apple and Orange trees, so it looks like we won’t have any shortage of fruit!  On the Isle of Wyrms proper Daryth has also used Heart trees, so this also helps keep the sim looking consistent with the rest of the continent.

I did consider buying some Straylight Botanicals forest trees, however the smaller trees are ~35 prims each (priced at around 160L$ per no-copy tree) and the mega tree just dominates the whole sim.  If I was making a tree house forest sim these would be my first choice however!  I recommend visiting ElvenValley to see a really nice forest sim with the Botanicals trees nicely used (including a mega).

Another tree maker worth mentioning is Julia Hathor, her trees are also very nice, very prim efficient and have some nice features (like the apple trees that do drop apples).  Although I find that it isn’t easy to integrate her trees with Heart and get a consistent look.

Again for bushes I tend to favour Heart, expect to see some Purple Loosestrife, Foxgloves and maybe even some grape vines turning up.

Structures

Most of my major builds are my own, due mostly to the fact I like building structures rather than a lack of purchasable alternatives.

Zephyr told me about the Swinging Rope Briges by Gypsy Paz.  I picked up a copy-mod set for 800L$ through SLX.  The bridges come in 20, 30 and 40 meter lengths and worst case requires 41 prims.  These move when you walk across them! and the effect is really accentuated if you lay them at a slight angle.  The only limitiation is that the bridges don’t like to be put across sim boundaries (they seem to go phantom).

On the South Eastern corner of the Island we have a Secret Hatchie tower.  This tower is intended to be a secret hiding place where the hatchlings can scheme and plot, plus it has really good views into Equus (with boxes under the windows so hatchies can see out).  I wanted to add a pirates cannon for the tower.  I found a few cannons on SLX which looked OK in the ad, but once rezzed either the textures were a bit naff or they were very primmy (40 prims in one case).  Then I recalled that I had seen a good pirates cannon on the Hatchie Haven sim (another Zephyr find).  Examining the creator of that object, I found it was made by Lia Woodget.  Using her picks I located her home store and picked up the no-copy Elysium cannon (16 prims) for 180L$.  This has a really nice sound and smoke effect to it (as well as shooting a cannon ball).

The tower also has lockable doors by Sirius Creations.  These doors are highly configurable (sound, speed, and a lot more) and come in a very wide range of styles.  They are low lag (0.05 max on the script console) and are a snip at 85L$ for a no-copy mod/trans single door.  I choose a couple of solid looking wooden doors and locked the inner one (have to keep my cookie hoard safe).

The other major structural element in the sim is the fishing area; this is a 7Seas fishing complex.  This system is very nice in that the whole installation is both low prim (you could have fishing with just one prim) and has low script usage.  The 7seas system is very good, both from an owners and users perspective.  It is cost effective (a low 750L$ one off cost to acquire the system) , there are frequent updates to keep people interested and the fish that you acquire are fun pets, and are often highly detailed.  My only criticism would be that my dragon can’t hold the fishing rod - not that there would be room for many dragons on the wharf anyway!

Wildlife

Scripted animals can be on the whole a bit laggy therefore we have to be careful what goes down.  Generally we are using scripted animals from Animania.   We have Jellyfish, Swans, Gulls and a Hummingbird.  I did also have a Shark, but this seemed to be a bit more laggy than the others, and a crab but the slope algorithm in it could not handle the megaprim sphere I use for my beaches.  Most of the Animania animals cost between 500L$ and 700L$ for a single animal and are very low prim (as they are sculpties).  We also have Piranhas from Splash Aquatics and these do bite - so don’t fall in the lake!

I may eventually put down some of my exploding sheep - so watch out if you try to eat one.

Shopping links

Here are some links to the shopping locations mentioned above.  Beware! Sometimes content creators do move there shops around, if in doubt check the creators profile.

Heart Garden Centre (Lillith Heart & Dolly Heart) - Trees, Bushes, Flowers

Botanicals (Kriss Lehmann) - Sculpti Trees

Creative Fantasy (Julia Hathor) - Trees, Houses. Birds, Butterflies

Gypsy Gadgets (Gypsy Paz) - Canoe, Swimballs and Swinging Bridge

Black Spot Shipyard (Lia Woodget) - Boats (static), Cannons and other seafaring items

Sirius Creations (Innes McLeod) - doors, gates, also furniture cabinets and beach towels

Animania (Vinnie Baxter) - animated animals, ducks, swans, sharks, hummingbirds, etc

Splash Aquatics (Kaikou Splash) - fish and fishy things!

1. Asset failed to compile/save (generally when the asset database is throwing a hissy fit)
2. SL ate the script
3. Finding scripts reverted in objects
4. Silly errors in scripts!
5. Script stopped running

Some of these just come down to doing things correctly and having patience (#3 is often down to taking an object back into inventory after modifying a contained script, before it has compiled and saved). However, trying to develop and debug scripts in-world can often be very time consuming. When SL is being laggy, often it takes some seconds for a script to compile, save and reset ready for testing.

One of the alternatives is to use an offline script development system. The one I use is LSLEditor which is an open source tool created by Alphons van der Heijden.

LSL Editor performs a number of functions, it has code completion and code tips (useful for if you can’t remember all the arguments to a function, or the exact name). It can check if your LSL is semantically correct and it has a debugger function. There is also a “Solution Explorer” which allows you to build a virtual object and test the interactions between multiple scripts.

Using LSL Editor

The easiest way to use LSL Editor is to just open it up and type your script directly in, check the syntax and transfer the script in-world. This does not use all the abilities of the tool, but this can still be a timesaver when SL is down and you still need to work on scripts. One point here, it’s important to maintain synchronisation between your in-world and out-world script library. There is nothing worse than not having the latest and greatest to hand when you want to do some development.

Debug It!

The debugger is probably the most useful feature of the tool. The ability to write some code and throw it into a debugger to work through your use cases and verify it behaves as expected. There are some limitations. The LSL Editor only provides scope to define a fairly simple object environment, if you need a complex scenario you have to test in-world. There is also no scope to view prim options such as colour or movement, you can however read these options being performed in the debug window.

In the basic debugger (not the Solution Explorer), there is also limited ability to interface with inventory. You can’t check inventory contents or read a notecard.  However, if you configure an object in the solution explorer, you can perform these options plus you can have multiple scripts in multiple objects.

The debugger is a pretty powerful tool and some basic tests can save a lot of time in-world. One of the nice features is that it does not constrain you in what you do to your script, for example you can send LSL events in any order (such as a detach before the attach) and watch the results.

It’s not Perfect!

LSL Editor does have areas where it differs from the in-world LSL compiler. The effect of this is that in some cases a script will behave differently from in-world.

One example is if you want to do a Switch statement. LSL does not support Switch, therefore you have to do it by:

// switching integer n
if (n == 0) {
    llOwnerSay("You typed zero.\n");
    jump break;
}
if (n ==3 || n == 5 || n ==7) {
    llOwnerSay("n is a prime number\n");
    jump break;
}
if (n == 2 || n == 4 || n == 6 || n == 8 ) {
    llOwnerSay("n is an even number\n");
    jump break;
}
if (n == 1 || n == 9 ) {
    llOwnerSay("n is a perfect square\n");
    jump break;
}
@break;

This will compile and debug in LSL Editor, but it will not work in-world. This is due to a bug in LSL in which you must have one jump target for every jump source (so you end up having break1, break2, break3, etc). This is a bug in LSL Editor because it does not contain the bugs that SL does!

LSLEditor also lets you do some silly things that the SL compiler seems much more strict on, such as integer number = (integer)(string) keyValue or for (integer n = 0; n < 10; n++). This can be a bad thing since only the really experienced instinctively avoid writing silly things into scripts.

There are a number of other issues with LSLEditor posted on the SecondLife Wiki, however it is always a good idea to check the details of the function you are using just in case there are any known quirks or bugs.

Other Options

There are other editors available, mostly those that provide code highlighting and tooltips, some provide semantic checkers as well. The full list can be found on the list of alternate editors on the LSL wiki. LSLEditor is unfortunately only available for MS Windows.

There was one other development tool which did catch my interest. I noticed there was a plug-in for the Eclipse framework called LSL-Plus. I’ve used Eclipse for C/C++ development and it is a very good tool. It still seems to be in Alpha development, so at some point I’ll give it a try and post some thoughts.

The Scores on the Doors are…

So, given my original list of annoyances:

1. Asset failed to compile/save (generally when asset database is throwing a hissy fit)
2. SL ate the script
3. Finding scripts reverted in objects
4. Silly errors in scripts!
5. Script stopped running

LSLEditor helps with (1) in that the server being slow doesn’t slow down development, and keeping a copy out of SL solves (2) as well. Going through a debug process will help keep down the number of bugs (4), but not completely prevent them due to the limitations of the tool.

Strange SL defects like finding a script has stopped or that it has reverted can’t be solved by the tool. Well 3 out of 5 ain’t bad.

Abalus, also known as the Island of Amber, is an Open Spaces sim. The sim is shared between the Purple Wyvern group and the Caudra Draconis group. This will soon be the new home location for the Purple Wyvern outlets. Jsindo is staying, alas delegated to second fiddle. This means that the Avendale Ruins location will be for sale soon!

Open Spaces Sims

Open Spaces sims are meant to be “void” sims used to provide ocean or open space areas. On a sim host, four Open Spaces sims occupy the space normally occupied by a normal sim. This means that an Open Spaces sim has much lower capabilities then a conventional sim. The most visible difference is that the sim has a limit of 3750 prims instead of 15000, but load up an Open Spaces sim with avatars and scripts and the other limitations become apparent too.

The benefit is that an Open Spaces sim costs a lot less than a normal Sim, but to own one you must already have a normal sim. Fortunately, Isle of Wyrms owner, Daryth Kennedy is starting to rent Open Spaces sims for residential use and is allowing commercial use in certain cases.

Terraforming

Terraforming a sim is an art that requires patience! The easiest way to do it is to use external tools to generate the RAW file and upload that. However, only the estate owner can upload RAW files on to the sim. As a tenant, I hold the Estate Manager roles, which allows me a lot of things, but not major terrain works.

The standard Land Editing tools are best left to small scale land terraforming. I tried to do a major change and had to revert it since everything just looked too blocky. Here are some useful tips for terraforming!

• Use select land and “Apply to selection” with care. This is the easiest way to end up with blocky terrain.
• Make small quick brushes with the selector for best effect, and use the smallest selection brush you can get away with.
• Using the “Flatten” tool and sweeping from higher to lower land seems to be an effective (but slow) way of extending hills and land into the sea (but mind, you could end up with a flat terrace if you don’t change your starting pont each time).
• Using the Flatten tool the other way around is a good way of cutting a channel or river
• The “Smooth” tool doesn’t smooth to a flat area! (It’s a bit weird).

Estate Management

Unfortunately the Estate Management tools are fairly undocumented in what they do and what are valid settings combination’s. The first thing I came across is teleporting, telehubs and landing points. As an Estate Manager I can by-pass a lot of the teleport limitations (I’ve not tried going into a banned parcel, but pretty sure I can). However, a non-estate manager can not.

Out of the box, the sim was set to not-public (which means you have to be on the named access list) but also with no direct teleport allowed. As I didn’t have a telehub set, any user on the access list who tried to teleport in were denied (had I been connected to a sim that was public, they would have ended up there). They were not actually barred, it was just the sim was redirecting them to the nearest telehub. That was in the next door sim, which was non-public. OK, allow direct teleports problem solved…

Telehubs

We wanted to initially add a telehub at our Stargate. Telehubs make all incoming traffic land at the telehub (except Estate Mangers, the Estate Owner and Officers in the group that owns the land). If you don’t mind that all your traffic lands at one spot, then they are the thing to use.

However, if you are going to cut plots and want to allow people to land at those plots, then you would use plot landing points instead. After some training by Onix Harbinger, I was ready to make my own Telehub. The instructions to do so can be found at the Second Life wiki under Estate and Private Region Telehubs and Direct Teleport. This particular wiki page isn’t the easiest to find!

A couple of bits of excellent information given to me by Onix were:

• You have to have at least one Spawn Point.
• Telehubs and Landing Points are mutually exclusive - if you set both then who knows where people could rez in!

The Future…

Abalus presents the opportunity to present the purple wyvern products plus it allows space, so the vendors no longer need to be crammed together. The fact I need to make a few dragon orientated items for the sim also provides a few new ideas for products…

So watch this space… and Abalus…

The treasure chest itself is based on a stripped down version (from about 16 prims to 3) of Daryth’s treasure chest from one of her building kits. To save prims I decided to move the chest lid instead of having 2 chest lids and swapping them using alpha transparency. The issue with this is that setting location and rotation of a prim in SL can be a headache inducing exercise. SL uses quaternions to specify rotations. Although there are a number of transformation functions to switch to more commonly known units.

Preparation

The first step is to reshape the treasure chest to the desired size. In my example the body of the chest is a box of 1.024 m width x 0.512 m depth and x 0.368 m height. The lid of the box is a linked cylinder of the same dimensions, but cut so that only half a cylinder is present.

The next step is to find the local position of the lid prim in both the open and closed positions. Rather than have the treasure chest learn the position, similar to how the Timeless Linked Door works, I am hardcoding the positions (which means it will be sensitive to resizing of the whole object).

I use the following script to get the rotation and position of the lid. Note the rotation is returned as a vector in Euler co-ordinates and in radians.

// This reads back the Local Pos and Rot when touched
default {
    touch_start(integer total_number) {
        llOwnerSay("Rot = "+(string)llRot2Euler(llGetLocalRot()));
        llOwnerSay("Pos = "+(string)llGetLocalPos());
    }
}

Since I am hardcoding these, I could actually use a raw Rotation and therefore not need to convert the units. I have left this extra conversion in so that I can tweak the values at a later stage (tweaking in Euler is much easier than tweaking in Quaternion).

Local vs Global

The prim position and rotation setting commands have differing behaviors depending on how they are used. In this case, I am going to put the script in the lid and move it when touched, therefore I need to set the local position and rotation. To do this I need to make sure the lid is a child prim and not the root prim. If you move and rotate the root prim, it will move and rotate the whole object (global).

llSetRot() essentially works in the global co-ordinates (and it’s an offset for a child prim), so in this case I use llSetLocalRot() as that is always a rotation with respect to the root prim. llSetPos() always works as an offset of the roots prims position for a child prim, therefore it is ok.

However, if you use these two commands to move the lid, the movement is jerky. This is because both functions cause the script to sleep 0.2 seconds. A technique to get around this is to use llSetPrimitiveParams() and set both the rotation and position at the same time. For llSetPrimitiveParams(), the rotation command is the same as llSetRot(). Therefore we have to deal with converting this to a local rotation. I sought the LSL Potal for some wisdom, and this advice could be found:

“If you are trying to set the rotation of a child prim relative to the root prim then divide the local rotation by the root rotation.”

Final Script

The final script goes into the lid of the treasure chest and looks a little like this:

// Treasure Chest Script
// On Touch, this swaps from open to closed and visa versa
// Constants for Treasure Lid Position
vector rotClosed = <-1.57083, -0.00000, -0.00000>;
vector posClosed = < 0.00000,  0.00000,  0.18400>;
vector rotOpen =   <-1.57000,  0.00000,  1.57000>;
vector posOpen =   < 0.23610,  0.00000,  0.43744>;
// Global variables
integer chestOpen = FALSE;

// Lid movement function
moveChestLid (rotation rot, vector pos) {
    rot /= llGetRootRotation();
    llSetPrimitiveParams([PRIM_ROTATION, rot, PRIM_POSITION, pos]);
}

default {
    on_rez(integer start_param) { llResetScript(); }
    touch_start(integer total_number) {
        // Swap between positions
        if (chestOpen == TRUE) { // set closed
            chestOpen = FALSE;
            moveChestLid(llEuler2Rot(rotClosed),posClosed);
        } else { // set open
            chestOpen = TRUE;
            moveChestLid(llEuler2Rot(rotOpen),posOpen);
        }
    }//end touch_start
}

Finishing Touches

There are a number of final touches that can be added to the final treasure chest fairly easily:

• trigger a particle effect when the box opens (and shut it off when the box closes)
• automatically close the box after a certain length of time
• give one (or more) inventory item(s) when the box is opened (although remember that you can only detect the avatar that touched the chest in the touch_start event)

The reasons you might create a HUD is if you want to make some aspect of your project controllable by your customer but don’t want to have to add lots of button prims on the product or have your customer edit notecards.

This tutorial covers some basic concepts in putting together a basic hud, the basic type that simply sends commands for processing in a separate in-world device, but doesn’t show a complete example (I’ll add that if it’s requested, should anyone read this).

More complex devices that might incorporate 2-way communication are beyond this simple tutorial.

Which HUD Position?

There are eight possible positions that you can attach a HUD to. These are show in the following picture:

Where T: Top, L: Left, R: Right, B: Bottom, C: Centre

The primitives that were used in the picture have the dimensions X=0.5, Y=0.1 and Z=0.1. By default it is the Y,Z face that faces the user on HUD attachments and not the X,Y.

A few things can be noted:

• the Centre and Centre2 positions are the same (meaning you can have two items defaulting to the centre of the screen).
• the other positions correspond to the edge of the screen in each case, and the centre point of the prim is placed on the attachment position. This means that if you attach a prim for a HUD to the Top Left attachment point, ¾ of the prim will not be visible to the user.

Choosing the right position is important. If the hud takes up a lot of screen real-estate and is only worn occasionally, then the centre positions may be ok. If it is something that is going to be worn all of the time, then it may be better to design for one of the bottom positions or the left side. As a note: the right side gets the statistics bar when enabled, and that can’t be moved elsewhere on the screen.

By editing the object you can move the object to a different position with respect to the attachment point and the prim will remember that position if you detach and reattach it and anyone you give the HUD to will also get that remembered setting.

SL sometimes forgets the remembered position, so check it is stored correctly!

How To Communicate?

When discussing two separate objects communicating with one another within SL, generally this is realised via various forms of chat:

• llSay() - This is the basic method used by most, this technique contributes to lag of the sim. This also has a 20m max range between the two objects.
• llShout() - This technique has a 80m working radius instead, but has a greater contribution to lag
• llRegionSay() - This technique allows communication within anywhere in the same sim. However, if the objects are either side of a sim boundary, even if this is less than 5 meters, they will not be able to communicate.

There are other ways also! You could use Email between objects, however this method requires that your object has fixed UUID’s (or that you can detect it). You could also use HTTP requests, with an out-world server storing the information to be communicated. However, both of these methods are slower than a basic Listen handler (normally).

I have intentionally left out llWhisper() because in a moderately lagged sim, this seems to reliably fail! This is the one problem with one-way communication, there is no guarantee that the message will be received and no way for you to know if it was received or not.

If your HUD is talking to another attachment worn by the user, llSay() would probably be the best technique. If it is for an attachment with a fixed position, then llRegionSay() might be a better idea.

Making the HUD

The HUD itself is fairly straightforward, the general design is to have one root prim and a number of linked buttons. The button send tells the root prim that it has been pressed and the root prim in turn sends this information to the object to be communicated with.

The script used in the buttons is as follows:

default {

    on_touch() {

    llMessageLinked(LINK_ROOT,0,llGetObjectName()+"|"+llGetObjectDesc(), "");}

}

This sends the contents of the prim name and description fields to the root node. Note the seperator “|”. This is used such that the commands can be decoded by the receiver, any separation character will do as long as it is not used in the object name.

The root node then has this script:

integer channel = -188800;

default  {

    state_entry() {

        llPreloadSound("6005e358-33fd-d08b-012f-6110ab27a413"); }

    link_message(integer sender_num, integer num, string str, key id) {

// Play UI click and say message to other object

        llPlaySound("6005e358-33fd-d08b-012f-6110ab27a413", 1.0);

        llSay(channel,str); }

}

The root node simple sends the information straight to the other object via llSay and plays a “click” sound. The click sound is used to give the user feedback that they did press a button.

The channel selection is fairly important. Low channel numbers tend to be more congested, channel 0 (normal chat) should never be used. Positive channels can be used directly by the avatar (ie, by typing /55 do something) but negative channels can not.

This is not the only, or even the best way to do this! A better way (in terms of less scripts and therefore less lag) is to use llDetectedLinkNumber() to detect which button was touched from the root object. The downside to this approach is that there is only a llGetLinkName() function, so the information to be passed to the other object has to be all in the prim name.

Target Object Processing

In the target object you need to set up a listen for the command from the hud, this is done by declaring an open listen on the channel to be used: llListen(channel, "", "", ""). Note, this is an open listen so all messages on that channel will be picked up regardless of source.

To prevent listening to other avatars and HUD’s owned by other avatars, the following code is used:

listen(integer channel, string name, key id, string message) {

    if ((id == llGetOwner())||(llGetOwnerKey(id) == llGetOwner())) {

    // process commands

The first part of this checks if the owner sent the message, the second part checks if an object owned by the owner sent the message.

The processing of the commands depends on what exactly the hud is going to do. If you have used a separation character to pass both a command and a parameter, the following code usefully extracts the command and parameter (and discards the separation character).

message = llToLower (message);

// get the position of the seperation character

integer sepCharPos = llSubStringIndex(message,"|");

//extract

string command = llGetSubString(message, 0, (sepCharPos-1));

string parameter = llDeleteSubString(message, 0, (sepCharPos));

This could of course be extended to include any number of separation characters and parameters. Listening to the owner is not without risk, LSL does not have rigorous type checking or error detection functions. There is no isInteger() function! If you intend to type cast the received parameter to a different type from string there is a risk that you may get errors due to the input being malformed.

Alternatives

There are a few alternative techniques that can be used in place of a HUD:

• Use a Menu - LSL provides for a menu system that pops a blue menu up in the top right corner which the user can click. Since the reply from the menu system is spoken back to the user, this still needs a Listener and thus contributes to lag. The menu system can only show a limited number of characters per button.

• Use a Configuration file - It is also possible to read a notecard in the objects inventory, the user can just edit this to change settings. This doesn’t use a Listener and therefore is less laggy. However, it does affect the time taken to change settings.

But sometimes it is better to buy in the components than to make them. There are any number of excellent texturers, scripters and animators around SL, and many of them sell components at fairly reasonable rates.

Looking for reasonable rates is important. If you are looking to make and sell a Sword for say, L$50, you do not want to be buying in a component that will cost L$5000 unless you know that it can be used in many other items or you can be sure you will sell 100 of them. In the same way, a L$1000 piece of Jewelery needs something better than a plain texture.

I have compiled a short list of places to buy components that offer good value for money and are of a high quality.

In most of these I have given the creators name, this is because, although sims don’t generally disappear overnight, creators do move store locations around.

Laura’s Tiling Textures (Laura Fox)

This is one of the first places I discovered for textures in SL (after raiding all the freebie textures from NCI). There are a wide range of textures available here including jewels, fabrics, food and themed sets. New textures are added regularly. I personally use the Jewelery textures and a number of the food textures.

The textures are usually between L$150 and L$500, and come with Copy/Mod/Trans permissions. Often the pack also includes sample pieces demonstrating how to apply them to an object.

Daryth Kennedy’s Building Kits (Daryth Kennedy)

Seeing as I am involved with Daryth Kennedy’s Isle of Wyrms, it should be no surprise that I have a set of Daryth’s building kits. There are six different types; Greek Pottery, Stone columns, Treasure Set, Jewels (good, but not as good as the Laura Fox ones), Mushrooms and Flowers.

Each kit is priced at L$100, and is set to Copy/Mod/Trans permissions. My only criticism would be that some of the items use more prims then I would like, but as a general set of building components these are useful to have.

Sadly these can no longer be found in-world and have to be brought through SLX.

Phun Stuph (Mr Greggan)

This shop was something recently shown to me whilst I was working on a project to make a bed suitable for a Steam Wyrmling.

Phun Stuph sells steampunk components, dials & gauges (some animated), gears, wheels, boilers, and all sort of weird looking steampunkery! If building steampunk is your style - then this is the place to shop.

The prices of the items I looked at ranged between L$35 and L$200 and where all set with Copy/Mod/Trans permissions. Phun Stuph also offers a free group-only sandbox for putting your creations together.

Pixel Lab (Cel Edman)

Pixel Lab produces a range of different sculpted shapes, including a fairly neat cave pack and stairs. The sculptie textures are of a reasonable resolution, which means that on a loaded sim they do take some time to load (giving that ugly sculptie default-sphere shape for a few seconds). However, this also means they have nice detailing.

The packs contain 30-60 sculptie shapes and range from L$300 to L$600 and all set with Copy/Mod/Trans permissions. Again, Pixel Lab provides details on how you use their shapes.

Rez-Faux (Lex Niva)

Rez-Faux isn’t necessarily something you would consider in the same sense as textures and objects for integrating into builds. However, it is a very useful tool to have around.

Rez-Faux basically allows you to Rez, De-Rez and position multiple unlinked components that are part of a build. Second Life places limits on how close together parts must be in order to link them. Also, setting one prim in a linked set phantom, sets all prims in the linkset phantom (which can be a pain if you are building a house and only want to phantom the doors). Rez-Faux is an essential tool for making larger and more complex builds

Rez-Faux was L$625 and the transfer package is Copy/No-Mod/Transfer permissions.

Interested in making a tiny, you try to duplicate what you have seen, but no matter what you try, it isn’t possible to create an avatar smaller than ~5ft yet these tinies are smaller.

The first tinies are acknowledged to have been created by Kage Seraph. The technique he introduced was to use a script to override the currently active default animation(s), and activate another in its place (often called an animation-overrider or ao). The animation itself folds the human avatar up into a smaller package to achieve the required “tiny” height.

This tutorial covers how to create a simple tiny standing animation using QAvimator.

Getting Started

The first stage is to open the QAvimator program. The screen shots I have used are the Windows version of QAvimator, but the other platforms behave in much the same way.

Before starting to create your pose, un-tick the “Joint Limits” under the Options menu. This allows you to twist the body beyond normal human limits. Normally QAvimator will constrain limb movement to “sensible” human limits. In this case we are going to fold the human avatar so we need to exceed normal limits.

Also drop the number of frames in the animation to 2. The first frame is protected and therefore you can not edit it (and it’s required by SL). For a simple static pose you only need two frames. This isn’t absolutely required, but I like to do this to be tidy.

Legs

The first mod to the human avatar is to fold the legs in on themselves. You do this by selecting the Left Shin (lShin) by either clicking on it or choosing it from the drop down menu and set the X rotation to 180 degrees. Then select the Left Foot (lFoot) and set this in to the leg by setting the X Rotation to -90 degrees.

Repeat this process for the Right Shin and Right Foot.

Arms

Again the arms need to be folded, the process to do this is much the same as for the legs, this time take the Left Fore Arm (lForeArm) and twist the Y Rotation to -180 degrees. Repeat for the Right Fore Arm. You can leave the hands as they are as we will deal with those later.

Torso

The changes up to now have given you a basic human torso with folded legs and arms. The final stage is to fold the torso as well. To do this take the abdomen and set the X Rotation to 180 degrees, then take the chest and set the X Rotation to -180 degrees.

Upload Animation

Now save your completed file as a “.bvh” file for upload into SL. You may also wish to choose the “Optimise BVH” option from the Edit menu.

To upload the completed animation into Second Life, choose Upload Animation from the File menu, make sure you select the Loop tick box and the priority to 4.  In Second Life, the minimum priority is 1, the maximum is 4. By setting the priority to 4 you minimise the chance of your animation being interrupted by a standard Linden animation.

To try to tidy the hands into the body I tend to also set the hands to fist. Most “primmy” tiny bodies will hide them anyway. If you don’t choose Loop, the animation will play once and then exit back to a standard Linden pose (probably stand).

Now you have a completed animation suitable for a pose ball.

Hold On, That Doesn’t Look Right!

Yes! One of the idiosyncrasies with Second Life is that any X,Y, Z Rotation set to zero in the animation will be treated as a movable joint.  Therefore when you activate the animation in Second Life, rather than your avatar taking on the T-pose as seen in the program, the avatar instead stands with the arms by it’s side. If you actually want to set a T-pose then the Z Rotation must be non-zero.  To fix the position of any body part, you must set at least one Rotation as non-zero.

You may also notice that the avatar is floating in the air slightly.  This isn’t so important if a pose ball is being used, since the position can be altered with an offset.   To correct this, the Y Position of the hip part must be reduced.

Tiny Development Kit

Now this just gives you a tiny standing pose with the arms set as a ‘T’.  You can repeat the process to make any number of different animations that would be suitable for a pose ball.  However, this is not the full story!

If you where aiming to make a tiny avatar, you would also need other tiny animations to use when the avatar is performing certain actions, such as sit, stand, animations for walk, run and fly.  You would also need a script to override the default Linden animations and trigger the special animations instead.  Lastly you would need a tiny shape.  The animations will work on the current size of the avatar, therefore if the avatar is 7ft, you will get a folded 7ft.

If this sounds like too much work, Kage Seraph sells a Tiny Development Kit that comes with full-permissions versions of various tiny animations, scripts and a shape that would allow any tiny animation maker  to get started with the minimum of fuss.

The requirements, an avatar can sit on the wheel and when they do so, they would start rolling and so would the wheel. Since the Hedgehog avatar made by Daryth Kennedy comes with a rolling animation (which was copy perms) and in theory it was only a case of bolting the wheel animation onto a standard pose ball script, it didn’t sound all that complicated…

Making the Wheel

The first step was to make the wheel that the hedgehog would roll inside and the scripts to provide the “rotating” effect. The wheel was a simple hollowed cylinder, with a second thin cylinder to provide the hub and spokes.

There were two techniques that I could use; animate the texture of the wheel using llSetTextureAnim or to rotate the whole prim using llTargetOmega.

Initially I choose to use llSetTextureAnim as this is the more conventional approach. This function offers both rotate, scale and frame by frame animation modes. To control the “rotation” animation for the test wheel I used a simple two state approach with the on_touch event being used to switch between “On” and “Off” states.

For the prim that contained the wheel hub and spokes, this worked very well and smoothly rotated the inner texture around the pivot point. The only issue was that two separate commands had to be used to rotate the front and back of the prim - this would mean in lag the textures would probably not be synched.

However, for the “roll” surface this worked less well. The issue with the llSetTextureAnim function is that it sets the texture to 1:1 scaling during animation irrespective of the actual texture scale setting applied to the prim. To achieve the desired effect I had applied 6x horizontal scaling and the animation function was setting this back to 1x - Ugh! One workaround would be to change the texture to incorporate the 6x horizontal scaling, but in order to maintain a sensible resolution the texture would become large (1568 x 256 in this case) and thus add to lag.

llTargetOmega

So, the alternative is to use the llTargetOmega fuction. This rotates the prim the script is contained in (unless that prim is the root-prim where it will rotate the whole object). Since the object I was making was non-physical, this processing would be done in the client and thus very low lag.

However, my “Off” state did not work correctly! The prim refused to stop turning. A quick search found that there was a bug in the function that llTargetOmega doesn’t update unless the object is interacted with by an AV! It wasn’t possible to stop the object turning using the script.

My workaround? Well since the spin rate is a float value, I set it to something very small, I used 0.0001 in this case. Since a value of 1 is a rotation of 1 radian per second, a value of 0.0001 is one rotation every 62,831 seconds or ~17 hours. Being a 32-bit float I could go smaller, but this was adequate to ensure movement was not instantly apparent!

Pose Ball

The next task is to make the “pose-ball” that would trigger the animation and send the commands to the wheel. I used a standard pose-ball script and added Daryth’s Hedgehog Roll animation. To make the pose-ball work with the wheel, I just linked it to the wheel (making the pose-ball the root prim) using llMessageLinked to communicate with the wheel in the show() and hide() methods. After replacing the on_touch events with link_message events, the wheel was good to go, so did it work?

Animation Override

Well yes and no. The wheel would have worked, but tiny avatars such as the hedgehog incorporate an animation-override - this is to keep the avatar looking correct regardless of what the avatar is currently doing, walking, running, swimming, etc. The default animations are meant for human avatars and are not for specialised avatars where the human frame has often been contorted.

Fortunately the script library also contained a handy AO Overriding Pose Ball Script! This relies on the fact that when the avatar sits on the object, the animation override will stop the default sit and then set its sit animation. To get the correct rolling animation, this script stops the default sit, the ao sit and then sets the desired pose. This relies on the fact most animation override devices do not periodically reset the pose.

To finish off I added a particle smoke effect for while the wheel was rolling.  So we now have a working Hedgehog Wheel - Weeee!