Time  Nick      Message
00:36 VanessaE_ ok, just making sure.
00:36 VanessaE_ btw, that is some EPIC terrain :)
00:36 paramat   good. nice mapper page you have
00:37 VanessaE_ thanks.  est31's handiwork :)
00:37 paramat   i'm thinking of adding a thin layer of gravel under seabed sand, to make it more available, thoughts?
00:38 VanessaE_ mmm...
00:38 paramat   since there are 2 layers of material usable and i'm only using 1
00:38 paramat   i'm not sure either
00:38 VanessaE_ how about right under the grass in those dirt_with_grass + sandstone biomes
00:39 VanessaE_ with seabed sand, I'd honestly expect a clay layer, but you already have blobs of the stuff spawning
00:39 paramat   yeah
00:39 VanessaE_ now that said,
00:40 VanessaE_ some days ago, I added HDX support for someone's biomes mod, and a couple of the nodes there were sandy dirt, and silt.  useful?
00:40 paramat   for gravel on land we would need an extra layer usable in code, the 2 layers are used up with grass on dirt
00:41 VanessaE_ oh ok, so skip that then.  didn't think about the just-dirt layer
00:41 paramat   best not add new nodes i think
00:41 paramat   well the gravel blobs are more common now underground so that's enough i think
00:42 VanessaE_ well I wouldn't be afraid of a few nodes added for the sake of better biomes, but I see your point.
00:43 paramat   sure, we can consider new nodes but they have to be really needed
00:43 VanessaE_ agreed.
00:56 paramat   what i meant was, sandy dirt and silt are similar to what we already have and i don't see a need for them in the seabed
00:56 VanessaE_ fair enough
00:57 VanessaE_ it's just, you ....well you know what?
00:57 VanessaE_ every time I've played a survival map, there's just never been enough clay.
00:57 VanessaE_ why not go ahead and spawn more of it under those sandy seabeds then
00:58 VanessaE_ (I'm thinking in terms of how useful the material is; gravel doesn't have much use except perhaps for pathways)
01:03 paramat   ah clay was a bit broken, the blob ore creation was broken and created really small blobs, they were too rare too. that's now been fixed
01:03 paramat   fixed in 0.4.13dev
01:04 VanessaE_ yeah, what I saw on that map was more reasonable :)
01:05 VanessaE_ but anyway that's the only thing I could expect to find under a sandy seabed.
01:07 paramat   yes i think i'll leave it as-is. the dirt/gravel/sand blobs underground are also fixed, larger and more common
01:07 VanessaE_ *nod*
01:08 VanessaE_ now, something that came up while searching - if you had an extra layer to use, putting *cobble* between the dirt/grass/snow and stone in biomes where those combos exist, would be a good idea
01:09 VanessaE_ (and desert cobble in deserts, of course.  Not sure what you'd use in those grass-over-sandstone biomes)
01:14 paramat   yes a nice transition using a broken form of the stone
04:36 paramat   attempting something, can anyone help? #3248
04:36 ShadowBot paramat: Error: Delimiter not found in "An error has occurred and has been logged. Please contact this bot's administrator for more information."
04:37 paramat   https://github.com/minetest/minetest/pull/3248
04:38 paramat   "ABMs: Add bool for catch up behaviour" by paramat
04:47 paramat   oh i made a mistake, nevermind
05:37 paramat   seems to work now =}
07:42 hmmmm     new rule for contributing to minetest:
07:43 hmmmm     if you are submitting something that claims to be a fix, you MUST HAVE TESTED the code to verify that it works, and add in the PR a complete description on how to replicate the original bug
07:43 hmmmm     if you do not have this in your PR, it IS GROUNDS FOR REJECTION.
07:44 hmmmm     the point is that it needs to be reproducible for others to perform an effective review on the said PR
07:45 hmmmm     you know what, I take back what I said about minetest not having enough developers
07:45 hmmmm     we don't have enough /quality/ developers
07:46 hmmmm     I think it's time the pull requests get more selective.  we don't *owe it* to the world to submit their code changes
07:47 hmmmm     when I get a nice stretch of free time I want to implement a formal framework of requirements for code submission
07:47 hmmmm     others no doubt already have some ideas on how to improve PR quality.  please share them
07:48 hmmmm     this disorganized "holistic" approach we take right now is really disorganized, messy, overly subjective, and generally bad
18:29 est31     hmmmm, I have some ideas, like automated checking of git whitespace errors #3142
18:29 ShadowBot est31: Error: Delimiter not found in "An error has occurred and has been logged. Please contact this bot's administrator for more information."
18:30 est31     https://github.com/minetest/minetest/pull/3142
18:30 est31     "Let travis check for git format mistakes"
18:31 est31     but that's only about some smaller things
18:31 est31     generally, I wish:
18:31 est31     1. better commit messages
18:31 est31     recent bad example would be https://github.com/minetest/minetest/commit/3a4bcf35a14d0f4740fe1ce379d87ac2094cc5ba
18:31 est31     "Fractal mapgen: Fix mysterious bug "
18:32 est31     no reference at all what the bug is about
18:32 est31     and a bug that gets fixed is usually not mysterious anymore
18:32 est31     (I don't know the details though, perhaps it still is, so correct me if I'm wrong)
18:33 est31     It would be great if a commit message included at least a reference to the bug report, or explanations about the bug fixed, except its really trivial
18:34 est31     kahrl's commit https://github.com/minetest/minetest/commit/e0b57c1140554fccbf3e57a036cc4100887ab8f1
18:34 est31     would be a good example
18:37 est31     2. unless its really impossible, PRs should only be about one single change. I support what hmmmm said in SN's logging PR, about splitting it up.
18:37 est31     you can put similar commits into one PR, but there should be separate commits
18:39 est31     3. I like the rules with squashing PR commits if they are just fixing the commit of the PR, etc. this creates a clean history. It should be kept. Also the "rebase to merge" strategy we currently have.
18:41 est31     so a PR shouldn't have 15 commits where the first is about the actual change, and the remaining 14 are "Update server.cpp", "Fix what @kwolekr pointed out", "Remove trailing whitespace"
18:44 est31     4. We discuss about new rules. Its like hmmmm proclaims a new rule, at least thats my impression when I read http://irc.minetest.ru/minetest-dev/2015-10-13#i_4421633
18:45 est31     correct me if my impression is wrong hmmmm, and you want to discuss it first.
18:48 est31     A good example to study a very formalized contribution process is coreboot: https://github.com/coreboot/coreboot/commits/master
18:49 nrzkt     est31: agree with all points
18:49 hmmmm     [02:32 PM] <est31> and a bug that gets fixed is usually not mysterious anymore
18:49 hmmmm     hah that's exactly what I said
18:50 hmmmm     est31:  yeah I want to discuss it first
18:50 hmmmm     I want to discuss rules in general though
18:50 hmmmm     what rules should we have, what don't make sense, how to enforce them, etc.
18:51 hmmmm     what ones we already have that don't make sense*
18:51 hmmmm     i'll have to take a look at coreboot
21:52 eugd      https://github.com/minetest/minetest/pull/3199
21:53 eugd      anything else?
21:54 eugd      paramat anything else on https://github.com/minetest/minetest/pull/3199?
22:00 paramat   a bug fixed is no longer mysterious of course :) i wrote that because, in my mind at least, the bug was known as 'the mysterious bug'. the message was a bit sloppy though and needed more detail, i was half asleep and hyper about the fix
22:01 paramat   eugd nothing else, seems good to me
22:02 eugd      cool, can we talk about mapgen determinism?
22:02 eugd      i feel this needs to be a feature
22:03 eugd      eventually a delta engine with user-side generation is preferred, right?
22:08 paramat   not sure it's preferred
22:09 paramat   this was discussed a while ago, can't remember the opinions
22:10 eugd      well in any case deterministic generation is critical to a lot
22:11 paramat   do you mean only saving changes to world?
22:11 eugd      i mean mapgen reliably giving the same results
22:12 paramat   (that's what delta engine suggested to me)
22:12 paramat   mapgen is mostly deterministic due to pseudorandom
22:14 paramat   but order of chunk generation changes things due to mapgen overgeneration of caves, dungeons etc
22:14 eugd      yeah
22:14 eugd      so i put forward this should be fixed
22:22 paramat   it's not much of a problem, and only a few minor details are non-deterministic. i feel it's not worth breaking dungeon gen for. of course mgv6 can't be changed now. mgv5/v7 could have 3D noise large caves though
22:24 paramat   however mgv7 was meant to have pr large caves, and is near stable now
22:25 paramat   so only mgv5 and future mapgens can be flexible
22:25 eugd      what causes nondeterministic gen? just chunksize or is there more to it? chunk ordering, you said?
22:31 paramat   there may be a few 'randoms' instead of 'pseudorandoms'. order of chunk gen due to how players explore, problem is overgeneration is extremely useful in mapgen (essential in some cases)
22:32 paramat   changing chunksize you would expect different generation because it's so fundamental to everything
22:33 eugd      "overgeneration"?
22:33 eugd      why would order affect generation?
22:34 eugd      and what is value of chunksize as a user config? performance i would guess?
22:36 paramat   the per-node randomness of schematics is not pseudorandom (the randomness of leaves on trees)
22:37 paramat   chunksize is a parameter yes but it's usually it's best to leave it alone
22:37 paramat   (-it's)
22:38 eugd      'schematics' ~= 'decorations', dungeons, trees, etc.?
22:38 paramat   i've never used it
22:38 paramat   yeah all trees in mgv5/v7 are schematics
22:38 paramat   dungeons are not
22:39 paramat   mgv6 trees are deterministic
22:42 paramat   surely though the non-determinism of tree rotation, leaves, roots and branches is not a problem
22:44 paramat   the locations of decorations are deterministic it seems
22:47 paramat   mgv6 relies on a chunksize of 5+. 5 is probably close to optimum. i only know of one modder who needs to use an alternative chunksize
22:48 paramat   i've written a lot of mapgens and never needed to change it
22:53 paramat   mgv6 type trees grown from saplings are non-deterministic
22:54 eugd      who was the modder who needed it changed, and why?
23:02 paramat   https://github.com/minetest/minetest/issues/3222
23:05 paramat   i suspect chunk gen order doesn't change large caves much, so it seems the only non-deterministic things are tree structure and the rare protruding dungeons
23:09 eugd      why would chunk order change anything? referencing system time?
23:14 paramat   overgeneration is a structure generating out beyond a mapchunk's border, whether the neighbouring mapchunk penetrated is generated or not might affect how that structure generates
23:52 hmmmm     blah
23:52 hmmmm     back
23:53 hmmmm     okay so I separated the core of SN's logging cleanup:  https://github.com/kwolekr/minetest/commits/sncleanup
23:53 hmmmm     errr https://github.com/kwolekr/minetest/commit/ed24a0e00f0971957c30a07be1d4b196421cafb6
23:53 hmmmm     now I just need to fix the commit message/author/etc..
23:54 hmmmm     not bad, only 25 changed files so far...