high-level version of NKGetVoxelChunk?

skypatcherskypatcher Posts: 12
edited October 2014 in Code
Hi:

I really enjoy this game! I am trying to create a mod to scan the terrain (for debugging purpose). The idea is very simple, I use a stick to point at the ground. When I left click, the mod gets a 5x5x5 chunk centered at the block indicated by the voxel selection box. The code then scan the chunk layer by layer and write the material-id of each block in a layer to a file.

I looked at how NKGetVoxelChunk() is used in BasePlaceableMaterial:PlaceBlock(). It seems strange that the offset of min-corner is calculated after mod(32). I calculate the offset before div(32) and mod(32)

The result is funny:
1. Sometimes the scan is correct, sometimes is wrong (even if the whole chunk is inside a 32x32x32 cell)
2. If I use a thicker chunk (e.g. 7x9x5); the result is almost always wrong (especially blocks above ground).

My questions are about the following API:
NKGetVoxelChunk(chunkBlockCount, chunkMinCornerPosInCell, chunkMinCornerCellId)
1. Do the blocks in the chunk must be all inside the same 32x32x32 cell?
2. If no, do I have to sub-divide the chunk at the cell boundary and call the API multiple times?

Does this API has a higher level version, which would take two parameters only (hides the way blocks stored inside the cells):
the size of the chunk, and
the 'absolute' position of the minCorner of the chunk (by 'absolute', I mean no div/mod 32 is necessary)

Finally, is it possible to turn on the mesh of the terrain (for debugging)?
function terrainScanner:AffectMaterial()
local chunkCenter = Eternus.PhysicsWorld:NKTruncatedPositionRemoval()
local chunkMinCorner = chunkCenter - vec3.new(2, 2, 2) -- my offset is calculated before div(32) and mod(32)
local chunkBlockCount = vec3.new(5, 5, 5) -- 5 blocks in each direction

local chunkMinCornerCellId = chunkMinCorner:div_scalar(32)
local chunkMinCornerPosInCell = chunkMinCorner:mod(32) -- simple modulo, no offset here

local chunk = Eternus.Terrain:NKGetVoxelChunk(
chunkBlockCount, chunkMinCornerPosInCell, chunkMinCornerCellId)

logToFile("
")
for iy = 0, 4, 1 do -- y-axis is vertical and points toward sky
logToFile("===============
") -- (horizontal) layer by layer
for ix = 0, 4, 1 do -- x-axis is in the horizontal plane
for iz = 0, 4, 1 do -- z-axis is in the horizontal plane
local voxel = chunk:getVoxel(ix, iy, iz) -- capture the voxel
local matId = voxel:getMaterial() -- an integer in the range 0..255
logToFile(string.format( "%3d", matId))
end
logToFile("
")
end
end
end

Comments

  • TestamentofTestamentof Posts: 1,234 Seed
    What are you trying to debug?
    The Machine is on....

    6.jpg

    otViQlH.png
  • What are you trying to debug?

    Right now I just want to log the block material to a file (horizontal layer by layer) and analyse the result outside the game. I want to eventually do something with the info inside the game.

    But I encountered funny result already. The scan is not always giving me the right result. I find it particularly strange that the examples I looked at do not consider the possibility that a chunk of blocks may reside in more than one cell.

    It seems a high-level API, shielding us from all the internal data structure of the blocks/cells, would be desirable.
  • TestamentofTestamentof Posts: 1,234 Seed
    I do hope you're not developing a mining hack, that would be seriously offputting.

    I assume you have seen the Eternus API that NK put up recently?
    The Machine is on....

    6.jpg

    otViQlH.png
  • I enjoy the game. When I play the game, I play it the way as it was built, I disallow myself to use console command or enable render debug text. If the game resources/difficulty seemed unbalance, I take a break from the game and play with the sandbox/mod aspect of the game.

    I develop mods for my pleasure, mainly to see what kind of new game experience I can create. With the sandbox nature and the exposed API, I would not be surprised that other people soon develop different kinds of cheat/hack. I am not interested in using cheat/hack when playing the game myself or with others.

    I refer to the Eternus Lua API a lot. Unfortunately it is still version 0.6.4
  • TestamentofTestamentof Posts: 1,234 Seed
    I do apologise if I have offended you, I've seen several MC servers ruined because of rampant mining and PvP hacks.

    I'm afraid I'm not much for modding myself, I can never get my head around code structure and syntax.
    The Machine is on....

    6.jpg

    otViQlH.png
  • I have always been enjoyed exploring, admiring and creating virtual world. I enjoy games that allow free exploration/simulation or have stories. I am not crazy about mindless competitive multiplayer mode.

    My ideal multiplayer mode: (1) tons of fun things for a single player to do, (2) interactions between players are non-linear and natural part of the story-telling in the virtual world, and (3) sufficient checks built into the game server to prevent 99.9%+ players from cheating (harmless mods are OK).
  • GrimGrim Posts: 15 Developer
    The VoxelChunk stuff will be deprecated and removed with the new terrain! It will probably resurface later, but for now there isn't a counter part. To answer your questions though..

    1. Do the blocks in the chunk must be all inside the same 32x32x32 cell?

    No. The VoxelChunk stuff was written so you wouldn't have to think about cells. The way that the voxels are represented is probably what is causing your problems. A cube isn't a single 1x1x1 voxel. It's really 8 voxels in a 2x2x2. You have to extend the voxel-chunk dimensions an extra +1 in every dimension. On top of that, a voxel chunk needs a corner cell (the minimum AABB corner), and a voxel position corner inside that cell (XYZ position from 0-31).

    2. If no, do I have to sub-divide the chunk at the cell boundary and call the API multiple times?
    No, you do not.

    3. There is not a way to turn the wireframe on at the moment.
  • Hi Grim:

    Thanks for the reply. Really happy to hear from a developer!
    The VoxelChunk stuff was written so you wouldn't have to think about cells.

    So NKGetVoxelChunk() is 'high-level' (cell-agnostic) already? I am confused why a cell-agnostic API would still require splitting the address of the corner block into 2 pieces: div32 and mod 32 (the intracell index, and the location of the cell the corner block)

    If a cube is really a 2x2x2 voxel, and I need a 3x3x3 neighborhood of a center (a 1x1x1 block); should I request a 4x4x4 chunk and ignore part of it? I know this question is confusing, I am just thinking aloud :) I prefer to working with the unit 1x1x1 blocks, I always choose the smaller voxel selection box in the game.

    Since I am not sure if I have the correct mental model (and terminology) of the relationships of the cubes, blocks, and cells; and that the API is going to be deprecated and removed with the new terrain; I am not sure if I want to try fixing my current code.

    I am, however, very excited about the new terrain and definitely looking forward to fixing the code to work for the next release. Hopefully you'll publish the new API, along with a brief explanation of blocks/cubes/cells. I hope the new API allows me to express everything in terms of the basic 1x1x1 block, and use absolute address.

    The new terrain is really exciting. Thanks, please keep up the good work!
Sign In or Register to comment.