DS
DS
Can reproduce. But it depends on `client_mesh_chunk`. If it's not 1, the area where the issue appears seems to appear in the wrong mapblock(s). Looks like there's some bug in...
> maybe related? #13463 Yes, definitely. You can set client mesh chunk to 1 if you want to search for the actual nodes causing this for you. >Would guess it...
I've [tried some things](https://github.com/Desour/minetest/tree/tmp_blend_overlay_tiles_perf). * Setting the hardware mapping hint to `EHM_DYNAMIC` doesn't fix the issue. * Rate-limiting transparency sorting doesn't fix it either (it's either way just done once...
Does not preserve perfect transparency sorting, but here's a workaround: #15115
Imo a function for getting the game time (i.e. by exposing the time value used by core.after) would be be better. It would be more general (e.g. would also work...
Oops, I actually wanted to implement this but never came to it. (Adding it to a milestone this time so I don't forget. (Doesn't mean it can't be implemented before.))...
The problem with this obvious solution is that it's not the start time of the current server step, but the start time of the current globalstep callbacks (assuming after's globalstep...
Idk if it will cause problems in practice or not. What is happening now is that if you use core.after in a nodetimer callback for example, it will run in...
Yes, I guess. (Document that `get_global_time` and `after` trigger on globalstep or so.) Would you prefer me or you to open the PR?