Time  Nick      Message
00:00 hmmmm     nope
00:00 hmmmm     set_noiseparams() is still necessary for global settings
00:00 hmmmm     i will however move it to l_settings.cpp in the future
00:01 hmmmm     or rather, deprecate it and replace it with a generic settings group interface that works on an arbitrary table
00:01 hmmmm     set/get_noiseparams will be implemented in lua
00:04 hmmmm     i made it so that you can't set mapgen settings while the mapgen is running, but even if you did, it would be meaningless without re-generating the MapgenParams structure
00:05 hmmmm     i suppose it is possible to safely do by surrounding all access to any Mapgen with a mutex, and if mg_name changed, reallocate the mapgens between makeChunk calls
00:05 hmmmm     but why would you want to do that?
00:08 paramat   yeah just seen 'if (mapgen_params) return false'
00:09 paramat   and indeed we don't need to do this
00:14 hmmmm     like
00:15 hmmmm     maybe i can see there being potential for a game that wants to change mapgen params including mapgen on runtime to enter into a new realm or so to spaek
00:15 hmmmm     but if that's the case then why isn't it using a lua mapgen to start with
00:26 paramat   i didn't fully understand all of this, but i understood more than i expected to. +1 for what it's worth
00:30 sofar     hmmmm: it may be interesting to make a mapgen that continuously adjusts params based on gameplay
00:31 paramat   i like the new functionality. looking forward to dungeon params being easily settable the same way, had a request for this today
00:31 hmmmm     the best part about all this is, now adding adjustable DungeonParams is downright trivial
00:51 paramat   game#1171
00:51 ShadowBot https://github.com/minetest/minetest_game/issues/1171 -- Remove reverse crafting of mese crystals and fragments
02:17 paramat   game#1172
02:17 ShadowBot https://github.com/minetest/minetest_game/issues/1172 -- Default/mapgen: Add precious ores above y = 1024 by paramat
02:18 VanessaE  "There's gold in them thar hills!"
02:23 paramat   VanessaE, you may want to comment on game 1171, bbl
02:24 VanessaE  I have no opinion on it.
03:33 paramat   shocking
03:55 VanessaE  what
04:04 paramat   you having no opinion :]
04:06 VanessaE  :P
04:16 paramat   does anyone use the 'melty' group? it was added to steel door on 19 Nov 2012 by PilzAdam
04:17 paramat   i can't see 'melty' used anywhere
04:24 paramat   i'll remove it then next chance
04:29 VanessaE  you may as well remove it along with that other group
04:29 VanessaE  wtf was it.. weather related..
05:11 paramat   'hot'
05:12 paramat   which is still lava groups
05:18 VanessaE  hm, I thought it was something else
05:18 VanessaE  roughly similar to melty..
05:19 VanessaE  *shrug*
05:43 sofar     paramat: https://github.com/PilzAdam/nether/pull/20 ?
05:46 paramat   looking
05:51 paramat   +1
05:57 sofar     aight, bedtime again, I'm out
05:58 paramat   will merge games 1167 1169 1170 in a moment
06:08 paramat   merging
06:11 paramat   done
06:13 paramat   minetest has 650 issues but the good news is 308 are feature requests, and only 181 are bugs :]
09:20 tenplus1  pull game#1081 restructured to remove place_liquid function, need dev to look at it plz
09:20 ShadowBot https://github.com/minetest/minetest_game/issues/1081 -- Placing liquid in protected area fixed by tenplus1
09:25 tenplus1  ...also game#1085 amended for server use
09:25 ShadowBot https://github.com/minetest/minetest_game/issues/1085 -- Disabling TNT by tenplus1
12:48 tenplus1  pull game#1081 updated with HybridDog's latest pull...  could a dev check pls for addition
12:48 ShadowBot https://github.com/minetest/minetest_game/issues/1081 -- Placing liquid in protected area fixed by tenplus1
14:32 T4im      xunto: you said yesterday, you are already using the linting stuff for your game; does that include travis usage? if yes, then it would be helpful to know, if that works, or if game#1165 still needs some changes for that
14:32 ShadowBot https://github.com/minetest/minetest_game/issues/1165 -- Let Travis-CI automatically lint the lua code of the game. by t4im
16:05 hmmmm     hey guys, do you think auto-item-pickup is a feature used often enough to warrant being put into the engine?
16:06 hmmmm     the operation could be a lot faster than it exists right now by making silly approximations of 'nearness'
16:07 hmmmm     truncate the coordinates for each active item by a factor of two and insert that into a multimap.  when the player steps do a lookup on that map and any items in that grid will then start getting vaccumed up
16:07 T4im      sounds like a great idea imo; it also seems to be one of the more expensive operations during profiling usually
16:07 Fixer     some people will welcome it, including me
16:08 hmmmm     the only problem with this is that people will undoubtably want the sucking radius to be adjustable, but it needs to remain small in order to keep the illusion of working properly
16:09 nore      hmmmm: idea then:
16:09 nore      store the items like that
16:10 nore      but when player is somewhere, walk among the positions that may contain items close enough
16:10 nore      and among those items, check those that are actually close enough
16:10 hmmmm     oh yeah i guess that makes sense too
16:10 nore      it's a bit more expensive, but not that much
16:10 hmmmm     so that'd be like 8 more lookups
16:10 hmmmm     maybe 4 if you're willing to make assumptions about the surface
16:10 nore      if the step is close to the size of radius
16:11 hmmmm     here's one of my wackier ideas that may still have some merit:
16:11 nore      8 multimap lookups is not something expensive
16:11 nore      even 1000 is still ok
16:11 hmmmm     3 multimaps, designated for each coordinate x y z
16:11 hmmmm     each item position is stored in each of these three
16:11 hmmmm     so that's 3x storage space
16:11 nore      hm...
16:12 hmmmm     now the players maintain their position inside of these maps
16:12 nore      what about that: https://en.wikipedia.org/wiki/R*_tree
16:12 hmmmm     remember they're ordered so we maintain an iterator per-player in each of these three maps
16:12 hmmmm     only problem is that if an item is inserted close to the player that might invalidate their iterator...
16:12 nore      hmmmm: no, multimap iterators are not invalidated by inserting items
16:13 nore      I checked that
16:13 nore      since this feature is used in the nodetimer efficiency code
16:13 hmmmm     but anyway the neighboring values would get checked for being within the radius
16:13 nore      hmmmm: but what not use specialized spatial data structures?
16:14 hmmmm     say for X multimap:  207, 207,  <player here>, 406, 435    |  Y multimap:  0, <player here>, 10 | Z multimap:  50, 60, <player here>, 90
16:14 hmmmm     so it'd do a check on the flink and blink
16:14 hmmmm     if blink is > current_pos.X - radius then reject
16:14 hmmmm     and so on and so forth with all of the 6 neighbors
16:15 hmmmm     if one of them passes all the constraints you can consider it 'near' and then use that one
16:15 xunto     >(05:32:29 PM) T4im: xunto: you said yesterday, you are already using the linting stuff for your game; does that include travis usage? if yes, then it would be helpful to know, if that works, or if game#1165 still needs some changes for that
16:15 xunto     It works but building of environment is too long. You can't do anything about this but it's quite faster to execute luacheck manually.
16:15 ShadowBot https://github.com/minetest/minetest_game/issues/1165 -- Let Travis-CI automatically lint the lua code of the game. by t4im
16:16 hmmmm     the issue with R trees is that the sectors need to move around
16:16 hmmmm     err wait
16:16 xunto     ofc it's still usefull for checking incoming pull requests
16:16 hmmmm     no each item would be the sector
16:17 T4im      xunto: alright thanks, that helps
16:17 nore      hmmmm: no, the x/y/z idea wouldn't work
16:17 nore      let's say the player is at 0,0,0
16:17 nore      there's an item at 1,1,1 that should be taken
16:17 nore      but there are items at 0.5,100,100, 100,0.5,100 and 100,100,0.5
16:18 hmmmm     well the item you're matching the constraints against would need to be the same item
16:18 nore      yes
16:19 hmmmm     that can be checked no problem
16:19 nore      but you'll have a lot of checks to do
16:19 hmmmm     so it'd require 6 lookups
16:19 hmmmm     maximum
16:19 nore      no, why would it?
16:19 nore      let's say you're walking the x multimap
16:20 nore      you first hit the 0.5,100,100 item
16:20 nore      and you say that it is too far and abort
16:20 nore      it will be the same for the other items
16:20 nore      and you won't get to the 1,1,1 one
16:21 hmmmm     oh no you don't understand
16:21 hmmmm     i'm not *walking* these multimaps, the player is already there
16:21 hmmmm     so the multimap should look like
16:22 hmmmm     (0.5, 100, 100), <player here>, (1, 1, 1)
16:22 hmmmm     sorted by the X value
16:22 nore      no, the player is at 0,0,0
16:22 hmmmm     right
16:22 nore      so it would be <player here>, (0.5, 100, 100), (1, 1, 1°
16:22 nore      s/°/)/
16:22 hmmmm     oh right the player is 0.0
16:22 hmmmm     well it wouldn't be rejected right away
16:23 hmmmm     it'd look past the immediate neighbors until all X values are out of range
16:23 hmmmm     this would make operations slow if there were many items in a straight line though...
16:23 nore      ^ that means that items far away would ruin performance
16:23 nore      the other solution was better
16:24 nore      but still, I'd say a specialized spatial data structure (I think we even have this code in the engine now) should be better for that
16:30 hmmmm     i think an R-tree might be a corrected version of what I proposed...
16:30 hmmmm     i'm reading about it right now
16:32 hmmmm     oh i see how an R tree works.
17:04 hmmmm     really wish est didn't go with a C++ library for the spatial areastore support...
17:05 hmmmm     as if leveldb isn't enough of a nightmare to get working :) lol
22:37 paramat   please can anyone review hmmmm's important mapgen parameters commit? https://github.com/kwolekr/minetest/commit/30b77a79505f4e32df5d00d0c8e2ea50f63900c3