Minetest logo

IRC log for #minetest-dev, 2015-10-13

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:29 zat joined #minetest-dev
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
01:18 paramat left #minetest-dev
02:22 Player_2 joined #minetest-dev
02:53 Zeno` joined #minetest-dev
03:44 swaaws joined #minetest-dev
04:32 paramat joined #minetest-dev
04:36 book` joined #minetest-dev
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:42 Icedream joined #minetest-dev
04:47 paramat oh i made a mistake, nevermind
05:14 OldCoder joined #minetest-dev
05:37 paramat seems to work now =}
05:53 Hunterz joined #minetest-dev
06:21 sebastia joined #minetest-dev
06:26 Ardonel joined #minetest-dev
06:28 kaeza joined #minetest-dev
06:28 paramat left #minetest-dev
07:19 Travis__ joined #minetest-dev
07:30 Travis__ left #minetest-dev
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
08:00 VanessaE_ joined #minetest-dev
08:29 nrzkt joined #minetest-dev
08:29 H-H-H joined #minetest-dev
08:36 Ardonel joined #minetest-dev
08:49 Icedream joined #minetest-dev
08:55 julienrat joined #minetest-dev
09:02 VanessaE_ joined #minetest-dev
09:16 jin_xi joined #minetest-dev
09:19 VanessaE_ joined #minetest-dev
09:33 Calinou joined #minetest-dev
09:41 VanessaE_ joined #minetest-dev
09:45 VanessaE joined #minetest-dev
10:34 julienrat joined #minetest-dev
10:41 proller joined #minetest-dev
10:59 nrzkt joined #minetest-dev
11:11 rubenwardy joined #minetest-dev
12:05 proller joined #minetest-dev
12:10 Puma_rc_ joined #minetest-dev
12:16 Darcidride joined #minetest-dev
13:14 nyje joined #minetest-dev
13:19 swaaws joined #minetest-dev
13:21 sebastia joined #minetest-dev
13:21 swaaws joined #minetest-dev
13:22 sebastia joined #minetest-dev
14:01 zat joined #minetest-dev
14:20 DFeniks joined #minetest-dev
14:30 CraigyDavi joined #minetest-dev
14:48 Puma_rc joined #minetest-dev
14:54 hmmmm joined #minetest-dev
15:07 younishd joined #minetest-dev
15:56 proller joined #minetest-dev
16:00 proller joined #minetest-dev
16:35 younishd joined #minetest-dev
16:38 VargaD joined #minetest-dev
16:43 FR^2 joined #minetest-dev
16:48 rubenwardy joined #minetest-dev
16:56 Darcidride joined #minetest-dev
17:02 Robert_Zenz joined #minetest-dev
17:05 VargaD joined #minetest-dev
17:19 Robert_Zenz joined #minetest-dev
17:33 troller joined #minetest-dev
17:36 nrzkt joined #minetest-dev
18:27 est31 joined #minetest-dev
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/commi​t/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/commi​t/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/minet​est-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/coreboo​t/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
19:14 jin_xi joined #minetest-dev
19:21 shadowzone joined #minetest-dev
19:57 damiel joined #minetest-dev
20:06 rubenwardy joined #minetest-dev
20:28 nyje joined #minetest-dev
20:49 alket joined #minetest-dev
21:14 eugd joined #minetest-dev
21:22 Amaz joined #minetest-dev
21:52 eugd https://github.com/minetest/minetest/pull/3199
21:52 paramat joined #minetest-dev
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 proller joined #minetest-dev
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:19 eugd joined #minetest-dev
23:33 paramat left #minetest-dev
23:47 zat joined #minetest-dev
23:48 zat joined #minetest-dev
23:49 zat joined #minetest-dev
23:51 zat joined #minetest-dev
23:52 hmmmm blah
23:52 hmmmm back
23:52 zat joined #minetest-dev
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...
23:54 zat joined #minetest-dev
23:55 zat joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext