Rider Linden

Yes. Pizzas and orbiting space stations are also possibilities. Other features include a texture on the sun disk and custom cloud textures... among other improvements.

Just because I've been feeling like a brat for the past day and teasing EEP images, here's one more. (This is the sun/moon editing)

The moon doesn't need to keep its round shape.

Under NO circumstances should you EVER look directly at the SL Sun without proper eye protection, it can be damaging to your sanity. (also, contrary to competing theories advanced here. SL Stars are actually holes caused by feral meeroos that have escaped their pens and chewed their way through the sky dome into the Void Between.)

Day Cycle Environment settings are divided into track. The first track (#0) is used for water. Tracks #1 - #4 are used for skies. Qie's numbers are correct although if I were being pedantic I would put it the following way: Anything above ground level. Anything at or above 1000m Anything at or above 2000m Anything at or above 3000m There always must be a ground level track (#1). Other tracks are optional. If a track is missing the environment defined by the track below it is in effect. So, if a day cycle defines tracks #1, #2 and #4. Below 1000m would use track #1. Track #2 would be in effect from 1000m to 3000m and then Track #4 would apply from 3000m upward.

It has been a long process but I'm nearing a point that I'll be able to start rolling out an initial project viewer very soon now. The most complex part has turned out to be the addition of settings objects to inventory, I think this is the first new inventory type that we've added since mesh so the change has taken quite a bit of archaeology, and more than a little prayer, to make. The first project viewer will most likely not have the scripting functions since I want to get settings into creator's hands as quickly as possible. They will follow soon after though.

EEP is the Environmental Enhancement Project. It allows you to store sky, water and day settings in your inventory. It revamps much of the old windlight code and adds a few new functions for interacting with the environment. Inara Pey is a much better writer than I am and did an excellent write up for the project.

I think that I see the what the issue may be. The problem is not your timer. From your testing you can see that it is happily ticking away. The problem is llGetSunDirection(). The current implementation of this function returns a vector to the current position of the region's sun. The keyword here is "region". The region's sun is not affected by whatever Windlight settings are applied to the region. (Think of it as pointing to an invisible sun... that gives its heat to everyone... ) When EEP rolls to the grid, this will no longer be the case. llGetSunDirection is being changed to accurately give you a vector pointed to the sun as calculated by the environment settings. There will additionally be a function added called llGetMoonDirection that will provide a vector pointing to the moon since it will be able to be moved independently.

Your observations are correct. llName2Key does a fast check against the agent name cache on the simhost. If the agent's name is not found the function returns NULL immediately. llRequestUserKey does a (potentially) longer lookup for the agent's name and may hit the user database in the process. When llRequestUserKey gets a response the name and UUID are added to the name cache for the region, so a subsequent llName2Key will in fact find a valid response to return. You should make no assumptions about the length of time a user's record will remain cached other than it will be kept as long as the agent is physically in the region, and for a short time after they have left. It will also be cached briefly following a call to llRequestUserKey. Note: Because of this behavior, llName2Key is not a reliable way to determine if a user is actually present in the region.

Create an LSL HTTP server using a scripted object in world. That object will be assigned a URL that you can hit from your PHP script. I believe that the URL will be persistent until the script (or the region?) is restarted. You can find some examples here.

Soon. I'm typing as fast as I can.

The new code is running on the regions now. Thank you for your patience.

I'm still updating the region. (give me 5 more minutes.)

Hi there, I'd like to take a moment to announce two new script function that we here at the lab are just putting into testing on the Beta Grid(Aditi) and that will roll out to the main grid in the coming weeks. llName2Key and llRequestUserKey. These functions will provide the UUID of a named avatar. llName2Key only works for agents that are either in the region that the script is running on, llRequestUserKey will work for any agent on the grid. Documentation on these functions is on the Second Life wiki. Here: llName2Key and here: llRequestUserKey. They are available for testing on the beta grid (Aditi) in the following regions: Sylveon, Umbreon, Leafeon and Mystic Lane Sample Usage integer chat_handle = 0; list events; integer STRIDE = 2; default { state_entry() { llSetTextureAnim(ANIM_ON|LOOP, ALL_SIDES, 5, 5, 0, 23, 20.0); chat_handle = llListen(1, "", llGetOwner(), ""); } listen( integer channel, string name, key id, string message) { llSay(0, "Checking for \"" + message + "\""); llSay(0, "llName2Key = " + (string)llName2Key(message)); if (llGetOwner() != id) { llSay(0, "No dataserver lookup for you!"); return; } events += [ llRequestUserKey(message), message ]; } dataserver(key request_id, string data) { integer index = llListFindList(events, [ request_id] ); if (~index ) { string name = llList2String(events, index + 1); llSay(0, "Dataserver \"" + name + "\" = " + data ); events = llDeleteSubList(events, index, index + STRIDE - 1); } } } A quick afterward for people who were at the user group meetings: Please note the name change.

Not to far off from the truth! Since you'll be able to change the moon texture in the environments I will be on the lookout for this somewhere:

Jopsy, Short answer: Yes, EEP will be available on mainland parcels. Long answer: Land owners will have the option to disallow parcel based environment settings if they desire. However, I do not believe that Governor Linden will restrict mainland regions in this way.

Since angle of altitude/azimuth ("time of day"/"angle from east") came up I feel like I should give you a preview on the interface. I'm changing the way these values are set. I have never been a fan of having two controls that influence a single value. The goal is to position either the sun or the moon somewhere on the celestial sphere. An intuitive way to perform this action would a "track ball" with a marker for the sun or moon's position in the sky. Spin the ball and the heavenly body's location above changes. My hope is this will be easier to use than trying to figure out how many degrees you want to rotate the sun around the sky (and trying to figure out on what axis the rotations will occur.)

EEP is not out yet, but I am typing as quickly as I can. I am nailing down a few last minute changes in the settings asset format. I want to avoid making changes after people begin creating settings in their inventories since that would result in broken skies, settings that do nothing but throw errors, and angry mobs at my window with torches and pitchforks. As far as I know there have been no changes to the rendering on the release viewer that would change how the windlight settings are displayed. All windlight rendering is done viewer side (the simulator simply tracks the values and sends them down to the viewers.) This will not change once EEP is in your hands, the viewer will still be responsible for rendering. (I do think the "black sea" look in the second picture is quite dramatic, by the way.)

The wiki has been update with further details about HTTP_ACCEPT in llHTTPRequest.

You will want to fix this line. "text/application/xml" is not a valid mime type and in a roll coming very soon we will be validating this value for formatting. A valid value will be in the form "type/subtype[;charset=utf-8". The examples on the wiki were incorrect but have been updated.

A heads up. Do not use: In both of those cases llHTTPRequest will throw errors to the debug console and reject the HTTP request. The culprit being the "\n"s in the URL.. Instead construct your URL request as follows: Please see llHTTPRequest Documentation. For a discussion of the issue see this thread: https://community.secondlife.com/forums/topic/406941-dj-board-display-not-working-properly/