✨ init bs.gui

[theogiraudet]

Tasks to do before merging

• [x] I accept to publish my contribution under MPL v2 License
• [x] My pull request is linked to an existing issue
• [ ] I have added my contribution to the changelog
• If my pull request is a new or modify an existing feature:
  • [ ] I have documented my contribution (/docs)
  • [ ] I have added or updated the header of the features' root function I contribute
  • [ ] I have tested my contribution

[theogiraudet]

Close #193

[theogiraudet]

@aksiome The code is not really up to date, but you can check the beginning of the documentation about the interaction API, if you have some feedback. As you will see, there currently are three APIs in this module. To discuss.

[aksiome]

Conventions

We never used as <any_descriptor>, only as <entities|entity|player|players> so I think it's worth clarifying what we do about those.

The help function tag is missing (im putting it here so we dont forget)

Logic related

I'm not a fan of using both a tag and an id to describe a listener/icon. Also I don't think we should rely on the bs.id score since a user could be using this module in a different way. Imo we should add an other obj that is both responsible for tagging the entity and its id. Having a predicate check is_listener that check a score instead of Tags in nbt will be better performance wise. Also I think it's more transparent for the user, only a single score to define if the entity is a listener as well as its id (and we can still keep the helper functions).

About link/unlink it's not really explained which interaction is used for the current icon if it's an ata function then it should be clarified (like for the create_link_ata in the link module). Maybe this function could work in both direction as icon at interaction and at icon as interaction. Also maybe we could have a command that can create the interaction on top of the icon? Could be something like this, not sure about the syntax tho:

execute summon icon ~ ~ ~ run function create_icon {
	width:
	height:
	nbt:
}

Optimization and other ideas

(that can really change the whole thing so it's up for discussion)

I'm mixing those 2 because when thinking about logic it gave me new ideas. Basically i think everything should be pre-computed when registering an event, we should not just record the raw executor and callback. What i mean by that is that we can precompute the UUID of the executor to then run only a single command when the event is triggered and avoid having to get the executor each time. Something like that:

execute as $(executor) run $(callback)

This can be done with the current implementation but it got me thinking: what if we accept a selector for the executor. Since the selector will get compiled to an UUID it will always point to the same entity that was used during the registration. The main advantage is that the user is free to create complex relationships. We could have this as well as the linking behavior, but if such a system exists do we really need to link the icon and the interaction with an id?

[theogiraudet]

Maybe this function could work in both direction as icon at interaction and at icon as interaction.

I don't see the need, the main entity of this API is the listener/the interaction, so from the interaction (as) we want to define an icon.

Also maybe we could have a command that can create the interaction on top of the icon?

The issue is that the icon can be any entity such as an armor stand for instance, so your proposition is only to create display-based icon. To discuss.

what if we accept a selector for the executor

Interesting, I like the idea. But I think we also have to keep source and target (or more understandable names) to abstract these selectors.

we can precompute the UUID of the executor to then run only a single command when the event is triggered and avoid having to get the executor each time.

I don't see how you can compute the source of the event.

[aksiome]

I don't see the need, the main entity of this API is the listener/the interaction, so from the interaction (as) we want to define an icon.

There is no real need but it does'nt cost much to have it both way? From a user standpoint you don't have to remember the order it can be at interaction as icon or as icon at interaction. But imo it's only a detail.

The issue is that the icon can be any entity such as an armor stand for instance, so your proposition is only to create display-based icon.

Not really, how i proposed it you can summon any kind of icon or execute as any kind of icon. The only constant is the interaction. The idea of this is to be able to summon and link an interaction to the current executing entity.

Interesting, I like the idea. But I think we also have to keep source and target (or more understandable names) to abstract these selectors.

Yeah i agree, if we keep the linking behavior for sure! But with such a system do we really need it? To discuss...

I don't see how you can compute the source of the event.

Yeah sorry, i was only talking about the executor. We still need to find the interaction that the player act uppon.

[theogiraudet]

Yeah i agree, if we keep the linking behavior for sure! But with such a system do we really need it? To discuss...

Here, source and target are the possible executors. The fact that the target can be the interaction or the icon depends on the presence of an icon. So even if we remove the notion of icon, these two possible executors remain. If we want to compute the executor at design time:

• If the executor is "target" so the executor can be computed since this is always the interaction (since we removed the notion of icon).
• If the executor is "source" so we cannot compute the executor since it depends on runtime information.
• If the executor is a selector, so the targeted entitled should exist at design time.

This last situation can lead to ambiguous situation if the entities do not exist at design time. What do you think?

[aksiome]

Yeah sorry i forgot that the target was both the interaction and the icon! For the last situation i don't think it's ambiguous. The selector is "consummed" when running the event registration command, so it always point to the same entity even if scores/tags/... change, a bit as if the entity was linked. If the entity does not exist you cannot link it and if the entity is killed, then there is no more entity linked.