|
|
|
[
Permlink
| « Hide
]
Qarl Linden added a comment - 22/Jun/07 11:19 AM
and for an example usage - wouldn't it be cool if residents could apply their own grass texture to the prim grass? daisies or whatnot? (or wheat? heh.)
proposed implementation details:
datablock to have a 18 byte payload: 2-byte type identifier (with a corresponding registration table, so uses don't overlap.) Imported this feature request into the Linden internal JIRA.
Go ahead and comment on Qarl's proposed implementation, but hurry – I think he's gonna code this up soon. I don't think it's general enough.
I would really like to see a general key-value attribute scheme for objects in SL. Virtually every one of its precursors - text-based virtual worlds like MUDs and MUCKs - have a mechanism to attach name-value attributes to objects. The datablock would be a permission byte and two text strings, and would only be sent to the viewer if the viewer requests attributes with matching strings. Scripts would be able to read and write the strings in their own prim and in detected prims. The permission byte would be composed of the following bits: 1 ANY_READ 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. Since it would only be sent for attributes the viewer requests, the bandwidth overhead would be minimal. This would solve so much else. There are so many OTHER places in SL where programs are forced to hide information in prim parameters or in live script data that gets lost on a reset that could be included in prim attributes. If this is going to be done, let it be done once. Qarl your proposal sounds perfect, my vote is to implement the extra 18 byte payload, but make sure it is sent as another block in the ObjectUpdate* family of packets and does not need an additional packet request like the description field.
Argent - heh. yes, that does sound nice - but i'm looking for something that is easily implementable and won't require 10 months of internal negotiation. (bureaucracy sucks.)
Eddy - i BELIEVE that's how extra-prim-params are implemented. but i don't have the code open right now.
Gigs - ah, NICE. yes, very similar, almost exactly the same.
my only comment is that the payload must be MUCH smaller and of fixed size. (size is now enforced on the simulator.) an LSL interface to the raw data is a good idea... but what should the API look like? can't use a string - you might legitimately want nulls in the data. a list of integers? hm. The 2+16 scheme sounds like a good start. (If bandwidth and storage weren't an issue, I'd love to see named key-value pairs a la HTML tag attributes. I dream of <prim type="torus" revolutions="3.0" my-custom-var="foo" />... and cascading prim styles... yummy. But I'm getting ahead of myself.)
Qarl: can you expand on your thoughts re: cases where it might be desirable to have nulls in the data? I need help seeing what you're seeing. P.S. Thoughts on adding a new prim type which has many "extra" prim parameter slots, but no standard parameters? It would allow for testing the case where there are multiple parameters which combine in effect; testing each one individually wouldn't ensure that they work with each other correctly. (I'm thinking for example of the standard prim attributes, where each attribute controls one aspect of the final shape.) oh, the ability to extend the grass and trees would rock my world
 I love the idea of an extensibility mechanism for prims! However, I think it would be even better if there was no need to maintain a centralized registry of 2-byte parameter identifiers.
To that end, I would suggest that instead of a 2-byte identifier, there be at least a 4-byte identifier, or even just add 2 16-byte fields; one for a UUID for the field identifier and one for the data field. UUIDs have a great advantage that they can be independently generated while still avoiding collisions, but even a 32-bit identifier would help (analagous to how scripts share a 32-bit space for channel numebers already). I know the ObjectUpdate (and related) messages are already rather large, but I think at least the additional 2-byte hit to have at least a 4-byte identifier would be worthwhile. Also, I definitely agree with Eddy that the extra prim parameter should be included in the ObjectUpdate message, and not something that has to be requested asynchronously. Jacek - regarding NULLs - when you use 3 bytes to encode a color, and you want to use black <0,0,0>.
Able - WAY too big of a payload for a UUID. the biggest extra-prim-parameter payload we currently have is 16 bytes, TOTAL. additional 2 bytes doesn't really buy us anything as we'd still need a registry... but perhaps. let me discuss over here. (honestly, if i had to choose, i'd ask for the 2 bytes as additional parameters - that way you can have 1 UUID and 2 byte parameters...) Correction: The biggest extra-prim-parameter is sculptie information at 17 bytes (UUID + type). Unless you are counting particle system data which is huge but also implemented differently. Anyways if this does go through it might be a good idea to elect the first byte as a type identifier and if people plan on using this, collaborate together on a wiki to reserve identifier numbers for different projects.
Qarl, for a larger extensible API, it doesn't matter what the data is. Just give us something like 512 bytes variable with a two byte address and a two byte length tag and we'll add our own "application level" stuff on top of those.
sigh
Permanent non-volatile object attributes has been part of virtually EVERY "adventure" or "multi-user dungeon" environment since MDL in the '70s. It's something that LS really needs. Ah well. For this: LSL interface: make it a set of primitive parameters: PRIM_ATTRIBUTE_BINARY,integer id,string data The id is in the range -1 to 65535: -1: conversion error... the attribute can't be represented as the requested type. The data part of the result is undefined. 0-65535: the two-byte ID of the attribute. Otherwise: the two-byte ID PRIM_ATTRIBUTE_BINARY would return or expect a URL-encoded string. URLencoding is pretty bloaty, couldn't we use base64?
I don't see any problem using any particular encoding. Make it "PRIM_ATTRIBUTE_BINARY would return or expect an encoded string (eg, base64 or URL-encoded)."
We already have place we're not using, such as the UUID key spacers.
Normal sculptie: "a822ff2b-ff02-461d-b45d-dcd10a2de0c2" Scultie flagged for modified clients not to be affected by LOD: "a822ff2b+ff02-461d-b45d-dcd10a2de0c2" (a - is now a +) Sculptie flagged for modified client to use the otherwise wasted pixels for animation displacement maps, as well as the no-LOD trick too: "a822ff2b-ff02+461d-b45d-dcd10a2de0c2" (another - is a +) Sculptie flagged for using all pixels as vertex for a plane sculpt map (x4 regular), in a modified client: "a822ff2b#ff02-461d-b45d-dcd10a2de0c2" (first - is a #) Of course it would require LL to actually accept characters other than - in keys... Also my favorite trick: Konan the barbarian has 7 healing potions, 3 genocide scrolls, a leather armor and a doomsword of doom: it is stored as a flexi type paremeters, but the prim that stores that info is not flexi so the prim is not deformed or anything. Pro: easy. Stable. Con: player may cheat if data is not somehow encrypted and has some kind of validity check. Many client plugins/mods could coexist like that and be compatible provided they keep track of other existing plugins/mods thru a wikipage. As for elaborate game data, you can make a script use a free DNS service such as http://www.everydns.com CR - we don't actually store/transmit those characters. a UUID is 128 bits, and every one is useful.
Getting off topic...
Qarl: Back in the days of old, the client included in the UI the ability to modify (and make) plants (trees and grass); course you couldn't do anything with it. Their individual description takes up something like 300 bytes each. Plants I suspect were always intended to be one of the transferable assets but there was never much push to have them like there was for animations. This project was probably rolled into the SpeedTree and put on permanent hold. Quarl, instead of 2 bytes and 16bytes. Hw about 2 fields of 16 bytes? The first would actually be a key for identifying the extension, and the second being the data as already planned. You really never know how many 3rd party extensions might crop up. UUIDs are very easy to generate, and for this purpose, a database of the extension keys doesn't need to be maintained, it would be the responsibility of the extension makers to not reuse the same extension keys. As keys probably use a timebase as at least part of their generation. I don't think it's likely that duplicate keys would ever be generated.
Additionally, the extension data should be both writeable AND readable with ll(Set/Get)[Link]PrimitiveParamaters and readable with llGetObjectDetails. Allowing objects to This layout would lend it self to permanant datastorage as well extensions, and be more easily extended in the future for more robust extension systems. Could this be added to avatars, and their profiles as well? Separately?One to extend the avatars, one to extend the profiles. Obviously not changeable by script, but still readable by llGetObjectDetails. Though, i would like to see much larger persistent data/prim parameters than that, i also realize the reason why not to do as such. As a side note, anyone REALLY needing more persistent data, could store a notecard key as the data, and retrieve a notecard as their extra data. Thus solving most data needs. Even if you do have to make an extra request. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
create new "extra prim parameter" type for open-source (outside LL) use.
