Missing trigger differentiation on fabric
imaron85 opened this issue ยท 4 comments
The Spigot Version of Dynmap has a very granular configuration of what triggers a rerender of a tile.
I turned to fabric, as we have many technical players and can not have redstone update order/etc messed up. Our biggest concern considering the new server I set up, is performance. It appears that the Spigot branch allows me to only trigger rerender on player caused updates. This appears to be missing on fabric. I can not have dynmap rerender a chunk, every time redstone activates or a piston moves a block. Neither if tnt blow something up or anything similar caused by farms and the such.
Is there a solution? Am I missing something?
Also, I am running both DimensionalThreading and C2ME. Will they interfere with Dynmap, or even benifit it?
Fabric port uses mixin to hook the block update event so it's possible (but could be tedious) to hook the specific types of updates and handle them separately.
Also, please evaluate your Dynmap performance using the Spark profiler. Most of the map processing happens in a separate thread so it doesn't affect MSPT; I have ran complex machines like world eaters without a visible performance penalty. I would risk saying that the vanilla light engine has way more performance issues than Dynmap (also one reason to use Starlight).
I don't think it is possible to differentiate what caused the block update on fabric, as the updates are provided by the server itself, for your other question, no I don't know whether dynmap will benefit / they will interfere with dynmap at all. maybe @kosma has an answer to this question?
Really sorry I only saw this now. Yes I'm running Starlight already, minecraft itself is truly a piece of garbage performance wise.
If you say worldeater won't obliterate dynmap, I might as well just turn it on and hope for the best..
Should I leave this open, in case anybody ever gets around to it? I am a programmer, but I am not touching Java/Kotlin... ever again...
Also thanks for tip with using Spark profiler. That's actually something I wasn't aware of. ^^