Windlight, no thanks

I downloaded the First Look viewer with Windlight. At first I loved the cloud effects and water, then I looked more closely.

All my subtle textures are now washed out with no detail, swirls of orange and yellow are replaced with featureless gray no matter which settings I use.

The old viewer faded the view with distance, but Windlight looks off to infinity in the presets they provided. The result is that you can see from side to side of a region and the edges of the sim.

I increasing the fog density and although the distance faded, so did everything close up. In the standard viewer there is a distance before things start fading.

The default settings are not good, much too bright. They drain the scene of detail.

Windlight is set-up for infinite scenes, but SL regions are only 256m across. There should be some form of distance limiting.

At the moment I don't like it much, it needs far more work for SL.

The fog fall off needs to be non-linear so that the area close to your viewpoint is not affected but distance is. This would keepo the foreground bright while hiding sim-edges.

The default settings need to be better and set for Secodn Life. We have all got used to and built under one lighting condition and changing the colour temperature and atmospheric effects spoils most of what we have done.

It has potential, but needs more work, otherwise it will show up shortcomings of SL in exchange for prettier skies and water.

Sit script

This is my Second Life sit-script and is the core for many functions starting with sitting on a seat, to teleports and pose-stands.

When an avatar sits they get linked to the object they are sitting on and your movement becomes linked to that object. This is why you move when flying a car, sailing a boat or riding a bicycle rather than being left behind.

The sit script works by:-

1. Wait for a changed event
2. Check if it was something being linked with the CHANGED_LINK mask
3. Check if it was an avatar being linked with llAvatarOnSitTarget
4. Check for the permission to trigger an animation. This triggers a run_time_permissions event
   
5. Stop the previous animation with llStopAnimation
6. Start my animation with llStartAnimation

When the avatar stands up:-

1. Wait for a changed event
2. Check if the avatar is being unlinked; llAvatarOnSitTarget will return a NULL_KEY
3. Unsit the sitter with llUnsit(sitter). The 'sitter' key will only be valid (not a NULL_KEY) if I already had permission to animate the avatar.

When objects are linked a change event is triggered, this includes when you sit on the object. The change event also triggers on other changes such as an object changing colour or size. I first check that this is a link event using the mask CHANGED_LINK, then check whether it was an avatar being linked with llAvatarOnSitTarget. This will return an avatar key if an avatar was linked. If I get an avatar key then I check for animate permissions. This triggers a run_time_permissions event and I check if I have permission to animate. If I have, then stop the old animation "sit" and start my animation "anim".

llAvatarOnSitTarget will only work if llSitTarget has been set for the object that you are sitting on. You can have several sit scripts running with one in each sit position and this is used where you have more than one seat in an object, such as a car or settee. The sit position that is triggered is the lowest link number that is not being sat upon.

If we attempt to animate an avatar without permission we will get a script error. It looks as if there are two places that llUnist will create an error as it is used where we may not have animate permission. The argument 'sitter' will be NULL_KEY if we do not have animate permission so this will not be a problem.

Setting the script up. You will need to change the sit position to match your animation. Change the first number to move the avatar backwards and forwards and the last one to adjust the height.

// Sit script
// by Asp Grelling 23APR07

vector sitPosition = <0.0, 0.0, 0.76> ; // Sit offset
vector sitRotation = <0,0,0> ; // Sit rotation

// ---- DO NOT MODIFY BELOW THIS LINE -----

key avatar ;
key sitter = NULL_KEY ;
string anim = "sit" ;

default
{
state_entry()
{
llSetSitText("Sit here");
rotation rot = llEuler2Rot(sitRotation);
llSitTarget(sitPosition, rot);
sitter = NULL_KEY ;
}

on_rez(integer param)
{
llResetScript();
}

changed(integer change)
{
if(change & CHANGED_LINK) {
avatar = llAvatarOnSitTarget();
if ( avatar ) {
// Request permision to sit
llRequestPermissions(avatar,PERMISSION_TRIGGER_ANIMATION);
} else {
if ( sitter ) {
llUnSit(sitter);
sitter = NULL_KEY ;
} else {
// We can get here for many reasons
// Do nothing
}
}
}
}

run_time_permissions(integer perm)
{
if(perm & PERMISSION_TRIGGER_ANIMATION)
{
// Sit action
sitter = avatar ;
llStopAnimation("sit");
llStartAnimation(anim);
} else {
// We do not have permissions, so unist
llUnSit(sitter);
sitter = NULL_KEY ;
}
}
}


Teleport script

Over the months I have had sever problems with teleports in Second Life.

How do teleports work in SL? They all use a hack; when you sit, the object you sit on has information about your sitting position including the offset from the object center and rotation. This is to allow for poses that may place you away from the default sit position or to rotate you to face a particular direction. The offset and rotation can be altered using the program call llSitTarget(). Someone noticed that the offset can be hundreds of meters away. All teleports work sitting you at an offset that places you at your destination and then unsits you.

If you use the example scripts, most will send you flying around put you off the sim for a while or leave you 'falling' in one position. This happens as you are often placed inside an object and then made to unsit. The physics engine sees you are inside an object and applies a force to get you out of it. The force can be quite violent and enough to send you flying around a room or leave you floating in space.

I found that pauisng before the unsit command gives the normal sit processes to work so that the program has time to place you correctly.

The second problem was caused my moving the teleport. Since the sit position is relative, every time you moved the teleport you have to recompile the script as moving changes the offset. I noticed there is an event that tells you when an object has moved. I added a small script that recalculates your sit position each time you move the teleport.

// Simple teleport script
// by Asp Grelling
// 08MAY07


vector targetPos = <128.0, 250.0, 251.566>; //The target location

reset()
{
vector target;
target = (targetPos- llGetPos()) * (ZERO_ROTATION / llGetRot()); // Calculate offset
llSitTarget(target, ZERO_ROTATION); // Set the offset and rotation
llSetSitText(llGetObjectName());
}

default
{
state_entry()
{
reset();
}

on_rez(integer startup_param)
{
reset();
}

changed(integer change)
{
llSleep(0.2); // Sleep to give the program time to seat you
llUnSit(llAvatarOnSitTarget()); // Unsit the avatar
reset();
}

moving_end()
{
// Detect that the object has been moved
reset();
}
}

Moved from http://designasp.blogspot.com



Blogger ate my scripts

After some investigation. To post program code in Blogger, use this first:-

http://www.accessify.com/tools-and-wizards/developer-tools/quick-escape/

Characters like < and > will be replaced with indigestible code that Blogger will sniff, but not eat.

The original problem was trying to post Linden Script Language (LSL) examples into my blog. They code showed fine in Editor and Compose mode, but was converted through Publishing so that important bits of code were omitted.

Now I am looking for something that will colour code the text, similar to the LSL Wiki.

Automatic light script

I was making a light for my stores and wanted the lights to fade on and off as the sun set and rose. The example scripts switch on and off, which looked ugly.

This script fades ON as the sun sets untill the lights are fully on as the sun dips below the horizon.

// Automatic lighting
// Light prim script
// by Asp Grelling
// 1MAY07

// The lights fade on and off according to the suns position above the horizon

vector lightColour = < 1.0, 1.0, 1.0> ;
float lightIntensity = 1.0 ;
float lightRadius = 8.0 ;
float lightFalloff = 0.75 ;


default
{
state_entry()
{
// Function entry
llSetTimerEvent(10); // Check every X seconds
}

timer()
{
integer lightOn ;
vector sun = llGetSunDirection();
float intensity = (0.25 - sun.z)*4;
if ( intensity < 0.0 ) {
lightON = FALSE ;
intensity = 0.0;
else {
lightON = TRUE ;
if ( intensity > 1.0 ) intensity = 1.0 ;
}
// Turn light on or off depending on intensity
llSetPrimitiveParams([PRIM_POINT_LIGHT, lightOn, lightColour , intensity, lightRadius, lightFalloff ]);
}
}

The call to llGetSunDirection() retrieves a vector pointing to the suns position in the sky, with x, y and z pointing to the sun. Z gives the angle above the horizon and a negative number indicates the sun is below the horizon. Another script I saw turned the lights on and off based on whether the sun was above the horizon (z > 0) or below the horizon (z <> float intensity = (0.25 - sun.z)*4;" changes the rate at which the light come on. A smaller number makes the light come on more slowly.

My actual script has a bit more with the fade happening a smothly and the light temperature changing so the light has a warmth as it comes on.

The lights will be on sale in my store and I will post some pictures when Dutch Business Park opens and my shops are accessible.

Note: Moved from http://designasp.blogspot.com