Signals & Events Module [FREE CODE]

[ElmuKelmuZ]

EDIT:
Updated the ModObject url to a newer version

I've made this really small but incredibly useful module that lets you create, connect, and fire custom events!
It requires the "ModObject" OOP module found here: https://gist.github.com/Elmuti/76af9f55ac1cba475f26

Source code: https://gist.github.com/Elmuti/4c8d2bf23cb9e6f3e27d

Usage example:

Code: Select all

local Signal = require("Signal")
Player.Died = Signal.New() --our event named "PlayerDied", let's make it a member of a player class

function playerDeath(player) --"listener" function
print("player "..Player.Name.." just died!")
--reset game state and do stuff
end

Player.Died:Connect(playerDeath) --connects the listener function to the event

--and somewhere in your code where a player gets killed, you just do this:
Player.Died:Fire(player)

TODO:
Signal:Wait() --Yields the current thread until the signal fires

[DeltaF1]

This reminds me of the event system used in the Just Cause 2 Lua scripting. I"ll check it out!

[Kingdaro]

This... isn't too useful, actually. It's basically just a function wrapped in an object. This does the same thing:

Code: Select all

function playerDeath(player)
  print("player " .. player.Name .. " just died!")
end

Player.Died = playerDeath

-- and later
Player.Died(player)

Maybe it'd be more useful if you could have multiple connections, instead of just one?

[Robin]

The only difference is that you can make them nil, which you can cover with:

Code: Select all

function nilFunc() end

and assigning nilFunc to the callback when you want it to stop doing things.

[Guard13007]

I would say to check out Beholder instead.

[SuperZazu]

That's funny, I was writing a signals module myself!
https://github.com/superzazu/signals.lua

This... isn't too useful, actually. It's basically just a function wrapped in an object. This does the same thing:

Code: Select all

function playerDeath(player)
  print("player " .. player.Name .. " just died!")
end

Player.Died = playerDeath

-- and later
Player.Died(player)

Maybe it'd be more useful if you could have multiple connections, instead of just one?

Could be really useful. Imagine you have a player that can die, and when the player dies, you want to change the game state to "Game Over". If you don't have a signal, that means you'd need to pass the game state to the method Player:is_hit() so that you can do game_state.gotoState('Game Over'). If you have a signal, you can uncouple the game state and the hero.

[ElmuKelmuZ]

Maybe it'd be more useful if you could have multiple connections, instead of just one?

Err lol I meant to do that but completely forgot about it, on it

[Kingdaro]

That's funny, I was writing a signals module myself!
https://github.com/superzazu/signals.lua

This... isn't too useful, actually. It's basically just a function wrapped in an object. This does the same thing:

Code: Select all

function playerDeath(player)
  print("player " .. player.Name .. " just died!")
end

Player.Died = playerDeath

-- and later
Player.Died(player)

Maybe it'd be more useful if you could have multiple connections, instead of just one?

Could be really useful. Imagine you have a player that can die, and when the player dies, you want to change the game state to "Game Over". If you don't have a signal, that means you'd need to pass the game state to the method Player:is_hit() so that you can do game_state.gotoState('Game Over'). If you have a signal, you can uncouple the game state and the hero.

Well... the solution to that is to just check if the player is dead outside of the player.

Code: Select all

function Gameplay:update(dt)
  -- other code...
  if Player:isDead() then
    gamestate.switch(GameOver)
  end
end

[CaptainMaelstrom]

+1 for beholder. I use it and believe it to be an elegant, powerful solution for keeping systems/objects well encapsulated.

[SuperZazu]

That's funny, I was writing a signals module myself!
https://github.com/superzazu/signals.lua

This... isn't too useful, actually. It's basically just a function wrapped in an object. This does the same thing:

Code: Select all

function playerDeath(player)
  print("player " .. player.Name .. " just died!")
end

Player.Died = playerDeath

-- and later
Player.Died(player)

Maybe it'd be more useful if you could have multiple connections, instead of just one?

Could be really useful. Imagine you have a player that can die, and when the player dies, you want to change the game state to "Game Over". If you don't have a signal, that means you'd need to pass the game state to the method Player:is_hit() so that you can do game_state.gotoState('Game Over'). If you have a signal, you can uncouple the game state and the hero.

Well... the solution to that is to just check if the player is dead outside of the player.

Code: Select all

function Gameplay:update(dt)
  -- other code...
  if Player:isDead() then
    gamestate.switch(GameOver)
  end
end

Yes, but that would mean that you'd have a condition each frame of the game update... Not so pretty, mainly if you have a lot of objects to test.