"Chunk updates pollution" event

[Reika]

As per viewtopic.php?f=28&t=50178&p=292472#p292472 , which was never responded to.

[Rseding91]

This is another one of the events we never made because of how frequently it would be called (100-200 times/tick or more).

[Reika]

This is another one of the events we never made because of how frequently it would be called (100-200 times/tick or more).

200 times a tick!? I thought chunks only updated their pollution once a second.

EDIT:
By "Update" I mean the spread/absorption behavior, not any time the data is accessed (like pollution emission).

[BenSeidel]

What does access to the event give you that iterating over the chunks once a second does not?

[Reika]

What does access to the event give you that iterating over the chunks once a second does not?

I want to do something similar to Minecraft's block ticks. Iterating over the entire world is far too expensive to ever do all at once, even once per second, resulting in a noticeable lag spike every time it happens. Much better would be to 'piggyback' on the pollution calls that are going to happen anyways, and can even save a call to surface.getPollution if the event provides it.

[Patashu]

If you don't have to do something to EVERY chunk EVERY tick, you can scan over all chunks, but stop after you've scanned X, and next tick pick up starting at the next chunk over. That way performance penalty is spread evenly over all ticks, and does not increase in proportion to number of chunks generated.

[Reika]

If you don't have to do something to EVERY chunk EVERY tick, you can scan over all chunks, but stop after you've scanned X, and next tick pick up starting at the next chunk over. That way performance penalty is spread evenly over all ticks, and does not increase in proportion to number of chunks generated.

No, the iterator is an "all in one" kind of thing; there was a past discussion about exactly that.

[BenSeidel]

Yes, the chunk iterator sucks for this kind of thing, you're much better off rolling your own by hooking into the "on_chunk_generation" code and putting each chunk into a table in a set of "iterator tables". This gives you control about how you divide them up. For example you could have 60 tables, one for each tick. On each tick, pick the appropriate table and iterate.

you could also divide the chucks up into non-polluted and polluted. This could help with large train-based maps where the pollution does not cover a significant portion of the map.

[Reika]

Yes, the chunk iterator sucks for this kind of thing, you're much better off rolling your own by hooking into the "on_chunk_generation" code and putting each chunk into a table in a set of "iterator tables". This gives you control about how you divide them up. For example you could have 60 tables, one for each tick. On each tick, pick the appropriate table and iterate.

you could also divide the chucks up into non-polluted and polluted. This could help with large train-based maps where the pollution does not cover a significant portion of the map.

This is an interesting idea.

[Reika]

I made a couple realizations that complicate the above:

Getting the pre-existing chunks into that cache would still require iteration, though, if only once.

And splitting based on pollution - while useful - needs some way of being kept up-to-date, whose only means is again chunk iteration.