IRC log for #minetest-dev, 2014-07-05

Time	Nick	Message
00:21		sapier left #minetest-dev
00:34		us`0gb joined #minetest-dev
02:45		kaeza joined #minetest-dev
03:36		psedlak joined #minetest-dev
03:40		Hunterz joined #minetest-dev
03:41		psedlak joined #minetest-dev
03:48		kaeza joined #minetest-dev
03:49		robmyers left #minetest-dev
03:51	hmmmm	hmm
03:51	hmmmm	ClientMap::m_last_drawn_sectors is not used at all
03:52	hmmmm	it may have been at one point, but certainly not now.
04:17		catninja joined #minetest-dev
04:26		Lord_Evil joined #minetest-dev
05:31		nore joined #minetest-dev
06:24		alexxs joined #minetest-dev
06:25		Eater4 joined #minetest-dev
06:26		alexxs joined #minetest-dev
06:33		alexxs joined #minetest-dev
06:45		Garmine joined #minetest-dev
07:00	RealBadAngel	,
07:06		grrk-bzzt joined #minetest-dev
07:06		grrk-bzzt joined #minetest-dev
07:31		Weedy joined #minetest-dev
07:31		Weedy joined #minetest-dev
07:42		casimir joined #minetest-dev
07:45		tomreyn joined #minetest-dev
07:55		us`0gb joined #minetest-dev
08:17	celeron55	i'm going to try figuring out the subgame thing now
08:17	celeron55	(yes, i'm late; i forgot the thing completely)
08:17	celeron55	i mean, the question of which games to include
08:18	celeron55	i don't have an opinion on "how to encourage not using minetest_game" other than that it should be done somehow, either a label or a hardcoded "legacy filter" setting enabled by default or something
08:20	kaeza	why not doing it in the same way as `minimal'? (a notice on join that the game is for testing purposes only)
08:21	celeron55	because it isn
08:21	nore	also, an uniform background in the menu isn't very encouraging either (as in minimal)
08:21	celeron55	+'t for testing purposes only; people use it in their old worlds
08:21	celeron55	and it's a perfectly valid use case
08:23		sapier joined #minetest-dev
08:24	sapier	what about providing a patch to irrlicht to support texture compression? Imho a way better alternative then forking and having to maintain on our own
08:25	sapier	in worst case we'd have to check for irrlicht version but if we don't start doing it it's never gonna be in irrlicht standard version
08:30	celeron55	i think co-operating more with irrlicht would make sense
08:33	celeron55	it could be a huge time sink though if they don't like it
08:33	celeron55	they obviously aren't making a 3d library for a minecraft-like game but something much more traditional
08:43		us`0gb joined #minetest-dev
08:46		Calinou joined #minetest-dev
08:51	celeron55	what
08:51	celeron55	why is there an FPS text forced to be on the screen all the time next to the version string?
08:51	celeron55	this is stupid
08:58	celeron55	removed it
09:00		Hunterz joined #minetest-dev
09:02		PenguinDad joined #minetest-dev
09:07	Calinou	thanks
09:07	Calinou	I don't need to know my FPS here ;)
09:08	celeron55	Calinou: i need to talk about carbone
09:08	Calinou	I'd appreciate if I could hide version string too, without hiding chat
09:08	Calinou	I don't need to know Minetest version either :P
09:08	celeron55	because it doesn't work
09:20	Eater4	The minetest versoin can stay...
09:20	Eater4	everything else can go
09:21	sfan5	I suggest following Eater4s request and removing the rendering of nodes
09:21		PilzAdam joined #minetest-dev
09:22	Eater4	celeron55: why arnt you voiced?
09:22		us`0gb joined #minetest-dev
09:38		LemonLake joined #minetest-dev
09:39	celeron55	Eater4: because i don't like being
09:40	PilzAdam	all core devs are equal, but celeron55 is more equal
09:40	LemonLake	how is that possible?
09:42	Calinou	https://github.com/minetest/minetest/issues/1443 â†’ tag as enhancement of feature request; by the way, is max_hear_distance even working with positional sounds in general?
09:42	Calinou	changing it does nothing for me
09:56		ImQ009 joined #minetest-dev
10:01	celeron55	so, i have picked carbone out of the two
10:02	sfan5	the two = ?
10:03	celeron55	out of carbone and minetest_next
10:04	sfan5	weren't there more?
10:05	celeron55	what do you mean
10:05	celeron55	i wanted to pick either one of those two as the more worthwhile one and did that
10:05	sfan5	https://forum.minetest.net/viewtopic.php?f=15&t=9103
10:07	celeron55	nodetest is the worst name ever imagined by a human being
10:07	celeron55	i'll take a look at it though
10:08	sfan5	VanessaEs Dreambuilder is probably to heavy..
10:09	celeron55	dreambuilder is about 18M compressed, carbone is 8M
10:10	celeron55	umm wait
10:11	celeron55	no, that was completely wrong
10:13	celeron55	dreambuilder 18M, carbone 3.3M
10:13	celeron55	18 wouldn't be that bad if it was perfect and perfectly polished but it's kind of a mishmash of things do maybe it's not worth it
10:14	celeron55	so*
10:15	celeron55	on the other hand, carbone seems to do a lot with the extra 0.5M compared to minetest_game
10:16	celeron55	like having mobs and more interesting sounds
10:21	sfan5	incoming commit in 5 minutes: http://sprunge.us/GNPN?diff
10:21	celeron55	nodetest seems to be kind of barebones, not really what we need now
10:21	celeron55	it's very small though; just 0.6M
10:21	celeron55	(bz2 compressed like all of my comparison values)
10:23	celeron55	nodetest: "It's focus is on a basic gameplay with more survival features."
10:23	celeron55	what kind of survival features does it have?
10:23	sfan5	does it even have mobs?
10:23	celeron55	seems kind of random as i don't see even mobs
10:24		asl joined #minetest-dev
10:26	celeron55	ehm, my minetest_game value was wrong...
10:27	celeron55	now this makes a lot more sense
10:27	celeron55	3,3M carbone.tar.bz2
10:27	celeron55	18M dreambuilder.tar.bz2
10:27	celeron55	748K minetest_game.tar.bz2
10:27	celeron55	844K minetest_next.tar.bz2
10:27	celeron55	580K nodetest.tar.bz2
10:28	celeron55	it's rather linear when compared to the features of each
10:29	celeron55	and carbone really is at a good spot
10:30	casimir	celeron55: nodetest is the worst name ever imagined by a human being
10:30	casimir	I was ill that day. Suggest a better one ;)
10:31	celeron55	now, i think there's a need for maybe two small-but-interesting games in addition to carbone
10:31	* sfan5	pushes his commit (5 minutes too late)
10:34	celeron55	in my opinion nodetopia would be interesting to have in there; we'd get a lot of opinions from all kinds of people for what they think about such a game
10:35	celeron55	another interesting one would be realtest
10:36	celeron55	and... well basically i think what wuzzy thinks here: https://forum.minetest.net/viewtopic.php?pid=138487
10:36	* sfan5	downloads nodetopia..
10:38	celeron55	realtest and nodetopia really need some easily accessible documentation though... maybe make the bundled versions always produce a text in the chat like "For help, go read http://wiki.minetest.net/Nodetopia"
10:38	sfan5	* Error in `./minetest': double free or corruption (!prev): 0x00000000024026e0 *
10:38	sfan5	:(
10:39	sfan5	the menu bg for nodetopia looks very nice
10:39	sfan5	I didn't even know you could have a bg and clouds
10:40	sapier	oops sorry fps was my fault, was from android build to know fps count in release builfs
10:40	celeron55	realtest and nodetopia are 0.7M and 0.8M
10:41	sfan5	I vote for including nodetopuia
10:41	sfan5	nodetopia*
10:42	sfan5	#0 0x0000000001236ac0 in ?? ()
10:42	sfan5	I love debugging. /s
10:42	celeron55	or... actually, they could just have a button in the inventory screen that would launch a formspec with the most important things listed
10:43	sapier	sfan5 any way to reproduce that bug?
10:43	celeron55	are there any subgames that have interesting non-survival gameplay?
10:43	sfan5	sapier: do things in the menu
10:43	celeron55	i guess this isn't really release-worthy? https://forum.minetest.net/viewtopic.php?f=15&t=6947
10:43	sfan5	sapier: I'm trying to find out why it crahes right now
10:44	sapier	some special thing?
10:44	sfan5	nope
10:44	sfan5	just normal things
10:44	sfan5	such as creating a world and/or joining said world
10:45	celeron55	adventuretest (https://forum.minetest.net/viewtopic.php?f=15&t=9184) has some things that are more RPG-like instead of open world survival -like... maybe not good
10:45	sapier	if this isn't something specific to your environment that sounds like a blocker
10:46	PilzAdam	Nodetopia isn't in a releaseable state
10:47	PilzAdam	if you really want to add it to the release then I have to remove some experiments of it
10:48	sapier	PilzAdam: can you do this till tomorrow?
10:48	sapier	"can" as of is this enough time
10:48	PilzAdam	sure, rm is fast
10:49	celeron55	sfan5: if you were impressed by nodetopia's menu background, try wasteland
10:49	sfan5	I will
10:50	celeron55	sfan5: literally the only thing wasteland does well is the menu screen
10:50	celeron55	8D
10:50	sfan5	(after I get Irrlicht to compile and Minetest not to crash)
10:50	celeron55	maybe your gpu drivers are borked and you need a restart
10:50	sfan5	maybe
10:52	PilzAdam	ummm... RealBadAngel why is the water in Nodetopia waving without me adding something to the nodedef?
10:54	PenguinDad	PilzAdam: the lava is waving too
10:54	PilzAdam	and you can also see farther under water now, if Im not mistaken
10:55		lemonlake_ joined #minetest-dev
10:55	sapier	https://gist.github.com/sapier/2f5f8fb31b60f57c59a4
10:55	sapier	correct state of game discussion?
10:56	sfan5	I don't think so
10:56	celeron55	https://gist.github.com/celeron55/6d6d8870e2960ee956cf
10:56	PilzAdam	Nodetopia also uses mapgen v7, which is still unstable
10:56		Jordach joined #minetest-dev
10:56	sapier	ah there already was a gist :-)
10:56	celeron55	we need to somehow indicate that only carbone (if finally chosen) is the long-term supported one
10:57	celeron55	sapier: i just made that gist
10:57	PilzAdam	I don't think I want it to be released in its current state
10:57	sapier	ok :)
10:57	sapier	18M seems a little bit big to me
10:58	celeron55	only a few of those have permission from their makers anyway, and out of those few carbone is the only reasonable one in terms of everything
10:58	sapier	well at least for android port carbone is to heavy
10:58	celeron55	i'm kind of worried that we will end up with carbone only
10:59	celeron55	sapier: ports can pick their games however they want
10:59	sapier	but that shouldn't be a problem for pc version
10:59	celeron55	it would be completely insane to drag down PC based on mobile phones
10:59	celeron55	stop it
10:59	celeron55	this is a PC games; everything else is a second-class citizen
11:00	celeron55	-s
11:00	sapier	I just wanted to be sure everyone knows android port wont be same as pc version ... ppl already demand full feature set there
11:01	celeron55	so... i wonder if there is any smaller game that differs considerably from minetest_game and that is finished enough
11:02	celeron55	not for android, but for the role that nodetopia would have fitted
11:02	sapier	why does it have to differ? as minetest game is frozen any successor of it won't demand that much
11:02	sapier	--demand + differ
11:02	celeron55	for having fun with different kinds of games goddamnit
11:02	Taoki	celeron55: My personal disappointment is that no games other than minetest_game I've seen so far appear to offer a more detailed / progressive / complex gameplay. Everything is still "you easily get everything and there's not much to do"
11:03	Taoki	Still, even so, I would encourage other games apart from minetest_game
11:03	celeron55	progressive gameplay is a good term, yes
11:03	Taoki	But we really need a better game, which offers a strong artistic style and better progress / etc
11:03	sapier	In generall I agree but with minetest_game frozen this seems to be rude ... as it results in never ever allowing a similar game but freeze current state
11:03	celeron55	and it's missing, yes
11:03	celeron55	sapier: carbone is such a game
11:03	celeron55	and it is in good state
11:04	PenguinDad	"you easily get everything" is not true for big_freaking_dig
11:04	Taoki	I was just yesterday arguing for instance about some apparent limitations in Minecraft... such as a limit of 64 for item stacks and a workbench for the 3x3 crafting grid. Calinou believes those are annoyances, but I believe details like this make things more fun and progressive.
11:04	Taoki	And of course much more added to it
11:04	celeron55	hmm, i need to check out in what state BFD is
11:04	casimir	So what speaks against nodetest? It has progression and things.
11:04	Taoki	I tried carbone, still looks a lot like minetest_game just with different textures
11:04	Taoki	I'll try it more though
11:05	celeron55	Taoki: well workbench is quite a small progression; but it does set the mood right from the start
11:05	Taoki	Yes
11:05	celeron55	casimir: what kind of progression? explain a bit
11:05	Taoki	Also, I personally don't believe a good game is possible without more biomes! But everyone is afraid to use V7, because some voices from above keep saying it's not stable, despite it working perfectly for me
11:05	Taoki	With the default biomes, the world looks simply... dead
11:06	celeron55	i would like to see a game that would use a lua mapgen
11:06	casimir	You can not punch trees with bare hand, so you need tools first.
11:06	celeron55	and take full advantage of everything that it allows
11:06	celeron55	casimir: anything more than that?
11:06	sapier	I guess I'll let others decide about the games to add :-)
11:07	celeron55	casimir: it would be nice to have all this on a forum or wiki page for easy reference
11:07	casimir	And there are not all those rainbow caves. It actually is hard to find resources.
11:07	Taoki	https://forum.minetest.net/viewtopic.php?f=11&t=7366&start=50#p139998 See the screenshots I linked in this post please. THAT is a beautiful environment right there
11:07	casimir	k. Will write it all into the forum post.
11:07	celeron55	casimir: i would ike to be able to easily compare nodetopia, nodetest and realtest, for example
11:08	Taoki	http://tinypic.com/view.php?pic=ipb8ra&s=8#.U7fcK6ZL1hE or http://tinypic.com/view.php?pic=10xuadw&s=8#.U7fcG6ZL1hE is what I really would love to find around the world :)
11:09	Taoki	Actually I'd advice those games to include paragenv7 specifically. Because it's so awesome and has such lovely environments
11:09	celeron55	tinypic sucks; it loads the page in like 0 seconds and then loads the image after 15 seconds
11:09	Taoki	oh
11:09	Taoki	Yeah I use imgur now
11:09	Taoki	Anyway, that mapgen + my basic workbench mod + PA's SimpleMobs would IMHO be enough to make a game look solid and real for starters.
11:10	celeron55	anyway, yes, well-thought-out biomes are interesting
11:10	celeron55	the issue is to combine everything in a single game
11:10	Taoki	yep. There need to be environments that attract the player and look awesome
11:10	sapier	taoki why not mobf with reduced set of mobs?
11:10	celeron55	there are mods for biomes like paragenv7, then there are multiple cave mods which make caves much more interesting
11:10	celeron55	and so on
11:10	Taoki	And I don't think it's an issue. Just needs someone to do it
11:11	celeron55	someone should put these together for example in an experimental version of carbone, polish it a bit and see how it works
11:11	Taoki	sapier: Problem is that mob frameworks other than SM are said to be more costly and laggy in multiplayer. Also, the default mobs in other mob mods aren't artistically ok. As in, they're low quality or full of diagonal surfacees rather than blocky as it looks right
11:11		vifino joined #minetest-dev
11:11	celeron55	and then figure out how to do progressive gameplay in it and implement that
11:11	sfan5	PilzAdam: are the hearts in nodetopia supposed to be this small? http://i.imgur.com/EbVNBUr.jpg
11:12	Taoki	celeron55: Calinou doesn't want some of those progressive features, like the workbench. So I don't think carbone is the perfect candidate for some of those features
11:12	Taoki	Although it might make a great game otherwise in its own way
11:12	celeron55	workbench isn't a necessity at all
11:12	celeron55	progression can be put in other parts of the game instead
11:12	celeron55	like how resources are placed in the world
11:12	Taoki	I guess. For me at least however, everything feels too quiick and non-progressive without it. Could say the same for lower item stack limits
11:12	celeron55	or how mobs appear in the owrld
11:13	celeron55	world*
11:13	Taoki	True too
11:13		BlockMen joined #minetest-dev
11:13	celeron55	or how crafting progression works
11:13	celeron55	you can put it pretty much anywhere you want, as long as you use your brain a bit
11:13	sfan5	BlockMen: you'll do the MSVC builds for 32 and 64 bit, right?
11:14	BlockMen	sfan5, if celeron55 is not bitchy about it anymore, yes
11:14	celeron55	i'm fine with that if everyone else is fine with that
11:14	sfan5	what was the problem?
11:14	Taoki	BTW. As I mentioned before, I'll be making my own game too eventually. But it will be a while, and the gameplay and ideas will be quite different (eg: it will use my Creatures system with mob possession). It aims to be good and immersive and artistic however
11:15	Taoki	Could still be an option to include it with Minetest though... years from now after it's ready
11:15	BlockMen	since it seems there are also not declared games
11:15	celeron55	anyway the issue is, there is no progression if you just slam random mods together
11:15	BlockMen	what is with mt+?
11:16	celeron55	you need to build progressive dependencies between the things the mods provide; they can't do it independently
11:16	Taoki	celeron55: Yes, true there. Mods need to be tweaked and thought of to work together
11:16	celeron55	this is why subgames exist
11:16	Taoki	And that is indeed hard, cuz it requires modifying each mod
11:17	Taoki	BTW: Does it make sense to have both minetest_game and minimal now? Since both seem to do the same thing; Are mostly there to offer basic functionality only, and both are frozen.
11:17	celeron55	hmmh
11:17	Taoki	minetest_game is probably as good for testing as minimal
11:17	celeron55	carbone could be a bad choice if calinou isn't intending to ever grow up some progression in it
11:18	Taoki	I don't know if he is, we only discussed features like workbench etc. He would have to speak about that
11:18	celeron55	but nobody else is doing that either, except a few small unfinished ones
11:18	Taoki	I plan to, but it will take a while since what I want to do I want to do well
11:19	Taoki	My work on the creatures mod is actually work on the most essential part of a game I'll make, so yeah
11:19	celeron55	i'll wait until calinou is available again and discuss this a bit
11:19	BlockMen	ok, the game choosing is acually kinda confusing for me. could someone sum up the current state?
11:19	Taoki	But until then, I agree that we really need a mod which doesn't copy Minecraft but offers the diversity and effect it has. Which is hard to achieve, since MC thought and balanced everything VERY well
11:21	celeron55	BlockMen: too few games are finished for release, and out of the minetest_game-continuations, carbone seems most reasonable in features vs. size and is quite polished, but now the issue is whether it is ever going to have any kind of progressive gameplay
11:21	Taoki	Also, truth be told, the engine also lacks many things for a very good gameplay to be possible. Mobs are still laggy due to how Lua entities work, animations aren't always set (players / mobs are often walking while standing), there are no sound and particle effects for water, chest inventories lag horribly, and more
11:21	Taoki	Player - player collisions don't even exist yet
11:21	Taoki	Those are details that harm immersion
11:21	celeron55	BlockMen: eg. nodetopia would have been a fun side game, but PilzAdam declared it not finished enough
11:22	BlockMen	so next is out?
11:22	Taoki	Not even yaw smoothing exists yet, like for positioning. Mobs and players simply snap to different rotations, which looks really really bad
11:22	sfan5	but nodetopia can still get included if PilzAdam decides to remove his experiments
11:22	celeron55	minetest_next seems to not really differ from minetest_game at all in any considerable way
11:22	Taoki	I'd make a list with those issues, but I don't want someone to feel like I'm telling the devs what to do without doing it myself.
11:22	celeron55	it's like the same thing
11:23	celeron55	having some information about how each of these are planned to be developed in the future would be extremely useful at this point
11:24	BlockMen	_next is tought as maintained _game, so everyone can make pull and they get merged when agreed by maintainers (currently sfan5, nore and me)
11:24	Taoki	Also, there's one more thing I REALLY believe a good game needs to have: Textured formspecs as well as hotbar. The black background looks very ugly and basic. Also a textured crosshair... the default one doesn't look too pretty.
11:24	BlockMen	its more community based like _game (in opposite to carbone)
11:25	celeron55	the ideal pick would be something that makes users go like "wow there's new stuff" right now, and in the future would develop a LOT more in a solid direction
11:25	sfan5	wouldn't that be nodetopia?
11:25	celeron55	BlockMen: that won't work
11:25	Taoki	For this purpose, I suggested a function in builtin to allow specifying a default formspec appearance per game, to be used when a formspec doesn't specify its own background.
11:25	BlockMen	celeron55, what exactly?
11:25	Taoki	celeron55: Agreed. For both games and the engine alike
11:27	Taoki	Also, we'll eventually want weather in some form. But with the old weather system removed (due to finite liquid), that will be harder to do now.
11:27	Taoki	So there's still a LOT to do in the engine too I think. Maybe I'll make a post about it, as I feel a list with those important missing features is needed
11:31	Taoki	BTW, when is 0.4.10 being released? I use GIT so I don't care personally, but I'm hoping the feature freeze running off might bring new features and fixes
11:31	sfan5	Taoki: tomorrow
11:32	* Taoki	can't figure out if that litreally means tomorrow or if it's that classic saying about software releases :)
11:33	sfan5	literally
11:33	Taoki	oh, cool then
11:33	BlockMen	celeron55, and your idea with "wow, new stuff" is nice but i think hard to reach. 1)because we still provide _game, which stays as is, 2) ppl want play their old worlds and not veryone is willing/knows how to "convert" it
11:33	BlockMen	and concerning next, for what was the vote on forum at all?!
11:34	sfan5	concerning 2): how about adding a button to convert worlds to a different game
11:34	celeron55	it got much less traffic than i thought it would
11:34	sfan5	(ofc with a not that "this may not work and may cause your world to not work at all")
11:34	sfan5	notice*
11:34	Taoki	You can convert worlds to different games? Doesn't fully make sense, if each game uses its own mapgen / ores / nodes
11:35	BlockMen	but it results say clearly to add _next
11:35	BlockMen	sfan5, yes. could be an option
11:35	celeron55	what is the development direction of _next?
11:36	celeron55	also, why did you choose that name, it's almost the worst ever; you had a chance of making it easy for everyone to differentiate engine from the games, and you didn't take it
11:37	celeron55	also, if it's chosen, it won't be "next" anymore; i guess it needs to be released under a different name
11:37	Taoki	_next probably means it was initially indented as an experimental version of minetest_game, which probably doesn't sound too good to the ear right now
11:38	celeron55	i really want to have games to have a different identity compared to minetest itself; trying to keep one of them under the same identity kills creativity and confuses people
11:38	BlockMen	the direction is to keep it lightweight as starting platform for mods (like _game), but with the option to include more mods/features in future
11:38	BlockMen	yes, the name is by me and not the best
11:38	celeron55	who chooses what mods and features?
11:39	celeron55	everyone adds their own, and there will never be any direction?
11:39		smoke_fumus joined #minetest-dev
11:39	celeron55	that's exactly what i don't want
11:39	* Taoki	agrees once again. Not every game needs to be called minetest_something, and especially not look like something experimental for MT. Just a different game and approach
11:39	BlockMen	everything is discussed on ##minetest-next
11:39	Taoki	yeah
11:39	BlockMen	everyone can join and talk
11:39	BlockMen	the maintainers decide what goes in
11:39	celeron55	designing games by committee always fails; i won't accept it
11:40	BlockMen	^ proove it
11:40	Jordach	and people wonder why BFD is a one man project :P
11:40	BlockMen	and minetest (engine) is designed same way
11:40	Taoki	minetest_game has actually ran this experiment: Every public server is minetest_game with various mods included. Some servers even have a lot of good mods! But none are exciting as of yet.
11:40	BlockMen	no, minetest_game was never maintained sanely
11:41	sfan5	Jordach: why not mark BFD for inclusion?
11:41	Taoki	Because the mods aren't intnded to work together, and rarely consider each other... mostly for compatibility purposes
11:41	celeron55	engines can be; they have less effect on the player experience
11:41	BlockMen	it was never clear who decides things and some liked to block everything
11:41	BlockMen	in next 2 maintainers are enough
11:41	BlockMen	even if one does not agree the other 2 can push it
11:42	celeron55	i want to see the direction of _next written down; otherwise i'm certain there will never be any
11:42	Taoki	For example: A server wants to have mobs and a mesecons device players can craft. The mobs mod and device mod are two different things, not meant to be related. So then, we miss the opportunity of a mob providing an essential item for crafting that device.
11:43	Taoki	The two can't work together as easily to provide the best balance
11:43	sfan5	they could work together
11:43	sfan5	but mesecons would need to add support for that
11:43	Taoki	Already an issue with simplemobs actually: If mobs could be the only source for an important item needed to craft special blocks, they would be more useful. But then, the mods for those special blocks wouldn't work without the mobs mod
11:44	celeron55	BlockMen: currently i am especially interested about plans for progressive gameplay
11:44	PilzAdam	sfan5, no, the hearts shouldn't look like that
11:44	Taoki	I guess. Thing is, too many mods need to look out for too many other mods
11:44	celeron55	PilzAdam: the statbar api had problems and had to be respecified, should be an easy fix
11:44	celeron55	(assuming it didn't break more in the fix)
11:44	PilzAdam	sfan5, there are other problems other than my experiements: it uses an unfinished and unstable mapgen; it has not enough features; I might want to break compatibility in the future development
11:45	Taoki	There is also another problem: When you rely on individual mods to compose a game / server, you also risk getting more bugs. Since unwanted functionality can occur between multiple mods. It's also harder to fix all bugs regarding them
11:45	Taoki	Still, every idea needs to be its own mod. Just maybe maintained by the same team, each mod in harmony with the other that's part of that game
11:45	PilzAdam	celeron55, I don't use that API, I only supply an heart.png
11:46	PilzAdam	though each image has 2 hearts, so there are no half hearts
11:46	celeron55	BlockMen: to be clear: if you do write the direction down and it seems solid enough for me, i can very seriously consider _next
11:47	celeron55	BlockMen: i can't judge it by the current features because they are all just small tweaks
11:47	sfan5	Taoki: idea: create a mod that allows other mods to register materials with tags (i.e. mobs mod) and other mods to get materials that match some tags (i.e. mesecons)
11:48	celeron55	BlockMen: most of the one-man games have something unique in them which gives me some idea how they will approach things in the future
11:48	sfan5	if every mod uses that system the crafting reciepes can dynamically adapt to the different subgame/mod combos
11:48	PilzAdam	who has changed the drawing of the built-in heartbar?
11:48	Taoki	sfan5: Might work. You can already do check_modpath really. But each mod needs to be on the lookout for each other mod. And unless the same author develops all mods, that's harder
11:48	celeron55	PilzAdam: could it be related to the GUI scaling improvements?
11:49	Taoki	BRB
11:49	sfan5	Taoki: no, no, a generic api
11:49	celeron55	PilzAdam: ah
11:49	Taoki	If it is possible in some way, it is a good idea yes
11:49	celeron55	PilzAdam: your problem is that the healthbar drawing was changed to not care about the aspect ratio about the imagess
11:49	celeron55	PilzAdam: because it has to scale the images for different screen sizes
11:50	PilzAdam	celeron55, probably; the 2 hearts seem to be scaled to the size of one, since apparently the engine now forces everyone to use half-hearts
11:50	celeron55	it can't draw the images 1:1 to the screen as the DPI varies so much
11:50	celeron55	preserving the aspect ratio is a thing that nobody thought though, maybe it would be possible
11:52	celeron55	sfan5: that's largely possible by using item groups
11:53	celeron55	but it's always harder to document and explain to people when you're using an abstraction like that
11:53	celeron55	and it's not magic
11:54	celeron55	if there is a mod that provides half of the things, then where do you get the other half?
11:54	celeron55	making some kind of a resolver for these would probably confuse players even more
11:55	sfan5	with fallback things ofc
11:55	celeron55	we might need a common mechanism for the fallbacks
11:55	sfan5	if mesecons can't find an item for "<insert describing adjectives for silicon here>" it will define it's own with the crafting it always had
11:56	celeron55	so that mesecons could define fallbacks which it will use only if zero other mods provide the items
11:56	celeron55	then again, it's impossible to have balance if two mods are providing something that mesecons expects only one mod to provide, as you have twice the availability
11:56	celeron55	but that's unsolvable
11:56	sfan5	no, no
11:57	sfan5	I mean mesecons/the API choosing one of the items that fulfills the criteria
11:57	celeron55	> if mesecons can't find an item for "<insert describing adjectives for silicon here>" it will define it's own with the crafting it always had
11:57	celeron55	hmm, this actually is simple and would work
11:57	celeron55	actually, there's still a problem
11:57	sfan5	the hardest part about that would probably be mod devs describing how their materials are
11:57	celeron55	mesecons has to know the mods so that it can load after them
11:58	sfan5	this is why we need being able to load mods dynamically
11:58	celeron55	well it needs some kind of staged loading
11:58	celeron55	good luck with full dynamic loading
11:59	celeron55	anyway, so i take this as we need a few more years before 0.4.10
11:59	sfan5	I think staged loading would be the easier option here
11:59	celeron55	i guess i'll go eat now, lol ->
12:00	sfan5	hm
12:00	sfan5	I'm pretty sure you could do full dynamic loading in pure lua
12:00	sfan5	0) save global variable state
12:00	sfan5	1) mod runs
12:01	sfan5	2) mod wants to dyn. load mod2
12:01	sfan5	2.1) restore global state
12:01	sfan5	2.2) patch methods that do something with the modname, e.g. minetest.get_current_modname()
12:01	sfan5	2.3) dofile(mod2)
12:02	sfan5	2.4) merge current global state with global state saved at 2.05 [forgot that step]
12:02	sfan5	3) success!
12:03		lemonlake joined #minetest-dev
12:05	celeron55	seems like a hack
12:05	celeron55	whatever, the real question is, will fallbacks or equivalent functionality solve this problem
12:06	sfan5	if every mod uses that system: very likely
12:06	celeron55	but do they care
12:06	sfan5	<sfan5> the hardest part about that would probably be mod devs describing how their materials are
12:06	sfan5	probably not D:
12:06	celeron55	nothing is a technical issue in the end; the real issues are with people
12:06	celeron55	nothing is a technical issue in the end; the real issues are with people
12:06	celeron55	-the other line
12:07	sfan5	nice quote :)
12:07	celeron55	i just quoted myself from this discussion, it was such a great line
12:07	celeron55	ehm, lol, anyway
12:08	celeron55	we should get back to 0.4.10 things
12:09	celeron55	i'm going to wait for _next's response to my question
12:09	sfan5	response coming soon
12:21	PilzAdam	I'd like this water waving and hotbar scaling issues to be resolved before 0.4.10
12:22	sapier	have you specified a correct size for your hotbar?
12:22	sapier	the fix won't work for old coding but only if you specify the needed information to do it correct
12:22	PilzAdam	sapier, I only have a heart.png with 1:2 aspect ratio and its drawn like 1:1
12:23	sapier	of course
12:23	sapier	they're not meant to be 1:2 but 1:1 only
12:23	PilzAdam	that is not documented
12:24	sapier	it's not documented to not be 1:1000000 too
12:24	PilzAdam	and it was totally valid at the last release
12:24	sapier	it was?
12:24	PilzAdam	I wouldn't have used it if it wasn't
12:24	celeron55	it indeed did work; previously it just drew the images next to each other 1:1 on the screen
12:24	sapier	could have been because of not scaling any items at all in last one ... you have to decide either have fixed size images or have them propperly scaled to gui
12:25	sapier	fixed size is old one
12:25	sapier	you can still use that api
12:25	celeron55	sapier: there's a third alternative: keep their aspect ratio
12:25	sapier	which one?
12:25	sapier	x or y?
12:25	celeron55	well that has to be specified
12:25	sapier	we can do this but I already know someone will complain "but my 1:4 image is too small
12:26	celeron55	probably keep y constant on the screen and stretch the bar based on the x:y ratio of the original image
12:26	sfan5	celeron55: dev. direction of _next: https://gist.github.com/sfan5/4ddc0bdd2f856caa7274
12:26	sapier	I can do everything of this but it's just gonna be someone else to complain instead of Pilzadam
12:27	celeron55	sfan5: so you just focus on being a base for modding?
12:27	sfan5	basically yes
12:27	sapier	btw what's usecase for non 1:1 statbar images
12:27	sapier	?
12:27	celeron55	sfan5: that's not what i am looking for
12:27	PilzAdam	sapier, I dont want half-hearts
12:27	PilzAdam	thats why my image has 2 hearts next to each other
12:28	BlockMen	celeron55, read the second part of first point
12:28	BlockMen	its a continously developed game
12:28	BlockMen	but not by throwing everything in
12:28	celeron55	BlockMen: i would like to have a second document that focuses solely on how you choose "new and useful items/nodes/etc"
12:29	BlockMen	https://gist.github.com/BlockMen/10886992
12:29	sapier	there'd be two ways to fix this, 1) using the proposed new statbar method second, the one that'd work right now too ... implement healthbar on your own
12:29	nore	about adding some progression to the game: technic does that
12:29	BlockMen	its by discussion on ##minetest-next
12:29	sfan5	celeron55: maintainers vote
12:29	sapier	you could copy most of code withing builtin and would just have to adjust the numbers
12:29	nore	but it's quite heavy
12:30	BlockMen	everyone can talk about it
12:30	sapier	and there's a third option too
12:30	BlockMen	but maintainers vote at the end
12:30	sapier	use old api which still behaves as before
12:30	celeron55	sfan5, BlockMen: that's what i feared and that i know won't work unless you have a plan right from this moment
12:30	celeron55	i want to see that plan
12:30	celeron55	the plan for how to choose "new and useful items/nodes/etc" which you are making such a small part of that page
12:31	PilzAdam	sapier, celeron55's suggestion to keep the y-size and aspect ratio seems like the best solution for the healthbar to me
12:31	BlockMen	you only know that it did not work at _game, but you still not know/accept why it did not work
12:32	BlockMen	and concering your plan: everyone has an oppinion on things. the single maintainer decides alone, here we vote
12:32	BlockMen	there is no difference in result
12:32	sapier	I'll have a look but I don't think it's a good idea to do a change like that 24 hours prior release just because someone wasn't able to mention this issue about 4 weeks before
12:33	PilzAdam	sapier, yea, this situation is not ideal
12:33	BlockMen	also, a lightweight game is needed aswell. e.g. android uses next because of that
12:33	celeron55	BlockMen: the issue is, i can't let _next into 0.4.10 if i can't know that it's going to work
12:33	BlockMen	and because its developed
12:33	celeron55	maybe i could see that it works at 0.4.11
12:33	celeron55	but not at this moment
12:33	BlockMen	you have NO prove that it does not work
12:33	sapier	imho it's a addon feature and not a bugfix as old api still works as before
12:33	BlockMen	ppl accept the game (see votes)
12:33	celeron55	if you're sticking to android, it's going to look bad in PC user's eyes so that's wrong too
12:33	celeron55	we need something that impresses PC players
12:34	BlockMen	what? where i said we stick to android?
12:34	celeron55	"a lightweight game is needed aswell. e.g. android uses next because of that"
12:34	sfan5	android uses _next?
12:34	sfan5	TIL
12:34	BlockMen	yes
12:34	celeron55	that's bad; you can't make the flagship game without dropping android
12:34	sapier	yes sfan ... at least for 0.4.10
12:34	BlockMen	and lightweight means not "interesting features)
12:35	BlockMen	well, then its clear. we need carbone AND next
12:35	BlockMen	not OR
12:35	BlockMen	because some pcs needs lightweight aswell
12:35		kaeza joined #minetest-dev
12:36	celeron55	oh god what a mess
12:36	sapier	Pilzadam I can't keep the y size as this would mess up the statbar again, the only way not to skrew up everything would be keeping x aspect
12:36	BlockMen	you had time to develop a good way to choose games
12:36	BlockMen	you didnt, now we have the mess
12:37	celeron55	i'm laughing at myself right now, this is minetest chaos development at it's best
12:37	PilzAdam	sapier, I don't know the exact terminology; does that mean that my 1:2 (2 hearts next to each other) image will be half as high as the normal healthbar?
12:37	sapier	yes that'd be the result
12:38	PilzAdam	:-/
12:38	sapier	sorry but the other way round statbar size would double that's exactly what we intended to fix
12:38	sapier	but as I said you could implement it the way you want it in pure lua too
12:38	sapier	actually it is pure lua
12:39	PilzAdam	how would I do that? isn't the hud API marked as unstable?
12:39	celeron55	so, it turns out, _next really is the undead _game and won't be anything else no matter what
12:40	celeron55	i didn't think there would be this much momentum for essentially the same thing
12:41	PilzAdam	sapier, there is still the question if you broke other texture packs or games
12:41	sapier	no there's nothing broken, everyone using old api will have same as before
12:41	sapier	you switched to new one so you have the new behaviour
12:41	casimir	That people want _next essentially shows that they want _game to be continued. And that is what it does.
12:41	PilzAdam	I don't even use the API
12:42	PilzAdam	I only supply a heart.png
12:42	celeron55	sfan5, BlockMen, nore: how do you plan to interact with carbone and similar things in the future in terms of compatibility?
12:42	sapier	ohh
12:42	sapier	ok so you actually abused a bug as feature ;-)
12:43	PilzAdam	you just dropped support for a good feature
12:44	sapier	not really ... I fixed a bug that caused statbars to not be scaled as it's been in 0.4.5? maybe a little bit earlier
12:44	PilzAdam	sapier, you said you can't keep the y-size because that would make the healthbar too wide, right?
12:44	sapier	yes
12:44	PilzAdam	I only allow half as much hearts, so the width should be same as default
12:45	sfan5	celeron55: compatibility = able to just change the gameid in world.mt and it works?
12:45	celeron55	sfan5: i mean more from the standpoint of modding
12:45	sapier	yes but that'd not change the fact that this hud still has that size
12:45	PilzAdam	does it cause any problems?
12:46	sapier	not in your special case but for others yes
12:46	celeron55	sfan5: of course ideally there would be the opinion from the other side here too but given that it is unknown right now
12:46	sapier	can you have a look at statbars.lua? there's a way how you can do it in a clean way
12:46	sapier	without abuse of features and with clean api
12:46	PilzAdam	sapier, if someone makes a heart texture wider then you would naturally expect the whole bar to be wider too
12:46	sfan5	celeron55: try to keep mods compatible; if not possible discuss with _next maintainers
12:47	sfan5	having mods not compatible with _next wouldn't be good
12:47	celeron55	i am thinking about giving you the _game repository
12:48	celeron55	which means that you are responsible for avoiding nightmares for other games that want to use the same mods
12:48	RealBadAngel	PilzAdam, because no one has asked me to add any "waving" property to water
12:48	PilzAdam	RealBadAngel, you should have done that
12:48	sapier	see the heartbar was broken since lua hud additions because of lack of scaling it, now scaling is added and built in statbar was fixed. what you used was lack of this scaling so basicaly the bugfix breaks your special usecase while it fixes any other one
12:48	RealBadAngel	PilzAdam, i can make that, no problem
12:48	Taoki	RealBadAngel: Hi
12:48	PilzAdam	RealBadAngel, then go ahead
12:49		LemonLake joined #minetest-dev
12:49	sapier	Especially as there is a way to do what you want with current api I don't really think we should do some strange hacks to partially reenable non scaling images
12:50	Taoki	RealBadAngel: I wanted to ask when we could look at that flickering issue some more please. I still get it any it's any annoying effect
12:50	sfan5	celeron55: could you give me an example of what I'd do?
12:50	celeron55	PilzAdam, RealBadAngel: why can't that be just a user setting?
12:50	RealBadAngel	PilzAdam, water stuff will be changed a lot after 0.4.10
12:50	celeron55	PilzAdam: the engine decides a lot about how to show liquids anyway
12:50	sapier	maybe we find a clean way to do it on thinking about it a while but I don't wanna rush this into 0.4.10 pilzadam
12:50	RealBadAngel	we had a conversation about water and waving
12:50	Taoki	I wonder if it can be fixed before 4.10. The shader issue I mean
12:51	celeron55	PilzAdam: it already is a user setting, i mean
12:51	PilzAdam	celeron55, waving water doesn't make any sense in Nodetopia, where water is basically a cube in which you can swim
12:51	celeron55	umm
12:51	celeron55	why is it waving then?
12:51	celeron55	when it is not a liquid
12:51	celeron55	is this hardcoded or something stupid like that?
12:51	RealBadAngel	there was an idea to split water into two kinds
12:51	RealBadAngel	ocean and lake/river like
12:51	celeron55	RealBadAngel: how does the engine decide what waves and what does not?
12:51	sfan5	celeron55: RBA hardcoded some check for nodename == "default:water_source" somewhere
12:52	celeron55	oh my god
12:52	PilzAdam	celeron55, apparently the waving applies to all nodes that are liquids; and I need to make my "water" liquid so I get the physics of swimming
12:52	celeron55	remove that right now
12:52	RealBadAngel	sfan5, not really
12:52	sfan5	no?
12:52	* Taoki	disagrees with hard-coding node names too
12:52	PilzAdam	sfan5, my water is called "base:water"
12:52	RealBadAngel	such code is there, but its temporary
12:52	sfan5	I already brought that up 1 week ago
12:52	RealBadAngel	and used for something another
12:52	sfan5	that doesn't make it acceptable
12:52	RealBadAngel	ofc not
12:52	celeron55	RealBadAngel: say the file and line, now
12:52	PilzAdam	RealBadAngel, wait wait wait; you want that code to be in a release?
12:53	sfan5	celeron55: ngel> such code is there, but its temporary
12:53	sfan5	*
12:53	sfan5	damnit
12:53	LemonLake	whoa
12:53	sfan5	https://github.com/minetest/minetest/commit/6c98fd6658fcf7c0c676ee88f03e364c852e9f1b#commitcomment-6672665
12:53	sfan5	^ celeron55
12:53	celeron55	this kind of stuff is exactly why i hate RBA
12:54	RealBadAngel	ofc, i wanted a clean way, strict, to enable the surface shader
12:54	LemonLake	don't hate rba :(
12:54	celeron55	i hate RBA.
12:54	RealBadAngel	which is the very same as nodes shader atm
12:54	celeron55	fix that shit, there are probably 100 better ways of deciding whether something should have waves
12:54	RealBadAngel	celeron55 i told that in chan already
12:54		us`0gb joined #minetest-dev
12:54	Taoki	celeron55: RBA does very good code. Saying that is too much IMO
12:54	RealBadAngel	celeron55, please do read what i say
12:55	RealBadAngel	that code has nothing to do about waving
12:55	LemonLake	maybe a group? just like the wavy group or whatever
12:55	RealBadAngel	its a surface shader
12:55	celeron55	RealBadAngel: so how does the thing decide whether something has waves?
12:55	sfan5	LemonLake: not a group, but an attr. in the nodedef
12:55	LemonLake	leaves/grass had their own group to decide whether they should wave
12:55	LemonLake	that too
12:55	celeron55	nodetopia's water does not flow
12:55	Taoki	I also do not think it is helpful to talk about hating other devs that way. Such issues can be solved professionally and by discussing them
12:55	celeron55	that should make it now have waves
12:55	LemonLake	+Taoki
12:55	celeron55	not*
12:55	Taoki	But yes, hardcoded node names aren't something I support. I hope another way to do that can be found
12:55	LemonLake	just do the same thing you did with leaves ^.^
12:56	RealBadAngel	yes, we need some new methods
12:56	RealBadAngel	ocean should wave, rivers shouldt
12:56	celeron55	nodetopia shouldn't need any new flags or properties for doing it
12:56	RealBadAngel	problem was how to connect those two
12:56	Taoki	I agree with all water waving myself
12:56	Taoki	IMO it needs to be a node option entirely.
12:56	BlockMen	celeron55, concering your last question we agreed on: "we keep campatibility to _game in general and decide adding other things for compatibility on request by users" (e.g. for carbone)
12:57	LemonLake	if you wanted a really complicated shader, do it based on whether it's surface water or not
12:57	celeron55	BlockMen: but if you are _game, what does that mean
12:57	RealBadAngel	by now waving is for all the liquids in general
12:57	celeron55	do you keep compatibility to this day's version of _game?
12:57	BlockMen	and all future bugfixes of _game
12:58	RealBadAngel	celeron55, and about default:water 0 tile
12:58	LemonLake	"This XCF is corrupt!"
12:58	LemonLake	fml
12:58	RealBadAngel	i need to make it very special, since there will be reflections, refractions, sun etc
12:58	celeron55	Taoki: that has the issue that if some user wants water to have waves, the user should get what he wants even if the subgame developer didn't want waves, because waves are just visual
12:59	LemonLake	true that ^
12:59	Taoki	yeah
12:59	LemonLake	why not some sort of config?
12:59	RealBadAngel	and any other node cant have such unique attributes, neither the rest of the tiles
12:59	celeron55	maybe there should be three options
12:59	celeron55	"no waves", "waves if game wants them" and "waves always"
12:59	Taoki	Can even be a general property of liquid nodes. Though personally I'd make it a node setting
12:59	RealBadAngel	Taoki, general "no way"
12:59	celeron55	actually, this is exactly how it should work
13:00	celeron55	there is an option for everybody
13:00	RealBadAngel	beause of extra rendering passes needed
13:00	celeron55	(from the user's perspective)
13:00	Taoki	Ok. A node setting sounds good to me really. With of course the client setting to allow disabling waves at all
13:00	Taoki	If it's a node setting, even solid nodes could use it. To make something jelly-looking that you can walk on
13:00	RealBadAngel	we need to set the camera looking up, then lookin down
13:00	Taoki	That's the type of implementation I'm a fan of personally... something flexible
13:00	celeron55	RealBadAngel: i agree for a special property for ocean nodes
13:00	RealBadAngel	then combine those 3 passes
13:01	celeron55	but not if it is doable without a property
13:01	sapier	what about mentioning that issue as "known issue" in release notes and change it later?
13:01	Taoki	Also, if we want to separate oceans from lakes, I'd suggest different water nodes. We could have default:water and default:salt_water. Of course, only MGV7 could use different waters per biome
13:01	RealBadAngel	celeron55, problem was i needed to assure that just for the very special tile of water
13:01	RealBadAngel	only the top
13:01		Amaz_ joined #minetest-dev
13:02	celeron55	can't you figure out from checking out what the environment contains?
13:02	RealBadAngel	i couldnt make that before
13:02	celeron55	it would be awesome to have oceans work anywhere on any level
13:02	RealBadAngel	hmm]
13:02	RealBadAngel	for that you should calculate average ocean level
13:03	celeron55	anyway this isn't 0.4.10 stuff
13:03	RealBadAngel	and choose it for clipping
13:03	RealBadAngel	otherwise refelections will be broken
13:03	Taoki	RealBadAngel: Can you make the waving property possible for all nodes and drawtypes really? I know it's mostly intended only for water plants and leaves, but making it fully general would allow for many and any ideas really :)
13:04	RealBadAngel	taoki, ofc i can make it, but as i said, we planned to split the water into kinds, waveable or not
13:04	Taoki	eg: Someone could make a magic biome where the ground wavers, by using a special default:dirt_with_grass node (named diferently of course)
13:04	Taoki	ok. That's something I'd rather the person who defines the node decides
13:04	RealBadAngel	but no one had an idea hot to graphically connect those two
13:05	RealBadAngel	waving oceans and the channels/rivers/lakes
13:05	celeron55	you need to somehow store a flag in the vertex or something
13:05	sapier	don't we have enough issues relevant for 0.4.10 right now? we can't do a major change in node definitions for this version anyway ;-)
13:05	Taoki	One can't really know if a water pool is an ocean or not. Unless oceans use a different water node, IIRC possible with v7
13:06	* Taoki	agrees with sapier there
13:06	RealBadAngel	we can Taoki
13:06	RealBadAngel	at map generation time
13:06	sapier	no we can't without delaying 0.4.10 for at least two weeks
13:06	RealBadAngel	so we can define oceans
13:06	Taoki	Possibly. But it feels potentially complex and maybe more trouble than it's worth. Water should always waver perhaps... I dunno
13:06	RealBadAngel	im talkin about how it should be done
13:07	RealBadAngel	not that it should be coded on a knee and merged
13:07	Taoki	yeah, likely not now
13:07	sapier	ok and I'm talking about 0.4.10 in case someone forgot we intended to release it tomorrow ;-)
13:07	RealBadAngel	celeron55, btw, heres the code:
13:07	Taoki	RealBadAngel: The mapgen can generate any large pool of water though. Each mapgen would need to be modified to recognize oceans individually. I'm not sure if this is a good idea just for the waver effect
13:08	RealBadAngel	https://github.com/RealBadAngel/terrainTest
13:08	celeron55	sapier, sfan5, BlockMen and other people interested about 0.4.10 release: #minetest-0.4.10
13:08	RealBadAngel	it does clipping for rendering passes
13:09	RealBadAngel	and generates all the textures needed
13:10	RealBadAngel	Taoki, its not just about waving, it will extend also for liquid being able to reflect the landscape and sky
13:10	Taoki	RealBadAngel: Reflections are also a thing I personally believe should be a node property, not automatically decided like that
13:10	RealBadAngel	thats why i made the water_surface_shader very special one
13:11	RealBadAngel	Taoki, ofc, you may think so
13:11	Taoki	Reflections should be defined in nodes IMO. Not just for liquids also... for example iron blocks could use it to be shiny
13:11	RealBadAngel	but mt wont be played on nasa mainframes to have such feature lol
13:12	Taoki	Ok. I just think it should be the author's choice entirely
13:12	Taoki	If someone abuses reflections of course, that's their problem, and their game's / mod's
13:12	RealBadAngel	because your approach would mean new rendering pass for every single node face you have chosen to have reflections
13:13		us`0gb joined #minetest-dev
13:13	Taoki	Hmm... that I don't know. I assumed it would be the same for any water node too
13:13	LemonLake	In water, you just want to reflect the top
13:13	RealBadAngel	no
13:13	RealBadAngel	with water we choose the level of the liquid
13:13	Taoki	Ah. Reflections won't work for flowing water then? That could look strange
13:13	RealBadAngel	clip it, lookin up
13:13	LemonLake	^
13:13	* Taoki	nods
13:14	RealBadAngel	then we have a texture seen from below
13:14	Taoki	Yeah, that makes sense... could be a property that might only work for water then
13:14	RealBadAngel	now with the same clipping we look dow
13:14	LemonLake	As for flowing water, it would be a bit different
13:14	RealBadAngel	*down
13:14	RealBadAngel	to get image of whats underwater
13:14	Taoki	Still, I don't agree with coding a special mechanism to detect oceans and make mapgens mark them as such only for this. If it's a liquid property, I believe it should apply to all liquid nodes
13:14	RealBadAngel	and then we do lotsa physics to show it properl
13:14	Taoki	If anyone wants a different behavior for oceans, we could make oceans use their own water node
13:14	LemonLake	I agree.
13:14	Taoki	eg: default:salt_water
13:15	LemonLake	Then just use an alias.
13:15	Taoki	Can have different waving and different reflection texture
13:15	LemonLake	No, it should always be the same, that just adds unneeded complication
13:15	celeron55	then if you have a salt water cave the water waves and shines in the sun?
13:15	Taoki	ok. Was thinking of allowing nodes to specify the amount of reflectivity and waving. After all, lave for example would have much less reflectivity if at all
13:16	celeron55	doesn't sound right to m
13:16	celeron55	+e
13:16	Jordach	just make all reflective objects the same, ignoring the facts
13:16	Taoki	Salt water would prolly be used for oceans only
13:16	LemonLake	Why not check the light level of the water?
13:16	celeron55	it has to be simplye ocean_surface_water or something similar because it doesn't make any sense otherwise
13:16	Taoki	Yeah, that might not be wanted behavior
13:16	celeron55	-y
13:16	LemonLake	That would be more realistic
13:16	Taoki	celeron55: +1
13:16	celeron55	+y-e
13:16	LemonLake	If it's dark, no reflections
13:16	LemonLake	If its max light, full reflection
13:16	Taoki	yes. Reflection intentisy could depend on light level. Makes a lot of sense
13:16	RealBadAngel	https://www.youtube.com/watch?v=181tdHyFUWU
13:16	Taoki	RealBadAngel: Does that sound like a good idea?
13:17	RealBadAngel	watch the shader
13:17	RealBadAngel	this is the one i want in
13:17	Taoki	RealBadAngel: Yep, that looks beautiful! Only question is how to do it most right
13:17	Taoki	Oh, and BTW...
13:17	Taoki	If you want to make waving realistic, there is another way
13:18	RealBadAngel	the shader works, i just need textures. relfection and refraction one
13:18	Taoki	We could check how close the water node is to a solid node, and specify a distance. Depending on how costly it is
13:18	Taoki	So if a water node touches a solid node on the sides, no waving. When it's let's say 10 nodes away from one, full waving
13:18	Taoki	And everything in between
13:18	LemonLake	That would be a lot of processing
13:18	Taoki	That would fix the oceans issue too. Only large pools of water would have full waving
13:18	Taoki	Yeah, I guess...
13:19	LemonLake	Also, it'd result in desync in an ocean
13:19	Taoki	A flag could be used here though. So this is only calculated once when nodes are placed / dug
13:19	Taoki	No... it could be updated whenever a node is modified
13:19	Taoki	So it would always reflect reality
13:19	LemonLake	No, I mean
13:19	LemonLake	full waviness / no waviness
13:19	LemonLake	that's 10 levels of waviness, yes?
13:20	RealBadAngel	https://www.youtube.com/watch?v=hubBBzh_190
13:20	LemonLake	a node that's on 4 waviness and another that's on 5
13:20	Taoki	10 could be a good idea yes
13:20	Taoki	Sure
13:20	LemonLake	their refractions would be offset
13:20		Amaz_ joined #minetest-dev
13:20	Taoki	Aaah. No, I was thinking that the waviness effects could be combined
13:20	LemonLake	Again, that's a lot of processing
13:20	Taoki	Of course we woudn't want the surfaces to cut off and wave out of sync
13:20	RealBadAngel	Taoki, see the vid
13:20	LemonLake	RBA: That's good, but I think I've seen that vid before
13:20	LemonLake	did you show it about 2 months ago?
13:21	RealBadAngel	it combines vawing (geometry) and normal mapped surface
13:21	Taoki	Yep, looks awesome
13:21	RealBadAngel	LemonLake, it wasnt possible before
13:21	RealBadAngel	now it is, because each tile can have own shaders
13:21	LemonLake	Ah wait
13:21	Taoki	Either way, if waving intensity can't be changed based on how large the pool of water is, I'd suggest letting it be the same everywhere like it's the case currently
13:21	LemonLake	I remember you showing the same vid in this chan a while back, that's all
13:21	Taoki	It really doesn't look bad to me if a single block of water waves
13:22	Taoki	Maybe a little unrealistic, but it's fine
13:22		casimir joined #minetest-dev
13:22	RealBadAngel	and now you can see, why theres so hardcoded water surface
13:22	Taoki	RealBadAngel: Yes. But by hardcoded water, I don't mean hardcoding "defaukt:water", but all liquid nodes in general
13:22	Taoki	Since after all it's just a liquid property then
13:22	casimir	Updated description for your reading (What is this game about & Features): https://forum.minetest.net/viewtopic.php?f=15&t=6346
13:22	casimir	^ celeron55
13:23	RealBadAngel	ofc thats gonna change
13:23	Taoki	ok. Sounds all good to me then :)
13:23	RealBadAngel	but i delayed that because we need to make very tough decisions
13:23	Taoki	RealBadAngel: BTW. Will the water only have reflections, or will there also be refraction? With added refraction it would look so beautiful!
13:23	RealBadAngel	so, opened the door, but made it default by now
13:24	RealBadAngel	Taoki, yes
13:24	Taoki	Awesome!
13:24	RealBadAngel	water gonna be VERY special tile
13:24	RealBadAngel	it wont even have a texture ;)
13:25	RealBadAngel	all there is done with math
13:25	Taoki	Hmmm. Not sure about that entirely. Maybe allowing a texture too can be useful. But you know best if that's possible or not
13:25	Taoki	For example, one would still want the ability to colorize water at least
13:25	RealBadAngel	for that you can define scolor
13:25	LemonLake	you can have a diffuse texture
13:26	Taoki	So if someone wants to add a node for toxic waste, they can make it green
13:26	Taoki	ok, great then!
13:26	LemonLake	at least give it some sort of texture to keep the feel
13:26	RealBadAngel	and make purple water
13:26	LemonLake	just render the reflections on top of it
13:26	LemonLake	default water texture just be white
13:26	Taoki	LemonLake: I'd suggest the same... but as long as it's possible only
13:26	RealBadAngel	LemonLake, see the vawes in the vid?
13:26	Taoki	Don'w want to ask for more than there can be
13:26	LemonLake	yes
13:26	RealBadAngel	theyre made with normal map
13:27	LemonLake	are they refractions?
13:27	LemonLake	oh
13:27	RealBadAngel	distortion to the surface
13:27		Amaz_ joined #minetest-dev
13:27	RealBadAngel	also, they do have unique attributes
13:27	Taoki	RealBadAngel: Also, will the reflections be realtime, or cubemap? Realtime could be nice, but very very costly. Maybe a cubemap can be auto-generated once every second for instance... many engines do that to get reflections at a good FPS
13:27	RealBadAngel	they do care about wind: speed, force and direction
13:28	Taoki	So for each player, the cubemap is generated at their camera's position, once every X seconds (where X can be a setting)
13:28	RealBadAngel	but currently engine lacks to give the shader actual values
13:28	Taoki	That way, allowing reflections on all types of nodes and in any direction would also be easy and cheap. I think...
13:28	LemonLake	why not just have an extra camera
13:28	LemonLake	per-block, but only in the blocks you're in + surrounding
13:29	LemonLake	have a very high fov
13:29	Taoki	Or, the sky itself could simply be the cubemap. But then water won't reflect either entities nor nodes
13:29	Taoki	Still it could reflect sun and moon
13:29	RealBadAngel	https://github.com/RealBadAngel/terrainTest
13:29	RealBadAngel	read the code
13:29	RealBadAngel	and see whats needed
13:29	RealBadAngel	its irrlicht based example
13:30	RealBadAngel	so the code needed is pretty the same for us
13:30	* Taoki	nods
13:32	RealBadAngel	the example has also one neat feature, shader material
13:32	RealBadAngel	too bad its not useable for us ;)
13:33	RealBadAngel	i have chosen to go very different way, and specialize the shaders
13:33	RealBadAngel	theyre precompiled now for each and every drawtype used
13:33	Taoki	Awesome
13:33	Taoki	That sounds good yes
13:34	RealBadAngel	you can definde ladders shader if you want to
13:34	Taoki	RealBadAngel: BTW. There's something else I really wanted to know about. Any idea when post-processing shaders will be possible? So we can add bloom, depth of field, etc
13:34		diemartin joined #minetest-dev
13:34	RealBadAngel	ofc
13:34	RealBadAngel	thats the next step
13:34	Taoki	Great!
13:35	RealBadAngel	if we will have rendering passes for water
13:35	RealBadAngel	it will mean we do have rendering passes at all
13:35	RealBadAngel	its almost the same code
13:36	RealBadAngel	now, thx to shaders unite, you can set the shader for the very special tile
13:36	RealBadAngel	another one
13:36		Amaz_ joined #minetest-dev
13:36	RealBadAngel	not the water surface, or any other node, but the rendered world
13:37	RealBadAngel	and then you can make with it whatever you want
13:38	Taoki	Sounds good yes
13:39	RealBadAngel	godrays, hue/saturation/contrast adjust/ lens flares/ shadows
13:39	RealBadAngel	name the idea
13:39	RealBadAngel	most funny, the most shaders will work out of the box
13:39	Taoki	Yeah, and I guess I was wondering one more thing. Maybe, until we can add real dynamic lighting sometime, it would be easier to allow directional lights to work already... at least with shaders. I mean, couldn't we brighten / darken faces based on sun / moon direction all the time?
13:39	RealBadAngel	i mean copying them from nvidia site, and just renaming the files
13:39	Taoki	Since we use voxels and blocks, so we know the direction of each face
13:40	RealBadAngel	Taoki, lights are another problem to discuss
13:40	RealBadAngel	because we do need 2 light systems
13:41	Taoki	true
13:41	RealBadAngel	one, to support real light sources (made by irrlicht)
13:41	RealBadAngel	and ours, to get light level at pos
13:42	RealBadAngel	the second will have to run server side
13:42	Taoki	yeah
13:42		Anchakor_ joined #minetest-dev
13:42	RealBadAngel	for that we will have to trash most of the lighting code
13:42	RealBadAngel	including smooth lighting
13:42	RealBadAngel	and leave just light level calcs
13:43	RealBadAngel	then we have to let real lighting be done client side
13:43		Amaz_ joined #minetest-dev
13:43	RealBadAngel	by irrlicht engine
13:43	Taoki	Smooth lighting needs to work when this is off, since existing behavior must remain possible
13:43	Taoki	Wow... can't even imagine how cool it will be when we'll have graphics like Terasology :)
13:43	RealBadAngel	i dont think so
13:44	RealBadAngel	light is serious problem for servers
13:44	RealBadAngel	it SHOULDNT be done that way
13:44	RealBadAngel	no matter what
13:44	Taoki	I know. But some old hardware can't handle dynamic lighting
13:45		kaeza joined #minetest-dev
13:46	RealBadAngel	if its capable of running Irrlicht, it will
13:46	RealBadAngel	no matter its sapier's watch, a fridge or pc
13:47	RealBadAngel	ILightSceneNode* light1 = scenemanager->addLightSceneNode( 0, core::vector3df(0,400,-200), video::SColorf(0.3f,0.3f,0.3f), 1.0f, 1 );
13:47	sapier	watch?
13:47	Taoki	I... guess. But if you plan to remove the entire lighting system entirely, you'll have to convince celeron55 and the other devs... which I don't think will be very easy
13:47	RealBadAngel	just put such code inside game.cpp somwhere, renaming scenemanager to smgr
13:48	RealBadAngel	sapier, that was you with a video of watch running mt :P
13:48	sapier	ahhh actually it's been someone else but I postet it :)
13:49	Taoki	It's fine by me of course. I consider the existing lighting system a horrible hack... using vertex colors to simulate brightness
13:49	RealBadAngel	Taoki, and in mapblock_mesh.cpp you need to enable ligthing for materials
13:49	RealBadAngel	setMaterialFlag(EMF_LIGHTING, true);
13:49	* Taoki	nods
13:49	RealBadAngel	and then, FIAT LUX ;)
13:53	RealBadAngel	shaders are already aware of main light source
13:53	RealBadAngel	the sun
13:54	Taoki	Direction too?
13:54	* sfan5	meows at RealBadAngel
13:54	RealBadAngel	https://github.com/minetest/minetest/blob/master/client/shaders/nodes_shader/opengl_vertex.glsl#L62
13:54	RealBadAngel	we need to define sun position in world just
13:55	RealBadAngel	by now shaders assume that it is 90 nodes above the player all the time
13:56	RealBadAngel	if we will move it, with time of day, shader will change the look of the game completely
13:56	Taoki	nice
13:56	RealBadAngel	because shading will become dynamic
13:58	RealBadAngel	http://i.imgur.com/hDpesVA.png
13:58	Taoki	Any chance of seeing this or water during this summer vacation? Sorry just sounds too awesome and I'm curious :)
13:58	RealBadAngel	at this image, light source is in the center
13:58	RealBadAngel	see the shadows
13:59	RealBadAngel	Water is almost done
13:59	RealBadAngel	im waiting for 0.4.10 to be released, then i will pull the code
14:00	Taoki	Awesome. That's tomorrow so yeah
14:00	RealBadAngel	even that picture with proper hardware lights is 4 months old already ;)
14:00		vifino joined #minetest-dev
14:01	RealBadAngel	but definitely i wont be able to do it just on my own
14:02	RealBadAngel	server side code has to be changed
14:02	RealBadAngel	sun postion added
14:02	RealBadAngel	grouping articfical light sources (nearby) for rendering
14:02	RealBadAngel	add rendering passes
14:03	RealBadAngel	allow postprocessing
14:03	RealBadAngel	lotsa to be done
14:04	RealBadAngel	also, mapblock_mesh has to be revamped a bit
14:05	RealBadAngel	we have to get rid of transparency issues
14:05		Amaz_ joined #minetest-dev
14:08	RealBadAngel	atm using one transparent material practically excludes usage of another, idk why
14:08	RealBadAngel	the second one is just invisible
14:08	Taoki	Ah... didn't know that was the case. Yeah it sounds wrong
14:09	RealBadAngel	"thx" to that water is fucked up for example
14:19		hmmmm joined #minetest-dev
14:41		sapier joined #minetest-dev
14:58		blaise joined #minetest-dev
15:02		Calinou joined #minetest-dev
15:13		vifino joined #minetest-dev
15:13		sapier joined #minetest-dev
15:36		us`0gb joined #minetest-dev
15:39		Megaf_ joined #minetest-dev
15:54		Kray joined #minetest-dev
16:09		Megaf joined #minetest-dev
16:33	Calinou	I read IRC logâ€¦ about this: http://irc.minetest.ru/minetest-dev/2014-07-05#i_3795328 â†’ I'm not against progression, but not when it puts stupid restrictions on people to make them waste time
16:34	Calinou	I like games I can play with limited time better, this is also why eg. digging and moving are faster
16:34	Calinou	http://irc.minetest.ru/minetest-dev/2014-07-05#i_3795337 â†’ woah, Minecraft's well balanced now? I doubt it :p
16:35	Calinou	http://irc.minetest.ru/minetest-dev/2014-07-05#i_3795339 â†’ I think there was player-player collision for a short moment, but I'm not sure; probably removed because it was annoying or people abused it
16:35	Calinou	(enable only if pvp is enabled?)
16:36	Calinou	http://irc.minetest.ru/minetest-dev/2014-07-05#i_3795354 â†’ nope! goes against flat design principle, increases file size. However, a nice textured crosshair is used by default in Carbone, which is also visible on all surfaces since it's outlined.
16:38	Calinou	http://irc.minetest.ru/minetest-dev/2014-07-05#i_3795413 â†’ many people who run the servers are ridiculously irresponsible and may cram different mods that do the same thing (frequently seen with mob or ore mods)
16:39	RealBadAngel	whats your point Calinou ?
16:41		zat joined #minetest-dev
16:43		werwerwer_ joined #minetest-dev
16:52		Piggybear87 joined #minetest-dev
16:52		Piggybear87 left #minetest-dev
16:57		casimir joined #minetest-dev
17:16		grrk-bzzt joined #minetest-dev
17:29		sapier1 joined #minetest-dev
17:58		alexxs joined #minetest-dev
17:59	sapier1	hmmmm you do know mapgen best, what could cause dirt and trees to (re)-grow constantly
18:08	hmmmm	in mapgen v6?? mud flow from newly generated chunks
18:10	hmmmm	set mgv6_spflags to nomudflow
18:10	sapier1	isn't that default?
18:10	hmmmm	mudflow is default
18:11	sapier1	ok I'll try if this fixes it we may be able to release a android singleplayer supporting version
18:11	hmmmm	the [M]ap[G]en [V6] [SP]ecific [FLAGS] are set to biomeblend and mudflow by default
18:11	hmmmm	setting mgv6_spflags = nomudflow preserves the rest of the flags, just unsets the mudflow bit
18:12	Calinou	thanks for shortening section tags on GitHub issue tracker :)
18:13	celeron55	sapier1: the flag shouldn't make them re-grow constantly though
18:13	sapier1	can I change this in a existing world hmmmm?
18:13	celeron55	only after generation, and never again in the same location
18:13	sapier1	it happens over and over again on android version
18:13	hmmmm	yes
18:13	hmmmm	but it's going to cause inconsistency in map generation between the previously generated chunks and the newly generated chunks
18:14	sapier1	I wonder why noone reported that by now
18:14	hmmmm	that is why i discourage it
18:14	sapier1	well the map generated is already messed up due to mud overflow ;-)
18:15	sapier1	any idea why this happens about any 30s ?
18:15	hmmmm	30 seconds??
18:16	hmmmm	THAT sounds like a mod problem
18:16	sapier1	strange thing is it doesn't happen on pc with same game
18:16	sapier1	or better good thing
18:16	sapier1	disabling mud flow helps
18:17	sapier1	guess I'm gonna add this workaround but we have to find the underlying error
18:20	hmmmm	I wonder if it could have something to do with synchronization between multiple emerge threads
18:21	hmmmm	make sure you don't have num_emerge_threads set to something other than 1
18:21	BlockMen	btw hmmmm, i noticed that mapgen places a second layer on generated terrain when i modified it with voxelmanip, e.g. the snowcaps in wasteland
18:21	hmmmm	if that field is present but blank, it'll autoselect the number of threads based on the processor count
18:22	hmmmm	yes blockmen, that's the same mudflow
18:22	BlockMen	ok
18:22	hmmmm	I really dislike features of v6 that modify neighboring chunks on generation
18:23	BlockMen	good to know how to fix now :)
18:23	hmmmm	this is a reason why we would possibly want to switch to 3d perlin noise generated caves
18:27	sapier1	android uses same config as pc version so I'd expect it to have same number of emerge threads
18:28	hmmmm	maybe i goofed up and there's still some sort of number of emerge threads configuration problem
18:28	hmmmm	could you check to make sure there is no more than one emerge thread?
18:30	sapier1	yes I'll check
18:32		sapier1 joined #minetest-dev
18:37	BlockMen	nomodflow does not fix the android bug for me
18:37		vifino joined #minetest-dev
18:38	sapier1	not?
18:38	sapier1	:-/
18:39	hmmmm	probably because he set it in the main configuration file and then tested an existing world
18:39	hmmmm	sometimes, I wonder if world configuration persistence is a mistake because people expect it to behave differently
18:39	BlockMen	no, i changed in map_meta.txt on existing world, on new world and new world after adding flag in .conf
18:40	BlockMen	it was always same result (and it was always set nomudflow in map_meta.txt)
18:40	sapier1	let me try again maybe I wasn't patient enough to see it happeb
18:41	BlockMen	also, does mudflow explain growing trees?
18:42	hmmmm	perhaps the mapblock isn't being marked as existing yet it already exists in memory
18:42	sapier1	but shouldn't it be completely regenerated in this case?
18:42	hmmmm	so it goes to generate the chunk, puts what's already existing in the MMVM, it generates the rock and all those features based on absolute y position
18:43	hmmmm	but then the mud is positioned based on relative height since it scans downward for the surface
18:43	hmmmm	and then of course, trees are spawned on the ground level that is found from the downward probe
18:44	BlockMen	sounds reasonable
18:44	hmmmm	this explanation accounts for all the details you described
18:44	sapier1	blockmen my single dirt needle is there for about 5 min now
18:45	BlockMen	then only the question why it only appears on android
18:45	hmmmm	synchronization is one thing to take a close look at
18:45	BlockMen	sapier, umm...it gets more and more weird
18:46	BlockMen	i just checked again, spflags clearly says nomudflow
18:47		EvergreenTree joined #minetest-dev
18:48	sapier1	wtf
18:48	sapier1	I'm in game but there are 5 async tasks left
18:48	sapier1	but only a single emerge thread so this can't be a sync issue
18:49	sapier1	blockmen can you check your nomudflow setting?
18:50	BlockMen	[20:46] BlockMen: i just checked again, spflags clearly says nomudflow
18:50	sapier1	that's crazy
18:50	sapier1	why does it work for one but not for someone else?
18:50	BlockMen	and just tested ingame again
18:50	BlockMen	its reset again
18:50	hmmmm	i wonder if it could be memory corruption
18:51	sapier1	I'd not be surprised but why should nomodflow work for someone and not for someone else?
18:52	BlockMen	wait, im not 100% if its just reset by lag or not
18:52	* BlockMen	testing it again
18:52	BlockMen	no, not by lag :\
18:53	sapier1	you did exit mintest in between?
18:53	BlockMen	between digging and regeneration?
18:53	BlockMen	no
18:53	BlockMen	between editing flags
18:53	BlockMen	yes
18:53	BlockMen	also forced kill
18:54	sapier1	so where's the difference
18:54	BlockMen	huh?
18:55	sapier1	why does it work for me and not for you ... and why does it happen at all ;-)
18:55	hmmmm	well finding the problem on one person's machine would be a good start
18:55	sapier1	did you just remove mudflow or change it to nomudflow?
18:56	BlockMen	changed it to nomodflow
18:56	BlockMen	srsly, sapier?
18:56	hmmmm	he said it has "nomudflow" in mgv6_spflags in map_meta.txt
18:56	hmmmm	that's a definite sign that the flag is present during execution
18:56	sapier1	sorry that's just crazy
18:56	BlockMen	*s/o/u
18:56	hmmmm	sapier, it might not be, we have no idea what's crazy or not until the problem is located
18:57	hmmmm	in any case you're going to have to debug deeper
18:57	BlockMen	and we need more who test it
18:57	sapier1	any idea where to start looking? ;-)
18:57	BlockMen	50:50 is not best result
18:57	hmmmm	i'd start setting printfs in MapgenV6::makeChunk that prints out the node_min and node_max of the block being generated
18:57	hmmmm	see if any chunks are overlapping or are identical
18:59	hmmmm	well, chances are that the reason why you and blockmen are seeing different behavior is caused by a property of the underlying bug
18:59	hmmmm	e.g. memory corruption
18:59	hmmmm	my bets are 70% on memory corruption
19:00	sapier1	any other bets?
19:00	hmmmm	the other 30% is unknown
19:01	sapier1	at least it's no random memory corruption
19:07	BlockMen	hey, ho http://irc.minetest.ru/minetest/2014-07-05#i_3796855
19:08	sapier1	well hard to tell if this is a missing save or this issue
19:10	hmmmm	it can't be a missing save because this overgeneration is happening within the same session of minetest
19:10	hmmmm	if the block exists, it exists in memory. the emergethread won't continue with generation if it finds it in memory first.
19:12	* BlockMen	still looks at 8ad8376
19:13	sapier1	feel free to check it I've already checked at least 10 times I wont find a bug in there on checking another time (even if it is there)
19:14	sapier1	but as this commit causes a lot of performance improvement it may cause the issue due to different timings
19:14	sapier1	the original one basicaly was same as adding sleep(some_time_dependent_on_area_size)
19:15	BlockMen	that could be a reason
19:16	BlockMen	and would also explain why i might still experience that issue
19:16	sapier1	I'd consider this as trigger not as reason
19:16	BlockMen	(since my device is slower)
19:16	sapier1	what device are you testing this at?
19:16	BlockMen	galaxy s+
19:16	sapier1	does it work now?
19:17	BlockMen	no?
19:17	BlockMen	oh..you ment mit at all
19:17	BlockMen	yes, im using cyanogenmod
19:17	BlockMen	+
19:17	sapier1	ahh :-)
19:17	BlockMen	*now
19:18	sapier1	yes that's really slower
19:18	BlockMen	but 10x faster than 2.3.6^^
19:18	sapier1	maybe that issue is in there forever and just occurs on slow devices
19:18	BlockMen	might be
19:18	BlockMen	and disableing mudflow is enough for your device
19:19	sapier1	no that piece doesn't really fit
19:19	sapier1	it should be fixed for you too if this was only one bug
19:19	BlockMen	doesnt mudflow slow down?
19:48	sapier1	hmmmm you're right there are chunks generated multiple times
19:49	sapier1	in all variations overlapping non overlaping identical
19:49	hmmmm	ooookay
19:49	hmmmm	then you know the cause of the symptom
19:49	hmmmm	so now why is emergethread queueing up identical blocks?
19:49	hmmmm	because it's not finding them in Map
19:50	sapier1	how could that be?
19:50	hmmmm	getMapBlockNoEx is failing somehow when it goes to check its presence, however it is not failing when the VoxelManipulator loads up the area
19:51	hmmmm	I can't help but wonder if this is caused at least in part by your optimization
19:51	hmmmm	or rather, changing the emerge to addArea
19:51	sapier1	hmm I did remove some asserts there in a function that could return null too
19:51	sapier1	and sometimes did return null
19:51	sapier1	maybe the assumption that null is a valid return case was wrong
19:52	sapier1	well I removed the null to as noone ever evaluated the return code too
19:52	sapier1	let me find the comit
19:54	sapier1	https://github.com/minetest/minetest/commit/9d57413af007ae952f08bf1130ee60da472c1099
19:56	hmmmm	well
19:56	sapier1	maybe that "fix" wasn't complete
19:56	hmmmm	I see the part at the end of finishBlockMake where you simply return the block at blockpos_requested
19:56	hmmmm	that is ineffectual though
19:56	hmmmm	you could remove that statement entirely
19:57	hmmmm	(you need to realize that finishBlockMake is 80% celeron's original code)
19:57	sapier1	well I wasn't sure what this function does so I didn't remove it
19:58	sapier1	is this right area?
19:59	hmmmm	again, I have no idea what could cause that to happen
19:59	hmmmm	looking around a bit more...
19:59	hmmmm	perhaps you should enable mapgen debug output
20:00	sapier1	where to do?
20:00	hmmmm	see if oyu get "not in meory, attempting to load from disk" stuff
20:00	hmmmm	in the config
20:00	hmmmm	enable_mapgen_debug iirc
20:00	sapier1	ok
20:00	hmmmm	orrr...
20:01	hmmmm	possibly isDummy or isGenerated aren't being updated
20:01	sapier1	:-) guess my idea not to learn how mapgen works won't have any future :-)
20:03	hmmmm	this has more to do with the emerge system
20:03	hmmmm	than anything else
20:04	hmmmm	anyway
20:05	hmmmm	so print out block->isDummy() and block->isGenerated() to the output "not in memory, attempting to load from disk"
20:05	hmmmm	to see if either of those variables are set wrong
20:06	sapier1	ok then I have to rebuild first
20:06	hmmmm	right
20:07	hmmmm	so when you see a duplicate chunk being generated, note which of those two are set (that is, if that's the issue)
20:07	sapier1	infostream ... guess I need to increase debug level too
20:09	hmmmm	well you could've just added a printf like ">>>>>>>>&&&&&& wooohoo i'm here!"
20:10	hmmmm	although I could've sworn EMERGE_DBG_OUT prints to dstream
20:10	hmmmm	hm
20:11		crazyR joined #minetest-dev
20:11	sapier1	I did as I had to add the other flags anyway
20:11	sapier1	just added a new output
20:39		us`0gb joined #minetest-dev
20:49		kahrl joined #minetest-dev
20:56	sapier1	hmmm what's supposed to happen if a block is just about to be generated while another makeChunk is called?
20:56		vifino joined #minetest-dev
20:57	hmmmm	why would another makeChunk be called?
20:57	sapier1	wow it's even more strange
20:58	sapier1	ahh no, on first call there is a block but it's flagged "not generated"
20:58	sapier1	next call (in between are other calls) there's not even a block
20:59	hmmmm	the block == NULL?
20:59	hmmmm	does loadBlock fail then?
20:59	sapier1	I don't know
20:59	hmmmm	how long of a period in between are the beginGenerateOrEmerge calls?
21:00	sapier1	about 7 seconds
21:00	sapier1	stop
21:00	sapier1	between those two calls for same block
21:00	hmmmm	yeah
21:00	hmmmm	I'm wondering if it could be getting unloaded and then loadBlock calls fail in between that time
21:00	sapier1	7 seconds is between the calls for same block
21:01	sapier1	I'll enable full debug logging now ... hopefully I can decode that much data later
21:05		vifino joined #minetest-dev
21:09	sapier1	there seem to be multiple cases I see variants where isGenerated is false on second call too
21:10	hmmmm	the generated attribute is only EVER modified in finishBlockMake
21:10	hmmmm	since you've changed it to skip the block rather than cause an assertion error, it seems to be blocking the case where it's not able to get the block from the map
21:11	hmmmm	blocking?
21:11	hmmmm	err i meant "hiding"
21:11	sapier1	most likely but how is it supposed to behave?
21:11	sapier1	assert is wrong for sure
21:12	hmmmm	so that getBlockNoCreateNoEx in finishBlockMake fails silently and setGenerated(true) never gets called for that mapblock, but it so happens that getBlockNoCreateNoEx succeeds for that same block the second time it gets emerged
21:12	hmmmm	nevermind the behavior part, that function should NEVER fail at that point in execution. it was just created. if it fails, that means something very wrong happened.
21:13	sapier1	well thenn using getBlockNoCreateNoEx is wrong
21:14	hmmmm	no, it's not wrong, the fact that getBlockNoCreateNoEx randomly fails is wrong
21:14	sapier1	still if you don't expect it to fail why should anyone calle the non exceptioning version?
21:14	hmmmm	that's true
21:14	hmmmm	i agree the exception version should be used there
21:15	sapier1	but this still doesn't explain why it fails ;-)
21:15	hmmmm	sapier, you should try printing out when a block gets unloaded
21:16	sapier1	you know I don't know map code very well ;-) where to look for that part?
21:17	hmmmm	perhaps Map::timerUpdate?
21:18	hmmmm	in any case, I think a goal minetest 0.5 should be the removal of legacy stuff
21:18	hmmmm	get rid of MapSectors completely
21:18	troller	it already was in <censored> ;)
21:19		alexxs joined #minetest-dev
21:21	sapier1	was of map code that'd most likely your job hmmmm ;-)
21:21	sapier1	+be
21:21	hmmmm	map.cpp is an abomination
21:22	sapier1	I agree but that doesn't help right now ;-)
21:26	sapier1	do I understand right that you assume block is unloaded prior beeing marked generated?
21:26	hmmmm	basically, yes
21:27	hmmmm	maybe the unload timer is going insane and the Server thread keeps tearing the blocks from under EmergeThread's feet
21:31	sapier1	hmm there are a lot of blocks unloaded
21:31	sapier1	not sure how to match it
21:31	hmmmm	erm, print out block->getUsageTimer() and unload_timeout
21:31	hmmmm	watch it be that due to a config file error, unload_timeout is at 0 or something.
21:32	sapier1	this may even be all blocks to be unloaded I create a gist
21:33	sapier1	https://gist.github.com/sapier/f5f7ca54b1292a193828
21:35		Megaf joined #minetest-dev
21:37	sapier1	wait ... that variable is used by different threads
21:37	sapier1	we had exactly that issue for day night cycle
21:38	sapier1	that damn mapblock just isn't threadsafe
21:40		nille joined #minetest-dev
21:42		vifino joined #minetest-dev
21:43	hmmmm	which variable
21:43	sapier1	timeout variable
21:44	sapier1	refcount variable ....
21:44	sapier1	all of those
21:44	sapier1	on x86 32 bit assignments are atomic
21:44	hmmmm	well that's because it's assumed that if you're accessing a MapBlock for whatever reason, you have a maplock
21:45	sapier1	case I'm right we'll see quite soon
21:45	hmmmm	it's not feasible to have a mutex per mapblock
21:46	sapier1	how much of them are usually loaded? a few hundred?
21:46	hmmmm	thousands
21:46	hmmmm	they should be getting unloaded after like 5 minutes of not being used
21:47	sapier1	then each mapblock should know which lock to take
21:47	sapier1	well they're unloaded within a few seconds
21:47	hmmmm	right, your gist pretty much confirmed my theory
21:48	sapier1	I've just added timer and timeout as well as mutexes ... if this works we know why it fails ... and can think about a sane way to fix it
21:49	sapier1	do you have any idea why basic things like that always pop up a few hours prior release?
21:49	hmmmm	\(o_O)/
21:50	Taoki	hmmmm: hello
21:50	hmmmm	Taoki: hello
21:51	Taoki	hmmmm: I've been wanting to ask you about something... although the answer will likely be negative: How capable is mgv7 of generating villages? I know it can place schematics, which IMO is enough to allow generating them (without roads of course). But is there anything else I should be aware of?
21:51	Taoki	For example, can V7 prevent schematics from clashing into each other?
21:51	hmmmm	it cannot
21:52	sapier1	didn't you say 5 minutes?
21:52	hmmmm	?? yes
21:52	Taoki	Ok. But is there a minimal distance you can impose between mts decorations?
21:52	Taoki	IIRC that did exist
21:52	hmmmm	no such thing
21:52	Taoki	I see
21:52	hmmmm	it's much simpler than you give it credit for
21:52	sapier1	nope I was wrong still happens
21:53	sapier1	timeout is 29 seconds only
21:53	Taoki	I still love it regardless :) But I understand
21:53	hmmmm	29 seconds ahh
21:53	hmmmm	i thought it was much longer than that
21:54	sapier1	server_unload_unused_data_timeout
21:54	hmmmm	yea i see
21:54	sapier1	let's check what happens if I set it to 5 min
21:54	hmmmm	erm, that's obviously not going to be the issue
21:54	Taoki	hmmmm: If it's not too much to ask for then, could you please consider any way at all (be it the simplest) to allow decorations to not clash into each other and touch? I assume this would be useful for many things... some people might not even want trees to overlap. This would be very helpful
21:55	hmmmm	have you checked the values of unload_timeout and getUsageTimer()??
21:55	hmmmm	Taoki: perhaps, but I am doing a lot more things right now
21:55	Taoki	ok. Thanks for considering it then
21:56	sapier1	yes 32 seconds most time
21:56	Taoki	Won't cry if it doesn't happen, but such would be very relevant to plans I have for a minetest game
21:56	sapier1	get usage timer is 32 seconds the timeout is 29
21:56	hmmmm	hmm
21:57	hmmmm	I don't know
21:57	sapier1	android devices ARE slow ... still thi
21:57	hmmmm	what if arm is just so slow that Server is taking up like 30 seconds for one cycle
21:57	hmmmm	or something
21:57	sapier1	s is a emerge bug even if it can be fixed this is crap
21:58	hmmmm	and it has the map locked for 32 seconds
21:58	hmmmm	bleh
21:58	sapier1	possible
21:58	hmmmm	you should check how long it takes for the after-map-generation lock aquire takes
21:58	hmmmm	acquire
21:58	hmmmm	err
21:58	sapier1	or it's a threading issue that this thread just isn't scheduled
21:59	hmmmm	yes, all possible
21:59	hmmmm	you should check how long it takes for EmergeThread to re-acquire the maplock after makeChunk** is what I meant to say
21:59	sapier1	still if this is a critical section it shouldn't rely on timings
22:00	sapier1	how to check this?
22:03	hmmmm	Timer::getTime()
22:04	sapier1	I guess I should remove the other debug output fist
22:07	sapier1	doesn't work just takes more time
22:08	hmmmm	huh?
22:08	sapier1	even with 300seconds the bug occurs
22:09	hmmmm	so it takes longer for the bug to happen if you increase the unload delay?
22:09		nille left #minetest-dev
22:09	sapier1	yes
22:10	sapier1	seems to be a quite good match
22:10	hmmmm	well then we know that the problem is definitely that the blocks are getting unloaded
22:10	sapier1	but we still don't know why
22:15		OldCoder joined #minetest-dev
22:20	hmmmm	could it be caused by insane dtime values?
22:20	sapier1	for what I know dtime is limited to something way below 300s
22:30		sapier1 left #minetest-dev
22:44		sapier left #minetest-dev
22:57		Eater4 joined #minetest-dev

← Previous day | Channels | #minetest-dev index | Today | Next day → | Google Search | Plaintext