Rider Linden

Animats, if you can open a feature request JIRA for following redirects on methods other than GET or HEAD so that it stays on our radar and we can take a bit of time to weigh the implications.

Be sure that you are not trying to follow an excessively long chain of redirects. LSL HTTP does automatically follow redirects, but the number of redirections is limited.

I have not personally used this method of doing what you are describing but it might be worth giving it a try. Consider treating your texture atlas as an animation and use llSetTextureAnim to display the cell/frame you want. You could rewrite your ShowNumber() function as follows: Note, that this turns the animation on for the indicated face, divides the texture into an 8x8 grid. It then starts a single frame non-looping animation and should display your number. Your mileage may vary.

Changing parameters on an already published API is not really a possibility. It would absolutely be a breaking change.

I'm not going to go into details about what changed beyond saying that some events (notably chat listens) were being collected and distributed once every script execution for every script. They are now queued immediately to the subscribed script(s) removing some work from the scheduler. The window between the object_rez event and on_rez() has become more variable and the delivery of chat messages to a channel has become faster. So, scripters that already use a handshake as recommended in the blog post will not notice any difference and their scripts will continue to work. However if the rezzers are relying on a timeout to determine when their rezzed object is ready, those scripts may break. on_rez() in multiple scripts should all occur within a server frame or two of each other (depending on the script load of the server), however the order in which they occur remains arbitrary.

Only on selected regions. What regions and sever version did you encounter the issues on?

Little Things Little drops of water, Little grains of sand, Make the mighty ocean And the pleasant land. Thus the little minutes, Humble though they be, Make the mighty ages Of eternity. -- Julia Abigail Fletcher Carney

If the script's sole purpose was to start an animation on a prim there is benefit to deleting the script once it has done that. Even scripts that contain no events currently consume some resources on the server and must be checked every frame to ensure that they do not have any events pending.

The download for the current EEP viewer is https://releasenotes.secondlife.com/viewer/6.4.0.530150.html You can check which viewer you are running by opening Help>About. For EEP the first line should read: "Second Life Release 6.4.0.530150" Windlight XML files are still included with the EEP viewer but it does not use them. You can find all of the old Linden Lab Windlight files (and many of the Firestorm Windlights) in your inventory under Library>Environments. You can use these directly on your land or copy them into "My Inventory" and edit them to create your own environments.

@skylarmalone. That appears to be a non EEP viewer. That floater was removed in the the EEP viewer. For the legacy Windlight viewers the windlight XML files are located in the Second Life install directory under: ./SecondLifeRelease/app_settings/windlight

At some point in the future (EEP2) we will be implementing density profiles which will give better control over things like haze, distance fog, god rays and ambient colors. This isn't until some unspecified future though so you should be fine with using SETTING_LEGACY_HAZE for the time being. Again, just be aware that they are considered legacy at this point and may be missing from future versions of the a settings asset. (At which time you'll have to infer what the values of distance_haze, distance_multiplier and ambient_color should be.)

The viewer's corresponding conversion code has been there for some time (It was put in place so that an EEP viewer could still update the environment on a Windlight simulator, and has never been removed, even after the whole grid switched.) You can find it in llsettingsvo.cpp. (found at the link). Search the file for methods named convertToLegacy( ), there should be three of them. The viewer conversions do not have the issue that impacted the simulator. Be warned. The legacy Windlight format does not include a number features such as customization for clouds and heavenly bodies, independent moon position, and several others. These improvements are stripped in the conversion.

As I mentioned above. This is a simulator, not a viewer, issue so there is no code to publish. All simulators on the grid at this point maintain EEP settings internally and do a translation to the legacy windlight when a viewer requests the environment through the old cap. It was this translation that was applying the improper scaling on our end. Conversely, if a viewer changes the environment using the legacy caps and sends Windlight to a simulator, we do the translation on our end into an EEP setting.

There was an issue on the servers that was scaling down the fog values when translating from the simulator EEP settings into legacy Windlight. (Scaling them down so that they were practically 0.) We have a fix for this and are rolling it out to an RC today as in simulator version 2019-09-24T17:23:00.531200.

DON'T DO THAT! You'll make me cry. 😭 But you are correct, scripts can cause effects that will be reflected in the viewer and potentially degrade performance... I will hazard a guess that virtual crops are not committing this particular sin however.

Scripting is handled entirely on the simulator. It would not impact your GPU in any way.

"Milotic"

Don't blink!

Have you filed bugs in JIRA for your master list?

In seriousness... the minimum distance between two frames in a day cycle is 2.5%. This works out to 6 minutes for a 4 hour day cycle. You could move the moon to near the zenith with a small scale factor and have it move to somewhere near the nadir with a large scale factor. This would give the appearance of a large rock(s) hurtling to the earth (it would cross the horizon at roughly the 3 minute mark.) If you had the sun and moon alternating positions (making the heavenly body unnoticeable when it reset to the zenith) you would certainly be able to simulate your own personal Perseids Meteor Shower.

Ok... but you're on your own for craters and an impact blast 😉

Giant asteroids are out of scope for the EEP project. I'll add Dinosaurs to the EEP two list.

I have corrected this oversight on the wiki.

In all cases, the Linden Lab EEP viewer allows the agent to override any simulator applied environment setting. This includes environments applied to the region, the parcel, and through scripts functions such as llSetAgentEnvironment and llReplaceAgentEnvironment. The simulator is unaware of any such override and can not track it through llGetEnvironment. This function works only to report on the state of the parcel or region settings.

Does this mean I'll need to a new LSL call? llAdministerDramamine( key agent_id ); This will, of course, require experience permissions.