You're sure about the manager? Seemed like it allowed more than one in the scene, but only one per water group. I did not test that to death, it just seemed like there was a pretty big relationship between each thrown Molotow and lag.

One of the things I thought of was that it might be considerably cheaper to treat each block as an agent without management; the current rules attempt to manage the whole as a system and I'm feeling like perhaps you can save math stages if you just check for water, air and land to the right, left and downwards of each agent, and then apply the rules. I've done stuff like that in shaders and it's generally cheaper than central management of a complex system, because your costs are then linear. It'd also allow for a reasonable cap on total water agents to keep it performing well.

Anyhow, I'll take a look at V5; it'd be awfully nice if this could operate without significant lag for small stuff.

I also really wish it was prettier. One idea might be to cycle glows with a repeating "watery" tile of light and dark but different colors, to create a more "watery" look; the other would be to judge absolute depth and adjust the glows emitted accordingly. Both together would probably make it look considerably better

But the blocky look would remain an issue. To get it really nice with this approach, even if it could run fast, it'd need to have a glow that rendered right after the sky but before the background pixels, so that it could exceed the borders a bit and look full; I doubt if that would be a huge engine change, since it appears to do that rendering order already... but it'd be pretty specific to doing bodies of water and perhaps dynamic weather events like changing the sky.

I tested the engine-side issues, and you're quite right, the engine won't let MOPixels not reach a rest state that doesn't leave them solid, it erases a lot of pixels it shouldn't be erasing, and it's incredibly lag-inducing, to boot. So I can see why that doesn't offer a reasonable solution. My apologies for my ignorance; I really expected that part of the engine to operate very strictly according to its parameters, but like other stuff, it looks like a lot of optimization was necessary to get performance to where it needed to be.

All that said, even if this version is 10X faster, it's still too slow for anything but a minor feature on a map atm; it's not practical to do a waterfall with this, or even a big lake. Ultimately, I think the engine has to address this, with either a special type of MOPixel that's optimized for simple water behavior, or polygonal water bodies if that can't be made fast enough- that would allow for waves at a reasonable cost too. But we don't get any direct access to drawing code or the engine side so that's just pipedream.