Time |
Nick |
Message |
00:06 |
waressearcher2 |
turtleman_: any suggestions of a new name ? |
00:08 |
turtleman_ |
what kind of tree gives you apples 1/8 of the time |
00:08 |
turtleman_ |
maybe just call it an apple tree? |
00:08 |
turtleman_ |
thats the only thing that makes sense to me |
00:15 |
waressearcher2 |
turtleman_: it can still be that "minecraft" influence so for time being it will be called "tree" |
00:16 |
waressearcher2 |
turtleman_: like you don't call "dirt" block a "soil" or "earth" |
00:26 |
turtleman_ |
huh? im a little confused |
00:26 |
turtleman_ |
im just saying that there are specific trees now, like pine, acacia, and jungle |
00:26 |
turtleman_ |
i just want things to be symmetric. |
00:31 |
T4im |
you do have a point with the name; perhaps suggest it in the minetest_game issue tracker? that way it will be seen by more people |
00:33 |
turtleman_ |
ok |
00:33 |
T4im |
https://github.com/minetest/minetest_game/issues |
00:33 |
T4im |
:) |
00:53 |
turtleman_ |
https://github.com/minetest/minetest_game/issues/684 |
00:58 |
|
paramat joined #minetest-dev |
01:02 |
paramat |
although nice to have specific tree types, changing the code is too disruptive. tree is some kind of appletree. the best match for jungletree seems to be rosewood |
01:10 |
turtleman_ |
paramat, what do you mean? are you opposed to the new trees? |
01:11 |
paramat |
i like the idea of specifying the trees, i have thought about that too. changing the code causes too many problems though |
01:12 |
paramat |
the best match for the dark junglewood colour is wenge |
01:14 |
|
H-H-H joined #minetest-dev |
01:16 |
paramat |
we can still possibly consider appletree and jungletree to be specific species, just not change the names in the code =) |
01:25 |
|
werwerwer joined #minetest-dev |
01:38 |
|
paramat left #minetest-dev |
01:42 |
turtleman_ |
jungletree is already in code though, isnt it>? |
01:42 |
turtleman_ |
i thought they were already separate |
01:42 |
turtleman_ |
jungle, acacia, pine |
01:42 |
turtleman_ |
are they parts of the same base? |
01:47 |
waressearcher2 |
what about bamboo ? |
02:10 |
turtleman_ |
bamboo sounds cool |
02:10 |
|
leat joined #minetest-dev |
03:10 |
|
eugd joined #minetest-dev |
03:14 |
waressearcher2 |
when someone trying to fix source and upload to main git repository, how can he be sure that no one edited that file allready ? |
03:15 |
asl97 |
it should error when you push if someone edited that file |
03:17 |
waressearcher2 |
so in that case you redownload and reedit and reupload it ? what if it gives an error again ? |
03:18 |
asl97 |
you redownload and reedit and reupload it again xD |
03:18 |
asl97 |
until it get in, more or less |
03:19 |
|
eugd joined #minetest-dev |
03:20 |
waressearcher2 |
can't you just block the file while you editing and uploading ? so everyone else will wait ? |
03:23 |
asl97 |
i doubt this kind of thing happen much |
03:32 |
asl97 |
waressearcher2: as when it error, you just need to git pull it and it should auto-merging whatever edit the other people did (most of the time) |
03:54 |
hmmmm |
aghh |
03:55 |
hmmmm |
what kind of suffix should be used to mean "a more advanced version of the same function" |
03:55 |
hmmmm |
i would use Ex but the meaning of that is muddled thanks to the NoEx suffix |
03:57 |
ShadowNinja |
Plus? |
03:58 |
ShadowNinja |
You'll need to document what "more advanced" means though. |
04:00 |
est31 |
I guess more options or so... |
04:04 |
waressearcher2 |
function, function_, function_2, function_50 |
04:05 |
asl97 |
waressearcher2: that's postfix |
04:05 |
waressearcher2 |
use postfix, but sendmail is better |
04:08 |
VanessaE |
hmmmm: _extended ? |
04:08 |
hmmmm |
meh |
04:08 |
VanessaE |
(or just _advanced) |
04:08 |
est31 |
_ is bad |
04:09 |
est31 |
we have CamelCase |
04:09 |
VanessaE |
ok camelCase then |
04:09 |
est31 |
well, camelCase |
04:09 |
hmmmm |
by the way about that |
04:09 |
VanessaE |
either way, don't go digging out the thesaurus :P |
04:09 |
hmmmm |
do you guys like our current setup of having ClassName::camelCaseMethod()? |
04:09 |
est31 |
yes |
04:09 |
hmmmm |
or would you prefer ClassName::PascalCaseMethod() |
04:10 |
hmmmm |
I noticed some functions in RemoteClient use the latter |
04:10 |
est31 |
meh, no, camel better than pascal |
04:10 |
est31 |
but honestly not that important |
04:11 |
hmmmm |
of course not |
04:12 |
hmmmm |
i just want to make sure the code style actually reflects what the developers want |
04:12 |
hmmmm |
check up every couple of months |
04:13 |
est31 |
I dont think we should change code style |
04:13 |
est31 |
bc that leads to first doing it in style a then changing to b then back to a etc |
04:14 |
|
paramat joined #minetest-dev |
04:15 |
paramat |
i prefer camelcase, one less shift press |
04:35 |
* hmmmm |
blinks |
04:35 |
|
Miner_48er joined #minetest-dev |
04:36 |
hmmmm |
http://fpaste.org/271312/43155755/ |
04:38 |
est31 |
wtf |
04:39 |
est31 |
its also funny |
04:39 |
est31 |
if (pos_ok) do_a; |
04:39 |
hmmmm |
// really want to make sure we got the correct node |
04:39 |
est31 |
if (!pos_ok) { do_b; } |
04:40 |
est31 |
instead of doing else |
04:41 |
|
OldCoder joined #minetest-dev |
04:41 |
est31 |
hmmmm, btw seen what Robert_Zenz has pointed out in your commit |
04:42 |
hmmmm |
? |
04:42 |
est31 |
the param does more than queue control after all |
04:42 |
est31 |
it sets flags for the queue entry |
04:42 |
hmmmm |
yeah I know |
04:43 |
est31 |
okay, you are aware thats good |
04:44 |
hmmmm |
hah! i was right |
04:45 |
hmmmm |
that was zeno |
04:45 |
hmmmm |
https://github.com/minetest/minetest/commit/5b8855e83c0d1cc7aef21492e7fe862b7d06917e#diff-ad60d65b34e16a3319296bb5d683acd6R2427 |
04:45 |
hmmmm |
no clue how I didn't catch that when originally reviewing this |
04:46 |
hmmmm |
in any case |
04:46 |
hmmmm |
I don't see any actual reason why the block needs to be queued into the emerge queue |
04:47 |
hmmmm |
it's fruitless - if the user is close enough to a node to interact with it, and it has not been loaded yet, you can be certain it'll get loaded soon enough |
04:47 |
hmmmm |
either that or they're cheating |
04:48 |
est31 |
yeah, it should be better just be a warning and done |
04:48 |
est31 |
the result isnt used anywhere |
04:49 |
hmmmm |
alternatively, it could be a way to get blocks unstuck that somehow get stuck |
04:49 |
hmmmm |
i wonder if that had been the original intention |
04:53 |
est31 |
thats fighting the symptoms |
04:54 |
est31 |
better find out why they get stuck and then fix that |
04:54 |
est31 |
if they do |
04:54 |
hmmmm |
of course |
05:17 |
|
paramat left #minetest-dev |
05:48 |
|
Darcidride joined #minetest-dev |
06:13 |
|
nrzkt joined #minetest-dev |
06:20 |
|
Hunterz joined #minetest-dev |
06:29 |
|
Player_2 joined #minetest-dev |
06:48 |
|
VargaD joined #minetest-dev |
07:00 |
|
VanessaE joined #minetest-dev |
07:13 |
|
Krock joined #minetest-dev |
07:53 |
|
julienrat joined #minetest-dev |
07:53 |
|
julienrat left #minetest-dev |
08:32 |
|
Amaz joined #minetest-dev |
09:12 |
|
T4im joined #minetest-dev |
09:31 |
|
lisacvuk joined #minetest-dev |
10:12 |
|
Krock joined #minetest-dev |
11:00 |
|
proller joined #minetest-dev |
11:04 |
|
turtleman_ joined #minetest-dev |
11:06 |
|
kilbith joined #minetest-dev |
11:18 |
|
H-H-H joined #minetest-dev |
11:44 |
|
Calinou joined #minetest-dev |
12:21 |
|
lisacvuk joined #minetest-dev |
12:46 |
|
Calinou joined #minetest-dev |
12:47 |
|
Amaz joined #minetest-dev |
13:18 |
|
Player_2 joined #minetest-dev |
13:31 |
|
Zeitgeist_ joined #minetest-dev |
14:03 |
|
kilbith joined #minetest-dev |
14:05 |
|
Zeitgeist_ joined #minetest-dev |
14:17 |
|
hmmmm joined #minetest-dev |
15:12 |
|
eugd joined #minetest-dev |
15:14 |
|
EvergreenTree joined #minetest-dev |
15:33 |
|
Miner_48er joined #minetest-dev |
15:40 |
|
rubenwardy joined #minetest-dev |
15:48 |
|
CraigyDavi joined #minetest-dev |
16:14 |
|
proller joined #minetest-dev |
16:17 |
eugd |
https://github.com/minetest/minetest/pull/3199 what's up with the check results here? |
16:19 |
hmmmm |
check results? |
16:19 |
hmmmm |
it looks like they passed... |
16:19 |
hmmmm |
oh I see what you're talking about |
16:20 |
hmmmm |
yeah I have no idea what you're doing wrong, but it wouldn't hurt to squash all those commits into one and then see what happens |
16:22 |
|
Soni joined #minetest-dev |
16:22 |
eugd |
how do i do that? |
16:23 |
hmmmm |
git rebase -i 9ce30ab |
16:23 |
hmmmm |
squash, pick pick pick pick ..., rename the commit |
16:26 |
Krock |
pick, pick, pick, like a chicken |
16:28 |
rubenwardy |
isn't it pick squash squash squash squash? |
16:28 |
rubenwardy |
as pick keeps the commit |
16:28 |
rubenwardy |
and squash merges into parent |
16:28 |
hmmmm |
heh maybe it is |
16:28 |
rubenwardy |
protip: use 's' instead of 'squash' |
16:28 |
hmmmm |
i haven't found myself needing to squash commits very often |
16:29 |
hmmmm |
if you do mix them up git would tell you about it though |
16:48 |
|
proller joined #minetest-dev |
17:03 |
|
waressearcher2 left #minetest-dev |
17:04 |
|
Puma_rc joined #minetest-dev |
17:10 |
|
Gael-de-Sailly joined #minetest-dev |
17:12 |
|
nrzkt joined #minetest-dev |
17:21 |
|
Player_2 joined #minetest-dev |
17:46 |
kilbith |
chuis content, de plus en plus de monde remplace homedecor par xdecor :) |
17:47 |
kilbith |
fini les maisons de barbie haute définition |
17:47 |
kilbith |
et quasi toutes identiques |
17:48 |
Calinou |
je suis très content que tu parles français dans ce canal |
17:48 |
kilbith |
hein ? |
17:48 |
Calinou |
tu es sur le mauvais canal :) |
17:49 |
kilbith |
ah merde ! |
17:52 |
|
proller joined #minetest-dev |
17:53 |
|
eugd joined #minetest-dev |
18:01 |
|
proller joined #minetest-dev |
18:07 |
eugd |
how do sector coordinates work? |
18:07 |
eugd |
how do they align to block/node coords? |
18:08 |
T4im |
factor 16 |
18:08 |
T4im |
that is mapblock to node |
18:08 |
eugd |
yeah |
18:08 |
eugd |
but when handling sectors |
18:08 |
eugd |
which block or node is 'center'? |
18:10 |
eugd |
code is already enabled to tell in debug mode, just don't have machine to do it:( |
18:10 |
T4im |
not quite sure what you mean with sector, mapchunks? or mapblocks? |
18:10 |
hmmmm |
erm |
18:10 |
hmmmm |
0? |
18:10 |
hmmmm |
a sector is just a vertical column of mapblocks |
18:10 |
hmmmm |
block coordinate y = 0 would be the center |
18:14 |
eugd |
sectors are 80x80x80 but are referred to with single v2s16 |
18:15 |
|
lisacvuk joined #minetest-dev |
18:15 |
T4im |
80³ were mapchunks (=5³ mapblocks) |
18:15 |
T4im |
iirc |
18:16 |
eugd |
yes you're right |
18:16 |
eugd |
still 80x80 |
18:17 |
hmmmm |
map chunks are a mapgen abstraction only |
18:17 |
hmmmm |
there is no "MapChunk" structure |
18:17 |
sfan5 |
ooh |
18:17 |
eugd |
yes |
18:17 |
hmmmm |
it's adjustable via config as well by the way |
18:17 |
sfan5 |
so thats why i didn't quite get those |
18:17 |
hmmmm |
this seems to be a common misconception... |
18:17 |
eugd |
i though what i was asking was straightforward but now i'm confused, ha |
18:17 |
eugd |
i'm looking at ServerMap::createSector(v2s16 p2d) |
18:17 |
hmmmm |
there's nothing confusing about this |
18:18 |
hmmmm |
there are three containers in a heirarchy |
18:18 |
eugd |
yes sector/block/node |
18:18 |
eugd |
sector is vertical slice |
18:18 |
hmmmm |
a Map contains a 2d grid of MapSectors, which are vertical columns of MapBlocks |
18:18 |
hmmmm |
a MapBlock is a voxel area containing 16x16x16 MapNodes |
18:18 |
hmmmm |
a MapNode is the smallest unit |
18:19 |
eugd |
that v2s16 p2d, it is a node address, right? or do sectors start from 1, 2, 3, etc. in their own coordinate system? |
18:19 |
eugd |
i know the answer |
18:19 |
eugd |
ugh |
18:19 |
hmmmm |
be careful here |
18:19 |
hmmmm |
there are block coordinates and node coordinates |
18:19 |
eugd |
are there? |
18:19 |
hmmmm |
block coordinates are what's used to look up MapSectors or whatever |
18:20 |
eugd |
i thought there was only one coord system? |
18:20 |
hmmmm |
or address a mapblock inside of the map database |
18:21 |
hmmmm |
to get the block coordinates from a node coordinate, use getNodeBlockPos() |
18:21 |
eugd |
ah |
18:21 |
eugd |
i remember that now |
18:23 |
|
proller joined #minetest-dev |
18:25 |
hmmmm |
getSector, getBlock, getBlockNoCreateNoEx, emergeBlock, loadBlock, etc. anything that operates on a mapblock uses block coordinates |
18:25 |
eugd |
so there are not also sector coordinates |
18:26 |
hmmmm |
to make this clear, the parameters to these functions are usually "blockpos" or "bp" or something to denote this |
18:26 |
hmmmm |
there are no sector coordinates, no |
18:27 |
hmmmm |
a blockpos v3s16 of, say, (4, 1, -3) would translate to the v2s16 of (4, -3) for the sector position, and then y=1 for the block within that sector |
18:51 |
|
eugd joined #minetest-dev |
18:52 |
|
Krock2 joined #minetest-dev |
19:10 |
|
Amaz joined #minetest-dev |
19:19 |
|
cvtsx joined #minetest-dev |
19:22 |
|
asl97 joined #minetest-dev |
19:33 |
|
lisacvuk_ joined #minetest-dev |
19:40 |
|
MinetestForFun joined #minetest-dev |
19:54 |
|
DFeniks joined #minetest-dev |
20:10 |
eugd |
i've been looking all over code and can't find where sector size is defined |
20:12 |
T4im |
hmmm defined it earlier as a vertical column of mapblocks, which means x and z are 16 each, and "y" probably spans the entire map |
20:14 |
eugd |
i mean where in the code the 80x80 node, or rather 5x5 block size of each sector is defined (and more importantly, implemented for mapgen purposes) |
20:14 |
eugd |
nvm just found it probably lol |
20:15 |
T4im |
you have a minetest.conf option "chunksize" |
20:15 |
T4im |
with default=5 |
20:15 |
eugd |
ah |
20:15 |
eugd |
thanks |
20:15 |
asl97 |
eugd: https://github.com/minetest/minetest/blob/master/src/constants.h#L78 |
20:15 |
asl97 |
oh, sector |
20:15 |
T4im |
and that's for the mapblock size ^^ |
20:15 |
eugd |
it's actually user configurable? |
20:15 |
T4im |
chunksize, yes |
20:16 |
eugd |
'chunk' vs 'sector' being chunks are the cubes used for mapgen, right? |
20:16 |
T4im |
https://github.com/minetest/minetest/blob/master/minetest.conf.example#L691 |
20:16 |
eugd |
and i guess sector just inherits its size from the chunksize setting? |
20:17 |
T4im |
no, if I understood hmm earlier correctly, then from the mapblock size, that asl97 linked |
20:17 |
T4im |
due to it being a column of mapblocks |
20:17 |
T4im |
:P |
20:18 |
eugd |
oh, wait, waht |
20:18 |
eugd |
you're probably right |
20:18 |
eugd |
dunno where this mental block came from, damn |
20:22 |
eugd |
well found an error |
20:22 |
eugd |
chunksize not really definable |
20:22 |
eugd |
or it is and it works fine but generates a constant stream of errors |
20:22 |
eugd |
'chunksize not divisible by sidelen, setting sidelen to 16' |
20:24 |
T4im |
where did you set it? |
20:24 |
T4im |
in the config? O_o |
20:24 |
eugd |
yeah it disappeared after close and restart |
20:25 |
T4im |
maybe the unit is documented wrong.. if it expects the chunksize in nodes, it would have to be a multiple of 16 |
20:25 |
T4im |
though the documentation implies it to be in blocks |
20:25 |
T4im |
defines it to be* |
20:26 |
T4im |
close and restart might have actually set chunksize to 16 then ;) |
20:26 |
asl97 |
https://github.com/minetest/minetest/blob/f062bbd7a182233f96c61287d0397534811627d9/doc/lua_api.txt#L3385 |
20:26 |
asl97 |
it might have been cause of a mod or something |
20:27 |
T4im |
hm.. yea, but that would then appear in a lua stacktrace, wouldn't it? |
20:27 |
eugd |
it's coming from mg_decoration |
20:27 |
T4im |
well then.. :D |
20:28 |
eugd |
note i'm also using map_generation_limit simultaneously |
20:28 |
eugd |
probably something to do with it |
20:28 |
eugd |
have it set up to only generate a single block |
20:28 |
asl97 |
T4im: why should it error when the doc already said it would just set it to the same as chunksize? |
20:29 |
T4im |
because there's no warning log level to report on it? ;) |
20:29 |
eugd |
it's strange also that it's not constantly doing it even at the defualt 5 |
20:30 |
eugd |
5 is also not evenly divisible by 8 |
20:34 |
eugd |
gtg |
20:53 |
|
lisacvuk_ joined #minetest-dev |
21:01 |
hmmmm |
eugd, if you want to limit the map to a single 16x16x16 block, you need to set chunksize = 1 as well in the config |
21:01 |
hmmmm |
except that's not going to work either because it's expected that there's at least room for the map chunk borders |
21:46 |
|
proller joined #minetest-dev |
21:51 |
|
paramat joined #minetest-dev |
21:53 |
VanessaE |
so, what's the story with #3166 ? |
21:53 |
ShadowBot |
https://github.com/minetest/minetest/issues/3166 -- Send to clients only changed node metadata instad of whole mapblock by RealBadAngel |
21:53 |
|
Gael-de-Sailly joined #minetest-dev |
21:56 |
paramat |
eugd hmmmm that error is my fault, i am using a sidelen of 80 for some decorations. i found this necessary because decoration code fails at very low densities (acacia tree, cacti), the larger sidelen helped. however it is better to alter the decoration code, i'll work on this |
21:58 |
paramat |
i haven't seen RBA around for a while |
22:25 |
|
samuellwn_ joined #minetest-dev |
22:29 |
paramat |
problem is .. to work with all chunksizes (without printing an error) sidelen cannot be larger than 16. at low density deco_count can only be 0 or 1 per 16x16 node area which looks bad |
22:30 |
paramat |
so i will continue to use sidelen = 80. for low densities the code does the right thing setting sidelen = carea_size, maybe the error should not be printed as it's not really an error |
22:32 |
|
Kray joined #minetest-dev |
22:39 |
paramat |
.. yes, i'll open a PR |
23:05 |
|
Siva joined #minetest-dev |
23:06 |
|
Siva_Machina joined #minetest-dev |
23:45 |
paramat |
#3203 |
23:45 |
ShadowBot |
https://github.com/minetest/minetest/issues/3203 -- Decorations: Remove error message 'chunksize not divisable by sidelen' by paramat |