Feature Request for SiO2 EventBus : Support for filtered listeners

[pspeed]

@zissis

Async events:
Fleet warping into sector
Fleet warped into sector
Fleet warping out of sector
Fleet battle started
Fleet battle ended

Yes, but what are you doing with these events? Why isn’t it just a scene ID on the event that is then targetting specific data structures instead of some if/else thing?

The issue is that if I add this to the EventBus then everyone pays the penalty for checking filters even when 99% of use-cases will not use the filters. Instead of just delivering the messages, I need to also check each one to see if it’s filtered. There is no guarantee of any kind of efficiency because these are O(N) and may even have side effects.

It also seems like you could have bound the events to scene objects that do the filtering for you and call whatever they are going to call… then at least you are aware of the inefficiency and could even do something smarter than “iterate over 1000 listeners to see which one matches the filter”… because what you really want is a scene ID dispatch.

[pspeed]

@Ali_RS

Fortunately in my game, each Party(Team) has just one active scene at a time which is limited (x = 1000m, z = 1000m). After the party win current level, the scene dispose and a new level starts which means a new Scene with new story.

Then you could achieve multiple “spaces” by setting the y values to spaceId * 1000 or whatever. Then the normal zone filtering will make sure clients only see their ‘space’.

[Ali_RS]

@pspeed

Then you could achieve multiple “spaces” by setting the y values to spaceId * 1000 or whatever. Then the normal zone filtering will make sure clients only see their ‘space’.

@pspeed then I wont need to use scene id filtering in ModelViewState, yes?

btw, what are exactly the benefits of using this method against filtering based on scene id (in my case) ? Do I need to use Zone filtering at all in my case ? Sorry if it seems a noob question.

[pspeed]

@Ali_RS

@pspeed then I wont need to use scene id filtering in ModelViewState, yes?

btw, what are exactly the benefits of using this method against filtering based on scene id (in my case) ? Sorry if it seems a noob question.

The benefit is the SimEthereal is already partitioning space. It’s not partitioning based on some game concept of scene IDs… and it seems like considerable work to add (especially without affecting games that don’t need it).

ModelViewState might still have to filter if you have static objects that are not managed by SimEthereal. In my own case, the position components for my static objects include a zone ID so that I can filter them easily.

[Ali_RS]

@pspeed

The benefit is the SimEthereal is already partitioning space. It’s not partitioning based on some game concept of scene IDs… and it seems like considerable work to add (especially without affecting games that don’t need it).

So by considering that I already have the scene id stuff implemented in my case then no reason for me to use SimEthereal Zone filtering, Yes ?

[pspeed]

I thought you were already using SimEthereal and wanted to keep everyone separate. If you aren’t using SimEthereal then no worries.

If you are… and are already spatially partitioned, then also no worries.

[Ali_RS]

I see. Thanks soooooo much for your helps Paul.

[zissis]

@pspeed

The issue is that if I add this to the EventBus then everyone pays the penalty for checking filters even when 99% of use-cases will not use the filters. Instead of just delivering the messages, I need to also check each one to see if it’s filtered. There is no guarantee of any kind of efficiency because these are O(N) and may even have side effects.

Sold! I agree that bad inefficient design to save a few lines of code is something I bash developers all the time on and effectively I was asking you to implement this bad design. MUCH more optimal to just do the sceneId check in the listeners like I have right now. I fell into the basic optimization trap because I wanted less code on my side. Big nono!

Move along. These are not the droids you are looking for.