I did not find an opportunity to send a private message on the Git, so I decided to open this question as an "issue".

• Minecraft 1.12.2
• DimensionalPocketsII-1.12.2-3.1.24

The point is that, for my personal game, I wanted to change the height of the walls generation to the maximum (up to 256 blocks). The reason is that I can "chunk loading" the entire chunk, but only use 14 blocks of height. Of course, you can dodge this rule and use any objects that allow you to teleport through the wall to get to the upper blocks ... But I would like everything that I build in the chunk to be somehow protected by walls.
I tried to change this on my own - in the file com/zeher/dimensionalpockets/pocket/Pocket.java i changed the values in the function generatePocket(), in particular this lines of code (if you look through the git):

129:	for (int y = 0; y < 16; y++)			->	for (int y = 0; y < 256; y++)
132:	boolean flagY = y == 0 || y == 15;		->	boolean flagY = y == 0 || y == 255;
143:	else if (x == 14 || y == 14 || z == 14)		->	else if (x == 14 || y == 254 || z == 14)

but the mechanic of teleportation to the dimension stops working in the game: when you shift+click to the block - nothing happens.
although, if on the contrary - lower the height to less than 16 blocks, then everything works (8/7/6, for example, then actual height where you can build is 6 blocks)
What am I missing in the code? Maybe there is somewhere similar limitation on checking the height that i missed? I would be grateful for any hint.

Hi,

When teleporting out of a Pocket, and just when retrieving the Pocket when inside in general, it does take into account the chunk height as well as the X & Y coords.

This is because chunks are stored as 16x16x16 objects. Not 16x256x16. Without changing significant code it is not possible. I will however add this as a config option in a future release of the 1.16.3 version.

If you want to attempt this yourself, PocketRegistryManager (com.zeher.dimpockets.pocket.core.manager) should be a good starting point. A custom object will most likely be required, to store the (X, Z) coords not (X, Y, Z): See BlockPos.

I have changed this in the 1.16.3 version. A release is coming soon, but it pertains to the Chunk vs the ChunkSection. Instead of applying the blocks to a Section of a Chunk, I instead use the entire chunk. This nullifies any stackoverflow errors. I have also including 2 config options. One is a slider from 15 to 255 which modifies the Pocket height. The other is force option, as I have implemented code to retrospectively update a Pocket if the config option is changed.

I have also written a new Class, ChunkPos which just stores an X and a Z value. Makes the whole thing smoother.

Hi. Thank you very mush for your explanation. I really not know that chunk build from sections 16^3 (after your explanation, I also read about this in the wiki (https://minecraft.gamepedia.com/Chunk_format) - img1). This information give me idea what to do next. (and I'm sorry for ignoring your suggestion about the PocketRegistryManager - at that time it seemed to me too complicated to solve my idea =/ )
So firstly i wanna apologize for my late answer. I just first wanted to check if this idea would work and if so, explain what I did. So it took longer than I thought (mostly because i wanted to remake for the latest playable version) but more on that later - now i'll explain my idea.
My idea: if we generate blocks in sections of 16^3, then in order to increase the height of the walls to the maximum (256 blocks), we only need to call this generation 16 times(for sections from 0 to 15).
What i do: as follows from the idea - put the generation in the cycle 16 times. but at the same time I also slightly changed the conditions for the "flagY" variable (check only at 0 and the last cycle) and "y" in the second "if" when checking the generation of BLOCK_DIMENSIONAL_POCKET_WALL_EDGE (also check only at 0 and the last loop). the example code I added below, in the file generatePocketDiffs.txt
So the result was what I originally wanted - the heights of the sides are generated up to the 256 block. (img2 & img3)
All these changes took me not much time and I could be content with that, but there was one problem - I originally played on version 3.1.34-beta-universal(downloaded this version from CurseForge somewhere over a year ago) and the source code I worked on - was from version 3.1.24. in that version there is no description for many things (like it must be "Some text" but it was "com.zeher.DimPocket.description" - something like that). So I decided to pay my attention to the version 5.2, but the situation looks about the same: lates version for game is 5.2.80, but source code only for ver. 5.2.61 and it has same problem - there's no sensible description. As a result, I spent a lot of time on deobfuscation, fixing errors and then compiling the mod on version 5.2.80. And I did it. But, i got a little problem: in the final jar-file, in places where the description color changes (through the "§" sign), there is a "B" symbol in front of it(img4 & img5). after deobfuscation, the code is clean, but after compilation it appears. This can be fixed simply by removing the symbols for painting the color, but it seems to me that then that part of the mod's peculiarity is lost. I've searched through many forums, but haven't found any similar cases or tips on how to fix this (without resorting to my way).
So I want to ask for your help a second time: can I somehow get access to the src-files of version 5.2.80 or can you tell me about how this two versions differ (of course I can check file by file, but it will take a very long time, so I thought that you can help with this), or at least suggest me how to fix my problem (with "B" character), please?
Img1:

Img2:

Img3:

Img4:

Img5:

Source changes:
generatePocketDiffs.txt