sqlite lock ignored?
Opened this issue · 15 comments
another lock issue, inverse of the other ones i've mentioned, is that when the map_interface is created the sqlite file can be open (like the player is in the game) and yet everything seems to proceed as normal including the save() but then nothing is saved and yet no error is thrown.
See the documentation of the connect method.
The lock is only preset at writing, and is kept by the first connection which writes into the SQLite buffer, until the transactions are committed (using MapInterface.save or MapVessel.commit). Try this :
from libminetest.map import MapVessel
from libminetest.nodes import Node
from libminetest.utils import Pos
k = MapVessel("map.sqlite")
m = k.load(0)
m.set_node(Pos(1, 1, 1).getAsInt(), Node("default:nyancat"))
u = MapVessel("map.sqlite")
u.write(0, m.implode())
k.write(0, m.implode())It will raise a MapError, telling you the database is locked. Now insert u.commit() before the last line, and it will work, although it saves the same mapblock twice.
I could set my own timeout, but the default one is good for me. I'll allow it to be set by the user upon opening a world though.
The link to the github is dead :( Can you guys update it ?
https://gist.github.com/bobombolo/bc0d002aa3c631cac1a0d51afbbaf6c6
an old version but works
Thanks a lot !! :)
(I haven't been here in what feels like years)
What's the status of this issue? How have things turned out?
the only issue I still have is the lighting issue and the on_generated issue
he only issue I still have is the lighting issue and the on_generated issue
Those are probably related to mapchunk flags. Did you generate those blocks? Did they exist and you modified them?
I am generating an entire map from an empty map.sqlite file.
As far as my knowledge goes back, it is only feasible to get a correct lighting if you manipulate flags, or force the engine to recompute it for every chunck you made. Usually, the latter applies.
Since my library doesn't do lighting computation, the game has to do it. Manipulating the "is_generated" flag doesn't seem to actually do anything (the documentation even points out that even if "is_generated" is at 0 the engine may not update the chunck). So far the only that can work at 100% is having a mod similar to mapfix go through the entire generated map and force a new computation of the lighting values.
I'll try and dig further, as much as my schedule allows me.
ya well that's what I do, i have a mod that does that, however this defeats the purpose of generating a world map outside the game, if I have to go visiting every part of the map in the game to fix the lighting then I might as well just generate the map with a lua mapgen mod in the first place.
What I had dreamed of was building a GUI for the tool I have built so far that allows World Painter type functionality in an open source, non-java, minetest-first approach, but this lighting issue is a total impasse for me.
What would be required to calculate the lighting via python?
even if you could fully light every block or set the light to some medium level. shading maybe not so important, or could be controlled programatically via a hillshade algorithm, but the way it is now, with NO lighting on each block, is useless.
i was also considering packaging my tool as a plugin for QGIS, so that qgis becomes the GUI for loading spatial layers and then outputting a minetest map.
I have no idea how lighting is stored in minetest, and, therefore, I can't promise that I'll find a way to make the illumination work by default. I'll see what I can do right now however.
I actually figured out a way which worked for me and doesn't require changes made to the code :
Try setting param1 of your nodes to a value close to 255, and tell me if you still get dark chuncks.
What that does is set the light parameter to its maximum value. During the night, you'll probably get artifacts on the ground, but, in daylight, there are no dark chuncks despite huge portions of land generated artificially.
(I'd also be nice to get a look at your project, if possible)