Thread: game events interface

I finished exposing game events to python, and after some experimenting I am now questioning whether some of the interface details should be altered.

Here's what I did:
Mimicking SourceMod, Lonestar registers a single meta listener with the Valve API for any events it may interested in catching. The listener itself is inert, and actual event handling is done by hooking the event firing function in Valve's IGameEventManager2. A pre-hook is used, so the normal event handler (whatever it may be) can be overridden if desired. The task of managing listeners on the Python side is completely independent of all this. As a side note, it is not possible to have a listener stop listening to only a particular event once it starts if it is listening for multiple events.

Here's what I observed:

• All events appear to be fired through the hook, whether or not a listener has registered for them.
• I have yet to see any effects of overriding the Valve event handler (though my experimentation in this regard was somewhat brief)

Here's what I want to do:

• Scrap the hook altogether, and the meta listener
• Wrap an IGameEventListener class in a Python listener class, and enable those to be registered for events from Python
• Possibly managing listeners on the Python side so Lonestar only needs one registered for each event, though I am not sure anything is really gained by doing this (except perhaps an extra layer of complexity in the Python interface)

Comments? Suggestions? Insults?

On an unrelated note, is it preferable to keep all the code for this in lonestar.cpp, or in a separate source file?

I'm not sure if this was part of what you were thinking, but I'd almost go for a hybrid approach.

C++ side:

• Implement a mechanism such that a python entity that's "callable" (see Timers) can register itself to receive a particular event.
• A LoneStar C++ class implements the event listener, and contains a list of the above callables.
• When an event is first registered for, a new one of the above objects is made, it's registered with the game, and the python callable is attached to it as the first callable in it.
• If any other python callables register for that event, they are simply appended to the list in the already made listener
• When a python callable unregister itself, it's removed from the above list. If it was the last callable in the list, the listener is removed from listening to the game event and deleted.
• Whenever an event fires, if any python callable is interested in it, then by definition a C++ class would be listening for that event and all python callables interested are in that listeners callable list. The listener object then iterates through its callable list calling each python entity.
• For now just pass the event name as a parameter to the python callable; don't worry about the rest of the fields in the event, they can be added in later. The name is the most important part anyway for most events.

Python side:

• Python code can register to listen to an event by passing any python callable to the proper hl2sdk function.
• The python callable must take a single paramter, which is the name of the event.
• Any number of python callables can register for an event, and they can unregister themselves at any time

P.S. In case you don't know what a "python callable" is, it's any python entity that can be called like a function: global function, member function of an object instance, or any python entity that implements the special function __call__

Originally Posted by timikoy

On an unrelated note, is it preferable to keep all the code for this in lonestar.cpp, or in a separate source file?

Eventually it's going to be split out, but it's header madness to do so. I don't expect you to deal with that mess, so feel free to include it in lonestar.cpp. Or you can include it in whatever.cpp and in lonestar.cpp #include "whatever.cpp" so you don't need to figure out all the headers in whatever.cpp. Your call. But eventually it'll become modularized and different C++ subsections will be in their own file.

Right now the plan is just to use the event manager interface available in the Valve SDK to handle the bookkeeping with listeners. To that effect, I implemented a python wrapper for a C++ listener that allows listeners to be (un)registered from within python with specified python callable. I don't think there is any significant benefit to ensuring only a single listener registers per event, as the only extra overhead for new listeners is the initial construction of the wrapper, but this can be easily reworked if need be.

My original post was more concerned with whether to do listening through the Valve interfaces as intended, or by hijacking the event firing mechanism with SourceHook. But because I can't figure out what superceding that mechanism affects (if anything), I have since convinced myself to stick with the Valve interfaces as-is.

Originally Posted by Ewok

For now just pass the event name as a parameter to the python callable; don't worry about the rest of the fields in the event, they can be added in later. The name is the most important part anyway for most events.

Event objects are already wrapped, with all the data accessors exposed.

Then go for it and we'll see how well it works once it's ready for inclusion