There has been a growing concern about the @detach:[point]
However... in very laggy places, upon relog, things do not rez as fast as they should and the restriction is issued before the object to lock, so it would be locked out. When it finally attaches it is too late, the viewer detaches it automatically, and obviously the product is not working as it should. I have heard of two separate examples of it already.
So the obvious solution would be to divide @detach:
* @detach:
* @attach:
Pros : It solves the problem, and it is more or less consistent with @remoutfit and @addoutfit respectively.
Cons : It requires a new command, nerfs an already existing command... so it kinda breaks existing content.
This is why I'm asking people who make products that use this @detach:
Please only comment about that issue though, no need to stray to any other subject.
Thanks !
Marine
Posts
22 comments:
From Chorazin Allen...
Very much in favour (and one of the people who's been bugging Marine about this already...)
If changing the behaviour of detach:point=n is a concern, another option is keep that as is and create a new syntax on detach as well as the proposed attach command.
--Chorazin
I am for this specific change. It is annoying extra work to query the attachment points or use some long timeout which gives an escape window. As far as I know, it is already possible to put that @attach:xxx=n restriction in without any negative side effects. So that people who want to lock empty attachment spots can start to modify there products now and have the new versions ready in time.
And more general I'd like to ask you to announce planned changes a couple of days before the release because sometimes there are side effects. (@clear on detach). I am aware that this is extra work for you and you are doing this in your spare time.
PS: A big "thank you" for creating RLV and spending so much time on maintaining it.
Hello Marine,
I would vote for: not to divide the @detach: command.
I have not yet heard about issues you describe with my products. However, I try not to fire the detach:point=n as fast as I can, but more at some 'safe' time during log in.
I think the detach:point=n very handy. The 2 years before you created that command my products used to rez, attach and lock a separate dummy attachment to block an empty attachment point.
I love detach:point=n for it makes locking of complete attachment sets very convenient - to use and to implement.
If there is really a big problem with not attaching locked attachments, what about the following idea:
"During log in" allow to attach and lock attachments to locked attachment points if: the attach event was not triggered by the viewer - either by using the inventory or by accepting to attach an attachment that asked for permission to attach.
If you use a separate command to lock worn and unworn attachment points, the scripter needs to check the state of the points by script to decide what lock command is to be used on every point - its possible to do this, but quite complex as well on the script side.
And still, if you use these commands to lock sets of outfits you still have the lag issue not only during log in, but any time you "change" locked outfits. This could lead to fire the wrong locking command after a change, when you try to check the state of attachments (attached/not attached) and get false results for that check - and indeed I do experience false results here from time to time. But these false results are not that critical at present.
About Chorazins idea:
- The pro is definitely the "will not break content"
- But: I do oppose, having 2 commands doing the same thing.
Thanks, all of you have a good point here... damn that's not going to be easy. lol.
Making 2 extra commands that each handle half of what @detach does is a good idea. Or at least it is the least bad idea.
The real problem is not while logging in actually, but while rezzing. If the object does not rez quickly enough and another one issues @detach on its point, then it will be kicked off as an intruder. The viewer has no way to differentiate when an object attaches because it was slow to rez from when it attaches just after the user wanted to attach it. The event comes when the object is rezzed, not when the server has managed to switch it to the "attached" state.
To me, the scripter wants to control whether the point must be locked "full" or "empty", not to just freeze it (even if is easier to use that way, but conceptually it is a toggle, and that's not a good way to handle things). This is because when wearing an outfit that locks points empty, it has to detach the target attach points first, cleaning them by doing several @detach:point=force. The @attach:point=n would do the same... or not. If it was to be consistent with @addoutfit, it should not detach whatever is on the point, so that requirement would stay.
But I'm just thinking out loud here, I really haven't decided anything yet... thanks for the extremely quick feedback already :)
Marine
Speaking for OpenCollar.
We had a few reports about this issue.
But very few, considering the huge user base (only 2 I know of!).
Locking both detach and attach with the same button in the OpenCollar's menu is the best in a usability perspective. So I completely understand Mo's concern.
This is, by the way, what is currently done in the dialog for locking clothing layers: sending simultaneously both @addoutfit:blah=n and @remoutfit:blah=n.
Now, if the change suggested by Marine is made, I think we would query what attachments are worn and act upon it to decide which lock to apply. Maybe a bit laggy, but certainly the best compromise in that case.
Shouldn't we trade a little efficiency for safety?
As for compatibility with OC 3.3:
- if @detach:blah=n only prevents detaching, well that changes the way the collar behaves, but not that much (and most people use it for locking attachments in, not out).
- OC 3.4 should come quickly enough now. If you take a decision within a few weeks, we can adapt in time.
All in all, no, there would be no serious content break.
So my answer to your question is a weak "yes" (be it your proposition or Chorazin's variation).
Semi off-topic:
Now, broadening the debate, wouldn't it be great if we had more powerful commands for locking outfits? Things like a global attachment lock, or folder locks?
In both cases I see obvious implementation issues (choice between locking attachments in or out, and the fact that items in a folder could be moved to another folder after the lock), but maybe it would be worth it finding a way around these.
As a possible workaround, would it make sense, if RLV could accept not only explicit behavior commands (=n/=y), but also macros?
A macro would make the viewer instate series of restrictions depending on the context.
I would see for instance a macro for triggering the lock behavior for every item in a shared folder, or for every currently worn item, or for every attachment point, but selecting the right type of lock.
I am aware scripts can do that. But I could really use sims with less lag ;-).
Closing this semi off-topic parenthesis.
I wish you to find the best solution!
Thank you for opening your blog to comments!
--
Satomi
I've had it happen once or twice, usually only in very laggy areas.
(And I'd like to second what the OpenCollar people said about specific folder locks, as well as the global inventory lock).
I'm in favor of splitting them. I've not written anything to use this command yet, but from a user's perspective, the issue with objects being locked off on logging in is *extremely* frustrating. If a new syntax is created to avoid confusion with scripts written for older versions, the old syntax should be depreciated, not shared, because frankly, the majority of the scripts written with it are useless.
There's no length of timer that could make this work properly, because SL can sometimes take several minutes to rez. Sure, you could put a ten minute timer on it, but that kinda defeats the purpose of the lock.
From Chorazin Allen...
A few more comments...
To Mo - there wouldn't be duplication, just one (existing) command that rolls up two (new) commands. That precedent already exists with @[attach|detach](all)this which saves the script some work - this is a similar situation. (I assume here the existing command is retained as is)
General - there's no safe amount of time to wait during login; any algorithm based only on a time delay will fails sometimes or be so long in becoming effective that it's useless as a restriction. Restrictions should be back in place before the av has a chance to get around them.
General - the current situation isn't just an issue for objects which know they're going to be managing a detach:point=n rule at next login but is also potentially a problem for relays - ideally a realy should be a simple, relatively dumb piece of code that validates the authority to issue a RLV command and then passes it through to the viewer. In the current situation the relay, like any other affected object, has to know that some of the commands it's going to reapply at login are detach:point=n commands and also has to know what the pre-logoff state was so that if the intent is to lock an attachment in place it waits until the attachment is reported as being back (which is different to visibly seeing it as back) before putting the rule back in place.
The way I'd like to see the two commands work (thinking particularly about some of the pain I've had around login rez scenarios) would be:-
lock empty - attempts to attach fail silently, ideally something already attached would be bounced off (though this is just to save on needing to check on the location and issue a force detach)
lock occupied - if occupied, the item becomes locked on. If not occupied, the restriction is stored and waits until an item is attached which then becomes locked on.
There is a kind of symmetry here. The first only affects attaching an item. The second only affects detaching an item.
I'm going to go offtopic for a moment and echo the thoughts of poster #2 in thanking Marine for her efforts on the viewer :)
--Chorazin
hm...
I think the main use of the feature is to 'fix' the state of the attachment point - no matter if occupied or empty - at least that is my experience. Its to prevent to change outfit by will of the sub. If I get Satomi right, its the same use case with the open collar. I think that very convenient as use case.
I have quite some scripts that do change outfits by unlocking attachment points then change them - either with wearing or undressing shared outfits or force detach and after that reapply the previous lock.
If you need to check the state with getattach (point empty or worn) before locking agin, it will really need some RLV 'traffic' to check the state. And even more delay, as I actually get failures with @getattach or @getinvworn.
hm.. if you implement attach:point, do you think it will detach items on force? - If not, a scripter could use attach and detach the same time to 'fix' the point no matter if worn or undressed?
I do oppose to the idea of popping attachments off with @attach: and propose to use the command that is designated to do this: @detach:point=force.
If you come to the conclusion that you will split up the @detach: command (I still oppose), I vote for the option that @detatch:spine=n,attach:spine=n would replace the present @detach:spine=n. That way you can still 'lock' worn outfit without additional checks - like you can do with clothing, as Satomi already pointed out.
Again, I don't know any @detach: failures from my side, but I do experience @getattach and @getinvworn failures after changing outfits, when there is some lag. - Interesting is, that @detach: never failed so far for me. - But that might be a coincidence ...?
As on log in: sure there is no 100% safe time to wait for rezing. This is why I stated 'safe', not safe. It takes about more then 30 seconds from the begin of rezing untill the blank screen with the progress bar is removed and you get a in world picture (if I remember right). To fire commands that do affect other attachments or clothing right the moment the script gets active again (e.g. the rez event or attach event) is very prone to fail indeed.
Let me find some time to do some log-in and outfit changes tests again in high lag areas.
Thanks all, I appreciate it :)
As it turns out, it seems that leaving @detach:point=n the way it is, and to add @detachpoint:point=n and @attachpoint:point=n is the best idea.
With this solution, the latter 2 new commands, used at the same time, would give the exact same result as the former, which would be kept for legacy reasons.
No force detach would occur either, unless the scripter calls @detach:point=force.
So yes, there would be a double symmetry : between @attachpoint and @detachpoint, and between @attachpoint and @addoutfit, and between @detachpoint and @remoutfit. @detach:point=n would merely become an "alias" to @attachpoint:point=n and @detachpoint:point=n.
What do you think about it ? Would that solution suit you all ?
Marine
With "merely an alias" you mean, the restrictions are 'compatible', meaning @detach:spine=n,attachpoint:spine=y,detachpint:spine=y will have no effect (as @detach:spine=n,detach:spine=y)
Sounds like a good solution to me. ... I really wonder when RLV will reach a 'complete' state. :o)
...
Oh dear with that locking attachments, I wonder if a command like @getlockedpoints=code would be handy sooner or later ...
Answer of the viewer: a 32 digit number (list of items that are locked - Digits: 0: unlocked, unworn; 1: unlocked, worn; 2: unworn, locked; 3: worn, locked
The result would be the 'global' result, not the state applied by the object with the script in inside.
@Chorazin:
ok, the case of the relays completely defeats the usability of my off-topic idea of macros (no way to remember what actual behaviors have been instated, unless the relay issues a cumbersome @getstatus). So don't act.
@Marine:
If the current @detach:blah=n really is Bad™ (unpredictible), is it really a good idea to keep it and thus encourage scripters in using it?
(even if it becomes possible to do it right, using the new commands)
Other remark: if we have @detachpoint:blah=n and @attachpoint:blah=n, then I suggest that @detachpoint=n and @attachpoint=n (global locks) should also be allowed.
From Chorazin Allen..
(Long reply deleted, since Marine posted in the interim :-) )
I'm good with Marine's proposal.
One detail to check...
with @detachpoint:point=n and @attachpoint:point=y in effect, will an empty attach point allow an attachment to be made, which then becomes undetachable?
If yes, that's ideal :)
--Chorazin
To all : yes sorry I should have mentioned that @attachpoint and @detachpoint without a parameter would also work, in a global fashion, but it was already in my todo list anyway :)
To Satomi : Yes it is important that the current command stays, as legacy, for those who do rely on it but who haven't commented here or expressed concerns yet.
To Mo : Hey I like your idea !
Marine
@Mo:
If we have the lock in and the lock out, maybe @getlockedpoints actually three bits (un/worn, un/locked in, and un/locked out).
But I really like the idea. We really need more commands like this one. For the sake of completeness, why not also a @getlockedoutfit for clothing layers?
Yes a getlockedoutfits would be logical to have too, if getlockedattach was to be made. I just have to make sure it is the sensible way to do it because the list of attach points could change in the future, if LL wanted (I have not heard about anything done in this way in the standard viewer, but I do know that a modified avatar_lad.xml file with additional points works very well on the RLV, after a certain change I've made to the way the object names are checked for attach point information).
Marine
Do you think if they add more points, that they will change the indices of the present points?
That's not impossible, in which case @getattach would have to be deprecated, and its successor (for instance getlockedattach) would have to be resistant to such a change. But I repeat, LL has not given any hint that they were going to move in that direction. It is just a strong wish of many Residents (including me) to add more attach points. And that's a viewer only change. Problem is, everyone must use a viewer that implements this change exactly the same way or the avatars would not look good.
Another small detail: @attachpoint/@detachpoint is not really consistant with the current command set.
What about @addattach/@remattach?(symmetrical to @addoutfit/@remoutfit)
@remattach:attachpt=force could also become a synonym to @detach:attachpt=force, thus completing the symmetry (and removing the ambiguity with folder commands).
Thanks Marine,
I am definitely one of the ones who wants to see the split. The names of the commands are not hugely relevant to me, I will change my use of @detach:xxx=n to use any new name. I prefer short names but @detachpoint is no big deal.
As I see it, the problem for both the viewer and the scripter comes if both @attachpoint and @detachpoint are set to =n for the same point. I'll make sure I don't do that, in which case life is good!
@addattach and @remattach work too, it's just a matter of giving a name to the commands... And as I was planning to create a @detachpoint:point=force as a synonym to @detach:point=force, well I guess that would become a @remattach:point=force, no problem :)
Ok guys, I have coded these commands (addatach, remattach, with or without parameters, plus the synonym). They are still to be tested thoroughly, and I would like to add a couple more unrelated commands and a bugfix in the next version 1.22.
Can't give an ETA yet because RL is very busy here, but I'm glad we settled for an easy and versatile solution already, in fact it even makes the code clearer now.
Thanks again, I will now close the comments since the problem is now solved.
Have fun !
Marine
Post a Comment