Featurescript selection of In-Context entities from an assembly

Scott_Boeberitz

Prologue:

This is a long one, but I feel like the background of my thought process will be helpful communicating my question and I'm hoping that someone here can help me wrap my head around how in-context works.

Inciting Problem:

My goal was to make a featurescript that evaluates using a query that automatically includes all bodies in the part studio, including the ones from an in-context assembly, but the query could not include the in-context geometry without manual selection in the UI.

TL;DR of the post:

As far as I can tell, this isn't possible because the parts from the assembly that you see as "ghosted" entities aren't actually in the part studio until they're manually selected to be referenced, but that raises another question for me that I haven't been able to figure out:

If the assembly parts don't exist within the Part Studio yet, how come features that use manually selected entities with EntityType filters are able to identify and control what is clickable on the assembly before the reference is made?

The Long version of the post:

My understanding was that any select-able/highlighted entity, like an edge or vertex, is a UI shortcut that's mapped to a pre-compiled list of all entities within the instance. Then, when a filter is applied, it activates/deactivates the UI shortcuts based upon what entity type it points to in the list it's already able to read. This total list is what I figured the input of "context is Context" is when defining a feature.

If true, it would stand to reason then that features can't automatically query from an in-context assembly because the entities within it aren't on the list that was used in the input of the feature. This explication also justifies why the assembly entities need to be referenced or derived before they can be used, since the act of referencing it is actually just reading from the assembly context, then writing a copy as a new entry to the part studio context, making it available to be accessed by features.

On the surface, these pieces seem to fit so nicely together; When you open a feature, the context up until that point is evaluated including any copied references from other contexts. Then, when a selection field is activated, the list of entities in the context is filtered to match the definition of the field and what's leftover is the list of entities that can be selected in the UI to be added to the query.

However, the rub is that in-context references don't have to be defined prior to using a feature in order to be filtered. If the "Offset Curve" tool is used, the selection UI still only allows for curves and edges to be clicked on at which point the reference is made and the copied edge/curve is added to the query. This seems to imply that the feature can still read the other context, at least enough to filter the UI based up what's being hovered over and trigger the steps to create and query the reference.

So if the in-context geometry is available to the feature to be filtered through for one by one selection via the user in the UI, how come there's no ability for it to simply apply the filer the same way, but automatically grab all remaining entities to be referenced in the same way as it would be if it was manually clicked on?

Epilogue:

I presume that I have at least one, if not many, critical flaws in how I understand this process to work. As such, I invite anybody with more accurate knowledge on the subject than I to impart their wisdom upon this thread. In the exceedingly unlikely event that I nailed it, I'd like to request some new functions to read and make references from in-context assemblies to the primary part studio context automatically.

Thanks in advance for any insight!