Event filter explanations

[Linver]

Hi all guys,
I'm trying to use the "Event filter" in paticular "LuaPlayerBuiltEntityEventFilters" on the event "on_built_entity", but I have try to declare a filter without understand if is right because I can't find on web a complete example about how use it. Could anyone give an example to me? Like, I want that the event is trigger only when the entity with name A or B is placed.
I try something like:

Code: Select all

filter =
{
	{
		name="A"
	},
	{
		name="B"
	}
}
...
script.on_event(eventA, functionA, filter)

But I got the error: "Filters can only be used when registering single events"(?)
I haven't find nothing on documentation or forum that talk about this.
Thank to all in advance for the answers.

[Linver]

This is what Bilka say to me about (if someone is interested in an answer):

Example for a filter:

Code: Select all

{{filter = "name", name = "portal"}, {filter = "ghost_name", name = "portal"}}

"Filters can only be used when registering single events"
You can't apply them to an array of events like {defines.events.on_built_entity, defines.event.on_robot_built_entity}, it has to be only one event, e.g. defines.event.on_built_entity. This is mentioned here:
https://lua-api.factorio.com/latest/Lua ... p.on_event

[Schallfalke]

Thanks for the example.

Just have a similar question about event filter. Just found this thread and I feel highly related to it, so I am posting here instead of creating a new thread.
Is it possible (or Devs make it possible) to use Lua match patterns to the filters here?

For example, I want to match for ALL ores (potential including any modded ones automatically) having name suffixed by "-ore".
If Lua pattern is supported, I can easily just put a single entry of "*\-ores", instead of manually adding tons of entries.

[PyroFire]

Is it possible to use Lua match patterns to the filters here?

It is not.
Feel free to make a modding api request for it, because this is something i need as well.
But at the same time, generating all the names isn't too hard either, so it probably won't happen and i probably don't need it if i'm not lazy.
Can't hurt to put in the request anyway.

[Honktown]

Thanks for the example.

Just have a similar question about event filter. Just found this thread and I feel highly related to it, so I am posting here instead of creating a new thread.
Is it possible (or Devs make it possible) to use Lua match patterns to the filters here?

For example, I want to match for ALL ores (potential including any modded ones automatically) having name suffixed by "-ore".
If Lua pattern is supported, I can easily just put a single entry of "*\-ores", instead of manually adding tons of entries.

Was there an issue with catching all events from that category, and doing string.match(event.entity.name, "-ore$")?

[PyroFire]

Was there an issue with catching all events from that category, and doing string.match(event.entity.name, "-ore$")?

You missed his question about how to do this with event filters, and my explanation that to actually make use of the event filters when you need patterns, you can either use a fixed table or generate a filter table for them by pre-searching for pattern matches in game.resource_prototypes for example, and dynamically build a filter table that way.

[Honktown]

Was there an issue with catching all events from that category, and doing string.match(event.entity.name, "-ore$")?

You missed his question about how to do this with event filters, and my explanation that to actually make use of the event filters when you need patterns, you can either use a fixed table or generate a filter table for them by pre-searching for pattern matches in game.resource_prototypes for example, and dynamically build a filter table that way.

He needs to catch "-ore$". A single pattern on the event will do that because you can't do that with the event filter. He did not do that for some reason.

[PyroFire]

He needs to catch "-ore$". A single pattern on the event will do that because you can't do that with the event filter. He did not do that for some reason.

It is possible to calculate which prototypes your mod will need to listen for before the event is fired, even with patterns.
Event filters allow us to capitalize on that fact and improve performance for everyone.

[Honktown]

He needs to catch "-ore$". A single pattern on the event will do that because you can't do that with the event filter. He did not do that for some reason.

It is possible to calculate which prototypes your mod will need to listen for before the event is fired, even with patterns.
Event filters allow us to capitalize on that fact and improve performance for everyone.

The problem is data stage information isn't 100% transferable to the "control" stage (you can only access what they want you to). Believe me, I've been threatened a little bit by a dev. This means it can't be done dynamically, which is a pain in the ass.

I thought I had found a way to get all the names in game.item_prototypes, I can't seem to remember.

[Honktown]

Ok yeah here we go:

Code: Select all

/c

local items = "\n"
for _, item in pairs(game.item_prototypes) do
	items = items .. item.name .. "\n"
end

log(items)

I thought there was something stupid I kept running into

may have been me

. We can create a filter at run-time based on names+patterns and register the event then.

Edit: I think some performance testing would need to be done. I could see simple patterns being faster than an array of filters (a string vs indexing/storing/etc separatefilters). Obviously if we could specify a pattern for the event filter that'd be fastest, but we can't, so......

[Honktown]

Ran across something while doing other stuff: you can do {{filter = "type", type = "resource"}}. That would at least shorten the list to a "resource" (or whatever else you can imagine - every event filter supports that).

[Schallfalke]

He needs to catch "-ore$". A single pattern on the event will do that because you can't do that with the event filter. He did not do that for some reason.

It is possible to calculate which prototypes your mod will need to listen for before the event is fired, even with patterns.
Event filters allow us to capitalize on that fact and improve performance for everyone.

Thanks PyroFire for explaining for me. That is exactly what I wanted to say.

I am already doing my own filtering in my mods. (Not exactly this code, just using ores as a more general example. Something similar though.) Just considering to "upgrade" my code to use event filters... But the discussions here said"no" to this. So I will just keep them in current state.

The problem is data stage information isn't 100% transferable to the "control" stage (you can only access what they want you to). Believe me, I've been threatened a little bit by a dev. This means it can't be done dynamically, which is a pain in the ass.

Too bad from a modder's perspective. To me, the current event filters are rather limited, without supporting Lua pattern.