LogiX node to get 'avatar save root' or similar slot

[Anomalous]

Is your feature request related to a problem? Please describe.

When I add things to an avatar I like to add them to the avatar root so they are easily found to be modified or deleted later. I have recently been trying to make an automated tool for adding a system to an avatar, and ran into the issue where the avatar root can not be found in an automated way. This makes it problematic to determine what slot to install the system into such that it will save with the avatar, and be readily found at a high level in the avatar hierarchy for editing or deleting later.

Relevant issues

No relevant GitHub issues found. There have been various Discord discussions in the part about the impossibility of determining an avatar root via LogiX, which is a slightly different but related problem.

Describe the solution you'd like

I think it would be handy to have a LogiX node that given a user, returns a slot where it is recommended to save avatar additions. This would be somewhere within the persistent hierarchy of the user's avatar, not in their non-persistent user root. It might be the root slot of the avatar, or it might be some other standardized and easy to find slot designated for saving things that have been added on to the avatar after the fact.

An avatar that has no persistent parts (like the default avatar) would likely just return null when used with this node, indicating that no part of the avatar will be saved.

Describe alternatives you've considered

Manually requiring a user to specify a slot to save avatar additions into, rather than finding the target slot in a automated way. This is a much higher barrier to adding something onto an avatar, especially for the less-technical users.

Finding the avatar root by identifying a body node slot and stepping up the hierarchy until "parent == user root". This seems to work for many full body avatars, but does not work for heads-and-hands avatars even when they have a single avatar root slot. And avatar root slot is not necessarily the same as a 'recommended save slot'.

[Aerizeon]

For Alternatives: The way I currently do it for my badge manager, is search for "Voice Range Visual" (which exists by default on all avatars), and step back up the hierarchy until the parent is the user root. If that slot doesn't exist, fall back to the body node slot method.

Turk and I both use an <color=red>Avatar Settings</color> folder for our addons, but I'm not sure if there are any other standards at present.

I think that the most useful slot to be returned would be roughly equal to what my system does now (but more robustly) - that is, the slot that is closest to the user root, but is a parent of the head slot. This seems to be what most people consider to be the "avatar root", even in cases where there are multiple root objects (head and hands, for example)

[Anomalous]

Thanks for the tip about the "Voice Range Visual", I appreciate that as a workaround for the moment!

Here's one case where the body node slot method doesn't work, but it looks like starting from "Voice Range Visual" would. This is a heads-and-hands avatar created with the avatar creator. The slot "Gryph H&H" is the highest-level persistent avatar slot (what I'd call the avatar root), but while that does indeed have head and hand slots, unfortunately the body nodes are in separate non-persistent head and hand slots outside of the avatar.

On Discord, H3BO3 observed that there's always an "AvatarRoot" component somewhere, which could be used to find the avatar root slot. Easy enough in C#, but unfortunately not something we can do in LogiX at the moment.

Of course as in the original issue, I don't especially care if I find the avatar root... I just want know what a good place to save something with the avatar is, in an automated way.

[Aerizeon]

Yeah, I just suggest using the body node as a fallback (and if you can't find either, the user probably knows enough to fix it).

you can also search for the "Avatar Settings" slot mentioned above - anyone who uses turk's nametag gun, or his avatar setup tool, or my badge manager, or who I've manually setup a near clip/expression driver on, will have one of those slots :P

[Zyzyl]

Just a small bit of context - Froox previously said that getting an avatar's slot would need to wait for collections since there may not be a single one https://github.com/Neos-Metaverse/NeosPublic/issues/264#issuecomment-505614911

Mentioned since it's relevant to one of the suggested alternatives

[Anomalous]

Zyzyl, thanks for the context! Had I known that I probably wouldn't have made the suggestion (even if it is a slightly different thing, wanting to find a good slot to put persistent avatar addons). But it's here now, so I guess we'll see what a team member says.

[Aerizeon]

I'm not sure I understand why this was tagged as collections, since the "Describe the solution you'd like" section, and the follow-ups explicitly mention wanting a single slot, which doesn't require an array to access.

As part of a discussion with ProbablePrime, I was told to add a possible suggestion:

An avatar component that defines a single slot, which will be used for storing add-ons/settings within the persistent hierarchy of a user's avatar.

This component would be automatically generated, and point to a standardized "Avatar Settings" or "Add-Ons" slot by default, and would give the end user the ability to modify the slot/slot name/slot placement if desired. The most sensible default location (to me) would be the highest-level slot that is both a parent of the user's head slot (where Voice Range Visual is located by default), and a child of the User Root Slot.

The component would also have a complimentary LogiX node, explicitly for retrieving the slot it is referencing.

This would satisfy the use case for my tools, turk's tools, and the scenario that Anomalous mentioned above - we would have a single, easily accessible slot that can be verified as being persistent, is known to be within the saved portion of the user's avatar, and is explicitly used for saving avatar additions.

[Frooxius]

What kind of things are you looking to save on the avatar exactly, can you give me some examples?

I'm not sure what form would a standardized system take without understanding that better. If you're making something custom, you're free to setup whatever solution you like for your avatar, but for something official we need to ensure it's flexible and robust enough to cover wide range of use-cases.

It might potentially require collections due to the nature of the avatar system - it can actually be composed from multiple separate avatar pieces (e.g. consider custom head, which adds the default hands), so you could end up with multiple of these "roots", which would require enumerating them, otherwise this solution will just give you one of them, which might not be the one you want.

[Aerizeon]

Generally, a centralized place for storing various automatically generated settings (using tools for setting up the avatar scale component, the clip distance component, etc.), for installing additional features into the avatar (custom nametags, custom badges, custom context menus, mute helper type interfaces, custom view visuals, etc)

These are all things which need to be placed somewhere on the avatar that will be saved, and traditionally used FindChildByName and creative guessing, which is now explicitly outlined as being not recommended

[3x1t-5tyl3]

I can agree to @Aerizeon with that statement. I've been avoiding making tools that save to an avatar waiting for this to be a thing. This explicitly goes for custom systems that creators make, Some users might not want to interact with the creation side of neos and having them require to put a slot in a specific place is already too much. Thus requiring something like a more direct and less "janky/hacky" way to go about this.

[gentlecolts]

Reposting this from the discord ideas channel:

so, one of the things that was a total thorn in the side for me for mmc was the lack of ability to directly fetch the user's avatar slot(s)...I know this one's a common feature request, and the common counterpoint is that it would require containers, however i'd like to instead raise the proposal that it could in fact be implemented in neos without the addition of containers, and logix already has a precedent for this: the multiplexer node. for example, a "get avatar slot" node's interface could be one which takes a user and int as its inputs, where the int is an index, and provides a slot and int as outputs, where this int is the total count. this would allow people to use existing looping constructs, which would likely need to be used for any of the use cases i can think of anyways, and would not require the addition of collections

also, in addition, an "on user avatar loaded" node would be pretty nice too

[ProbablePrime]

Please open a separate issue for "on user avatar loaded"

As for your idea, Unfortunately, you've described hacky collections.

We can certainly make hacky adjustments and nodes but these are brittle and will usually break later down the line. This is a case of that.

Its better to wait for collections then to die by a thousand cuts of solutions like these. I really do apologize that this is the case though.

[Aerizeon]

There's an open request for avatar Equip/Dequip events in #1694

[gentlecolts]

Oh whoopse, I'd already made a new one at #3634, perhaps the two can be merged?