Affichage des articles dont le libellé est script. Afficher tous les articles
Affichage des articles dont le libellé est script. Afficher tous les articles

mercredi 23 mai 2007

Five thinks linked

Five likes to think about life, first or second. At the same times Five programmes a lot. This is called scripting in Second Life. So Second Life two lines of interests come together, the reflections and the programming. Sometimes these are mingled: Five looks at life from a gaming point of view: if we change this or that setting in life, what would happen? Most of the time, if you think well, you cannot escape the conclusion that life is a very good game. This is the position of poor old Leibniz: this is the best of all worlds! At the same time you see that so much is so wrong! It was not difficult for Voltaire to ridicule this observation of Leibniz, for instance in his novel Candide.
There we go again, you might think, but no, this time Five stays practical.
Five wants to show you something. A handler which might be handy when working with linked objects. A linked object, when scripted, mainly functions from its root object, sending messages to the links, or receiving info from these links. The linked objects have numbers, depending on which order you follow linking them together.
If you change the order, the numbers are changed. This is terrible! For instance making a HUD with digits, you have to be careful to take the same order, and when you decide to link something within this order, you can change the whole script! This is because although the function llGetLinkName(integer linknum) exists, there is only llGetLinkNumber() in the link itself! Not something like llName2LinkNumber(string name)!
And this is quite needed, sending commands to the links from the root, with
llMessageLinked().
So Five proposes a small function, see how it works:

This is all taking place in your root script, please give a name to every link, for instance (for the digital clock) digit1, digit2, digit3, digit4, digit5, digit6, etcetera.
Than at the top of your script you declare a list, linkNameList. Then you make a function, going through the whole list of linked objects, and noting the names of the objects. It is as simple as that.


list linkNameList = [ ];
///////////////////////////////////////////////////////////////////////
//getting linknumbers from link names this in state_entry handler
getLinkNameNumberList()
{
integer x;

//x=0 is taken by the root returns 00000000-0000-0000-0000-000000000000
//so we have to go to llGetNumberOfPrims() + 1, to get all the linked objects

for (x=0;x<llGetNumberOfPrims() + 1;x++)
linkNameList +=[x,llGetLinkName(x)];

//these last lines can even be left out, just for checking
integer check = 0;//if check = 1 this gives list of numbers and names
if (check==1)
for (x=0;x<llGetListLength(linkNameList);x+=2)
llSay(0, (string)(x / 2) + " " + llList2String(linkNameList,x) + " " + llList2String(linkNameList,x+1));
}

Ok, then all we need is a small function to be used in the rest of the script, simply replacing the name of the object by the number. Put this function also above the default

// linkName -> linkNumber
integer name2LNum(string linkName)
{
integer x;
for (x=0;x<llGetListLength(linkNameList);x+=2)

if ( linkName == llList2String(linkNameList,x+1) ) return x / 2; //the 2 is because of the ‘strided’ list
return 0; //returning 0 means an error: name not found
}

At the state_entry of the default, we simply call the preparation….

default
{
state_entry()
{
getLinkNameNumberList();//this prepares the list of names and linknumber
//etc….

And now somewhere else in the script, instead of

llMessageLinked( 12 , my1000, "", NULL_KEY); //where 12 is the number of the link

and you can edit and renumber the 12 every time the link order is changed, you use the nice function, just by the putting in the name of the linked object you want to send a message
llMessageLinked( name2LNum("digit4") , days, "", NULL_KEY);
llMessageLinked( name2LNum("digit3") , hours , "", NULL_KEY);
llMessageLinked( name2LNum("digit2") , minutes , "", NULL_KEY);
llMessageLinked( name2LNum("digit1") , seconds, "", NULL_KEY);

So regardless of the linkorder or the complexity of the linked prim, the script will find your digit without a problem!





lundi 30 avril 2007

Five plays with Fire

Second Life has some reminiscences of the primitive shooter games which featured on the early computer. The games where your thumb got numb from pressing the button, to shoot on all kinds of nasty flying objects. Because continuous firing wasn’t invented in these middle ages of computer history, you had to click of push buttons or the mouse incessantly. It were the days before RSI, the repetitive strain injuries and all was well. If something doesn’t have a name, it doesn’t exist.

Firing can be done in Second Life. An object produces other objects, the bullets, which exist only temporarily in the Second Life world. These bullets, or whatever are removed automatically after about a minute. Five isn’t too thrilled by weapons, but the possibility of the making of these temp-rezzed objects is very interesting, because it can also serve more peaceful ends. It is like melting cannons into ploughshares. This alone should be a reason for Five to use this way of making objects. The objects coming out, rezzed, are stored in the inventory of the thing that makes them. This is also very nice: it’s the kangaroo idea: an object has other objects in its belly. These temporarily produced objects can again be filled with other objects. It is not only a kangaroo, but also the idea of a Russian baboesjka, the puppet in puppet in puppet idea. This principle can be fire for programmers, but this blog is not about that kind of fire.

Other virtual fire was needed to use in the game of gold searching in the desert.

The idea was to let players gain a bar of dynamite to get access to secret places where they could find more hidden items. But an object giving of an explosion, smoke, and rubble? That’s programming particle systems, sounds, and this rezzing of temporary objects, which must be exploding, shooting away. This exploding can be done by using the Havok built in SL. This Havok produces natural falling and bouncing of objects, and the effects are never to be programmed by hand, because it involves lots of calculations which have to be done very fast. It is done on a deep basic level in the software.

Experimenting began. Five made an object which rezzes other object around itself, producing clouds and sounds. All went well, steadily more features were added. And then suddenly it went wrong. The kangeroo thing didn’t react anymore on commands. Five checked everything but eventually was puzzled by the malfunctioning. After a few hours of doing something else the solution was found: the lindenscript is delayed by all sorts of things, the rezzing of objects, the talking of objects between themselves (the rubble has to know in which direction to fly away), the smoke effects and the sounds. By loading more and more effects on top of each other the script got mixed up in itself and refused to function.

The solution was to separate all the different effects by enough time to let the script carry out the commands. So a whole string of effects states are ordered in a sequence in the so called timer event.

Then the explosion is well performed, although even then, depending on the traffic in the sim, some effects can be forgotten, making every explosion a bit individual, which is quite good.

Of course the fire is obtained by the text animation script you can obtain free.

Five was often working in the middle of fierce and violent effects. This made Five think, because Five is much more in the habit of making peaceful games. Shooters are not in Five's repertoire! Could it be possible to make a friendly explosion? So the rubble was replaced by flowers, the smoke by flowery images, and the fire animation was replaced by cheerful colors, jumping to and fro. But then again all was going wrong. The flowers proved to be too heavy for the sim, and the sim Five was working in was going down! You know, also peaceful acts can endanger the world? Luckily this Second Life world is partitioned, one sim going down, doesn’t mean the whole world is in danger. The sim quickly recovered from the flowers, removed them and regained consciousness. But the flowers were not saved, so no pictures from these peaceful demolitioners of sims in this blog!