Time Nick Message 08:59 Megaf Morning, https://github.com/minetest/minetest/issues/1512#issuecomment-53543271 09:03 kahrl I didn't even realize we had a drawscene.cpp file :P 09:03 kahrl oh, it came with the android support 09:10 kahrl Megaf: it's weird that you can reproduce this everywhere because it never happens for me 09:11 Megaf kahrl: player for a couple of hours, then return to main menu 09:11 kahrl hmm 09:11 Megaf then change some settings 09:11 Megaf then go back to server tab, and try to reloging to the same server 09:11 kahrl that makes it harder to reproduce :P 09:11 Megaf maybe play even for a couple of minutes 09:12 Megaf kahrl: some players will stay online in my server for more than 8 hours 09:12 kahrl I know 09:12 kahrl I only play for a couple minutes at a time at most 09:13 Megaf well, at least try the way I said, play > main menu > change one or two settings > server tab > relog 09:13 kahrl server tab or client tab? 09:14 Megaf hm 09:14 Megaf the tab where you log in in a server 09:14 Megaf play multiplayer 09:15 kahrl well, both of them do that in a way 09:15 kahrl but I guess you mean the client tab 09:20 Megaf kahrl: yep, the client tab 09:21 Megaf and sometimes if will cash even not playing before, just go from client tab to settings, change some settings, go back to client tab, try to login, crash 09:22 Megaf It’s not really easy to reproduce, as it seem to only crash when it feels like crashing… Like it has its own will 09:22 Megaf By the way, I’m testing on 64 bit 09:23 Megaf and well, on OS X it crashes without having to go to setting, I just opened minetest, it was on the client tab, I left it open for 5 minutes or so, them I tried to loging, tyoing my password, but it crashes as soon as I hit login button 09:26 kahrl the crash is always within irr::gui::CGUIEnvironment::OnPostRender, right? 09:41 Megaf let me see if I can make it crash 09:43 Megaf I dont know, I cant make it crash, it will crash when it feels like crashing 09:55 iqualfragile the bots are gone, where did they go? 11:10 RealBadAngel hi 11:11 iqualfragile hi RealBadAngel 11:11 RealBadAngel i made special_tiles and usage of it common for all kind of drawtypes, it works suprisingly good 11:12 RealBadAngel uploading now video on how it works 11:12 iqualfragile RealBadAngel: what is the progress on real light sources? 11:12 RealBadAngel stuck on fixing old system 11:13 RealBadAngel before i fix current one i cant go any further 11:13 RealBadAngel because new one is gonna be mix of old one and irrlicht lights 11:14 RealBadAngel i need to make old one kinda lib, with all the light code in one place, instead of being spread everywhere 11:47 iqualfragile RealBadAngel: by old light you referr to the light levels? 19:18 Megaf any help here? https://github.com/minetest/minetest/issues/1502 19:57 Cylus It seems TNT destroys steel doors, locked chests (deleting their inventories), and nodes in protected areas. Is this a bug or an intended feature? 19:59 Jordach that's a bug 19:59 Cylus Okay, I'll get working on a solution then. 20:00 Cylus Adding a protection check will be easy, but a non-node-specific (as in, not hacky) check for the chests and doors may be a problem. 20:06 Cylus Got it. .can_dig(). This shouldn't be too hard then. 20:08 Cylus Never mind, that won't work. .can_dig() expects a player reference, not a name, so we can't pass in an invalid play name such as "***TNT***". 20:09 PilzAdam Cylus, maybe player can be left nil 20:10 PilzAdam or get the player who charged the TNT 20:10 Cylus Oh. Sweet. Thanks PilzAdam! 20:11 Cylus Does the TNT keep track of who charged it, even through a line of gunpowder? 20:11 sfan5 no 20:13 Cylus Actually, The locked chest seems to assume the player argument is a valid player and calls player:get_player_name(). nil:get_player_name() would likely crash the server. 20:15 Cylus Maybe if .can_dig() exists at all, TNT can't breach it? That would be simple to check for. 20:15 PilzAdam too hacky 20:15 Cylus Yeah, you're probably right. 20:15 PilzAdam it might always return true 20:16 Cylus Is there a way to create a temporary fake player reference? 20:16 PilzAdam why don't you add a way to keep track of who charged the TNT? 20:16 sfan5 yes, you can create a player reference 20:17 sfan5 just create an objects with all the methods a real player objref has 20:17 PilzAdam if you create a fake player then owners of protected areas wouldn't be able to nuke it 20:19 Cylus Hmm. A fair point. I suppose that's the angle I'll work from then. Thanks for the help PilzAdam and sfan5! 20:25 Cylus What about when a forest fire lights the TNT? There's no player to find in that case. 20:27 Cylus Or if someone leaves TNT behind, and a lava flow finds it after someone else mines a hole in a lava pit way above, possibly several chambers away? 20:28 Cylus As liquid is handles by the engine, I don't think there's a good way to track down the player who let it loose in Lua. 20:29 Cylus *handled 20:29 sfan5 you can't always find someone to blame 20:31 Cylus In which case the server crashes because an invalid player was passed in. It can't even default to the placer of the TNT, as if the person isn't online, there's no player reference for them. 20:32 Cylus Would it be too hacky to use PilzAdam's idea when possible, but when flammable nodes are involved, instead default to a fake player? 20:33 PilzAdam use rollback for liquids; if its disabled just use the next player? 20:33 Cylus What do you mean by the "next" player? 20:34 sfan5 probably the nearest one 20:35 sfan5 if you can't find out who ignited the tnt (without doing too much work [like using rollback]) don't just blame it on the nearest player 20:35 Cylus I can see a lot of trickery being used in that. Someone sets off events, then tricks the owner into going to their area only to have the bomb go off just outside the protected range. 21:42 cg72 you could have gunpowder carry metadata(who ignites it) and transfer it as it burns to the tnt 21:48 VanessaE that would make too much sense. 21:48 cg72 lol @ VanessaE 21:48 cg72 K.I.S.S ;D 22:54 cg72 ok anyone know how to call a c++ function from lua in minetest? 23:25 Cylus cg72: That's not the hard part, that was already a part of the plan. But what happens when it isn't a *person* that lights it? Fire, lava, et cetera can also light it. 23:26 cg72 well check to see if its is a player and if not check what node did it 23:26 VanessaE then use the person who placed the gunpowder? 23:27 VanessaE it's not like there's some infinite supply of gunpowder nodes out there. sooner or later all those which have been placed without "placer" meta in them will burn up or otherwise be destroyed. 23:27 VanessaE that's assuming you can't get the placer of the lava or fire 23:27 Cylus The person placing the gunpowder may log off before it gets lit. In that case, there's no player reference to pass to .can_dig(), resulting in a server crash. 23:28 VanessaE come on, this is simple stuff here. 23:29 cg72 lol 23:29 VanessaE lava and fire can propagate their placer info just as well as burning gunpowder can 23:29 VanessaE if it isn't one of those, it HAS to be a torch 23:29 VanessaE and if it's a torch, that means it's a player wielding it, and you've got a player reference right then, at the moment the gunpowder is lit 23:30 VanessaE all you need for a protection check is a player name anyway when I last looked 23:30 VanessaE and that doesn't depend on the player being online 23:31 Cylus The reference may not be valid (the player logs out) by the time the gunpowder/lava gets to the TNT, and lava cant track player interference from Lua. 23:31 VanessaE why wouldn't it be? 23:31 VanessaE the player set the gunpowder alight 23:31 Cylus If you don't also check .can_dig(), which requires a valid player reference, chest get blone up and you lose inventories. 23:31 VanessaE their name is just as valid at the end of a 100 meter long string of powder as it is at the start 23:31 VanessaE whether they're online or not 23:32 VanessaE so then propagate the entire player object. 23:32 Cylus minetest.is_protected() isn't the issue. .can_dig() is. 23:32 VanessaE you've got one when the player sets it alight. copy the whole damn thing if you're forced to 23:32 Cylus Can the player object be propagated? I guess I can try that. 23:32 Cylus That does seem hacky though, I don't know if that will get pulled. 23:32 cg72 yes one node get the metadata from the one who lit if then the meta passes down the line 23:33 VanessaE if it's the only way to ensure that the player reference never gets lost from the beginning to the end of the operation, then that's how you have to do it. 23:33 VanessaE either that or extend the can_dig() call in the engine so that it'll accept a plain player name. 23:33 Cylus Can non-strings be stored as node metadata? 23:33 VanessaE er can_dig callback rather. 23:33 VanessaE sure 23:33 VanessaE you can store bools and other stuff too 23:33 VanessaE I forget what all can be stored 23:33 cg72 anything can be metadata 23:34 Cylus The .can_dig() function is defined by individual nodes, so redefining it would break backwards compatibility. 23:34 Cylus Okay. I'll get to work on that in a bit then. Thanks! 23:35 VanessaE I'd start looking at upgrading the can_dig callback to take just a player name first though 23:35 VanessaE it's less hacky that way 23:36 Cylus It's less hacky, but breaks compatibility. I thought that was frowned upon here, but I've been away a while, so maybe I'm mistaken. 23:36 VanessaE well I don't mean make it ONLY take a name 23:36 VanessaE I mean as an alternative 23:37 VanessaE it shouldn't be much trouble to determine in the engine if it's being handed a whole player object or just the player name as a simple string 23:37 Cylus OH! Wow, I don't know why I didn't get that. Sorry, being a bit spacey right now. 23:37 VanessaE (assuming it even needs to go through the engine and not some handler somewhere in builtin - in which case it would be easier, if slightly slower, to patch it there) 23:38 Cylus Wait, no, I was right. Because .can_dig() is defined by the node, old mods might not expect strings, but new mods might pass them in anyway. 23:38 VanessaE then pass it as another field. 23:39 VanessaE if player is nil then there must be a player NAME as the third parameter 23:39 Cylus If player is nil, old mods crash the server. 23:39 VanessaE wat 23:39 VanessaE how would an old mod crash the server? 23:39 VanessaE it'll be passing/using a whole player object there 23:39 VanessaE I think you mean an old *server* would crash :P 23:40 Cylus If you pas nil into default:chest (as an example)'s .can_dig(), the server crashes. 23:40 Cylus Oh, really? My bad. 23:40 VanessaE hrm, right. 23:40 VanessaE then it has to be caught by the engine 23:40 VanessaE no two ways around it 23:41 Cylus An engine exception seems even hackier though. 23:41 Cylus I swear, this TNT is a nightmare. 23:42 Cylus I've always thought that functions should take a string instead of a player reference though, to be honest. It would have made things so much easier in some of my old work. 23:42 Cylus *that function 23:44 VanessaE well I can see the argument for passing an entire player object, sometimes you need something other than the player's name 23:44 VanessaE but this is one case where that's all we want and it's the one thing you don't readily get 23:44 Cylus The only non-hacky way I can see to make this work is to deprecate .can_dig(), and add something new that takes strings. But that seems like overkill to deal with one little TNT problem. 23:44 Cylus minetest.get_player_by_name(name) 23:44 VanessaE so... either you catch it in the engine, or you duplicate the whole damn object and pass it along as lava, fire, or burning gunpowder spreads. 23:45 VanessaE either way is hacky. which is less evil? 23:46 Cylus I think the less evil way is to go back an do it right, dismissing compatibility issues. But judging by the code still in the engine, I'm guessing that won#'t happen. 23:47 VanessaE replacing can_dig is probably a non-starter. there's too much stuff that uses it and not enough people around who are willing to maintain those things.. 23:47 Cylus I mean, we still have references to default nodes in the engine. And what even is default:coalstone? Did we ever have that? 23:48 VanessaE that's probably coal with stone? 23:48 VanessaE if not some weird reference to what is now coalstone in the Moreblocks mod 23:48 Cylus Nope. The engine references both default:stone_with_coal and default:coalstone in the same section, if I recall. 23:49 * VanessaE looks... 23:49 VanessaE oh wow 23:49 VanessaE that's an OLD one 23:49 ShadowNinja You can do what the Technic quarry does, but that will slow down the explosion a lot. 23:50 VanessaE Cylus: yeah, I think that's a reference to the old coal-in-stone from the legacy mapgen v5 stuff 23:50 VanessaE which is still supposedly gonna be added back in some day 23:50 ShadowNinja The quarry only digs one node/sec and it only uses the LVM because it has to scan a large area for non-air nodes before deciding what to dig. 23:51 VanessaE https://github.com/minetest/minetest/blob/70074800a207974a0c1383275186cefe6955f297/src/content_mapnode.cpp#L89 23:51 VanessaE also line 55 of that file 23:51 VanessaE and one reference in the old python mapper 23:51 VanessaE that's it 23:51 Cylus VanessaE: Okay, well these days it's used to translate 0.3.* maps. Some node is translated to default:coalstone, an unknown node. 23:52 VanessaE also a reference on line 145 of that file... 23:52 VanessaE and on 195. 23:52 VanessaE (strange that github's search didn't find these initially) 23:52 Cylus And why is anything translated to default:stone? It should translate to mapgen_stone to allow for other games. (I tested this, it works.) 23:53 Cylus Yeah, that's the file used to translate 0.3.* maps. 23:53 VanessaE weird. 23:54 VanessaE eh, whatever, 23:54 Cylus It means though that dropping compatibility is out of the question. 23:54 VanessaE I don't pretend to understand the decisions that went into this piece of code ;-) 23:55 Cylus I wonder if I should just form minetest_game. Having unfettered TNT doesn't really work for me, but there doesn't seem to be a viable way to put TNT in check either. 23:56 Cylus Forking would break compatibility with third-party mods though .... 23:58 VanessaE well for your normal usecase it would be easiest to just delete the TNT mod altogether 23:58 VanessaE that's all I do 23:58 VanessaE BUT, 23:59 VanessaE if you want to fix it *right*, the only way is like I said above, and that's gonna need engine changes since lava reflow is done in-engine 23:59 VanessaE (and liquid reflow is a nasty piece of business to begin with)