|
If you were logged in you would be able to see more operations.
|
|
|
|
Issue Links:
|
Relates
|
|
This issue Relates to:
|
|
|
SVC-701 Copyright/license/notes fields on assets, to allow proper attribution and provide license and configuration information.
|
|
|
|
 |
|
SVC-1115 General "attributes" for accounts
|
|
|
|
|
|
SVC-98
Client Script & Persistent Data Object
|
|
|
|
|
|
SVC-2508 In-world script/viewer communications
|
|
|
|
|
|
This issue is related to by:
|
|
|
SVC-674 Inventory loss if description was set to greater then 256 characters
|
|
|
|
 |
|
SVC-1394 New server rollouts (1/31) break llSetObjectDesc() / llGetObjectDesc()
|
|
|
|
|
|
MISC-907
Major Bork Bork Bork after the restarts today 31 jan 2008 in object name, description
|
|
|
|
|
|
SVC-1118
objects with descriptions set to over 127 characters by a LSL script cause the object to become unstable (affects vary)
|
|
|
|
|
|
SVC-1444
Object name and descroption limit is now too small
|
|
|
|
|
|
SVC-186
A string of over 255 Chracters stored in an Object's description field are resetting to the first 255 in certain conditions.
|
|
|
|
|
|
|
SVC-3515 Storage Objects instead of writing Notecards
|
|
|
|
|
|
|
SVC-701 Copyright/license/notes fields on assets, to allow proper attribution and provide license and configuration information.
|
|
|
|
|
|
SVC-4048 Creation of Compression and Decompression (builtin) functions for keys.
|
|
|
|
|
|
|
This is a formal request for the extended version of extensible prim attributes*, which I'm opening as "major" because the quote-fix-unquote for SVC-674 makes the issue of non-volatile script- and user- editable configuration associated with objects even more critical.
Proposed design, (originally from the Wiki):
The root prim (or any prim) of an object would have an associated list of name-value pairs. The name would be a string and the value could be a string, or alternatively it could be a simple type (string, key, integer, float, vector, or rotation). This list would be saved and restored with the prim, and a client could register its interest in specific values that would be delivered to it. This is similar to MUCK attributes, UNIX environment variables, file metadata in BeFS and later file systems, Lisp property lists, and so on. It's a powerful, efficient, and easily generalized mechanism.
LSL API
llCreateProp(string name, integer perm);
llSetPropString(string name, string value);
string llGetPropString(string name);
llSetPropStringKey(string name,key object,string value);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
string llgetPropStringKey(string name,key object);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
Permissions:
1 ANY_READ
2 ANY_WRITE
4 GROUP_READ
8 GROUP_WRITE
16 READ_PROTECT
32 WRITE_PROTECT
READ_PROTECT and WRITE_PROTECT mean that scripts outside the prim can not read or write the attribute.
This means that the default 0 permission should do the right thing in most cases.
The total amount of space available for all attributes on the root prim of an object would be limited to 1024 bytes. This 1024 bytes would include the name, the permission byte, and the value. It could be stored as the permission byte value, a nul-terminated UTF name, and the nul-terminated value, followed immediately by the next value. Two consecutive nulls (zero-length name) would terminate the list. This implementation worked well for early UNIX on machines whose CPU power and available memory was of the same magnitude as an LSL script.
*https://wiki.secondlife.com/wiki/Extensible_Prim_Attributes_from_LSL which includes a more sophisticated version of this that includes client-server communication for open-source client extensions.
|
|
Description
|
This is a formal request for the extended version of extensible prim attributes*, which I'm opening as "major" because the quote-fix-unquote for SVC-674 makes the issue of non-volatile script- and user- editable configuration associated with objects even more critical.
Proposed design, (originally from the Wiki):
The root prim (or any prim) of an object would have an associated list of name-value pairs. The name would be a string and the value could be a string, or alternatively it could be a simple type (string, key, integer, float, vector, or rotation). This list would be saved and restored with the prim, and a client could register its interest in specific values that would be delivered to it. This is similar to MUCK attributes, UNIX environment variables, file metadata in BeFS and later file systems, Lisp property lists, and so on. It's a powerful, efficient, and easily generalized mechanism.
LSL API
llCreateProp(string name, integer perm);
llSetPropString(string name, string value);
string llGetPropString(string name);
llSetPropStringKey(string name,key object,string value);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
string llgetPropStringKey(string name,key object);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
Permissions:
1 ANY_READ
2 ANY_WRITE
4 GROUP_READ
8 GROUP_WRITE
16 READ_PROTECT
32 WRITE_PROTECT
READ_PROTECT and WRITE_PROTECT mean that scripts outside the prim can not read or write the attribute.
This means that the default 0 permission should do the right thing in most cases.
The total amount of space available for all attributes on the root prim of an object would be limited to 1024 bytes. This 1024 bytes would include the name, the permission byte, and the value. It could be stored as the permission byte value, a nul-terminated UTF name, and the nul-terminated value, followed immediately by the next value. Two consecutive nulls (zero-length name) would terminate the list. This implementation worked well for early UNIX on machines whose CPU power and available memory was of the same magnitude as an LSL script.
* https://wiki.secondlife.com/wiki/Extensible_Prim_Attributes_from_LSL which includes a more sophisticated version of this that includes client-server communication for open-source client extensions. |
Show » |
made changes - 01/Feb/08 08:52 AM
| Field |
Original Value |
New Value |
|
Link
|
|
This issue is related to by SVC-674
[ SVC-674
]
|
made changes - 01/Feb/08 08:52 AM
|
Link
|
|
This issue is related to by SVC-701
[ SVC-701
]
|
made changes - 01/Feb/08 08:55 AM
|
Link
|
|
This issue is related to by MISC-907
[ MISC-907
]
|
made changes - 01/Feb/08 08:56 AM
|
Link
|
|
This issue is related to by SVC-186
[ SVC-186
]
|
made changes - 01/Feb/08 08:56 AM
|
Link
|
|
This issue is related to by SVC-1118
[ SVC-1118
]
|
made changes - 01/Feb/08 08:59 AM
|
Link
|
|
This issue Relates to SVC-701
[ SVC-701
]
|
made changes - 01/Feb/08 08:59 AM
|
Link
|
|
This issue Relates to SVC-1115
[ SVC-1115
]
|
made changes - 01/Feb/08 09:00 AM
|
Link
|
|
This issue is related to by SVC-1394
[ SVC-1394
]
|
made changes - 01/Feb/08 09:02 AM
|
Description
|
This is a formal request for the extended version of extensible prim attributes*, which I'm opening a "major" because the quote-fix-unquote for SVC-674 makes the issue of non-volatile script- and user- editable configuration associated with objects even more critical.
Proposed design, from the Wiki:
The root prim of an object would have an associates list of name-value pairs. The name would be a string and the value could be a string, or alternatively it could be a simple type (string, key, integer, float, vector, or rotation). This list would be saved and restored with the prim, and a client could register its interest in specific values that would be delivered to it. This is similar to MUCK attributes, UNIX environment variables, file metadata in BeFS and later file systems, Lisp property lists, and so on. It's a powerfule, efficient, and easily generalised mechanism.
LSL API
llCreateProp(string name, integer perm);
llSetPropString(string name, string value);
string llGetPropString(string name);
llSetPropStringKey(string name,key object,string value);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
string llgetPropStringKey(string name,key object);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
Permissions:
1 ANY_READ
2 ANY_WRITE
4 GROUP_READ
8 GROUP_WRITE
16 READ_PROTECT
32 WRITE_PROTECT
READ_PROTECT and WRITE_PROTECT mean that scripts outside the prim can not read or write the attribute.
This means that the default 0 permission should DTRT in most cases.
The total amount of space available for all attributes on the root prim of an object would be limited to 1024 bytes. This 1024 bytes would include the name, the permission byte, and the value. It could be stored as the permission byte value, a nul-terminated UTF name, and the nul-terminated value, followed immediately by the next value. Two consecutive nulls (zero-length name) would terminate the list. This implementation worked well for early UNIX on machines whose CPU power and available memory was of the same magnitude as an LSL script.
*https://wiki.secondlife.com/wiki/Extensible_Prim_Attributes_from_LSL which includes a more sophisticated version of this that includes client-server communication for open-source client extensions.
|
This is a formal request for the extended version of extensible prim attributes*, which I'm opening a "major" because the quote-fix-unquote for SVC-674 makes the issue of non-volatile script- and user- editable configuration associated with objects even more critical.
Proposed design, from the Wiki:
The root prim of an object would have an associated list of name-value pairs. The name would be a string and the value could be a string, or alternatively it could be a simple type (string, key, integer, float, vector, or rotation). This list would be saved and restored with the prim, and a client could register its interest in specific values that would be delivered to it. This is similar to MUCK attributes, UNIX environment variables, file metadata in BeFS and later file systems, Lisp property lists, and so on. It's a powerful, efficient, and easily generalized mechanism.
LSL API
llCreateProp(string name, integer perm);
llSetPropString(string name, string value);
string llGetPropString(string name);
llSetPropStringKey(string name,key object,string value);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
string llgetPropStringKey(string name,key object);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
Permissions:
1 ANY_READ
2 ANY_WRITE
4 GROUP_READ
8 GROUP_WRITE
16 READ_PROTECT
32 WRITE_PROTECT
READ_PROTECT and WRITE_PROTECT mean that scripts outside the prim can not read or write the attribute.
This means that the default 0 permission should do the right thing in most cases.
The total amount of space available for all attributes on the root prim of an object would be limited to 1024 bytes. This 1024 bytes would include the name, the permission byte, and the value. It could be stored as the permission byte value, a nul-terminated UTF name, and the nul-terminated value, followed immediately by the next value. Two consecutive nulls (zero-length name) would terminate the list. This implementation worked well for early UNIX on machines whose CPU power and available memory was of the same magnitude as an LSL script.
*https://wiki.secondlife.com/wiki/Extensible_Prim_Attributes_from_LSL which includes a more sophisticated version of this that includes client-server communication for open-source client extensions.
|
made changes - 01/Feb/08 09:03 AM
|
Description
|
This is a formal request for the extended version of extensible prim attributes*, which I'm opening a "major" because the quote-fix-unquote for SVC-674 makes the issue of non-volatile script- and user- editable configuration associated with objects even more critical.
Proposed design, from the Wiki:
The root prim of an object would have an associated list of name-value pairs. The name would be a string and the value could be a string, or alternatively it could be a simple type (string, key, integer, float, vector, or rotation). This list would be saved and restored with the prim, and a client could register its interest in specific values that would be delivered to it. This is similar to MUCK attributes, UNIX environment variables, file metadata in BeFS and later file systems, Lisp property lists, and so on. It's a powerful, efficient, and easily generalized mechanism.
LSL API
llCreateProp(string name, integer perm);
llSetPropString(string name, string value);
string llGetPropString(string name);
llSetPropStringKey(string name,key object,string value);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
string llgetPropStringKey(string name,key object);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
Permissions:
1 ANY_READ
2 ANY_WRITE
4 GROUP_READ
8 GROUP_WRITE
16 READ_PROTECT
32 WRITE_PROTECT
READ_PROTECT and WRITE_PROTECT mean that scripts outside the prim can not read or write the attribute.
This means that the default 0 permission should do the right thing in most cases.
The total amount of space available for all attributes on the root prim of an object would be limited to 1024 bytes. This 1024 bytes would include the name, the permission byte, and the value. It could be stored as the permission byte value, a nul-terminated UTF name, and the nul-terminated value, followed immediately by the next value. Two consecutive nulls (zero-length name) would terminate the list. This implementation worked well for early UNIX on machines whose CPU power and available memory was of the same magnitude as an LSL script.
*https://wiki.secondlife.com/wiki/Extensible_Prim_Attributes_from_LSL which includes a more sophisticated version of this that includes client-server communication for open-source client extensions.
|
This is a formal request for the extended version of extensible prim attributes*, which I'm opening as "major" because the quote-fix-unquote for SVC-674 makes the issue of non-volatile script- and user- editable configuration associated with objects even more critical.
Proposed design, from the Wiki:
The root prim of an object would have an associated list of name-value pairs. The name would be a string and the value could be a string, or alternatively it could be a simple type (string, key, integer, float, vector, or rotation). This list would be saved and restored with the prim, and a client could register its interest in specific values that would be delivered to it. This is similar to MUCK attributes, UNIX environment variables, file metadata in BeFS and later file systems, Lisp property lists, and so on. It's a powerful, efficient, and easily generalized mechanism.
LSL API
llCreateProp(string name, integer perm);
llSetPropString(string name, string value);
string llGetPropString(string name);
llSetPropStringKey(string name,key object,string value);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
string llgetPropStringKey(string name,key object);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
Permissions:
1 ANY_READ
2 ANY_WRITE
4 GROUP_READ
8 GROUP_WRITE
16 READ_PROTECT
32 WRITE_PROTECT
READ_PROTECT and WRITE_PROTECT mean that scripts outside the prim can not read or write the attribute.
This means that the default 0 permission should do the right thing in most cases.
The total amount of space available for all attributes on the root prim of an object would be limited to 1024 bytes. This 1024 bytes would include the name, the permission byte, and the value. It could be stored as the permission byte value, a nul-terminated UTF name, and the nul-terminated value, followed immediately by the next value. Two consecutive nulls (zero-length name) would terminate the list. This implementation worked well for early UNIX on machines whose CPU power and available memory was of the same magnitude as an LSL script.
*https://wiki.secondlife.com/wiki/Extensible_Prim_Attributes_from_LSL which includes a more sophisticated version of this that includes client-server communication for open-source client extensions.
|
made changes - 05/Feb/08 06:33 AM
|
Link
|
|
This issue is related to by SVC-1444
[ SVC-1444
]
|
made changes - 08/Jun/08 11:46 AM
|
Link
|
|
This issue Relates to SVC-2508
[ SVC-2508
]
|
made changes - 13/Nov/08 12:04 PM
|
Workflow
|
jira-2007-12-22a
[ 51677
]
|
jira-2008-11-14
[ 80653
]
|
made changes - 13/Nov/08 04:29 PM
|
Workflow
|
jira-2008-11-14
[ 80653
]
|
jira-2008-11-14a
[ 86702
]
|
made changes - 13/Nov/08 04:45 PM
|
Workflow
|
jira-2008-11-14
[ 86702
]
|
jira-2008-11-14a
[ 91781
]
|
made changes - 13/Nov/08 04:55 PM
|
Workflow
|
jira-2008-11-14
[ 91781
]
|
jira-2008-11-14a
[ 95280
]
|
made changes - 11/Dec/08 10:55 PM
|
Link
|
|
This issue is related to by SVC-3515
[ SVC-3515
]
|
made changes - 28/Mar/09 11:43 AM
|
Link
|
|
This issue is related to by SVC-4048
[ SVC-4048
]
|
made changes - 20/May/09 05:38 AM
|
Description
|
This is a formal request for the extended version of extensible prim attributes*, which I'm opening as "major" because the quote-fix-unquote for SVC-674 makes the issue of non-volatile script- and user- editable configuration associated with objects even more critical.
Proposed design, from the Wiki:
The root prim of an object would have an associated list of name-value pairs. The name would be a string and the value could be a string, or alternatively it could be a simple type (string, key, integer, float, vector, or rotation). This list would be saved and restored with the prim, and a client could register its interest in specific values that would be delivered to it. This is similar to MUCK attributes, UNIX environment variables, file metadata in BeFS and later file systems, Lisp property lists, and so on. It's a powerful, efficient, and easily generalized mechanism.
LSL API
llCreateProp(string name, integer perm);
llSetPropString(string name, string value);
string llGetPropString(string name);
llSetPropStringKey(string name,key object,string value);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
string llgetPropStringKey(string name,key object);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
Permissions:
1 ANY_READ
2 ANY_WRITE
4 GROUP_READ
8 GROUP_WRITE
16 READ_PROTECT
32 WRITE_PROTECT
READ_PROTECT and WRITE_PROTECT mean that scripts outside the prim can not read or write the attribute.
This means that the default 0 permission should do the right thing in most cases.
The total amount of space available for all attributes on the root prim of an object would be limited to 1024 bytes. This 1024 bytes would include the name, the permission byte, and the value. It could be stored as the permission byte value, a nul-terminated UTF name, and the nul-terminated value, followed immediately by the next value. Two consecutive nulls (zero-length name) would terminate the list. This implementation worked well for early UNIX on machines whose CPU power and available memory was of the same magnitude as an LSL script.
*https://wiki.secondlife.com/wiki/Extensible_Prim_Attributes_from_LSL which includes a more sophisticated version of this that includes client-server communication for open-source client extensions.
|
This is a formal request for the extended version of extensible prim attributes*, which I'm opening as "major" because the quote-fix-unquote for SVC-674 makes the issue of non-volatile script- and user- editable configuration associated with objects even more critical.
Proposed design, (originally from the Wiki):
The root prim (or any prim) of an object would have an associated list of name-value pairs. The name would be a string and the value could be a string, or alternatively it could be a simple type (string, key, integer, float, vector, or rotation). This list would be saved and restored with the prim, and a client could register its interest in specific values that would be delivered to it. This is similar to MUCK attributes, UNIX environment variables, file metadata in BeFS and later file systems, Lisp property lists, and so on. It's a powerful, efficient, and easily generalized mechanism.
LSL API
llCreateProp(string name, integer perm);
llSetPropString(string name, string value);
string llGetPropString(string name);
llSetPropStringKey(string name,key object,string value);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
string llgetPropStringKey(string name,key object);
// key must be an object in the same sim, and the object must be owned by the script owner or have appropriate permissions
Permissions:
1 ANY_READ
2 ANY_WRITE
4 GROUP_READ
8 GROUP_WRITE
16 READ_PROTECT
32 WRITE_PROTECT
READ_PROTECT and WRITE_PROTECT mean that scripts outside the prim can not read or write the attribute.
This means that the default 0 permission should do the right thing in most cases.
The total amount of space available for all attributes on the root prim of an object would be limited to 1024 bytes. This 1024 bytes would include the name, the permission byte, and the value. It could be stored as the permission byte value, a nul-terminated UTF name, and the nul-terminated value, followed immediately by the next value. Two consecutive nulls (zero-length name) would terminate the list. This implementation worked well for early UNIX on machines whose CPU power and available memory was of the same magnitude as an LSL script.
*https://wiki.secondlife.com/wiki/Extensible_Prim_Attributes_from_LSL which includes a more sophisticated version of this that includes client-server communication for open-source client extensions.
|
made changes - 13/Jun/09 08:26 PM
|
Link
|
|
This issue Relates to SVC-98
[ SVC-98
]
|
made changes - 11/Aug/09 12:08 PM
|
Link
|
|
This issue is related to by MISC-3077
[ MISC-3077
]
|
made changes - 13/Aug/09 05:03 PM
|
Link
|
This issue is related to by MISC-3077
[ MISC-3077
]
|
|
|
New Feature
