AND THIS IS A NO-GO.
After much talking, thinking, trial and error and technical difficulties, I have decided NOT to introduce IM commands at all. As a reminder, I wanted to make the viewer execute commands received through object IMs as well as llOwnerSays, provided the object that sends IMs to you passes some very tight tests such as "its group must the same as the parcel you are on", or "its owner must be in your friends list and must be able to map you".
Well the main reason of my step back is that many people are concerned with upcoming unsolicited @version=nnnn IMs from objects that they don't even know, eventually leading them to leave public BDSM areas because of the spam. Truth is, there is no way that I know of to check whether you're using my viewer or not, except by actually asking you with that very message and adapting to the answer or lack thereof. So the reason is social.
Technically I had to adapt too, because when receiving task IMs the viewer does not have a clue about the actual UUID of the object that sent the IM. Presumably because that object could be in another sim, and not even the root prim of its link set. I don't really know why we don't get that UUID but at least we have the owner of the object, along with its position and region, so that would have been possible.
So instead of relying on IMs coming directly from cages, the user will have to wear an attachment to "relay" chat messages from the cage (or furniture, let's not forget furniture designers) to the avatar through llOwnerSay like before. That attachment would decide to relay commands by checking the object against rules very much like the ones I have been describing in pseudocode in my previous post. So basically, what I wanted to do in the viewer will be done in a script instead, which is a sane approach if you ask me.
To be honest I am not totally decided yet. But we're making progress here, and I would like to thank you all for your precious comments and discussions in-world, special thanks going to Chorazin Allen for his very detailed concerns (and also his Relay mockup) and Ariel Moonsoo for commenting here. People who know me well know how difficult it is to convince me of something, 'cause I am more stubborn than a donkey and twice as slow* :)
Marine
(* The first one who can tell me where that line comes from and who said it, receives a full shibari set for free, or something else of the same value if they already have it ^_^)
Subscribe to:
Post Comments (Atom)
Posts
29 comments:
I've been thinking about the spam issue, and I wish to propose an alternate method for an object to communicate to the viewer that it is aware of the viewer's existence, and wishes to provide additional functionality to users utilizing the viewer.
The way I propose to perform this communication is for the object to have a description ending in a string similar to '@RLversion'. (I chose to have it end, as the compatibility is the least important part of the object's description from a user prospective.) This would also allow the viewer to filter this element out from all objects that the user can't edit, so that they won't know if something is Restrained Life enabled or not. (I don't suggest performing this filtering on objects the user can edit, as it could make it more difficult for content creators to use the viewer to create their products.)
If the viewer detects such an object, and it meets the conditions that were debated in the previous post, it will respond with '@version=nnnn' on a 'high' numbered channel. This channel could either be a pre-defined channel (I'd suggest at least 10000), a channel specified by the object (making the ending string similar to '@RLversion=nnnn', where nnnn is the non-zero channel number), or by hashing on some portion of the object's UUID (such as the last 4 hexdecimal characters) and and adding a constant (such as 0xFFFF).
I can see a couple ways of handling this detection. One way is to examine the description of all objects that enter chat range, and respond appropriately on detection.
A second, more nuanced way, is to perform the detection checks only on collision or when an object is sat on. Collision in this circumstance would be defined as bumping into, standing on, or passing through an object. (passing through implying that the object is phantom).
--Ariel Moonsoo
Hello I am eagerly awating the RR Viewer 1.10 as a Master who has his slaves use it regually I am glad to see some of the ideas I had come to life... like eliminating the stand button on objects that lock. I have one question... will the object need to have the script for not letting them stand or will be be thru the excisting RR scripts and viewer??
I would like to recommend instead that the object the slave wears performs an announcement on a common channel, and the announcement string can contain protocol information such as a channel to respond to, allowable rules (so behavior can be customized to what the owner determines), and perhaps a time limit and so forth. This technique seems to work with networks and service discovery and the slave is just another node on the network so to speak and is highly customizable. Because the handshake is initialized by the slave this would also make it resource-friendly and eliminate a spam risk.
Something else I'd like to ask for - bundle together the text responses the client delivers instead of scattering them throughout the client code, and expose a service that allows the response text to be changed on an individual basis by the slave's owner - so they can ask IM's to be redirected or state a time when X can receive IM's perhaps.
Most solutions here would require an attachment to be worn. I really like good HUD-attachments and would appretiate an open restraint protocol for attachments very much, so attachments/HUDs could interact with objects, other users of the viewer or attachments that use that protocol and of course to interact with restraints, so that for example, a HUD worn by the sub could lock handcuffs of the same sub or give away the keys to a specified person. Such a communication network would make RL much more intuitive and would allow content providers to create really thrilling interaction scripts. Oops, sorry, I am drifting far into off topic.
The idea of the IM system was that it would be a viewer feature that would work without any attachments required. Ok now, IMs tend to spam non-RL-users. So why not simply use a chat channel instead? I see no difference. The cage for example knows, who it wants to trap, so it whispers on a specified channel, adresses to the UUID if the target person and initiates a handshake that way. As easy as it gets:
cage whispers at -12345: RL@UUID@Version
Why IMs anyway? The only advantage of IMs is that it is not sim restricted. But Commands across sim borders would be kind of unrealistic anyway. A chat channel would give you all the information you want, is not delayed and as secure as IMs. It just does not perform visible spam.
And if you really want to continue the communication using IMs you could switch to IM communication after handshaking.
--- Justus Galli
Hi haver
I wanted to reply to your announcement suggestion. This way of network would work with great flexibility if any object and script in the network was trustworthy which unfortunately is not the case.
Informing objects about general rules or restrictions is a very good idea! But you must not expect them to follow the rules. That should be the duty of your attachment. And such a handshaking could be initiated locally whenever an object wants to interact with the sub. No need for a networked announcement, which would require more administration effort for the device scripts.
The sub in your version is already wearing an attachment and this attachment already knows rules and restrictions. So this attachment could communicate with foreign objects and control the sub on it's own.
So the foreign objects do not control the sub directly, but they tell your control attachment what they want you to do, using an open restraint protocol I mentioned above. That way the trusted attachment controls the sub according to communicated orders by the foreign objects and you can be sure that your rules will be followed.
--- Justus Galli
Some more thoughts on the original idea of objects/others controlling sub functions by using communication, which would still be possible by using a chat channel. I hope I am not bothering anyone.
Marine, you planned to add an on/off option for this feature, which I think was a good idea. If your "no-go" would become a "go" again one day (using another solution then IMs), could you please think about extending this access option? "On" is a generall state (restricted to friends/group and so on) right now. Two more options could be of interest here: "Yes for Userlist" (I know, that means additional effort) and, way more interesting: "Pass to owner".
The last one means that the viewer does not perform the command itself, but passes it to the sub's attachments as a request, using a channel or whatever to tell the sub's attachments silently who tried to perform what command.
E.g.: @Request@{sub-UUID}@{requester-UUID}@commandThat
This may sound silly on the first glance. But imagine, for example, a struggling attachment, a "game in the game" which you seem to like as much as I do, which decides about a successful attempt of forcing the sub into doing something.
Of course such an attachment could do this on it's own using an open restraint protocol handshaking. But the suggested viewer solution would work for people without such a hud too, depending on their set access option, and would only address the controlling attachment if this one changed setting to "pass by". Therefor this way would be closer to your original intention of general behaviour, as I think it was.
-- Justus Galli
Miss Marine - thought You would be interested in the link below (and would appreciate the right of reply to educate others).
this slave has already said his piece *grins*
http://forums.secondlife.com/showthread.php?t=236798
Ariel : yes I see what you mean. It is an interesting and very precise way of handling things, unfortunately it requires a request to the server (like when you hover your mouse to get the tooltip of an object), so it's not atomic.
Tuelly : that depends. I am making a plugin that forces you to sit (and keeps you sat) on any object, even if it's not scripted for that. But the object itself could be scripted as well, the two are not incompatible.
Haver : that would allow the sub to change her automatic responses in real-time, which would basically defeat the "no-receive-IMs" feature in my opinion.
Justus : the viewer cannot listen to a specific chat channel, only zero and debug (the small icon when a script has an error). The rest will simply not be even delivered, so one MUST wear something that relays as llOwnerSay. I am also planning on making a "relay" attachment that users wear to let cages and other in-world objects control their viewer. Actually that's where the rule I have been talking about goes, and I will not even be the only one to provide such a relay. Yes there will be several levels of authorizations, but I trust other people will make better, more user-friendly relays soon.
Klaus : thank you for pointing that URL out, I have posted a message there to explain some things :)
...more stubborn than a donkey and twice as slow
Ultimately, that would be a reference to Andrew Marvell's poem To His Coy Mistress; the original line runs "Vaster than empires, and more slow"
Oh. I'm sorry I don't know about this poem, perhaps this sentence comes from it but it's not where I got mine...
I hope there will be one single "relay attachment" with a "standardized" (and open!?) protocol to handle cages and other objects from different creators.
It would be nice not having to wear 15 different attachments to be compatible with everything.
Heloise, the sentence Marine quoted must be one of many variations of some original model. I remember the film "The Stupids" was originally going to be promoted with the slogan "As American as the apple pie - and twice as smart".
shamota.stoop@gmail.com
(admirer of Marine's work, in particular when worn by someone else, and eagerly waiting for the new viewer)
Danii : Yes the protocol is almost finished. It will be specified, with a working sample code, so that any script implementing those specs will be able to talk to any furniture or cage also implementing them. This way, some creators will make really serious relays (with access lists, dialogs, tighter security rules and such) whereas others will only provide basic ones, and the user will only choose the one they prefer once and for all.
Shamota : Hehe thank you... Although the sentence I've quoted was really heard as is, which means maybe it was a variation on something older. But what I'm expecting is where it is said exactly like I've written. One thing though, I am not a native english speaker, and I have not heard that sentence in english, so this is a translation of a translation. I am pretty sure it was said like that, although "donkey" could also have been "mule". I don't remember, it was a long time ago.
Well, I asked if the canned responses could be changed because I know my Mistress would want anyone trying to IM me to either wait or to contact her instead. That's been our usual practice when we're in a session is to have me briefly tell her of the IM and she decides how to proceed - since we're often both invited over by our neighbors.
As for the quote, it seems to describe our current president :P But I also have a gut feeling that its something that either presidents Truman or Lincoln, or maybe Grant, could have easily said, or should have, even if then didn't.
The open protocol version is most appretiated too. Realizing it this way makes not much of a difference in the end, compered to the original idea. So having a relay in mind I already like it. :-)
Please allow me one off topic suggestion here. Ok, it is more a careful request rather then being a suggestion.
Could you please think about the possibility of expanding this protocol later, so attachments could control other attachments of the same wearer too, to some degree? That is no viewer request, i know.
What I have in mind is, that if an attachment has the ability to sit the wearer on something and lock her there, in some context it would be as nice if the attachment would have the ability to send some very bacic instructions to, let's say, the handcuffs it's wearer is wearing, to gain some more control here. Just some very basing things like "take keys, leave keays, lock, unlock, lock with setting UUID as new keyholder, give keys to".
Nothing to override the usual behavior of course, just being able to remote some basic actions, the wearer could do herself or, in one case, everyone could do who is near the handcuffs.
That is just a little request, targetted at your RR-line, but it fittet to the protocol because it basically should enable very similar possibilities, as your relay version would enable for furniture.
-- Justus
Marine: Well, it was worth a try - and a welcome chance to read the poem again. ;)
Shamota: Well, seeing as Marvell lived and wrote in the 17th century, there's a good chance the line I quoted is the original model for the variations.
I just introduced my slave to the RestrainedLife viewer so that she could have the permalocked collar she's always wanted but cant wear in 1L. I was very impressed. Impressed enough to grab the source and applaud the elegant way you dealt with some of the restrictions.
However, any consideration of permalocking does run us straight into the side-effect of restricting "wear" objects when anything is locked. Its a particular problem with the flexi skirts she loves and that I love to see her in.. they are ALL wierded out by being "attached" rather then "worn" so I'm going to have to build a custom permalock script that allows her to activate short time windows with it unlocked to change clothes in! Now of course she could cheat and remove the item in that window but that brings me to my other scripting project - and its almost exactly what you're thinking of in terms of a command-relaying attachment. In this case, probably a ring for her, a hud for me and interactive scripts for various objects. I plan to have a little library of scripts available eventually but to get around the possibility of cheating and still allow short unlocks I'm going to try to have the ring and collar monitor each other. If either is removed, the other will instantly lock, and impose some punishment... something like immobilizing the slave, blocking tp and dropping her to her knees on the spot whilst IMing me to come get her out of her embarrasing situation. I cant wait to see 1.10
Da5id : Thanks for the compliment, and your solution is wicked and clever :) The Wear option, as you know already, cannot be enabled while at least one object is locked, because of the very way SL handles attachment requests.
I wanted to just say THANK YOU!!! The new 1.10 viewer and the associated plugins are amazing... You have taken the viewer in EXACTLY the direction I was hoping you would!
Only one last question remains... Will you be releasing the updated API docs / source soon? I would love to get going on some new projects...
Sharie : Thank you :) Well I have sent both the API and the source code to Orchid of eRestraint, she will put them online when she can. I am also planning on moving the API from its text file to the LSL Wiki, in the Protocol Exchange section. The format there is better and it's easier to reach.
That was fast Marine! For anyone looking for the API: https://wiki.secondlife.com/wiki/RestrainedLifeAPI
I did find one minor issue in the "stand up" restriction... Right clicking on the Avatar to get the Avatr pie menu and choosing "stand up" still works when restricted. Other than that, it's fantastic!
Oh nd thank you so much for helping Jean with her shackles yesterday (poor girl had FUBARed herself...) She is a very happy girl now!
Just two (three) words from me:
Amazing
and
Thank You!
And i guess the clear and easy way of the RL-API will introduce many new products . And i think not all will focus on BDSM things. Many RP products will come. Very cool. :-)
Marine, you're a scary genius. And I say that with awe and glee in my voice.
Thank you, thank you, thank you!! You've made your already wonderfully wicked viewer even better. The new version is just great. I love the new plugins and functions, it's got all the stuff in it I always hoped to see. You're awesome, Marine!
Kathi
Marine, i am buiding a scripts for a future jail in SL that will use your API, and i think that is better NO allow IM from objects, and keep only with the llOwnerSay.
If someone wants make a cage that can restrict someone inside, this cage must send a object for the captive wear. this object will receive commands for trigger the functions.
Otherwise, will be very harder avoy IM spam from bad objects that can be dropped in everyplace
Seems a little problem with @sit:key=force
It does not always work & not sure yet what the circumstances are(just tried it with a simple cube which announces its ID and I have a script which echos what I say as llOwnerSay for testing).
Otherwise great ! Well done
♥ Mars
Thank you all for your kind comments and the mini-bug-report :)
I'm still here, but so busy I can't even find the time to post a proper blog entry. I will this weekend, promised (after the update to 1.13 that I'm working on right now).
As for not allowing task IMs, don't worry I didn't intend to introduce them anymore, I'm working with Chorazin Allen on a spec to implement into worn "relays" and... more on this later, it deserves a blog in itself.
Mars : yes when you're prevented from tping, therefore from sit-tping, and you're too far from the sit target, force sit won't work. So far I have not found a way to work around this.
Have fun (back to work)
Marine (hugs Kathi)
PS : Nobody found the solution to my little challenge yet ? It's easy though !
Thank you for the great viewer extension.
found a way around the no edit restraint.
if you are edit restrained, you can still edit land by right clicking on it, then you can click on any object on to edit it.
Today i came across the RLV and i am researcing it to see if i want to use it..
i was wondering if the RLV allows the Domme to ready my local chat, IM's, inventory ect
*read
Post a Comment