Author Topic: Multi-events as the default?  (Read 101 times)

alexgleason

  • Jr. Member
  • **
  • Posts: 72
  • Vegan on a Desert Island
    • View Profile
    • Vegan on a Desert Island
Multi-events as the default?
« on: October 17, 2018, 08:41:47 pm »
I was just having this moment of great realization for why Lua is a powerful programming language, then I hit a wall again.

To give an example, I have a script which does get_metatable("map"):register_event("on_started", ...)

The problem is, Solarus Quest Editor creates every map script with an empty on_started defined. So I'll need to edit all my maps and change it to map:register_event("on_started", ...) in order to make both functions run.

Basically, I'm trying to have events in "layers". Every map will always call the same "on_started" function in the metatable, but it will also call the "on_started" function of the specific map itself.

So I'm wondering if there should be a push towards using multi-event functions in Quest Editor instead. Eg, creating a new map might look like this:

Code: Lua
  1. -- Lua script of map test_map.
  2. -- This script is executed every time the hero enters this map.
  3.  
  4. -- Feel free to modify the code below.
  5. -- You can add more events and remove the ones you don't need.
  6.  
  7. -- See the Solarus Lua API documentation:
  8. -- http://www.solarus-games.org/doc/latest
  9. require("scripts/multi_events.lua")
  10.  
  11. local map = ...
  12. local game = map:get_game()
  13.  
  14. -- Event called at initialization time, as soon as this map becomes is loaded.
  15. function map:register_event("on_started", function()
  16.  
  17.   -- You can initialize the movement and sprites of various
  18.   -- map entities here.
  19. end)
  20.  
  21. -- Event called after the opening transition effect of the map,
  22. -- that is, when the player takes control of the hero.
  23. function map:register_event("on_opening_transition_finished", function()
  24.  
  25. end)

This would offer a lot more flexibility, because you could disable the default behavior by switching to an empty function. This seems like a more common use-case. I can't think of a use-case where it's better off the way it currently is.

The only real issue I see is that Quest Editor would have to assume you have a multi_events script. So then it makes me think... maybe package that into the engine itself? I mean, it's an essential tool for quest development.
RIP Aaron Swartz

alexgleason

  • Jr. Member
  • **
  • Posts: 72
  • Vegan on a Desert Island
    • View Profile
    • Vegan on a Desert Island
Re: Multi-events as the default?
« Reply #1 on: October 17, 2018, 09:56:13 pm »
I was able to achieve what I wanted by manipulating the map from the context of an item script. I ended up with way less code (and cleaner code), so I'm wondering if my suggestion here is bad practice? I'm not really sure.
RIP Aaron Swartz

Max

  • Full Member
  • ***
  • Posts: 173
    • View Profile
Re: Multi-events as the default?
« Reply #2 on: October 18, 2018, 03:55:00 am »
I don't think the idea of a built-in multi-events script is bad- for a case where I can't think of a way to do it with an item, I wrote a script for saving the player's respawn location whenever a map is changed to make the game more forgiving. I have done the work you're dreading, of having the manually go in and delete or change every map's default events to keep them from overriding my functionality, and it is a pain.

For some reason, I've been assuming Solarus 1.6 is going to automatically include the multi-events script built in? I don't know if I have a reason for thinking that or if I'm mistaken, maybe someone working on it would know better, haha.

The only thing I can think of why the current system is better, is that you've got a kind of override of whatever you've defined in your metatable. For example, if you define some behaviour for every enemy in enemy:register_event(on_dead, function() ), and you want to override this for just some frog enemy, you can just define enemy:on_dead for the frog, and it'll override. If you built-in support for multi-events, I don't know if you'd have that override. But I suppose if you were building in support for multi-events, you could also just build in an override functionality?

If I'm mistaken about the changes in 1.6, you guys should consider at least not automatically defining events on map scripts. I found it very helpful for the first month of development, then annoying for the next two years, haha : )