Rider Linden

The ability to run scripts is controlled on the simulator(region). Your only options are: Everyone can run scripts Only group members can run scripts Nobody can run scripts There is no option to say: "Bob can not run scripts." As an aside, since you did not specify what problem you are trying to solve, if "Bob" is causing problems you can always ban him from entering the parcel or region.

A word of caution, be careful about selling EEP settings right now in the marketplace since they are only visible to people using an EEP viewer and will only work on EEP enabled regions.

Thanks for the JIRA. That will make sure it stays on my radar. I think it is possible, but give me some time to consider how we'd do it.

I'm happy to announce that the first EEP related LSL functions are in the latest roll of the EEP servers. The documentation will be up on the wiki very soon. llGetEnvironment Retrieves the current environmental settings for a region or parcel in the specified layer. Function list llGetEnvironment(vector pos, list params) These functions return the current environment values for the parcel and the region as a list of attributes. They take a list of attributes to retrieve in params and returns them in the order requested. pos: A position in region coordinates. X and Y are in region coordinates and determine the parcel. If X and Y are both -1 the environment for the entire region is inspected. Z is the altitude in the region and determines which sky track is accessed. params: A list of parameters to retrieve from the current environment. See table below for details. If an unknown rule is encountered in the parameter list an error is emitted to the debug channel. Caveats If the script can not run in the requested parcel this function returns an empty list and issues a warning in the debug channel. Parameters parameter return values description SKY_TRACKS 15 float sky2, float sky3, float sky4 Altitudes for sky transitions in the region. SKY_AMBIENT 0 vector ambient_color The ambient color of the environment SKY_TEXTURE_DEFAULTS 1 Integer bloom_is_default, integer halo_is_default, integer rainbow_is_default Checks if the textures are currently set to use the default. For default values the returned integer is 1, if the texture uses something other than the default this value is 0. SKY_CLOUDS 2 vector color, float coverage, float scale, float variance, vector scroll, vector density, vector detail, integer is_default Environmental cloud information. color: The color used for the clouds. coverage: The coverage percentage. scale: The scaling applied to the cloud textures. variance: A randomizing factor applied to the main cloud layer scroll: The scroll speed of the clouds. X is east/west Y is north/south Z is unused density: The X/Y and D parameter used to generate cloud density detail: The X/Y and D parameter used to generate cloud details. is_default: 1 if the clouds are using the default texture. SKY_DOME 4 float offset, float radius, float max_altitude Sky dome information. offset radius maximum altitude SKY_GAMMA 5 float gamma The gamma value applied to the scene. SKY_GLOW 6 vector glow_color Glow color applied to the sun and moon. SKY_MOON 9 rotation rot, float scale, float brightness, integer is_default_texture, vector direction, vector ambient_color, vector diffuse_color Detailed moon information rot: The current rotation applied to the moon. scale: The current scale applied to the moon's texture brightness: The moon's brightness is_default_texture: 1 if the moon texture is set to the default. 0 otherwise direction: A unit vector pointing at the moon. ambient_color: The ambient color of the moon diffuse_color: The diffuse color applied to the moon. SKY_STAR_BRIGHTNESS 13 float brightness SKY_SUN 14 rotation rot, float scale, vector sun_color, integer is_default_texture, vector direction, vector ambient_color, vector diffuse_color Detailed sun information rot: The current rotation applied to the sun. scale: The current scale applied to the sun's texture sun_color: is_default_texture: 1 if the moon texture is set to the default. 0 otherwise direction: A unit vector pointing at the moon. ambient_color: The ambient color of the moon diffuse_color: The diffuse color applied to the moon. SKY_PLANET 10 float planet_radius, float sky_bottom_radius, float sky_top_radius Planet information used in rendering the sky planet_radius sky_bottom_radius sky_top_radius SKY_DENSITY_PROFILE_COUNTS 3 integer rayleigh_count, integer mie_count, integer absorption_count Number of profiles currently active for atmospheric scattering. Currently all values will return 1. SKY_RAYLEIGH_CONFIG, integer profile_num 18 float width, float exponential, float exponential_scale, float linear, float constant Rayleigh scatting profile parameters. profile_noshould be passed along with this parameter to request a specific profile index. Currently only one profile is supported. width exponential exponential_scale linear constant SKY_MIE_CONFIG, integer profile_num 17 float width, float exponential, float exponential_scale, float linear, float constant, float anisotropy MIE scatting profile parameters. profile_noshould be passed along with this parameter to request a specific profile index. Currently only one profile is supported. width exponential exponential_scale linear constant anisotropy SKY_ABSORPTION_CONFIG, integer profile_num 16 float width, float exponential, float exponential_scale, float linear, float constant Absorption profile parameters. profile_no should be passed along with this parameter to request a specific profile index. Currently only one profile is supported. width exponential exponential_scale linear constant SKY_REFRACTION 11 float moisture_level, float droplet_radius, float ice_level Sky refraction parameters for rainbows and optical effects. moisture_level droplet_radius ice_level SKY_LIGHT 8 vector light_direction, vector fade_color, vector total_ambient Miscellaneous lighting values light_direction: unit vector indicating the direction of the dominant light source. WATER_BLUR_MULTIPLIER 100 float multiplier Multiplier applied to blur the scene when under water. WATER_FOG 101 vector color, float density, fload modulation Fog parameters applied when underwater color: The color of the underwater fog density: Density exponent applied to the fog modulation: WATER_FRESNEL 102 float offset, float scale Fresnel scattering applied to the surface of the water. offset scale WATER_TEXTURE_DEFAULTS 103 integer normal_is_default, integer transparent_is_default Checks if the textures are currently set to use the default. For default values the returned integer is 1, if the texture uses something other than the default this value is 0. WATER_NORMAL_SCALE 104 vector scale Scaling applied to the water normal map. WATER_REFRACTION 105 float scale_above, float scale_below Refraction factors when looking through the surface of the water. scale_above scale_below WATER_WAVE_DIRECTION 106 vector large_wave, vector small_wave Vector for the directions of the waves Y represents north/south and X represents movement east/west. large_wave: Large wave speed and direction. small_wave: Small wave speed and direction.

We still have quite a bit of work to do on the various shaders... could you file a feature request one for the underwater lighting caustics please? I will watch for the JIRAs. (It is much more reliable than adding to the litter of post-it notes on my desk)

Yes. I have some ideas about how to make them a little easier to use. I believe we have something on the radar now... so keep an eye out.

I think that is actually a great idea. If you would please create a JIRA for this ( http://jira.secondlife.com/ ) we can see if we can get it into the schedule. (If it doesn't make phase 1, it is absolutely something that we should try and incorporate into future enhancements.)

Do you mean create an entire sky dome texture and apply that?

No. This isn't a setting that can be controlled through EEP.

In general the Environment will be determined by where the avatar is located (not the camera) Actually no. We only show the environment that will apply to the avatar where they are currently standing. (We don't show multiple at one time)

No, that is also part of EEP. Experiences will allow a script to set environments for individual avatars. I am working on that now.

No need to be sorry, I welcome the feedback, that's why we've put the EEP viewer out there for feedback. I'd like to keep the trackball in place for most movements. But maybe we can fix the issue with the addition of a pair of controls that can allow for a more precise positioning. (Azimuth and Altitude perhaps?)

You make some very good suggestions. Please take a few moments and open a few new feature JIRAs. We are still taking suggestions and that is the best way to ensure that yours do not get lost in the sea of post-it notes that litters my desk. You can access JIRA here. Try and keep it to one feature per JIRA and prefix the subject with "[EEP]" so that we can filter them correctly in our daily triage.

Hi there Oliviatoms, You should check out the Environmental Enhancement Project (EEP) which we have just released as a project viewer. This new system will allow you to set skies and day cycles on a per-parcel basis. It will also allow parcel owners to set different skies at different altitudes.

I'm sorry. But the ability to change a viewer's environment settings will be tied to an experience.

llGetSunDirection will return a unit vector pointing at the position of the parcel's sun as defined by the environment setting. (llGetRegionSunDirection does the same for the entire region) llGetSunRotation will return the same information in the form of a rotation ( llGetSunRotation() * UNIT_DUE_EAST should give the same result as llGetSunDirection() ) A historical note about llGetSunDirection: It used to return a vector to what was known as the "Estate sun". This position was maintained by the region and had no correlation with any windlight sun positioning. The estate sun would orbit once every four hours (a "Linden Day"), adjusting the plane of it's orbit slightly over the course of 11 Linden Days making a Linden Year.

llGetDayOffset and llGetRegionDayOffset return the number of seconds from GMT that the time is shifted when calculating the current "time of day" or progress through the day cycle. So for day cycles set to 24hours it will be roughly equivalent to a time zone. From memory, the calculation is as follows: daycycle_pos = ((GMTNow + DayOffset) % DayLength) / DayLength;

Parcel owners should have access to all EEP features (unless the estate managers have explicitly specified otherwise.) The only exception to this will be sky altitudes (equivalent to what Firestorm calls "zones"). These are only settable at the Region level.

Think of it as a bit of artistic licence.

Here's a snap shot of the next version of the Region/Estate environment tab. This will be available in the next PV. Sky layer altitudes are adjustable at the region level.

Keep your eyes open, we are continuing to fill out the features that will be available in EEP. Here are a couple teaser images for what we have in the works:

Scripts will be in prior to EEP going RC. There are a number of script functions already in EEP but the big ones are still under development. Right now these are what is available: For Parcels llGetSunDirection() llGetSunRotation() llGetMoonDirection() llGetMoonRotation() llGetDayLength() llGetDayOffset() For Regions llGetRegionSunDirection() llGetRegionSunRotation() llGetRegionMoonDirection() llGetRegionMoonRotation() llGetRegionDayLength() llGetRegionDayOffset()

There is an issue in the release viewer that prevented the purchase of land on the beta grid (Aditi.) The EEP viewer addresses this issue.

As people mentioned above. The rule of thumb for any of the user name functions is: If the function has an immediate return the script function is only checking the user cache on the simulator. (There are a number of ways a user can be added to the cache but the safest assumption is "the user is in the region, or has been in the region recently." A more indepth description can trigger mental breaks.) The llRequestXYZ functions will do a call into the database if the information is not currently cached. This is more expensive and can take more time to execute (hence the need for the dataserver event.) however you will get a more authoritative answer.