Skip to content
Al'rind edited this page Jul 13, 2015 · 4 revisions

Beware, this feature has completely been redesigned. Don't hesitate to read back this page.

Nuki said:

If I had to give my two cents on the biggest and coolest RME's new feature, I think that it will be this one. Even if it is the result of a merge between all you could have read in the previous pages (Custom triggers, commands and selectors), micro-events will help you to save an incredible amount of events in parallel process, alongside improving performances !

Executing pieces of events in specific context

The idea that lays behind a micro-event is the fact to execute portion of events in behalf of specific conditions ! For instance, we would like to display "lol" in the console (thanks to: puts "lol") each time we click on an event. One solution would be the creation of an event in parallel process with a loop which check everytime if the event has been clicked or not, etc. Furthermore, we would have to repeat this code if we want this behaviour on other events. This is not quite handy.

Bind command

Technically, the bind command allows to associate a trigger's condition and a portion of event to execute (if the given condition is checked) to multiple events (thanks to a selector). Let's take back the previous example with the command: bind(0, :click). Once this command will be processed, each time the condition relative to :click is checked for the hero (event n°0), the command puts "lol" will be executed.

Bind taxonomy

Now let's see how to call this special command:

bind(SELECTOR, TRIGGER, *Number_of_executions).

  • There is nothign tricky behind the selector's notion, you can refer to this section.
  • Micro-event's name.
  • Number of times to execute the action. By default, it is infinite.
Saving a micro-event

Like many things in RME, you have also to save micro-events. We have taken the habit to save them in a blank script above main. To add a micro-event, the syntax is a the following:

store_action(:name, trigger{|id| condition on id}){|id| action on id}

For instance, if we want to display the corresponding event's ID in the console each time the player click on an event; we could do something like this:

store_action(:click_to_id, trigger{|id| mouse_click_event?(id)}){|id| p "Oh, the event n°#{id} has been clicked!"}

Starting this micro-event is as simple as calling the following script:

bind(all_events, :click_to_id)

Once this event is processed, each time an event is clicked, the console will display the message.

Examples

For instance, if we want to know the last event on which the mouse has clicked, we will have to put a listener on every event:

bind(all_events, :click){|id| V[5] = id}

Each time an event is clicked, the variable n°5 will take the ID corresponding to the clicked event.

Another example (a little bit strange), would be: Each time I click on an event, I want to put a mirror effect on the picture n°1.

bind(all_events, :click){|id| picture_flip(1)}

Life span

Through adding the number of possible executions per event (as the third parameter of the command bind); you are able to allocate a life span on a micro-event.

Unbind command

Obviously, the unbind command allows to unbind a micro-event. In fact unbind(SELECTOR) unbinds all the micro-events of all events pointed by the given selector. However, it is possible to specify the micro-event to unbind through giving (as second parameter) the selector's name to unbind. For instance, unbind(selector, :press) unbinds the micro-event :press from all events pointed by the given selector.

Building your own triggers

  • The name of a trigger is a mandatory in order to delete the event through the command unbind.
  • The trigger is identical as custom triggers, excepting the fact that the variable id allows you to work on the current event.

Conclusion

Even if micro-events usage might seem complex, we are intimatelyconvinced that they offer advantages to ease Event-Making, alongside proposing a performances' improvement (because they are lighter to execute than events in parallel process). They can be declared in map_onload or in an event in parallel process which deletes itself afterwards. This feature can save you a lot of time.

Clone this wiki locally