Hi! The mod has some interesting mechanics!

Perhaps it would be nice to have some settings for tuning the performance. For example, the number of entities checked per update, and so on.
At 60 frames per second, the render time is 16.6 ms. For the current scenario on an i7 10700K, I have an average of 4 ms [with debug viewer] for the game update for the mod alone. If it is used with other mods like Rampant, etc., it may cause a performance degradation.

Disabling debug viewer decrease time to ~1.5 ms =)

And the first step of scenario:
- after water was pumped out, can it be deregistered from handle queue?

it seems to be checked even without water. Same can be reproduced with lake for ironclad.

Hi! Thank you for the feedback.

Spot on! The mod is indeed CPU-intensive. I’ve already made some optimizations in the 0.1.0 release: now all grid operations are tick-limited. Still, there are some areas that could be improved.

The Debugging View itself is also quite heavy on the CPU since it makes a lot of rendering calls for text and lines. I don’t recommend keeping it enabled all the time.

after water was pumped out, can it be deregistered from the handle queue?

Right, it’s still being checked even when there’s no water. That’s because I was planning for possible features like reverse pumping or rain refilling. I’m still deciding how best to handle this.

For refilling with rain\events it seems maybe better have another one queue with tiles or what is stored as reference for update for empty tiles. And if some action of refilling trigger it, push it back to main process queue.

Just a little suggestion) Thx for response and developing the mod)

Thanks for the suggestion!

I actually keep three types of storage:
1. GlobalWaterCells — populated on chunk generation; a boolean grid that marks whether each tile is water
2. WaterSimulationGrid — init lazily when a pump touches an area; they store the current amount of water in each cell
3. WaterAvailableForPump (per pump) — each pump periodically scans reachable cells and depletes water from the corresponding WaterSimulationGrid, which results in different water levels across the grid

There’s also a periodic step that iterates over WaterSimulationGrid and averages values with neighboring cells. This simulates diffusion/flow from higher to lower levels

Your idea about a separate queue for refill events makes sense — especially once a lake is completely drained and there’s nothing left to balance. Performance could really improve if the gameplay is just about placing pumps on lakes and draining them one by one :)