You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the most important features of any ECS library is the ability to process entities by filters or queries. `evolved.lua` provides a simple and efficient way to do this.
588
590
589
-
First, you need to create a query that describes which entities you want to process. You can specify fragments you want to include, and fragments you want to exclude. Queries are just identifiers with a special predefined fragments: [`evolved.INCLUDES`](#evolvedincludes) and [`evolved.EXCLUDES`](#evolvedexcludes). These fragments expect a list of fragments as their components.
591
+
First, you need to create a query that describes which entities you want to process. You can specify fragments you want to include, and fragments you want to exclude. Queries are just identifiers with a special predefined fragments: [`evolved.INCLUDES`](#evolvedincludes), [`evolved.EXCLUDES`](#evolvedexcludes), and [`evolved.VARIANTS`](#evolvedvariants). These fragments expect a list of fragments as their components.
592
+
593
+
-[`evolved.INCLUDES`](#evolvedincludes) is used to specify fragments that must be present in the entity;
594
+
-[`evolved.EXCLUDES`](#evolvedexcludes) is used to specify fragments that must not be present in the entity;
595
+
-[`evolved.VARIANTS`](#evolvedvariants) is used to specify fragments where at least one must be present in the entity.
The builder interface can be used to create queries too. It is more convenient to use, because the builder has special methods for including and excluding fragments. Here is a simple example of this:
@@ -604,10 +612,11 @@ The builder interface can be used to create queries too. It is more convenient t
604
612
localquery=evolved.builder()
605
613
:include(health, poisoned)
606
614
:exclude(resistant)
615
+
:variant(alive, undead)
607
616
:build()
608
617
```
609
618
610
-
We don't have to set both [`evolved.INCLUDES`](#evolvedincludes) and [`evolved.EXCLUDES`](#evolvedexcludes) fragments, we can even do it without filters at all, then the query will match all chunks in the world.
619
+
We don't have to set all of [`evolved.INCLUDES`](#evolvedincludes), [`evolved.EXCLUDES`](#evolvedexcludes), and [`evolved.VARIANTS`](#evolvedvariants) fragments, we can even do it without filters at all, then the query will match all chunks in the world.
611
620
612
621
After the query is created, we are ready to process our filtered by this query entities. You can do this by using the [`evolved.execute`](#evolvedexecute) function. This function takes a query as an argument and returns an iterator that can be used to iterate over all matching with the query chunks.
613
622
@@ -786,7 +795,7 @@ The [`evolved.process`](#evolvedprocess) function is used to process systems. It
786
795
functionevolved.process(...) end
787
796
```
788
797
789
-
If you don't specify a query for the system, the system itself will be treated as a query. This means the system can contain `evolved.INCLUDES`and `evolved.EXCLUDES` fragments, and it will be processed according to them. This is useful for creating systems with unique queries that don't need to be reused in other systems.
798
+
If you don't specify a query for the system, the system itself will be treated as a query. This means the system can contain `evolved.INCLUDES`, `evolved.EXCLUDES`, and `evolved.VARIANTS` fragments, and it will be processed according to them. This is useful for creating systems with unique queries that don't need to be reused in other systems.
790
799
791
800
```lua
792
801
localevolved=require'evolved'
@@ -880,6 +889,43 @@ The prologue and epilogue fragments do not require an explicit query. They will
880
889
> [!NOTE]
881
890
> And one more thing about systems. Execution callbacks are called in the [deferred scope](#deferred-operations), which means that all modifying operations inside the callback will be queued and applied after the system has processed all chunks. But prologue and epilogue callbacks are not called in the deferred scope, so all modifying operations inside them will be applied immediately. This is done to avoid confusion and to make it clear that prologue and epilogue callbacks are not part of the chunk processing.
882
891
892
+
#### Processing Payloads
893
+
894
+
Additionally, systems can have a payload that will be passed to the execution, prologue, and epilogue callbacks. This is useful for passing additional data to the system without using global variables or closures.
895
+
896
+
```lua
897
+
---@paramsystemevolved.system
898
+
---@param ... anyprocessing payload
899
+
functionevolved.process_with(system, ...) end
900
+
```
901
+
902
+
The [`evolved.process_with`](#evolvedprocess_with) function is similar to the [`evolved.process`](#evolvedprocess) function, but it takes a processing payload as additional arguments. These arguments will be passed to the system's callbacks.
`delta_time` in this example is passed as a processing payload to the system's execution callback. Payloads can be of any type and can be multiple values. Also, payloads are passed to prologue and epilogue callbacks if they are defined. Every subsystem in a group will receive the same payload when the group is processed with [`evolved.process_with`](#evolvedprocess_with).
0 commit comments