Post your modding questions here

[Nathan.S]

I've got this currently,

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

after_place_node = function(pos, placer, itemstack)
         local n = minetest.get_node_or_nil(pos) --get the location of the placed node
         if not n or not n.param2 then
            minetest.remove_node(pos)
            return true
         end
         local dir = minetest.facedir_to_dir(n.param2)
         local p = {x=pos.x+dir.x, y=pos.y+1, z=pos.z+dir.z}
         local n2 = minetest.get_node(p)
         if not {{n2.name}={'default:tree'}} then
            minetest.remove_node(pos)
          end
   end,


this currently just crashes I tried using minetest.get_item_group but got no place with that either. I just need to compare location of a node, to the name of a node.

[12Me21]

I've got this currently,

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

after_place_node = function(pos, placer, itemstack)
         local n = minetest.get_node_or_nil(pos) --get the location of the placed node
         if not n or not n.param2 then
            minetest.remove_node(pos)
            return true
         end
         local dir = minetest.facedir_to_dir(n.param2)
         local p = {x=pos.x+dir.x, y=pos.y+1, z=pos.z+dir.z}
         local n2 = minetest.get_node(p)
         if not {{n2.name}={'default:tree'}} then
            minetest.remove_node(pos)
          end
   end,


this currently just crashes I tried using minetest.get_item_group but got no place with that either. I just need to compare location of a node, to the name of a node.

I couldn't get minetest.get_item_group to work, either (in my own projects)
Anyway, try making it use facedir instead of wallmounted, then do this:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

after_place_node = function(pos)
   local node = minetest_get_node(pos)
   local dir = minetest.facedir_to_dir(node.param2)
   for y, -1 to 1 do
      node2 = minetest.get_node({pos.x-dir.x,pos.y+y,pos.z})
      if node2.name ~= "default:tree" then
         minetest.remove_node(pos)
         break
      end
   end
end,

[prestidigitator]

...this currently just crashes I tried using minetest.get_item_group but got no place with that either. I just need to compare location of a node, to the name of a node.

The expression:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

not {{n2.name}={'default:tree'}}

is not valid (it should even cause a syntax error). You probably want:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

not (n2.name == "default:tree")

or, better yet:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

n2.name ~= "default:tree"

("~=" is Lua's not-equal-to operator, "==" is Lua's equal-to operator, and "=" is Lua's assignment operator).

EDIT: To clarify further, curly braces ({}) in Lua create a new table object. Provided what is inside them is valid table syntax, a table will always evaluate to true (everything but nil and the boolean value false evaluate to true). However, table syntax also requires entries separated by commas, with each entry either being a simple value or a key-value pair. A key-value pair DOES separate the key and value by a single equals (=) character, but the key must either be a simple identifier-style name or an expression in square brackets ([]), whose value is used as the key. So valid examples are:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

{ 3, 2, 1, "contact" }  -- Implicit keys 1, 2, 3, 4; table treated as array
{ x = 1, y = 5, name = "Fred" }  -- Simple names "x", "y", "name" as keys
{ [x+1] = 1, [y-1] = 5, [name] = "Fred" }  -- Keys are derived from the values of the x, y, and name variables, not the strings "x", "y", and "name"


[prestidigitator]

...this currently just crashes I tried using minetest.get_item_group but got no place with that either. I just need to compare location of a node, to the name of a node.

Oh, and I'm not sure how exactly you are trying to use minetest.get_item_group(), but the correct way for your tree test expression should look like:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

minetest.get_item_group(n2.name, "tree") == 0

which tests whether the n2 node is NOT in the tree group. To test whether a node IS in the tree group, it would look like:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

minetest.get_item_group(n2.name, "tree") > 0

[Nathan.S]

Thank you Prestidigitor, I've almost got things working now, just need to finish up the rest of the node.

[Sokomine]

For my build_chest (a bit like the one in towntest or in npcf, except that it comes without a mob), I need to find all .mts and .we files the player has. The most promising locations for these files are worlds/<worldname>/schems/ and mods/<modname>/<some sub directory>/. Trouble is: Locating files depends on the operating system, and access to these files may change in the future (planned security restrictions?). So how may I get those file names? I need to be able to read the files as well. Files outside the minetest/ hierarchy are of no intrest. Files from other mods and other worlds are certainly of intrest as players may want to move a building from one world to another or take a look at a schematic a mod provides.

[prestidigitator]

The most promising locations for these files are worlds/<worldname>/schems/ and mods/<modname>/<some sub directory>/. Trouble is: Locating files depends on the operating system, and access to these files may change in the future (planned security restrictions?). So how may I get those file names? I need to be able to read the files as well.

Reading (and/or writing) a file with a particular path is as simple as using Lua's standard io.open() function and the methods on the resulting file object. You'll probably want to start with minetest.get_worldpath() as a base path, and construct full file paths by appending things to it (e.g. minetest.get_worldpath().."/mymod_motd.txt").

As for reading directory contents, unfortunately you are SOL. There is no portable way to do it. This is one of the major deficiencies of the Lua/Minetest environment. Your best bet is to use a command/script/editor outside of Minetest to create a file that lists file names or paths in it. If you knew a very specific pattern of filenames (e.g. "message_001.txt", "message_002.txt", "message_003.txt", ...) you could iterate over them trying to open the files until you get an error, but that's about as automated as it's going to get. You're shooting in the dark.

[Sokomine]

As for reading directory contents, unfortunately you are SOL. There is no portable way to do it. This is one of the major deficiencies of the Lua/Minetest environment. Your best bet is to use a command/script/editor outside of Minetest to create a file that lists file names or paths in it.

Well, that's the trouble. And then there's that issue with possible upcomming security features, which may limit file system access even more. Perhaps I'll use your approach and rely on a player/script-generated list of filenames.

[prestidigitator]

Well, that's the trouble. And then there's that issue with possible upcomming security features, which may limit file system access even more. Perhaps I'll use your approach and rely on a player/script-generated list of filenames.

Actually, I'd love to nail down security a bit, and I think I even suggested it in the past. If done properly, you can sandbox the hell out of Lua, and do it pretty transparently. I've done this before, and it's not that bad. Basically, all the standard library functions that execute programs, access the filesystem directly or indirectly, or have the potential to change how Lua works (e.g. debug functionality and functions that cause compilation like loadfile() and dofile()) need to be either removed or wrapped with very paranoid code. For example, anything that uses a filepath should whitelist the set of base directories that should be used and either pre-resolve all parent directory segments ("..") or flat out not allow any paths that contain them. A strategy for dealing with symbolic links should also be identified.

Anyway, security could be done very well, but there's certainly the potential for messing it up, either leaving holes or harming functionality. I hope they're careful about it.

[Ben]

I'd also like to see the security increased – I was quite amazed when I saw the "raw" io-calls in mods, to tell the truth.

How about this: someone™ writes a support library mod which offers functions for the common use cases (I've seen "loading another .lua from the same mod", "reading a data file in the mod's directory", and "reading/writing a mod-related file (typically a serialized table) in the world directory".

Then everyone gradually switches over to using this support library mod (bonus effect: the "common use cases" should all get found), and after that, we're free to replace the standard io library with something a lot stricter, if we wish.

[prestidigitator]

How about this: someone™ writes a support library mod which offers functions for the common use cases (I've seen "loading another .lua from the same mod", "reading a data file in the mod's directory", and "reading/writing a mod-related file (typically a serialized table) in the world directory".

Then everyone gradually switches over to using this support library mod (bonus effect: the "common use cases" should all get found), and after that, we're free to replace the standard io library with something a lot stricter, if we wish.

Well, I think there's also something to be said for the standard Lua API. Someone who is very comfortable with Lua already can then come to Minetest and mod away. So I'm in favor of simply replacing the standard library methods with ones that are more secure. Keep the same signatures and general contracts, but replace the behavior behind the scenes. Actually, maybe I'll work on a mod that can do this on its own, and could be included in a game (i.e. make the game's "default" mod depend on it. The only problem is that there's still no guarantee it would be loaded first (if there are mods with absolutely no dependencies), so there might need to be a bare amount of actual engine support.

[rubenwardy]

Lua sandboxing will be added in 0.5. It's already been written, but it does break several mods.

[fishyWET]

Most mapgen mods seem to make use perlin noises or such noises to determine the physical features of the terrain generated.
Would it be perhaps possible to generate a world with a predefined terrain, a fixed mapgen? One that have the same predefined physical features (but not geographical features) at the same spot for all created worlds running the mapgen.
In simpler terms, a pre-self-defined, unchanging bare terrain that is not based on random noises.

[Krock]

In simpler terms, a pre-self-defined, unchanging bare terrain that is not based on random noises.

That's simple to realize but I doupt the people would like to have alays the same terrain.

[fishyWET]

That's simple to realize but I doupt the people would like to have alays the same terrain.

By "simple to realize", do you mean simple to achieve? If so, how so?
Identical terrain might be useful sometimes, like for example, creating an exact clone of earth.
Or for the reason why i asked this question in the first place, to settle on an lifelike Middle Earth mapgen. Instead of one that randomly generates biomes, causing conflicts like Shire beside of Mordor.

[Hybrid Dog]

you could use fractals for mapgen, e.g. http://en.wikipedia.org/wiki/Burning_Ship_fractal

[Ben]

@rubenwardy, how does the sandboxing break mods? If the standard io library is going to be removed (for example), I think it would make sense to start moving towards the new interface now, with a wrapper mod that provides the new interface by wrapping io again.

@prestidigitator: the point of keeping standard libraries, in my opinion, would be to use Lua code from other places unmodified here, which probably makes little sense. As for Lua experts coming to Minetest, I think there's little difference between having to learn

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

local file = io.open(minetest.get_modpath("mymod") .. "/mystash.mt", "r")
local stash = minetest.deserialize(file:read())
io.close(file)

and

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

local stash = minetest.read_modstash("mymod", "mystash")

because either way, the minetest API is the new part.

[rubenwardy]

It breaks some mods due to functions being removed. Worldedit relies on os.execute to make folders. The IRC mod needs it to do IRC. Because it's a breaking change, it's going to be added in 0.5 rather than having been added in 0.4.12. (According to chatter in #minetest-dev, anyway)

And yes, it makes sense to start encouraging mods to change to alternative functions. For example, the mkdir function that will be added.

[prestidigitator]

Well, here's a go at it anyway: [Mod] Security [security]

Might be useful for people before then or as a reference implementation for comparing security measures. The main feature is a virtual filesystem that disallows unsafe file path and access to anything but the world and mods directories. But it does other things as well, such as restricting access to debug functionality and to metatables and environment tables not explicitly set by user code.

It'll probably break the same mods as the 0.5 changes will, and for the same reasons.

[fishyWET]

you could use fractals for mapgen, e.g. http://en.wikipedia.org/wiki/Burning_Ship_fractal

Could you give an example of how to apply it? I'm sort of a newbie towards it.
And just to confirm, will it achieve v ?

In simpler terms, a pre-self-defined, unchanging bare terrain that is not based on random noises.

[Hybrid Dog]

I'm sort of a newbie towards it.

me too

[Rui]

[DELETED]

[Nathan.S]

I'm using an ABM to swap nodes, but I need a way to run a timer on those nodes after the ABM swaps them, is there a way to do this?

I want to have my fires turn into embers, accomplished with the ABM when the fuel runs out, then after two minutes I want the embers to turn into kindling. I can't achieve that with an ABM because it would change all embers into kindling without regard to how long they would have been in existence. I can't seem to find any callback that will run after an ABM places the node.

[prestidigitator]

I'm using an ABM to swap nodes, but I need a way to run a timer on those nodes after the ABM swaps them, is there a way to do this?

I want to have my fires turn into embers, accomplished with the ABM when the fuel runs out, then after two minutes I want the embers to turn into kindling. I can't achieve that with an ABM because it would change all embers into kindling without regard to how long they would have been in existence. I can't seem to find any callback that will run after an ABM places the node.

A couple solutions come to mind. First, you could store a count or time in the ember nodes' metadata and use an ABM. Only make your transition if the metadata meets the required conditions. I would recommend this one as it will probably take care of corner cases like the node being dug/replaced better.

Second, you could use minetest.after() and include the position of the newly created embers as a parameter. You'll have to test whether the node is still the expected one, and/or keep a list of "canceled" callbacks to ignore when the node is dug/replaced, etc.

[Nathan.S]

I hadn't thought of using another ABM to make the change from embers to kindling, but that might work if I can just get the time to trigger a variable change that the ABM will read.

I'll keep bashing away at it, I'll have to figure it out eventually.

[bdjnk]

I'm using an ABM to swap nodes, but I need a way to run a timer on those nodes after the ABM swaps them, is there a way to do this?

I want to have my fires turn into embers, accomplished with the ABM when the fuel runs out, then after two minutes I want the embers to turn into kindling. I can't achieve that with an ABM because it would change all embers into kindling without regard to how long they would have been in existence. I can't seem to find any callback that will run after an ABM places the node.

This doesn't feel like ABMs are needed at all. Have you tried using node timers?

[prestidigitator]

This doesn't feel like ABMs are needed at all. Have you tried using node timers?

Oh! Good point! I'd forgotten about them. That's an even better idea.

Question: Does anyone know if node timers are cancelled if the node is replaced? Might be worth a test....

[Nathan.S]

I use an ABM currently in the exact way the furnace does, I thought I could use node timers but I can't get them to start after the ABM places the node.

[Don]

I hadn't thought of using another ABM to make the change from embers to kindling, but that might work if I can just get the time to trigger a variable change that the ABM will read.

I'll keep bashing away at it, I'll have to figure it out eventually.

Let me know how you make out. I am working on a mod that needs timers. I want them to work when placed by am abm. I was trying to think of another solution.

[Nathan.S]

I'll be sure to do that Don. It's probably something really simple, and I just haven't thought of it yet.