Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Put new undress functionality into core collar #85

Closed
nirea opened this issue Jan 1, 2018 · 16 comments
Closed

Put new undress functionality into core collar #85

nirea opened this issue Jan 1, 2018 · 16 comments

Comments

@nirea
Copy link
Member

nirea commented Jan 1, 2018

Over at #83 I made a change to the oc_undress script that makes the "Rem. Attach." menu a lot more user friendly. It's now a list of things the sub is wearing instead of a list of attach points. See https://gyazo.com/ed65f122abaf674fc09c058e9621a3e1 for how it looks now.

With this usability improvement, I think this feature would be really nice in the collar core, instead of buried deep in the menu of an optional plugin. I could add it pretty easily to the core RLV script, or we could have a new script with just this in it to add an Undress button to the RLV menu.

I propose adding this feature to the default collar, but not adding all the other stuff from oc_undress. Note that this would be useful for removing attachments like mesh clothing, but couldn't remove clothing layers or mesh body appliers.

I want others' opinions:

  1. Would you like this feature in the core collar?
  2. Do you think we should build it into the core RLV script or have it separate?
@nirea
Copy link
Member Author

nirea commented Jan 1, 2018

Tagging @SilkieSabra, @Athaliah, @SatomiAhn specifically for opinions. And anyone else interested of course!

@Davros-and-Babble
Copy link

Davros-and-Babble commented Jan 2, 2018

This looks a lot more inline with how the RLV folders look now. I like it, and I think its very needed (as seen in The pros below). This will be one of the best improvements to OC, in my opinion, since the dressing system is my favorite thing.

The pros: 1. This simplifies undressing (without having to go through tons of folders in the RLV folder menu), which means a LOT less setup needs to be done in the RLV folders (unless you want to put clothes back on, but that's what outfits are for) 2. This would make it easy for "masters/controllers" who don't understand the menu system for folders to easily remove things (especially if items in nostrip folders aren't listed, thus uncluttering the list).

The cons: This would make 3 ways to work with attachments: outfits, folders and undress, which might be a bit confusing as to which to use.

As you said, keeping it as a plug in is one option. But in my opinion: This should be part of the core functionality. Im not familiar with the code, but I think it makes sense to group it with "outfits" and "folders" functionality in the same script (all in the RLV script or a separate script depending on which is cleaner and works better with the code)... especially if this keeps them grouped in the menu in a way that they make sense to the end user, so its easy for them to know what to choose. Maybe buttons like 1. "Detach" or "Undress", 2. "Outfits" or "Dress", and 3. "Folders" or "Attach". Davros ponders this

The rest here is just additional thoughts which might be off topic, skip if you'd like:

This thread about separating "Detach/Undress" to make things simple is awesome and may be all that is needed. But... an alternative idea (which would probably be another issue # all together) might be to rethink the way we work with folders that combines and simplifies the 3 different functions somehow. Originally I had been planning on looking at some other wardrobe systems to see how they work with RLV folders to come up with ideas to submit to OC, including how special characters in folder names are used to define different functionality with folders.

Also, this would be great for integrating with the relay on furniture. If furniture RLV menus actually gave attachment lists like this... (not sure how that would be coded), that would make furniture RLV usable again for mesh users, as opposed to smart strip.

Addition thoughts: 1. Whether it effects or integrates with chat commands such as "prefix - foldername" and "prefix -- foldername". 2. Whether it uses the same locks RLV folders use. 3. Whether nostrip folder names still effect it (and don't show it on the list - which I'm all for).

@SilkieSabra
Copy link
Contributor

i think this returns a whole lot of functionality to the strip menu, that really hasn't been there for years, ever since attachments became part of every outfit. It doesn't necessarily make smartstrip obsolete but it gives more flexibility to undress for wearers who don't want to mess with the fussy directories necessary to use smartstrip.

@Athaliah
Copy link
Collaborator

Athaliah commented Jan 3, 2018

  1. no, 2, add it to the RLV script. Am open on this but my thoughts:
    My first question is that will this only work for RLV enabled people or will this feature work for all those enabled and not enabled? Will we need to have a collar wearer setting to allow others to dress them. At that point, should it really be part of the core collar design or as a drop in plugin script as the whole point is to have a very lightweight collar script. I think it might need to be its own script if its only for RLV users as its a pretty high level knowledge item, as the collar wearer would need to know how to manage the folder system, the attachments and how everything works together.

@nirea
Copy link
Member Author

nirea commented Jan 3, 2018

No @Athaliah, this change makes it so you can undress someone without any special folder setup and without knowing beforehand which things are attached to which points.

When I say "core collar" I just mean included in the default set of scripts. I agree that one of the default RLV scripts would be the right place for it, and the button should show under the RLV menu.

@SatomiAhn
Copy link
Collaborator

In a nutshell, I would say go for it. We need this plugin. I also believe that many features should be added, but I see no reason not to publish it as it is now. More can be added to it later.

My (maybe unorganized) thoughts:

  • yes, we want this in the rlv script. We had un/dress, and this is the new un/dress (provides roughly the same features, adapted to current technical background).
  • current rlv un/dressing, based on folders, requires too much set up for it to be really popular or even usable for most people. Thus current situation does not provide a feature set on par with what we used to have (in terms of ease of use).
  • that said, folders are still useful as they make possible finer control. Probably we want both systems, but as @Psych0babble remarked, too many menu entries may be confusing. It would be nice if we could "integrate" both systems into a single plugin (I will try to make a proposal, but not now).
  • (feature) A typical avatar wears lots of attachments. It would be nice to have some way to filter (by keyword) or categorize (head/upper body/lower body... con: rigged mesh can be attached anywhere).
  • (feature) We could also add to this menu the result of a @GetOutfit RLV query, so that clothing layers could also be removed from this menu. Con: it makes the plugin more complicated (scriptwise) as it needs to be, since @GetOutfit and llGetAttachedList() are two totally different mechanisms. And by using RLV queries, we would lose the immediateness of the pure LSL function call. We had this talk in group chat, I mention it for the sake of completeness, but I am not strongly in favor of such an addition (considering that people who would need the new un/dress typically would not care about clothing layers... maybe except shoe bases)
  • (feature) For advanced users, it would be nice, when the user clicks the button, instead of stripping the attachment, it would pop up a (contextual) submenu, proposing a set of actions such as:
    • strip attachment
    • lock attachment
    • lock the folders containing a link to this attachment
    • open the (first) folder containing a link to this attachment (sends a request to oc_folders)
    • "open" the spot where it's attached to (opens a subsubmenu with actions related to this spot: lock attach, lock detach, strip all attachments worn here, strip or lock all folders containing an attachment for this spot, ... )
    • ...
  • (feature) Provide a way to mark folders such that worn attachments having a link in that folder are hidden as such in this menu, but instead appear under a single entry having the folder name (thus allowing more explicit/shorter names, and allowing stripping the whole folder instead of just one attachment).

@Attitum
Copy link

Attitum commented Jan 3, 2018

I was wondering if we can clean the buttons too so that it only shows the numbers to the corresponding list. Rather then :
Example :
current [ 00 tram F728 ] to something like [ 00 ]

@nirea
Copy link
Member Author

nirea commented Jan 3, 2018 via email

@PeeBeeMcMillan
Copy link

Greetz, out there!

I'll chip in, because this has been on my "wishful thinking" list for years. Hehe.

Everything, that anyone said so far is valid and true. I would apply the KISS rule, though: Keep It Smart & Simple. Personally, as a power user and designer, I don't think the folder/outfits system needs a -full- overhaul, but Nirea's added undressing proposal is a BIG improvement.

Undress by attachment point is utterly useless nowadays, with the multiple attachments per point and mesh attachments in general. Theoretically, a shoe could be attached to the head (memories, anyone? :P) and there is no way of knowing that as a menu operator.

RLV outfits can only be detached as whole and we have no easy way to get a list of single items within an outfit. So it's only possible to take one part of an outfit off, if the wearer has set up the same item link in a separate RLV folder.

Providing a plain and simple way to take off single, currently worn items by list, is perfection in terms of every day usability and I'm very much looking forward to this implementation!

@Athaliah
Copy link
Collaborator

Athaliah commented Jan 4, 2018

Am enjoying the discussion on this and with the new information, I'm changing my thoughts on this, that it should be added to the core product as the overhaul as long as we keep it simple and not overload it with so many features that it becomes a mess.

@SatomiAhn
Copy link
Collaborator

We could also choose to modify the behavior of the Dialog plugin (quite easy). Then this would be the default behavior for all dialogs, but why not? In this case, I suppose this change should be discussed in a separate issue.

@nirea
Copy link
Member Author

nirea commented Jan 4, 2018 via email

@silentwar-resident
Copy link

silentwar-resident commented Jan 5, 2018 via email

@nirea
Copy link
Member Author

nirea commented Jan 5, 2018

645c809 makes the detach feature uuid-based instead of attach point-based, and builds it into oc_rlvsuite (though it's also still in oc_undress, and maybe we should just not even include that in spares anymore).

It doesn't try to protect bodyparts from being detached. I can't think of a way to do it cleanly, and am not feeling super motivated to do it uncleanly. If someone has a good idea, please make a ticket for that.

The new feature has been sent in a dev release to the R&D group.

@nirea nirea closed this as completed Jan 5, 2018
@Davros-and-Babble
Copy link

Davros-and-Babble commented Jan 6, 2018

I made a change to the DetachMenu function (in oc_rlvsuite) my own collar with the following code. This seems to get rid of all the items I don't want to see in my specific case (since maitreya puts the word "body" in its hands and feet too). Just a thought in case anyone is interested.

for (n = 0; n < iStop; n++) {
    key k = llList2Key(attachmentKeys, n);

    //Added 7 lines:
    list lDetachFilters = ["nails", "body", "piercing", "head", "ears", "eyes"];
    integer keep = 1;
    integer i;
    for (i = 0; i < llGetListLength(lDetachFilters); i++) {
        string sName = llToUpper(llKey2Name(k));
        string sFilter = llToUpper(llList2String(lDetachFilters, i));
        if (~llSubStringIndex(sName, sFilter)) {  keep = 0; }
    }

    //Added " && keep":
    if (k != llGetKey() && keep) {
        g_lAttachments += [llKey2Name(k), k];
    }
}

@Davros-and-Babble
Copy link

Since this thread is closed I opened the proposal above as issue #89

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants