You have added a commit to your repo. You haven't created a PR yet.

Works fine for me:

$ node
Welcome to Node.js v16.19.0.
Type ".help" for more information.
> 
> function traverseDFS (root) {
...   const stack = [root]
...   const res = []
... 
...   while (stack.length) {
...     const curr = stack.pop()
...     res.push(curr.key)
... 
...     if (curr.right) {
...       stack.push(curr.right)
...     }
... 
...     if (curr.left) {
...       stack.push(curr.left)
...     }
...   }
... 
...   return res.reverse()
... }
undefined
> traverseDFS({key: 42, left: {key: 33}})
[ 33, 42 ]

That said, there seem to be multiple issues with this code:

• No tests?
• No proper module usage: Just writes its functions to the global environment (ugh)
• General graph traversal method limited to trees (binary trees even), pretty much not documented at all
• Side effects ("tests" seem to be embedded as console.log statements)

Feel free to rewrite / refactor it.

Added a function in maths to find arithmetic mean of an array.

We already have https://github.com/TheAlgorithms/TypeScript/blob/master/maths/calculate_mean.ts.

This is ultimately a tradeoff between maintainability and usability. It is IMO preferable to "pass this to client code" for multiple reasons:

• Mod code that does this themselves will have better compatibility. It is ridiculous to rely on an engine version for such minor convenience features.
• Mod code can decide on whatever conventions they prefer.
• Mod code can be abstracted away in a utility / library mod.
• Game code is even "allowed" to monkey-patch the vector table.

Adding another way to express pos:offset(0, 1, 0) will also leave you with the following forms until all code is converted:

• {x = pos.x, y = pos.y + 1, z = pos.z}
• vector.new(pos.x, pos.y + 1, pos.z)
• vector.add(pos, vector.new(0, 1, 0))
• pos:add(vector.new(0, 1, 0))
• pos:offset(0, 1, 0)
• pos:above()

New mod authors will have to learn more API functions to fluently and idiomatically use vectors.

I'd prefer to stay consistent with Lua's API minimalism here. This is something mod authors can very well do themselves with very little overhead. And really, you don't need a convenience function to save you the explicit (0, 1, 0) offset.

Agreed with SmallJoker.

There is no real issue here; pos:offset(0, 1, 0) is hardly inconvenient or unreadable.

First of all, consider the incompleteness of the proposed API: Why should above and below be special in any way? The other 4 directions also ought to be considered.

Second, the naming: above and below might create confusion as pointed out by ruben. Having this "utils" in the vector namespace is indeed "cluttering" and plain dirty, esp. if you had all 4 directions (left, right, back, front).

At this point, a cleaner API would be to just store the 6 directions - up, down, left, right, front, back - but that would be confusing with X vs Z and cluttering the vector namespace. You could use a subtable vector.dir for it, but then you lose the small benefit of fewer keystrokes.

Finally, all of this can always be left up to mods to do locally to adhere to whatever convention they consider cleanest. Library mods can help abstract it away.

First of all this is a low-priority (second class) feature request because what it calls for is already very well possible in plain Lua (although care is to be taken to do it efficiently; for large volumes voxelmanip ought to be used rather than plain get_node). Second, various workarounds exist that still leverage the C functions (such as dummy inverted groups - might be inefficient depending on the specifics).

Second, this doesn't make all that much sense and allows for many illogical combinations by default; ~nodename only makes sense as a single entry in a nodenames or neighbors table (at which point you should rather have a single invert switch on the ABM/LBM).

Third, I consider our custom strings (including group:...) a dirty API. If this were to be implemented, it should be done using clean Lua data structures.

"Increasing the power" always comes at a cost. You might have the conception that these functions are doing a linear search (and most of them are), but ABMs use indices to speed matters up. This becomes much more complicated the more you extend capabilities; ultimately ABMs are likely to be slower if using such "advanced" features. And even for the linear search you'll likely be increasing the constant factors (if done right it'll hopefully be negligible though).

I think it's a great idea to use Minetest as a SAT solver.

You need shaders to properly implement these "fake shadows" as well. You need shaders for any serious graphics programming in fact.

~~https://content.minetest.net/packages/LMD/character_anim/ is superior anyways~~