Minetest logo

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

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

All times shown according to UTC.

Time Nick Message
01:38 twoelk|2 joined #minetest-dev
02:07 RealBadAngel joined #minetest-dev
02:44 Hunterz joined #minetest-dev
03:04 kaeza joined #minetest-dev
03:06 blaise joined #minetest-dev
04:18 cornernote_ joined #minetest-dev
04:19 paramat joined #minetest-dev
04:21 paramat argh! est31 is too obsessed with getting a release out on a fixed date at all costs
04:23 kaeza well, we complained time and time again that the "it's done when it's done" release model of Minetest leaves players hanging
04:23 paramat 0.4.13 stable mtgame has been forced through with errors, my mushroom drops have been changed to a stupid system, and the essential renaming of pine tree nodes has not yet been merged. all with no discussion with me or any mtgame devs
04:24 paramat mtgame 0.4.13 stable will have to be re-released
04:24 paramat i will fix the mushrrom drops, est and vanessa misunderstood how it works
04:26 paramat yeah i don't mind minetest 0.4.13 being released, luckily i had nothing essential to go in
04:27 paramat i made a mistake with the names of pine tree nodes, these needed fixing before mtgame release, my PR is ready to go i will push it very soon
04:31 paramat mushroom drops: digging a mushroom should always drop a mushroom (obviously), plus a variable number of spores from 0 to 3, with an average just above 1 spore, this allows a slow multiplication of mushrooms when farming, just like trees and saplings
04:32 VanessaE paramat: didn't you see the part where the player can re-placed/re-dig the mushroom to get more spores?
04:33 paramat ah i see, dig, place, dig, place?
04:33 VanessaE yeah
04:34 VanessaE the only way to solve that is either a bunch of extra on-place code, or limiting drops to 1 item(stack)
04:34 paramat oh sorry okay this needs fixing
04:34 paramat um a mushroom item is dropped that can't be placed?
04:35 VanessaE no
04:35 VanessaE at least it doesn't work that way in dan's/my mushrooms mod
04:35 VanessaE if you do that, players can't place them decoratively.
04:36 paramat despite my misunderstanding, est31 still rushed a release with no consultation with devs or myself, charlie brown says 'oh good grief!'
04:37 paramat okay this needs work then, what was commited was not good enough
04:37 VanessaE I still say the junglewood textures need to go in too
04:37 paramat yes sure
04:38 paramat another couple of days and we re-release mtgame 0.4.13
04:38 paramat when i see another mtgame dev i'll ask for the 0.4.13 tag and release to be reverted
04:39 paramat mtgame release is not usually on the same day
04:40 paramat the day for release is 'the right time' not a fixed arbitary date, otherwise we have broken releases
04:44 paramat don't worry about aliases not being transative, pine nodes have only ever been in 0.4.12dev so they can be renamed freely, we don't really need the aliases at all, those were just to be extra nice to players =)
04:44 VanessaE we need aliases :)
04:45 VanessaE my Basic world tons of such nodes in use
04:46 paramat sure, i mean for pine nodes
04:47 paramat anyway i support a continued feature freeze, we need it, i was hoping for a really long freeze this time
05:09 paramat okay lets have 2 types of mushroom, only the type grown by abm will drop spores, the picked one is sporeless
05:10 VanessaE use meta for that.
05:10 VanessaE like placed leaves
05:10 VanessaE if placed:  dig gets no drops
05:10 paramat meh don't like metadata
05:10 VanessaE on the other hand, wild grass and jungle grass work the way est set for the mushrooms
05:11 VanessaE you can place-dig-... over and over until you've converted the grass into seeds
05:11 VanessaE (and you have no grass then)
05:11 paramat sure but that only gives seeds for another crop, so is less cheaty =)
05:12 VanessaE well that was the idea I was suggesting for mushrooms too
05:12 VanessaE guess it didn't end up so.
05:13 paramat hmmmm, please can you revert the release of mtgame 0.4.13? so that players don't start filling longterm worlds with the wrongly named pine nodes
05:14 paramat we need a couple more days to fix important stuff
05:14 hmmmm well i don't think we came to a complete consensus on it but I think we're moving to a model where even version numbers are bugfix releases and odd versions are feature releases
05:14 hmmmm so it's like a tick-tock model of development
05:15 paramat meh players will see mtgame 0.4.13 and think 'stable!'
05:15 hmmmm so i don't necessarily think that calling what we have right now "0.4.13" is that bad, so long as throughout this -dev cycle we focus on improvements and bugfixes only
05:15 hmmmm we need to retrain them perhaps
05:15 hmmmm fwiw nerzhul was against this, vanessae and est liked it
05:16 hmmmm if you don't like it i'll count you as a nay
05:16 paramat it was forced through without discussion and with 2 big problems, that's reason enough to revert the release
05:16 VanessaE I favor any versioning scheme that doesn't confuse people :)
05:16 hmmmm vanessae what do you think
05:16 hmmmm should it be reverted or not
05:16 VanessaE with all due respect to est, revert.
05:17 hmmmm est doesn't take very kindly to reverts FYI...
05:17 VanessaE or it might be cleaner to just rewrite history
05:17 paramat i will work full time now to get it ready, just 1-2 days
05:17 VanessaE (I know it's WAY beyond the usual time limit, but this is a special case)
05:17 hmmmm what do other people around think about it?  kaeza?  cornernote?  RBA?  kilbith?? sfan5 i saw around earlier
05:18 hmmmm btw what do you guys think about this https://github.com/minetest/minetest_game/com​mit/6a64ec4dac8c92b8435107fb6ab1bc6bb7ce1820
05:18 paramat i'm sure est will realise his/her mistake and accept the revert
05:18 hmmmm est is a guy
05:18 paramat okay
05:19 paramat est commited some texturs then removed them later?
05:19 paramat (textures)
05:19 VanessaE hmmmm: for that texture, see game#619
05:19 ShadowBot https://github.com/minetes​t/minetest_game/issues/619 -- Better jungle wood and jungle tree top textures by VanessaE
05:19 VanessaE paramat: yeah.
05:19 hmmmm did he?
05:19 VanessaE he thought he was breaking the no-features freeze rule.
05:19 hmmmm it seems like they're not part of history
05:19 hmmmm oh come on that obviously does not apply to minetest_game
05:20 VanessaE I assume he force-pushed them out
05:20 paramat that was without dev discussion too
05:20 hmmmm the whole point of the no-features rule is to ensure stability
05:20 VanessaE hmmmm: tell that to kilbith :)
05:20 hmmmm a texture change isn't harming stability
05:20 hmmmm i don't give a rats ass about textures as long as the grass is fixed to something that isn't that depressing shade of green, and gold stops looking like blocks of american cheese
05:21 VanessaE lol
05:21 hmmmm so it's up to what you guys think about the textures
05:21 paramat we're almost ready with the new textures, vanessa's latest tree top is good
05:21 kaeza that system could work
05:21 paramat i'm planning to change the grim grass
05:21 VanessaE I personally don't have a problem with the grass, but honestly the dirt just looks like noisy brown, to me.
05:21 paramat i can't stand it anymore
05:21 kaeza I'm more interested in better grass sounds
05:21 hmmmm kaeza, ?  you mean what I proposed with the feature release/improvement release?
05:21 kaeza ye
05:21 hmmmm so another yay for that
05:22 hmmmm yay: me, est, kaeza  |  nay: vanessae, paramat, nerzhul
05:22 VanessaE eh?
05:22 hmmmm er
05:22 VanessaE I'm on the "yea" side.
05:22 kaeza I think VE is a yay
05:22 hmmmm I thought you said whichever doesn't confuse people
05:22 VanessaE I did.
05:23 VanessaE I don't think your idea will confuse too much
05:23 hmmmm well okay
05:23 hmmmm should we make a forum vote maybe
05:23 VanessaE nah
05:23 paramat nah
05:23 hmmmm we're getting a very limited sample size you know
05:23 hmmmm so just to be clear:
05:24 hmmmm adopting the stable/feature release number scheme would mean NOT reverting the 0.4.13 version bump commits
05:24 hmmmm or would you rather still adopt it but rollback that change
05:24 VanessaE I'd say adopt and roll-back
05:24 VanessaE it's the cleanest way
05:24 VanessaE less'n someone here has a better idea
05:25 VanessaE we all seem to agree 0.4.13 should not have hit the shelves
05:25 hmmmm yeah
05:25 VanessaE but then again, it hasn't hit the website yet
05:25 hmmmm well
05:25 hmmmm the 0.4.13 bump commit serves as the HEAD for 0.4-stable
05:25 paramat i don't mind minetest 0.4.13 being released. but mtgame was forced through without discussion so the 0.4.13 tag/release needs removing
05:26 VanessaE yeah I know
05:26 hmmmm the engine needs some work before a release
05:26 hmmmm i'm working on the delete_area fixes, rollback fixes, and adding more information about the double error
05:26 hmmmm I think that at the very least if those things get fixed a release COULD be plausible
05:26 kaeza to be fair, bad node names are not exactly world-breaking bugs like other things that have been added (*looks at proller* [weather])
05:26 VanessaE so my proposal is to reset --hard to a953ff4d and carry on from there
05:27 hmmmm yeah but
05:27 hmmmm how many people have already checked out this version in git
05:27 VanessaE probably a few, BUT it's a non-functional change
05:27 hmmmm the problem with hard resetting is you screw everybody's repos
05:27 VanessaE other than a couple flags in CMakeLists anyway
05:27 hmmmm well
05:27 hmmmm it can't be more than a few
05:28 hmmmm kaeza, are you on board?  paramat?
05:28 VanessaE I know, but it's not impossible to force-pull or just re-clone if your repo goes wonky
05:28 paramat erm let me reread
05:28 hmmmm we're going to reset to HEAD^2
05:29 kaeza hmmmm, I have no problems with resets. also, a 1 day reset is not that of a big deal really
05:30 kaeza if it's even 1 day
05:30 hmmmm here we go then
05:30 paramat yeah rollback the 0.4.13 bump
05:30 VanessaE kaeza: exactly, and it's only been 8 hours anyway
05:31 VanessaE hmmmm: inb4 kilbith complains ;)
05:32 hmmmm ooh
05:32 hmmmm git push -f upstream master
05:32 hmmmm that -f.
05:32 hmmmm that does not happen often.
05:32 hmmmm it's done
05:33 kaeza inb4 -f means --fuck-up
05:33 hmmmm -f is the short flag for --fuck-upstream
05:33 VanessaE lol
05:34 paramat mtgame doesn't have a bump commit, just a tag and entry on the releases page
05:34 hmmmm for what it's worth, you guys can do anything you want to minetest_game
05:34 hmmmm just don't screw it up
05:34 hmmmm there's no special restrictions
05:35 paramat yeah i just don't know how to remove that release entry and tag =)
05:35 paramat anyway now to sort it out..
05:35 hmmmm here ya go
05:35 hmmmm https://www.google.com/sear​ch?q=git+delete+tag+remote
05:37 paramat thanks, this will need to be done before i push the next commit?
05:37 hmmmm i don't think so no
05:37 paramat okay will do so anyway
05:39 hmmmm https://github.com/kwolekr/minetest/commit​/18cfd89a86af550b3c4663def77a5fac46e895ae
05:39 hmmmm PTAL
05:39 paramat soon after that i will push the corrected pine node names, then vanessa's tree top and kilbith's dark planks, then will work on mushroom farming
05:40 hmmmm can you also add the light grass texture back
05:40 hmmmm that's really annoying but i learned to accept it
05:40 paramat and yes
05:40 paramat new grass
05:40 VanessaE light grass texture pack?
05:40 hmmmm every time i update minetest_game i need to fix it
05:40 VanessaE back*
05:40 VanessaE hmmmm: good idea regarding the mem usage
05:41 hmmmm yeah
05:41 hmmmm it's actually quite variable on my system
05:41 hmmmm sometimes it's 512MB
05:41 hmmmm others it's ~1980 MB
05:41 paramat i made a bright new grass recently based on the current one https://github.com/minetes​t/minetest_game/issues/560 what do you think?
05:41 hmmmm yeah I think that's an improvement
05:42 paramat it's colour, brightness and contrast matched to what came before
05:42 hmmmm RealBadAngel's comment is the real solution but the thing is that comes along with client-side biomes
05:42 VanessaE paramat: +1
05:42 hmmmm i.e. not a thing we can do right now
05:44 hmmmm paramat:  did you look at my commit?
05:44 * paramat looks
05:45 paramat useful feature
05:45 Hunterz joined #minetest-dev
05:46 hmmmm +1??
05:46 paramat yes
05:46 hmmmm ok :)
05:46 hmmmm push complete
05:48 VanessaE what's the disposition of game#581 ?
05:48 ShadowBot https://github.com/minetes​t/minetest_game/issues/581 -- New stairs and slabs discussion
05:49 paramat i'd like steelblock added
05:49 paramat we need at least one ption for modern stairs
05:49 hmmmm heh this reminds me of terasology's setup
05:49 paramat (option)
05:49 hmmmm each mapnode has a material and a block type
05:50 hmmmm can't help but think that ours is kind of inefficient and repetitive
05:50 VanessaE it is.
05:50 hmmmm well we're not going to fix that without splitting up param1
05:50 hmmmm err, i mean param0
05:50 hmmmm that's the tough part
05:50 VanessaE the only reason dreambuilder has over 16'000 nodes is because it's stair-this and slab-that and colored-this-other-thing
05:51 hmmmm i dunno, maybe
05:51 hmmmm the longer we go the more pressure there is to move to an 8-byte mapnode structure
05:51 hmmmm and, man, trust me I am not going to waste 3 of those bytes on something as pathetic as colored lighting
05:51 VanessaE 8 byte for alignment purposes?
05:51 hmmmm of course
05:51 hmmmm we don't really have much of a choice..
05:52 hmmmm if you increase the structure by 1 bit it's going to be now 8 bytes
05:52 VanessaE regarding colored lighting, seems to me you could just use *one* byte as an index into a color lookup table.
05:52 VanessaE (not unlike the idea you had for generic colorized nodes)
05:52 paramat i don't see coloured light as all that important, or needed
05:52 hmmmm not only that
05:52 hmmmm but if i were going to do colored lighting, i'd rather fix the minetest lighting algorithm first
05:53 VanessaE yes
05:53 VanessaE RBA will want to have a hand in that
05:53 hmmmm that's what's really needed rather than monkey patching individual color channels into the central data structure of the game
05:53 VanessaE still this is out of scope for now
05:53 hmmmm well i still need to come up with the lighting algorithm
05:53 hmmmm it's tough
05:53 hmmmm yeah all this is future talk
05:53 hmmmm but think about it, if we doubled the size of a mapnode, what things would you use it for
05:54 VanessaE well 4 bytes is a lot of space given the sort of constraints we're working with, so .. I dunno
05:55 VanessaE alternate nodes.
05:55 VanessaE that's the first thing that comes to mind.
05:55 VanessaE 1 bit stored somewhere that will switch in an entirely different node def for that spot
05:56 VanessaE (for the mesecons/furnaces/et al. use case)
05:56 hmmmm how do furnaces work right now again?
05:56 hmmmm i forget
05:56 VanessaE they swap in a new def manually.
05:56 VanessaE minetest.swap_node()
05:56 VanessaE which may as well be read-meta, minetest.set_node(), rewrite meta.
05:56 hmmmm ah
05:57 VanessaE mesecons is similar.
05:57 hmmmm yeah, we'll see what we can do
05:57 hmmmm I think that's already quite doable tbh, if param1 is stolen
05:57 VanessaE it is yes
05:57 hmmmm we just need somebody to work on it
05:57 hmmmm man this is depressing
05:58 hmmmm all the NetworkPacket handler routines lack PacketError exception handlers
05:58 OldCoder joined #minetest-dev
05:58 hmmmm you can crash any minetest client right now by sending a packet with an invalid length
05:59 hmmmm crash, as in stop it from running, but thankfully no remote code execution or arbitrary memory reads or anything bad like that
05:59 hmmmm you know, if the minetest gaming community had users that were just 5% smarter than they are right now there would be havoc
06:00 hmmmm thanks nerz
06:04 paramat left #minetest-dev
06:06 VanessaE hmmmm: come to think of it, what harm would there be in partially adopting terasology's model?
06:06 VanessaE regarding block types and materials
06:06 hmmmm nothing, i think it might be a decent idea
06:06 hmmmm but you'd also have a lot of irrelevant combinations for one-of node types
06:07 VanessaE for example?
06:07 hmmmm mesecons with the grass material?
06:07 hmmmm lol.
06:07 VanessaE haha
06:07 VanessaE right
06:08 VanessaE well I was thinking, one new byte for the material (index into a table that a mod can add to/change), one byte for the model/block type (if 0, refer to the node def's drawtype)
06:09 VanessaE block type could even indicate different tables for different drawtypes for that node
06:09 hmmmm ha..
06:09 hmmmm maybe...
06:09 hmmmm okay how about this setup
06:09 hmmmm MAX_CONTENT is still at 32k right?
06:10 VanessaE yeah
06:10 hmmmm we'll steal the top bit
06:10 hmmmm if the top bit is set, that means that param0 is a block type/material pair
06:10 hmmmm the low 8 bits of param0 will be the block type
06:10 hmmmm and then the top 7 bits will be the material
06:10 hmmmm yea?
06:10 VanessaE I like it.
06:10 hmmmm there you go, it's even reverse compatible
06:11 hmmmm will 128 materials be enough for you though?
06:11 VanessaE well worst-case in any mod I've ever written, only about 90 unique nodes for a given shape
06:11 VanessaE (unified dyes-related stuff)
06:12 hmmmm so which is needed more
06:12 hmmmm more materials or more shapes
06:12 VanessaE hm
06:12 VanessaE you know, I'm not really sure.
06:13 VanessaE if I were to use one node per hue in a unified dyes based mod, then a given node would only need one of 6 or 7 materials
06:14 hmmmm btw you realize this is a global number, not a per-mod number, right?
06:14 VanessaE the "worst offender" is probably the stained glass mod
06:14 VanessaE yeah, I'm just thinking out loud at the moment
06:15 VanessaE more shapes than materials, it seems to me
06:16 hmmmm okay
06:16 hmmmm i still think 7 bits is too small
06:16 VanessaE yeah
06:17 VanessaE damn
06:17 hmmmm what do you think about this
06:17 hmmmm https://github.com/kwolekr/minetest/commit​/1c408c4f1df25ecec0dd8ea8b6cb00534e08bc66
06:17 VanessaE I don't think you'll be able to cover everyone's use cases without adding another byte to the node.
06:17 hmmmm PTAL
06:18 VanessaE I'm curious about the change to line 88 but the rest seems reasonable to me
06:19 hmmmm that's there because i missed that instance when i changed the rest of them
06:19 VanessaE (of course, in no case will a u16 ever be more than 2 bytes, so it's probably moot anyway)
06:19 hmmmm sizeof(u16) isn't ever not going to be 2, but it's just for consistency with the rest of them
06:19 VanessaE right
06:19 hmmmm get into the habit of using the number literal for when you mean serialized byte lengths instead of in-memory-representations
06:21 VanessaE damn, you don't waste any time :P
06:24 VanessaE what about this:  steal that top bit, lower 10 bits for materials, upper 5 from there plus another 5 from another byte for shapes
06:24 nrzkt joined #minetest-dev
06:24 VanessaE use one of the leftover 3 bits for that special-nodedef idea
06:25 VanessaE that least 2 bits plus another three unassigned bytes
06:25 hmmmm yeah we can use param1
06:26 hmmmm param1 is only ever used for torchlike
06:26 VanessaE how are you gonna wrestle-away the lighting info from the engine?
06:26 hmmmm well I highly doubt a transparent node needs to have variable materials
06:27 hmmmm unless you want a grassy air node and a brick air node
06:27 VanessaE glass stairs
06:27 hmmmm hum
06:31 kahrl even stairs made of a solid material have paramtype = "light"
06:31 VanessaE right
06:31 VanessaE otherwise they'll be black.
06:32 hmmmm oops
06:32 kahrl anyway I did a quick valgrind run and it showed two problems
06:32 kahrl first, there is an uninitialized value in minimap.cpp:272
06:33 kahrl second, intlGUIEditBoxes are leaked
06:34 kahrl this should fix those issues: https://gist.github.com/kahrl/4c3f9d0f75572a93c079
06:35 hmmmm looks good to me
06:35 kahrl pushing.
06:39 hmmmm :)
06:40 kahrl gah, that typo in the commit message is going to haunt me forever :P
06:41 hmmmm 5 minute rule
06:41 hmmmm you can still amend that commit
06:41 kahrl alright. I didn't see it as important enough but I'll do it :)
06:45 paramat joined #minetest-dev
06:47 paramat actually i do have an essential engine PR to go in before 0.4.13 #3020 can anyone approve? will push when i rename pine nodes in mtgame
06:47 ShadowBot https://github.com/minetest/minetest/issues/3020 -- Treegen: Rename pine tree mapgen alias by paramat
06:48 hmmmm that i think is fine
06:48 hmmmm go ahead
06:48 paramat thanks
06:49 VanessaE paramat: wait a sec...
06:50 paramat yeah
06:50 VanessaE mmm.. nevermind
06:50 paramat lol
06:51 paramat will push 3020 and game#617 very soon
06:51 ShadowBot https://github.com/minetes​t/minetest_game/issues/617 -- Default: Rename pine tree nodes, textures and mapgen aliases by paramat
06:55 paramat since there's still much to do in mtgame i'd like roughly a week before releasing 0.4.13
06:55 VanessaE at least.
07:03 paramat left #minetest-dev
07:03 hmmmm no problem
07:04 VanessaE ok time for me to head to bed
07:04 VanessaE night
07:19 nrzkt i see a bump version but no git tag, is this normal ?
07:29 nore joined #minetest-dev
07:30 paramat joined #minetest-dev
07:34 paramat hi nore please can you remove the mtgame 0.4.13 tag and 0.4.13 release from the releases page? (see logs for why) i was going to do it myself but not confident i will do it right
07:36 nore hm... I don't know how to do it :/
07:36 paramat heh
07:37 nrzkt https://nathanhoad.net/how-​to-delete-a-remote-git-tag
07:37 nrzkt look at this
07:37 paramat i did =)
07:39 paramat not sure if that's to be done from my master branch or from a cloned repo
07:40 paramat anyway no rush everyone knows 0.4.13 has been reverted now
07:41 paramat left #minetest-dev
07:41 RealBadAngel joined #minetest-dev
07:54 Darcidride_ joined #minetest-dev
07:57 kahrl re-tagging will screw up everyone who already pulled the tag (a lot of people)
07:57 kahrl https://www.kernel.org/pub/software/sc​m/git/docs/git-tag.html#_on_re_tagging
07:59 kahrl I would just make a new tag called 0.4.13.1 or something like that
08:00 kahrl even if it's ugly, it's a lot less hassle
08:01 kahrl (I guess you can do that and also delete the 0.4.13 tag)
08:05 Yepoleb joined #minetest-dev
08:13 paramat joined #minetest-dev
08:14 paramat ah okay kahrl lets not retag then no problem
08:15 paramat now pushing game#617
08:15 ShadowBot https://github.com/minetes​t/minetest_game/issues/617 -- Default: Rename pine tree nodes, textures and mapgen aliases by paramat
08:23 paramat complete, 500 commits!
08:24 sfan5 would minetest_game be ready for a releave after this?
08:28 paramat nah still lots to do, perhaps in a week
08:28 paramat will push #3020 when checks are done
08:29 ShadowBot https://github.com/minetest/minetest/issues/3020 -- Treegen: Rename pine tree mapgen alias by paramat
08:29 paramat a week at most, maybe less
08:30 paramat read logs for details
08:32 rubenwardy joined #minetest-dev
08:33 Player_2 joined #minetest-dev
08:34 paramat hmmmm is fed up with the depressing grass texture, so is cele55 and myself, i think it will need to be changed to a brighter one, or at least something more lush, i will work on it
08:37 paramat .. and submit a dark improved one and a brighter one, maybe 3..
08:39 leat joined #minetest-dev
08:46 proller joined #minetest-dev
08:47 paramat now pushing 3020
08:48 SopaXorzTaker joined #minetest-dev
08:53 rubenwardy #3020
08:53 ShadowBot https://github.com/minetest/minetest/issues/3020 -- Treegen: Rename pine tree mapgen alias by paramat
08:54 paramat complete
08:54 paramat left #minetest-dev
09:06 Amaz joined #minetest-dev
09:07 SopaXorzTaker joined #minetest-dev
09:39 WSDguy2014 joined #minetest-dev
09:48 kilbith joined #minetest-dev
09:49 rubenwardyy joined #minetest-dev
09:51 SopaXorzTaker joined #minetest-dev
09:53 kilbith VanessaE: reverting the textures was not about my complaints
09:53 kilbith it was clearly a violation of the rules
09:54 kilbith textures, especially, have to subjected to the maintainers since they highly depend on tastes
09:55 kilbith also i agree with the devel model of hmmmm
10:01 CraigyDavi joined #minetest-dev
10:17 diemartin joined #minetest-dev
10:41 rubenwardy joined #minetest-dev
10:43 asl97 joined #minetest-dev
10:51 SopaXorzTaker joined #minetest-dev
10:52 Niebieski joined #minetest-dev
11:20 Calinou joined #minetest-dev
11:37 Ardonel joined #minetest-dev
11:37 est31 joined #minetest-dev
11:38 est31 seems a 0.4.13 release is highly not wanted
11:39 est31 so we're going the irrlicht route then, no release for years
11:39 Calinou seriously, don't let that happen.
11:39 Calinou "release early, release often" is still very true
11:42 est31 and about ordering nodedefs by criteria: I hate this
11:42 est31 the criteria just limit how generic we are
11:42 est31 its wasted space
11:43 est31 we can do something like it, but please as mod then
11:43 est31 and without wastery
11:44 est31 e.g. criteria_lib.register_node_wood_type(pine", "pine_wood_1.png")
11:44 est31 or so
11:45 est31 I'd like to hear technical arguments which speak for such a change
11:47 est31 if we dont release, people will think this project is dead
11:48 est31 seems the windows builds done by sfan and blockmen were in vain then
11:48 est31 well, no problem, they can be re-done
11:49 nrzkt maybe having a news field in the client could be good to show the project is not dead :p
11:49 nrzkt and i dont' think project is dead, look at commits
11:50 est31 irrlicht has commits too
11:50 Calinou news in the client is possible with the master server
11:50 kilbith joined #minetest-dev
11:50 est31 might be an idea
11:50 est31 well, its a feature, so future talk
11:50 kilbith some people are facing a new bug : https://forum.minetest.net/v​iewtopic.php?f=6&t=13001
11:51 est31 for the version after 0.4.14 or how its called
11:51 est31 heh, i guess its a deadlock thanks to one of those "race prevention" locks added
11:54 kilbith RealBadAngel: how goes the handmade relief mapping for the default textures you were heading to do ?
11:56 nrzkt est31: an added muted ?
11:56 nrzkt mutex* ?
11:56 est31 perhaps, just a wild guess
11:57 est31 to fix one of the race conditions added thanks to an "optimisation"
12:00 nrzkt some mutex were useless in the code
12:00 nrzkt as i said when they were merged...
12:00 nrzkt like one mutex on a getter function but no mutex in setter...
12:01 est31 they arent useless
12:01 est31 they are just creating bugs, like before already
12:01 est31 just different bugs
12:11 SopaXorzTaker joined #minetest-dev
12:12 est31 I have tried to do a sensible discussion about what to do before the release
12:13 est31 and we ended up with "fix every medium bug in the tracker"
12:13 nrzkt critical and very high okay, but medium can be differed
12:14 est31 even that's too much
12:14 est31 people are running around labeling every bug as critical
12:14 est31 critical bugs are ones which ruin the game for EVERYBODY
12:14 est31 not just for some person with an ATI card when they install this mod and play for 10 hours a piece.
12:16 nrzkt for me it's medium in that case
12:16 nrzkt but label are handled by coredevs, not users, no ?
12:16 est31 I have just tried to make a release with not more bugs as 0.4.12, and then give us time to do a bugfix release
12:18 est31 the delete_area suckery has existed since < 0.4.12
12:18 est31 no need to block everything for it
12:19 est31 ~topic
12:19 ShadowBot est31: Minetest core development and maintenance. Feature freeze IN EFFECT until 0.4.13 release, no commits on the master branch except bugfixes or trivial (small) cleanups. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/
12:19 est31 I've thought ive done something everybody wants
12:20 est31 hmmm wants to have eternal feature freeze, so let him have it
12:20 est31 others want a release, so let them have it
12:21 est31 everything would have bene fine
12:21 est31 been*
12:21 est31 what do we have now
12:22 nrzkt est31, have you taken holidays this summer ? :
12:22 nrzkt :)
12:22 est31 nrzkt, I'll quit doing stuff for minetest, perhaps, and let people fuck it as they wish
12:23 est31 no more changes, any day!
12:23 est31 no release for years!
12:25 kilbith this is not what hmmmm wants btw
12:25 kilbith he wants a linux release scheme
12:26 kilbith we can afford weekly-released software
12:26 deltib joined #minetest-dev
12:26 est31 he didnt say weekly released
12:27 est31 he and VanessaE just wanted to stop progress until every medium bug was fixed in the tracker
12:27 kilbith bumped versioning for minor patches and so on
12:27 Calinou to be honest, maybe we would be better off with rolling release.
12:27 Calinou that's what Red Eclipse does now
12:27 Calinou an updater is included in the game
12:28 Calinou (uses curl, no GUI front-end currently)
12:53 FR^2 joined #minetest-dev
12:55 leat joined #minetest-dev
13:01 kilbith yet again another crash : https://forum.minetest.net/v​iewtopic.php?f=6&amp;t=13010
13:03 est31 oh, even reproducible
13:09 FR^2 left #minetest-dev
13:11 * VanessaE looks at est31 and kilbith and grumbles.  loudly.
13:11 kilbith oh i love that
13:21 VanessaE est31: 0.4.13 release is not wanted *yet*..  I told you that it was a bad idea to push it through.
13:21 VanessaE the plan right now is to postpone it for a week or so
13:22 VanessaE kilbith: given the number of disparaging remarks you've levied at me in public lately despite every attempt on my part to help make this a project people actually WANT to use, frankly I'm not at all inclined to accept any further criticisms from you for now.
13:23 kilbith of course you get naturally frustrated because *your* PR was reverted, that's human
13:24 kilbith but there are rules, it's not for our pets
13:25 kilbith isn't that you that harassed RBA for reverting a texture that you don't liked btw ?
13:25 VanessaE wat
13:25 kilbith the handmade sand relief map
13:25 kilbith and a bunch of others
13:25 kilbith that was included in a PR
13:27 kilbith well, all that for demonstrating how poor-standards you have
13:28 VanessaE maybe you should talk to RealBadAngel then about that because I don't recall harassing him over such a thing
13:28 kilbith ok, i'll dig the logs
13:29 VanessaE if someone produces a texture or feature that's terrible, I will yell about it until they fix it or provide a way to disable it.
13:30 VanessaE in the case of those texture maps, it's absolutely critical that they be as good as possible if they're gonna be there as a default feature.
13:31 VanessaE and a blurry or rounded looking texture is not good.
13:31 VanessaE as far as I can remember that's the only complaint I had with those particular textures.
13:31 kilbith that was rather repetitive injections for reverting
13:31 VanessaE as for my PR I understand why it was reverted, however it was apparently NOT against the rules to put it in.
13:32 kilbith http://dev.minetest.net/minetest_game_Development
13:33 kilbith it's not because it comes from miss ezekowitz that the rules should be tilted for her
13:33 kilbith people had always to comply with the rules and won't change
13:34 kilbith at the time BlockMen reverted easily commit that haven't another +1, whatever if it was minor or not
13:35 kilbith the benevolent father of _game is gone, people are getting insolently commit-friendly
13:36 est31 yea, a benevolent father is good to have, less fighting, if things are aligned to one person's preferences
13:39 kilbith as for the VE's injonctions for revert things she subjectively don't like : http://irc.minetest.ru/minet​est-dev/2015-07-13#i_4321680
13:40 kilbith not even in a suggestive mean...
13:40 VanessaE yeah, just as I stated
13:40 VanessaE be was trying to push through blurry images.
13:40 kilbith it sounded like an order
13:40 kilbith no, it *was* an order
13:40 VanessaE well it wasn't.  in normal english parlance, "you have got to X" used in this context means "this is terrible, PLEASE undo it"
13:41 kilbith err, look around for the other input containing "revert"
13:41 kilbith that's literally an harassing
13:42 kilbith not even only for this day, not even for this channel
13:43 VanessaE what you don't see in the logs is the the private discussions I usually have with him, sometimes others, to clarify the whole thing without polluting the public log with useless discussion
13:44 kilbith ... and ? good strategy for re-writing the history
13:44 VanessaE RBA has said unequivocally that my input is valuable to him.
13:44 nrzkt VanessaE: did you use RFID or Wi-Fi for you wireless discussions ?
13:44 VanessaE nrzkt: huh>
13:44 VanessaE ?
13:44 kilbith people can't check the private part, re-writing the history is easy
13:44 nrzkt lol... i read wireless instead of useless, i need to clean my eyes :p
13:44 VanessaE haha
13:44 * VanessaE hands nrzkt some new reading glasses :)
13:47 Robert_Zenz joined #minetest-dev
13:52 VanessaE as for rewriting history, the discussion for that was entirely in public
13:58 leat joined #minetest-dev
14:02 est31 so, as we give every random person who comes along with a crash the blocker label, I've labeled some further bug reports: https://github.com/minetes​t/minetest/labels/blocker
14:02 est31 please complete the list with more bugs
14:42 VanessaE celeron55, can you please weigh in on #611 ?  Let's end this damned debate about the origin of the game's jungle tree.
14:42 ShadowBot https://github.com/minetest/minetest/issues/611 -- Animation blending. by blue42u
14:42 VanessaE er
14:42 VanessaE game@611
14:42 VanessaE game#611 damn it.
14:42 ShadowBot https://github.com/minetes​t/minetest_game/issues/611 -- Junglewood texture too light, boring
14:47 leat joined #minetest-dev
14:49 celeron55 well i prefer whatever is the most faithful to the original
14:50 celeron55 because it's one of the textures i used some time actually designing
14:51 celeron55 altough it is kind of weird 8)
14:51 celeron55 but it's my kind of weird!
14:52 VanessaE heh
14:52 VanessaE well in this case I meant the species that you patterned it after :)
14:53 VanessaE see also game#619 for my proposal (I just want to replace the wood with an image kilbith came up with, and tried to derive a matching tree top)
14:53 ShadowBot https://github.com/minetes​t/minetest_game/issues/619 -- Better jungle wood and jungle tree top textures by VanessaE
14:55 celeron55 well i threw a comment in there
14:55 celeron55 maybe it helps
15:04 hmmmm joined #minetest-dev
15:11 SopaXorzTaker joined #minetest-dev
15:17 leat joined #minetest-dev
15:21 hmmmm jeez, delaying a release is not equivalent to never releasing
15:22 hmmmm I already did the same thing one time and guess what, it was a disaster
15:22 hmmmm and everybody else even supported the idea of a new release
15:33 est31 joined #minetest-dev
15:34 est31 hmmmm, why do you want to delay the release?
15:34 hmmmm because it's half-baked
15:34 est31 is there any bug thats so severe we cant release?
15:34 hmmmm there are too many reviews
15:34 hmmmm err
15:34 hmmmm too many problems
15:35 est31 are there less problems, than e.g. for 0.4.11?
15:35 est31 or 0.4.10?
15:35 hmmmm it's like serving people half-raw chicken
15:35 hmmmm yes
15:35 est31 so LESS problems
15:35 est31 ?
15:35 hmmmm in both of those releases we didn't know about blatant crashes or things taking down a server every 3 to 4 hours
15:36 est31 why can't it wait for 0.4.14
15:36 est31 you want to rush the bugfixes
15:36 est31 and make them inproperly
15:36 hmmmm i don't actually understand what the reason is why there needs to be a release so badly
15:36 hmmmm est31, out of everybody here, you're actually the ONLY one to want a release right now
15:37 est31 am I?
15:37 hmmmm yes
15:37 est31 so then lets blow it off
15:37 hmmmm why don't we
15:37 est31 no release until 2016
15:37 est31 until then we have freeze
15:38 est31 then minetest is proper
15:38 est31 finally
15:38 hmmmm oh my god this is RBA level bullshit
15:38 hmmmm come on
15:38 est31 so you want a release?
15:38 est31 yes or no
15:38 est31 and when do you want it
15:39 est31 name me a date
15:39 leat joined #minetest-dev
15:39 hmmmm one week from now
15:39 est31 lets say two, so that we have time
15:39 nrzkt joined #minetest-dev
15:39 VanessaE one or two weeks -- unless we find a reason to delay again
15:39 est31 august 24?
15:40 hmmmm whichever you prefer
15:40 est31 VanessaE, no additional delays
15:40 est31 we can have three weeks if you want
15:40 VanessaE est31: what if some critical bug pops up right before release, as a result of another bug fix?
15:40 est31 lets determine it NOW
15:40 hmmmm but jesus christ, it's like not only are you taking the half-cooked chicken out of the oven, but you're trying to cram it down your customers' throats
15:40 VanessaE you know fix one, create two, that sorta thing.
15:40 est31 ok, but only new bugs
15:40 est31 not existing ones
15:41 est31 thats what you say VanessaE?
15:41 VanessaE yes basically.
15:41 est31 ok august 23 then, people like sundays more it seems
15:42 est31 and possible delays if more critical bugs pop up
15:42 VanessaE fine.
15:42 VanessaE but now:
15:43 VanessaE what's the *real* list of bugs that must be fixed by then?
15:43 est31 next thing: no bug wishlists, but actual lists which bugs we deem as "blocking"
15:43 est31 ninja'd lol :D
15:43 VanessaE well that's actually what I was referring to
15:43 VanessaE I saw where you tagged a lot of issues as blocker
15:43 VanessaE I wasn't sure if some of those were so-tagged out of frustration, irritation, or legitimate.
15:44 est31 more to show that we did have crashes before
15:44 VanessaE ok
15:44 est31 and that giving the blocker label is easy
15:45 est31 and if you just dont want to release, pressing the blocker label button is even easier
15:46 VanessaE but that raises the question: why should a crash bug skip multiple releases?
15:46 VanessaE rather, "if not now, when?"
15:46 VanessaE (don't get me wrong, I understand perfectly well that some stuff can be a real bitch to fix)
15:49 VanessaE at what point do you say "Ok, that's it - there's no way in hell we can make another release until old bugs X, Y and Z are fixed once and for all" ?
15:49 est31 that's what bugfix releases are for
15:50 hmmmm again the whole point of it is
15:50 hmmmm we never released while in a state where we KNEW that something was crashing, and was a common problem
15:51 est31 what are common problems in your eyes?
15:51 est31 please, github numbers only
15:51 VanessaE hmmmm: right, however we did release in a few cases where there was an irritating, common problem that *didn't* result in a crash
15:51 VanessaE (for example we nearly released 0.4.13 with that extruded wield mesh glitch)
15:51 est31 firefox too has a list of "known bugs" on every release
15:52 est31 but agreed, if there is a bug that makes minetest crash all 4 hours, its inacceptable
15:52 hmmmm #3027 and #3011 at least
15:52 ShadowBot https://github.com/minetest/minetest/issues/3027 -- PcgRandom crashes the application.
15:52 ShadowBot https://github.com/minetest/minetest/issues/3011 -- Sometimes, you get "Lua: error in error handling" messages. Is the (non-handling) error caused by the engine?
15:53 hmmmm these are really obvious bugs
15:53 hmmmm big bugs
15:53 hmmmm 3011 is hard to track down but it happens every 3-4 hours
15:53 est31 ok, agree
15:53 VanessaE *nod*
15:53 hmmmm and then delete_area() needs to be fixed
15:53 hmmmm this was introduced in 0.4.12-dev
15:53 hmmmm *not before*
15:53 est31 delete_area?
15:53 est31 its older than 0.4.12
15:53 hmmmm minetest.delete_area()
15:53 hmmmm it is?
15:53 * hmmmm goes to look
15:54 est31 https://github.com/minetest/minetes​t/blob/0.4.12/doc/lua_api.txt#L1885
15:54 est31 ok, addition of 0.4.12 it seems
15:54 hmmmm when was 0.4.12 released
15:55 hmmmm feb 18th
15:55 hmmmm okay so i guess you're right
15:55 hmmmm didn't seem that long ago
15:55 est31 time flies :/
15:57 hmmmm 6/6/2013 - 11/24/2013 - 1/1/1024 - 7/6/2014 - 12/26/14 - 2/18/15 - 8/18/15
15:57 hmmmm just looking at the timeline of releases
15:57 Calinou 1024 heh
15:58 VanessaE Calinou: well he likes nice round numbers :)
15:58 hmmmm 5.5 months, 1 month, 6 months, 5 months, 3 months, 6 months
15:58 hmmmm sorry 1024 just gets typed more naturally than 2014
15:58 est31 heh lol
15:58 est31 yea it does indeed
15:58 hmmmm I really don't think that 0.4.13 is taking too long
15:59 est31 you convinced me
15:59 hmmmm you can see there have been releases that were clearly rushed in the past and another release was made a month later to fix it
15:59 hmmmm the thing is though
15:59 hmmmm the general public sees our big nasty bugs
15:59 hmmmm and they form opinions about minetest
16:00 hmmmm the opinions are not positive
16:01 est31 what do you mean with "big nasty"?
16:01 hmmmm crashing sort of stuff
16:02 est31 the fact that 0.4.12 generates shadow fields everywhere, which is fixed now?
16:02 hmmmm minetest becomes known as "that minecraft ripoff that crashes every couple of hours"
16:02 VanessaE is not fixed.
16:02 est31 further bugs of 0.4.12?
16:02 hmmmm "hah, the chinese must've ripped off minecraft"
16:02 hmmmm "it's so poorly made"
16:03 est31 the reviews I've seen in the internet say "minetest doesn't have the features of minecraft, but for people who like minecraft alpha, its a nice nostalgic journey"
16:03 VanessaE I still get random, square, black shadows on my worlds from time to time.  not super-common, but occasional and out of nowhere in areas already generated.  Easily fixed with worldedit thankfully.
16:03 hmmmm yeah
16:04 est31 admittedly, most of those reviews are outdated
16:04 VanessaE I'd take that as a negative review frankly.
16:04 hmmmm the shadow thing wasn't as big of a deal IMHO because it didn't /crash/
16:04 hmmmm and it's pretty difficult to solve
16:04 VanessaE given that we're trying to build something here that's definitely not merely "minecraft alpha/nostalgic" quality
16:04 est31 crashes are difficult to solve too
16:04 est31 quality or feature set VanessaE?
16:05 VanessaE both.
16:05 est31 the reviewers complained about the feature set.
16:05 hmmmm what i plan on working on next version should actually fix this for real along with any other mapchunk dependency ordering-class problems
16:05 est31 you mean after the bugfix version 0.4.14 or whatever it's called?
16:05 VanessaE most revies I've seen, when there was a complaint, it was of a general quality nature - i.e. the game feels buggy or "laggy" (usually low FPS) or some other nebulous thing.
16:05 hmmmm hmm
16:06 hmmmm est, we'll do things normally for one more version
16:06 hmmmm 0.4.14 should have bugfixes/improvements for 0.4.13's new features
16:06 est31 "normally"?
16:06 hmmmm normally as in
16:07 hmmmm we'll resume with adding new features next version
16:08 est31 this way we never get stable
16:09 est31 we have to freeze for months, or we wont get into a state VanessaE and others deem as "bug free"
16:09 kilbith joined #minetest-dev
16:10 hmmmm well
16:10 VanessaE when did I say "bug free"?
16:10 est31 "ok for release"
16:10 est31 dunno, hmmmm said it
16:10 hmmmm i just don't want to be embarassed if i tell somebody that i work on minetest
16:10 est31 lemme see
16:11 hmmmm and they try it out
16:11 VanessaE to me, "ok for release" == "no nasty, major bugs that are gonna piss off the userbase" :)
16:11 hmmmm oh god that's my biggest fear
16:11 hmmmm i don't want people who know me IRL to look at minetest
16:11 VanessaE heh
16:11 hmmmm why is my name stamped on this thing even
16:11 est31 http://irc.minetest.ru/minet​est-dev/2015-08-09#i_4357791
16:11 hmmmm "hey <name> I played around with it a while, it crashed when I did X"
16:12 VanessaE well to be fair, hmmmm, at least people who know I work on it (as a modder) are pretty happy to hear.  I'd say if that's the case, then you should be rather proud.
16:12 hmmmm heh
16:12 hmmmm that's because you don't work with the messy parts
16:14 VanessaE true enough
16:14 VanessaE BUT, the average person doesn't see the "messy" parts.
16:14 VanessaE they just see that it works or doesn't (or fails after some time)
16:15 VanessaE so a nasty, messy bodge like connection.cpp matters to us, but the user doesn't mind a little spaghetti as long as it tastes good.
16:16 hmmmm they'd get a bug in their spaghetti every once in a while with that connection.cpp :)
16:16 hmmmm that's enough to make me throw up
16:16 hmmmm and probably a call from the health inspectors
16:17 VanessaE lol
16:23 est31 ok hmmmm VanessaE #3031
16:23 ShadowBot https://github.com/minetest/minetest/issues/3031 -- Critical bugs to be fixed before 0.4.13
16:23 VanessaE in any case you've put a ton of work into the project, and it's objectively better for it, so you should be proud at least of that much, even if the current state of the code is less than stellar.
16:28 est31 suggest further bugs
16:29 est31 but we need an actual list of bugs
16:29 est31 vague ideas are bad
16:32 Krock joined #minetest-dev
16:42 Hunterz joined #minetest-dev
16:50 est31 sigh
16:51 est31 I try to assemble an actual list of bugs to be fixed until 0.4.13, and I just get the reply "use the blocker label"
16:54 VanessaE take the compromise: if it has a blocker label now, either add it to your list or remove the blocker label
16:55 VanessaE and put them in a task list that can be checked off
16:56 VanessaE (I think the markdown for that is "[ ] Fix crash foo in barBlah()" )
16:58 est31 VanessaE, do you propose additional bugs to be added?
16:58 VanessaE not precisely.  lemme skim through the list again.
16:59 ripper93 joined #minetest-dev
17:00 ripper93 Hello everyone. This is the channel where I can report a problem with the dev wiki?
17:01 VanessaE ripper93: as long as it's not "I can't create an account because no kitten captcha" :)
17:01 ripper93 VanessaE: lol, never mind then.
17:01 VanessaE ripper93: in which case, ask Calinou to create one for you :)
17:02 est31 /msg Calinou e-mail address
17:02 ripper93 VanessaE: thank you.
17:02 Calinou hi
17:02 ripper93 est31: this means I should send my e-mail address for him in a private message?
17:03 est31 yes
17:03 Calinou ripper93, in the PM, specify e-mail, desired username (MediaWiki will add an uppercase character automatically at the first character)
17:03 est31 and I think its her
17:03 Calinou and whether you want an account for regular wiki, dev wiki, or both
17:03 Calinou est31, him*
17:03 est31 ok
17:04 VanessaE est31: how about this one: https://github.com/minetest/minetest/issues/2984
17:04 VanessaE it's not a regression, but rather a skin compat failure
17:04 est31 it is a valid bug I agree
17:05 est31 but its rather something for github's milestone feature
17:05 est31 you like to have it, but perhaps you like to procrastinate it too
17:09 VanessaE ok this one I can confirm:  #2964
17:10 ShadowBot https://github.com/minetest/minetest/issues/2964 -- right click and drag inventory bug
17:10 est31 the question is whether this is a bug
17:10 est31 e.g. whether it is actually desired behaviour
17:10 VanessaE if it doesn't work the way users expect, it's a bug imho
17:10 VanessaE well that's not strictly tue
17:10 VanessaE true*
17:11 est31 just you know, pushing things back, then forth, then back again is time waste imo
17:11 est31 and at the end of the day you dont even release
17:11 VanessaE but in this case, you try to use the feature and it just acts weird even to seasoned users. An implementation failure, you could call it since it's trying to mimic a feature in MC./
17:11 est31 even more waste
17:12 twoelk joined #minetest-dev
17:13 VanessaE #2945
17:13 ShadowBot https://github.com/minetest/minetest/issues/2945 -- Immortal/Zombie Glitch
17:13 VanessaE ok this one is a definite gameplay breaker.
17:13 VanessaE but as you said, it's not new
17:19 VanessaE I think you can close #2690 .. it's been fixed hasn't it?
17:19 ShadowBot https://github.com/minetest/minetest/issues/2690 -- positions of particle_spawner output not entirely accurate
17:20 est31 I think no, im not sure
17:29 VanessaE anything else I could suggest would be among the ones labeled as blocker.
17:40 MinetestForFun joined #minetest-dev
17:49 kaeza2 joined #minetest-dev
17:51 FR^2 joined #minetest-dev
17:55 kaeza joined #minetest-dev
18:16 blaise joined #minetest-dev
18:20 nore joined #minetest-dev
18:21 nore_ joined #minetest-dev
18:21 nore_ left #minetest-dev
18:38 lag01 joined #minetest-dev
18:45 blaise joined #minetest-dev
19:01 est31 joined #minetest-dev
19:02 est31 hmmmm, kahrl what's your preferred way to make heaps?
19:02 est31 I want to fix this leak paramat keeps pointing to
19:02 est31 so I need to order mapblocks now by their last used time
19:02 est31 (last used for rendering)
19:02 kaeza joined #minetest-dev
19:03 est31 and then I've planned to delete mapblocks older than a specified amount of seconds
19:03 est31 err
19:03 est31 delete mapblocks that are over a given count
19:03 est31 e.g. 1000 mapblocks are allowed to be loaded, not more
19:04 VanessaE est31: what about also freeing them based on distance from the player?
19:04 est31 not good
19:04 est31 a day ago you suggested to add travelnets to mtgame
19:04 VanessaE mmhmm
19:05 MinetestForFun joined #minetest-dev
19:06 VanessaE but I am thinking more a multiplier - i.e. if max(age_seconds,0)*max(distance_meters, 0) is greater than some reasonable threshold, delete the block
19:06 VanessaE and if the count is over 1000, delete strictly by age
19:07 est31 if you limit by count only, the leak is gone
19:07 est31 so distance metric not needed
19:08 VanessaE true
19:09 VanessaE but if you also limit by age and distance, you reduce the total memory in use, for example of a typical player who teleports back and forth between his/her home and mine
19:09 VanessaE in theory one shouldn't need more than a few hundred mapblocks loaded in that case - for that user anyway
19:10 est31 travelnets are much like quotient space identifications of points
19:10 est31 the metric needs to be updated
19:11 VanessaE in that example, the blocks' age would be fairly low, enough to keep even a large distance from exceeding the unload threshold.
19:11 VanessaE in any case limiting it by count alone is enough for now
19:11 VanessaE the rest can be worked out later.
19:14 hmmmm no don't add travelnet to mtgame until the error in error handling gets fixed
19:14 VanessaE of course, there's network bandwidth to consider - the less you keep loaded, the more you have to re-transfer as the old blocks expire.  if the client would cache the received data and only query the server for newly-changed blocks (based on timestamp, not content) then it wouldn't matter how many the client keeps on hand
19:15 est31 well yeah
19:16 VanessaE hmmmm: agreed, though I think that was more the result of using any generic teleporter between two points on the map
19:16 est31 but that goes in the feature domain
19:16 VanessaE (i.e. how that would affect how many blocks are loaded)
19:16 est31 hmmmm, fully agree
19:18 est31 hmmmm, does std::priority_queue sound goo?
19:18 est31 good*
19:18 hmmmm I don't know, I guess
19:18 hmmmm whatever works
19:18 est31 also, should I rather implement a custom type to get the comparisons, or should I implement a custom comparator
19:19 est31 I need it to store 1. the useagetimer
19:19 hmmmm est, the thing is, mapblocks are already deleted
19:19 est31 2. the mapblock
19:20 est31 and 3. the mapsector
19:20 est31 while 1 isnt required
19:20 est31 it can be read from the mapblock already
19:20 est31 its one pointer dereference and method call
19:21 est31 hmmmm, they are, just they are deleted by time, not by how much there are
19:21 hmmmm so do you know if that's the actual problem??
19:22 est31 I've set the time to 10 seconds, and the blocks got deleted
19:22 est31 but setting time that low is bad again, because of the server
19:22 est31 instead we should allocate as much blocks as we can, and only delete if there is no more room
19:22 est31 people can adjust it then in their settings
19:23 hmmmm sounds good to me
20:09 TBC_x hey, aren't the too-far-away mapblocks sitting in memory uncompressed
20:09 TBC_x ?
20:11 est31 yes
20:11 TBC_x why not to do all caching compressed?
20:11 est31 thats a feature
20:12 TBC_x well... memory overuse is not a bug?
20:12 est31 I just delete them
20:13 est31 no need to do fancy compressing
20:13 est31 also its hard to find out how far away mapblocks really are for clients
20:13 est31 as they can teleport around
20:14 TBC_x I think the most offenders are underground, never actually seen by the player
20:14 TBC_x therefore I think that a server could use some form of occulsion culling (if that's the correct term)
20:15 est31 it is
20:15 est31 and currently the client manages it
20:15 TBC_x oh, okay
20:17 TBC_x is there any kind of statistics of visible vs loaded blocks?
20:19 est31 yes
20:19 est31 either turn on infostream
20:19 est31 @ least loaded blocks)
20:19 est31 (
20:20 est31 or edit map.cpp, change infostream to actionstream in  Map::timerUpdate
20:20 est31 and remove the deleted_count != 0 case for if
20:20 TBC_x and I expect that too-far-away mapblocks deallocate their meshes
20:25 est31 its damn hard to find out what too far away means
20:26 est31 because if you have a travelnet, and teleport back and forth, you have a problem
20:26 est31 you'll need to "cut" the distance here
20:26 est31 its better to manage them based on count
20:27 TBC_x for mapblock meshes I would say that renderable distance
20:27 TBC_x for any meshes
20:28 TBC_x teleportation would just skip mapblock download
20:29 est31 #3033
20:29 ShadowBot https://github.com/minetest/minetest/issues/3033 -- Add count based unload limit for mapblocks by est31
20:52 lag01 joined #minetest-dev
22:30 cheapie joined #minetest-dev
22:50 nore_ joined #minetest-dev
22:50 Guest26086 joined #minetest-dev
22:50 Guest26086 left #minetest-dev
23:19 Lunatrius joined #minetest-dev
23:27 Sokomine joined #minetest-dev
23:49 Taoki_1 joined #minetest-dev

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