Second Life and Virtual Worlds
Jeremy Linden has been working on the Second Life(TM) wiki, the Best Practices for building, mesh, animation, and more. Check out the main page: Good Building Practices.
This page covers all the aspects of building or making just about anything in Second Life. If you are building with mesh, check this out. It covers several aspects of reducing Land Impact costs.
I would say the place is being spruced up for the coming entry into Steam. Whatever, it is nice to the wiki updating.
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.
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:
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“.
Some are reporting vehicle crossing are slower.
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.
About the 6th of September Maestro Linden updated the Pathfinding Events. See the Wiki page: Event path_update. I hadn’t looked at the page for some time. So, I had not noticed until now.
Events are triggers for scripts. They are sort of thing that says: this just happened. You then have a chance to have the script do something in response. The Pathfinding events now include these things:
The green items are new.
Being able to detect when a region has disabled Pathfinding allows the scripter to move the character out of the area and restart it. That will stop PF Characters from piling up at the borders of disabled regions.
When I looked at the page the links from these items had not been added yet. So, we don’t have detailed information on each event. For instance at what distance does PU_SLOWDOWN_DISTANCE_REACHED trigger? Can one set the distance?
Eventually the pages will get written and appear. Until then we’ll just have to go with the short descriptions provided on the path_update page.
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.
I woke up way too early this morning… browsing through the forum I came across a post by Judith Flow about working with petite animations, which I am clueless about. Judith has a process for correcting animations so they work well with petite avatars.
Check it out: How to: make your animations Petite Mesh Avatar Compatible
Thanks Judith.
I would appreciate comments on how well this works from those that have been working with Petite avatars and animating them.