Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

status enquiry for 16 LSL functions
Angel Fluffy
Very Helpful
Join date: 3 Mar 2006
Posts: 810
07-19-2006 16:54
Do LL have any plans to implement :

1) llIsInGroupRole(key avatarkey, string groupname, string rolename);
* returns 1 if avatar is a member of group "groupname" and is in role "rolename". Rolename can be "Owner", "Everyone", or any other valid group role name. Using this call with 'Everyone' or '*' as the rolename should just check if the avatar is in that group.
* returns 0 otherwise.
This function would vastly improve the compatibility between groups and scripting, for the simple reason that it'd make checks on groups both convenient to the person being checked (and in SL, with users, convenience is half the battle)... and also undodgable (think security systems that can ban by group). Robin Linden has already posted that bans by group ARE on LL's to-do list, and just as bans are LSL-scriptable, so should bans by group be.

2) llName2Key(string avatarname);
Put simply, it would be much more efficient to have a call for doing this in LSL than it is to have to use 3rd party websites to do so. Security systems, for example, often use keys to ban people - which is fine if the 3rd party database sites have their key, but useless on newly-created 'just signed up today' alts.

3) Ban-management functions enabling LSL scripts owned by avatars with permission to add to, delete from and list both parcel-level and estate-level bans. "ll" + ("AddTo"||"DelFrom"||"List";) + ("Land" || "Estate";) + "BanList".

4) Increasing the maximum number of people a sensor can detect... up from 16 to about, say, 64? Would result in less need for multiple sensors, link scripts, etc.

5) A function llGetPrimsOnLand(key ownerkey); - which returns the total prims that owner 'ownerkey' is using on your land. Great for enforcing prim count limits in conjunction with...

6) LSL calls to return object :
llReturnObject(key object); - returns a single object with a given key
llReturnObjectByOwner(key owner); - returns all objects on parcel owned by given owner key. This could be very useful for managing prim counts, especially

7) Reliable storage - either via writing to notecards (I know it's hard, but so many people want it...) or via some sort of *sql database system (even better as many scripts in different objects/sims can access the same database).

8) Give scripts the ability to send and recieve instant messages between each other, in a way that can't be intercepted by other scripts. This would eliminate a lot of laggy listeners, and a lot of communications/encryption scripts.

9) Includes, either from another script or from a notecard.

10) Events which get raised when the object is pushed, or the avatar to which the object is attached takes damage. E.g. pushed(vector impulse, vector rotational, key pusher)

11) Switch/case statements in LSL scripts.

12) Find/Replace in scripts (and notecards too, for that matter).

13) Allowing group-owned objects to give inventory, send IMs, etc just as normal objects do.

14) Functions to allow LSL scripts to fetch the price of the parcel under a specific x/y co-ordinate, and to set the parcel price and 'for sale' box of land owned by the object owner. Would require a PERMISSION_SELLINGLAND to avoid people tricking mainland land owners into rezzing such an object and then stealing their land. With groups, objects deeded by the group founder should automatically get this permission.

15) llGiveInventory return/event - to know if the person accepted your inventory offer.

16) llSetObjectPrice.

There are a lot of good ideas in this topic, however the poster, Aaron Linden, has since left the company it seems (Last Activity: 09-30-2003 07:52 PM). If you could outline which features you plan to add to LSL, it would be nice.
I know the Lindens are very busy, which is why I'm asking this - I figure if you devote your time to giving residents a more powerful LSL, we can write scripts to do a lot of the other things we really want done in SL.

Could you please let us know :
*) for each proposed LSL function/feature above, if you plan to implement it, and, if so, in what sort of timeframe?
*) if people should continue posting in this topic, or just wait for the status of their requests thus far to be announced. It'd be helpful for them to know this, and it'd help keep up Resident morale.
_____________________
Volunteer Portal (FAQs!) : https://wiki.secondlife.com/wiki/Volunteer_Portal

JIRA / Issue Tracker : http://jira.secondlife.com (& http://tinyurl.com/2jropp)
Torley Linden
Enlightenment!
Join date: 15 Sep 2004
Posts: 16,530
07-20-2006 11:28
Asking about this...
_____________________
Kelly Linden
Linden Developer
Join date: 29 Mar 2004
Posts: 896
07-20-2006 12:32
I know you asked for time frames, but really I only know a couple possible time frame statuses: Currently in development, planned, not yet planned. None of them really give a good indication of WHEN it will be released. Even ones that are in development could be released after some not yet planned. Sorry.

Do LL have any plans to implement :

1) llIsInGroupRole(key avatarkey, string groupname, string rolename);
* returns 1 if avatar is a member of group "groupname" and is in role "rolename". Rolename can be "Owner", "Everyone", or any other valid group role name. Using this call with 'Everyone' or '*' as the rolename should just check if the avatar is in that group.
* returns 0 otherwise.
This function would vastly improve the compatibility between groups and scripting, for the simple reason that it'd make checks on groups both convenient to the person being checked (and in SL, with users, convenience is half the battle)... and also undodgable (think security systems that can ban by group). Robin Linden has already posted that bans by group ARE on LL's to-do list, and just as bans are LSL-scriptable, so should bans by group be.

This is not currently in development. There are some issues with this. It is probably not desireable that just *any* object be able to tell all your group statuses. We can't assign roles to an object, so we can't really follow the 'samegroup' route for roles. I have thought about, but not really investigated, adding a few powers like 'LSL Power1', 'LSL Power2' etc. Then giving and lsl call like 'llHasPowerInMyGroup(power_x)' that would allow scripts in that group to query those powers. This would in a fashion enable custom powers. Part of the problem with this is adding the customizable name and description fields that would be needed to keep these types of powers understandable. These ideas are currently just that - ideas. They aren't in development or planned, and will definitely not be in 1.12's initial release. Really, if the feature isn't already in 1.12 it is very unlikely to get added at this point.


2) llName2Key(string avatarname);
Put simply, it would be much more efficient to have a call for doing this in LSL than it is to have to use 3rd party websites to do so. Security systems, for example, often use keys to ban people - which is fine if the 3rd party database sites have their key, but useless on newly-created 'just signed up today' alts.

I want it. It is in my personal list of lsl functions I want, (which is a sublist of the big list) and it is also somewhere else in the list. It is not in development.

3) Ban-management functions enabling LSL scripts owned by avatars with permission to add to, delete from and list both parcel-level and estate-level bans. "ll" + ("AddTo"||"DelFrom"||"List";) + ("Land" || "Estate";) + "BanList".

Planned, but to my knowledge not actually in development yet, but maybe soon?

4) Increasing the maximum number of people a sensor can detect... up from 16 to about, say, 64? Would result in less need for multiple sensors, link scripts, etc.

Not planned. Everytime a scan is done a snapshot of all the data getable with llDetected* functions is saved. This is not an insignificant amount of data unfortunately. Must also account for queued events which may have similar data attached. The 16 limit is done to limit how much memory this takes up. It seems more likely that methods to access other objects or data directly could be added. For example functions to get a list of agent ids for agents on a parcel or in a sim, and then the specific functions needed to get data about that agent - not at the time of the 'sensor' but when the library method is called.

5) A function llGetPrimsOnLand(key ownerkey); - which returns the total prims that owner 'ownerkey' is using on your land. Great for enforcing prim count limits in conjunction with...

I know this has been requested, however I do not think it is currently planned. It shouldn't be that hard, so I can add it to the list if it isn't there already. However, that doesn't mean it is planned still.

6) LSL calls to return object :
llReturnObject(key object); - returns a single object with a given key
llReturnObjectByOwner(key owner); - returns all objects on parcel owned by given owner key. This could be very useful for managing prim counts, especially

Often requested, not yet planned. As in no one is working on it, and I don't think it is explicitly slated to be worked on.

7) Reliable storage - either via writing to notecards (I know it's hard, but so many people want it...) or via some sort of *sql database system (even better as many scripts in different objects/sims can access the same database).

I think something in between is planned, and maybe in progress. I don't have details at this time.

8) Give scripts the ability to send and recieve instant messages between each other, in a way that can't be intercepted by other scripts. This would eliminate a lot of laggy listeners, and a lot of communications/encryption scripts.

There are lots of ideas around this. Some have been started, only to have their developer resources shifted elsewhere. The solution for (7) may resolve some of the cases for using this, but maybe not all.

9) Includes, either from another script or from a notecard.

I want this. It is not planned or designed. Almost definitely not to happen prior to mono integration - which may just take care of it.

10) Events which get raised when the object is pushed, or the avatar to which the object is attached takes damage. E.g. pushed(vector impulse, vector rotational, key pusher)

Not yet planned.

11) Switch/case statements in LSL scripts.

Again, probably not until mono. We don't really want to spend a lot of development time at this point working on core syntax for LSL2 (the current LSL) when many of these issues will be resolved with mono or made much easier to resolve, or at the very least implementing them now would just cause more headaches later on because of the move to mono.

12) Find/Replace in scripts (and notecards too, for that matter).

This was added a (very) short while ago. Some 1.10 release I think. It is live now, under the Edit menu of a script.

13) Allowing group-owned objects to give inventory, send IMs, etc just as normal objects do.

This needs to be re-evalutated, but it is not currently planned. Part of the problem is accountability for such actions, and back end data needs to be updated to better track such information as 'last owned by' etc.

14) Functions to allow LSL scripts to fetch the price of the parcel under a specific x/y co-ordinate, and to set the parcel price and 'for sale' box of land owned by the object owner. Would require a PERMISSION_SELLINGLAND to avoid people tricking mainland land owners into rezzing such an object and then stealing their land. With groups, objects deeded by the group founder should automatically get this permission.

I am extremely reluctant even for the GET functionality of this. There has been issues in the past with 'land scanners', and implementing such features would likely bring them back. The summary is just that scanning for data like this is not very good with LSL - it lags the script system because it is gernerally a constantly running process and usually distributed over a large number of our simulators. This type of data is something that is much more suited to external means of data collection. Those means are not yet implemented.

15) llGiveInventory return/event - to know if the person accepted your inventory offer.

Yes, wanted. Not trivial. Alternatively we have considered transaction functions to improve this path in lsl vendors. For exmaple llSellInventory(key buyer, list inventory, integer price) which would offer the specified inventory to buyer at the specified price. The transaction would be atomic - the money only collected if the inventory given and visa versa. This seems much better than the current two part process, even if a return or success event was available. I don't have any time frame other than that this is a wanted feature.

16) llSetObjectPrice.

I implemented this once. It introduced a lot edge cases and scamming potential and was pulled after a short stint in preview. I know of no plans currently to bring it back.

There are a lot of good ideas in this topic, however the poster, Aaron Linden, has since left the company it seems (Last Activity: 09-30-2003 07:52 PM). If you could outline which features you plan to add to LSL, it would be nice.
I know the Lindens are very busy, which is why I'm asking this - I figure if you devote your time to giving residents a more powerful LSL, we can write scripts to do a lot of the other things we really want done in SL.

Could you please let us know :
*) for each proposed LSL function/feature above, if you plan to implement it, and, if so, in what sort of timeframe?
*) if people should continue posting in this topic, or just wait for the status of their requests thus far to be announced. It'd be helpful for them to know this, and it'd help keep up Resident morale.

I havn't reviewed that thread (by Aaron) in a while although I should do so again. It is probably time to remove that thread (after 2 years!) and start fresh. Many ideas in there have been implemented and some no longer make sense. I do support improvements to lsl, I started my SL career very focused on LSL even before I was employed by LL. I try to add features to it when I can, and I'm not the only one. However it does tend to take a back seat to most other things a lot and we rarely have projects specifically to add to lsl. The recent llHTTPRequest and the future mono integration are big exceptions.
_____________________
- Kelly Linden