Description (Required)

Woodcutter androids no longer chopping down whole trees (stops after a few blocks).

Steps to reproduce the Issue (Required)

Attempt woodcutter android on tree as usual and inspect results.
https://imgur.com/a/DtfvfFZ

Expected behavior (Required)

Entire tree to be chopped as usual.

Server Log / Error Report

No log activity.

Environment (Required)

[15:44:13 INFO]: Paper v1_14_R1 (209)
[15:44:13 INFO]:
[15:44:13 INFO]: CS-CoreLib vDEV - 77 (git 6e171836)
[15:44:13 INFO]: Slimefun vDEV - 284 (git b36f9cd)
[15:44:13 INFO]:
[15:44:13 INFO]: Installed Addons (12)
[15:44:13 INFO]: Barrels vDEV - 7 (git 0d14dd9f)
[15:44:13 INFO]: SlimeXpansion vDEV - 4 (git 5bf10c29)
[15:44:13 INFO]: ExtraGear vDEV - 3 (git de222ab7)
[15:44:13 INFO]: ChestTerminal vDEV - 17 (git 933a7d36)
[15:44:13 INFO]: EmeraldEnchants vDEV - 5 (git 6adbbb87)
[15:44:13 INFO]: HotbarPets vDEV - 20 (git cd87bc60)
[15:44:13 INFO]: ExoticGarden vDEV - 22 (git a855f5b7)
[15:44:13 INFO]: SoulJars vDEV - 4 (git 4a600aa2)
[15:44:13 INFO]: SlimefunOreChunks vDEV - 2 (git 24d90a3e)
[15:44:13 INFO]: ElectricSpawners vDEV - 5 (git c3f8cc9d)
[15:44:13 INFO]: ExtraHeads v1.1
[15:44:13 INFO]: ColoredEnderChests vDEV - 7 (git 6885cb88)

Should also note that recent "performance improvements" (283-284) builds have had the reverse effect... dropping server to about 10fps average (with only 4 players on). I reverted to build 280 which runs fine performance wise but does have this same issue with the woodcutting androids.

Have any timings? I haven't noticed a single dip, Cookie had a performance drop and fixed that problem. I believe he was fine after that though.

We really need timings to see where, what and when.

Well, I'll have to run a later build again to generate them, sorry I didn't think to at the time. I gave it about 20 minutes or so then reloaded with the earlier build to see if it resolved it and it did so I haven't messed with it since then... we tend to be busier over the weekend so I probably won't do rebooting again till monday, I can try then and see.... I could do some timings on my local machine for you but that's probably not going to be a very helpful information source since there'd only ever be one user logged in and since I'm playing on the same machine running that "server", it doesn't get a ton of ram either. Probably only useful timings would be from the real server and I can't get that till after the weekend. But I certainly will then (probably open another ticket for that issue now that I know what you need for it) unless he finds something obvious before then and puts more builds that fixes it before I get to it.

Thanks, yeah please make another issue for it. If you can reproduce it locally then that is still something to work from, my guess is it is due to load of multiple players or just lots of blocks/items. Any info you can give is great.

But that isn't the topic of this issue. As for this one, from what I can tell nothing has changed and it still uses the old way of calculating trees. So from a quick look, /shrug

Well i'm not sure which build changed things but I'm pretty sure the order of block destruction seems to have changed... like I feel like it used to proceed bottom to top... for each section of tree... clockwise if you're looking down at it where as now it looks like it goes bottom to top... then top of the next section to the bottom... then from there back to the top... snaking it's way through the available logs which I'm pretty sure it did not used to do. I'm not sure about the lag situation now since I have people griping about the current build (280) saying pretty much the same thing and the server's tps isn't falling below 20.0 very often for me so I'm not certain about there being problems here. I put a timings report for the current build in case it reveals something... slimefun showing 61% of usage in this which may well be typical, I haven't checked it in awhile. https://timings.aikar.co/?id=f1ff9e9c2d0c4b70843ec9f93ab4b2f7#plugins

Yeah slimefun now at 81% of with only 2 users on in build 289, significantly worse.

Well, post a Timings report...
Also run /sf timings and post the result here.