@Quasialias (View Post)
We can't skip any particles, because they all need to be updated. Most particles do the common 5x5 loop around them to check for other elements, but there are many elements that do things outside of this and need to be updated no matter what is around them. Checking which elements are possible to skip might somehow work, although that's just adding more checks to the game, and generally we already skip these elements that wouldn't pass the check. DMND doesn't even have an update function since it does nothing at all, so there is nothing to skip there, it's already skipped (and the movement code for it is too is skipped since it has no velocity)

I don't see what you mean by "implementing heat in a separate handler", heat is calculated in the large update loop that goes through each particle one at a time. One at a time it goes through each particle and goes through the step of calculating some velocity / other things, transferring heat at that particle, updating state changes from temperature and pressure, and then it calls the particle's update function if it has one. After that, if the particle has a velocity it will try to move it with the movement code. Then it moves onto the next particle. Separating heat into a separate loop going through all particles might even be laggier, we probably need less of these loops, not more.

And for the other heat suggestion, of course we don't update heat for elements with a HeatConduct of 0, we just skip over it.

and something like "temporal analysis" just sounds too complicated and memory inefficient, I don't really want to get into things like that that will just make it messier and harder for others to understand.

Edit: I spent a while writing this apparently
Edit2:

Also, WOOD doesn't check for FIRE. FIRE checks for things with a .flammable property. Generally we put things like this in the better element to prevent constant checking for no reason, so we do think of the small things too. And yes, we iterate through every particle once per tick (maybe slightly more but it's really update_particles_i that's the slowest). We aren't iterating through n particles n^2 times though ...