I’ve been busy with other things, so I’m a bit behind. Also, while there is news, there isn’t that much exciting news. But, here is what’s up.
Andrew Linden was busy enough with Pathfinding fixes, creation, and changes he could not make the Sever/Scripting User Group (UG). I suppose that is a good sign.
Falcon Linden is supposed to have a new UG up tomorrow, Thursday, April 19. It will meet in the Pathfinding sandboxes at 4 PM PDT/SLT in ADITI. There is a Pathfinding Project Viewer. It is probably a good idea to use it if you attend the meeting.
Falcon has not added an office hour/user group entry to the wiki. So, I doubt many new faces will be there. Plus the 4 PM time in ADITI is going to cause problems for those of us attending Andrew and Simon Linden’s Server/Scripting group that runs from 3 to 4. It will take some time to log off AGNI and into ADITI. So, lots of late arrivals.
Also, DO NOT change your password if you are working in ADITI or planning to attend the meeting in ADITI. See: ADITI Inventory Loss. Also see: SVC-7727. There are some small bits of info that some work has been done on the problem. But, nothing I can point to.
Once again the release channel tests were failed and no new packages rolled to the main channel. Today we are got two new packages rolled to the release channels.
Blue Steel & Le Tigre
This region gets a package that is indirectly about Direct Delivery. It is a package that has changes to the Inventory API’s to improve inventory transfers. It’s a scalability and reliability thing.
This is a server maintenance package with a couple of new scripting features among the bug, crash, and griefer things.
PRIM_SLICE has been added to the array of llGetLinkPrimitiveParams() type functions. That includes the SET functions too. This is something that has long been a desire of residents. At last we have this handy feature. Expect new types doors and object animations. There are some other tweaks to various parameters in the functions but information is sketchy.
I know I’ve recently had problems with PRIM_POSITION and PRIM_POS_LOCAL in llSetLinkPrimitiveParamsFast() in a new product I’m building. I think that is my lack of understanding, but I have more experimenting to do now that those fixes and tweaks are in place.
HTTP_BODY_MAXLENGTH is an addition to the llHTTPRequest() function. For those that make products and services that use external web sites and databases this is going to make life much easier. Expect improvements in combat meters and XCITE! genitals and toys.
We get a new function many have been anxiously awaiting: llGetRegionAgents(). This function returns a list of all agent keys in the region.
- SCR-15: Add flag parameter [vector slice] to llSetPrimitiveParams PRIM_TYPE flags PRIM_TYPE_BOX, PRIM_TYPE_CYLINDER, and PRIM_TYPE_PRISM
- SVC-680: Increase HTTP Response body size from 2048 to 4096 or larger
- SVC-5488: llGetRegionAgents() — returns list of agent keys in the current region
- SVC-6894: Excessive EnableSimulator message spamming to viewers
- SVC-7307: creation of scripts gets a nice error
The current flight limit for an unassisted avatar is about 150 to 200 meters. It is affected by ground height. That is being raised. In all the release channels that limit is now 5,000m.
You won’t have to have flight feathers to get above 200m. However some flight feathers will get you there faster. Some may get you there ridiculously faster, sort of like a rocket launch. That depends on how your flight assist thingy is designed.
This roll out flight limits happened after the RC updates. It was a first live test of new system that allows simulator configurations to be changed without a simulator restart, which means fewer region restarts in the future.
The idea is new features can be added and rolled out disabled. After the roll-out more and more regions can be enabled to test the feature. If a failure or other problem is found, the feature can be disabled without having restart regions for a roll-back. It’s a good thing and gives the Lindens better testing tools.
The ban height was recently raised too. It is now 5,000 meters. There are rumors one can get around the ban limit. All viewers based on V2/3 code can’t. Apparently some of the old viewers can. This problem is probably the only reason the Lindens would consider blocking older viewers. I expect the Lindens to accept some level of pain rather than block older viewers. Only of the community seriously abuses the exploit will they take steps.
If you haven’t noticed, there is a griefing epidemic. See: Grids defend themselves against hackers. Such people have no foresight and fail to realize it drives the shallow thinkers to SOPA like laws.
One of the problems creators face is being able to resize and color things they sell. Using llSetPrimativesParams() runs into permission problems when trying to adjust textures and sizes in no modify items. This was discussed in a recent Server/Scripting meeting. A feature request is being written to allow some of these prim changes to work without one having to supply the texture UUID for each change.
The idea is if the object, texture, and script creator are the same person then the changes should be allowed.
To understand what this is you have to understand how scripting time is allocated in the Second Life system. All you really need to know is the effect has mostly been mitigated and is far less effective than in the past.
The effect is caused by the system’s forward looking time allocation algorithms. Everything in SL happens with in a frame. Those frames are 22ms long when things are running at 45 FPS. Not all script tasks can complete in 22ms. To get better performance the system tries to anticipate script needs and provide more script time to scripts that need it. This is where the flywheel concept comes into play.
Some people that understood the time allocation algorithm figured out that if they put an empty FOR loop in that took a couple of frames to complete the system would allocate them a huge time slice. So, starting in the 3rd or 4th frame their script had lots of time to run resulting in way better performance for their script.
The Lindens think they have pretty well removed that advantage now. In Monday’s Scripting UG the subject came up. Some special cases seem to have persisted. Kelly is looking at an example of it to see if there is still an exploit to be handled.
Some time ago such a tactic would get a script thousands if not hundreds of thousands of frames of extra long time slices. That has been mitigated and such techniques get only get a script 3 or 4 extra long frames and it takes that many frames to fire off the flywheel.
This is still a pending matter. No new resolution or information. One of the TPV Dev’s says no new information.
This is an issue because some think it is the Lab’s way to kill off Third Party Viewers (TPV). Of course they have to pre-suppose that the Lab wants to kill off TPV’s, which strikes me as ridiculous. However, the wording of the proposed sub-license (see 1-1.1-(b) ) uses a phrasing that is problematic.
(b) Sublicensee must require the Third Party Viewer to connect only to servers owned or operated by the Company;
Oz Linden has made it clear that his take on the policy is different than what many of us see as clear wording. It seems clear to me. If a viewer uses the Havok features, those features can only be used when connecting to Linden Lab’s servers.
What are the Havok features used by the SL Viewers? There are two that I know of. One is in the Mesh Upload panel. Havok is used to ‘automatically’ create the physics layer of uploads. One can work around this problem by creating their own physics layer. In fact at a meeting of the Mesh/Content Creation Group none of the people there used the Havok creation feature. Everyone was making their own physics layers because they could have more control and could reduce their Land Impact cost over what the Havok tool can.
The other use is in Pathfinding. There is a Navmesh viewer and editor that uses Havok features built into the viewer.
Consider. AFAIK, none of the OpenSim grids use Havok. They use ODE, Bullet, and similar open source physics engines.
The lack of a physics process to create a convex hull for mesh uploads has not killed off TPV’s. Since other grids will not have Havok Navmeshes I doubt that is going to kill off TPV’s. The feature is simply useless on other grids. The Pathfinding sort of thing is handled differently in OpenSim.
Plus one pretty much has to be a land owner to use the Navmesh editor. So, there is a pretty small subset of SL users. Leaving the Navmesh features out of TPV’s is not going to have much effect on use rates for TPV’s, at least I don’t see it.
Things are happening. Not much excitement just now. But, we are still told exciting things are coming. Presumably the rumors are about things the Lindens have kept secret. We’ll know eventually.