Fix //hollow not behaving correctly

[eztaK-red]

Overview

Fixes #3083

Description

Turning the mutable position vectors of the region iterator to immutable ones, to allow the original implementation of the hollowOutRegion to function as expected.

Submitter Checklist

• Make sure you are opening from a topic branch (/feature/fix/docs/ branch (right side)) and not your main branch.
• Ensure that the pull request title represents the desired changelog entry.
• New public fields and methods are annotated with @since TODO.
• I read and followed the contribution guidelines.

[eztaK-red]

Result of //hollow in latest FAWE versions vs result with fix from this PR

[dordsor21]

Assuming this still works (don't see why not), lgtm, thanks!

[eztaK-red]

Oh hold up, there's a specific case for which it doesn't work

[eztaK-red]

The fix worked. The case I was just talking about was something separate. recurseHollow was incorrectly marking north-east-upwards concave corners as inside. Adding toImmutable() to a bv3 fixed it. In this case, it is not obvious to me whether there is a better way.

[dordsor21]

The fix worked. The case I was just talking about was something separate. recurseHollow was incorrectly marking north-east-upwards concave corners as inside. Adding toImmutable() to a bv3 fixed it. In this case, it is not obvious to me whether there is a better way.

Make it not immutable after adding, this current way you're creating extra BV3s

[eztaK-red]

Like this?
As far as I can see, //hollow now/still works as it should.

[dordsor21]

Like this? As far as I can see, //hollow now/still works as it should.

Yeah I don't see why it would need to be immutable here - the queue does not actually store the BV3 and stores as an index in a long array

[dordsor21]

You added the comments in the wrong place - where you added is already covered. Should be around 3301 and 3316

[SirYwell]

Looks fine. I wonder if we should change MutableBV3 to create an immutable instance on add and instead have specific mutating variants instead. But that's out of scope for now.

[dordsor21]

Looks fine. I wonder if we should change MutableBV3 to create an immutable instance on add and instead have specific mutating variants instead. But that's out of scope for now.

Mm probably, but I think that should be a forcibly breaking change in v3; relocating/renaming the class e.g.