Minetest logo

IRC log for #minetest-dev, 2014-08-27

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

All times shown according to UTC.

Time Nick Message
00:00 herocraft joined #minetest-dev
00:48 cg72 joined #minetest-dev
02:14 cg72 left #minetest-dev
02:27 Miner_48er joined #minetest-dev
03:50 harrison joined #minetest-dev
04:04 hax404 joined #minetest-dev
04:29 zat joined #minetest-dev
05:42 casimir joined #minetest-dev
05:42 jin_xi joined #minetest-dev
05:44 Hunterz joined #minetest-dev
06:33 SmugLeaf joined #minetest-dev
06:33 SmugLeaf joined #minetest-dev
07:34 OldCoder joined #minetest-dev
07:53 OldCoder joined #minetest-dev
08:00 werwerwer joined #minetest-dev
08:15 RealBadAngel joined #minetest-dev
08:17 deltib joined #minetest-dev
08:17 OldCoder joined #minetest-dev
08:31 iqualfragile joined #minetest-dev
08:59 Megaf joined #minetest-dev
08:59 Megaf Morning, https://github.com/minetest/minetes​t/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:34 nore_ joined #minetest-dev
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:48 PilzAdam joined #minetest-dev
09:55 iqualfragile the bots are gone, where did they go?
10:07 casimir joined #minetest-dev
10:11 proller joined #minetest-dev
10:49 unnamed joined #minetest-dev
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 jp joined #minetest-dev
11:13 jp left #minetest-dev
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:28 proller joined #minetest-dev
11:33 ImQ009 joined #minetest-dev
11:47 iqualfragile RealBadAngel: by old light you referr to the light levels?
11:55 CraigyDavi` joined #minetest-dev
11:57 Jordach joined #minetest-dev
11:59 AnotherBrick joined #minetest-dev
12:25 iqualfragile joined #minetest-dev
12:31 jp joined #minetest-dev
12:31 jp left #minetest-dev
12:49 Amaz joined #minetest-dev
13:04 proller joined #minetest-dev
13:13 Taoki joined #minetest-dev
13:21 rubenwardy joined #minetest-dev
13:37 proller joined #minetest-dev
13:41 NakedFury joined #minetest-dev
13:46 Amaz joined #minetest-dev
14:05 hmmmm joined #minetest-dev
14:36 NakedFury joined #minetest-dev
14:55 VanessaE joined #minetest-dev
15:05 Eater4 joined #minetest-dev
15:18 FungusAdam joined #minetest-dev
15:19 rubenwardy_ joined #minetest-dev
15:21 darkrose_ joined #minetest-dev
15:22 lanxu joined #minetest-dev
15:23 werwerwer joined #minetest-dev
15:25 Garmine joined #minetest-dev
15:39 Eater4 joined #minetest-dev
15:58 Miner_48er joined #minetest-dev
16:15 loggingbot_ joined #minetest-dev
16:15 Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/
17:22 AnotherBrick joined #minetest-dev
17:22 Megaf joined #minetest-dev
17:26 jp joined #minetest-dev
17:26 jp left #minetest-dev
17:28 AnotherBrick joined #minetest-dev
17:42 HLuaBot joined #minetest-dev
17:48 dysoco joined #minetest-dev
17:54 casimir joined #minetest-dev
18:00 khonkhortisan joined #minetest-dev
18:07 proller joined #minetest-dev
18:10 Miner_48er joined #minetest-dev
18:51 khonkhortisan joined #minetest-dev
19:18 Megaf any help here? https://github.com/minetest/minetest/issues/1502
19:26 werwerwer joined #minetest-dev
19:32 AnotherBrick joined #minetest-dev
19:38 ImQ009 joined #minetest-dev
19:51 AnotherBrick joined #minetest-dev
19:56 Cylus joined #minetest-dev
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. <node def>.can_dig(). This shouldn't be too hard then.
20:07 werwerwer joined #minetest-dev
20:08 Cylus Never mind, that won't work. <node def>.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 cg72 joined #minetest-dev
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 <node def>.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.
20:45 proller joined #minetest-dev
20:51 AnotherBrick joined #minetest-dev
21:07 proller joined #minetest-dev
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 <node def>.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 <node def>.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. <node def>.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 <node def>.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 <node def>.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 <node def>.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 <node def>.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/70074800a207974a0c1383275186cefe​6955f297/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)

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