on_entity_clicked
Posted: Sun Oct 30, 2016 2:53 pm
Doing custom GUI for an entity is a PITA.
There are two approaches currently available, both of which suck:
custom-input
This is useful if we need to retain existing gui, but want optional alternative gui. We define custom-input keyboard shortcut, and when its event is triggered, we check game.players[event.player_index].selected to see if it's applicable entity and if so show the GUI.
.opened
We can check player.opened every so often (putting more stuff in on_tick is good for performance, compared to events), and if its not nil check to see if the opened entity is something we are interested in and then show our custom GUI. As far as I know there's no way to hide the vanilla GUI for the entity though.
If we set entity.operable = false for the entity, it will stop vanilla GUI opening but then as far as I know the player.opened will never get set because the player can't "open" the entity.
Proposed solution
When an entity is clicked, trigger an on_entity_clicked event, with the entity as a property of the event table.
This way we could set .operable = false, to prevent default GUI, and use the evnet to trigger our GUI.
While our GUI is open, we can check player proximity to the entity (again, via on_tick, because that's good for performance compared to events) and if they get too far away we can close the GUI (It would be nice to have that event driven also, but not sure if it would be feasible to implement - the game can and does already do it for vanilla entities, but I imagine that an event to allow mods to do the same would impact performance).
As for manual closing of our GUI, we'd likely need to create a custom-input, or put a little X button on the GUI to close it with mouse click. As far as I know the standard ways of closing GUI are not going to be available to mods (they are reserved for vanilla GUI) so we have to provide alternate user interaction for modded GUIs. Different interaction models for vanilla and modded GUI are good UX design.
There are two approaches currently available, both of which suck:
custom-input
This is useful if we need to retain existing gui, but want optional alternative gui. We define custom-input keyboard shortcut, and when its event is triggered, we check game.players[event.player_index].selected to see if it's applicable entity and if so show the GUI.
.opened
We can check player.opened every so often (putting more stuff in on_tick is good for performance, compared to events), and if its not nil check to see if the opened entity is something we are interested in and then show our custom GUI. As far as I know there's no way to hide the vanilla GUI for the entity though.
If we set entity.operable = false for the entity, it will stop vanilla GUI opening but then as far as I know the player.opened will never get set because the player can't "open" the entity.
Proposed solution
When an entity is clicked, trigger an on_entity_clicked event, with the entity as a property of the event table.
This way we could set .operable = false, to prevent default GUI, and use the evnet to trigger our GUI.
While our GUI is open, we can check player proximity to the entity (again, via on_tick, because that's good for performance compared to events) and if they get too far away we can close the GUI (It would be nice to have that event driven also, but not sure if it would be feasible to implement - the game can and does already do it for vanilla entities, but I imagine that an event to allow mods to do the same would impact performance).
As for manual closing of our GUI, we'd likely need to create a custom-input, or put a little X button on the GUI to close it with mouse click. As far as I know the standard ways of closing GUI are not going to be available to mods (they are reserved for vanilla GUI) so we have to provide alternate user interaction for modded GUIs. Different interaction models for vanilla and modded GUI are good UX design.
