For the command //maze sand 2 1:
In a selection with even lengths on x and z there are 2 extra layers radiating from pos2:

In a selection with odd lengths on x and z there is 1 extra layer radiating from pos2:

As WorldEditAdditions grows, so too does the number of commands we have - and the documentation thereof.

It would be of significant benefit if we could display our own formspec-based help GUI that automatically parses Chat-Command-Reference.md. /help for example does this already to display the current commands categorised by the mods they are from.

A sensible direction to head in might be to integrate with the doc mod. The API thereof can be found here: https://repo.or.cz/minetest_doc.git/blob/HEAD:/API.md.

Care must be taken here to keep a single source of truth for our documentation - that way it'll stay easy to update.

Flower Field

Make a flower field with no grass.

//overlay air 20 flowers:geranium 1 

Adjust the air value to change flower density.

//overlay air 80 flowers:rose 1 flowers:tulip 1 flowers:dandelion_yellow 1 flowers:chrysanthemum_green 1 flowers:geranium 1 flowers:viola 1 flowers:dandelion_white 1 flowers:tulip_black 1

When working with many types of flowers the air values need to be higher to compensate. The best equation for the air value that I've found is <desired spacing> * <sum of flower probabilities>.

Grass Field

Make a grass field

    //overlay air 36 default:grass_2 2 default:grass_3 2 default:grass_4 1 default:grass_5 1

Adjust the air value to change grass density. As with flower field the best equation for the air value is <desired spacing> * <sum of flower probabilities>.

ERROR[Main]: ModError: Failed to load and run script from /home/user/.minetest/mods/worldeditadditions/worldeditadditions_commands/init.lua:
ERROR[Main]: .../worldeditadditions/worldeditadditions_commands/init.lua:40: attempt to call field 'alias_command' (a nil value)
ERROR[Main]: stack traceback:
ERROR[Main]:    .../worldeditadditions/worldeditadditions_commands/init.lua:40: in main chunk
ERROR[Main]: Check debug.txt for details.

Minetest: 5.3.0 (flatpak)
WE: latest from ContentDB
WEA: latest from ContentDB

I assume in the following sentence the term path_height should be replaced with the term path_length

Note that path_width must always be at least 1 less than the path_height in order to operate normally.

Sorry to open that many issues, but I feel this project deserves more attention :)

There comes a point in every project that one realises that some tests might assist in ensuring correct functionality. It's perhaps not a particularly fun task, but definitely worth doing.

We should implement some tests for WorldEditAdditions, starting with the contents of the utils directory.

The reason for this is that recently a number of bugs have come to light regarding the utilities we've implemented, which could have been avoided if we had tests for them.

Testing the world-modifying functionality itself that calls the Minetest/WorldEdit APIs is very complicated and out-of-scope of this issue - not least of which because all the Minetest API calls would have to be refactored out of the existing worldeditadditions core API codebase.

u-test appears as though it'll do the job nicely and supports inclusion via a git submodule too (which would be our preference I think), however we'd need to work out how we'd do that since Minetest would consider it to be a mod and try to load it.

I'd suggest here that we have a testssubdirectory inside the worldeditadditions mod directory that we put all the tests stuff in. Other mods in the modpack can have their own tests subdirectory if desired, but with a symlink to the u-test git submodule in worldeditadditions/tests perhaps.

I'd like to be able to select where the marker is and run something like //floodfill dirt 30 y 1

//floodfill <node> <radius> [<axis> <thickness>]

2020-05-08 16:27:32: WARNING[Server]: Assignment to undeclared global "end_time" inside a function at .....\mods\worldeditadditions\worldeditadditions/maze2d.lua:115.

Here is the separate issue for 5 and 6 point cloud selections.

To Reiterate, the idea is to create a standard 2 point selection big enough to encompass a target using 5-6 points selected on that target.

The basic working of the feature would be to simply find the minimum x y and z values of the 5 or 6 point cloud and assign them to the first point of the 2 point (normal) selection, then take the maximum x y and z values of the point cloud and assign them to point 2 of the normal selection.

Moreover, you brought up the idea of making a wand to assist with the task. I'm not sure how you would implement that especially for the case where one point needs to be moved but I'm sure you'll come up with an idea about that.

As for the actual invocation command I'm thinking //cloudset [re-set number (1-6)]. My other idea was //pc set [re-set number (1-6)]. As always let me know if you have any questions.

Like //many except it will iterate through the arguments before do and insert them into the argument after do at the {}.

Example: //for 2 3 4 5 do //overlay air 6 default:grass_{}

I don't know how easy these suggestions will be to implement or if some of them would be even possible without changing the main world edit mod but the current selection system is so frustrating I've decided to lay out my ideas and let you take or leave them (command names are placeholders--feel free to change them if you want).

1. Temporary Saving and Retrieval of selections (until program close). The retrieval command would have an option to use the current Position 1 as the basis for the retrieved selection or to use the original coordinates. Syntax: //savesel <name> //getsel <name> [c(urrent)] //listsels. //listsels would return a list of the saved selections and their pos1 and pos2 coordinates.
2. 5 and 6 point selections (6 for things like floating islands that have a bottom--otherwise the lowest of the 5 points would be the bottom). For spheres, floating islands and anything else with rounded edges and corners. With //fineset [1-6] you would be able to set the bounds of the final selection by punching nodes on the widest points and top (and optionally a 6th point on the bottom) of the thing you want to select and then the command would generate a selection box including those points. Putting a number after the command, e.g. //fineset 2, would allow to redefine that point by punching a different node and then change the selection box to fit the new point.
3. Perfect 2 axis box and 3 axis cube selections based on the current Position 1. Syntax: //sbox [+/-]x/y/z [+/-]x/y/z <length>, //scube [+/-]x [+/-]y [+/-]z <length>. Examples: //sbox -x y 10, //scube x -y -z 7.

Let me know if you need any clarification or further detail. Also I'm learning lua bit by bit so hopefully I can start contributing some time in the future instead just dumping ideas.

I was browsing the web recently, and I discovered an old tool for Minecraft called TeethOfTime. Finding information on it is difficult - but the basic premise is that it simulates weathering and decay of the selected area over time - e.g. nature reclaiming it, 'man-made' nodes falling down / decaying / disappearing, building crumbling, etc.

With the help of the mod's code repository, I've located the original forum post on the wayback machine. It has some before/after screenshot pairs:

(Before on the left, after on the right)

While the original tool was an external one using Substrate (awesome project btw if you want to parse Minecraft worlds I'd guess!), I think it's perfectly possible to implement this as a set of regular WorldEditAdditions commands. Perhaps //weather, //decay, or //teethoftime as a reference to the original creator?

The code repo lists the following features:

• Unsupported blocks fall, supported blocks topple
• Blocks decay into others (cobble into mossy cobble, etc.)
• Nature takes over human creations, using Minecraft itself to repopulate all chunks
• A Perlin filter to add non-uniform destruction and more detail
• Everything can be customised in config files which can be easily chosen at start of the app
• Multiple "official" configs included, with varying degree of decay
• Relighting
• Fluids recalculation
• Mod compatible

An impressive feature set! I think we might be able to translate most of this.

• Falling / toppling seems pretty straightforward
• Decay: we'd need a translation table for this, and expose an API to allow mods to define which block decay into which other blocks (suggestions from the community to add to this table would be welcome - we could have them in a dedicated file with a bunch of if minetest.get_modpath("modname") then ..... end blocks in it. Utilising some well-known groups could be a great way to automatically gain support for other mods.
• Nature takes over: this would be a fun challenge.
• Perlin filter: Minetest has a built-in Perlin noise generator - we're going to hook into that in #17
  • Some noise algorithms implemented (more to go though), so we should be able to use these to apply them to adjust chances.
• Everything can be customised: We can expose everything as space-separated key / value pairs in a command - then people can share different command combinations (e.g. a general purpose one that does everything, or one that only lets the erosion engine kick in or something).
• Presets: We could definitely include some of these. Perhaps we could have each feature behind its own command, but have 1 big command like //teethoftime that calls all the others? Again, suggestions from the community playing around with it can be added here!
• Relighting: I think Minetest / the WorldEdit helpers does this automagically when saving a VoxelManip back? I can't remember. Either way, //fixlight is a thing.
• Fluids recalculation: Certainly possible. This might result in a new separate command too.
• Mod compatibility: If we try to use established groups as much as possible, we should retain some automatic mod compatibility.

Some other ideas that spring to mind:

• //flowfluids - recalculate fluids
• //fall - from we_env - though we'll want far more granular control, perhaps we can use the code from here that identifies nodes that are affected by gravity

It's going to be a while until I can get to this, so if anyone wants to start tackling this in the meantime, please go ahead! Please comment on this issue if you start working on it to avoid duplicating effort - and consider opening a PR when done :-)

Links

• TeethOfTime GitHub repo
• Original Forum Post

If one executes an extremely large //subdivide, it becomes increasingly likely that all the nodes in the defined region will not actually be loaded into memory all at once. To this end, we should refactor //subdivide to use minetest.emerge_area() to load each block before we execute the command on it. We should be careful to avoid loading the entire area in 1 enormous minetest.emerge_area() call though, because that won't scale to the sizes we are looking to support here.

There's a nice tutorial on how to use minetest.emerge_area() here: https://rubenwardy.com/minetest_modding_book/en/map/environment.html#loading-blocks.

We might as well take the time to refactor //subdivide a bit to use the step-based approach we use for the //many command too, in order to make it asynchronous. It's a shame Lua doesn't support Promises or async/await....

This feature would allow export of scenes for render in blender, maya, 3ds etc.

TODO:

1. Find a format or formats that can pack geometry and textures
2. Narrow down format list to formats that are commonly importable by most 3d modeling programs
3. Implement export of selection geometry and textures
4. Implement conversion of export to previously listed formats

TODO:

1. Add parse function to make compatible with worldedit register
2. Add support for sapling alias lists e.g. //saplingaliases apple pine birch

When I use a non-numerical seed, I crash my game:

//maze default:dirt 2 3 seed

AsyncErr: ServerThread::run Lua: Runtime error from mod 'worldeditadditions_commands' in callback on_chat_message(): .....\mods\worldeditadditions\worldeditadditions/maze2d.lua:26: bad argument #1 to 'randomseed' (number expected, got nil)
stack traceback:
	[C]: in function 'randomseed'
	.....\mods\worldeditadditions\worldeditadditions/maze2d.lua:26: in function 'generate_maze'
	.....\mods\worldeditadditions\worldeditadditions/maze2d.lua:152: in function 'maze2d'
	...tadditions\worldeditadditions_commands/commands/maze.lua:57: in function 'func'
	....0\minetest-5.2.0-win64-dev\bin\..\builtin\game\chat.lua:69: in function <....0\minetest-5.2.0-win64-dev\bin\..\builtin\game\chat.lua:48>
	...inetest-5.2.0-win64-dev\bin\..\builtin\game\register.lua:429: in function <...inetest-5.2.0-win64-dev\bin\..\builtin\game\register.lua:413>

Sorry, took me a while to properly test it.

Implement better node checking (is_airlike for now) to remove the requirement for an air node to be above a target node.

When we're using //conv with the intention of using //layers, we sometimes get 'caves' occurring whereby we have a relatively thin 'crust' of nodes above a cavern of air. It would be great to have a command to fill these in with a given node. It could take the following form:

//fillcaves [<node_name>]

Example invocations:

//fillcaves
//fillcaves stone
//fillcaves dirt

Perhaps it could default to stone?

Add command to return object base names for given aliases. E.g. //basename stone returns: default:stone.

Idea: add capability to save and load (temporarily and or to file) worldedit selections in absolute or relative position (at the exact coordinates where the selection was saved or relative to pos1).

ModError: Failed to load and run script from C:\Users\Util7\Documents\Louis\minetest-5.2.0-win64\bin..\mods\worldeditadditions\worldeditadditions_commands\init.lua:
...tions\worldeditadditions_commands/commands/floodfill.lua:6: attempt to call field 'register_command' (a nil value)
stack traceback:
...tions\worldeditadditions_commands/commands/floodfill.lua:6: in main chunk
[C]: in function 'dofile'
...\worldeditadditions\worldeditadditions_commands\init.lua:20: in main chunk
Voir debug.txt pour plus d'informations.

Sometimes, we want to run a single command on a truly vast area. Usually, this results in running out of memory.

If we could implement a //subdivide <size_x> <size_y> <size_z> <command> command, it would really help.

Perhaps we could even implement an ETA calculator that tracks how long each chunk is taking, and includes an ETA in the progress update:

WorldEdit -!- Subdivide [<command_name]: 45 / 226 chunks complete (~19.91%), ETA: 5.11mins

If in the syntax we strip the double forward slashes from the beginning // of the command we're going to execute, then it would even be compatible with //multi! Though we'll have to make that clear in the help.

This command will only be useful for commands where context doesn't matter as much, but still it should come in real handy.

Be careful to execute this command. It brought up the windows error reporting circus on my machine :D No grayscreen, no log entry, just a crash to desktop.

//maze dirt 1 0

Building on the iterative thickness and width idea, ramp creation would be a perfect complement to 2d lines while removing the need to stack them on an axis in order to build roofs and stuff.
Suggested syntax: //ramp <replacenode> [<incline dir>]

It would be very cool indeed to expose Minetest's inbuilt noise primitives in a practical worldeditadditions command.

The API documentation can be found here: https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L6305

We could have 2 commands: 1 that operates in 2D (e.g. a heightmap), and 1 that operates in 3d (e.g. caves / blobs / sky islands etc). It's probably best to consider them both separately.

Let's think about the 2D version first. We'd want to expose the all the interesting parameters in a command (maybe //noise? it would fit what we've done with //maze if we later added //made3d).

We'd also perhaps want to add the ability to perturb the existing heightmap by a percentage or something to allow for both altering existing terrain, and layering multiple different kinds of noise to make fractals.

Speaking of, if we design the syntax right we should be able to allow for defining multiple kinds of noise at the same time that we can layer together in a single command to allow for easier complex fractal noise.

In the future we might want to add new different noise functions too, so maybe adding room for that would be worth doing too (though we want to make the invocation concise, so specifying the noise function should be optional and default to the inbuilt Minetest perlin noise).

The current worldedit.register_command function does not pass the name parameter to the parse element of the commands it registers. Having looked at the worldedit implementation I think it should be fairly painless to implement a better version of it ourselves. I could be totally wrong and this might turn into a nightmare but I think it's worth trying. Worst case we learn something and revert.

Runs harvesting/mining operation on targeted nodes in selection volume (or all non-water/non-lava/non-air nodes if no targets are specified). Drops items associated with removed nodes at the removed nodes locations or at player's coordinates if "here" argument is present.
Syntax: //harvest [here] [node_name1 [node_name2 [...]]]. Alias //mine.

Looks like we can't assign any commands in WorldEditAdditions to the WorldEdit brush.

I suspect this might require a looking through WorldEdit's code & potentially making a PR against it to add support.

I think it was @Miniontoby on the Minetest Forums who asked for //replacenear.

After seeing WorldEdit's //cubeapply function, I've had a brilliant idea that would effectively allow use to imitate //replacenear (if we assume //replacenear replaces inside a sphere) while simultaneously adding support for all other existing commands that operate using both worldedit pos1 and pos2.

In short, it would work like this:

1. Set pos1 and pos2 to be a box around the original pos1
2. Use VoxelManip as normal to fetch a copy of newly defined area in question
3. Call the command in question (it could even be //multi I guess) and allow it to do it's thing
4. Read a second copy of the defined area with VoxelManip
5. Copy the contents of the first VoxelManip onto the second, masking a spherical area around the original pos1
6. Write the 2nd VoxelManip back to the world
7. See only a spherical area has ultimately been changed

We could even add support for implementing an expression that defines whether we keep or revert edits based on the xyz position (we'd want to normalise x, y, and z to between 0 and 1 on each axis though) - though this would be a separate command. Perhaps MathPlot has an API we can hook into for the expression parsing - then we could add it as a soft dependency? We'd want to be careful to sandbox the expressions themselves.

If not, we might be able to implement a recursive-descent finite-state-automaton parser of some description for this purpose instead, since tokenising should be (fairly?) straight-forward if we force spaces between everything, but then again we could port our Lexer C♯ class over? Hrm......

Anyway, we'd want to implement //sphereapply first before we start thinking about that :P

WorldEdit has //stretch, but it doesn't support decimal numbers. We should fix that, and implement a more intelligent version here instead.

Please make a new cmd

Name: walls
Command: //walls
Param:
Function: Make inside the selected area (//1 and //2) an wall; just a kind of an //hollowcube but with no top and no bottom.

Example: //walls stone

Currently the chat commands code is getting a bit unwieldy. We should consider refactoring it so that every chat command has it's own file.

Additionally, we should consider ChatCmdBuilder, as it might reduce the amount of code we write & duplicate - and make our code more legible.

I would like to see line and ramp creation functionality (with variable thickness) added to this awesome mod. I wish I knew enough lua to fork the project and add the feature myself but sadly I don't.

I've just implemented a new //count command, as I'm aiming to bring WorldEdit + WorldEditAdditions up to parity with this worldedit reference such that anything listed there that WorldEdit for Minecraft does you can with Minetest - even if it requires multiple or a more complex command to do so.

Unfortunately, despite the code I've written correctly aligning everything so that it looks nice in a table, this isn't the case in the chat window:

....this is because the chat window is not a monospace font. The solution here would normally be to measure the text and measure the width of a space and adjust for it, but I haven't yet located a method in the Minetest API that lets me do this.

Another solution would be to display it in the chat window with a monospace font, but again I don't think that this is possible.

I've tried to mitigate the worst of the effects by putting the numbers in the first 2 columns (as pictured), but it isn't ideal.

If we can solve this, we could also then print a histogram in dots at the end of each line of output 📈 😃

With that, we could also apply it to counting a specific item by layer too and returning an ascii art histogram showing the value at different levels.

Input would be greatly appreciated on this issue, as I'm stumped as to what to do about it.

Doesn't fill any torus in Minetest 5.4.1.

Please make a new cmd

Name: replacenear
Command: //replacenear
Param: (size [in % or all]) (from-block) (to-pattern)
Function: Replace all (from-block) nearby to pattern.
Pattern: (number)%(block1),(number)%(block2),...

Example: //replacenear 50% air 20%stone,80%cobblestone

New Selection Tools:

Selection modifiers
//srel [x <amount>] &| [y <amount>] &| [z <amount>] &| [? <amount>] &| [up <amount>] &| [down <amount>] &| [left <amount>] &| [right <amount>] &| [front <amount>] &| [back <amount>] -- like scube but each axis length and direction must be separately defined.

//scenter -- sets pos 1 and 2 to the ceiling and floor respectively of the center point of the selection + 0.5. Ceiling and floor are used because in a selection of even length there are two center points and we want to select them both.

Measure Tools (mtools):

Selection info
//msize -- returns the length and axis of the selection along each axis of the selection relative to pos1. Example: 4x, 5y, -10z (200 nodes)
//midpos -- returns the vector of the center point of the selection area.
//mtrig -- returns the length of the diagonals between pos1 and pos2 (with height excluded and with height included) as well as the angle on the xz plane and the hy plane. Example: If the difference between pos1 and pos2 is dx,dy,dz = 5,6,7 then //mtrig should return D: 10.49, X/Z: 54.46° D/Y: 60.23° (prototype sqrt(dx^2+dy^2+dz^2), arctan(z/x), arctan(y/sqrt(dx^2+dy^2+dz^2)))
//mface -- returns player horizontal facing direction
//mcount -- your //count function should be absorbed into this new library

This request is to make it possible to require build operations to take building material from inventory.
Nobody wanted to do it in WorldEdit
, so I make the request here. WorldEditAdditions could become a fork of WorldEdit.

I have this mod activated with WE and when I trie to do //r node1 node2, it says i shall type //y.
Then i get: No Operation Pending! This only happens when this mod is active.

Like //floodfill except it will work upward as well. Possible aliases //bucket, //bfill.

Example: //bucketfill water_source 50

The name cloud wand is a bit confusing especially since there's a cloud mod. I move to change the name to Add Selection Wand or Cloud Select Wand or something.

Secondly as with the main world edit select wand there should be a chat command to do the same job. I plan to implement this as //scloud <1...6>.

I'd like to request the addition of a config/settings file to this mod. Further I'd like to request the option to turn off command execution conformation for large operations (requiring //y///n when a large number of blocks will be effected) be added to the settings file.

The overlay command will overlay on top of water nodes. That can be useful sometimes but when creating marshes, fields, papyrus stands or other stuff it is rather annoying:

My suggestion is to make add and option to make the command hydrophobic or make a separate command that is.

Ok here goes:

2d lines

The red line is how //line currently behaves when radius is 1. The green line is how it should behave when radius is 1.

That said instead of having a single radius we should have the option to input separate width and vertical thickness values. The new syntax would be: //line <replacenode> <thickness> [<width>].

Further the line creation process should be made iterative based on the central line. The yellow line in the screenshot would be and example of the result of //line <node> 2 1

3d lines

The only suggestion that I have for this is to look into the idea of having an option to make a staggered line (like the one in yellow) optimized for laying minecart track. This would probably be complicated though so it shouldn't be high priority.

Could you add a parameter to separately let us configure the width/thickness of walls and pathways?

Like when we want to have a maze with walls 3 blocks thick and a pathway 2 blocks wide?

I get a gray screen of death when I issue the maze command without having selected WE points`

//maze default:dirt 2 3 100

2020-05-08 15:56:18: ERROR[Main]: ServerError: AsyncErr: ServerThread::run Lua: Runtime error from mod 'worldeditadditions_commands' in callback on_chat_message(): ...tadditions\worldeditadditions_commands/commands/maze.lua:78: attempt to index local 'pos2' (a nil value)
2020-05-08 15:56:18: ERROR[Main]: stack traceback:
2020-05-08 15:56:18: ERROR[Main]: 	...tadditions\worldeditadditions_commands/commands/maze.lua:78: in function 'nodes_needed'
2020-05-08 15:56:18: ERROR[Main]: 	...\worldeditadditions\worldeditadditions_commands/safe.lua:23: in function 'func'
2020-05-08 15:56:18: ERROR[Main]: 	....0\minetest-5.2.0-win64-dev\bin\..\builtin\game\chat.lua:69: in function <....0\minetest-5.2.0-win64-dev\bin\..\builtin\game\chat.lua:48>
2020-05-08 15:56:18: ERROR[Main]: 	...inetest-5.2.0-win64-dev\bin\..\builtin\game\register.lua:429: in function <...inetest-5.2.0-win64-dev\bin\..\builtin\game\register.lua:413>
2020-05-08 15:56:18: ACTION[Server]: singleplayer leaves game. List of players: 
2020-05-08 15:56:18: ACTION[Main]: Server: Shutting down

A non-destructive envelope for other commands to prevent them from changing non-air nodes.
E.g. //airapply torus 10 5 stone zy

I had a few ideas about how to keep the repository and development streamlined going forward.

Labels

I would like to propose 3 new labels for issues:

• In Process (orange) -- To denote that the developer (you) or a contributor (me or someone else) is working on the issue.
• Delayed (burgundy) -- To denote that development/debugging has stalled or been delayed (like teeth of time?)
• Meta (very light grey) -- For issues like this that are about the repository or code organization itself.

Branches

As previously stated I will open my own development branch for continued contributions. I would like to go further though and propose a general management system:

1. The master branch should be the primary and default branch. I understand some of the reasons you decided to change it but having also changed it on other repos I manage I know from experience that it usually just leads to confusion and mix ups.
2. We should have a testing branch that all of our changes and any pull requests from contributor's forks get staged in until we are ready to release the next version. Some people create a new branch for every version but I think that's too much work and sticking with one permanent testing/staging branch gives people the opportunity to get "nightly build" style updates through github desktop.

Steps to reproduce:
Run in chat //multi <some commands> //many 2 //multi <some more commands>

The command I ran:
//multi //fp set1 -63 19 -20 //scube z z 3 //many 2 //multi //shift z 1 //shift y 1

Error thrown on crash:

AsyncErr: ServerThread::run Lua: Runtime error from mod '' in callback on_chat_message(): ...ions\worldeditadditions_commands/commands/meta/multi.lua:45: bad argument #1 to 'sub' (string expected, got nil)
stack traceback:
	[C]: in function 'sub'
	...ions\worldeditadditions_commands/commands/meta/multi.lua:45: in function 'func'
	...ions\worldeditadditions_commands/commands/meta/multi.lua:62: in function 'func'
	...\Media\minetest-5.3.0-win64\bin\..\builtin\game\chat.lua:69: in function <...\Media\minetest-5.3.0-win64\bin\..\builtin\game\chat.lua:48>
	...ia\minetest-5.3.0-win64\bin\..\builtin\game\register.lua:429: in function <...ia\minetest-5.3.0-win64\bin\..\builtin\game\register.lua:413>