Second Life Wiki - User contributions [en]

LlAsc & llChr

2007-05-04T23:35:37Z

Xoren Raymaker:

This article is a feature request

This is a simple script feature. Two added functions: llAsc and llChr. These two will convert between characters from a string and their ascii code. This might be especially useful when using font textures..

llAsc returns the integer value that represents the ascii value of the given character.
llChr does the opposite, returning the character with the given ascii value.

integer llAsc(string character);
string llChr(integer asciivalue);

----
See also: [[Feature requests]]

LlAsc & llChr

2007-05-04T21:08:58Z

Xoren Raymaker:

Talk:LlGetChannel

2007-04-26T21:26:09Z

Xoren Raymaker:

Reasons why this feature request shouldn't be implemented.
#Would break existing content.
#Would require hundreds if not thousands of developer hours to code, debug and maintain.
#Easily griefable. Just open a channel and lock it.
#Collsions are rare.
#*If two objects are communicating on random channels, the probability of a collision is 2-32
#*Sims lag horribly when you have several thousand [[listen]]s open, being that there are 232 channels, stumbling upon a used channel is rare.

Ways to mitigate collisions
*Your script can do owner and object name checks to validate who is speaking, allowing for the filtering of collisions.
*Your script can add a header to the message that gives the listener added information that it can use to filter out collisions.
*A protocol can be designed to move the channel it's communicating on when collisions occur.

Since this feature-request would break content and there are already methods for mitigating collisions, I cannot support this feature suggestion. --[[User:Strife Onizuka|Strife Onizuka]] 18:36, 19 April 2007 (PDT)

----
I agree. If it breaks a little existing content, then we might think about implementing it, but if a lot of content would become broken, then it would need to be a very important update. Also the point about griefing you name, is a very good argument.

With this article i was merely trying to put the current method to discussion, as i think it isn't very intuitive how to use this in a secure way. Of cause one would need to use a header and one could even implement encryption and/or compression. But computers are dumb things that only do what we tell them to. If we know all facets of a computer program, we can predict it's entire flow. Unless (and here is where i am getting near my point) something unpredictable, or at least hard to predict, comes along. Because these situations would not (or at least should not) be hard to be made predictable, i do not like depending on something that *might* break because some people found a small chance of collision enough to depend on.
I am a professional computer programmer. If i tell my boss something i made *could* break if another copy is being run on a nearby computer, then i would have something to explain. It might be very well tolerated if we were in a hurry to produce something that would work (mostly), but we on second life are in no hurry, i believe, to make things the way they should be. To think about it and make things right and stable, in stead of something that *might* break, is hard to debug if it breaks and is difficult to maintain in the future.

Also, your solutions do not entirely satisfy me. The two objects in the given example would both have prims of the same name, owner and creator. Indeed, they would have a different key, but how would you tell each one which key to listen to? Of cause there are ways around this as well, and even simple ways by asking the user during initialization phase which key to listen to, but this would make it more difficult to set up, more sensitive to wrong user input and the script would need to have quite some extra code to get this setup done.

So, concluding: yes, you are right in saying it's not as easy as i perhaps pictured it in the article, but i do think it still deserves (and needs) some thinking over. Although, i admit, it is not a very high priority request. --Xoren Raymaker 26 april, 2007

Talk:LlGetChannel

2007-04-26T21:23:25Z

Xoren Raymaker:

Reasons why this feature request shouldn't be implemented.
#Would break existing content.
#Would require hundreds if not thousands of developer hours to code, debug and maintain.
#Easily griefable. Just open a channel and lock it.
#Collsions are rare.
#*If two objects are communicating on random channels, the probability of a collision is 2-32
#*Sims lag horribly when you have several thousand [[listen]]s open, being that there are 232 channels, stumbling upon a used channel is rare.

Ways to mitigate collisions
*Your script can do owner and object name checks to validate who is speaking, allowing for the filtering of collisions.
*Your script can add a header to the message that gives the listener added information that it can use to filter out collisions.
*A protocol can be designed to move the channel it's communicating on when collisions occur.

Since this feature-request would break content and there are already methods for mitigating collisions, I cannot support this feature suggestion. --[[User:Strife Onizuka|Strife Onizuka]] 18:36, 19 April 2007 (PDT)

I agree. If it breaks a little existing content, then we might think about implementing it, but if a lot of content would become broken, then it would need to be a very important update. Also the point about griefing you name, is a very good argument.

With this article i was merely trying to put the current method to discussion, as i think it isn't very intuitive how to use this in a secure way. Of cause one would need to use a header and one could even implement encryption and/or compression. But computers are dumb things that only do what we tell them to. If we know all facets of a computer program, we can predict it's entire flow. Unless (and here is where i am getting near my point) something unpredictable, or at least hard to predict, comes along. Because these situations would not (or at least should not) be hard to be made predictable, i do not like depending on something that *might* break because some people found a small chance of collision enough to depend on.
I am a professional computer programmer. If i tell my boss something i made *could* break if another copy is being run on a nearby computer, then i would have something to explain. It might be very well tolerated if we were in a hurry to produce something that would work (mostly), but we on second life are in no hurry, i believe, to make things the way they should be. To think about it and make things right and stable, in stead of something that *might* break, is hard to debug if it breaks and is difficult to maintain in the future.

Also, your solutions do not entirely satisfy me. The two objects in the given example would both have prims of the same name, owner and creator. Indeed, they would have a different key, but how would you tell each one which key to listen to? Of cause there are ways around this as well, and even simple ways by asking the user during initialization phase which key to listen to, but this would make it more difficult to set up, more sensitive to wrong user input and the script would need to have quite some extra code to get this setup done.

So, concluding: yes, you are right in saying it's not as easy as i perhaps pictured it in the article, but i do think it still deserves (and needs) some thinking over. Although, i admit, it is not a very high priority request. --Xoren Raymaker 26 april, 2007

LlRequestUpgrade

2007-04-21T10:23:34Z

Xoren Raymaker:

''This article is a feature request, not an actually existing function (yet)''

== Summary ==
llRequestUpgrade(key objecttypeid, integer currentversion, list params)

This command sends a request for an upgrade.

== Upgrading ==
Sometimes you don't want to help everyone who has purchased an item you created with an upgrade of that item. In these cases you might want to build in a feature in the object so that it can replace itself for an upgraded version. This is exactly what this command does. It sends a request to the server for an upgraded version of this object and if an upgrade is available, it destroys itself and it is then replaced with an upgraded version.

However, there are several things that may happen, depending on how the upgrade was made available. For this, there would be a command like [[llPublishUpgradableObject]] which takes a key and object name as parameter. For example:

=== The publishing script ===
<pre>
key typeid = "18b03c24-809b-2c19-68d9-fac357e98d29";

default
{
state_entry()
{
llPublishUpgradableObject(typeid, "some_upgradable_object");
}

upgrade_request(key requester, integer currentversion, list params)
{
if (currentversion < 1)
{
llUpgradeError(Requester, "Sorry, your current version is too old. Cannot migrate the settings of your current version to the new one");
}
else if (currentversion == 1)
{
llConfirmUpgrade(requester, 100, param);
}
else
{
llConfirmUpgrade(requester, 0, param);
}
}
}
</pre>

=== The requesting object script (old version of the object) ===
<pre>
integer version = 1;
key mytypeid = "18b03c24-809b-2c19-68d9-fac357e98d29";

default
{
state_entry()
{
llSetText("Version 1...", <1,1,1>, 1);
}

touch_start(integer num)
{
list params;
params += "some value to pass to new version of object";
params += "another value to pass to new version of object";
llRequestUpgrade(mytypeid, version, params);
}
}
</pre>

=== The upgraded object script ===
<pre>
integer version = 3;
key mytypeid = "18b03c24-809b-2c19-68d9-fac357e98d29";

default
{
state_entry()
{
llSetText("Version 3!", <1,1,1>, 1);
}

touch_start(integer num)
{
list params;
params += "some value to pass to new version of object";
params += "another value to pass to new version of object";
llRequestUpgrade(mytypeid, version, params);
}

upgraded(integer oldversion, list params)
{
if (oldversion == 1)
{
// Do stuff to migrate settings from version 1...
} else {
// Do stuff to migrate settings from version 2...
}
}
}
</pre>

I think the example should make it clear, except perhaps for the second parameter to the llConfirmUpgrade command. Sometimes you might want to support an update for an object, but don't want to do it for nothing. It might have been a difficult job to support the upgrade from that version to the new one. For this, there would be a money parameter. If the value to this parameter is greater than 0, the user will receive a dialog, asking if the user wants to pay the amount of linden dollars passed.

== Author ==
Original author: Xoren Raymaker
This request might need some tweaking.. I'm interested what you think of it and what your ideas are.

[[Category:Feature Requests]]

LlRequestUpgrade

2007-04-21T10:22:29Z

Xoren Raymaker:

''This article is a feature request, not an actually existing function (yet)''

== Summary ==
llRequestUpgrade(key objecttypeid, integer currentversion, list params)

This command sends a request for an upgrade.

== Upgrading ==
Sometimes you don't want to help everyone who has purchased an item you created with an upgrade of that item. In these cases you might want to build in a feature in the object so that it can replace itself for an upgraded version. This is exactly what this command does. It sends a request to the server for an upgraded version of this object and if an upgrade is available, it destroys itself and it is then replaced with an upgraded version.

However, there are several things that may happen, depending on how the upgrade was made available. For this, there would be a command like [[llPublishUpgradableObject]] which takes a key and object name as parameter. For example:

=== The publishing script ===
<pre>
key typeid = "18b03c24-809b-2c19-68d9-fac357e98d29";

default
{
state_entry()
{
llPublishUpgradableObject(typeid, "some_upgradable_object");
}

upgrade_request(key requester, integer currentversion, list params)
{
if (currentversion < 1)
{
llUpgradeError(Requester, "Sorry, your current version is too old. Cannot migrate the settings of your current version to the new one");
}
else if (currentversion == 1)
{
llConfirmUpgrade(requester, 100, param);
}
else
{
llConfirmUpgrade(requester, 0, param);
}
}
}
</pre>

=== The requesting object script (old version of the object) ===
<pre>
integer version = 1;
key mytypeid = "18b03c24-809b-2c19-68d9-fac357e98d29";

default
{
state_entry()
{
llSetText("Version 1...", <1,1,1>, 1);
}

touch_start(integer num)
{
list params;
params += "some value to pass to new version of object";
params += "another value to pass to new version of object";
llRequestUpgrade(mytypeid, version, params);
}
}
</pre>

=== The upgraded object script ===
<pre>
integer version = 3;
key mytypeid = "18b03c24-809b-2c19-68d9-fac357e98d29";

default
{
state_entry()
{
llSetText("Version 3!", <1,1,1>, 1);
}

touch_start(integer num)
{
list params;
params += "some value to pass to new version of object";
params += "another value to pass to new version of object";
llRequestUpgrade(mytypeid, version, params);
}

upgraded(integer oldversion, list params)
{
if (oldversion == 1)
{
// Do stuff to migrate settings from version 1...
} else {
// Do stuff to migrate settings from version 2...
}
}
}
</pre>

I think the example should make it clear, except perhaps for the second parameter to the llConfirmUpgrade command. Sometimes you might want to support an update for an object, but don't want to do it for nothing. It might have been a difficult job to support the upgrade from that version to the new one. For this, there would be a money parameter. If the value to this parameter is greater than 0, the user will receive a dialog, asking if the user wants to pay the amount of linden dollars passed.

This request might need some tweaking.. I'm interested what you think of it and what your ideas are.

[[Category:Feature Requests]]

LlRequestUpgrade

2007-04-21T10:21:04Z

Xoren Raymaker:

''This article is a feature request, not an actually existing function (yet)''

== Summary ==
llRequestUpgrade(key objecttypeid, integer currentversion, list params)

This command sends a request for an upgrade.

== Upgrading ==
Sometimes you don't want to help everyone who has purchased an item you created with an upgrade of that item. In these cases you might want to build in a feature in the object so that it can replace itself for an upgraded version. This is exactly what this command does. It sends a request to the server for an upgraded version of this object and if an upgrade is available, it destroys itself and it is then replaced with an upgraded version.

However, there are several things that may happen, depending on how the upgrade was made available. For this, there would be a command like [[llPublishUpgradableObject]] which takes a key and object name as parameter. For example:

=== The publishing script ===
<pre>
key typeid = "18b03c24-809b-2c19-68d9-fac357e98d29";

default
{
state_entry()
{
llPublishUpgradableObject(typeid, "some_upgradable_object");
}

upgrade_request(key requester, integer currentversion, list params)
{
if (currentversion < 1)
{
llUpgradeError(Requester, "Sorry, your current version is too old. Cannot migrate the settings of your current version to the new one");
}
else if (currentversion == 1)
{
llConfirmUpgrade(requester, 100, param);
}
else
{
llConfirmUpgrade(requester, 0, param);
}
}
}
</pre>

=== The requesting object script (old version of the object) ===
<pre>
integer version = 1;
key mytypeid = "18b03c24-809b-2c19-68d9-fac357e98d29";

default
{
state_entry()
{
llSetText("Version 1...", <1,1,1>, 1);
}

touch_start(integer num)
{
list params;
params += "some value to pass to new version of object";
params += "another value to pass to new version of object";
llRequestUpgrade(mytypeid, version, params);
}
}
</pre>

=== The upgraded object script ===
<pre>
integer version = 3;
key mytypeid = "18b03c24-809b-2c19-68d9-fac357e98d29";

default
{
state_entry()
{
llSetText("Version 3!", <1,1,1>, 1);
}

touch_start(integer num)
{
list params;
params += "some value to pass to new version of object";
params += "another value to pass to new version of object";
llRequestUpgrade(mytypeid, version, params);
}

upgraded(integer oldversion, list params)
{
if (oldversion == 1)
{
// Do stuff to migrate settings from version 1...
} else {
// Do stuff to migrate settings from version 2...
}
}
}
</pre>

I think the example should make it clear, except perhaps for the second parameter to the llConfirmUpgrade command. Sometimes you might want to support an update for an object, but don't want to do it for nothing. It might have been a difficult job to support the upgrade from that version to the new one. For this, there would be a money parameter. If the value to this parameter is greater than 0, the user will receive a dialog, asking if the user wants to pay the amount of linden dollars passed.

This request might need some tweaking.. I'm interested what you think of it and what your ideas are.

LlRequestUpgrade

2007-04-21T10:20:16Z

Xoren Raymaker:

''This article is a feature request, not an actually existing function (yet)''

== Summary ==
llRequestUpgrade(key objecttypeid, integer currentversion, list params)

This command sends a request for an upgrade.

== Upgrading ==
Sometimes you don't want to help everyone who has purchased an item you created with an upgrade of that item. In these cases you might want to build in a feature in the object so that it can replace itself for an upgraded version. This is exactly what this command does. It sends a request to the server for an upgraded version of this object and if an upgrade is available, it destroys itself and it is then replaced with an upgraded version.

However, there are several things that may happen, depending on how the upgrade was made available. For this, there would be a command like [[llPublishUpgradableObject]] which takes a key and object name as parameter. For example:

# The publishing script:
<pre>
key typeid = "18b03c24-809b-2c19-68d9-fac357e98d29";

default
{
state_entry()
{
llPublishUpgradableObject(typeid, "some_upgradable_object");
}

upgrade_request(key requester, integer currentversion, list params)
{
if (currentversion < 1)
{
llUpgradeError(Requester, "Sorry, your current version is too old. Cannot migrate the settings of your current version to the new one");
}
else if (currentversion == 1)
{
llConfirmUpgrade(requester, 100, param);
}
else
{
llConfirmUpgrade(requester, 0, param);
}
}
}
</pre>

# The requesting object script (old version of the object):
<pre>
integer version = 1;
key mytypeid = "18b03c24-809b-2c19-68d9-fac357e98d29";

default
{
state_entry()
{
llSetText("Version 1...", <1,1,1>, 1);
}

touch_start(integer num)
{
list params;
params += "some value to pass to new version of object";
params += "another value to pass to new version of object";
llRequestUpgrade(mytypeid, version, params);
}
}
</pre>

# The upgraded object script:
<pre>
integer version = 3;
key mytypeid = "18b03c24-809b-2c19-68d9-fac357e98d29";

default
{
state_entry()
{
llSetText("Version 3!", <1,1,1>, 1);
}

touch_start(integer num)
{
list params;
params += "some value to pass to new version of object";
params += "another value to pass to new version of object";
llRequestUpgrade(mytypeid, version, params);
}

upgraded(integer oldversion, list params)
{
if (oldversion == 1)
{
// Do stuff to migrate settings from version 1...
} else {
// Do stuff to migrate settings from version 2...
}
}
}
</pre>

I think the example should make it clear, except perhaps for the second parameter to the llConfirmUpgrade command. Sometimes you might want to support an update for an object, but don't want to do it for nothing. It might have been a difficult job to support the upgrade from that version to the new one. For this, there would be a money parameter. If the value to this parameter is greater than 0, the user will receive a dialog, asking if the user wants to pay the amount of linden dollars passed.

This request might need some tweaking.. I'm interested what you think of it and what your ideas are.

LlRequestUpgrade

2007-04-21T09:20:07Z

Xoren Raymaker: llRequestUpgrade(key target, integer objecttypeid, integer version, string param)

''This article is a feature request, not an actually existing function (yet)''

This command sends a request for an upgrade.

LlGetChannel

2007-04-19T17:54:49Z

Xoren Raymaker:

''This article is a feature request''

Freedom of speech is a very important thing, both in real life and in second life. In second life, objects can speak. They can speak only to their owner, speak over instant message to any object or they can even [[llWhisper]], [[llSay]] or [[llShout]] to a channel of choice.
This is where the problem starts to form: With a constantly growing number of objects containing scripts, the number of used channels is climbing fast. The chance that two objects (perhaps two copies of the same thing) use the same channel to communicate is getting bigger and bigger. If such a thing would happen, the chance of undefined behavior of objects would be very realistic. I would consider such undefined behavior to be a bug and i personally see any bug as a way for certain people to bring the grid to it's knees or do other bad things..

A way to prevent these problems is to limit the choice of channel to use, by enforcing a rule. We could allow every object free use of channels 0-9999. Channels above 9999 would then not be free to choose, but would have to be requested, so the server may ensure that the channel is not used by any other objects in the grid. The way to request such a channel for usage is to use the function llGetChannel() which returns an integer, identifying the channel.

The object that requested a channel, becomes owner of this channel and must decide which objects may or may not communicate on it. Therefor a few other functions would need to be added. Other objects could use a new function like llRequestChannelUsage(integer channel), upon which an event would be fired in the script of the channel owner. This could be perhaps a channel_request(integer channel, key id) event and the owner could then llAllowChannelUsage(integer channel, key id) or llDenyChannelUsage(integer channel, key id). The requesting object would then receive this answer through a new channel_permission(integer channel, bool allowed) event.

This is just an idea and it might still need some thinking over, but i think the idea is clear enough.

See also:
[[Category:Feature Requests]]

LlGetChannel

2007-04-19T17:52:25Z

Xoren Raymaker:

LlGetChannel

2007-04-19T17:50:37Z

Xoren Raymaker:

''This article is a feature request''

Freedom of speech is a very important thing, both in real life and in second life. In second life, objects can speak. They can speak only to their owner, speak over instant message to any object or they can even [[llWhisper]], [[llSay]] or [[llShout]] to a channel of choice.
This is where the problem starts to form: With a constantly growing number of objects containing scripts, the number of used channels is climbing fast. The chance that two objects (perhaps two copies of the same thing) use the same channel to communicate is getting bigger and bigger. If such a thing would happen, the chance of undefined behavior of objects would be very realistic. I would consider such undefined behavior to be a bug and i personally see any bug as a way for certain people to bring the grid to it's knees or do other bad things..

A way to prevent these problems is to limit the choice of channel to use, by enforcing a of rule. We could allow every object free use of channels 0-9999. Channels above 9999 would then not be free to choose, but would have to be requested, so the server may ensure that the channel is not used by any other objects in the grid. The way to request such a channel for usage is to use the function llGetChannel() which returns an integer, identifying the channel.

The object that requested a channel, becomes owner of this channel and must decide which objects may or may not communicate on it. Therefor a few other functions would need to be added. Other objects could use a new function like llRequestChannelUsage(integer channel), upon which an event would be fired in the script of the channel owner. This could be perhaps a channel_request(integer channel, key id) event and the owner could then llAllowChannelUsage(integer channel, key id) or llDenyChannelUsage(integer channel, key id). The requesting object would then receive this answer through a new channel_permission(integer channel, bool allowed) event.

This is just an idea and it might still need some thinking over.

See also:
[[Category:Feature Requests]]

LlGetChannel

2007-04-19T17:50:25Z

Xoren Raymaker:

''This article is a feature request''

Freedom of speech is a very important thing, both in real life and in second life. In second life, objects can speak. They can speak only to their owner, speak over instant message to any object or they can even [[llWhisper]], [[llSay]] or [[llShout]] to a channel of choice.
This is where the problem starts to form: With a constantly growing number of objects containing scripts, the number of used channels is climbing fast. The chance that two objects (perhaps two copies of the same thing) use the same channel to communicate is getting bigger and bigger. If such a thing would happen, the chance of undefined behavior of objects would be very realistic. I would consider such undefined behavior to be a bug and i personally see any bug as a way for certain people to bring the grid to it's knees or do other bad things..

A way to prevent these problems is to limit the choice of channel to use, by enforcing a of rule. We could allow every object free use of channels 0-9999. Channels above 9999 would then not be free to choose, but would have to be requested, so the server may ensure that the channel is not used by any other objects in the grid. The way to request such a channel for usage is to use the function llGetChannel() which returns an integer, identifying the channel.

The object that requested a channel, becomes owner of this channel and must decide which objects may or may not communicate on it. Therefor a few other functions would need to be added. Other objects could use a new function like llRequestChannelUsage(integer channel), upon which an event would be fired in the script of the channel owner. This could be perhaps a channel_request(integer channel, key id) event and the owner could then llAllowChannelUsage(integer channel, key id) or llDenyChannelUsage(integer channel, key id). The requesting object would then receive this answer through a new channel_permission(integer channel, bool allowed) event.

This is just an idea and it might still need some thinking over.

See also:
[[Category:Feature Requests]]

LlGetChannel

2007-04-19T17:49:15Z

Xoren Raymaker:

''This article is a feature request''

Freedom of speech is a very important thing, both in real life and in second life. In second life, objects can speak. They can speak only to their owner, speak over instant message to any object or they can even [[llWhisper]], [[llSay]] or [[llShout]] to a channel of choice.
This is where the problem starts to form: With a constantly growing number of objects containing scripts, the number of used channels is climbing fast. The chance that two objects (perhaps two copies of the same thing) use the same channel to communicate is getting bigger and bigger. If such a thing would happen, the chance of undefined behavior of objects would be very realistic. I would consider such undefined behavior to be a bug and i personally see any bug as a way for certain people to bring the grid to it's knees or do other bad things..

A way to prevent these problems is to limit the choice of channel to use, by enforcing a of rule. We could allow every object free use of channels 0-9999. Channels above 9999 would then not be free to choose, but would have to be requested, so the server may ensure that the channel is not used by any other objects in the grid. The way to request such a channel for usage is to use the function llGetChannel() which returns an integer, identifying the channel.

The object that requested a channel, becomes owner of this channel and must decide which objects may or may not communicate on it. Therefor a few other functions would need to be added. Other objects could use a new function like llRequestChannelUsage(integer channel), upon which an event would be fired in the script of the channel owner. This could be perhaps a channel_request(integer channel, key id) event and the owner could then llAllowChannelUsage(integer channel, key id) or llDenyChannelUsage(integer channel, key id). The requesting object would then receive this answer through a new channel_permission(integer channel, bool allowed) event.

This is just an idea and it might still need some thinking over.

Object Oriented LSL

2007-04-19T16:53:44Z

Xoren Raymaker:

''This article is a feature request''

This should be straight forward: Classes in LSL.

Because it might not be clear why this is needed or how this would fit into currently existing LSL, I will try to make this clear through an example.

To keep it simple, this object has two prims, one base and one prim simulating the laser light. The laser light prim contains two scripts and the base prim contains one script, which uses code, written in the two other scripts.

== Class Declaration ==
This is the first script, containing the interface of a script library, containing the interface of a class.
<pre>
!type libraryinterface;

!exports class Laser;

class Laser: inherits llcConePrim
{
protected
function SetPosition(vector pos); override;
public
constructor Create(); override;
destructor Destroy(); override;

function SwitchOn();
function SwitchOff();

function SetColor(colorandalpha rgba); override;
function GetColor(): colorandalpha; override;

property Color: colorandalpha; read GetColor write SetColor;
}
</pre>

This script introduces a few things yet unknown in LSL, none of which are (at the time of writing) documented feature requests. First line in this script specifies that this script is of a different type than a normal script. It is in fact the interface of a script library. It knows a counterpart called a libraryimplementation, which we will find in the second script. This is done because someone who wants to use the script library, needs to know it's interface, so these interface scripts need to be viewable by other users, but you might want to protect the implementation part of the library, so hence two scripts are needed, so that one can be viewable and the other not viewable.
The next line we find, contains an !exports keyword, which says "this script exports something that should be able to be used by other scripts". In this case, it exports the class "Laser", which is defined after this.
Note: The keywords !type and !exports are both prefixed by an exclamation mark (!) because they tell something about the script itself. They could be seen as extra (optional) properties to a script.
Note2: I will not explain in depth here what everything means, i will assume therefor that the general concept and terminology of classes is known.

=== The Keyword Class ===
Now the actual subject of this feature request. The next line after the !exports keyword begins the definition of a class called "Laser". Straight into it, we also specify that it inherits from llcConePrim, which would be the base class representing all cone shaped prims. The llcConePrim itself then inherits from the basic llcPrim which would be the base class for all prims.

=== The Keyword Protected ===
Inside the class declaration, we find the keyword protected. This specifies that things defined after this keyword not available for use by all other code. Only members of the class itself, classes which inherit from this Laser class and classes which are "friends" of this Laser class, can "see" (and therefor use) the protected members declared.

=== The Member Function ===
A class would be worth almost nothing if it didn't have member functions. Not much is to be said about these. The keyword "override" that follows it's declaration means "this functions overrides the functionality of a memberfunction with the same name in the base class". Of cause this overriding can only be done if the function with this same name was defined as virtual in any of the ancestors. Besides override, there are many keywords to be invented here for use, like "reintroduce", "abstract", "overload", etc.. I think that the idea of "abstract" (pure virtual) and "overload" is clear to most people.
The keyword "reintroduce" hides any functions of the same name from the inherited classes. Lets say a class A contains a virtual function "Test" with a parameter name as a string and a class B inherits from A and also implements the function Test, but does not have any parameters. You would then use the keyword reintroduce on the function B.Test, because this one reintroduces this functionality and you would not want a user of the class to use A.Test(...)

=== The Keyword Public ===
After the protected SetPosition member function we find the keyword public. This specifies that functions and such specified after this keyword are publicly available. In other words: every bit of code can "see" the things declared after the keyword public.

=== Constructor and Destructor ===
The constructor and destructor are special memberfunctions. Every class has a constructor and destructor, but not every class needs to do anything special inside the constructor or destructor. The constructor and destructor are guaranteed to be called when an object of this class is created or destroyed. This way the object can do some initialization and finalization.

=== Class Properties ===
Near to the end, we find a line defining a so called property with the name "Color". This works almost like a variable and we will demonstrate this later. When we set the value of this property, the function SetColor will be used and when we will read out the value of the property, the function GetColor will be used to return the value.

== Class implementation ==
Here is the second script, which contains the implementation of the class defined in the previous section.
<pre>
!type libraryimplementation;

!implements class Laser;

class Laser: inherits llcCubePrim
{
private
colorandalpha _Color;
bool _State;
key _id;
protected
function SetPosition(vector pos)
{
llSetPos(pos);
}
public
constructor Create()
{
_id = llGetKey();
_State = false;
_Color = <0,0,0,0>;
llPrimHide();
llTargetOmega(<0,0,0>, 0, 0);
}
destructor Destroy()
{
// Nothing to do..
}

function SwitchOn()
{
_State = true;
llPrimShow();
llTargetOmega(<1,0,0>, PI, 1);
}
function SwitchOff()
{
_State = false;
llPrimHide();
llTargetOmega(<0,0,0>, 0, 0);
}

function SetColor(colorandalpha rgba)
{
_Color = rgba;
}

function GetColor(): colorandalpha
{
return _Color;
}
}
</pre>

I've use a few functions here that might not be actually existing functions, but for the sake of the simplicity of the example.. I don't know all functions yet, so i couldn't find a function for hiding and showing the prim the script is part of.
This shouls be pretty self explanatory, except at the beginning, we see the keyword !implements. This new keyword tells the scripting environment that this script implements the Laser class.
Further down this script, some people might wonder why the property Color was not present here. This is because properties are interface only. Think about it: What it there to implement on a property? A property only specifies how to read and (optionally) write the value.

== Usage ==
Now perhaps the most important part: How are we to use these classes? Well, remember the !exports keyword, which said that the class Laser was exported? We will now use that exported class in the base object.
<pre>
!type normal; // not needed, but one may specify if one wants to waste time of specifying this that are already default.. ;)

!include LaserCone.LibraryInterfaceScript;
!include LaserCone.LibraryImplementationScript;

Laser cone1, cone2;

default
{
state_entry()
{
cone1 = Laser.Create();
cone1.Color = <0,1,0,1>;
cone2 = Laser.Create();
cone2.Color = <1,0,0,1>;

state off;
}
}

state off
{
state_entry()
{
cone1.SwitchOff();
cone2.SwitchOff();
}
touch_start(integer num)
{
state on;
}
}

state on
{
state_entry()
{
cone1.SwitchOn();
cone2.SwitchOn();
llSetTimerEvent(1);
}
touch_start(integer num)
{
llSetTimerEvent(0);
state off;
}
timer()
{
float r = llFrand(1);
float g = llFrand(1);
float b = llFrand(1);
cone1.Color = <r,g,b,1>;

float r = llFrand(1);
float g = llFrand(1);
float b = llFrand(1);
cone2.Color = <r,g,b,1>;
}
}
</pre>

Well, most of this should be a piece of cake, really, except, perhaps, the lines containing the !include keyword. This keyword specifies that this this script would like to use code in a different script. In this case, I immediately went a step further than the basics, including a script which is not part of the content of the same prim, but which is inside a different prim. The prim which contains the scripts in this example is called "LaserCone" and the two scripts are called LibraryInterfaceScript and LibraryImplementationScript.
Any script from any prim in the set may be included, but only things that are actually exported can be used. In this case, the implementation script does not export anything. It only implements the interface of the Laser class. The interface script does export something: the Laser class, so the last script may use it.

In the state_entry() of the default state, we see two Laser objects are created, stored in the variables cone1 and cone2. Also their Color is set. Pure green for cone1 and pure red for cone2. The way the color is specified here is not currently possible in LSL, but i like to think about color as a 4D vector, including red, green, blue and alpha values, which makes it easier to specify color. Also, OpenGL accepts color this way through glColor4f(r, g, b, a), so it might be better, performance wise, to do it like this. Here, i mostly used it for the sake of the example. It also makes the example class a lot tighter than including a seperate alpha property and set and get methods.
Note: From this script, it is impossible to call the SetPosition function, defined in the interface of the class. This is not possible, because this function is defined in a protected visibility and this code is not part of a decendantclass, friend class, or other such code that should be able to see protected functions of the Laser class.

== Authors ==
Original author: Xoren Raymaker, April 18, 2007. 
I realize this might need some tweaking, but i'm interested what your ideas and comments are about this idea of mine. It is a big thing to add to SL, but i think it could (in time) greatly enhance flexibility and features.

== Related ideas ==
#[[Operator overloading]]

[[Category:Feature Requests]]

Object Oriented LSL

2007-04-18T19:22:47Z

Xoren Raymaker:

This should be straight forward: Classes in LSL.

Because it might not be clear why this is needed or how this would fit into currently existing LSL, I will try to make this clear through an example.

To keep it simple, this object has two prims, one base and one prim simulating the laser light. The laser light prim contains two scripts and the base prim contains one script, which uses code, written in the two other scripts.

== Class Declaration ==
This is the first script, containing the interface of a script library, containing the interface of a class.
<pre>
!type libraryinterface;

!exports class Laser;

class Laser: inherits llcConePrim
{
protected
function SetPosition(vector pos); override;
public
constructor Create(); override;
destructor Destroy(); override;

function SwitchOn();
function SwitchOff();

function SetColor(colorandalpha rgba); override;
function GetColor(): colorandalpha; override;

property Color: colorandalpha; read GetColor write SetColor;
}
</pre>

This script introduces a few things yet unknown in LSL, none of which are (at the time of writing) documented feature requests. First line in this script specifies that this script is of a different type than a normal script. It is in fact the interface of a script library. It knows a counterpart called a libraryimplementation, which we will find in the second script. This is done because someone who wants to use the script library, needs to know it's interface, so these interface scripts need to be viewable by other users, but you might want to protect the implementation part of the library, so hence two scripts are needed, so that one can be viewable and the other not viewable.
The next line we find, contains an !exports keyword, which says "this script exports something that should be able to be used by other scripts". In this case, it exports the class "Laser", which is defined after this.
Note: The keywords !type and !exports are both prefixed by an exclamation mark (!) because they tell something about the script itself. They could be seen as extra (optional) properties to a script.
Note2: I will not explain in depth here what everything means, i will assume therefor that the general concept and terminology of classes is known.

=== The Keyword Class ===
Now the actual subject of this feature request. The next line after the !exports keyword begins the definition of a class called "Laser". Straight into it, we also specify that it inherits from llcConePrim, which would be the base class representing all cone shaped prims. The llcConePrim itself then inherits from the basic llcPrim which would be the base class for all prims.

=== The Keyword Protected ===
Inside the class declaration, we find the keyword protected. This specifies that things defined after this keyword not available for use by all other code. Only members of the class itself, classes which inherit from this Laser class and classes which are "friends" of this Laser class, can "see" (and therefor use) the protected members declared.

=== The Member Function ===
A class would be worth almost nothing if it didn't have member functions. Not much is to be said about these. The keyword "override" that follows it's declaration means "this functions overrides the functionality of a memberfunction with the same name in the base class". Of cause this overriding can only be done if the function with this same name was defined as virtual in any of the ancestors. Besides override, there are many keywords to be invented here for use, like "reintroduce", "abstract", "overload", etc.. I think that the idea of "abstract" (pure virtual) and "overload" is clear to most people.
The keyword "reintroduce" hides any functions of the same name from the inherited classes. Lets say a class A contains a virtual function "Test" with a parameter name as a string and a class B inherits from A and also implements the function Test, but does not have any parameters. You would then use the keyword reintroduce on the function B.Test, because this one reintroduces this functionality and you would not want a user of the class to use A.Test(...)

=== The Keyword Public ===
After the protected SetPosition member function we find the keyword public. This specifies that functions and such specified after this keyword are publicly available. In other words: every bit of code can "see" the things declared after the keyword public.

=== Constructor and Destructor ===
The constructor and destructor are special memberfunctions. Every class has a constructor and destructor, but not every class needs to do anything special inside the constructor or destructor. The constructor and destructor are guaranteed to be called when an object of this class is created or destroyed. This way the object can do some initialization and finalization.

=== Class Properties ===
Near to the end, we find a line defining a so called property with the name "Color". This works almost like a variable and we will demonstrate this later. When we set the value of this property, the function SetColor will be used and when we will read out the value of the property, the function GetColor will be used to return the value.

== Class implementation ==
Here is the second script, which contains the implementation of the class defined in the previous section.
<pre>
!type libraryimplementation;

!implements class Laser;

class Laser: inherits llcCubePrim
{
private
colorandalpha _Color;
bool _State;
key _id;
protected
function SetPosition(vector pos)
{
llSetPos(pos);
}
public
constructor Create()
{
_id = llGetKey();
_State = false;
_Color = <0,0,0,0>;
llPrimHide();
llTargetOmega(<0,0,0>, 0, 0);
}
destructor Destroy()
{
// Nothing to do..
}

function SwitchOn()
{
_State = true;
llPrimShow();
llTargetOmega(<1,0,0>, PI, 1);
}
function SwitchOff()
{
_State = false;
llPrimHide();
llTargetOmega(<0,0,0>, 0, 0);
}

function SetColor(colorandalpha rgba)
{
_Color = rgba;
}

function GetColor(): colorandalpha
{
return _Color;
}
}
</pre>

I've use a few functions here that might not be actually existing functions, but for the sake of the simplicity of the example.. I don't know all functions yet, so i couldn't find a function for hiding and showing the prim the script is part of.
This shouls be pretty self explanatory, except at the beginning, we see the keyword !implements. This new keyword tells the scripting environment that this script implements the Laser class.
Further down this script, some people might wonder why the property Color was not present here. This is because properties are interface only. Think about it: What it there to implement on a property? A property only specifies how to read and (optionally) write the value.

== Usage ==
Now perhaps the most important part: How are we to use these classes? Well, remember the !exports keyword, which said that the class Laser was exported? We will now use that exported class in the base object.
<pre>
!type normal; // not needed, but one may specify if one wants to waste time of specifying this that are already default.. ;)

!include LaserCone.LibraryInterfaceScript;
!include LaserCone.LibraryImplementationScript;

Laser cone1, cone2;

default
{
state_entry()
{
cone1 = Laser.Create();
cone1.Color = <0,1,0,1>;
cone2 = Laser.Create();
cone2.Color = <1,0,0,1>;

state off;
}
}

state off
{
state_entry()
{
cone1.SwitchOff();
cone2.SwitchOff();
}
touch_start(integer num)
{
state on;
}
}

state on
{
state_entry()
{
cone1.SwitchOn();
cone2.SwitchOn();
llSetTimerEvent(1);
}
touch_start(integer num)
{
llSetTimerEvent(0);
state off;
}
timer()
{
float r = llFrand(1);
float g = llFrand(1);
float b = llFrand(1);
cone1.Color = <r,g,b,1>;

float r = llFrand(1);
float g = llFrand(1);
float b = llFrand(1);
cone2.Color = <r,g,b,1>;
}
}
</pre>

Well, most of this should be a piece of cake, really, except, perhaps, the lines containing the !include keyword. This keyword specifies that this this script would like to use code in a different script. In this case, I immediately went a step further than the basics, including a script which is not part of the content of the same prim, but which is inside a different prim. The prim which contains the scripts in this example is called "LaserCone" and the two scripts are called LibraryInterfaceScript and LibraryImplementationScript.
Any script from any prim in the set may be included, but only things that are actually exported can be used. In this case, the implementation script does not export anything. It only implements the interface of the Laser class. The interface script does export something: the Laser class, so the last script may use it.

In the state_entry() of the default state, we see two Laser objects are created, stored in the variables cone1 and cone2. Also their Color is set. Pure green for cone1 and pure red for cone2. The way the color is specified here is not currently possible in LSL, but i like to think about color as a 4D vector, including red, green, blue and alpha values, which makes it easier to specify color. Also, OpenGL accepts color this way through glColor4f(r, g, b, a), so it might be better, performance wise, to do it like this. Here, i mostly used it for the sake of the example. It also makes the example class a lot tighter than including a seperate alpha property and set and get methods.
Note: From this script, it is impossible to call the SetPosition function, defined in the interface of the class. This is not possible, because this function is defined in a protected visibility and this code is not part of a decendantclass, friend class, or other such code that should be able to see protected functions of the Laser class.

== Authors ==
Original author: Xoren Raymaker, April 18, 2007. 
I realize this might need some tweaking, but i'm interested what your ideas and comments are about this idea of mine. It is a big thing to add to SL, but i think it could (in time) greatly enhance flexibility and features.

== Related ideas ==
#[[Operator overloading]]

[[Category:Feature Requests]]

Object Oriented LSL

2007-04-18T19:19:34Z

Xoren Raymaker:

This should be straight forward: Classes in LSL.

Because it might not be clear why this is needed or how this would fit into currently existing LSL, I will try to make this clear through an example.

To keep it simple, this object has two prims, one base and one prim simulating the laser light. The laser light prim contains two scripts and the base prim contains one script, which uses code, written in the two other scripts.

== Class Declaration ==
This is the first script, containing the interface of a script library, containing the interface of a class.
<pre>
!type libraryinterface;

!exports class Laser;

class Laser: inherits llcConePrim
{
protected
function SetPosition(vector pos); override;
public
constructor Create(); override;
destructor Destroy(); override;

function SwitchOn();
function SwitchOff();

function SetColor(colorandalpha rgba); override;
function GetColor(): colorandalpha; override;

property Color: colorandalpha; read GetColor write SetColor;
}
</pre>

This script introduces a few things yet unknown in LSL, none of which are (at the time of writing) documented feature requests. First line in this script specifies that this script is of a different type than a normal script. It is in fact the interface of a script library. It knows a counterpart called a libraryimplementation, which we will find in the second script. This is done because someone who wants to use the script library, needs to know it's interface, so these interface scripts need to be viewable by other users, but you might want to protect the implementation part of the library, so hence two scripts are needed, so that one can be viewable and the other not viewable.
The next line we find, contains an !exports keyword, which says "this script exports something that should be able to be used by other scripts". In this case, it exports the class "Laser", which is defined after this.
Note: The keywords !type and !exports are both prefixed by an exclamation mark (!) because they tell something about the script itself. They could be seen as extra (optional) properties to a script.
Note2: I will not explain in depth here what everything means, i will assume therefor that the general concept and terminology of classes is known.

=== The Keyword Class ===
Now the actual subject of this feature request. The next line after the !exports keyword begins the definition of a class called "Laser". Straight into it, we also specify that it inherits from llcConePrim, which would be the base class representing all cone shaped prims. The llcConePrim itself then inherits from the basic llcPrim which would be the base class for all prims.

=== The Keyword Protected ===
Inside the class declaration, we find the keyword protected. This specifies that things defined after this keyword not available for use by all other code. Only members of the class itself, classes which inherit from this Laser class and classes which are "friends" of this Laser class, can "see" (and therefor use) the protected members declared.

=== The Member Function ===
A class would be worth almost nothing if it didn't have member functions. Not much is to be said about these. The keyword "override" that follows it's declaration means "this functions overrides the functionality of a memberfunction with the same name in the base class". Of cause this overriding can only be done if the function with this same name was defined as virtual in any of the ancestors. Besides override, there are many keywords to be invented here for use, like "reintroduce", "abstract", "overload", etc.. I think that the idea of "abstract" (pure virtual) and "overload" is clear to most people.
The keyword "reintroduce" hides any functions of the same name from the inherited classes. Lets say a class A contains a virtual function "Test" with a parameter name as a string and a class B inherits from A and also implements the function Test, but does not have any parameters. You would then use the keyword reintroduce on the function B.Test, because this one reintroduces this functionality and you would not want a user of the class to use A.Test(...)

=== The Keyword Public ===
After the protected SetPosition member function we find the keyword public. This specifies that functions and such specified after this keyword are publicly available. In other words: every bit of code can "see" the things declared after the keyword public.

=== Constructor and Destructor ===
The constructor and destructor are special memberfunctions. Every class has a constructor and destructor, but not every class needs to do anything special inside the constructor or destructor. The constructor and destructor are guaranteed to be called when an object of this class is created or destroyed. This way the object can do some initialization and finalization.

=== Class Properties ===
Near to the end, we find a line defining a so called property with the name "Color". This works almost like a variable and we will demonstrate this later. When we set the value of this property, the function SetColor will be used and when we will read out the value of the property, the function GetColor will be used to return the value.

== Class implementation ==
Here is the second script, which contains the implementation of the class defined in the previous section.
<pre>
!type libraryimplementation;

!implements class Laser;

class Laser: inherits llcCubePrim
{
private
colorandalpha _Color;
bool _State;
key _id;
protected
function SetPosition(vector pos)
{
llSetPos(pos);
}
public
constructor Create()
{
_id = llGetKey();
_State = false;
_Color = <0,0,0,0>;
llPrimHide();
llTargetOmega(<0,0,0>, 0, 0);
}
destructor Destroy()
{
// Nothing to do..
}

function SwitchOn()
{
_State = true;
llPrimShow();
llTargetOmega(<1,0,0>, PI, 1);
}
function SwitchOff()
{
_State = false;
llPrimHide();
llTargetOmega(<0,0,0>, 0, 0);
}

function SetColor(colorandalpha rgba)
{
_Color = rgba;
}

function GetColor(): colorandalpha
{
return _Color;
}
}
</pre>

I've use a few functions here that might not be actually existing functions, but for the sake of the simplicity of the example.. I don't know all functions yet, so i couldn't find a function for hiding and showing the prim the script is part of.
This shouls be pretty self explanatory, except at the beginning, we see the keyword !implements. This new keyword tells the scripting environment that this script implements the Laser class.
Further down this script, some people might wonder why the property Color was not present here. This is because properties are interface only. Think about it: What it there to implement on a property? A property only specifies how to read and (optionally) write the value.

== Usage ==
Now perhaps the most important part: How are we to use these classes? Well, remember the !exports keyword, which said that the class Laser was exported? We will now use that exported class in the base object.
<pre>
!type normal; // not needed, but one may specify if one wants to waste time of specifying this that are already default.. ;)

!include LaserCone.LibraryInterfaceScript;
!include LaserCone.LibraryImplementationScript;

Laser cone1, cone2;

default
{
state_entry()
{
cone1 = Laser.Create();
cone1.Color = <0,1,0,1>;
cone2 = Laser.Create();
cone2.Color = <1,0,0,1>;

state off;
}
}

state off
{
state_entry()
{
cone1.SwitchOff();
cone2.SwitchOff();
}
touch_start(integer num)
{
state on;
}
}

state on
{
state_entry()
{
cone1.SwitchOn();
cone2.SwitchOn();
llSetTimerEvent(1);
}
touch_start(integer num)
{
llSetTimerEvent(0);
state off;
}
timer()
{
float r = llFrand(1);
float g = llFrand(1);
float b = llFrand(1);
cone1.Color = <r,g,b,1>;

float r = llFrand(1);
float g = llFrand(1);
float b = llFrand(1);
cone2.Color = <r,g,b,1>;
}
}
</pre>

Well, most of this should be a piece of cake, really, except, perhaps, the lines containing the !include keyword. This keyword specifies that this this script would like to use code in a different script. In this case, I immediately went a step further than the basics, including a script which is not part of the content of the same prim, but which is inside a different prim. The prim which contains the scripts in this example is called "LaserCone" and the two scripts are called LibraryInterfaceScript and LibraryImplementationScript.
Any script from any prim in the set may be included, but only things that are actually exported can be used. In this case, the implementation script does not export anything. It only implements the interface of the Laser class. The interface script does export something: the Laser class, so the last script may use it.

In the state_entry() of the default state, we see two Laser objects are created, stored in the variables cone1 and cone2. Also their Color is set. Pure green for cone1 and pure red for cone2. The way the color is specified here is not currently possible in LSL, but i like to think about color as a 4D vector, including red, green, blue and alpha values, which makes it easier to specify color. Also, OpenGL accepts color this way through glColor4f(r, g, b, a), so it might be better, performance wise, to do it like this. Here, i mostly used it for the sake of the example. It also makes the example class a lot tighter than including a seperate alpha property and set and get methods.
Note: From this script, it is impossible to call the SetPosition function, defined in the interface of the class. This is not possible, because this function is defined in a protected visibility and this code is not part of a decendantclass, friend class, or other such code that should be able to see protected functions of the Laser class.

----
Original author: Xoren Raymaker, April 18, 2007. 
I realize this might need some tweaking, but i'm interested what your ideas, comments are about this idea of mine. It is a big thing to add to SL, but i think it could (in time) greatly enhance flexibility and features.

----
(Other) related ideas:
#[[Operator overloading]]

[[Category:Feature Requests]]

Object Oriented LSL

2007-04-18T19:10:43Z

Xoren Raymaker:

Object Oriented LSL

2007-04-18T19:01:25Z

Xoren Raymaker:

Object Oriented LSL

2007-04-18T18:45:20Z

Xoren Raymaker:

This should be straight forward: Classes in LSL.

Because it might not be clear why this is needed or how this would fit into currently existing LSL, I will try to make this clear through an example.

To keep it simple, this object has two prims, one base and one prim simulating the laser light. The laser light prim contains two scripts and the base prim contains one script, which uses code, written in the two other scripts.

== Class Declaration ==
This is the first script, containing the interface of a script library, containing the interface of a class.
<pre>
!type libraryinterface;

!exports class Laser;

class Laser: inherits llcConePrim
{
protected
function SetPosition(vector pos); override;
public
constructor Create(); override;
destructor Destroy(); override;

function SwitchOn();
function SwitchOff();

function SetColor(colorandalpha rgba); override;
function GetColor(): colorandalpha; override;

property Color: colorandalpha; read GetColor write SetColor;
}
</pre>

This script introduces a few things yet unknown in LSL, none of which are (at the time of writing) documented feature requests. First line in this script specifies that this script is of a different type than a normal script. It is in fact the interface of a script library. It knows a counterpart called a libraryimplementation, which we will find in the second script. This is done because someone who wants to use the script library, needs to know it's interface, so these interface scripts need to be viewable by other users, but you might want to protect the implementation part of the library, so hence two scripts are needed, so that one can be viewable and the other not viewable.
The next line we find, contains an !exports keyword, which says "this script exports something that should be able to be used by other scripts". In this case, it exports the class "Laser", which is defined after this.
Note: The keywords !type and !exports are both prefixed by an exclamation mark (!) because they tell something about the script itself. They could be seen as extra (optional) properties to a script.
Note2: I will not explain in depth here what everything means, i will assume therefor that the general concept and terminology of classes is known.

=== The Keyword Class ===
Now the actual subject of this feature request. The next line after the !exports keyword begins the definition of a class called "Laser". Straight into it, we also specify that it inherits from llcConePrim, which would be the base class representing all cone shaped prims. The llcConePrim itself then inherits from the basic llcPrim which would be the base class for all prims.

=== The Keyword Protected ===
Inside the class declaration, we find the keyword protected. This specifies that things defined after this keyword not available for use by all other code. Only members of the class itself, classes which inherit from this Laser class and classes which are "friends" of this Laser class, can "see" (and therefor use) the protected members declared.

=== The Member Function ===
A class would be worth almost nothing if it didn't have member functions. Not much is to be said about these. The keyword "override" that follows it's declaration means "this functions overrides the functionality of a memberfunction with the same name in the base class". Of cause this overriding can only be done if the function with this same name was defined as virtual in any of the ancestors. Besides override, there are many keywords to be invented here for use, like "reintroduce", "abstract", "overload", etc.. I think that the idea of "abstract" (pure virtual) and "overload" is clear to most people.
The keyword "reintroduce" hides any functions of the same name from the inherited classes. Lets say a class A contains a virtual function "Test" with a parameter name as a string and a class B inherits from A and also implements the function Test, but does not have any parameters. You would then use the keyword reintroduce on the function B.Test, because this one reintroduces this functionality and you would not want a user of the class to use A.Test(...)

=== The Keyword Public ===
After the protected SetPosition member function we find the keyword public. This specifies that functions and such specified after this keyword are publicly available. In other words: every bit of code can "see" the things declared after the keyword public.

=== Constructor and Destructor ===
The constructor and destructor are special memberfunctions. Every class has a constructor and destructor, but not every class needs to do anything special inside the constructor or destructor. The constructor and destructor are guaranteed to be called when an object of this class is created or destroyed. This way the object can do some initialization and finalization.

=== Class Properties ===
Near to the end, we find a line defining a so called property with the name "Color". This works almost like a variable and we will demonstrate this later. When we set the value of this property, the function SetColor will be used and when we will read out the value of the property, the function GetColor will be used to return the value.

== Class implementation ==
Here is the second script, which contains the implementation of the class defined in the previous section.
<pre>
!type libraryimplementation;

!implements class Laser;

class Laser: inherits llcCubePrim
{
private
colorandalpha _Color;
bool _State;
key _id;
protected
function SetPosition(vector pos)
{
llSetPos(pos);
}
public
constructor Create()
{
_id = llGetKey();
_State = false;
_Color = <0,0,0,0>;
llPrimHide();
llTargetOmega(<0,0,0>, 0, 0);
}
destructor Destroy()
{
// Nothing to do..
}

function SwitchOn()
{
_State = true;
llPrimShow();
llTargetOmega(<1,0,0>, PI, 1);
}
function SwitchOff()
{
_State = false;
llPrimHide();
llTargetOmega(<0,0,0>, 0, 0);
}

function SetColor(colorandalpha rgba)
{
_Color = rgba;
}

function GetColor(): colorandalpha
{
return _Color;
}
}
</pre>

I've use a few functions here that might not be actually existing functions, but for the sake of the simplicity of the example.. I don't know all functions yet, so i couldn't find a function for hiding and showing the prim the script is part of.
This shouls be pretty self explanatory, except at the beginning, we see the keyword !implements. This new keyword tells the scripting environment that this script implements the Laser class.
Further down this script, some people might wonder why the property Color was not present here. This is because properties are interface only. Think about it: What it there to implement on a property? A property only specifies how to read and (optionally) write the value.

== Usage ==
Now perhaps the most important part: How are we to use these classes? Well, remember the !exports keyword, which said that the class Laser was exported? We will now use that exported class in the base object.
<pre>
!type normal; // not needed, but one may specify if one wants to waste time of specifying this that are already default.. ;)

!include LaserCone.LibraryInterfaceScript;
!include LaserCone.LibraryImplementationScript;

Laser cone1, cone2;

default
{
state_entry()
{
cone1 = Laser.Create();
cone1.Color = <0,1,0,1>;
cone2 = Laser.Create();
cone2.Color = <1,0,0,1>;

state off;
}
}

state off
{
state_entry()
{
cone1.SwitchOff();
cone2.SwitchOff();
}
touch_start(integer num)
{
state on;
}
}

state on
{
state_entry()
{
cone1.SwitchOn();
cone2.SwitchOn();
llSetTimerEvent(1);
}
touch_start(integer num)
{
llSetTimerEvent(0);
state off;
}
timer()
{
float r = llFrand(1);
float g = llFrand(1);
float b = llFrand(1);
cone1.Color = <r,g,b,1>;

float r = llFrand(1);
float g = llFrand(1);
float b = llFrand(1);
cone2.Color = <r,g,b,1>;
}
}
</pre>

Well, most of this should be a piece of cake, really. In the state_entry() of the default state, we see two Laser objects are created, stored in the variables cone1 and cone2. Also their Color is set. Pure green for cone1 and pure red for cone2. The way the color is specified here is not currently possible in LSL, but i like to think about color as a 4D vector, including red, green, blue and alpha values, which makes it easier to specify color. Also, OpenGL accepts color this way through glColor4f(r, g, b, a), so it might be better, performance wise, to do it like this. Here, i mostly used it for the sake of the example. It also makes the example class a lot tighter than including a seperate alpha property and set and get methods.
Note: From this script, it is impossible to call the SetPosition function, defined in the interface of the class. This is not possible, because this function is defined in a protected visibility and this code is not part of a decendantclass, friend class, or other such code that should be able to see protected functions of the Laser class.

Prim and Object Hierarchy

2007-04-18T01:09:20Z

Xoren Raymaker:

''This article is a feature request''

== The problem ==

Lets say that in SL we would want to make a human skeleton. When we want to do such correctly, we need to think about the bones and how they work together. Very soon we realize that if one bone moves, the bones which are connected to it and the bones connected to them, will follow the movement. Of cause, in the real world, this is only logical, but with a computer, this is a different story. It actually needs program code to make sure that the bones of the wrist, hand and fingers move along if the arm moves.
When you think about it, you see that the upper arm depends on the movement of the shoulder; the lower arm depends on the upper arm; the wrist depends on the lower arm, etc.. Clearly, there is a relation between these bones. This relation is often referred to as child and parent.
The shoulder in this example is the parent for the upper arm. The upper arm is itself then the parent to the lower arm, which is the parent for the wrist bone.

In SL there is not such a relation between prims. It is possible to put several prims together in a set of linked prims, but if we would want to make something which needs a child-parent relation between prims, then the designer of the object needs to do this him or herself in LSL code, which is a difficult job that takes a lot of time and adds some extra code which makes the script less maintainable.

== The solution ==

The solution is probably fairly easier for the user to understand than it is to make the changes to the viewer and server. For an easy solution, a prim could receive an extra flag indicating that it acts like a bone. If this flag is set (the box is ticked), then the prim has a few extra properties. Among which are a parent prim and child prim, but both are optional. In script some extra commands would be available:

prim llGetPrimParent(prim p);
// This returns a pointer (be it a key, name or other) to the parent of the given prim.
integer llGetPrimChildCount(prim p);
// Returns the number of child prims linked to the given parent.
prim llGetPrimChild(prim p, integer n);
// Similar to llGetPrimParent(), but returns a pointer to the n'th child.
llSetPrimParent(prim child, prim parent);
// This command takes two prims and links them by way of script. This is usefull for prims that are rezzed by script.
// This sets the parent of the given child prim. Of cause it also sets the child of the given parent to the given child.
llAddPrimChild(prim child, prim parent);
llRemovePrimChild(prim child, prim parent);
// Adds or removes a given child prim to the given parent prim. This seems to do the same as llSetPrimParent,
// but there is a subtle difference. While a prim can only have one parent, it can have multiple children.
// It is true that these can be used for most of the linkage, but the first prim in a chain never has a parent and to set this,
// llSetPrimParent() is needed.
llSetJointRotation(prim p, rotation rot);
// This would set the angle between the given prim and it's parent. Thereby rotating it around the point where it meets it's parent.
llSetSkinPoseRotation(prim p, rotation rot);
// This would set a special angle value for the joint. It is called the skin pose, which is the rotation of the joint in a rest.
// One might see the skin pose as the initial rotation or a rotation where you want the joint to reset to.
llSetSkinPoseRotationAndPosition(prim p, rotation rot, vector pos, bool StretchConnectedPrims, bool MoveConnectedPrims);
// Sometimes, it might be needed to also set the position of a child prim and stretch or move other prims accordingly.
llSetSkinPose(prim p);
// This is a command travels through the entire hierarchy and resets all the joints to their skin pose.
// This should be just a bit faster than explicitly setting each joint to its skin pose from a script loop.
llSetJointOmega(prim p, vector v, float speed, float time);
// Like llSetTargetOmega(), but this one takes into account, the rotation of all the child prims.
// By keeping two different commands for this, and the parent-child relationship needing probably a lot of extra code, it is
// probably better to keep the function this one offers seperated from the existing llSetTargetOmega().

More such commands could probably be invented. This allows for easy multi axis rotation of objects like disco lights and lots of other designs which need extra flexibility. -Xoren Raymaker

[[Category:Feature Requests]]

Prim and Object Hierarchy

2007-04-18T01:06:37Z

Xoren Raymaker: