Gwanin fellas, guess who?

 

Right, so I'm making a quarry which you can find the important code for here: https://github.com/MistaOmega/Opes/blob/master/src/main/java/mistaomega/opes/tiles/TerraEngineTile.java

It works fine, pls ignore the mess, I haven't tidied it yet, just got it basically functional

 

So the issue I'm having is storing the block position for where it last mined, so if it's broken, and replaced, it can keep going

I've tried getting the x, y and z coords, storing them in an int array and putting that in NBT and that's all well and good but the problem is that when placed, the constructor won't be able to instantiate a starting position (blockpos comes up as null, because it's being constructed), so I need a boolean flag to get the block pos first tick (runOnFirstTick) (i've got rid of that saving btw, but I pinky promise it was there)

Which then becomes an issue after making the block because whatever I saved just gets replaced, or at worst, comes out as null because "currentMiningBlockPos" is null from beforehand.

 

At this point all I'm wondering is, is there a simpler way to go about this that I'm missing.

 

Thank you all as always ❤️

You see this method?

https://github.com/MistaOmega/Opes/blob/master/src/main/java/mistaomega/opes/tiles/TerraEngineTile.java#L198

Do you see any code related to the mining position there?
No?

Why not?

3 hours ago, Draco18s said:

You see this method?

https://github.com/MistaOmega/Opes/blob/master/src/main/java/mistaomega/opes/tiles/TerraEngineTile.java#L198

Do you see any code related to the mining position there?
No?

Why not?

So I tried that before, I was storing the blockpos as an int array. but you see in my tick method, where I have the runOnFirstTick, that resets whatever I put as a stored value, and I need it because without it, it breaks as it can't get it's own position I'll try storing the boolean flag aswell, it might help my problem, I'll have another shot at it when I finish work 

 

Thank you

1) Because you don't save that variable either and

2) You could do without it entirely by storing garbage data in the BlockPos by default (say, a y value of -1) and if the data is garbage after read has been called, do the thing you currently do in first tick.

3 hours ago, diesieben07 said:

Uh, yes it can.

TileEntity#getPos. You already use it...

Doing it on the construction phase returns null because it hasn't been placed yet, apologies, was at work rushed the response. I stated about it in the original post 

3 hours ago, Draco18s said:

1) Because you don't save that variable either and

2) You could do without it entirely by storing garbage data in the BlockPos by default (say, a y value of -1) and if the data is garbage after read has been called, do the thing you currently do in first tick.

See this is why you're the smart people here, thank you for the help, I'll give it a go, see how it ends up 

Edited June 8, 20205 yr by MistaOmega

6 hours ago, Draco18s said:

1) Because you don't save that variable either and

2) You could do without it entirely by storing garbage data in the BlockPos by default (say, a y value of -1) and if the data is garbage after read has been called, do the thing you currently do in first tick.

Turned out not to need the garbage data, kept with using checks for null positions, just ditched the run once flag for a check if the mining pos was null although I might still add it for "cleanliness" made sure I implemented the getUpdatePacket method for reading and writing the NBT value on entity tick and it works a treat, thank you again

Edited June 8, 20205 yr by MistaOmega

3 minutes ago, diesieben07 said:

Yes, doing anything in a TE constructor is pretty pointless and leads to confusing things happening.

I'll be sure to avoid it in the future, ended up realising "oh yeah, it won't know where it is, doesn't even exist yet" and felt like an idiot for a solid 10 minutes