Time |
Nick |
Message |
00:34 |
eugd |
so, what changes should I be making to https://github.com/minetest/minetest/pull/3199 ? |
00:34 |
eugd |
restore default setting as a master control |
00:35 |
eugd |
and someone said something about giving positive and negative axis different values... not sure i see much point in that really |
00:35 |
eugd |
possibly even desirable to keep sectors 'centered' (as much as they are, which is not really at all) around zero |
00:37 |
est31 |
still wondering about the use case |
00:39 |
eugd |
hold on |
00:43 |
eugd |
as i said before i want to use it for future things especially adding a 'loop' option |
00:44 |
eugd |
whereby the world will seamless loop back on itself to give the illusion of a spherical world |
00:44 |
eugd |
http://i.imgur.com/NqXvAKy.png |
00:44 |
est31 |
also for y? |
00:44 |
eugd |
it would be possible |
00:45 |
eugd |
basically it just gives more control |
00:45 |
eugd |
just another option for users |
00:45 |
est31 |
options should be useful |
00:46 |
eugd |
it permits the creation of non-cubic worlds, is the essence |
00:46 |
eugd |
will be essential for looping but probably would have other uses |
00:46 |
est31 |
I know what the code does |
00:49 |
est31 |
btw does the patch respect the new setting as c55 asked? |
00:49 |
est31 |
err the old one |
00:49 |
est31 |
does it respect the old setting |
00:50 |
est31 |
e.g. you say limit_x = MYMIN(limit,limit_x) |
00:51 |
eugd |
not yet |
00:51 |
eugd |
i was asking for more input, if anything else was needed |
00:51 |
est31 |
that would be needed |
00:51 |
eugd |
yeah |
00:51 |
eugd |
makes sense |
00:52 |
eugd |
i think i may be making a mistake in my implementation, now |
00:52 |
eugd |
but i need to get it uploaded in like 5 min or it's gonna wait till tomorrow |
00:53 |
est31 |
no need for rushing it |
00:56 |
eugd |
yeah |
00:56 |
eugd |
it's not gonna happen |
00:56 |
eugd |
tonight anyway |
00:56 |
eugd |
not sure about my types here |
00:57 |
eugd |
before i was just multiplying what had existed |
00:57 |
|
eugd left #minetest-dev |
00:57 |
est31 |
they should be static |
00:57 |
est31 |
if they arent static, they are read each time |
00:57 |
est31 |
and reading settings is slow |
00:57 |
est31 |
therefore, its better to cache them |
02:06 |
|
x041 joined #minetest-dev |
02:36 |
|
eugd joined #minetest-dev |
02:38 |
eugd |
is there a way to change pull request or do i just have to close it and make a new one? |
02:39 |
asl97 |
define change |
02:41 |
eugd |
update? new/different commits. they're the same files but with different changes. |
02:42 |
asl97 |
as in how you want to change the pull request |
02:42 |
eugd |
oh, right |
02:43 |
eugd |
https://github.com/minetest/minetest/pull/3199 |
02:43 |
eugd |
i think i have it right to maintain the old setting |
02:43 |
eugd |
which was celeron55s request before adding it |
02:43 |
eugd |
can't actually build to test but it's pretty dead simple |
02:44 |
|
eugd joined #minetest-dev |
02:46 |
asl97 |
what do you mean by change pull request? |
02:47 |
asl97 |
add more commit? remove them? merge them? |
02:49 |
|
eugd joined #minetest-dev |
02:52 |
|
x041 joined #minetest-dev |
02:59 |
|
x041 joined #minetest-dev |
03:02 |
|
rubenwardy joined #minetest-dev |
04:15 |
|
Player_2 joined #minetest-dev |
04:52 |
|
x041 joined #minetest-dev |
05:50 |
|
AnotherBrick joined #minetest-dev |
05:56 |
|
Hunterz joined #minetest-dev |
06:49 |
|
red1 joined #minetest-dev |
06:53 |
|
nrzkt joined #minetest-dev |
07:15 |
|
leat joined #minetest-dev |
07:17 |
|
Krock joined #minetest-dev |
07:39 |
|
nrzkt2 joined #minetest-dev |
08:50 |
|
Darcidride joined #minetest-dev |
08:58 |
|
julienrat joined #minetest-dev |
08:58 |
|
julienrat left #minetest-dev |
09:11 |
|
T4im joined #minetest-dev |
09:16 |
|
Megaf joined #minetest-dev |
09:23 |
|
ninnghazad joined #minetest-dev |
09:30 |
|
ElectronLibre joined #minetest-dev |
09:47 |
|
ElectronLibre_ joined #minetest-dev |
09:53 |
|
ElectronLibre_ joined #minetest-dev |
10:29 |
|
lisacvuk joined #minetest-dev |
10:48 |
|
T4im joined #minetest-dev |
10:52 |
|
Calinou joined #minetest-dev |
11:08 |
|
proller joined #minetest-dev |
11:31 |
|
H-H-H joined #minetest-dev |
11:40 |
|
kilbith joined #minetest-dev |
11:56 |
|
ElectronLibre joined #minetest-dev |
12:46 |
|
H-H-H joined #minetest-dev |
13:48 |
|
Hunterz joined #minetest-dev |
14:12 |
|
Krock joined #minetest-dev |
14:28 |
|
Amaz joined #minetest-dev |
14:39 |
|
hmmmm joined #minetest-dev |
14:46 |
|
proller joined #minetest-dev |
15:06 |
|
proller joined #minetest-dev |
15:07 |
|
proller joined #minetest-dev |
15:17 |
|
rubenwardy joined #minetest-dev |
15:23 |
|
twoelk joined #minetest-dev |
15:30 |
|
ElectronLibre joined #minetest-dev |
15:41 |
hmmmm |
celeron55: are you around? I was wondering more about the EmergeThread, like for example why there needs to be an option to disallow generation |
15:44 |
celeron55 |
that's there so that the server can opportunistically send blocks from longer distances to clients if they happen to exist, but to save resources by not generating them too far |
15:45 |
celeron55 |
it's definitely a useful feature |
15:45 |
hmmmm |
all under the presumption that disk access is faster than generation though, no? |
15:46 |
celeron55 |
i don't think the database should need to access disk in order to check whether a mapblock exists |
15:47 |
hmmmm |
well that's a database dependent detail |
15:47 |
celeron55 |
maybe it does, i don't know |
15:47 |
celeron55 |
maybe you can't assume either way |
15:47 |
celeron55 |
hmmmm: anyway, currenetly if a block is generated, it will also be saved on disk |
15:47 |
hmmmm |
i was going to add a splay filter or skip list or some sort of interesting data structure for the purpose of knowing block existence before attempting a load |
15:47 |
celeron55 |
and it will bloat the database |
15:48 |
celeron55 |
if you make it so that they aren't necessarily saved if a player doesn't come very close to them, then i guess they could be generated |
15:49 |
hmmmm |
okay, fair enough |
15:49 |
hmmmm |
but how do you decide whether or not to allow generation? |
15:49 |
celeron55 |
even then with the heaviest lua generators the current behavior might be preferred |
15:49 |
celeron55 |
simply by how far the block is from a player |
15:50 |
hmmmm |
hrmm |
15:50 |
celeron55 |
max_block_send_distance, max_block_generate_distance |
15:50 |
celeron55 |
it's directly controlled by those |
15:50 |
celeron55 |
it's not complicated |
15:50 |
hmmmm |
should blocks that have been newly added to the environment be generated if not existing on disk? |
15:51 |
hmmmm |
it's complicated because this parameter is used differently in different places |
15:51 |
celeron55 |
what are "blocks that have been newly added to the environment"? |
15:51 |
hmmmm |
blocks that somehow got added, but are not yet activated |
15:52 |
hmmmm |
and are getting activated in the next env step |
15:52 |
celeron55 |
i guess they should be |
15:52 |
celeron55 |
altough it will open a new can of wormms with broken mods |
15:52 |
celeron55 |
worms* |
15:52 |
hmmmm |
what do you mean |
15:53 |
celeron55 |
is it possible to set any entity to activate blocks around itself? |
15:53 |
celeron55 |
or was that even added back then, i have never used it... |
15:55 |
celeron55 |
actually i don't think it was |
15:55 |
twoelk |
like technik-anchor maybe? |
15:55 |
celeron55 |
in that case it means that the only situation where what you just referred to can happen is where the server just hadn't been able to keep up with player positions |
15:55 |
celeron55 |
or the server is weirdly configured |
15:56 |
celeron55 |
and eventually the blocks that are being activated will be generated; the server just hasn't gotten to it yet |
15:56 |
celeron55 |
unless the active block range is larger than max_block_generate_distance which is really kind of an invalid configuration but it isn't checked |
15:57 |
celeron55 |
hmmmm: so, i mean, i think you'll end up in a fine enough design for it if you just think yourself |
15:58 |
hmmmm |
to be honest I have no idea |
15:58 |
hmmmm |
I just want to make sure things aren't totally broken when I get done with it |
15:59 |
celeron55 |
i'm not sure if anything will actually break if active blocks aren't necessarily generated ones |
16:00 |
celeron55 |
we might or might not want to allow code to make that assumption, i'm not sure |
16:02 |
celeron55 |
the problem with implementing that is that you need a new queue of blocks that would have to be active, but aren't because they aren't generated yet, and then the server has to generate them and after that it can actually activate them (and the server doesn't even really know when a block is actually fully generated because some things generate after the actual generation has happened) |
16:12 |
|
Soni joined #minetest-dev |
16:22 |
|
Puma_rc_ joined #minetest-dev |
16:24 |
|
proller joined #minetest-dev |
16:46 |
|
Robert_Zenz joined #minetest-dev |
16:48 |
|
lisacvuk joined #minetest-dev |
16:53 |
|
proller joined #minetest-dev |
16:53 |
|
nrzkt joined #minetest-dev |
17:06 |
|
samuellwn joined #minetest-dev |
17:13 |
|
eugd joined #minetest-dev |
17:17 |
eugd |
would appreciate some feedback on https://github.com/minetest/minetest/pull/3199 |
17:18 |
eugd |
re: packaging into v3u16 (or v3s16? i don't think that's right though), and making the required new getter function for settings |
17:18 |
Krock |
just... where's this going to be used? |
17:20 |
T4im |
by any subgame concepts, that might require smaller maps? |
17:20 |
Krock |
can be done with a square map |
17:21 |
eugd |
use is for something else down the line |
17:21 |
eugd |
multiple other things |
17:21 |
T4im |
Krock: perhaps, perhaps not.. |
17:21 |
eugd |
most immediately looping world |
17:22 |
T4im |
from the top of my head: simulate a big tree for players to live in, you would want more y-map than x/z/ there |
17:23 |
eugd |
that's the big issue exactly |
17:23 |
Krock |
https://github.com/minetest/minetest/pull/3199/files#diff-d9fcb7408652f56a0f66984c0d13d278R643 is there a * BS missing? |
17:23 |
T4im |
make it a halo/ring around a planet, and you have high x, small y/z |
17:23 |
Krock |
oh no nvm |
17:23 |
eugd |
where krock? |
17:23 |
eugd |
the first one? |
17:24 |
eugd |
i want to do small worlds but will with appreciable interiors |
17:25 |
Krock |
No, it's good. Haven't looked exactly |
17:25 |
eugd |
v3u16 is correct, right? not v3s16 as suggested on that page? |
17:25 |
T4im |
you will eventually have to squash those commits though :) |
17:25 |
eugd |
'squash'? |
17:25 |
T4im |
and give them a better commit message |
17:25 |
Krock |
imagine negative lengths |
17:25 |
Krock |
so, use u16 ;) |
17:26 |
eugd |
yeah it doesn't make sense as i said there |
17:26 |
eugd |
the code uses absolute values anyway, checks both - and positive |
17:27 |
T4im |
squashing means to combine commits that add or change the same thing |
17:27 |
eugd |
s16 can also store value "31000" and lower |
17:27 |
eugd |
right? |
17:27 |
eugd |
T4im how do i do that? that's what I wanted to do to start with |
17:27 |
Krock |
using _x, _y and _z instead of v3u16 might be confusing because it's actually the width, height and depth |
17:28 |
T4im |
eugd: may I assume, based on the commit messages, that you have been editing the files through the github web interface? |
17:28 |
eugd |
yes |
17:28 |
eugd |
ha |
17:28 |
eugd |
switching back and forth between linux and windows pcs |
17:28 |
Krock |
T4im knows the shocking truth behind the commit |
17:28 |
eugd |
also i know nothing about git anyway |
17:29 |
Krock |
Git GUI software ftw |
17:29 |
T4im |
https://try.github.io |
17:29 |
T4im |
there are also plenty of free ebooks and websites offering tutorials ;) |
17:30 |
Krock |
Youtube. |
17:30 |
T4im |
probably too, yes :D |
17:31 |
eugd |
should i use v3u16 (and make a new 'getter' function in settings.h/settings.cpp) or just use v3s16? |
17:31 |
eugd |
as far as i can tell they will both work |
17:33 |
eugd |
well gtg |
17:33 |
eugd |
please comment on the git page |
17:35 |
|
nrzkt joined #minetest-dev |
17:40 |
|
ElectronLibre_ joined #minetest-dev |
17:44 |
|
lisacvuk joined #minetest-dev |
17:56 |
hmmmm |
eugd: use v3s16 |
17:58 |
Krock |
<eugd>please comment on the git page |
18:06 |
|
paramat joined #minetest-dev |
18:08 |
paramat |
hi proller did you ever get this bug in fractal mapgen? https://github.com/minetest/minetest/pull/3088#issuecomment-134002097 any idea what causes it? |
18:11 |
|
twoelk|2 joined #minetest-dev |
18:12 |
|
DFeniks joined #minetest-dev |
18:33 |
|
asl97 joined #minetest-dev |
18:42 |
|
OldCoder joined #minetest-dev |
18:45 |
|
Amaz joined #minetest-dev |
18:50 |
|
H-H-H joined #minetest-dev |
19:01 |
|
paramat left #minetest-dev |
19:19 |
|
asl97 joined #minetest-dev |
19:20 |
|
red1 joined #minetest-dev |
19:23 |
red1 |
is a mapchunk called a sector in the code? |
19:24 |
Krock |
line? |
19:25 |
red1 |
? |
19:27 |
Krock |
nvm. No, it's something different because there are functions like: Map::getSectorNoGenerate(v2s16 p) |
19:27 |
Krock |
and mapchunks require a 3d position |
19:28 |
Krock |
Sorry, can't tell you more - hopefully it's documented somewhere |
19:28 |
Krock |
^ red1 |
19:30 |
red1 |
There used to be a page about how mapblocks are organized in sectors, but i can't find it |
19:30 |
red1 |
*on the dev wiki |
19:31 |
red1 |
nvm |
19:31 |
red1 |
found it |
19:32 |
red1 |
what is m_sectors used for? |
19:32 |
red1 |
I though it was for loading sectors form the map database |
19:33 |
asl97 |
red1: did you mean this page when you said `found it`? > http://dev.minetest.net/Core_Architecture |
19:33 |
red1 |
but there is m_sectors_cache |
19:33 |
red1 |
asl97 |
19:33 |
red1 |
yes |
19:39 |
|
Amaz joined #minetest-dev |
19:46 |
|
proller joined #minetest-dev |
19:46 |
|
MinetestForFun joined #minetest-dev |
20:19 |
|
VargaD joined #minetest-dev |
20:36 |
|
asl joined #minetest-dev |
20:53 |
|
ElectronLibre_ left #minetest-dev |
20:56 |
waressearcher2 |
does minetest's code use some thing deemed unspecified or undefined by the C++ standard ? |
20:58 |
sfan5 |
what kind of question is that? |
21:02 |
waressearcher2 |
that is from chapter "6.1 The ISO C++ Standard" from C++ book: "It is worth spending considerable time and effort to ensure that a program does not use some thing deemed unspecified or undefined by the standard. In many cases, tools exist to help do this." |
21:03 |
waressearcher2 |
for example "unsigned char c1 = 64; is well defined: a char has at least 8 bits and can always hold 64" but "unsigned char c2 = 1256; is implementation-defined: truncation if a char has only 8 bits" |
21:04 |
waressearcher2 |
"const int size = 4*1024; char page[size]; void f() { page[size+size] = 7; // undefined }", "Plausible outcomes of this code fragment include overwriting unrelated data and triggering a hard ware error/exception. An implementation is not required to choose among plausible outcomes. Where powerful optimizers are used, the actual effects of |
21:04 |
waressearcher2 |
undefined behavior can become quite unpredictable. If a set of plausible and easily implementable alternatives exist, a feature is deemed unspecified or implementation-defined rather than undefined." |
21:07 |
|
est31 joined #minetest-dev |
21:17 |
rubenwardy |
waressearcher2, we aim not to do that, however: |
21:18 |
rubenwardy |
it may have been missed when reviewing code additions |
21:18 |
rubenwardy |
following standards is essential to cross platform programs |
22:11 |
|
asl97 joined #minetest-dev |
22:54 |
|
Siva_Machina joined #minetest-dev |
23:45 |
|
samuellwn joined #minetest-dev |
23:50 |
|
Sokomine joined #minetest-dev |
23:53 |
|
turtleman_ joined #minetest-dev |
23:54 |
turtleman_ |
hi, dont know if here is the place to ask. is there a plan to rename "regular" trees to something more interesting? |
23:54 |
turtleman_ |
i find it weird now that jungle, pine, and acacia trees are common. |
23:55 |
|
Siva joined #minetest-dev |
23:57 |
|
samuellwn joined #minetest-dev |
23:59 |
|
VanessaE joined #minetest-dev |