Given an entity, you can get its parent (if any) by looking at the entity’s “parent ID” property.
However, given an entity, as far as I can see you cannot reliably get all an entity’s children …

You can do Entities.findEntities(position, radius) and then look at each entity’s parentID property to determine if that entity is a child. However, findEntities() only returns entities in you local copy of the tree, i.e., only entities that are or have been in your view. Unless you turn through 360 degrees and have your search radius large enough you will not necessarily get all the parent entity’s children in the search results.

Unless I’m missing something, it seems like a new API call is needed; one that does the search on the server’s tree rather than one’s local copy.

like Entities.getChildEntity(id, index); And too, I hope there is a hierarchical relationship too - a child entity can have children parented to itself. It would make possible building subassemblies to which common operations can be applied (such as rotate).

One use case where being able to obtain the complete list of child entities is important is implementing an “undo” of entity deletion. If your script deletes a parent entity then all that entity’s children are automatically deleted (on the server, whether you can see them or not). Yes, Entities.deletingEntity() events are emitted which you can subscribe to, but the data contains only the ID of the entity deleted. So there is no way your script can reliably undo the delete. The best it can do is scan your local entity tree within an arbitrary search radius and compile a list of child entities and their properties before deleting the parent entity; then it can later undo the delete of the parent entity and child entities that it found, but very possibly not undoing the deletion of all the entities that were deleted.

If it’s not possible to implement a proper Entities.getChildren() method, perhaps it’s possible that the Entities.deletingEntity() events of entity deletion could be made to include all the properties of each entity deleted rather than just its ID? In this way, your script could monitor the stream of deleted entities and take note of any that were children of the parent just deleted. (Though things may get tricky when identifying children of children, unless the order of deletion is guaranteed: parent first, then children.)

A related issue that will probably crop up: If an Entities.getChildren() method is implemented that returns the full list of child entity IDs, some of these entities may not be in the local entity tree so presumably Entities.getEntityProperties() may fail for those entities?

To summarize, two questions:

Given High Fidelity’s implementation, is it possible to add a complete Entities.getChildren() method or not? If so, is this going to be done? And if so, will Entities.getEntityProperties() for an entity not in the local tree work?

If the answer to 1) is “no”, is it reasonable for the Entities.deletingEntity() signal to include the properties of the deleted entity as well as its ID? (And delete parent first, children thereafter?)

Given High Fidelity’s implementation, is it possible to add a complete Entities.getChildren() method or not? If so, is this going to be done? And if so, will Entities.getEntityProperties() for an entity not in the local tree work?

All Entities methods operate against your known “local” tree only. There is no plan to change that.

ctrlaltdavid:

If the answer to 1) is “no”, is it reasonable for the Entities.deletingEntity() signal to include the properties of the deleted entity as well as its ID? (And delete parent first, children thereafter?)

Due to the nature of when the deleting entity signal is sent it is not possible to know the properties of the entity at the time that that signal is sent.