TODO

Lua MapVoxelManipulator Interface

Description

Practically any mod that is more complex than the little clicky thing on the end of ink pens would want to modify portions of the map. To do this, a minetest.env:set_node() call is required for each node to be modified. It does not take much imagination to arrive at the conclusion that the performance of these mods suffer accordingly, due to not only the inherent slowness of Lua, but the overhead of Lua-to-C calls, and the overhead of each Map::setNode() call. To make matters even worse, all this must be done within an envlock, leaving the rest of the server unresponsive while the Lua mods do their thing. Absolutely disgusting.

The answer is to give the Lua API the power of the ManualMapVoxelManipulator, so nodes may be retrieved or modified through a 3d array, and then blit (if necessary) back to the map.

What needs to be done

• The API for this needs to be well thought-out - no afterthoughts or hacky looking pieces.
• The central structure of the VoxelManipulator will be the data itself - a 3D array (in Lua, a table containing tables containing tables of MapNodes), or even better, just one huge array, leaving the modders responsible for finding the index within the array (the latter would surely improve performance).
• An API to simply read chunks of map to an array without any intentions of modifying it. An envlock would only be required when initially reading from the map to the VoxelManipulator.
• An API to read chunks of map, then blit back to the map when done. An envlock is required throughout the lifetime of the object (unless you're not concerned with the contents of the map being modified in between the mod doing so).
• An API to create a blank VoxelManipulator, perhaps filled with CONTENT_IGNORE, to which the mod sets only some blocks, and is blitted back to the map (CONTENT_IGNORE nodes aren't set, obviously). Here, an envlock would only be required when blitting back changes.

LuaJIT

Description

Lua is an interpreted scripting language. As such, it is *slow*. No, really. Much of the time, it feels like the problem of Lua's slowness is the elephant in the room being avoided by adding more and more API so the actual work is delegated to the core in C++. While some may argue that Lua mods is simply the dashboard to the car, and the core is well... the engine, it cannot be argued that the amount of work being deferred onto the core is too much.

What needs to be done

• Research LuaJIT. Find out how it fits in with the current Lua interpreter, what changes would need to be made, etc. Probably not too much.
• Real, substantial benchmarks. Some within the Minetest community have commented that LuaJIT has been tried before, but the performance increases "weren't worth it", and was therefore dumped - this may not be so. Regardless, even if the performance increase is minimal 'in most cases', it must be added to not neglect the subset of cases where the benefits would be much greater. Also, 'less than optimal' is unacceptable, especially if the work to make it optimal had already been done.

Voxel Area Entities

Description

How cool would it be to build a full-sized boat in Minetest, and then drive it around the ocean? That's one example of something that would be possible with this feature.
Voxel Area Entities are moveable ActiveObjects whose mesh and texture is user-modifiable via setting MapNodes in it. This is an extremely powerful feature, and while perhaps not of extreme difficulty to implement, there is very much to be done.

What needs to be done

• A new derived SAO and CAO (they would need to be treated fundamentally differently), along with setNode() and removeNode() calls.
• A derived VoxelManipulator class, perhaps called ObjectVoxelManipulator, which will be used to manipulate them.
• These types of objects have meshes, and will need to be updated in MeshUpdateThread along with MapBlocks.
• Some way to store these in the map. Perhaps these objects will get special non-block-ID keys in the map DB.
• A decent way to serialize these objects. This detail in particular will require special attention.

Envlock Scope Reduction

Description =

Envlock needs to be put on a diet. Seriously. This is believed to be the primary reason for perceived unresponsiveness in Minetest - solving this would help matters immensely.

What needs to be done

• Add a thin abstraction layer for atomic operation intrinsics.
• Replace Environment operations that require concurrency but are simple enough with the said atomic operations and clever ordering.
• Add a thread-safe hashtable structure to be used instead of std::map (or core::map) where locks would be needed, make use of this.
• RCU for Map things - big structures such as MapBlocks could benefit from Read-Copy-Update for synchronization. This is the biggest change, but the reward would be immense.