New BlockTracer classes

[xoft]

Lately I'm carrying this idea in my head, so now I'm gonna dump it here for peer analysis.

The current cTracer class is weird. I have tried several times to understand how it is used, but failed every time. Also, it seems to do one job only, so if we needed something very similar but a little bit different, it couldn't do it.

What we'd need is a generic BlockTracer class that would "enumerate" all blocks within a certain path. Let's say we need to simulate entities' movement. So we need to know when each entity hits a wall in the direction they're moving. Or, we need to simulate a projectile, again wall-hitting. But this time, rather than a straight line, it might be better to use a parabolic trajectory instead. Or we need to determine if a monster sees another entity; it's again a line traced through the blocks, but this time we're not only looking at walls, but also transparent materials. I'm pretty sure you now get the picture.

What I'm proposing is quite simple at first: a cBlockTracer class that would call a callback function for each block in the trajectory, until the callback returns a "finish" value instead of "continue". Then, we could make descendant classes that provide the trajectories - line, parabola, etc. Or the trajectories could be fed in through a template.

Using this class should be pretty straightforward: declare the callback to use, then create an instance of this class (+ trajectory) and call its Trace method with whatever parameters it takes.

As for the Lua API, this should be made available; at least the basic trajectories, if not completely custom.

Questions / decisions:
- How to feed in the trajectory
- How to feed in the block data
- Reactions for out-of-world?

[NiLSPACE]

Maybe also an idea is that you can "create" a whitelist/Blacklist of blocks it should not detect. for example if I add 1 to the white list it continuous to trace until it reaches a different block.

[xoft]

Actually the idea was that the tracer would keep tracing until the callback returned "no more", so effectively the callback decides when to stop.

[NiLSPACE]

That is probably a better idea yes.

[xoft]

Since I've dumped this idea here, I'm seeing more and more places where this kind of tracing would become useful. I'm starting a Git branch to work on it.

[bearbin]

Sounds good.

[xoft]

Getting this to work with Lua will be quite a chore.

[xoft]

It seems that the basic line tracing works now. I'd like to export it to Lua for the plugins to use, but am still not sure on the interface.
The best candidate so far is the approach taken by LuaExpat: the Trace() function would take the callbacks wrapped as a table of named functions, so it would look something like this:

local Callbacks = {
  OnNextBlock = function(a_BlockX, a_BlockY, a_BlockZ, a_BlockType, a_BlockMeta)
    -- handle the block
    return false;
  end
  OnNoMoreHits = function()
    -- handle the end of tracing
  end
  OnNoChunk = function()
    -- handle out-of-loaded-chunks
  end
} ;
cLineBlockTracer.Trace(World, Callbacks, StartX, StartY, StartZ, EndX, EndY, EndZ);

What do you think?

[NiLSPACE]

Seems good.

[bearbin]

It seems ok.