Development Blog

sound good and i will try the beta later

 

are Interact, Jump, and Throw method names, or are they constants?

They are methods. Not strings, but the Lua method itself.

The way you bind those events, in my opinion, is how the GUI events should work as well.

self.btnExit:BindEvent(ON_CLICK, self, self.btnExit_OnClick) or self.btnExit.onClick:Bind(self, self.btnExit)

Normally you have to pass the script itself as well so you can pass it as the first parameter tot he function so we can define it like

function Script:btnExit_OnClick()

end

 

and use self inside of the function to refer to the script itself as 'self' is hidden 1st parameter to the function

@Rick Yeah, it seems like the next logical step is general event binding:

self:BindEvent(EVENT_MOUSE_DOWN, self.OnClick)

However, binding to an event is different from binding a key or button. The OnClick method would get called when any mouse button was clicked, so you would need to check the button ID in the OnClick function:

function Script:OnClick(event)
	if event.data == MOUSE_LEFT then
		...
	end
end

And then user-created events would probably be the next step:

function Script:Start()
	EVENT_DEATH = AllocateEventID()
	self:BindEvent(EVENT_DEATH, self.OnDeath)
end

function Script:TakeDamage(damage)
	self.health = self.health - damage
	if self.health <= 0 then
		EmitEvent(EVENT_DEATH)
	end
end

I can't really think of a way in which user events would be useful. It seems like it just complicates the code for no reason. I am curious to see what you think.

7 hours ago, Josh said:

I can't really think of a way in which user events would be useful. It seems like it just complicates the code for no reason. I am curious to see what you think.

I hope that even if events were implemented, we were still left with at least the basic Down function we have now.  It's great to have options but often simpler is better.

9 hours ago, Josh said:

I can't really think of a way in which user events would be useful. It seems like it just complicates the code for no reason. I am curious to see what you think.

I think user events are very useful in this kind of subscribe/publish style because it allows for other scripts to know about whatever gameplay event you want without the script needing a reference to another script or entity. Cross script communication via events in my view is the best way to communicate. Allow the EmitEvent() to take a second parameter which is the value that will be passed to the subscribed functions. Since it's lua you only need 1 parameter and it can be a table that the person emitting the event fills out and if you are catching an event you have to just know the structure of said event parameter (a reasonable request).

This would make using 3rd party scripts that emit events easier I think.

Let's think about when we create enemy instances on the fly (not via the editor) and we need them to know about certain things the player is doing. How do we do that today? The enemy script either needs to get a hold of an instance of the player or the player get a hold of instances of the enemies so they can communicate. How they do that isn't very efficient or wise because it either means you're storing a global variable of the player so the enemies can get it (globals bad and error prone) or the player script is looping over every enemy to get a reference of them but enemies could be loading all the time so this doesn't work well. With the event system you can screw all that noise and just have the enemy script bind to a certain event that the player will emit. This way neither need a reference to each other to talk. 

So in summary user events gives us a way to have cross script communication without needing references of scripts/entities.

 

2 hours ago, gamecreator said:

I hope that even if events were implemented, we were still left with at least the basic Down function we have now.  It's great to have options but often simpler is better.

I agree with this. Events work well for cross script communication and UI stuff, but gameplay stuff like picking objects work best with these inline procedural functions. Both are needed.