| 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:09 |
|
Void7 joined #minetest-dev |
| 00:10 |
|
xunto joined #minetest-dev |
| 00:10 |
|
ptv joined #minetest-dev |
| 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:15 |
|
sloanonlinux joined #minetest-dev |
| 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:37 |
|
cat5e joined #minetest-dev |
| 00:43 |
|
Taoki joined #minetest-dev |
| 00:51 |
paramat |
game#1171 |
| 00:51 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1171 -- Remove reverse crafting of mese crystals and fragments |
| 01:01 |
|
Miner_48er joined #minetest-dev |
| 01:24 |
|
KaadmY joined #minetest-dev |
| 01:36 |
|
everamzah joined #minetest-dev |
| 01:36 |
|
VargaD joined #minetest-dev |
| 01:36 |
|
Sokomine joined #minetest-dev |
| 01:38 |
|
Tmanyo joined #minetest-dev |
| 01:46 |
|
Ambistic joined #minetest-dev |
| 01:49 |
|
lisac joined #minetest-dev |
| 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. |
| 02:30 |
|
halt_ joined #minetest-dev |
| 03:13 |
|
domtron joined #minetest-dev |
| 03:15 |
|
Void7 joined #minetest-dev |
| 03:24 |
|
paramat joined #minetest-dev |
| 03:33 |
paramat |
shocking |
| 03:55 |
VanessaE |
what |
| 04:04 |
paramat |
you having no opinion :] |
| 04:06 |
VanessaE |
:P |
| 04:08 |
|
Tmanyo joined #minetest-dev |
| 04:10 |
|
red-001 joined #minetest-dev |
| 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:02 |
|
Calinou joined #minetest-dev |
| 05:09 |
|
Hunterz joined #minetest-dev |
| 05:11 |
paramat |
'hot' |
| 05:12 |
paramat |
which is still lava groups |
| 05:14 |
|
Grandolf joined #minetest-dev |
| 05:18 |
VanessaE |
hm, I thought it was something else |
| 05:18 |
VanessaE |
roughly similar to melty.. |
| 05:19 |
VanessaE |
*shrug* |
| 05:19 |
|
Calinou joined #minetest-dev |
| 05:30 |
|
nrzkt joined #minetest-dev |
| 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:04 |
|
ssieb joined #minetest-dev |
| 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 :] |
| 06:26 |
|
paramat left #minetest-dev |
| 08:25 |
|
Darcidride joined #minetest-dev |
| 09:01 |
|
red-001 joined #minetest-dev |
| 09:05 |
|
red-001 joined #minetest-dev |
| 09:19 |
|
tenplus1 joined #minetest-dev |
| 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 |
| 09:28 |
|
tenplus1 left #minetest-dev |
| 09:56 |
|
nrzkt joined #minetest-dev |
| 09:57 |
|
bugzapper joined #minetest-dev |
| 10:32 |
|
proller joined #minetest-dev |
| 10:40 |
|
Player_2 joined #minetest-dev |
| 11:59 |
|
Taoki joined #minetest-dev |
| 12:39 |
|
proller joined #minetest-dev |
| 12:48 |
|
tenplus1 joined #minetest-dev |
| 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 |
| 13:07 |
|
Grandolf joined #minetest-dev |
| 13:11 |
|
tenplus1 left #minetest-dev |
| 13:17 |
|
Lunatrius joined #minetest-dev |
| 13:55 |
|
lisac joined #minetest-dev |
| 14:01 |
|
T4im joined #minetest-dev |
| 14:20 |
|
KaadmY joined #minetest-dev |
| 14:20 |
|
Void7 joined #minetest-dev |
| 14:24 |
|
dmurph joined #minetest-dev |
| 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 |
| 14:49 |
|
Fixer joined #minetest-dev |
| 15:07 |
|
Tmanyo joined #minetest-dev |
| 15:29 |
|
Hunterz joined #minetest-dev |
| 15:36 |
|
Krock joined #minetest-dev |
| 15:47 |
|
domtron joined #minetest-dev |
| 15:47 |
|
proller joined #minetest-dev |
| 15:59 |
|
hmmmm joined #minetest-dev |
| 16:00 |
|
edgrey joined #minetest-dev |
| 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. |
| 16:35 |
|
Fixer joined #minetest-dev |
| 16:42 |
|
Void7 joined #minetest-dev |
| 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 |
| 17:55 |
|
Void7 joined #minetest-dev |
| 18:00 |
|
domtron joined #minetest-dev |
| 18:24 |
|
Ambistic joined #minetest-dev |
| 18:49 |
|
damiel_ joined #minetest-dev |
| 19:05 |
|
nrzkt joined #minetest-dev |
| 19:08 |
|
Void7 joined #minetest-dev |
| 19:42 |
|
Hunterz joined #minetest-dev |
| 19:43 |
|
edgrey joined #minetest-dev |
| 19:45 |
|
Calinou joined #minetest-dev |
| 19:47 |
|
exoplanet joined #minetest-dev |
| 19:54 |
|
lisac joined #minetest-dev |
| 20:05 |
|
hmmmmm joined #minetest-dev |
| 20:10 |
|
ptv joined #minetest-dev |
| 20:29 |
|
Miner_48er joined #minetest-dev |
| 21:26 |
|
domtron joined #minetest-dev |
| 21:38 |
|
troller joined #minetest-dev |
| 21:49 |
|
Zeitgeist_ joined #minetest-dev |
| 21:51 |
|
jomat_ joined #minetest-dev |
| 21:52 |
|
Void7 joined #minetest-dev |
| 21:53 |
|
cat5e joined #minetest-dev |
| 21:54 |
|
ElectronLibre joined #minetest-dev |
| 21:55 |
|
domtron joined #minetest-dev |
| 22:19 |
|
paramat joined #minetest-dev |
| 22:37 |
paramat |
please can anyone review hmmmm's important mapgen parameters commit? https://github.com/kwolekr/minetest/commit/30b77a79505f4e32df5d00d0c8e2ea50f63900c3 |
| 22:37 |
|
proller joined #minetest-dev |
| 22:55 |
|
proller joined #minetest-dev |
| 23:11 |
|
Tmanyo joined #minetest-dev |
| 23:16 |
|
jomat joined #minetest-dev |
| 23:46 |
|
proller joined #minetest-dev |
