Scripting

ALERT: Le Tigre HTTPRequest Change

by

This change could be a problem. Kelly Linden tells us that cURL has changed and that is going to affect HTTPRequest calls coming from Linden Scripting Language (LSL).

Here is the deal. cURL is a communications and security process used by Second Life™. The cURL process has always added a no-cache parameter to all HTTP requests passing through it. In a recent update, which is now on Le Tigre, that changed. A no-cache parameter is not added. This means those using 3rd party servers to implement their breedables and other tasks may run into problems. They will have to change their queries to use HTTP_CUSTOM_HEADER in their requests.

If you have breedables or frinds that do, contact the maker or your friends and send them to this post.

Read more

Scripting & Server News Week 42

by

For the release candidate on Le Tigre we have some new information that comes from the wiki release notes just recently updated. Some of those are:

Havok Update

The Havok Physics Engine updates to version 2012.1 in the release candidate. In week 35 I reported that this version was coming. At the time we had just updated to 2010.x, I think. This update enables Havok’s terrain optimized that simplifies the physics shape of the terrain for improved performance. This feature can be disabled by region owners and estate managers with the Region Debug Console command “set optimize_terrain false“.

Havok Physics

Some are reporting vehicle crossing are slower.

llGetSimStats

llGetSimStats() has yet to show up in the Linden Scripting Language (LSL)  pages of the wiki. Fortunately the release notes say:

Currently, this function accepts only [[SIM_STAT_PCT_CHARS_STEPPED]] as its parameter, which returns the % of Pathfinding characters skipped each frame, averaged over the last minute.  The returned value corresponds to the “Characters Updated” stat in the viewer’s Statistics Bar.

Read more

Scripting Week 36

by

llCastRay

SprSrsNoFun brought up an aspect of the llCastRay():llCastRay seems to not function properly once you get to a certain velocity.

The object with the script that executes llCastRay() starts to return somewhat random results once it reaches a certain speed. This is one of those real time problems that involve timing of the script, server, and physics engine. Since the server’s script and physics engines are asynchronous they are not in lock step. So, when the script fires the function may be in a different frame than when the physics engine sees it fired. One may not get the results they expect.

Simon Linden said it this way, “Well, your llGetPos() might execute on one frame, and the ray cast on another, after things have moved.”

Andrew answered, “SprSrsNoFun, the problem you’re seeing is that the script engine is running asynchronously with the physics engine. That is to say, the moments your script gets to run is spotty, and not necessarily synched with the physics engine.

Read more