love.event purpose/use

[Garan]

What exactly does love.event do? I noticed it's used in love.run, but is also able to be called outside of it. Why?

[I~=Spam]

This page from wikipeadia might help. Also this in the wiki.

[Garan]

This only tells me what it is for. I'm looking for how to utilize it.

[Jasoco]

Actually, I'm with Garen. Is there any way the user can take advantage of Events or is it just meant for Löve's personal internal use?

[markgo]

You can use it for your own custom event callbacks.

Code: Select all

love.event.push('wasHit',damage)

function love.handlers.wasHit(damage)
  entity.health = entity.health - damage
end

The above example shows how you can handle getting hit by an enemy. Each game loop would process the pushed "wasHit" event. It's the same as love.keypressed, love.mousepressed, etc functions that you define.

[Kjell Granlund]

Thanks for the info. I was wondering the same thing. I think I will start using this now.

[Inny]

Using the event handler that way is a terrible idea. The event loop is for people who want to eschew the default love.run and write their own. The core event loop is primarily for input/output handling. Game logic shouldn't be tied up in the event loop, because very subtle and difficult to solve bugs can hide in those interactions.

You should really use something like [kikito's beholder](https://github.com/kikito/beholder.lua) if you want to do event-response or publish-subscribe style programming.

[Garan]

Actually, I'm with Garen.

Irk! I've been using this for years before League of Legends! It's "Garan", not "Garen" (although the difference in pronunciation is almost indetectible)

Anyway, thank you Inny for linking to that, it will make my turn based game a lot easier to make, what with the different menus and interfaces that will have to be brought up.

[bartbes]

I, as the creator of the latest incarnation of love.event, don't agree with inny. Yes, it might be a bit finicky to use, especially with the default love.run, but the event system was written with customizability and usability in mind, it used to be something mostly internal (though you could manually simulate internal events), but now the decision was made to allow custom events, not to let that sit around and rot, but to be used!

Though the wasHit thing might not make too much sense, I could see this come into play with other things, like libraries. Theoretically LUBE could send an event when a message was received for instance. In fact, love.event might be nice with threading, too, since it's now thread-safe (except for pump, which you don't need anyway), so you could use an event to tell your main thread your calculation is done (possibly even send the result), and to handle the result.

[Inny]

In fact, love.event might be nice with threading, too, since it's now thread-safe (except for pump, which you don't need anyway), so you could use an event to tell your main thread your calculation is done (possibly even send the result), and to handle the result.

I should consult the source code more often, I wasn't aware that love.thread preserved SDL_PushEvent's thread-safety. So, I revise my statement that love.event should never be used ever. love.event is very good for pushing events between threads, to eliminate any need for polling.

Now that I think about it, I imagine a lot of 3rdparty libraries could probably eliminate the need for an update(dt) function by registering custom event handlers.

I still think, however, that internal game logic shouldn't be tied to the love API. Someone somewhere is going to want to port their game to an esoteric platform like Roku (free Angry Birds with purchase of an XS model ) and will butt up against the lack of Love2d on that platform. Not having to plumb the internal game logic would help greatly while writing a custom host program.