sfence

@grorp Using a callback over a non-active object will require creating ServerActiveObject for each object and calling Lua `on_activate` callback over it. It can have consequences that I am not...

> > Using a callback over a non-active object will require creating ServerActiveObject for each object and calling Lua `on_activate` callback over it. It can have consequences that I am...

> I don't think this needs a new callback. > > First of all, you can pass the entity name to the "filter" callback. This will already be enough for...

> I think a callback with entity name and staticdata is enough for mods to handle this themselves (although, wouldn't work for your usecase of letting the caller of the...

I have pushed the proof of concept version. Compilable, callback untested-> reused from on_emergcy_area_callback as much as possible. It is not implemented over active objects yet. But the idea of...

Looks to be working now. So you can test it. Some test is included in `/unittests` command and not fully tested/finished features in mod https://github.com/sfence/clearobjects. For example: `/clearobjects quick names...

After the update, clearing active objects causes `on_deactivate` to be called with `removal = true`. Do we want it to happen?

@rubenwardy Benchmark added. 665 ms vs 531 ms on my machine for actual implementation.

@appgurueu Sounds like an idea for new Lua API functions.

> I don't think those new drawtypes are particularly bad, but it would be good to have a discussion first, how useful they are and some use cases. `plantlike_rooted` for...