| 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/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: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/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) |
