Multi-events as the default?

[alexgleason]

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) Select Expand

-- Lua script of map test_map.
-- This script is executed every time the hero enters this map.

-- Feel free to modify the code below.
-- You can add more events and remove the ones you don't need.

-- See the Solarus Lua API documentation:
-- http://www.solarus-games.org/doc/latest
require("scripts/multi_events.lua")

local map = ...
local game = map:get_game()

-- Event called at initialization time, as soon as this map becomes is loaded.
function map:register_event("on_started", function()

  -- You can initialize the movement and sprites of various
  -- map entities here.
end)

-- Event called after the opening transition effect of the map,
-- that is, when the player takes control of the hero.
function map:register_event("on_opening_transition_finished", function()

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.

[alexgleason]

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.

[Max]

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 : )