[1.12.2] Acquiring a list (or other structure) of Blocks around the player

[DeadPix]

Hello again!

I need to get an information about the blocks that are around the player (or a certain location) - probably for few chunks around the player. I understand that I can loop through coordinates around the player and create a BlockPos structure for each block around the player and then query them (pretty much check them in condition) on what they are, but it seems to me, that this functionality is something that should be already implemented in the game/forge itself. I looked through the documentation and there is nothing except for BlockStates, I also tried looking into the code, but am pretty much clueless at the moment.

 

What is the best way to do the following.

• Get information about 'any' block? Is it to create a BlockPos object for it and then somehow convert it to Block and find info from there? And how would I convert BlockPos to Block correctly, please?
• Get information about chunk and its composure (e.g. what blocks are in there at specific positions, or to specified 3D-depth from some position?

 

Are there dedicated structures that can be loaded easily, or do I have to manually specify every block  I am interested in inspecting? 

 

Thank you!

[Draco18s]

4 minutes ago, DeadPix said:

but it seems to me, that this functionality is something that should be already implemented in the game/forge itself

Yeah, its called BlockPos.getAllInBox(...)

5 minutes ago, DeadPix said:

Is it to create a BlockPos object for it and then somehow convert it to Block and find info from there?

...Yes, by using World#getBlockState(BlockPos)

Unless you know what block you want info about and aren't interested in "what block is over there?" In which case you can do something like Blocks.STONE.getHardness(...)

6 minutes ago, DeadPix said:

Get information about chunk and its composure (e.g. what blocks are in there at specific positions, or to specified 3D-depth from some position?

BlockPos.getAllInBox(...)

6 minutes ago, DeadPix said:

or do I have to manually specify every block  I am interested in

Yes

[jabelar]

One thing to keep in mind is that iterating through a large area will likely cause performance issues. You have to realize that the number of blocks grows rapidly. For example, in one chunk there is 65k block positions to scan! If you scan for two chunks in each direction you'll be at over 1 million block positions.

 

Due to this performance hit, there are not really any vanilla mechanisms that scan blocks for a distance. There are a lot of "neighbor" checks (like redstone connections) but they only check the next block. Thinks like bookshelves have a dedicated scan when the enchanting table is opened and it only checks a short distance for specific placement.

 

What exactly are you trying to achieve?

Edited July 25, 2018 by jabelar

[Draco18s]

5 minutes ago, jabelar said:

For example, in one chunk there is 65k block positions to scan!

Good news, looking at a block and doing nothing takes almost no time. I've benchmarked this. Scanning an entire chunk (in my case, 16384 blocks as my code stopped when it reached the surface starting at bedrock) takes about 400,000 nanoseconds (0.4 miliseconds).

 

That still limits how many chunks you can scan (if you're doing something every tick, you can probably look at 10 chunks and still be safe). If you're doing it less often (e.g. once when the chunk is generated) you can look at a lot more or schedule it (e.g. only scan one chunk every tick, but change what chunk is being scanned).

[DeadPix]

Alright guys, thank you all for wonderful replies.

 

As @jabelar asked, what I am trying to achieve - I am trying to write an 'AI' that will be walking through the lands and completing some goals (the AI takes over the player). At the very moment I am trying to come up with some reasonable path finding algo that I could further extend. I pretty much want to set target destination to which from player.posX/posY/posZ the AI will travel, and so I need to probably start with creating a structure that will represent visible surface. Is it correct?

 

And would something like this be a good approach?

• Start with figuring out on what block I am currently standing. Check block bellow and the block above on whether it is an air block to determine that I am on 'some sort' of a surface.
• Continue with all blocks around (all eight of them) the same way as above, storing only those that have 2 (or 3 - possible to jump) air blocks above them.
• Extend the 'circle' and so on and so forth, up until some distance. 

Output of this function would then be sort of a map of my surroundings on which I could then start calculating the best path. Also when I would need some specific item or tool or ore to mine, I would take it into account in the algorithm I mentioned and store these values there too so I could feed my path finding with that. 

[Draco18s]

1 hour ago, diesieben07 said:

I hope you benchmarked this correctly. The JVM is stupidly smart and will figure out that your loop does nothing and just not do the loop at all.

I did.

I specifically benchmarked an code I was doing things with. That is, I specifically wanted to know how long it was taking my code to do its processing.

That is, I have code that says "is this an block ore? no? continue. yes? do this other thing with it."

In chunks that contained no ore, it took about 400,000 nanos to process. In chunks with ore, it would take as much as 800,000 nanos (usually closer to 600,000; it depended on how many blocks of ore there were and it was usually "less" than "more" due to the distributions I was using).

 

If you're interested, here's the code. The timing was done in the event handler class around the call to this method.

(The same method in 1.12; might be cleaner)

Edited July 25, 2018 by Draco18s