Time Nick Message 10:31 RealBadAngel https://github.com/minetest/minetest/pull/1519 10:31 RealBadAngel made some final changes, cleaned the code and tested it 10:32 RealBadAngel celeron55, can you take a look at it now? 10:36 celeron55 https://github.com/minetest/minetest/pull/1519/files#diff-70868aa6d6b96c0c1623c761500d23c4L1032 10:36 celeron55 you removed this final else 10:37 celeron55 it's kind of important 10:38 celeron55 what is light_source_alternative? 10:39 celeron55 doesn't make any kind of intuitive sense to me 10:39 RealBadAngel i want 2nd set of tiles (special ones) to be also used as alternative for a node 10:39 RealBadAngel like furnace inactive and active 10:40 RealBadAngel but for it to be complete 2nd value of light source is needed 10:40 RealBadAngel thx to that all two stated nodes could become just one def 10:42 RealBadAngel about that else, ooops, adding it back 10:48 RealBadAngel also for example mesecons wires nodes count could be cut by half thx to light_source_alternative and thats pretty high number of defs 10:50 RealBadAngel with wires that can climb the walls its about 1k of node defs, so 0.5k saved 10:51 sapier someone will have to update mesecons ;-) 10:51 Krock Did anyone notice the following bug yet: Text from chat does not wrap if it goes outside of the window 10:51 RealBadAngel sapier, ofc, but thats gonna be huge benefit for such a small change 10:54 RealBadAngel celeron55, "else" is back there 10:54 sapier I don't denie this it's just some other not linked issue as jeja isn't around for a while 10:56 RealBadAngel he is around, just not showing here, and there are more contributors to mesecons too 10:57 RealBadAngel VanessaE for example has push rights 10:57 RealBadAngel https://github.com/Jeija/minetest-mod-mesecons/commits/master 10:58 celeron55 RealBadAngel: ehm... no, don't add a light value like this 10:58 celeron55 RealBadAngel: what about a second set of nodeboxes? second set of walkable? 10:58 celeron55 what about a third set? 10:58 RealBadAngel its not meant for this 10:58 celeron55 don't add this, it's arbitrary and incomplete and a wrong development direction 10:59 RealBadAngel does the furnace change its shape on becomig active? 10:59 RealBadAngel it just start to emit light 10:59 celeron55 we aren't developing a furnace, we are developing the engine 10:59 celeron55 you either do a thing properly or don't do it 11:00 RealBadAngel furnace is just an example 11:00 RealBadAngel there are dozens of nodes that are waiting for this change 11:00 celeron55 at least do not add it in this pull request 11:00 RealBadAngel i did it now because its related to cf protocol 11:01 celeron55 you can just add it to the end at any point anyway 11:01 celeron55 no need to chunk it with other stuff 11:01 RealBadAngel ofc, but now i avoided to put into try-catch 11:01 celeron55 there's no reason to avoid that 11:01 RealBadAngel but as you wish 11:01 RealBadAngel remove it now? 11:02 celeron55 remove it now, and design it properly later 11:02 RealBadAngel what do you mean by "properly" ? 11:03 RealBadAngel by now it is just a property aviable to read by drawtypes 11:03 celeron55 in my opinion doing this properly means doing it in some way that doesn't just randomly pick one property and make it specially changeable 11:03 celeron55 if it is done, it should be generic for a large set of properties 11:04 celeron55 because that is what modders are going to want in the long run anyway 11:05 celeron55 can you explain why that wouldn't happen? 11:05 RealBadAngel there are many properties that are used by specific drawtypes only 11:05 RealBadAngel and this is supposed to be such one, not generic one 11:06 celeron55 then let's discuss it again when you include it in a pull request that contains the actual feature 11:06 RealBadAngel ok, that sounds reasonable 11:06 celeron55 good 11:06 RealBadAngel hard to talk bout a feature that dont exists yet 11:12 RealBadAngel celeron55, ok, removed it for now 11:15 celeron55 as long as you update clientserver.h's comment, now it finally looks nice and clean 11:18 RealBadAngel done 11:27 sol_invictus yesterday my server was griefed by some leet haxor which spilled lava over houses and then water over them 11:28 sol_invictus the strange thing in this is that in logs I found him using empty buckets only 11:28 sol_invictus is that a bug or normal behavior? 11:30 PenguinDad sol_invictus: That is normal behavior 11:31 sol_invictus is there anything I can do? 11:32 sol_invictus I was thinking about making lava placeable on claimed areas only 11:37 celeron55 sounds like something you could suggest to the author of your preferred protection mod 8) 11:38 celeron55 (i'm not aware of how bucket usage is logged) 13:50 VanessaE http://pastebin.com/Ki4WrZjp <---- wasn't this already fixed in git? 13:51 VanessaE and if not, why is minetest loading images from anywhere in ~/.minetest at all? 13:51 sfan5 maybe someone mixed path_share and path_user 15:33 VanessaE ok so ulla81's problem in that paste, ultimately, is preload item visuals being turned on is causing in-world textures not to render, or so I gather. 15:33 VanessaE language barrier, so I'm not entirely sure that's what he's trying to say. But this is not the first time I've heard of that setting causing this problem. 15:34 VanessaE I am aware that it is disabled by default now, but obviously it has a problem. 15:34 sapier guess it's same issue as I have 15:34 sapier inventory textures messed up 15:34 VanessaE sapier: could be. I don't suppose you have a screenshot of it? 15:34 VanessaE because I'll be damned if I can actually make proper sense of what he REALLY means 15:35 VanessaE :) 15:35 sapier well it's same as always, random pieces of memory shown as inventory items 15:35 VanessaE ah 15:35 VanessaE I think jordach filed a report for that 15:36 VanessaE this seems related,https://github.com/minetest/minetest/issues/1175 15:36 VanessaE https://github.com/minetest/minetest/issues/1175 15:36 VanessaE ah, here it is: https://github.com/minetest/minetest/issues/347 15:36 sapier I've seen a error report at irrlicht where some "openGL texture corruption" was fixed for 1.8 ... I have 1.7 so I might suffer that issue 15:36 VanessaE look familiar? 15:37 sapier jessie should be newer yet I don't know what irrlicht version is included there 15:39 PenguinDad sapier: 1.8.1 is included in jessie 15:40 sapier for what I remember about that report at least the issue I am talking about was fixed for 1.8.0 so this is most likely something different 17:29 casimir Is there a reason there are user, clicker, placer, digger and player? Would 17:30 Krock clicker is easier to understand than placer or player 17:30 VanessaE but clicker makes no sense in a tablet environment ;) 17:30 * VanessaE pokes sapier :P 17:31 casimir Wouldn't it be more consistent to use just player? 17:31 VanessaE imho "actor" would have been the most correct word 17:32 VanessaE casimir: not really, because sometimes even a player isn't the one causing a callback to happenb 17:32 VanessaE -b 17:33 casimir I's just confusing to change the name any time you copy a function somewhere. 17:33 VanessaE for example, in ferns mod, the cavegen can sometimes trigger on on_destruct callback, which in turn can trigger an after dig callback due to the way that mod is coded, and in neither case is a player involved. 17:36 casimir Hm, so "actor" would be better in theory, but that would make things even more complicated. 17:38 VanessaE yep 17:39 VanessaE better to not change it at all, less'n you want to supply that variable to all of those callbacks and have the old variable names supplied "in secret" somehow. 18:05 sapier I don't think renaming things is usefull if there's no need to do it ... just causing unknown amount of glitches ;-) 18:05 VanessaE and tons of broken mods :P 18:06 sapier as lua doesn't care about names I'd guess it's not very likely ... yet without good reason I'd not take the risk ;-) all imho of course 18:07 VanessaE well come to think of it, it would just be a matter of changing lua_api.txt wouldn't it. 18:07 VanessaE since the params are positional instead of named 18:08 sapier nope we'd need to change a bunch of c++ files where those parameters are added too 18:08 VanessaE hm 18:08 VanessaE right. 18:08 sapier those would be comments yes but it'd be a worse inconsistency then the names are right now 18:08 VanessaE I meant from a purely Lua-side standpoint 18:09 sapier yes but as always there's more to consider ;-) 18:09 VanessaE all the callback does is pass e.g. three or four parameters, it doesn't actually matter what name you *use*. 18:09 VanessaE (pos, node, placer) could just as easily be (position, node, actor) in your mod and it would still work 18:10 VanessaE it just wouldn't be consistent with the internal state of the engine 18:10 sapier still you want this change to get a more consistent state if you don't change the c++ parts the overall result will be different 18:10 VanessaE I don't really want it. casimir does :) 18:10 sapier if he find someone to do all the renaming work we may think about it but only changing lua not changing c++ imho is wrong direction 18:14 VanessaE I could agree with that. 18:18 casimir I didn't meant to change something of the c++ things, nor the lua_api.txt. I just wondered if there was a reason for using different names. 18:22 VanessaE casimir: I suspect a lot of randomness 18:22 VanessaE sometimes a place event is being done, so "placer" seems to fit 18:22 VanessaE sometimes it's something else, so a different word seems to make sense there 18:22 VanessaE etc