Minetest logo

IRC log for #minetest, 2020-03-27

| Channels | #minetest index | Today | | Google Search | Plaintext

All times shown according to UTC.

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

| Channels | #minetest index | Today | | Google Search | Plaintext