Ever cut down all the logs and wondered why the leaves can stay there for up to 10 minutes? Me too. I propose that a trees leaves should all die off within 10-20 seconds of the logs being removed. I literally cant imagine why anyone would want them to stick around. You want your saplings, you want your apples, you want to replant in the area or build there, it just makes sense for the leaves to disappear WAY faster.
"Hey Johnny, I gonna chop down this tree"
"Sure thing bob! Why your at it, could you get me some leaves?"
"Why sure thing Johnny!"
*bob chops down tree*
"Alright, time to get me some leaves!"
*pulls scissors out of inventory*
*leaves go poof*
"What...is this sorcery..."
"Hey Johnny, I gonna chop down this tree"
"Sure thing bob! Why your at it, could you get me some leaves?"
"Why sure thing Johnny!"
*bob chops down tree*
"Alright, time to get me some leaves!"
*pulls scissors out of inventory*
*leaves go poof*
"What...is this sorcery..."
Dunno bout you but I always trim before I remove the tree. Even if not, trees are a very' easily renewable resource. I find this argument moot.
The reason is that leaves disappear on the random block updates, which occur only on 3 blocks per tick, to save up on processing them more dynamically, which would, supposedly, be laggier.
The game definitely needs a new type of "block update" that occurs much less frequently than game ticks (20 per second), but would still occur much more regularly and on average much faster than "maybe in a few seconds, but also maybe once in a blue moon".
Game ticks are 20 per second, at a very predictable speed.
Block updates are on average every 68 seconds and extremely random.
We definitely need some kind of updating mechanism occuring very regularly and in the 1 to 2 seconds range.
Maybe "layer updates": whenever a block is scheduled to have events occuring at a granularity in the 1-2 seconds range, it is added in one of the 20 layer updates in a round-robin way for that section (i.e. the 16x16x16 blocks forming the section), so that the events are evenly distributed amongst all ticks. Thus, if you add say 3 events, then 25 events, you end up with the first 8 layers having 2 events each, and the remaining next 12 layers 1 event each. This is a very fast way to spread out and allocate events, too.
Then each game tick, all the events of the "next" set of layer events are checked. This would mean that "layer" level events get an update every second. Semi-slow stuff that currently are checked on every game tick but with a low probability of something happening (so that the event occurs semi-slowly instead of quite fast), would effectively become instead checked on layer ticks, with much bigger probability of the happening, effectively reducing processing for these events by a factor of nearly 20.
This would take care of your leaves problem nicely.
I have never seen a tree's leaves despawn slower than 5 minutes. I don't think it's too long; its perfect.
Well Im glad we dont have to wait 5 minutes for leaves to despawn in the real world. itd be really annoying to have to punch out 100 meters square of leaves before building anything.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
"Sure thing bob! Why your at it, could you get me some leaves?"
"Why sure thing Johnny!"
*bob chops down tree*
"Alright, time to get me some leaves!"
*pulls scissors out of inventory*
*leaves go poof*
"What...is this sorcery..."
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe game definitely needs a new type of "block update" that occurs much less frequently than game ticks (20 per second), but would still occur much more regularly and on average much faster than "maybe in a few seconds, but also maybe once in a blue moon".
Game ticks are 20 per second, at a very predictable speed.
Block updates are on average every 68 seconds and extremely random.
We definitely need some kind of updating mechanism occuring very regularly and in the 1 to 2 seconds range.
Maybe "layer updates": whenever a block is scheduled to have events occuring at a granularity in the 1-2 seconds range, it is added in one of the 20 layer updates in a round-robin way for that section (i.e. the 16x16x16 blocks forming the section), so that the events are evenly distributed amongst all ticks. Thus, if you add say 3 events, then 25 events, you end up with the first 8 layers having 2 events each, and the remaining next 12 layers 1 event each. This is a very fast way to spread out and allocate events, too.
Then each game tick, all the events of the "next" set of layer events are checked. This would mean that "layer" level events get an update every second. Semi-slow stuff that currently are checked on every game tick but with a low probability of something happening (so that the event occurs semi-slowly instead of quite fast), would effectively become instead checked on layer ticks, with much bigger probability of the happening, effectively reducing processing for these events by a factor of nearly 20.
This would take care of your leaves problem nicely.