Events in Verse Pattern

[alk3ovation]

Hello! I wanted to confirm that this pattern I’m using in Verse is the expected pattern to use for events and to see if there are any other people using events differently.

I’m used to be able to create events more similar to the way most of the “subscribable” events are on the Epic created Verse classes. You subscribe to an event and when it fires, your function gets called. However, I couldn’t find an example of creating and triggering your own “subscribable”. The docs make it sound like your class needs to implement “signalable” and “subscribable” but it’s unclear to me how you create specific events that way. However, I did find the “event” object and I have started to use that.

The event object looks to be created for async contexts and the pattern I started using is as follows

HandlerFunction<private>()<suspends> : void = 
        loop:
            EventPayload : event_payload = AnotherObject.CustomEvent.Await()

            Logger.Print("CustomEvent Tirggered")
           # DO something with the payload

 OnBegin<override>()<suspends>:void=        
        #init logic
        spawn:
            HandlerFunction()

If I need multiple event handlers in the class, I spawn them each individually. This doesn’t feel quite right but it works, so I wanted to see how others are using events and if anyone has figured out the “subscribable” pattern.

Thanks!

[Mapshot_Agency]

For now, it looks like we’re not able to implement our own “listenable” or “subscribable” interfaces. This post already covered this topic with a workaround.

How do you implement your own listenable in Verse?

Hello, you can’t initialize a listenable interface inside a class. For now, I recommend exposing an event like the CountdownEndedEvent (for example OnTimerIteration/OnTick) that lets users of the class Await it. You’d then Signal the event when needed. I haven’t played around with it much, but maybe something like this could also be helpful to you: # In this case the functions we accept should take one string parameter and return void. my_fun := type{_(:string):void} my_subscribable := clas…

Hope this helps!

[alk3ovation]

That is helpful, thanks! I think the array of function objects makes sense. I thought there might be a way to officially utilize the interfaces they use on internal classes though.

I guess the follow question I would have is that epic recommends against using “spawn” if you can. In this case, I don’t think I could avoid it. Is there any problem with having a bunch of spawned handlers “awaiting” a bunch of events? Performance or memory wise?

[Mapshot_Agency]

I’m not an expert on memory but Epic also states in their documentation that sometimes there’s just no way around using a “spawn”. They even say that sometimes it’s the best option. So my guess would be that as long as you think everything through and you don’t use hundreds of spawns, you’ll be fine.