Jump to content

Jenna Felton

  • Posts

  • Joined

  • Last visited

Everything posted by Jenna Felton

  1. Cathy Foil wrote: Those making and selling animations will want to clearly label their animations as "Rotations Only", "Rotations and Translations" or "Translations Only"... I think that is a good suggestion. But I think also mesh head creators will have to classify their mesh by what sort of expressions the mesh will accept. Because the customer buying the mesh head will rarely understand why the particular expression will not work with the mesh, but they can learn that some expressions will go and some not. They must not even understand what a rotation and what a translation is, but when they know this mesh fails on expressions using translation than they know which expressions the customer can look at and which are not worth of spending time for looking at the demos for them. Also, when the mesh head or fullbody uses the expression override (be it the suggestion of polysail or LL implements the feature request for it) this must be explained too, since that is a big plus in having predefined best looking expressions (since made by the mesh creator themselves) and probably simple to use new expressions made by third party. However, there will be a load of new information falling on the head of the to the mesh wearer and I think they have to be prepared for it. So I think there must be an explaining post somewhere targeting the customers and explaining that there is a slides vs. expressions problem, that some expressions can not work on some meshes, what an expression override is (if there will be a ready to use solution) and probably a simple to understand video about what translations and rotations are, how they affect the mesh and why some mesh can not accept translations in expressions. A bold request, sorry, but I myself am not good enough to make an easy to understand explaination and having deep understanding of the topics technically. Cathy Foil wrote: I probably am not explaining my self well enough. The program that is setup to use your web cam watches your face for expression and when it recognizes an expression say like when you smile it recognizes that you are smiling and sends a signal to the viewer you are logged in with to play a pre-recorded smile animation. So it wouldn't matter how big your smile was in real life it simply play the animation named "Smile". This can be done by expression overrider (assumed it is available.) The web cam program will just start recognized expressions and they will run overriding animations. Needs a service that sends signals from the clinent computer to the LL server running the agent. Can be done by LL or probably the web service which the expression hud worn by the avatar offers and client web cam program is registered into.
  2. This is getting very long already and every time I have time to read the thread gets 10 new pages But I am glad how it is going on, and that there are debates, since it schows the topic is so important, and I am glad Bento team is stil waiting with release before all issues are resolved. The rest of the post can be pointless, as I am neither an avatar designer not animator (although I have an intension to make my very own full bento mesh body myself some day) so you can ignore the folowing when it is pointless. However, when I read the debates about sliders vs. expressions, I get a feeling the goal is to have sliders and expressions in the same extend the default avatar shape allows. And I beleive there is a mistake in this.At least in theory. There are exactly two default meshes, a male and a female mesh. They are changed by the shape sliders or animations. Some sliders morph the shape but I think it is irrelevant as we want emulate morps via bones. But the point is, the default avatar mesh is only one of two meshes that every one uses and changes via sliders and animations. Everyone has one of them. While there will be legions of avatar designers and each of them will create dozens of different mesh bodies. Now, when we want change all the mesh bodies via sliders and animations/expressions in the same range the default avatar mesh allows, than I beleive we get into a situation that you can take a mesh body (or head) from designer A, replace skn and use the shape sliders and you get the look of mesh body from designer B. When it happens, the mesh bodies will become replaceable. And then you can think what happens. People will take cheaper bodies when they look like the more expensive. Prices will fall probably down to dollaraby level. Or DMCA reports will snowing. Neither of them I'd like to see. Expressions are good. Sliders are good also. But I think shape sliders should change the mesh only slightly, just to make the mesh unique but the mesh must stil stay recognizeable. And when the range the sliders change the mesh is limited, perhaps the expressions will stil work well on them and not destroy the mesh? I think when it is possible this way, the goal must be limited on that. I am not sure if the mesh format allows to restrict the range of sliders and animations.When it can not, I think there is stil a simple way for the mesh creators to restrict the sliders. Put a notecard with the mesh listing the bounds of every relevant slider. There is such a notecard with the mesh body I wear and mesh head I wear and I have no problem in following the instructions. Animators will have to get the same information from the mesh designer in same or other possible way. Just some thoughs I got by reading the next 10 pages
  3. Thank you (Bento team) very much for opening Bento to the Agni, expected it soon but not so soon that is cool. And for updating the skeleton files. However,there is a problem, or better to say stil, because I noticed it since long time. When I import the .dae files (mesh + skeleton) into Blender, I see the skeleton broken. Some bones are minimized and their head tips do not catch the tail tips of their child bones in the line. You can see it by comparing the leg lines with hind lines:  The same problem I have when I import into Blender 2.75 and into Blender 2.77a. Is there a way to import it in an unbroken way or do I have to corect this manually? It seems not too hard, although I am not sure if I can do it without a mistake.
  4. Hello DS, response to you, althought it would be one for the whole human avatar subproject. That looks cool, yes, I played with the Manuellab addon a little, the customization is really good, very many options and it looks as if Manuel took a long study about body types, shapes, and this makes me respect that work. And when i look at the hands and feet, that is a dream of hands, really. Well, body needs more complexity at some places and there are number of places that are way too complex, like eyebrows or wimpers, eyeballs or teeth, they use much too much vertices for SL. However, apparently Manuel will make a simplier version, or the mesh designer could simplify the body themselves. I am really support the idea of a resident-driven standard of human and humanoid avatars so the avatar and clothing designers can work together very much like the legacy avatar mesh designer (that is LL) worked together with the legacy clothing designers (that were the system layer clothing) That would improve SL very much if it would be possible. But, I thnk the part about open source avatar based on Manuellab, needs really a separate thread, which I'd suggest Gaia opens herself and posts a link here. I am sure there would be interest to talk about the standard, implementations and everyting else around it, but that topic tangents the Bento topic only and is not a part of the Bento topic. Hope it not sounds rude, was just an idea. Something around the idea of resident-driven hummanoid avatar standard. It must not remain by a hummanoid one only. I am not sure at the moment, but perhaps Bennto could birth a few other standards, for horses, pets, animals, dragons and more. Which could be handled in similar way, standarticed open source mesh that avatar designers could adapt on their own needs while the accessory for the final avatars would be similarly useable on all of the avatars based on that standard one. Perhaps its too early to talk about it yet.
  5. Not sure if this is too late to add bones, but I was just talking with a friend about hair cuts and then it came up, that you could make changeable hair styles when there was bones for hair in the skeleton. I think 2 or 3 chains of 3 bones parented to mSkull would allow to get dynamic hair and change hair style. At least 2 chains for tails left and right, one of them or both you can use for ponytail. It needs be different bones than used for (for example) wings or face because you want probably wear hair to the wings or mesh head. Just an idea. I am not an avatar designer, so this suggestion needs being verified by those who mesh avatars and/or hair.
  6. Thank you Code for liking the contribution I added the "[bENTO]" prefix to the Jira name. I was not sure at the time of wriging if i should. The post does address an issue that is there since mesh avatars and not just since bento, and it is also scripting issue. But bento has the ability to solve it. So I decided to add the prefix thank you for reminding on it. Edit: Managed to miss the meeting, forgot about the daylight saving time... When no one brought up the topic today, LL has more time to reply
  7. Something that doesn't seem to have been covered in this thread is how Bento will affect existing content. This is true, I realized that too, after reading this thread. The idea of polysailis also good and it has a good chance to be implemented, I think, when LL not accepts your idea about extending animation override. However, I dared to think about it, as i am also a scripter rather than mesher or builder and to post a feature request for it: Animation Override for built-in animations. I extended it to all built-in animations because not only facial expressions are affected, but also hand poses may be and, if there any, also animations that use morphs on other parts than face or hands. I also added a second way to implement this parallel to the llSetAnimationOverride because although we also want override avatar animations but it may be something different internally. But I hope it will be to do as easy as copy the llSetAO code and paste into new functions Tomorrow is a Simulator User Group where it is a good place to discuss the idea and what way is better to go.When i manage to come there and there will be time I'd bring it to discussion. However, either way it will be going, I'd suggest to open a new page in the wiki, similarly to the one for RLV protocoll for maintaining the communication protocol (when the polysail solution will it be), the both scripts (avatar part script + expression API script for the furniture etc.) and selection of the expressions/poses to override. I think such a protocol / standardized access to custom expressions is a necessarity, otherwise a Bento avatar is not complete.
  8. Thank you for your Answer Nalates Yes thats corect, waiting 24 or even 48 hours (two days) is generally a good idea. Also it is important to log in to the beta grid with the SL viewer (and not with SL Beta viewer despite the name) as first. The second login can be with any viewer. This worked for me as i had once the problem that the Aditi session was not stored somehow. Yes, as far i was also told, the inventory on Aditi is managed by weaker hardware than the inventory on Agni. This was the main reason why i started the tread. Now after i was thinking more, i beleive the idea of packaging stuff was correct. As far as i know there are shared asset servers that are keeping the content of the assets, for example content of notecards or the pictures. The inventory itself is than just like an index telling who has what assets in their inventory. Which is simply a large list of names and asset keys organized in folders like the content page in a book. Due the inventory transfer Agni to Aditi only this content is tranferred, not the files themselves (they are stil on the shared asset servers.) Also the smaller this index is, the less work should the inventory database have. Hence, when i package, say, all the furniture i have into a box, than only this box is in my inventory and takes only a single entry in my inventory database. The inventory transfer brings only this entry to Aditi. Now when i rez the package box on ground than this box comes from the shared asset server. And as long i dont unpack it into my inventory (on Aditi), nothing goes to the inventory server. This means, the idea to rezz all the package boxes and pick them up after the inventory transfer can work but has little benefits. When i do it, than the box of furnitures does not go to my Aditi inventory. But i can leave this box in my inventory, too, let the tranfer routine bring it to Aditi, and as long i do not unpack it, my Aditi inventory has just a single entry for this box and that probably does not hurt. 10,000 items per folder is a crazy number I think i have just a few folders with one or two thousands items, for unorganized objects and landmarks, but i am working on them: when i open that folder i get a huge scrolling problem. I suppose a folder with 10,000 items would bring the viewer to a real winter-sleep once i open it.
  9. Good evening I know there is a routine that exports all our inventory from Agni (main grid) to Aditi (beta grid). To initiate this routine all you need is change your password. The question is, is there a way to organize my inventory in order the export routine has less to work or also in order the inventory servers on Aditi can work with the inventory on Aditi easier? An example to make the question some more concrete: When I package all my stuff in boxes (you know, by rezing a prim, putting there my stuff, take the boxes and removing the stuff from my inventory) than i have on the first view less items in my inventory, but the packaged stuff is a part of the boxes that are in my inventory, it is still present and available somehow. Now when i change my password, the export routine brings the boxes to Aditi. Now when i rez the boxes i should be able to take the exported stuff out of the boxes. Hence, the packaged stuff was still exported to Aditi. Why i am asking this, there is plenty of stuff i need on main grid but don't need on beta grid. For example most clothes, landmarks and notecards, skins and shapes, furniture, vehicles etc. That are more than 20.000 items i do not need on Aditi but they would make a load on the Aditi inventory servers when exported. My first idea was to package all the stuff into boxes, than change password. But I guess, the export routine will still bring all the stuff to Aditi. When so, than probably the only way to avoid the full export will be to rez the boxes somewhere for 2 days and remove them from my inventory and after export pick up the boxes again. Is this correct, or does packaging the stuff into boxes still a good idea for the Aditi inventory servers, even if the boxes are exported with the content, so i could leave the package boxes in my inventory before i change my password? Best regards, Jenna
  10. The avatar you want check the ping must have a RLV-enabled viewer and possibly an active relay. Unless you implement that check by a device and give them the device, than the device can communicate with the viewer directly without a relay. But their viewer must understand the RLV commands. Your viewer must not be RLV-capable. This is an interesting idea actually to implmement such a thing and test on myself how much the ping value calculated this way differs from the ping value shown in the statistics bar. If i get time i'll try that
  11. Principally it seems to be possible to test how good is a connection of the avatar and how good is the avatar's machine by using a RLV-enable viewer. RLV has a number of commands awaiting a response from the viewer. For example a "@version=channel" command. The protocol is this: A scrip in avatars object (e.g.) relay opens a chat listen on a channel, e,g, 222, than issues a command llOwnerSay("@version=222"); This is a message sent by script directly to the viewer using by the avatar.The string "@version=222" is thus passed over the server - viewer connection and is delayed in respect of the connection speed. The viewer receives the message and understands as command to reply the viewer's version on the channel 222 (if the viewer supports RLV, if not it just displays the message.) The response again is sent over the viewer - server connection and is the faster the better the connection is. The script in the scripted device receives the message and calculates the "ping" value. However, in most cases you have a device that is owned by you and not by the avatar. In that case there will be also a step 0, when your device sends a RLV Relay message towards the relay worn by the avatar, This message is a command to request viewer's version and this will make an additional delay by script - script connection. From the step 1 on, there will be three delays until you receive the viewr's response, those in steps 2 and 4 are caused by the viewr - server connection and are as bad as the ping of the avatar's machine. The delay in step 3 is caused by the machine itself and determine how fast the machine is but can also hapen because of the virus scan program and similar loads at the moment. So with this technique you can quess the avatar's ping but not measure an exact value, but principlly it is possible. PS. Two links about that RLV version checking command RLV Relay specification
  12. Hi Eden I think it is because RLV is something not everyone who uses SL needs in the viewer. If you sail mostly or even only, you not need RLV. And if creators tools come alive you not need RLV for gridwide teleporting. So RLV is a partial solution used by part of residents. The SL viewer needs only stuff every SL resident uses mostly. So the current solution is to have the official SL viewer and the third party viewers implement the RLV. This solution works actually good. Perhaps the better solution would be modular viewers when the SL viewer offrs a framework for plug-ins (one for inventory, one for world map and so on)and you as user simply install the plug-in you need, like it is done by Eclipse. Than RLV would be simply a plug-in to install. This solution needs plently of work i think, though.
  13. The Problem Some residents do experience inventory problems last times when the inventory in Aditi, especially after password change (made to update the Aditi inventory) breaks. And I also read from indirect sources that the inventory on Aditi is on smaller hardware so there are needs to cull out data that are not used. As I understood the asset index for Agni and Aditi are in separate databases while asset server has the files on disc (notecards, LMs textures, objects and so on) and every asset index just links the files for avatar and object inventories. This makes it easy to look up the inventory: Loading index is faster than the files. But you have than to maintain both asset indexes for Agni and Aditi. You must keep them in sync, for example by copying the Agni inventory (the asset indexes) into Aditi inventory so you have an updated inventory there. This also wastes resources because you have to maintain two index databases with almost equal data, the one for Agni and one for Aditi, while for many residents that data are even not used (the residents not went to beta grid yet or went and left for good.) And the question is now how to cull out the unused database indexes. I have a suggestion to solve that problem which bases on two principles: Don’t use redundant indexesHandle the beta inventory as joint of the inventory in Agni and items added in beta grid. How to do that: In the first step flush out the avatars inventory in beta grid except for items created or acquired in beta grid. When the viewer in Aditi requests inventory from the server, the server passes the request over to the Agni inventory server. The result is then extended by items and folders the user added in Agni by creating the folders, notecards, objects picked fromworld etc. So you always see the full inventory and everything you own in Aditi or agni. You see them here automatically, without needs to copy everything from Agni to Aditi first. Now, if the user tries to perform an operation on inventory that affects the Agni inventory, and the operation would remove or alter the items (can you alter an item without making a copy?) than the operation is rejected with an error message. For example You are in Aditi and want to give out an item that is in your Agni inventory and is no copy. This would remove the item from Agni inventory – fail.You have selected an item in inventory and hit delete button, but you are in Aditi and the item is in Agni – fail.You open a notecard that is in your Agni inventory, edit and save it – accept. The new copy of the edited notecard is now in your Aditi inventory. If you go to Agni, and open this notecard, you still see the old text.You are in Aditi and rezz an object from inventory, or put this object into another object rezzed inworld. The object is in your Agni inventory and is copy. Ok, the new copy of this object is created and is in your Aditi inventory if you pick up the object fromworld.You are in Aditi and upload a mesh or image or sound etc. That all lands in your Aditi inventory which is in fact an extension of the Aditi inventory. You are free to rezz the mesh or use the notecard etc. If you go to Agni, you will not find the item in the place it is in Aditi.You are wearing a clothing layer or attachment, and this is in your Agni inventory and no copy. Because you have read access, the viewer can wear or attach it with no problems.You can also modify the item, the changes are saved in your instance of the item in Aditi, the changes are not passed over to Agni.This way you have always a read-only access to your current Agni inventory from Aditi and must not change password in order your inventory updates. And the server load of the Aditi inventory is minimal, so you not need to cull out anything. Actually you need only to change the servers (I hope) and add a new error message, or even extend existing error notification by new text, i.e. I hope by now this suggestion doesn’t affect the viewers at all. But i would to go farther and extend also the viewer. I’d like to see the properties of inventory items extended by a new grid field telling if this is an item in Aditi or Agni inventory, so you can see if you have full access to the item or the read-only and you must not await the error message if you was wrong. This field the viewer has to display than at some way. Possibly even more: “this item is in Agni inventory”, “this item is a modified copy of an item in Agni inventory” and “this item was acquired in Aditi”. If you go to Agni, the viewer displays only the first possibility. Limits This design doesn’t support deleting Agni inventory from Aditi login. Sometimes it is necessary. For example most Agni landmarks don’t work in Aditi and your favorites list is full in Agni, and you want it to list way other landmarks in Aditi. Although you can put some favorite landmarks in the favorites list also in Aditi, but have than troubles to find them under the amount of not working landmarks. The solutions of that are filtering and hiding, which needs more altering of the viewer. Filtering means you can set the viewer to filter folders and types of inventory items that are only in Agni inventory, so you don’t see them in Aditi. The filtering should be a separate setting for each folder and inventory type, so you can filter out all Agni landmarks or those in favorites list but nothing else. Hiding means you explicitly hide an item or a folder from being shown in Aditi. This way you can refine the hiding criteria. The disadvantage of that design is further, that by hiding or filtering inventory parts you create data for inventory index and can potentially make relatively much of them so the benefit of incremental inventory design looses. For this reason I’d suggest to support filtering by grid property for every inventory item (this setting doesn’t increases with inventory), but restrict individual filtering and hiding only to the top-level folders and system folders (that are top-level actually) and their direct content. The subfolders and their content should be no more individual filter- and hide able. That's all. Hope it willl give some constructire ideas, or start a usefull discussion. Greetings Jenna
  14. I have the sae theory like Freya A default script that you always create by clicking "New script" in contents tab of the build floater is telling "Touched" in local chat if touching the object. The script is called "New script", eventually with a number appended to it (if the prim has nother item called new script" and is always edit-able for the one who created it. The content should look like in this page: Hello Avatar The script does not interract with other scripts and since created accidentally should not harm others if deleted. If you can't see such a script, than the reason is possibly an other.
  15. Yes Darien, and thanks for replay. Yes, the script looses permissions if copied out of inworld object and if copied with object copied inworld. But it retains permissions if the object is taken into inventory and copied there. And i am pretty unhappy with the fact that once granted permisions can not be taken back, unless the owner of the object holding the script makes some mistake like resetting the script. The owner of the object gained avatar permissions can use the permissions in another means than the grant was intended to, and the victim can do nothing about it, or at leas i not know any way to, say revoke animation permission given to a griefing object pretended to be a hug attachment . However, i may be wrong. I see there is a message for revoking permissions if the script is on the sim, as far i can understand the definition. Edit: To be honest, i can't figure out how this message works and even it this message is sent when you decline a permission request, or really to revoke a permission granted once. My indirect informations state, this message is sent to revoke permission granted to a script available on the sim but not to a script in an attachment.If so, returning to the sim to revoke teleport permission seems not a good idea for me, since the griefing teleporter may send you out on sight before you take it the ability to do so. I've also not found a button allowing revoking permisions in Firestorm viewer. The only place dealing with permissions i found is Privacy tab in Firestorm settings. Permissions being revoked this are just two, animation and taking control, as far i can read on the help page. Especialy for dangerous permissions like debit or teleport this is an issue.But also animation permissions can be used for grief. This proopsal was a try to give a possible answer to the issue. I tried to keep the overhead low, so a permanent traffic for every script action is not a good idea. This made the complete design very complex.
  16. 9. Status interface a) Permission confirmation floater (temporary) If a script connects to the status storage, due the sync protocol, and the storage is missing the status for the script runtime permissions, a floater is prompted that is similar to the permission request but is 1) telling what permission the script has already, and 2) allows to confirm the permissions or revoke them. In the shown example we rezzed a dance machine, which has already the animation permission, but the status for the permission is missing in the status storage. Now we can confirm the permission, revoke it, mute the device as usual. Because there will be many such floaters, we can here check the check box and the decision taken now will be auto-applied to all following confirmation requests. The floater is temporary, it is fading out because there will be probably a quite number of such confirmations, especially if we cleaned out the status storage. The floater toast could collect the floaters and display the number of floaters not confirmed yet, so we can reopen the floaters at later point. b) Run-time permissions floater Here is the legend of the icons and also the view to open lists: This floater demonstrates the interface to the status storage or storages. The floater presents a list of permissions granted to objects, i.e. the scripts inside. Each script requested permanent permissions produces an entry for an object, as it produces a permission item which is registered by a status storage. The entries can be filtered by the name of the object and it's owner, as well by the granted permissions and their status. The displayed legend presents the filters and explains the used symbols. Entries passed the filters are displayed page wise, since 3218 permission entries is not a unrealistic number, even if not every permission request produces an entry. The list dislays the objects requested and granted run-time permissions, with Object name and name of the object owner, The region where the object requested the permissions. Revealing the current position of foreign object would be a privacy flaw, so for unowned inworld objects the position should be hidden. Attachments have no current position, The permissions holding by the object are shown by icons, if a script holds more than one permission, the entry for the script displays multiple icons. The status icon is clickable, if clicked a floater is shown with a possibility to set the permission status, i.e. revoke or re-grant the permissions. The last column 'last used' displays when the script into the object used the given permission and what permission was used. If one object is selected and the entry shows the object position, we can teleport there by clicking a button. If at least one object is selected we can delete the selected entries (not the objects) or change the permission status for them. The 'last used' column is a very nice to have feature, but perhaps not so easy to implement. It may require a permanent data stream from the script to the status storage. In return this allows to identify a griefer who used a script permission given to the griefer's gadget months ago. The list displays some teleporting devices (TP Relay, Pingpong Teleporter, Personal Teleporter), animation devices (Dance Machine, Hug&Kiss attachments), a radar working on links, two vendors with access to the avatar's money, and a RC device holding a permissions set. You can see, the dance machine still has unconfirmed animation permission, the permission floater was just ignored. You can also see how a grief was defeated: The Pingpong Teleporter gained the teleport permission but after we broke out of the grief, we just open the floater and revoke the teleporter the TP permission. At same point or earlier we revoked also the animation permission to the strange named ring device belonging the same griefer. Here we are at the end of the proposal. I put it on discussion so we can find out if this idea can be implemented and must be implemented at all. LG, Jenna
  17. 7. Sync protocol Via status interface, the user can change status of every permission item holding permissions granted to a script before. The sync protocol ensures that the status storage provides the new status of a permission item to the script as soon as possible. The protocol avoids generating too much traffic; it uses only asynchronous events that are sent on demand. a) If the script is available while the permission status is changed via status interface, an event is sent to the script immediately. If the new state is 'revoked' and the old state was 'granted' or 'unconfirmed' (which both means the script is granted permissions) than a revocation event is sent to the script. The script looses the permissions by receiving the event. If the new state is 'granted' or 'unconfirmed' and the old state was 'revoked' (which means the script had no permissions granted) than a regranting event is sent, due this the script stores the permission item holding the permissions bitfield. b) If the script was not available at time of changing permission status, than only the new status is saved in the status storage. c) As soon the script and the status storage become available to each other, for example while the script is in an attachment and the script owner is logging on, than the script connects to the status storage and requests status for the held permission item. If the status is 'revoked', a revocation event is sent to the script with the same effect of script loosing the held permissions. d) If a script recycles a permission item from the cache, the script sends a status request to the status storage and names the UUID of the recycled permission item. If its status is 'revoked', the status storage also sends a revocation event to the script. 8. Revocation messages If a script was revoked a permission, this may also affect another person than the agent revoked the previously given permission. In this case an instant message should be sent to the affected agent. a) If a script given say an avatar permission (e.g. animation permission) by an agent who is not owner of the script, and the agent revoked this permission, the owner of the script should be informed that the avatar actions are no more possible. b) If the CHANGE_LINKS property permission was revoked, there is no affected avatar, so no messages must be sent. c) If the DEBIT property permission was revoked, this can broke content potentially, because the debit action is used often to split money or to implement affiliate vending systems. Revoking this permission can create fraud affiliate vendors if the script relies on non-revocability of the DEBIT permission. In this case, as soon a script tries to give money and the debit permission was revoked, the recipient of the money should receive an instant message telling the money transfer was aborted because of missing permission. This way the creator could ban the fraud affiliate from the vending network for instance.
  18. 5. Status storage Status storage is an instance keeping states of permission items. The storage allows to manage the script permissions without access to the script, so script permissions can be revoked even if the script is not available. The status storage must be instanced in an appropriate place, for example kept by the user agent if the avatar permission is handled, or the sim agent if the property permission is handled. The connection between the script and status storage must be fast and short, as well the connection between the status storage and the status interface (of the viewer.) The status storage binds more data to the permission item than the script created and stored the item: The permission item on the storage side holds also the UUID of the holding script, object, and the object's owner, as well also the region where the permissions were granted to the script. I can imagine a few scenarios where to hold the status storage. a) Global status storage The simplest variant uses a global server holding all permission states. The scripts and viewers can find it easily, but we have a tight bottleneck here, even if we synchronize status due initialization of the script only and not in real-time, all scripts access the same place. Also the way is far for the data between viewer and status server and between the status server and the script VM. b) Outsourcing avatar permissions Because avatar actions make no sense without target avatar being available on the sim, we can separate the permissions in two parts: The pure avatar permissions, e.g. TRIGGER_ANIMATION|TELEPORT, will be handled by status storage attached to the user agent of the target avatar. The pure property permissions, like DEBIT, and mixed permissions like TRIGGER_ANIMATION|CHANGE_LINKS will be handled by the global status storage server. In this case, the permission item in the script may need the reference to what status storage is handling it's permission status. This way the viewer would always able to access the status storages, either the one attached to the user agent (pure avatar permission) or the global status storage. A teleporter device will synchronize the permission status as soon the avatar becomes available on the sim, and hence teleport-able. A vendor or device working on linksets will load the permission status from the global server accessible instantly. The bottleneck is relieved, but not eliminated: The property permissions will need access to global status server and this may generate huge traffic on a single point, even if the hits are only generated while rezzing an object with script requesting the status. c) Outsourcing all permissions Here we eliminate also the global status storage: The pure avatar permissions, e.g. TRIGGER_ANIMATION|TELEPORT, will be handled by status storage attached to the user agent of the target avatar. The pure property permissions, like DEBIT, and mixed permissions like TRIGGER_ANIMATION|CHANGE_LINKS will be handled by the status storage attached to the sim agent of the sim where the script was rezzed last time. To implement this the permission item in the script should definitely keep track about what status storage handles the permission status. If the script holding property or mixed permissions is moved to another sim, the status storages of the sim agents will have to move the status information, too. This way we eliminate the bottleneck: The scripts access the right status storage easily and on a short way, also the status interface in the viewer will have access to all (pure) avatar permissions granted before, as they are handled by the status storage sticked to the user agent. Access to the mixed and pure property permissions is only possible for objects on the sim the avatar is currently, which is insufficient. Imagine a bugged device requested and granted the CHANGE_LINKS|TELEPORT permission. As it is mixed, you would not be able to revoke the permission without return to the sim, and once there the device would send you out on sight. To enlarge the range for mixed and property permissions, the viewer could store references to status storages of, say, 16 last sim agents. This way you can access and change states of script permissions remotely, without needing to visit the target sim. Also connected regions like in a continent or estate could connect the status storages of each sim, than you can teleport to a sim in the continent and manage the status of permissions granted to an object everywhere on this continent. d) Splitting mixed permissions If the states for avatar and property permissions are handled by different storages, as suggested above, it may make sense to split mixed permissions into avatar and property permissions. The permission item in the script refers than both storage servers, one for avatar permissions and one for property permissions. Both storage servers may synchronize the permission states if needed and possible. This way the viewer has a direct access to the status storage for avatar properties (it is sticked to the user agent), and the scripts an access to the status storage for property permissions (sticked to the sim agent), even if the user agent is not available. This way a device can not take the avatar permission like animation or teleport out of reach from the viewer just by making the permission mixed. 6. States of permission items On the script side, a permission item has two states: Either it exists, the script is holding a permission item (actively, not in cache,) than the script is granted permissions bound to the item, or the permission item doesn't exist (or it is just cached but not held actively), than the script is not granted any permissions. For the status storage, the permission item has three states: Granted, revoked and unconfirmed. a) Granted permission state. In this state is a permission item if saved into the status storage if the script has generated the item (the user accepted requested permission.) Say a script working in a kiss hud requested the animation permission which was granted. The script generated the permission item (if recycling was not possible) and it was stored inside the script and the user's status storage. b) Revoked permission state. In this state a permission item is in the status storage, when the user decided to revoke the script’s run-time permission. Say the owner of the kiss hud decides to grief the user by starting of nasty animations. Traditionally, the user has no other way to stop that but fill the abuse report. Now, the user opens the status interface which connects to the status storage. There, the user finds the hud animating them and changes the state of the permission from granted to revoked. The sync protocol ensures that the animation script into the kiss hud is notified as soon as possible and looses the animation permission. c) Unconfirmed permission state. It is possible, that the status storage saves not every permission item: Permissions granted before the revocation system is established, will generate new permission items by first script action but those permission items will be not in the status storage, Status storage may remove items that are not used for long time, unter assumption the objects holding the scripts are temporally or removed meanwhile, The user may remove obsolete permission items to keep the list clean. If a script executes an action due holding permission item allowing the action, but the permission item is not in the permission storage, this item is saved into the permission storage but with unconfirmed state. The user receives a message, that a script is executing an action which was allowed before but this action is not confirmed. The message may be shown by a floater, which is fading out after a while. The user is now able to... To accept the action, than the permission item changes the state to granted. To decline the action, than the permission item becomes the revoked state and the revocation event is sent. Or to ignore the floater allowing the action to continue. At later point the user can find the new permission item in the status storage interface and change the permission state correctly. d) Temporally granted permissions Sat unowned objects may give the permissions TAKE_CONTROLS, TRIGGER_ANIMATION, TRACK_CAMERA and CONTROL_CAMERA automatically to the sitting agent. This permissions are given temporary, after standing up they are lifted. Hence the permission items generated temporally for the sitting period must not be stored into the stats storage and managed by the status interface for instance. The same applies to other possible cases where permissions are granted temporally to scripts.
  19. 3. Permission item In order we can revoke a given permission, we have to clearly identify it. This identification goes deeper than per object and per script: An object can hold different permissions via scripts inside, as well every copy of the same script (with same UUID) can hold another permission. To do so, we bind permissions given to a script (a bitfield of permissions to be exactly) to a permission item. This item will have an unique UUID and store the bound permissions bitfield. The permission item is only generated by the script as soon the requested permissions are granted. There is no other way to create the permission item. Declined request will not generate the item. Also, not every accepted permissions request will generate a permission item, and in some cases even an already created item can be reused, 'recycled' so to say. In some cases the permission is given temporary resulting in a short-living permission item managed very locally. As soon generated, the permission item will be stored into the script and the status storage(s). Now the script has an efficient way to check what permissions it hold, and the user granted the permission has a way to revoke it by changing the status of the permission item. For implementation reasons you can divide the permissions and actions allowed by them in two classes: The avatar actions are actions affecting the avatar, the avatar permissions are TAKE_CONTROLS, TRIGGER_ANIMATION, ATTACH, TRACK_CAMERA, CONTROL_CAMERA and TELEPORT. The property actions are actions affecting the user’s property and are allowed by property permissions DEBIT and CHANGE_LINKS. The avatar actions require the affected avatar to be available (online and on the sim) while the property actions do not require the avatar granted the permission (i.e. the script owner) to be available or even online. 4. Recycling of the permission items A disadvantage of permission items is that they generate an UUID which is to be managed by the whole SL infrastructure. Generating an item for every granted or auto-granted permission request will create a new permission item and waste resources even if used temporally. The recycling technique avoids this by reusing already created permission items. Generally said, if we have to create a permission item and we have already another permission item created for the same parameters (avatar granted permissions and the permission bitfield) so we would not tell the new item from the existing one, we reuse the existing permissions item instead of creating the new. Here are a few examples how we do this: a) Copying of the script with granted permissions If a script grants a permission, say to animate an avatar, and then copied by copying the holding object, every copy of the script holds a copy of the permission item, i.e. every copy of the permission item will have the same UUID and bind the same permissions. This is similar to traditional definition: If a script holding run-time permission is copied by copying the holding object, every copy of the script will hold the same permissions. The difference is now, that by revoking the (animation) permission of one object will revoke the permission for every copy of that object, since all copies share the same permission item. This is a new behavior, but since the revocation system is new, the existing content is not corrupted at this point. b) Repeatedly requested permissions If a script holding some run-time permissions, requests permissions again, the already created permission item may be re-used, if all this are true: The requested permissions are granted, The avatar being requested and having granted the permissions is the same of the existing permission item, The requested permissions are the same of the permissions bound to existing permission item. This way a script (for instance animation machines or poseballs) requesting the permissions repeatedly without checking if the permissions are already granted eventually, will not produce a bunch of permission items while only one of them is sufficient. c) Permission cache If a script holding the permission item has to remove it or to generate another one, say because The avatar granted the permission to actual permission item but declined the new request, Or because other permissions were requested and granted (but the avatar is the same) Or because another avatar was requested and accepted the permissions. Than the actual permision item is not removed but stored in a limited cache (for example of 64 items.) As soon an avatar is requested permissions and the new permission item to create would exactly match (avatar and permission bitfield is the same) the item in the cache, than the item from the permission cache is restored instead of creating a new item. This way for example a multiuser animation script would not produce a lot of permission items because a group of avatars use it sequentially.
  20. Hello Well, this post will quite long so i better split it in a few. Also i am not sure where to post ths proposal, as it affects the SL infrastructure, hence the servers, but also the viewer. Choosen the SL Servers category, as this part is more affected. The current system of run-time script permissions is (apparently) build of a bitfield storing locally into a script giving the run-time permissions granted to the script (if not, the suggestion will be probably not obsolete, but the suggested components would need a maping to the implemented.) However, this solution is very efficient on run-time since to perform an action, the script has simply to read in the locally saved permissions bitfield if a permission to run this action is granted to the script or not. But this solution makes it hard to give a resident a way to revoke permission given to a script at least if the script is temporally not available, e.g. taken into inventory or if the script owner gone offline. 1. The challenge The problems we are facing if making the run-time script permissions revocable: To make script run-time permissions revocable instantly, you have to store the granted permissions in a place not bound to the script, so you can revoke the script permissions even if the script is not available at time.The permission storage must be also available if the avatar granted the permission is not available, so the script is able to check if it is allowed to access to the money of the avatar for instance.By outsourcing the permissions out of the script, we create a traffic between the script and the permission storage every time an action, say animation of the avatar has to be started, and this is very often the case.The data volume of the permission storage will be extremely high, as every avatar could have granted a quite large amount of animation permissions (sitting on furniture, vehicles, and kiss&hug huds produce such a grant.) This proposal gives a possible way to allow an instant revocability of run-time script permissions with less management overhead and data load. 2. Abstract overwiew The permissions revokability system is roughly based on few things A permission item is an unique object holding permissions granted to the script. The permission item is stored in place of the permissions bitfield and represent the runtime permissions held by the script.A status storage maintains the status of the permission items and thus the run-time permissions granted to the script related to this item. The status tells if the permission is granted or revoked.A status interface is a floater in the viewer, with a direct access to the status storage. The floater allows to identify and revoke every permission the user ever grated to scripts, regardless if the scripts are available or not.The sync protocol between scripts and the status storage allows to revoke run-time permissions at the point the script to revoke permissions becomes available. The protocol uses ...... the revocation event sent by the status storage towards the script (holding the permission item) with an effect of revoking permissions given to the script.The revocation message is again sent by the script (or possibly the status storage) to an agent affected by revoking the script permission.
  21. Hello SinfulPrince I am not sure if you've seen this, but you ask about instruction with screenshots. For me, the best information about how to configure clothings give the both tutorials made by Marine herelf. The tutorials have also screenshoots so that seems to be what you look for: Part 1 Part 2 However, the instructions are long.Also depends on what viewer she uses, she may have to activate the shared folders feature (#RLV folder for clothing) in the viewer first in order others can access the folder's content. What she can also do is, and i take it as best way, she can take some device accessing the shared folder for example the OpenCollar (which costs npthing) or the RR collar (Steel collar or RR Elegance) and get access to the item as master or owner. Than she can configure her shared folders and see the effect in the menus herself, and also see how the itms are looking for you (if you are in the dom role) Hope that helps Jenna
  22. Nods @Misti RLV affects way more then just the 'kinky' community.... RLV allows for example to redress avatar like in RL - you see what you'll wear, watch the video to this warderobe please: RLV Wardrobe. Or forcing teleport without needs to open map or chat history (although i'm awaiting the technology of Linden Realms, where it might be also possible without RLV) There are applications for RLV far aside of BDSM, even in PG sector, and i'm glad this inventory issue affecting #RLV folder was really a bug and not a feature. Thanks for correcting that.
  • Create New...