BlockPos.MutableBlockPos

[robustus]

Can someone explain to me what this does?  Ive looked around but have not seen an explanation.  Ive seen it a few times but have not needed to use it or have used other methods but am running into it would like to know it is used for.

 

Thanks

[Draco18s]

BlockPos objects, by default, are not modifiable (that is, their coordinates don't change). A mutable BlockPos object is one that can be modified.

[robustus]

ok, I think I get it.  Im looking specifically at this bit of code

 

 

  Reveal hidden contents

 private static int getColorAtPos(IBlockAccess blockAccess, BlockPos pos, BiomeColorHelper.ColorResolver colorResolver)
    {
        int i = 0;
        int j = 0;
        int k = 0;

        for (BlockPos.MutableBlockPos blockpos$mutableblockpos : BlockPos.getAllInBoxMutable(pos.add(-1, 0, -1), pos.add(1, 0, 1)))
        {
            int l = colorResolver.getColorAtPos(blockAccess.getBiomeGenForCoords(blockpos$mutableblockpos), blockpos$mutableblockpos);
            i += (l & 16711680) >> 16;
            j += (l & 65280) >> 8;
            k += l & 255;
        }

        return (i / 9 & 255) << 16 | (j / 9 & 255) << 8 | k / 9 & 255;
    }

 

 

if I have to guess this is taking all mutable blocks around a certain block to get the color of the current block, is that correct?

[Draco18s]

That chunk of code probably doesn't even need mutable blockpos objects. But yes, it looks like you are correct.

[desht]

MutableBlockPos might be of benefit where you find yourself creating many BlockPos objects - avoiding unnecessary object creation overhead is always good.  For example, if you're using a BlockPos to process many blocks, you might do:

 

BlockPos pos = startPos;
for (int i = 0; i < MAX_BLOCKS; i++) {
  processBlockAt(world, pos);
  pos = pos.offset(directionToScan);
}

 

But that creates MAX_BLOCKS short-lived BlockPos objects  (BlockPos#offset() creates a new BlockPos object each time).  Using MutableBlockPos:

 

MutableBlockPos pos = new MutableBlockPos(startPos);
for (int i = 0; i < MAX_BLOCKS; i++) {
  processBlockAt(world, pos);
  pos.move(directionToScan);
}

 

...and that's MAX_BLOCKS-1 short-lived objects you didn't need to create.

 

Of course, the official Java docs state:

 

  Quote

Programmers are often reluctant to employ immutable objects, because they worry about the cost of creating a new object as opposed to updating an object in place. The impact of object creation is often overestimated, and can be offset by some of the efficiencies associated with immutable objects. These include decreased overhead due to garbage collection, and the elimination of code needed to protect mutable objects from corruption.

  -- https://docs.oracle.com/javase/tutorial/essential/concurrency/immutable.html