[Addon SDK - Editor API ] Missing obvious Hierarchy Methods

[OverboyDev]

Problem description

Exposed Editor API missing obvious Hierarchy Methods on the IWorldInstanceBase or IWorldInstance :

obvious : GetChildren() GetAllChildren() GetParent() AddChild(args) RemoveFromParent()

less obvious, but still : OnChildAdded(childIWorldInstance) OnChildRemoved(childIWorldInstance) : also triggered when Child is Destroyed SetHierarchyParams(HierarchyParams) : allow to override Hierarchy parameters boolean, useful, for UI

Attach a .c3p

Impossible

More details

Those are probably trivial to add and it looks like an oversight but those additions would be game-changers for Editor Addon Making

Affected browsers/platforms:

First affected release:

System details

View details

PASTE HERE

[AshleyScirra]

This is a feature request so please file it on the suggestions tracker.

[OverboyDev]

I already submitted a feature request for on the last platform (2023) and on the current platform (2024) https://github.com/Scirra/Construct-feature-requests/issues/15

However the feature request is about the exhaustive list of methods needed in the Editor SDK to create cool UI systems which includes several more specific/time-consuming/less obvious methods.

Any chance to have basic OnDestroy()/Destroy() methods and basic Hierarchy methods like GetChildren/GetParent/AddChild/RemoveFromParent or OnChildAdded/OnChildRemove in a reasonable timeframe please ?

Those all feel like oversight and those are probably just a matter of exposing existing stuff to the exposed Editor SDK while it would be a huge game-changer for 3rd party editor dev. Not only it would help for UI but also to create a bunch of tools allowing to procedurally create and move instances directly from the editor. By just exposing those exisiting stuff, Editor Tool would become possible to dev in C3 with countless usecases. I've been stuck for too long on many things because of the lack of those simple "obvious" methods.

[AshleyScirra]

The SDK APIs are actually pretty complicated and the external APIs are particularly time-consuming and tricky to test adequately (sometimes involving building an entire fake plugin just to see if methods work properly). Please file suggestions to the suggestions tracker, as it is inappropriate to file feature requests to the bug tracker, even for things you assume are small or easy, but also please note in the feature request guidelines we ask that you do not claim your suggestions are easy, as often minor features turn out to be complicated anyway. We also ask that you provide a compelling use case to help us prioritise suggestions, and issues like this one do not state any clearly explained use case nor review the workarounds, which usually means we would not prioritise it as it does not follow the suggestion guidelines.

[OverboyDev]

The usecase and workarounds are explained in the feature request though.

I'm having a hard time to understand how I could write a more detailed and exhaustive feature request.

There is no way to create UI system that work at edit-time. (And there is no way to create pleasant UI autolayouting systems without using HTML/CSS as almost every single C3 realized at some point and as it was reported by many people since many years). By just exposing existing method to the editor SDK you solve the most annoying issue of C3 : the lack of UI tools.

(There are a lot of extra usecases for all those methods but those reasons detailed are already huge and why so many people upvoted it : it solves one of the most annoying construct weaknesses among other things)

[OverboyDev]

"We also ask that you provide a compelling use case to help us prioritise suggestions, and issues like this one do not state any clearly explained use case nor review the workarounds"

Actually the feature request I linked above provides extensive details about the issue/the workarounds/the usecases/the implementation

[OverboyDev]

The fact this suggestion is one of the most popular (5th most popular out of 84 suggestions) should at least give you an hint the issue raised are a big pain for a big part of the community. I think it's fair to say the "obvious methods" i posted here in bug report aren't the most complex thing to do ever as it's about exposing existing stuff in the engine, not creating complex new User Interface for C3 users, or brand new systems.

I don't understand the urge to act as if you didn't get the point of the suggestion. This is really annoying

[AshleyScirra]

What does "create a UI system" mean though? How does it actually work? What will the user do? What kinds of UI will it cover and what other kinds will it not cover? What is the involvement of hierarchies? What other alternatives have been considered, which could work, and which are insufficient, and why? Which parts of the request are essential and which are optional? This is all stuff we'd like to know, and so the feature request guidelines encourage you to explain all that, but if you look at just the issue filed here in the first post, it completely skips over all that.

We can't consider feature requests that say something like "I'm making an RPG and it's essential I have XYZ", or "XYZ is so obviously essential I consider it an oversight and you should drop everything and do it right now". It just leaves so much unsaid that there a high risk we don't cover what you actually want, that it turns out it's 5x as much work as originally stated (follow-up requests are extremely common - "actually I need ABC too, and it's useless without it..."), sometimes it was already possible another way, etc. etc. etc... It's not a good way to design and develop software that is most likely to be most useful to most people.

I'm trying to help you make a good case for your features - if you ignore all this and we can't adequately evaluate feature requests, it's unlikely they'll be done.

[OverboyDev]

Ok thanks I understand what you mean. I'll try to explain it better here:

---

I think the suggestion was more clear on the previous platform as I wrote it after a first proposal for a Scirra-made Hierarchy-based UI system, which didn't involve Behaviors but directly new Hierarchy settings, such as a "UI Hierarchy Mode" changing the other available Hierarchy settings (and that obsolete suggestion was referenced proposal on the 2023 platform) Even if this idea is now obsolete thanks to this new proposal to add methods to the Editor API of the Addon SDK, it's worth a read to understand it details what could be made : (obsolete request) Hierarchy-based UI Autolayouting https://construct23.ideas.aha.io/ideas/C23-I-78 Since then i thought it would be way better to just provide us the Editor API so anyone can do it itself making addons, and because adding too many option to Hierarchy by default (and a whole new UI hierarchy mode) would be really confusing. Also Editor API gives the power to create many different things, not just Grid/Vertical/Horizontal auto-layouting but also premade UI elements such as Slider-bar, Radial Menus.

---

The main idea with those new Editor API would be that Behaviors of an instance would be able to access and set the position/angle/scale of their parent and children. (but also any other info available via the editor API)

Also Behaviors would be able to listen for some Events that happen on their own object instance or parent/child instances such as OnChildAdded/OnChildRemoved/OnDestroyed/OnAngleChange (important : i realized that part wasn't clearly explain on my suggestion, but yeah the whole point is that behaviors should be able to act when those events happen)

For example you could have a Vertical Layout or Gird Layout behavior on a parent instance, and that automatically layouts all its children based on the behavior parameters. (such as child spacing, max number of columns). (I'm only giving the most basic example here because the true potential of it is immense, the best UI system also allow both the UI parent to have impact on their UI children and the UI children to have impact on their UI parent)

Those Hierarchy-based Behavior-based UI system any addondev could create would have the benefit to perfectly work with everything else in the engine (any world-object plugins such as 9Patch/TiledBG/Text would be compatible while it's incredibly hard to do it via events with Families as multi-plugin family support doesn't exist), it would also work directly in editor exactly the same way it works at runtime (there is not a single way in C3 to have autolayouting UI at edit-time), and doesn't involve very complex system to implement for Scirra. Just exposing existing stuff for the most part (with the exception of a few very handy methods I explain in details in the suggestion)

Most of the UI system made in Game-engines are hierarchy-based and work that way : parent UI objects have properties that acts on their UI children and everything happens live directly in the editor, this is the industry-standard. Ressources about AutoLayouting in other Game Engines : Godot Containers : https://docs.godotengine.org/en/stable/tutorials/ui/gui_containers.html Unity Autolayouting : https://docs.unity3d.com/Packages/com.unity.ugui@1.0/manual/comp-UIAutoLayout.html I especially recommend reading the Godot Container documentation as it's considered as the best UI system made in a popular Game engine and the documentation is very clear and concise.

---

The methods i'm asking in the feature request are all important if we want to build such systems.

For example, we should know the top parent Object changed its angle if we want to make sure to update the position of the full UI Hierarchy when it happens.

For the same reason, we should be able to Trigger something when a Child is added/removed to an parent object with a "Horizontal Layout" behavior to update the position of all the remaining children.

The least obvious are detailed extensively there (especially the MoveParentInstead(boolean))

---

Every single method API suggestion listed in the suggestion would have an even bigger potential that just UI. For example, we could imagine creating a Plugin/Behavior called "DecorationGenerator", that takes an Object, a radius, and an instance count properties. When pressing a callback link button "Generate", it would automatically generate that number of instances at random position inside the circle around the object defined by the radius. (to procedurally create a forest directly in editor for example).

If we were able to Destroy instances via Editor API, we could add an other callback link button "Cancel" to destroy all the instances that were just created (or it could just happen automatically when regenerating the forest if the first generation doesn't please us). Right now we only can create instance but can't destroy them.

If Hierarchy API were a thing, all those procedurally generated instance could be automatically added as child of the generator so moving the generator moves the whole generated forest).

That last point is just a "dumb example" to show how exposing Destroy and Hierarchy methods to Editor API opens a lot of potential for Editor Tools in C3. (but again UI is the number 1 reason why the suggestion is so popular)

---

Being able to have Object-type properties for Behaviors would also be huge for UI systems and any kind of Tools working in editor, but I put it as a seperate suggestion : https://github.com/Scirra/Construct-feature-requests/issues/25

In fact being able to callback Link properties for Behaviors would be great too as it would allow to create "editor buttons" that could execute some stuff directly in the Editor, as Plugins are already able to do.

Example of use-case of new property type for Behaviors :

Object property : allow for a Layouting behavior to only set the position of children that are instances of a given ObjectType or Family (so other children from other ObjectTypes aren't affected by the Auto-Layouting)

Link property : allow for a Layouting behavior to have an editor button to revert the order of all UI children (so first from the left becomes the first from the right etc..). Or a button to move every children index by one to left/right, so index = 0 become index = lastElementIndex, index = 1 become index = 0

[AshleyScirra]

Just to be clear, this is a closed issue on the bugs tracker - this kind of content ought to be on the feature request tracker instead.

[OverboyDev]

I updated the 2024 suggestion to include all additional details,

You can still access the post above easily from there as there is a link to this issue if you want the additional sentences and examples i wrote here, but some of them are redundant with the last edit of the suggestion.

I saw you added a "major project" tag to the suggestion, this is why I ask again if at least some of the obviously missing methods could be pushed in a reasonable timeframe.

Every single listed API would enhance the possibilities.