Time Nick Message 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. 07:00 RealBadAngel , 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: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: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: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:22 Eater4 celeron55: why arnt you voiced? 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 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: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 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 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 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 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 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 "" 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 "" 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: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 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: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 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 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: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 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 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 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 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 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 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 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 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: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: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: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 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 ? 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:37 BlockMen nomodflow does not fix the android bug for me 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: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 sapier1 I did as I had to add the other flags anyway 20:11 sapier1 just added a new output 20:56 sapier1 hmmm what's supposed to happen if a block is just about to be generated while another makeChunk is called? 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: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 ;) 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: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: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 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: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