Hooks

[Josh]

What do you think?:

 

AddHook(hookname,function)

RunHooks(hookname)

 

Example:

 

AddHook("UpdateHook", UpdateBullets() )

AddHook("UpdateHook", UpdatePlayers() )

 

Then somewhere in the main Lua loop:

 

RunHooks("UpdateHook")

 

This can be coded entirely in Lua. Does gmod do anything fancier than this?

[Rick]

It seems interesting. Where do you see this being used? Why would I use this as opposed to just calling the update methods by name?

[Scott Richmond]

Well in his example there you could run x code whenever a number of Updatexxx functions are run. IMO I guess it has a use, but surely its a sign of bad design?

[Josh]

You can add update loops to the main loop while keeping all the code contained in one file.

 

Let's say you include a script that has to update something every frame. Instead of adding extra code in the main loop, you can add a hook in the included script, and that way you only have to include a single file. It just makes it easier to mix and match components.

[TylerH]

Rick, please pay $10, buy Garry's Mod, and browse through the Lua. The entity system that Leadwerks originally implemented in the editor in the pre-alpha releases was based on an adaptation of mine of how Garry's Mod handled entities.

 

The hook system is the same. garry's Mod uses it to allow addons and gamemodes to add hooks to be run when certain things are called. i.e. Setup my gamemode's Update function to be called when the game itself Ticks, or play a message on screen when the game calls the PlayerConnected hook.

 

It is a very powerful system.

[Rick]

I'm sure I could find a use for it, but it seems like it's useful for addons where you don't have control over the main game loop, but we do have control over the main loop. That's why I have a hard time seeing where it fits in with LE.

[Scott Richmond]

I tend to agree with Rick - Garrys Mod is very adhoc and so Hooks were no doubt a very useful tool. But in LE its usefulness is considerably less. That said, it fits right into the whole speedy programming and ease of use that LUA brings to the party.

[Josh]

It just means you can turn functionality on and off with a single include file.

[TylerH]

The point it you shouldn't be coding your entire game into your main loop, that has to be the stupidest thing ever. You need to level your code and divide it into areas that execute and correlate to different levels of interactivity.

 

I mean, I definitely find it easier to code say my UI module and my AI module seperately, and then add them to the game loop via hooks, than to be fiddling with the main loop itself.

[Guest Red Ocktober]

needless to say... i'm tolly in luv with this...

 

--Mike

[Rick]

The point it you shouldn't be coding your entire game into your main loop, that has to be the stupidest thing ever. You need to level your code and divide it into areas that execute and correlate to different levels of interactivity.

 

I mean, I definitely find it easier to code say my UI module and my AI module seperately, and then add them to the game loop via hooks, than to be fiddling with the main loop itself.

 

 

That makes sense. I think once we are able to remove the need for us to use the main loop this would be useful. We just don't seem to be there yet. The main loop is still in lua files and we need to specify that loop. I agree that it would be nice to have the main loop inside the exe. In order for that to happen we would need ways to set all sorts of properties to config what we want to use and how to use it.

 

A good start I think would be the camera. It would be nice if that was more module. Maybe it could have it's own lua file. That way you could just point to what lua camera file you want to use and it uses that style. That would allow the flexibility of people writing camera modules that people can just plug in because all FP or 3rd person cameras aren't all created equally for all game types. I think this would be better than creating a generic camera in the exe and only allow changing some settings because someone somewhere will need something totally unique that the settings exposed won't allow. So if it was just a lua file they could control it.

 

I'm picturing treating the camera as another entity that you drag into the scene. You could then drag it to another entity to make the target association and set a lua file for the camera in the properties. Then the lua file would control how the camera works.

[TylerH]

An info_camera node would be nice, with a Drop down in the property editor that had choices from a recursive search of the Models/Entities/Cameras folder, so it could display "First Person Camera (Leadwerks)", "Third Person Camera (Klepto2)", "Third Person Camera (TylerP9P)"

 

Where it reads the camera type (FPS, TPS, RTS, etc.) and the author from the Lua file of the camera entity, and adds it to the drop down list. Then at run time, info_camera basically relays to the selected camera entity, creates it, and then that implementation takes over.

 

Seems like the best way to get "Drag and Drop" abilities for an infinitely large possible number of camera configurations.

 

The possibilities are endless...