Time Nick Message 00:00 hmmmm it looks pretty good 01:01 kahrl hrm 01:02 kahrl I made an almost completely empty game to test my dependency algorithm 01:02 kahrl stumbled upon a segfault in ~CItemDefManager 01:02 kahrl itemdef.cpp:250 needs an if(cc->wield_mesh) around it 01:03 kahrl can't be bothered to make a pull request for this now 01:03 Exio what? 01:03 Exio sounds like a "non-defined" hand 01:03 kahrl yeah, I think that's what it is 01:04 kahrl it calls cc->wield_mesh->drop() but cc->wield_mesh is NULL 01:04 hmmmm great... 01:04 hmmmm i hope this is the last of the null dereference bugs introduced when sapier fixed the memory leaks 01:07 hmmmm there fixed 01:09 kahrl thanks 01:23 kahrl my algorithm doesn't work 01:23 kahrl consider 3 mods: a, b, c; b depends on a and a optionally depends on c 01:23 kahrl say the normal dependency resolver returns the sort order a, b, c 01:24 kahrl the optional dependency resolver can't move a behind c because b is in the way 01:38 hmmmm what's wrong with moving the optional dependency in front instead? 01:40 hmmmm hmmm. i think i have an idea of how to deal with structures that are larger than a single block 01:41 hmmmm but it requires recalculating all the decoration placements of the block below 01:41 hmmmm s/block/chunk 01:43 Exio what about "just adding" optional deps at the end, and when loading if (!optional && not_found) cancel; (as actually it is a if (not_found), no?) 01:43 hmmmm so let's reason this out. if node_min.Y > heightmap[index], then we're above what was already to have been generated 01:44 hmmmm so if we are generating a decoration with a height greater than 16 (size of the border), calculate all the positions of decorations placed 01:44 hmmmm if decoration height + heightmap[index] is > chunksize.Y + MAP_BLOCKSIZE, then we know that one was definitely cut off 01:46 hmmmm so, generate it again, and blit it back to the vmanip starting at the point where it was cut off 01:46 hmmmm and of course, then there's the problem with sunlight not being propogated properly? 01:47 hmmmm i would need to fix all instances of calcLighting() to assume there is sunlight if the overtop is CONTENT_IGNORE _or_ it's a node that propagates sunlight 01:53 hmmmm i'm not sure if it's worth all the effort 01:54 hmmmm could just call spawn_ltree() after finishBlockMake on those areas 01:55 hmmmm hrm, i should only bother with that if the height passes a threshhold - same thing with schematic-based placements 02:11 RealBadAngel damn im playing with water and ice 02:12 RealBadAngel can some1 explain why water is still drawn if i did this? 02:12 RealBadAngel case NDT_LIQUID: 02:12 RealBadAngel { 02:12 RealBadAngel continue; 02:13 RealBadAngel nvm, im tired propably ;) 02:20 RealBadAngel well, both liquid drawtypes disabled, water surface still drawn. very funny :) 02:27 fuzzywuzzy VanessaE are you there? 02:27 fuzzywuzzy kaeza estas? 02:28 kaeza hm? 02:29 fuzzywuzzy i need to know how i can make a image of my map i try this 02:29 fuzzywuzzy python minetestmapper.py ../worlds/MTVIlle map.png 02:29 fuzzywuzzy but it doesnt seem to work 02:29 kaeza fuzzywuzzy, → #minetest 02:29 fuzzywuzzy i cant go on there pm? 02:30 Exio -- [#minetest] *!*@189.191.* banned by VanessaE - »»» fuzzywuzzy (~fuzzywuzz@189.191.76.74) 02:30 fuzzywuzzy OMG its working! 02:30 kaeza Exio, guessed 02:31 fuzzywuzzy well it seems to be working 02:31 fuzzywuzzy so ill tell you if it worked in a while 02:32 fuzzywuzzy it worked!!! 02:32 fuzzywuzzy yeah baby 02:34 fuzzywuzzy thanks kaeza 02:34 fuzzywuzzy still i need to install all the mods too i get the image of the block that is under the unknown block 02:54 Exio i think all the people with access to the repo should have op in/on #mt and #mt-de 02:54 Exio v 03:00 hmmmm ._. 03:01 hmmmm +++ATM0DT911 03:07 ShadowNinja Having a public access list here would be nice... 04:41 hmmmm hrm 04:42 hmmmm i think it's worth looking into varying 3d noise prevalence based on biome 07:37 kahrl seems I'll have to rework ModConfiguration a bit to properly support optional dependencies 07:37 kahrl question: is having multiple mods with the same name (in different paths) a supported configuration? 07:38 VanessaE not really, no - but it does work. 07:38 VanessaE whichever one loads second is the one whose node defs and such take precedence. 07:38 kahrl yeah, the current ModConfiguration loads them but I'm not sure if dependencies are handled correctly 07:39 VanessaE (I ran into that exact scenario last night in fact) 07:39 kahrl oh 07:39 kahrl mind sharing the paths and dependency situation so that I can use it as a test case? 07:40 kahrl if it's not too much work 07:41 VanessaE I don't remember the specifics, because I was quick to correct it (after realizing the issue) 07:41 VanessaE but, 07:42 VanessaE it was something like ModA included a copy of ModB within, plus there was a second copy of ModB in the same folder as ModA (e.g. ~/.minetest/mods/minetest). When ModA loaded, it loaded ModB with it, and then the second, "extra" ModB got loaded, redefining everything the copy included with ModA had established,. 07:42 VanessaE make sense 07:42 VanessaE > 07:42 VanessaE ? 07:43 kahrl I see 07:43 VanessaE I've had the same thing happen with modpacks vs. individual mods 07:44 VanessaE it really makes you scratch your head for a while if you're not in a mental state to think of such a thing. 07:44 kahrl there used to be a warning in this case 07:44 VanessaE maybe there still is, I rarely look at the console except when there's a fatal error. 07:44 kahrl see commit 6b2023dc3eb1b483c92ba967f3335bb6880d2db1 07:45 kahrl nah, it's no longer there, unless grep failed me 07:45 VanessaE https://github.com/minetest/minetest/commit/6b2023dc3eb1b483c92ba967f3335bb6880d2db1 07:45 VanessaE it's there. 07:48 VanessaE I have to wonder if that code even still exists a year later 07:50 VanessaE nope. 07:50 VanessaE at least, not that "mod name conflict" message anyway 07:51 VanessaE nor any of the other associated messages. 07:52 kahrl I wonder what the right thing to do is 07:53 VanessaE good question. 07:53 VanessaE I suppose it's possible that this IS a supported configuration now, but even so there ought to be at least a warning. 07:54 VanessaE "Warning, $MODNAME already loaded from $PATH1, also loading the copy at $PATH2" or so. 08:22 celeron55 two mods with the same name shouldn't ever be loaded at the same time 08:22 celeron55 there's no way to make the end result reasonable at all 08:23 VanessaE they shouldn't, no, but it's trivial to cause it to happen. 08:23 celeron55 it should just ignore the other one, with either a preference for modpacks or for non-modpacks or for user-installed or globally installed; dunno which 08:24 VanessaE I would guess it should prefer individual user-installed mods. 08:24 VanessaE that way a person could still, say, supply their own copy of the fire mod or something, without having to delete the original. 08:25 VanessaE look for a user mod first, then a modpack containing one, then the current game, then fall back to whatever is below that 08:25 celeron55 but what if mods in two modpacks depend on the same mod and both provide it, AND it also exists globally or not in a modpack? 08:26 VanessaE then the global one takes precedence, with a warning message printed to the log. 08:26 celeron55 the algorithm for that is going to be very hard to make 08:27 VanessaE as long as the order is predictable and there are warning messages, modders (and maybe users) will be able to sort out the conflicts. 08:27 VanessaE yeah, I guess it would be,. 08:27 celeron55 if somebody does, then fine; but i am guessing nobody will 8) 08:27 VanessaE have fun :D 08:27 celeron55 >as long as the order is predictable 08:27 celeron55 that is important, yes 08:28 celeron55 i mean, the preference order 08:28 VanessaE yes. 08:28 celeron55 mod loading order, disregarding dependencies, is not predictable by design 08:28 VanessaE is there a particular reason why that is? 08:29 celeron55 making it predictable serves no purpose because everyone has a different set of mods, breaking predictability 08:29 VanessaE well, predictable doesn't have to mean "Mod A will always load before Mod B".. It can simply mean "Mod A was found in ~/.minetest/mods/minetest and ~/.minetest/games/survival, load the one in mods/minetest and ignore the other" 08:30 celeron55 the same thing applies somewhat to the order of preference, but it's lower there 08:30 celeron55 the applicability is lower, i mean 08:30 VanessaE i.e. it only needs class granularity 08:31 kahrl implementing this is not hard at all 08:31 VanessaE there's little or nothing to be gained by trying to get too fine-grained really 08:31 kahrl I mean, look ModConfiguration(std::string) 08:31 kahrl look at* 08:31 kahrl the mods are already searched in this preference order 08:32 kahrl if a new mod is found with a duplicate name, discard the older one 08:32 VanessaE kahrl: link to that code? 08:32 * VanessaE is not familar with the engine layout. 08:33 kahrl https://github.com/minetest/minetest/blob/master/src/mods.cpp#L210 08:33 VanessaE thanks 08:33 celeron55 it needs the addition that if there are two mods at the same "level", it would revert to the previous "level" (levels being, in order: global, global+modpack, user, user+modpack (or something like that)) 08:34 VanessaE celeron55: in that particular case, check the modified time of the two mods. Whichever is newer takes precedence. If no timestamp, alpha-order. 08:34 celeron55 timestamps make no sense at all 08:34 VanessaE (alpha order by modpack name for example) 08:35 VanessaE why so? 08:35 VanessaE or why not, rather 08:35 celeron55 there's nothing to guarantee they actually represent anything related to the version of the mod 08:35 celeron55 and both mods could be forks of a previous one with different additions 08:35 VanessaE hrm 08:35 VanessaE nono I mean the timestamp on the user's filesystem 08:36 VanessaE well no, I guess that's not too difficult to get wrong 08:36 celeron55 the timestamps will be copied in archives 08:36 VanessaE so then just alpha order. 08:36 VanessaE falling back down one "level" in that instance would probably cause neither mod to load 08:36 celeron55 alphabetic order is not useful at all either 08:36 kahrl what is the use case for reverting to a previous level? 08:37 celeron55 also i think it would be just as good to just simply fail 08:37 VanessaE why not alpha order? 08:37 celeron55 VanessaE: my question is, why the hell IN alpha order? 08:37 VanessaE kahrl: I don't see a point to that, myself, not in this particular corner case. 08:38 VanessaE celeron55: simple, you can be guaranteed that the next level up will have at least some way to differentiate the two modpacks. 08:38 VanessaE if they had the same directory name, you've got a broken filesystem on your hands anyway 08:38 celeron55 so i'll make modpack XXXXXXXgreatmods 08:38 celeron55 and it'll always override everything until someone makes XXXXXXXXxXxXXxgreatmods 08:39 VanessaE in which case a warning is printed that two mods with the same name are attempting to load - and the user can be asked to find that warning in their log if they have a problem with the resutl. 08:39 VanessaE result* 08:40 celeron55 i think it actually should just fail 08:40 VanessaE we already tell users to post their logs when some obscure-to-that-user error occurs anyway 08:40 celeron55 the end result is so uncontrollable anyway 08:40 celeron55 and it's a very far corner case resulting from bad practices 08:41 VanessaE true. 08:41 VanessaE I guess a failure is okay, as long as the error message spells out in detail what caused it. 08:41 celeron55 the error must be as clear as possible 08:41 VanessaE just saying there were two of ModA tryign to load is insufficient - it must at least give full paths, too. 08:42 VanessaE oh G*d, does that mean we agree on something again? *faints* 08:45 kahrl suggestion for the order of levels: http://paste.dy.fi/hmb 08:45 VanessaE kahrl: where higher level numbers take precedence? 08:45 kahrl okay, so let's say that there are 3 mods with the same name: 2 in user modpacks and 1 user mod 08:46 kahrl VanessaE: yes 08:46 VanessaE kahrl: I like this. 08:46 kahrl should that fail or load the user mod? 08:46 VanessaE load the user mod. 08:46 VanessaE (and warn that the other two were ignored) 08:46 kahrl okay, that's what I'd have said 08:46 kahrl makes it a little more complicated to implement but for the better 08:51 celeron55 umm 08:51 celeron55 i think we just agreed that it should fail 08:52 celeron55 oh no, it's the other way in precendence 08:54 celeron55 i'm not sure if that actually would make sense 08:55 kahrl it would allow a user to fix a mod conflict (say in user modpacks) without having to uninstall at least one modpack 08:55 celeron55 it brings up the same question as with the other way in precedence - are the depending mods in the modpacks compatible with the user mod 08:56 celeron55 yes, that's the difference 08:56 celeron55 i guess it's good enough 08:56 kahrl it will give a warning in any case 09:18 kahrl should this be documented somewhere? lua_api.txt? the wiki? 09:20 celeron55 there's stuff about mod loading at the beginning of lua_api.txt 09:20 celeron55 you could define it very briefly somewhere near there 09:21 celeron55 nothing noob-proof but something that makes it clear there is an order of preference and certain conflicts will directly fail 09:22 kahrl I don't know, I have a feeling that it will bloat the file if I describe it completely 09:22 kahrl I'll make a page on dev.minetest.net if I can get past the cat photos 09:23 celeron55 i have never been able to get past them (otoh, i have an account there so i haven't had to trie too hard 8)) 09:23 celeron55 try* 09:24 celeron55 (but to me it seems they just don't work) 09:25 celeron55 also, not adding anything to lua_api.txt is fine to me 09:25 kahrl I got past the cats somehow 09:25 kahrl woohoo :D 09:27 VanessaE and the wiki never knew what hit it...... 09:27 VanessaE ;) 10:12 kahrl http://dev.minetest.net/Mod_name_conflicts 10:13 kahrl brb 13:00 RealBadAngel hi all 13:01 RealBadAngel does anybody know where liquid surface is drawn? i have disabled NDT_LIQUID it is still being drawn 13:30 RealBadAngel hi hmmmm 13:31 RealBadAngel do you know where water surface is drawn? 14:02 kahrl RealBadAngel: NDT_LIQUID is only used when new_style_water = 1 in minetest.conf 14:02 kahrl NDT_FLOWINGLIQUID is always used 14:03 kahrl if new_style_water is 0, water source nodes are drawn in MapBlockMesh() 14:03 kahrl like all solid nodes 14:04 RealBadAngel i disabled both liquid drawtypes 14:05 RealBadAngel and surface (only) is still being drawn 14:06 RealBadAngel case NDT_FLOWINGLIQUID: 14:06 RealBadAngel { 14:06 RealBadAngel break; 14:06 kahrl Yeah. Try enabling new_style_water 14:08 RealBadAngel i am asking what code draws the surface 14:08 RealBadAngel because it does it wrong 14:09 kahrl what are you actually trying to do 14:10 RealBadAngel fix it 14:10 kahrl fix what? 14:10 RealBadAngel but cannot find code that draws it, it is ridiculous 14:10 kahrl by default it's drawn like solid nodes such as dirt, stone, ... 14:11 kahrl just with a different shader that moves it down the y axis 14:11 RealBadAngel way it is displayed, it is affedcted with some weird bug that causes it to display it in some regions properly in others not 14:11 RealBadAngel shaders are off.. 14:11 kahrl screenshot? 14:13 RealBadAngel http://i.imgur.com/jrL1geS.png 14:14 RealBadAngel both drawtypes disabled, shaders off 14:14 PilzAdam kahrl, no, shaders dont move water down anymore 14:15 PilzAdam I fixed new_style_water, so shaders arent needed for that anymore 14:15 kahrl I'm getting lowered water even without new_style_water 14:15 RealBadAngel have you introduced new code to draw water surfaces? 14:15 PilzAdam RealBadAngel, liquid sources are drawn like normal nodes with new_stlye_water = 0; flowing liquids are drawn in the generate_special() function 14:16 PilzAdam so, you have disabled NDT_FLOWINGLIQUID, so you see the sources only in the screenshot 14:16 RealBadAngel what code draws the sources? 14:16 PilzAdam with new_style_water or without? 14:17 RealBadAngel drawtypes are disabled 14:17 RealBadAngel wheres the code that draws the surface 14:17 PilzAdam with new_style_water or without? 14:17 RealBadAngel whatever 14:17 RealBadAngel what draws it god damm it 14:18 RealBadAngel am i askin in chinese? 14:18 PilzAdam well, with new_style_water = 1 its drawn in mapblock_mesh_generate_special(), with new_style_water = 0 its drawn in MapBlockMesh() (like kahrl already said) 14:19 kahrl okay forget what I said, I apparently had new_style_water on without knowing 14:19 kahrl I disabled it and now the water is not lowered 14:19 RealBadAngel in mapblock_mesh_generate_special draws all NDT_'s 14:19 RealBadAngel i disabled it 14:19 kahrl umm 14:19 PilzAdam umm 14:19 RealBadAngel so MapBlockMesh(), yes? 14:20 kahrl yes. 14:20 PilzAdam do you actually read what we say? 14:21 PilzAdam mapblock_mesh_generate_special() only draws the special node drawtypes 14:21 PilzAdam and with new_style_water=0 water sources arent handled special 14:21 kahrl look at nodedef.cpp:608 14:22 RealBadAngel where in mapblock_mesh.cpp? 14:22 RealBadAngel i cannot see here anythin related to liquids 14:23 PilzAdam because liquid sources are not handled special 14:23 PilzAdam they are drawn like every other node with drawtype "normal" 14:24 RealBadAngel great... 14:24 RealBadAngel thats why theyre drawn twice 14:24 PilzAdam what do you want to fix there? 14:24 RealBadAngel in several regions 14:24 RealBadAngel its screwed 14:24 RealBadAngel thats why i want to fix it 14:25 PilzAdam what is screwed? 14:25 RealBadAngel draw regions are square shape, like the chessboard 14:26 RealBadAngel in one alpha works perfectly, node next to it dont 14:26 RealBadAngel it makes transparent ice impossible 14:26 RealBadAngel also causes air bubbles visible like black hole in water 14:27 RealBadAngel there are two water surfaces displayed at the same time 14:28 RealBadAngel this code needs to be fixed 14:30 RealBadAngel how and where to do force liquids to be displayed as all other nodes with solindess!=0 ? 14:30 RealBadAngel *do you 14:30 PilzAdam look at nodedef.cpp:608 14:31 RealBadAngel ah, thx 14:48 celeron55 inb4 some horrible hack 15:02 RealBadAngel http://i.imgur.com/dFOuYmY.jpg 15:02 RealBadAngel ice under and above water 15:03 RealBadAngel need just to make water face not being shown below ice 15:03 RealBadAngel but apart from it, its working fine 15:16 PilzAdam hmmmm, Im building a nether at -5000 by registering netherrack as an ore and replace stone and all the other ores; but only the stone gets replaced, the register_ore calls of netherrack with wherein="some ore" have no effect 17:32 PilzAdam hmmmm, nvm, I had a typo in my code 17:33 PilzAdam but still, not all nodes are replaced with clust_scarcity = 1 17:34 celeron55 oh by the way, did thexyz fix the 0.4.6 build? 17:34 thexyz http://minetest.ru/builds/minetest-0.4.6-2.zip 17:34 celeron55 i'll change the download page to point to that 17:34 celeron55 not worth making any news of i guess though 17:35 thexyz no idea what i broke this time 17:35 thexyz the only difference SHOULD BE cURL support 17:40 celeron55 i wonder where we'd find people who would take pride in making sure windows packages are good 17:41 celeron55 or, really, we don't really have any QC over launchpad packages or anythinge lse either 19:05 BlockMen hi 20:29 emptty sapier: around? 20:29 sapier yes how may I help you? 20:29 emptty I was wondering about the license of your mods 20:30 emptty I'd love packaging mobf for my lazy users, but the license is not one very clear 20:30 sapier CC-BY-SA 20:31 sapier for most there are some things that are even CC0 those are stated in the attached license files 20:32 emptty thanks a lot 20:32 emptty could you add a formal notice in the git or somewhere? 20:33 sapier I'll have a look where to add it 20:34 emptty I also noted that the mention on top of every file contains a typo: "And of course you are NOT allow to pretend you have written it. " 20:34 emptty that should be "allowed" 20:35 sapier yes you're right I think there is more to change in this header 20:36 emptty Also, I wanted to say that I like these mods very much, thanks for your work 20:36 sapier yes of course thanks for the hint I didn't know about that typo by now 20:37 emptty the mese is not expensive enough by the trader, but that's the only glitch I can think of after a few days of extensive use :) 20:38 sapier :-) it's easy to change and of course you can write a issue on github for next mobf version 20:40 RealBadAngel btw i keep getting lately such strange warning when closing the client: 20:40 RealBadAngel Could not open file of texture: [inventorycube{default_lava.png{default_lava.png{default_lava.png^[forcesingle 20:40 RealBadAngel sometimes it is about 20+ textures 20:40 * PilzAdam too 20:41 BlockMen i have same warnings 20:43 jin_xi same here 20:43 sapier hmm does this happen anytime? 20:43 RealBadAngel memory leaks fixes sideeffect? 20:43 sapier sounds like it yes 20:43 sapier I'll have a look 20:43 RealBadAngel it always ends with forcesingle 20:43 PilzAdam anyone wanna dig into "git bisect"? 20:43 RealBadAngel i mean warning 20:44 VanessaE same here. 20:44 VanessaE I get those warnings even on stuff I know for a fact is good, like homedecor textures. 20:44 sapier lol what about looking at changes and think about what may have done it ;-) 20:46 fubarr hello all, i just came accross minetest... and I was wondering maybe to port it to IRIX, the old Silicon Graphics unix. It's semi-modern round 2005 EOL, and my hardware is OpenGL 1.2/GLX 1.3 compatible. Though it doesn;t have the multi-texture extension. Should I even consider it? 20:50 sapier rba is this the full line? 20:50 emptty fubarr: if irrlicht works on your platform, minetest should work like a charm 20:51 RealBadAngel sapier, the waring? if so then yes 20:51 emptty fubarr: in other words, you're asking on the wrong channel: ask to the creators of the graphical engine ;) 20:51 sapier I don't even find a matching error text in code :-( 20:51 fubarr lol - fair enough - i'm looking at the irrlicht pages right now. 20:52 emptty sapier: issue opened 20:53 hmmmm [01:33 PM] but still, not all nodes are replaced with clust_scarcity = 1 20:53 hmmmm holy crap that must be slow. 20:54 PilzAdam https://github.com/PilzAdam/nether/blob/master/init.lua#L356 20:54 PilzAdam its still faster than looping through the mapblock(s) with on_generated() 20:54 PilzAdam (note that also with 6 register_ore() calls there still appears stone) 20:55 hmmmm well that's because the rand used in minetest sucks 20:56 PilzAdam would ore_type = "sheet" work better? 20:56 hmmmm maybe 21:09 PilzAdam what noise_params would I use when I want everything to be replaced? 21:21 Exio PilzAdam: just some small things, gravel exists in the nether (MC) - and the soul sand (nethersand) doesn't fall like normal :P 21:28 jojoa1997 and quartz 21:29 Exio quartz should be added in mesecons, not default 21:34 jojoa1997 mesecons? 23:59 hmmmm hmm