FOSS gamedev and creative worlds

Would it be feasible to have LuaAPI functions load chunks automatically if they are not already loaded? Certain mods, such as mesecons, worldedit, and such would benefit greatly from being able to operate when a player is not within view distance of a chunk.

+2! Good Idea!

+1=3! That's what we need! (I'm just interested if performance is ok then)

Jeija wrote:+1=3! That's what we need! (I'm just interested if performance is ok then)

Me too. You wouldn't want any rogue mods loading every single chunk.

You wouldn't want any rogue mods anyway. Remember, they can do anything, they can eat your cookies and read your mails.

+1 need this for giant mesecons buildings

There are two ways to load a MapBlock - one is to add it to the load queue and wait until the "EmergeThread" gets to loading it in the background, while continuing doing other things, like moving objects and doing block placement and everything.

The other one is to just block everything until the block has been read from disk, which can take, well, a good fraction of a second, if not longer in the worst case, and can be annoying to the players. There is no way the server could continue running while a Lua callback has not returned.

I am guessing the blocking way would need to be used, because otherwise coding the delayed action is a bitch.

Also, sometimes a MapBlock hasn't been generated at all. In that case I think I won't let the Lua script to generate it; the generator generates stuff in huge bunches and the latency is just completely horrible. Maybe it would be possible to generate an empty area marked as not generated; the map generator could mess up anything added in there though.

Maybe something like:


This is trickier to implement, but could be made in the future if really needed:


In both of these cases, the area will be automatically unloaded when it hasn't been used for a while.

celeron55 wrote:There are two ways to load a MapBlock - one is to add it to the load queue and wait until the "EmergeThread" gets to loading it in the background, while continuing doing other things, like moving objects and doing block placement and everything.

The other one is to just block everything until the block has been read from disk, which can take, well, a good fraction of a second, if not longer in the worst case, and can be annoying to the players. There is no way the server could continue running while a Lua callback has not returned.

I am guessing the blocking way would need to be used, because otherwise coding the delayed action is a bitch.

Also, sometimes a MapBlock hasn't been generated at all. In that case I think I won't let the Lua script to generate it; the generator generates stuff in huge bunches and the latency is just completely horrible. Maybe it would be possible to generate an empty area marked as not generated; the map generator could mess up anything added in there though.

Maybe something 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.load_node(pos)
^ Returns true if the volume in which the node is could be loaded, or
  already was loaded, in which case it then is available regularly by
  minetest.env:get/set_node()


This is trickier to implement, but could be made in the future if really needed:

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.load_node_async(pos, func(pos, success, param), param)
^ If pos is in a loaded area, will return true
^ If pos is not loaded, will return false and queue the load. When the load
  completes, func(pos, true, param) will be called in case the load was
  succesful, and func(pos, false, param) will be called in case the node
  could not be loaded (which, in practice, means that the area has not been
  generated.)


In both of these cases, the area will be automatically unloaded when it hasn't been used for a while.

The second would be better.

celeron55 wrote:There are two ways to load a MapBlock - one is to add it to the load queue and wait until the "EmergeThread" gets to loading it in the background, while continuing doing other things, like moving objects and doing block placement and everything.

The other one is to just block everything until the block has been read from disk, which can take, well, a good fraction of a second, if not longer in the worst case, and can be annoying to the players. There is no way the server could continue running while a Lua callback has not returned.

I am guessing the blocking way would need to be used, because otherwise coding the delayed action is a bitch.

Also, sometimes a MapBlock hasn't been generated at all. In that case I think I won't let the Lua script to generate it; the generator generates stuff in huge bunches and the latency is just completely horrible. Maybe it would be possible to generate an empty area marked as not generated; the map generator could mess up anything added in there though.

Maybe something 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.load_node(pos)
^ Returns true if the volume in which the node is could be loaded, or
  already was loaded, in which case it then is available regularly by
  minetest.env:get/set_node()


This is trickier to implement, but could be made in the future if really needed:

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.load_node_async(pos, func(pos, success, param), param)
^ If pos is in a loaded area, will return true
^ If pos is not loaded, will return false and queue the load. When the load
  completes, func(pos, true, param) will be called in case the load was
  succesful, and func(pos, false, param) will be called in case the node
  could not be loaded (which, in practice, means that the area has not been
  generated.)


In both of these cases, the area will be automatically unloaded when it hasn't been used for a while.

Actually, I would prefer the second choice, this way we can have some sort of /command to assist with loading of the chunks.

i actually just change the minetest config file with these

max_simultaneous_block_sends_server_total = 1
max_block_send_distance = 4
max_block_generate_distance = 25

until i get something that loads well. see it only loads one "chunk" section at a time(by default its 8 at a time). so my single core Cpu likes it:D