Blockpos mutability issue while finding blocks

[Slit_bodmod]

I have been having trouble with an algorithm in one of the goals of a mob I am working on, this function is supposed to find a nearby cake block so that the entity can locate it however the cake seems to keep setting itself to null. After some diving i realised this was because of the mutability of blockposses but I haven't been able to find a way around it. Here is my latest version of the code.

public boolean findCake(){
	BlockPos entitypos = new BlockPos(eaterEntity);

	for (BlockPos pos : BlockPos.getAllInBoxMutable(entitypos.add(-40, -40, -40), entitypos.add(40, 40, 40)) ){
		if( isCake(entityWorld.getBlockState(pos).getBlock()) ){
			cakePos = new BlockPos(pos).toImmutable();
			break;
		}
	}
	return cakePos == null;
}

I have tried all manner of things when it comes to transferring the data into my cakePos variable (which is a class variable in the goal).

I have tried calling pos.toImmutable, I have tried calling the x, y and z values of pos and putting them into BlockPos instead, I even tried saving them as integers independently and waiting until after the for loop to construct my BlockPos.

 

I also at points in my code logged cakedPos, what i found was that inside of the loop it would print the coords however outside it would say that cakePos only holds null, apart from occasionally seeming to log twice, once saying it existed and then saying it had been set to null which I found incredibly strange.

 

I have now looked up how other mods have done it and most recently changed it all to use getAllInBox( bla bla bla).foreach( pos -> {...}) and made sure while doing this i called immutable and such.

I am very confused.

[LexManos]

Are you SURE you wanna search 531,441 spots for cake... All in one loop, presumably all in one tick?

The answer is no, that's a horrible idea.

Secondly, BlockPos IS immutable. The point of the toImmutable is to convert the MutableBlockPos to BlockPos.

So either remove the new, or remove the toImmutable

 

Third, are you sure it's actually being set? toImmutable will never return null so it's most likely that you're not being hit at all, or that something else is unsetting it.

[Slit_bodmod]

Thankyou,

Firstly, yeah I thought that seemed like it would take a while but most approaches I've seen use this and I was too focused on trying to fix this. If you have any faster way of searching an area that big I would appreciate it greatly.

 

Secondly that's what I thought but like I said this just happened to be the final iteration of a long series of attempts made to get this to work.

 

Thirdly when I put a log statement in before the break, that fired and said the pos existed and the second log i put in (before return) said it did and then didn't. 

 

Seeing as this logged two things, what I assume happened is that the whole find cake function is called twice, once after the other, on two seperate areas, one with cake and one without, or something like that.

 

Find cake is called once and only once by the goals shouldExcecute function (now I've said/written that outloud/in Helvetica I might inline it) and my tick function then uses the cakePos set as an attribute and startFunction does not interact with the cakePos or any cake related functions, it does clear the navigator and set the entity state to (byte)10 (I don't know why but it looked like I should include it). I assume then that shouldExcecute isn't called twice, nevermind with different results before the first tick but I really don't know.

Again thankyou,