| Time |
Nick |
Message |
| 00:01 |
|
KiwiExtex joined #minetest |
| 00:11 |
|
el joined #minetest |
| 00:14 |
|
Copenhagen_Bram1 joined #minetest |
| 00:36 |
|
Ruslan1 joined #minetest |
| 00:38 |
Ruslan1 |
I still can’t login to minetest forums |
| 00:41 |
Ruslan1 |
Can anyone fix my account in minetest forums |
| 00:50 |
|
Calinou joined #minetest |
| 00:54 |
|
mmuller joined #minetest |
| 01:42 |
|
norkle joined #minetest |
| 02:01 |
|
Pie-jacker875 joined #minetest |
| 02:06 |
Extex |
How do I get the text from a text list based on an index? |
| 02:07 |
Extex |
So I've got the textlist |
| 02:07 |
Extex |
And I need to get the number selected (comes out as "CHG:#") |
| 02:08 |
Extex |
And I need to get the text contained at that index |
| 02:08 |
Extex |
Of the textlist |
| 02:11 |
|
FreeFull joined #minetest |
| 02:22 |
luk3yx |
Extex: You'll have to store the text server-side. |
| 02:23 |
Extex |
Ya I am.. But how would I get the index when the output is "CHG:#"? |
| 02:26 |
|
Mahjong joined #minetest |
| 02:32 |
|
Pest joined #minetest |
| 02:34 |
|
nephele_ joined #minetest |
| 03:15 |
|
oil_boi_ joined #minetest |
| 03:28 |
|
Mahjong joined #minetest |
| 03:36 |
|
Ruslan1 joined #minetest |
| 03:39 |
|
est31 joined #minetest |
| 03:59 |
|
sagax joined #minetest |
| 04:03 |
oil_boi_ |
So if you set_attach to the player you can no longer see the object? |
| 04:09 |
|
YuGiOhJCJ joined #minetest |
| 04:24 |
|
Seirdy joined #minetest |
| 04:39 |
|
fruitsnack joined #minetest |
| 05:08 |
|
Hawk777 joined #minetest |
| 05:09 |
|
Kimapr joined #minetest |
| 05:48 |
|
solrac joined #minetest |
| 05:49 |
solrac |
Hello. I wanted to know if there were more technical requirements (RAM, GPU 'generation', etc) I ask cause I am contemplating a rather ambitious port that I'm almost certain it might be impossible |
| 05:58 |
|
sec^nd joined #minetest |
| 05:59 |
|
est31 joined #minetest |
| 06:13 |
|
galaxie joined #minetest |
| 06:21 |
|
Flabb joined #minetest |
| 07:24 |
|
Flabb joined #minetest |
| 07:46 |
|
macc24 joined #minetest |
| 08:18 |
|
maccraft joined #minetest |
| 08:25 |
|
Flabb joined #minetest |
| 08:33 |
|
mizux joined #minetest |
| 08:40 |
|
ShadowNinja joined #minetest |
| 08:46 |
|
solrac joined #minetest |
| 09:15 |
|
Beton joined #minetest |
| 09:26 |
|
Thermoriax joined #minetest |
| 09:30 |
|
DrFrankenstone joined #minetest |
| 09:34 |
sfan5 |
solrac: you need a c++11 compiler for your target platform; your target platform needs to be supported by sqlite3; [Irrlicht-related requirements] it needs to have either OpenGL or GL ES (officially supported) or DirectX 8 or 9 (not explicitly supported, but works); Irrlicht needs to know how to create a window and/or rendering context plus how to do keyboard/mouse input |
| 09:34 |
sfan5 |
the RAM requirement is roughly the same everywhere, the processor does not matter it just can't be too slow or nothing will work out in the end |
| 09:40 |
sfan5 |
to be more precise on GL/GLES: I think the minimum OpenGL requirement is somewhere around 2.x (2.0?). With OpenGL ES either 1.0 or 2.0 are supported by Irrlicht and work with MT. |
| 09:44 |
solrac |
Thaks for the replies! I was contemplating the original Xbox, I noticed a bare MTG runs with 68~mb of ram, and sadly the OGXB has 64, so I was thinking maybe reduce few things here and there. But while thinking, I'd figured I might go for Switch instead. |
| 09:44 |
solrac |
That being said, I believe there is no Controller support just yet, correct? |
| 09:45 |
sfan5 |
I have seen some code for joysticks here and there but I don't know how well it works |
| 09:46 |
solrac |
Also I Apologize for my late replies and ignorance, I just got back ^^" |
| 09:47 |
sfan5 |
no need to apologize |
| 09:48 |
sfan5 |
oh and one more thing: Minetest relies that there is a working filesystem exposed by the C and C++ standard library, it'd not be impossible to replace this with a custom implementation to use system-specific way, but that'd be potentially a lot of work |
| 09:49 |
solrac |
Could it look for a subfolder of wherever it might be running? |
| 09:49 |
sfan5 |
"working" here means that it can read its assets from the fs and freely create and write files to save user data |
| 09:49 |
solrac |
Understandably so. |
| 09:49 |
sfan5 |
sure you can make it use any path you desire |
| 10:08 |
|
calcul0n joined #minetest |
| 10:17 |
|
jluc joined #minetest |
| 10:18 |
|
TomTom joined #minetest |
| 10:22 |
|
tomraceror joined #minetest |
| 10:47 |
|
YuGiOhJCJ joined #minetest |
| 11:09 |
|
mizux joined #minetest |
| 11:12 |
|
tomraceror joined #minetest |
| 11:31 |
|
Flabb joined #minetest |
| 11:36 |
|
galex-713 joined #minetest |
| 11:37 |
|
MDude joined #minetest |
| 11:47 |
Elouin |
Hi, in minetest only the server needs the mods/subgame installed not the clients, right? |
| 11:48 |
sfan5 |
correct |
| 11:49 |
|
galex-713 joined #minetest |
| 11:50 |
Elouin |
? |
| 12:20 |
|
ektor joined #minetest |
| 12:42 |
|
Fixer joined #minetest |
| 13:03 |
|
calcul0n joined #minetest |
| 13:05 |
|
galex-713 joined #minetest |
| 13:18 |
|
karamel joined #minetest |
| 13:26 |
solrac |
Hello again. Can this game be compiled with static linking instead of dynamic linking? I'm not exactly too familiar with how CMake does things tho |
| 13:30 |
|
fruitsnack joined #minetest |
| 13:32 |
sfan5 |
sure |
| 13:32 |
sfan5 |
add -DCMAKE_EXE_LINKER_FLAGS="-static" to your cmake invocation |
| 13:32 |
solrac |
is there a way to do it in a config by chance? |
| 13:33 |
sfan5 |
what are you referring to by "config"? |
| 13:33 |
solrac |
or I imagine the CMakeList.txt |
| 13:34 |
sfan5 |
you can also put set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static") there, yes |
| 13:34 |
solrac |
thanks! |
| 13:45 |
solrac |
For some reason my tool ain't reading it (same no -rdynamic error) but I believe it's apart |
| 13:51 |
sfan5 |
made sure to delete the cmake cache before running it again? |
| 13:57 |
solrac |
Had to add a toolchain and clean. thank you tho ^^" Installing missing packages atm |
| 13:58 |
|
tomraceror joined #minetest |
| 14:02 |
|
erlehmann joined #minetest |
| 14:27 |
|
fruitsnack joined #minetest |
| 14:53 |
|
sagax joined #minetest |
| 14:55 |
|
ektor joined #minetest |
| 14:59 |
|
Andrey01 joined #minetest |
| 15:03 |
Andrey01 |
I noted there are pretty lots of players on servers lately |
| 15:04 |
Andrey01 |
regularly totally about 720-750 players online |
| 15:07 |
sfan5 |
people have too much time on their hands due to corona |
| 15:07 |
solrac |
Server has be de-canceled due to Corona Virus |
| 15:07 |
Andrey01 |
I thought about it, too |
| 15:09 |
Andrey01 |
Wow, now already 840 online |
| 15:16 |
MinetestBot |
[git] sfan5 -> minetest/minetestmapper: Fix bug introduced in 9096f70 84c4fc4 https://git.io/JvH6y (2020-03-27T11:45:31Z) |
| 15:16 |
MinetestBot |
[git] sfan5 -> minetest/minetestmapper: Sort out include path mess in CMakeLists a160dc0 https://git.io/JvH6S (2020-03-27T10:19:25Z) |
| 15:17 |
|
tomraceror joined #minetest |
| 15:32 |
MinetestBot |
[git] sfan5 -> minetest/minetestmapper: Properly support -DENABLE_REDIS=TRUE even if library is not found 04b9dff https://git.io/JvHiC (2020-03-27T15:27:55Z) |
| 15:35 |
|
Jdog joined #minetest |
| 15:37 |
|
Fusl joined #minetest |
| 15:43 |
|
fruitsnack joined #minetest |
| 15:47 |
|
Fuchs joined #minetest |
| 15:47 |
|
Flabb joined #minetest |
| 15:50 |
|
Fuchs joined #minetest |
| 15:59 |
|
Extex joined #minetest |
| 16:08 |
|
ANAND joined #minetest |
| 16:16 |
|
Copenhagen_Bram1 joined #minetest |
| 16:20 |
|
Verts joined #minetest |
| 16:21 |
|
lzap joined #minetest |
| 16:31 |
|
ANAND joined #minetest |
| 16:35 |
sfan5 |
!tell JDCodeIt ping |
| 16:35 |
MinetestBot |
sfan5: I'll pass that on when JDCodeIt is around |
| 16:35 |
|
macc24 joined #minetest |
| 16:36 |
|
JDCodeIt joined #minetest |
| 16:36 |
MinetestBot |
JDCodeIt: Mar-27 16:35 UTC <sfan5> ping |
| 16:38 |
JDCodeIt |
sfan5: ping right back at ya |
| 16:38 |
sfan5 |
coincidence? |
| 16:38 |
JDCodeIt |
You believe in those? |
| 16:38 |
sfan5 |
it happens, sometimes |
| 16:39 |
sfan5 |
the slow performance you had with minetestmapper was with an sqlite3 world right? |
| 16:39 |
JDCodeIt |
Yes |
| 16:40 |
sfan5 |
I have implemented some optimizations so it uses a range query whenever possible |
| 16:40 |
sfan5 |
if you have some time, I'd appreciate some testing https://github.com/minetest/minetestmapper/tree/next |
| 16:41 |
JDCodeIt |
At least on "Z" or all axes? |
| 16:41 |
sfan5 |
Z-only |
| 16:41 |
JDCodeIt |
I'll download and run against that large file... |
| 16:42 |
sfan5 |
range queries for the other axes are not possible due to the pos hashing as far as I understand it |
| 16:42 |
sfan5 |
I did implement range queries for all axes in the postgres backend though |
| 16:43 |
JDCodeIt |
I read the <history> </history> section - any chance the map storage would change in future? |
| 16:44 |
sfan5 |
in terms of the serialization or the storage on disk? |
| 16:45 |
sfan5 |
for the latter any future changes will come in the form of a new backend that server owners can migrate to |
| 16:45 |
JDCodeIt |
I meant getting rid of the hash concept and going to three part key, for example |
| 16:48 |
sfan5 |
someone proposed that once IIRC and it wasn't done at the time, might actually happen in the future if the coredevs consider the change justified |
| 16:59 |
JDCodeIt |
OK, it's running now on a test picture 400x400 -2 to +50 in Y. The first message says : Failed to parse color entry 'coloredwood:slope_wood_medium_redviolet_s50_outer_cut_half_raised 102 37 70' |
| 17:00 |
sfan5 |
!c len("coloredwood:slope_wood_medium_redviolet_s50_outer_cut_half_raised") |
| 17:00 |
MinetestBot |
65 |
| 17:00 |
sfan5 |
I guess I could allow node names up to 128 in length |
| 17:02 |
JDCodeIt |
or CString? |
| 17:03 |
JDCodeIt |
I ran the old code last night for 9 of these pictures - took about 10 hours |
| 17:11 |
JDCodeIt |
Just wondering why not compute the block hashes that include the 3D node ranges and only feed this sub-set to the rendering routine |
| 17:29 |
sfan5 |
that's only faster if you reach a certain percentage of lookups you make and blocks that actually exist |
| 17:30 |
sfan5 |
and doesn't work particularily well if you want to render the entire map |
| 17:35 |
JDCodeIt |
Seems like a query optimization step may be needed to approach the problem efficiently |
| 17:35 |
JDCodeIt |
40 minutes and still running to make the picture |
| 17:38 |
sfan5 |
I still plan to implement your suggestion, but I'm wondering what a good heuristic would be so it doesn't try to exhaustively search e.g. an entire map |
| 17:39 |
JDCodeIt |
Maybe break the problem into manageable chunks when it's a big one. Smaller areas like I'm trying might just fit into a single chunk |
| 17:40 |
JDCodeIt |
The mapper just finished at 45 minutes - better than 90! |
| 17:40 |
sfan5 |
great! |
| 17:40 |
sfan5 |
can you run a 'SELECT COUNT(*) FROM blocks;' on your map file? |
| 17:40 |
JDCodeIt |
...and it has colors and everything! |
| 17:41 |
sfan5 |
!c 400 % 16 |
| 17:41 |
MinetestBot |
0 |
| 17:42 |
sfan5 |
!c (400/16) * (400/16) * (52/16 + 1) |
| 17:42 |
MinetestBot |
2656.25 |
| 17:42 |
sfan5 |
!c (400//16) * (400//16) * (52//16 + 1) |
| 17:42 |
MinetestBot |
2500 |
| 17:43 |
|
DS-minetest joined #minetest |
| 17:47 |
JDCodeIt |
Sorry I didn't have the CLI installed, took a minute, and opening from the browser is a bit of a non-starter |
| 17:49 |
JDCodeIt |
it's taking its sweet time counting the records |
| 17:50 |
sfan5 |
hm I would have expected counting to be O(1) |
| 17:52 |
|
Taoki joined #minetest |
| 17:54 |
JDCodeIt |
Guess it's a ton of i/o |
| 17:55 |
sfan5 |
sqlite does have an index of the database contents though... |
| 18:00 |
sfan5 |
...are you sure it's taking more than 15 minutes to count the blocks? |
| 18:02 |
JDCodeIt |
over 1.0 load on the system, yes it's doing something |
| 18:02 |
JDCodeIt |
How cool is that? |
| 18:02 |
JDCodeIt |
CPU load bouncing between 1.1 and 2.7 (2 core machine) |
| 18:03 |
sfan5 |
o.O |
| 18:03 |
JDCodeIt |
Just returned the value - 9764215 |
| 18:04 |
DS-minetest |
you can do ".eqp full" before doing the sql query to see the query plan |
| 18:05 |
JDCodeIt |
error not a boolean value "full" |
| 18:06 |
sfan5 |
!c "%.1f%%" % (2500 / 9764215 * 100) |
| 18:06 |
MinetestBot |
'0.0%' |
| 18:06 |
sfan5 |
eh |
| 18:06 |
sfan5 |
!c "%.20f%%" % (2500 / 9764215 * 100) |
| 18:06 |
MinetestBot |
'0.02560369676415359674%' |
| 18:06 |
DS-minetest |
JDCodeIt: then try "on" or "true" instead of "full" |
| 18:07 |
DS-minetest |
(but it probably won't show interesting information anyway) |
| 18:08 |
|
lzap joined #minetest |
| 18:08 |
JDCodeIt |
I get 0|0|0SCAN TABLE blocks USING COVERING INDEX sqlite_autoindex_blocks_1 |
| 18:10 |
DS-minetest |
yeah, I get the same |
| 18:11 |
|
SwissalpS joined #minetest |
| 18:11 |
DS-minetest |
btw. JDCodeIt what's your sqlite version? |
| 18:11 |
JDCodeIt |
version 3.11.0 |
| 18:12 |
DS-minetest |
(oh, and feel free to ignore me, I'm not helpful anyway) |
| 18:13 |
sfan5 |
guess I can't run count(*) to determine if blocks should be exhaustively searched |
| 18:16 |
JDCodeIt |
interesting if I include a keyed field this thing flies: select count(*) from blocks where pos between -1000000000 and 100000000 - less than a second |
| 18:17 |
JDCodeIt |
I missed a couple zeros there but you get the idea |
| 18:18 |
DS-minetest |
and what's the result then? |
| 18:18 |
JDCodeIt |
the query plan is SEARCH TABLE blocks USING COVERING INDEX ... |
| 18:18 |
JDCodeIt |
same number 9764215 |
| 18:18 |
DS-minetest |
ah |
| 18:18 |
sfan5 |
huh |
| 18:18 |
DS-minetest |
weird |
| 18:21 |
JDCodeIt |
TABLE SCAN is usually never a good idea. |
| 18:21 |
DS-minetest |
have you tried running select count(*) from blocks; again? maybe it's faster now |
| 18:22 |
JDCodeIt |
You're right - it's cached now |
| 18:22 |
DS-minetest |
or maybe sqlite added an index |
| 18:22 |
JDCodeIt |
it can? seems odd to not control such things |
| 18:23 |
DS-minetest |
https://www.sqlite.org/optoverview.html#autoindex |
| 18:23 |
JDCodeIt |
They say "single statement" but is it actually the duration of the connection session? |
| 18:27 |
JDCodeIt |
i think the plan is referring to the Internal index created because pos is unique |
| 18:28 |
JDCodeIt |
Could it take 15 min to read the index the first time? |
| 18:28 |
DS-minetest |
if I do .indexes blocks, I also get sqlite_autoindex_blocks_1 |
| 18:31 |
JDCodeIt |
I quit sqlite3 and went in again. The query is still fast with and without the where clause. Must be buffered in RAM? |
| 18:32 |
|
adfeno joined #minetest |
| 18:32 |
|
DS-minetest_ joined #minetest |
| 18:32 |
adfeno |
Hi all, when using xdecor mod, how do I break xdecor:cobweb ? |
| 18:33 |
|
minduser00 joined #minetest |
| 18:33 |
sfan5 |
tried using a sword? |
| 18:33 |
adfeno |
Im using a silver sword, but nothing happens |
| 18:34 |
|
DS-minetest joined #minetest |
| 18:34 |
JDCodeIt |
groups = {snappy = 3, liquid = 3, flammable = 3}, |
| 18:36 |
adfeno |
sfan5, JDCodeIt: Oh, so silver is weaker than bronze |
| 18:37 |
adfeno |
Swords at least |
| 18:37 |
DS-minetest |
https://github.com/minetest-mods/moreores/blob/e3d8f88e9cbfe2582056ec6987cff005e3e5c379/init.lua#L276 |
| 18:37 |
JDCodeIt |
Depends on how the sword_silver is implemented in moreores |
| 18:38 |
DS-minetest |
!title |
| 18:38 |
MinetestBot |
DS-minetest: moreores/init.lua at e3d8f88e9cbfe2582056ec6987cff005e3e5c379 · minetest-mods/moreores · GitHub |
| 18:38 |
DS-minetest |
there's a time for snappy 3 |
| 18:41 |
adfeno |
Hm, perhaps the moreores mod version being used is older than that commit |
| 18:47 |
JDCodeIt |
sfan5: I guess I need to reboot that box to see if the slow query is a first time read thingy |
| 18:47 |
sfan5 |
you can also drop caches without rebooting |
| 18:53 |
DS-minetest |
did you know that farming in mtg is easier at world boarders? |
| 18:53 |
DS-minetest |
soil won't dry out |
| 18:54 |
JDCodeIt |
did a boot anyway - yes it's slow again even with the SEARCH TABLE plan |
| 18:56 |
JDCodeIt |
The file system is ETX4, so should not suffer from fragmentation so much - maybe this is just thrashing the disk |
| 18:59 |
JDCodeIt |
e4defrag says it is 162 fragments which doesn |
| 18:59 |
JDCodeIt |
t seem awful |
| 19:05 |
|
Flabb joined #minetest |
| 19:06 |
|
Fixer_ joined #minetest |
| 19:08 |
|
HolyGun joined #minetest |
| 19:19 |
JDCodeIt |
sfan5: you mean sync; echo 1 > /proc/sys/vm/drop_caches ? |
| 19:19 |
sfan5 |
yea |
| 19:28 |
|
Extex joined #minetest |
| 19:43 |
|
Kimapr_ joined #minetest |
| 19:46 |
|
mransom joined #minetest |
| 19:46 |
|
est joined #minetest |
| 19:54 |
|
nates2ndaccount joined #minetest |
| 19:56 |
|
oil_boi_ joined #minetest |
| 19:57 |
oil_boi_ |
texmex: Alright, I'm gonna try it, here we go |
| 19:57 |
oil_boi_ |
texmex: I'm also working on a new mob creation tool which will make the head seperate from the body so the mob can look around |
| 19:58 |
DS-minetest |
^ I did that once with a tank |
| 20:00 |
DS-minetest |
question: do we still need to use things like MutexedQueue in c++11? |
| 20:01 |
sfan5 |
what would you propose instead? |
| 20:04 |
DS-minetest |
using std::dequeue directly (at https://en.cppreference.com/w/cpp/container there's that c++11 thread safety block) |
| 20:06 |
DS-minetest |
(but I'm a bit confused. does "can be called concurrently" mean that you are safe if you try calling it from multiple threads or that there are concurrency-problems because it doesn't lock?) |
| 20:08 |
DS-minetest |
ah, forget it, I understand now |
| 20:10 |
sfan5 |
JDCodeIt: here's another thing to test https://github.com/minetest/minetestmapper/tree/next |
| 20:11 |
sfan5 |
if you use it with the narrow limits from before it'll try to grab the 2500 blocks it needs directly without ever making a single range query |
| 20:11 |
sfan5 |
...which should be much quicker than the previous run of 45 minutes |
| 20:12 |
JDCodeIt |
Ok will give it a go - but traversing the file entirely with the count(*) takes 17 minutes alone. |
| 20:12 |
sfan5 |
don't worry it doesn't do so |
| 20:12 |
|
lzap joined #minetest |
| 20:19 |
JDCodeIt |
16 seconds first time, less than a second on a re-run |
| 20:20 |
JDCodeIt |
Incredible |
| 20:20 |
JDCodeIt |
What was the main structural change? |
| 20:22 |
JDCodeIt |
Would this also avoid the problem where table locking starts to occur and really make minetestserver angry? |
| 20:36 |
sfan5 |
does a read query lock the database? |
| 20:36 |
sfan5 |
the main structural change is this -> <JDCodeIt> Just wondering why not compute the block hashes that include the 3D node ranges and only feed this sub-set to the rendering routine |
| 20:37 |
JDCodeIt |
Right I see that in the change log - now I'm checking how it scales with a 8000x8000 image |
| 20:38 |
sfan5 |
the only remaining problem is to come up with a heuristic to devide when to do this and when to do the usual thing |
| 20:39 |
JDCodeIt |
If this takes about 26 minutes, it's linear |
| 20:40 |
sfan5 |
should be |
| 20:41 |
sfan5 |
a better question is: would rendering that 8000x8000 image the usual way been faster? |
| 20:41 |
sfan5 |
still using --min-y -2 and --max-y 50 ? |
| 20:42 |
JDCodeIt |
Yes, same Y range. You mean the "next" version just before this one? |
| 20:42 |
sfan5 |
yes |
| 20:42 |
sfan5 |
!c (8000//16) * (8000//16) * (52//16 + 1) |
| 20:42 |
MinetestBot |
1000000 |
| 20:43 |
JDCodeIt |
Non-linear - took 16 minutes |
| 20:43 |
JDCodeIt |
24 MB image file |
| 20:44 |
JDCodeIt |
You can see where players went on a walkabout |
| 20:47 |
JDCodeIt |
Do you expect 90 minutes or more for such a large area using the old code? |
| 20:47 |
DS-minetest |
does anyone here know how to use doxygen in minetest? |
| 20:47 |
JDCodeIt |
I'm going to run the whole map just for grins |
| 20:47 |
sfan5 |
likely hours |
| 20:48 |
sfan5 |
and now that you mention it, I don't think you need to test that; it will be terribly slow either way |
| 20:49 |
JDCodeIt |
!c (62000//16) * (62000//16) * (52//16 + 1) |
| 20:49 |
MinetestBot |
60062500 |
| 20:51 |
JDCodeIt |
If a lot of the blocks are not generated, think it could speed through those sections? |
| 20:51 |
sfan5 |
how would it know without doing a range query? |
| 20:52 |
JDCodeIt |
Not to know in advance, but I'm wondering how long this will run now with the current code - maybe overnight... |
| 20:52 |
sfan5 |
hm, there's still some potential, it could run just one range query instead of a bunch |
| 20:54 |
JDCodeIt |
Anyway one cannot do something that large - exceeds INT_MAX |
| 20:54 |
DS-minetest |
ah, I have to do make doc |
| 20:56 |
DS-minetest |
apparently the description the introducing commit is the best source of information here XP |
| 20:57 |
JDCodeIt |
16000x16000 image generation is running just over a gig of RAM |
| 21:01 |
JDCodeIt |
The 16 minute job had lots of space that was not explored yet, so maybe this is why it performed better than linear |
| 21:11 |
oil_boi_ |
Ah man, I don't think there's any doc for this https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L4472 |
| 21:12 |
sfan5 |
which documentation are you missing? |
| 21:13 |
JDCodeIt |
documentation for the documentation? |
| 21:13 |
oil_boi_ |
sfan5: Ohhh, that submenu doesn't reference https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L2819 that's weird |
| 21:18 |
JDCodeIt |
Interesting - 19 minutes for the 16000x16000 image |
| 21:19 |
JDCodeIt |
Vast majority of the map is unexplored |
| 21:20 |
sfan5 |
!c (16000//16) * (16000//16) * (52//16 + 1) |
| 21:20 |
MinetestBot |
4000000 |
| 21:20 |
sfan5 |
interesting |
| 21:20 |
sfan5 |
looks like I really need a good heuristic for this |
| 21:27 |
|
absurb joined #minetest |
| 21:28 |
|
Taoki joined #minetest |
| 21:30 |
JDCodeIt |
Well I like this code for my purposes - it hasn't been tested for other types of worlds e.g. skyblock |
| 21:32 |
|
Taoki joined #minetest |
| 21:33 |
|
solrac joined #minetest |
| 21:34 |
JDCodeIt |
It was fun going through that with you. I hope others will reap the benefits as well. |
| 21:35 |
sfan5 |
sure, thanks for taking the time to test my changes |
| 21:58 |
|
Hirato joined #minetest |
| 22:02 |
oil_boi_ |
texmex: I added in the cheat function |
| 22:05 |
JDCodeIt |
sfan5: does a read query lock the database - yes something rather bad starts to happen if you try to read a world for a long time while the server is using the same file |
| 22:06 |
JDCodeIt |
All the tests I did above were on an offline backup |
| 22:08 |
JDCodeIt |
If minetest follows the sqlite protocol to obtain a SHARED lock until ready to write, then getting a RESERVED lock when writing, it all should work out |
| 22:09 |
sfan5 |
what happens if the mapper is still inside a SELECT query while minetestserver wants to write? |
| 22:09 |
sfan5 |
I don't see a way to avoid locking in that situation |
| 22:10 |
JDCodeIt |
It has a journaling system, so this is what the doc says: Only one process at a time can hold a RESERVED lock. But other processes can continue to read the database while the RESERVED lock is held. |
| 22:11 |
DS-minetest |
so, they always read the old version? |
| 22:12 |
* DS-minetest |
wonders how many locks there are, just one for the entire db or one per table or some hierarchic thing or something else... |
| 22:12 |
JDCodeIt |
READ processes are reading the disk image. Pages not written to the disk are in the journal. When all the reading processes are done, the journal in memory can be written to disk |
| 22:13 |
sfan5 |
ah so that still blocks *something* but not the writing, it only blocks the journal merging |
| 22:13 |
sfan5 |
unless this means that COMMIT will block, that would cause problems |
| 22:14 |
JDCodeIt |
An explicit COMMIT will wait for the SHARED locks to be all gone - seems it could block the process trying to commit |
| 22:15 |
DS-minetest |
so, if something holds a shared lock for a long time, minetest will always read the old version of the map |
| 22:16 |
sfan5 |
sounds like it might be better for minetestmapper to use sqlite's backup functionality to take a snapshop of the db and let minetest continue working on it |
| 22:17 |
JDCodeIt |
I think minetest is going to have to commit the change before reading back the block later, right? |
| 22:19 |
JDCodeIt |
To be kind to the database, one should release the SHARED lock as soon as practical and often |
| 22:20 |
JDCodeIt |
When the data base file needs to be written to the lock goes to PENDING - which delays new SHARED locks until the write is done |
| 22:21 |
JDCodeIt |
So, instead of holding the lock during the whole activity, one should release it often and only gain it back when something new must be read |
| 22:21 |
JDCodeIt |
docs - A PENDING lock means that the process holding the lock wants to write to the database as soon as possible and is just waiting on all current SHARED locks to clear so that it can get an EXCLUSIVE lock. No new SHARED locks are permitted against the database if a PENDING lock is active, though existing SHARED locks are allowed to continue. |
| 22:22 |
JDCodeIt |
I think perhaps only the writer is trying to do this internally, not user code |
| 23:18 |
|
Hirato joined #minetest |
| 23:18 |
MinetestBot |
[git] sfan5 -> minetest/minetestmapper: Implement --exhaustive y mode as another database access optimization cb8341a https://git.io/JvHAP (2020-03-27T23:14:47Z) |
| 23:18 |
MinetestBot |
[git] sfan5 -> minetest/minetestmapper: Optimize database access further by allowing "brute-force" queries in… 7ff2288 https://git.io/JvHAX (2020-03-27T22:38:18Z) |
| 23:18 |
MinetestBot |
[git] sfan5 -> minetest/minetestmapper: Rewrite DB class to allow backends to fully optimize block fetches 5b264fd https://git.io/JvHA1 (2020-03-27T19:30:13Z) |
| 23:18 |
MinetestBot |
[git] sfan5 -> minetest/minetestmapper: Rewrite config file parser ecc2b31 https://git.io/JvHAM (2020-03-27T18:33:42Z) |
| 23:19 |
sfan5 |
13 hours and I haven't done anything except programming |
| 23:19 |
Extex |
Wow sfan you're on a roke |
| 23:19 |
sfan5 |
yes, but I'm done now |
| 23:19 |
Extex |
role* |
| 23:28 |
nephele |
Heh, and here i am starting modding on minetest for the day :D |
| 23:34 |
|
galaxie joined #minetest |
| 23:44 |
MinetestBot |
[git] sfan5 -> minetest/minetestmapper: Fix minY/maxY calculation (closes #66) 48bf44c https://git.io/JvHxz (2020-03-27T23:40:38Z) |
| 23:54 |
|
Pie-jacker875 joined #minetest |
| 23:57 |
MinetestBot |
[git] sfan5 -> minetest/minetestmapper: Fix another bug in the Redis backend 539bdbd https://git.io/JvHxb (2020-03-27T23:56:11Z) |
| 23:58 |
|
Taoki joined #minetest |
