Fork me on GitHub
#minecraft
<
2022-05-17
>
plexus08:05:01

Workshop prep going great šŸ˜„

šŸŽ‰ 3
plexus09:05:51

I'm releasing a new version which should make a lot of things a lot faster

šŸŽ‰ 2
plexus09:05:25

Turns out clojure.core/satisfies? is really inefficient, and I'm using it all over the place šŸ™ˆ , but it's easy enough to cache

plexus09:05:50

this new version also allows the :material in a cursor to be a function that returns a material

mynomoto11:05:32

About perf, is there a recommended way to change lots of blocks at a time? I crashed the server more times than I would like to admit šŸ˜…

plexus13:05:13

Yeah you can't lock up the server thread for too long... this might be better now with these recent improvements, depending on how much work witchcraft is doing to calculate the blocks.

plexus13:05:05

otherwise what you can do is ā€¢ wrap your code in future (or similar, take it off the rendering thread) ā€¢ chunk up your total amount of blocks and draw them in batches ā€¢ then you have to make sure any witchcraft/bukkit operations are wrapped in wc/run-task so they are scheduled on the server thread again

plexus13:05:26

(future
  (doseq [batch (partition 1000 many-blocks)]
    (wc/run-task #(wc/set-blocks batch))))

plexus13:05:33

^ something like this

plexus13:05:58

I still haven't really figured out a good way to bulk change blocks in paper, for Glowstone we have a separate optimized codepath for this... for paper I haven't been able to find something like that. There's some good stuff in WorldEdit but then we'd have to add that as an extra dependency, and also haven't really figured out yet how to use it.

plexus13:05:35

maybe this pattern could be made explicit though, (set-blocks ... {:async? true :batch-size 1000})

ā¤ļø 1