IReactiveSystem excecute based on component data?

[Stals]

It is possible to have a IReactiveSystem that executes not only based on the fact that some component has changed, but also Match the value inside one of them? (or is it the wrong way to design this?)

So, for example, I have a ColorComponent that stores a enum value of colors.
And I want to add a ReactiveSystem that only reacts to entities in which for example position changed (PositionComponent), but only those entities which ColorComponent has its color property equal to GREEN.

If it is impossible - should I make a system that reacts to all position changes (from entities that also have the ColorComponent)? But it also doesn't seem right.
It's just that instead of adding a new system that reacts to the specific color I would need to modify this system that reacts to all of them and calls some other class to handle the specific color. (And so I lose part of the promise that it is easy to add and remove features by adding/disabling systems.)
I guess I could make each color as a Component - like GreenComponent, etc. But this also doesn't seem right.
What is the way to go in this example?

[vladpazych]

You can create your system as usual, to react on ColorComponent added, but in Execute method add something like that:

if (e.color.value != Color.Some) return;

I didn't find perfect solution, so I do this all the time :)

[Stals]

I've also thought of this option, just forgot to mention it.
I just think that if the trigger could do this - you could see all of your conditions in one place, instead of looking at both trigger and Execute() every time.

[sschmid]

Basically, the question is:
Can we have a Matcher with a condition, e.g.

Matcher.Color().Where(e => e.color.value == 1); // not Linq where

and use it as a trigger.

This can also work for more complex matchers

Matcher.AllOf(A, B, C).NoneOf(D).Where(e => ...);

It's not implemented yet, but generally yes.

A few things that pop to my mind:

• Currently matchers are cached and reused. With this approach, this is not possible, since we customize it with a function.
• I have to check first, but: this lambda will most likely produce garbage.
• Filtering will be a little bit more expensive.

But all in all, shouldn't really be reasons not to implement it. This might actually a pretty nice addition to Entitas.

[cloudjubei]

I've had this implemented maybe like a month ago but only for components with enums - if Simon decides that's enough you could get it soon :)