Overlays.findOverlays does not find local overlays

[digisomni]

As reported by Basinsky.

[HifiExperiments]

hmmm you mean Entities.findEntities doesn’t find local entities (or overlays, which are the same)? this was actually intentional because hifi didn’t want overlays (often used for UI) to show up in create.

the eventual plan is to deprecated these methods and replace them with an asynchronous method in the Pick namespace where you can exactly configure which types of entities you want

[AleziaKurdis]

Also, Overlays.findOverlays can be used to find "local" entities, and of course Overlays (2d and the deprecated 3d) (It's in the doc I think, but clearly not easy to notice)

I think "local Overlays" is a pleonasm. They are all local. Many things wouldn't work if this was broken.

[Basinsky]

I understand that you dont want to find the UI elements themselves. My use case was creating a local entity with a entity script. When the local entity is created it has a uuid and I can capture that with a variable. And so delete it if want with the script. But when the object that created the local entity is deleted I have no way of finding the UUID because it does not show up in the Overlays.findEntities. I als cannot select it with the create app, so there is no way of removing it besides restarting interface.

My use case was showing a bingo card with the overlay system because it is very smooth and stays on nice position on the screen. If I would do that with local entities and parent them to the avatar they start to jitter when I move and rotate. The overlays dont have that problem.

[HifiExperiments]

ah, so the problem is the Overlays.findOverlays doesn’t find 2D Overlays? I see what you mean. the reason for that is that it doesn’t quite make sense to search for a 2D overlay with a 3D position. the docs reflect that findOverlays only returns 3D overlays/local entities. getOverlayAtPoint is intended to help with that, but doesn’t quite meet your needs...

I can imagine expanding findOverlays to also find 2D overlays (maybe by just using the xy part of the input), but that’s a little hacky. Maybe a new method for finding 2D Overlays within a certain distance?

the jitter with parented local entities is something I’m already looking into fixing also

[digisomni]

Won't the Picks API solve all of this, then? Honestly, I'm pretty sure if a script can create something, you want it to be able to find it back for whatever reason. So we should at least have some way for scripts to have access to all these things (if needed.) Though, with security in mind we'll get proper permissions and architecture upon graduating the scripting engine.

[HifiExperiments]

the move to the picks API is for performance (all these find methods are expensive, and the picking system does smart stuff to improve performance) and simplicity (one configurable method instead of all these other ones). we still need some underlying method to search for overlays, and we could implement that now in the Overlays API and then move it later.

I don’t think having script know about everything they create solves the issue, since it sounds like the problem is finding those overlays once the entity with the script has been deleted

[digisomni]

I don’t think having script know about everything they create solves the issue, since it sounds like the problem is finding those overlays once the entity with the script has been deleted

Indeed, that's what I had meant. We shouldn't be hiding "local" or anything in particular from these things. If the Create App doesn't want to know about something, a simple parameter should be enough to say "I only want Domain Entities, no Local." Then, anyone can script anything to find a type of entity or overlay they need to find.

However, one concern that was brought up is that it's hard to identify what an overlay is... mayhaps we should add a "Name" or "Description" field to all overlays?

[HifiExperiments]

not sure what you mean by the last part...2D overlays are identifiable by their type, and local vs. domain entities are identifiable by their entityHostType

but yeah, the goal here should be a fully configurable search functionality, which is the plan for the Picking API. the old implementation (all of these different findXXXX methods) has gotten bogged down by reverse compatibility issues, as they aren't easily extendable as we add more types of things.

[daleglass]

A test case would be helpful here

[digisomni]

@HifiExperiments Entities for example can have a description, name, and even UserData. Overlays don't appear to have that (anymore). So when using a script to find/refind an Overlay, there's no simple way to figure out what Overlay is what. https://apidocs.vircadia.dev/Overlays.html#.OverlayProperties

[HifiExperiments]

ah, 2D overlays don’t have those things, that’s true. I don’t think they ever have. but they do have a type, so you can check if they are “rectangle” “image” or “text” (the only 2D overlay types)

3D overlays do have all of those things (they have the Overlay properties in addition to their entity properties), so in addition to checking their types, you could read those properties. there’s no reason to overload those things though...you should have enough information already.

[digisomni]

@HifiExperiments Yeah, but 3D overlays are deprecated! :D So for the 3 Overlay types that still exist, there's no identifying factors on them (well, human-friendly identifiers). Unless I'm missing something? It looks like it's not there according to the docs but I haven't actually tried myself, I must say.

[AleziaKurdis]

I would be curious to see why you would lose track of your overlay id. Maybe this can simply be scripted differently to avoid that. (Overlays being local, you have certainly generated your-self at some point)

[HifiExperiments]

@digisomni they have type and ID, which is enough to say “I’m a 2D Overlay”. but it’s true that they lack most of the other properties that entities have. if they really needed a description or name we could easily add them, but I’d say that’s unrelated to this

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

Hello! Is this still an issue?

[stale[bot]]

Hello! Is this still an issue?