Minetest Forums

I've noticed that my ARM Open-GLES v1 compiled version of Minetest seems to have performance issues when calling mc.setBlock, resulting in noticeable frame drops for a brief moment.

At first I thought this might be due to loading textures into memory, but I don't believe this is the case since there are other nodes in the world that share the same textures and node type. I tried some other examples (LUA code that displays text as blocks or analog clocks that draw hands on a watch face), and they also seems to hitch when blocks are set.

Is this a known issue? Is there something I can try to not cause some jitter and hitching at the moment when mc.setBlock is called?

I've came up with some additional questions while reading this topic:
1) How did you debug this binary? A text log would be helpful to get more details about this.
2) What binary did you debug there? "mc." alone looks very suspicious and there's no single function called "setBlock". Looks like you've debugged the wrong application, try again.
3) Was this observed in singleplayer or on a server? If server: Which one is it?

Apologies, but I seemed to have completely failed to point out the most critical piece of information here for some reason. I am using raspberryjammod with Python, which supports calling functions like mc.setBlock. The data is then sent to Minetest through a LUA socket. For example, in World.py:

In World.py:
https://github.com/arpruss/raspberryjam ... /block.lua

Code: Select all

def setBlock(self, *args):
        """Set block (x,y,z,id,[data])"""
        self.conn.send_flat("world.setBlock", floorFlatten(args))

Which I assume called world.setBlock in Minetest through the socket:
https://github.com/arpruss/raspberryjam ... nection.py

Code: Select all

 def send_flat(self, f, data):
        """Sends data. Note that a trailing newline '\n' is added here"""
#        print "f,data:",f,list(data)
        s = "%s(%s)\n"%(f, ",".join(data))
        self.drain()
        self.lastSent = s
        self.socket.sendall(s)

So to answer your questions:

1. I'm not currently debugging any binary, just using mods and Python scrips to call the API. I don't have a text log with me, but I don't recall seeing anything too noteworthy. I'll try to get another on for you.
2. As mentioned, mc.setBlock is a Python class that apparently passes the arguments on to world.setBlock through a lua soket.
3. This is only being authored in singleplayer.

I've now noticed that world.setBlock has been replaced with world.setBlockState. Which now makes me surprised that this even works at all. Perhaps I can try updating raspberryjammod to integrate the Minetest API changes and see if that helps at all.

Pardon my ignorance... but you are aware that this website is all about Minetest and NOT Minecraft? They are completely not the same software. https://github.com/arpruss/raspberryjammod is not for Minetest at all. It appears to be for Minecraft.
Hopefully this is the case as I'm completely lost trying to figure out what's going on here :P

AFAIK there's an interface for running these pyhton scripts for MC with MT. Take a look at this thread on the forum which describes that raspberryjammod. Any bug reports/problems with the mod will likely be understood better if reported in the context of that forum thread instead of in this seperate thread :-)

ExeterDad wrote:Pardon my ignorance... but you are aware that this website is all about Minetest and NOT Minecraft? They are completely not the same software. https://github.com/arpruss/raspberryjammod is not for Minetest at all. It appears to be for Minecraft.
Hopefully this is the case as I'm completely lost trying to figure out what's going on here :P

There is a version of this mod that is specifically for Minetest, which is the one I'm using.

https://github.com/arpruss/raspberryjammod-minetest

Sokomine wrote:AFAIK there's an interface for running these pyhton scripts for MC with MT. Take a look at this thread on the forum which describes that raspberryjammod. Any bug reports/problems with the mod will likely be understood better if reported in the context of that forum thread instead of in this seperate thread :-)

I did see that thread earlier, so I'll post my question there. Originally I thought there was just some general issue with creating blocks, but I just did a test using LUA instead of Python and it runs much better. So it definitely seems like it's an issue with raspberryjammod and not Minetest.

Thanks for the help, though!

celinnia wrote:

ExeterDad wrote:Pardon my ignorance... but you are aware that this website is all about Minetest and NOT Minecraft? They are completely not the same software. https://github.com/arpruss/raspberryjammod is not for Minetest at all. It appears to be for Minecraft.
Hopefully this is the case as I'm completely lost trying to figure out what's going on here :P

There is a version of this mod that is specifically for Minetest, which is the one I'm using.

https://github.com/arpruss/raspberryjammod-minetest

Thanks for clearing that part up for me. I honestly thought you might of landed on the wrong website lol

Actually, I now have a followup question. Looking through the raspberryjammod code, it seems the frame hitching is a result of this function:

VoxelManip:write_to_map()

Apparently this is being executed whenever a block is set, even if it's just a single block. Can someone clarify if this function is supposed to be slow? And is it not a good idea to call it after every time you set a node?

It has overhead, which means it will be relatively slow for a single node - as it's copying a whole 16x16x16 mapblock (chunks in minetest) at least. For larger areas it's the fastest way, however for small areas, you should just use minetest.set_node

What would be the minimum largest area recommended to use this method?

I've only ever heard estimates, maybe a few hundred nodes? Need to test and time the methods to know for sure but i'm not sure anyone has.

paramat wrote:I've only ever heard estimates, maybe a few hundred nodes? Need to test and time the methods to know for sure but i'm not sure anyone has.

Looks like (for my ARM OpenGLES build, at least), creating more than 200 nodes in one frame without using write_to_map() is too much.

Thanks for the help!

Actually the threshold may be lower, since every 'set node' triggers a separate light update, so i would use the Lua voxel manipulator for more than 10-20 nodes.