You can use getValue in the exact way you were, you just need to specify BlockLeaves.CHECK_DECAY instead of CHECK_DECAY without the class.

How is this?

 getIBS(pos).getValue(BlockLeaves.CHECK_DECAY

Edited March 20, 20178 yr by clowcadia

7 minutes ago, Jay Avery said:

An update for anyone who's interested. I've made a searching algorithm that finds all connected trunk blocks, and connected leaves up to a certain count, starting closest to the trunk. I use it in this method, (and use the search results to make all the tree blocks fall). If anyone has ideas on how to improve the performance I'd be grateful - I know I've used several different collections to keep track of all the checking but I couldn't think of any way to reduce that further.

 

On 3/20/2017 at 9:45 AM, Jay Avery said:

An update for anyone who's interested. I've made a searching algorithm that finds all connected trunk blocks, and connected leaves up to a certain count, starting closest to the trunk. I use it in this method, (and use the search results to make all the tree blocks fall). If anyone has ideas on how to improve the performance I'd be grateful - I know I've used several different collections to keep track of all the checking but I couldn't think of any way to reduce that further.

 

I'm using a method very similar to yours. I've gone through several versions of this already. In my current iteration I'm only using two collections: one for blocks that need to be checked, and one for blocks I've already checked. The collection of blocks that need to be checked is an ArrayList. I use an iterator to work through it and only add blocks to it if they are logs and aren't in the list of blocks I've already checked. When I'm done, theoretically, it should only contain log blocks that need to fall.

 

However, I'm having trouble getting my collections to compare BlockPos objects correctly. It only seems to detect equivalents some of the time, so I always end up with duplicate BlockPos objects in my final list. Is that happening to you?

 

One idea for improving performance is to check for what type of log is being broken. If it's a birch log, for example, you only need to check logs directly above (no branches in birch trees).

7 hours ago, Daeruin said:

 

I'm using a method very similar to yours. I've gone through several versions of this already. In my current iteration I'm only using two collections: one for blocks that need to be checked, and one for blocks I've already checked. The collection of blocks that need to be checked is an ArrayList. I use an iterator to work through it and only add blocks to it if they are logs and aren't in the list of blocks I've already checked. When I'm done, theoretically, it should only contain log blocks that need to fall.

 

However, I'm having trouble getting my collections to compare BlockPos objects correctly. It only seems to detect equivalents some of the time, so I always end up with duplicate BlockPos objects in my final list. Is that happening to you?

 

One idea for improving performance is to check for what type of log is being broken. If it's a birch log, for example, you only need to check logs directly above (no branches in birch trees).

Interesting!

 

I started off trying to use an iterator but that caused ConcurrentModificationExceptions when I added to the list during iteration - that's why I switched to a Queue. How do you avoid that problem?

 

I haven't noticed any problem with BlockPos duplication but I haven't checked carefully. I'll try printing out the results list before using it and see if it does contain any duplicates. How are you checking for duplicates before adding to the results list? BlockPos uses Vec3i#equals which just compares the three co-ordinates so I can't think of a reason that wouldn't work reliably.

 

Would you care to share your code?

8 hours ago, Daeruin said:

 

One idea for improving performance is to check for what type of log is being broken. If it's a birch log, for example, you only need to check logs directly above (no branches in birch trees).

On the surface this seems like a good optimization, but I think it would break down when doing modded trees that change the structure of a birch tree.  Currently working on a modpack that has birch, oak, spruce, etc. that defy the normal vanilla growth patterns.

15 hours ago, Jay Avery said:

Interesting!

 

I started off trying to use an iterator but that caused ConcurrentModificationExceptions when I added to the list during iteration - that's why I switched to a Queue. How do you avoid that problem?

 

I haven't noticed any problem with BlockPos duplication but I haven't checked carefully. I'll try printing out the results list before using it and see if it does contain any duplicates. How are you checking for duplicates before adding to the results list? BlockPos uses Vec3i#equals which just compares the three co-ordinates so I can't think of a reason that wouldn't work reliably.

 

Would you care to share your code?

An iterator works fine if you use the iterator's add and remove methods (iterator.add). I discovered that after running into the ConcurrentModificationException and doing some more research. There's another problem, however, because the iterator's cursor is always in between elements in the collection. When you add a new object to the collection, it gets placed behind the cursor. I have to keep track of how many things I've added and move the iterator back to look at them. I'm thinking I'll switch back to a queue at this point. The only reason I wanted to try the ArrayList in the first place was to see if it was somehow more accurate with detecting duplicates in the collection.

 

I've tried using a LinkedList, an ArrayList, and now a hash set to hold the blocks I've already looked at. In each case, I just used the collection's #contains method to see if the BlockPos is already in the list. Looks like the same thing you're doing here:

 

if (!checked.contains(toAdd))

 

My code is currently part of a private BitBucket repository. I didn't want it to be public at first, because I was embarrassed.  I was going to post some of my code here , but it looks like it isn't possible to do spoilers or code blocks in topic replies. Unless I'm missing something?

 

Come to think of it, how do you do that monospace font in replies? All I see are bold, italic, and underline.

 

By the way, I loved your idea of using a list of BlockPos offsets and iterating through that to scan for log blocks. I tried that in my code, and it's so much cleaner than what I was doing before, which was basically a giant block of code with a million BlockPos.up().north().east() references and the like.

14 hours ago, OreCruncher said:

On the surface this seems like a good optimization, but I think it would break down when doing modded trees that change the structure of a birch tree.  Currently working on a modpack that has birch, oak, spruce, etc. that defy the normal vanilla growth patterns.

Good point! For that matter, it seems possible that modded trees could defy the pattern Draco pointed out early in this thread. For example, you could have long branches with log blocks below another log block.

I just realized another tradeoff between LinkedList and ArrayList. With the ArrayList, you can keep it around for later use. With the LinkedList, you can't look at an element in the list with removing it from the list, which requires you to store things in yet another list if you want to do something with them later. But if you do everything you need to at the time you get the element from the list, you wouldn't need to store them elsewhere.

9 hours ago, Daeruin said:

An iterator works fine if you use the iterator's add and remove methods (iterator.add). I discovered that after running into the ConcurrentModificationException and doing some more research. There's another problem, however, because the iterator's cursor is always in between elements in the collection. When you add a new object to the collection, it gets placed behind the cursor. I have to keep track of how many things I've added and move the iterator back to look at them. I'm thinking I'll switch back to a queue at this point. The only reason I wanted to try the ArrayList in the first place was to see if it was somehow more accurate with detecting duplicates in the collection.

Ohh, I remember now - I found out you could add elements to an iterator but I was unhappy about the cursor positioning problem which is why I went with a queue. That way, the elements which are added later are always searched later, so that guarantees that the leaves closest to the trunk will be selected first if the search gets stopped by the maximum count (rather than by reaching the edge of all leaves).

 

9 hours ago, Daeruin said:

 

I've tried using a LinkedList, an ArrayList, and now a hash set to hold the blocks I've already looked at. In each case, I just used the collection's #contains method to see if the BlockPos is already in the list. Looks like the same thing you're doing here:

 

if (!checked.contains(toAdd))

I did a test with printing out my results list before using it and there don't seem to be any duplicates - I can't think of a reason that would be happening for you!

 

9 hours ago, Daeruin said:

 

My code is currently part of a private BitBucket repository. I didn't want it to be public at first, because I was embarrassed.  I was going to post some of my code here , but it looks like it isn't possible to do spoilers or code blocks in topic replies. Unless I'm missing something?

 

Come to think of it, how do you do that monospace font in replies? All I see are bold, italic, and underline.

You can post code!  The eye icon is a spoiler, and the <> icon is for a block of code. And the monospace font is the tt button.

9 hours ago, Daeruin said:

By the way, I loved your idea of using a list of BlockPos offsets and iterating through that to scan for log blocks. I tried that in my code, and it's so much cleaner than what I was doing before, which was basically a giant block of code with a million BlockPos.up().north().east() references and the like.

Thanks! It backfired at first because I made the list of offsets manually and ended up missing some, so then I gave in and wrote code to print a list of all offsets so that I could copy that back into the code.  

13 hours ago, Jay Avery said:

I did a test with printing out my results list before using it and there don't seem to be any duplicates - I can't think of a reason that would be happening for you!

I figured out why. It has to do with the way I'm adding things to the list. I was checking to see if the BlockPos was in the list of things I already checked, but I wasn't checking to see if it was already in the list waiting to be checked. Because I do a round of adding stuff to the queue up front, before starting to iterate on the queue, those things were getting added to the queue twice. Should be pretty easy to fix.

 

13 hours ago, Jay Avery said:

You can post code!  The eye icon is a spoiler, and the <> icon is for a block of code. And the monospace font is the tt button.

I don't see an eye icon or <> icon. I have a single row of icons with B, I, U, link, quote, emoticon, two lists, and preview.

 

It looks like you may be doing something special with making the blocks fall. Are you just breaking and harvesting the blocks, or do you have some nifty method for making the blocks fall to the ground horizontally like a real tree? I've been messing with that piece and having some weird behavior for big oak, jungle trees, and regular oaks with branches. I think I can deal with it, but I was curious to see if you've already solved those problems.

22 minutes ago, diesieben07 said:

This sounds like the use-case for a Set.

A set won't give first-in-first-out order though, which is needed in this situation. It looks like there's no existing collection that has these exact properties (e.g. this conversation) - a LinkedHashSet might nearly work except the iterator can't be added to.

 

5 hours ago, Daeruin said:

It looks like you may be doing something special with making the blocks fall. Are you just breaking and harvesting the blocks, or do you have some nifty method for making the blocks fall to the ground horizontally like a real tree? I've been messing with that piece and having some weird behavior for big oak, jungle trees, and regular oaks with branches. I think I can deal with it, but I was curious to see if you've already solved those problems.

I make the blocks actually fall - I made a custom falling block entity that moves sideways as it falls, so that the blocks end up going roughly diagonally like a real tree. Here is my entity class - I've got slightly different behaviour for logs and leaves, to make sure that logs are prioritised as much as possible and fall through leaves that are in the way.