Minetest logo

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

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

All times shown according to UTC.

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/v​iewtopic.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/v​iewtopic.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/vi​ewtopic.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/sa​pier/2f5f8fb31b60f57c59a4
10:55 sapier correct state of game discussion?
10:56 sfan5 I don't think so
10:56 celeron55 https://gist.github.com/cel​eron55/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.ph​p?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/6c98fd6658fcf7c0c676ee88f03e​364c852e9f1b#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/v​iewtopic.php?f=15&amp;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/c​lient/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/minet​est-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/minet​est-dev/2014-07-05#i_3795337 → woah, Minecraft's well balanced now? I doubt it :p
16:35 Calinou http://irc.minetest.ru/minet​est-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/minet​est-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/minet​est-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/min​etest/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/commi​t/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/sa​pier/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

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