Freitag, 21. Mai 2010

Second Life Server 1.38

So new it is not really, almost a month ago Linden Labs updated the sim servers to the 1.38 version: The pilot was at 30 march and there are plans for the 1.40 already. But let's look at the 1.38 first. The release notes you find here. A few changes, but actually this server means a generation change for a number of scripts found around SL. If even not to say a little revolution as those few things change much.

For example the LSL (the scripting language for SL) understands two new funktions, llGetLinkPrimitiveParams and llSetLinkPrimitiveParamsFast. The effect of this two might become a complete replacing of resize scripts that were writen years ago and are still verry common in SL. The disadvantage of them is that a copy of a script has to be put in every prim of the device. The maior reason is simple: A script had access only to size and position data of a prim where the script is installed. But absolutelly no way to read this data of other prims. Without knowing this alignment data, we are unable to scale the device with all its parts consistently.

A minor reason is a build-in delay for commands changing the prim's alignment. This delay caused an ugly looking transformation of the device. The result is a large amount of scripts per device and a large resource load slowing the sim down. Now it might become a dust of yesterday. This two functions make us really able to write a single script, that reads alignment data of every prim in the device, calculate new values and set them fastly.

Another interesting function is this: llLinkParticleSystem. This one changes particles of prims. Particles are verry common way to create a beautiful light effects, fireworks, flying hearts or soap bulbs, clouds, water beams or fire. Verry much interesting stuff can be made with particle effects. Before this funktion, each prim that must produce any particle effect needed a script setting the effect. Now it is possible to do that with a single script for the whole device. We can even change the decision which prim has to create which particles dynamically, without to edit the device and put any script in right prims.

And what means this for MACS?

Well for the MACS itself not much, but verry much for the TASC SDK. It was made in old style: The processor script has to be put in every prim of the device. Now it is over. I am actually working on a new processor generation, that allows the user to avoit this boilerplate. The processor script will go than into the root prim of the device and will be still able to manage all it's prims. This allow an easier installation and handling of the system. But more about i tell if i am ready with the development.

Warm greetings from
Jenna

Keine Kommentare:

Kommentar veröffentlichen