Optimized scanning?
Closed this issue · 32 comments
Describe the feature
I notice the game tanks if it scans too many blocks (ie intertwined mangroves), this only occurs as you are currently looking at a valid log while holding an axe.
Oddly enough this doesn't occur with SHIFT_DOWN, are you scanning differently for INSTANTANEOUS?
ok this example may be kinda horrible but with the max scan size and max size at 100,000 it causes no lag breaking it, there is a noticeable delay since the furthest blocks are a few thousands logs away on the chain but yes, no lag.
took me a second to find one of the farthest logs in the video so I marked it with pillars to show the distance
I tested out this similar mod,
https://modrinth.com/mod/tree-harvester
It has much less configurability but it handles instant tree felling without a laggy scan function, is it just because yours counts the blocks?, surely there a way to apply a limit to how many blocks can be broke without the resource expensive scan.
I'm curious, all of your examples have clear endpoints, what happens if there is a loop in a tree? what is farthest then? does it know not to scan infinitely?
Oddly enough this doesn't occur with SHIFT_DOWN, are you scanning differently for INSTANTANEOUS?
No difference between the different breaking mode.
Basically FallingTree will work in 2 phases, detection and then breaking.
Stuff that impacts detection are the max scan size, detection mode, required leaves ; but not the breaking mode.
The breaking part simply takes the result from the detection and performs the actual breaking.
This is only a scan size of 500...
Search radius is -1 however
Search radius probably won't change much, you'll hit the max scan size earlier, maybe.
However what i can see from the video, all those linked trees seems to be very very dense (like not much air blocks in between). So seems normal that with a max size of 500, you'll scan a ton of blocks to see if they are logs or not. Imagine that for each blocks it potentially scans 26 (27 - 1 as it's a cube and we don't scan the same one) other blocks. So you quickly get in the thousands of blocks that have to be scanned. Lowering the max scan size probably will help present this.
ok this example may be kinda horrible but with the max scan size and max size at 100,000 it causes no lag breaking it, there is a >noticeable delay since the furthest blocks are a few thousands logs away on the chain but yes, no lag.
took me a second to find one of the farthest logs in the video so I marked it with pillars to show the distance
Maybe the server is still processing things? Like around 34s we see floating fern (dunno if it's supposed to or not) and around 40s we can see a block reappearing. Sounds weird that the behavior wouldn't happen on a larger limit.
I tested out this similar mod,
https://modrinth.com/mod/tree-harvesterIt has much less configurability but it handles instant tree felling without a laggy scan function, is it just because yours counts the blocks?, surely there a way to apply a limit to how many blocks can be broke without the resource expensive scan.
Maybe it's time to change mod :)
But from what i quickly looked, seems like this mod is a bit more restrictive on tree detection. It'll only scan logs within a height of 30, and in a 3*3 squarre. So I'm not sure it can compare to what you have with falling tree and the max size = 500. You're maybe more at a maxSize = 270 or something. Also as you said it has less settings, so it probably do way fewer checks.
I'm curious, all of your examples have clear endpoints, what happens if there is a loop in a tree? what is farthest then? does it know not to scan infinitely?
It doesn't scan infinity, every position that has been scanned won't be scanned again.
The furthest, it's the furthest in terms of distance from your hit location. You have to imagine that the scanning is done in a succession of steps where each "branch" are progressed 1 by 1. So it won't scan 1 branch until the end, and then come back. More like water spreading on a flat surface, it spreads more and more into a sphere around the hit point (followign the trunks/leaves).
I'll have to try on my side to see if I can reproduce, but it probably just boils down to a max scan size being too high. But will still if thinfgs can be done.
Even at a max scan size of 50 it still really chugs looking at a large tree.
https://streamable.com/po01cn
I believe it would be fine if the scanning happened after you broke the block but since it occurs just from looking at the block, it bricks sometimes before you could even try to cut it.
If this is ran on a server it will freeze the whole world anytime someone looks at a tree.
Perhaps there is an optimization mod that hurts this? Or 1.20.1 for this mod is just outdated?
I'm also a bit confused on if I should be duplicating the leaves into the other one, from my understanding only leaves that decay naturally should be in the first list? Does SHIFT_DOWN break non-decay leaves?
Falling tree doesn't do anything "when you look at it".
It does things when the log is broken.
Maybe a starting point would be to reproduce the behavior with just fallingtree and that mod adding the trees. See if it happens or not.
Also, maybe removing just fallingtree from the pack may still produce those lags and indicate it comes from something else.
Regarding the leaves, you probably shouldn't have them in both.
Allowed leaves will trigger the fast decay on them.
Allowed leaves non decay will use your axe to break them like logs.
It seems like alone it doesn't "pre-scan", but it is definitely from this mod, it only occurs when looking at wood and holding an axe, switching to SHIFT_DOWN removes it entirely, so doesn't removing this mod.
I tried same config on a profile with just falling tree and a huge block of acacia wood and that was fine.
It must be another mod that moves the scan to be preemptive, any ideas?
https://drive.google.com/file/d/1QTTpRMnTyBuknOmpfpA79wHaQXTngP-L/view?usp=sharing
You can test it with the pack and reproduce it with the mod, with other config settings for the mod, without the mod, and you can see its definitely happening when looking at a log with an axe in hand only when this mod is installed without even trying to break the log.
As I said, FallingTree does nothing "when you look". So if it happens even if you don't start using your axe, then it cannot be fallingtree.
Seems like you have "speedMultiplicand" set to a different value. That will cause the tree to be scanned twice. Once when you start breaking the log (to know how long the breaking should take). And a second time when the log is broken, to perform the breaking.
Though, still nothing happens "when looking".
You have leavesBreaking=true but also have the mod Fallingleaves, seems a bit like a conflicting thing.
I cannot reproduce, FT works as expected with your modpack.
Even looking at the trees (which FT has nothing to do with) does not bring any lag.
It seems like alone it doesn't "pre-scan", but it is definitely from this mod, it only occurs when looking at wood and holding an axe, switching to SHIFT_DOWN removes it entirely, so doesn't removing this mod.
Try you modpack without FallingTree. If it still happens then you'll have to look elsewhere than this mod. I think you're a bit too sure of yourself, though FT does nothing "on looking". So try it first without FT to be sure. Will save up time for everyone to do things in order and be sure ratehr than havign assumptions.
I already did test it without falling tree, the lag only happens with falling tree installed.
FallingLeaves is a particle effect.
https://modrinth.com/mod/fallingleaves
I cannot reproduce, FT works as expected with your modpack. Even looking at the trees (which FT has nothing to do with) does not bring any lag.
Did you look at a 10000+ block tree or were you looking at a normal tree? I got 16 gigs on my pack and it shits itself
With FT
https://streamable.com/5vsxui
With only FT removed
https://streamable.com/tw04m8
Note that switching from INSTANTANEOUS to SHIFT_DOWN also fixes the lag
Seems like you have "speedMultiplicand" set to a different value. That will cause the tree to be scanned twice. Once when you start breaking the log (to know how long the breaking should take). And a second time when the log is broken, to perform the breaking.
Though, still nothing happens "when looking".
Trying with speedMultiplicand at 0.0 instead of 0.33 also fixes the issue
https://streamable.com/735c2c
(dw about it not working at the end that is like a hundred trees bunched together, you can see it calculating the durability loss, I'll cap the blocks broke at once when I play)
It seems like the "scanning" frame loss is from the speedmultiplicand feature, maybe an optimization mod pre-calculates the time it will take to break a block to aid in the server ticking? It may be scanning all of the blocks every second/fraction of a second just from looking at it. When it is 0.0, it only calculates the one block.
Did you look at a 10000+ block tree or were you looking at a normal tree? I got 16 gigs on my pack and it shits itself
I don't know if it's a 10k+ one, tried to find a large one but didn't count. However setting the maxScanSize to 500 made it so that the breaking happens almost instantly whatever the size of the tree.
Note that switching from INSTANTANEOUS to SHIFT_DOWN also fixes the lag
This is probably because you have speedMultiplicand changed. With SHIFT_DOWN the speed multiplicand option is not applied as it does not make any sense, you just break 1 block.
Trying with speedMultiplicand at 0.0 instead of 0.33 also fixes the issue
To me it does not make any sense that just looking at the block it triggers that part of the code. FallingTree just wait for the event fired by forge to get the breaking speed. Maybe you have a mod that will trigger that event to display some info about the block upon looking? But I can't help you with that, I don't know the mods.
Best option to find out is to remove half the mods each time. Remove half, if it still happens then the mod that is triggering FT is still here, otherwise it's in those you remove and you'll have to swap them (and keep FT).
It seems like the "scanning" frame loss is from the speedmultiplicand feature, maybe an optimization mod pre-calculates the time it will take to break a block to aid in the server ticking?
It doesn't work like that. Break speed is calculated on both the server and the client. It isn't a value passed by the server to the client.
Pre-calculating can't really be done, you need to find the tree fully (respecting the FT settings) to know how many blocks are about to be broken to then apply the percentage you choose (unless it's 0 where we already know in advance whe consider just one block).
It may be scanning all of the blocks every second/fraction of a second just from looking at it. When it is 0.0, it only calculates the one block.
Scanning every seconds wouldn't be efficient, most of the time people are not breaking trees. Plus it relies on forge own exposed events to compute the breaking speed only when needed. And when needed = when you start hittign a block.
You probably have another mod triggering the event in order to retrieve that breaking speed upon looking.
As it is I cannot do anything regarding this. Either you have to set the speedMultiplicand to 0 and so it'll basically compute nothing when that event is triggered. Or you'll have to find out what is triggerign that event upon looking and see if you can/want to disable that feature.
The only optimization i can do is remove that feature entirely, which is the same as setting its value to 0.
Maybe you have a mod that will trigger that event to display some info about the block upon looking?
oh yeah that makes it really obvious lol
Its Jade, removing it makes it only lag WHEN breaking the block
Its been there the ENTIRE TIME, Jade displays how far you are into breaking the targeted block.
So I'll close this issue for now. It'll be for you to decide the tradeoff and choose either betwwen removing Jade (or at least that progress abr thing), or have the speedMultiplicand set to 0.
I left an issue on jade explaining how it makes a wack recalculate loop. I have the setting set to 0 in the meantime.
Does CUT after too big of scanning? like if it scans 500 blocks out of 10,000 and it breaks 100 will it break the 100 of that 500 or will it abort instead of cut due to the scanning size?
Not capping the scan size with CUT, LOWEST_FIRST is definitely fastest for finding which blocks to break, only takes a second to return
obviously, it lags but this is the whole forest cut down in one swing with 100,000 max size
https://streamable.com/alak43
https://streamable.com/t6cya6
How come there is not highest first break order? I'm stuck either not capping the size and breaking everything at once or getting floating tree bits since it does the tops of the tree last? I assume it just return the lowest y value what about the highest y values?
searchAreaRadius has infinite y reach yes?
I have it set to 15, and the max size and scan really high
wondering why it seems to give up sometimes
does the area limit hard stop it from scanning past the area or does it still try to scan it, does it abort if it hits the area limit?
I edited some of the code to make a custom merger of SHIFT_DOWN and INSTANTANEOUS
https://streamable.com/6k1fwb
(cutting out a ~32x32 region of my fucked up little forest)
https://streamable.com/aaflwe
The only thing that bothers me now is if I don't have the leaf requirement for shiftdown added than it can break logs players placed in a house, usually minor if its 1 block at a time but breaking 5 or 10 blocks at once can grief yourself hard if not careful
I heard somewhere this mod tracks if logs are player placed or not, is this true?
That's a lot of thigs haha. Seems like you manage to figure out a bit of the internals as you go through code.
I heard somewhere this mod tracks if logs are player placed or not, is this true?
It doesn't. FT simply scans logs. The only way to know if a tree is natural, is by checking the leaves as a player will never be able to place a leave with the metadata preserve=false. So indeed, if you remove the minimum leaves requirement, you expose yourself to potential griefing of player structures.
I ended up just making the breakspeed divisor a constant from the config and // out the scan
this is where I am now
https://streamable.com/4azyrm