Time Nick Message 00:01 BlockMen always when i finished a build something is comitted here... 00:02 PilzAdam BlockMen, thats a feature 00:04 BlockMen i bet so 00:05 Exio4 how many seconds/minutes does it take to compile? 00:05 PilzAdam NaN, he uses MSVC 00:05 Exio4 exactly, with msvc 00:06 BlockMen :P ~10min for me 00:06 Exio4 what hardware? 00:06 BlockMen i5 2,6ghz 00:06 Exio4 k 00:07 Exio4 mobile or not? 00:07 BlockMen *m 02:44 hmmmm so weather seems to be always enabled, all the time 02:50 hmmmm can somebody please explain to me why it needs to be sent to the client in the first place? 03:19 hmmmm https://github.com/kwolekr/minetest/commit/f12078263dd56cfbfa59a140d37f7f2d14fa2dde 03:22 hmmmm https://forum.minetest.net/viewtopic.php?pid=103885#p103885 03:24 hmmmm i don't know, now i'm having second thoughts about this 03:25 hmmmm when someone uses a raw schematic specifier and they want to simply place things, right now they just have an array of {name="nodehere"}, probably. now they'd have to do {name="nodehere", param1=255} for all of them 03:25 hmmmm i don't know how inconvenient that is 03:45 kahrl hmmmm: perhaps use a different readnode that reads a missing param1 as 255? 03:50 hmmmm wouldn't it be weird if a node is different for this one particular API, though? 03:51 kahrl a bit, yes 03:56 hmmmm i'm not sure what i should do here 03:57 hmmmm should i scrap this whole thing and leave it be? or is this change good? 03:57 hmmmm i think i will use a different readnode though, as long as this exception to the rule is documented it's fine 04:05 kahrl I'm not a modder, but I prefer the new 0-255 range 04:06 kahrl huh, is MutexedQueue::pop_back used anywhere? 04:06 hmmmm the thing that the old emergethread used? i don't think so 04:07 kahrl I'm getting an error when I try to use it, in util/container.h:303 04:07 kahrl because back() does not return an iterator 04:07 hmmmm that could've been caused by thexyz's container migration 04:09 kahrl looks like it 04:16 kahrl it compiles! https://gist.github.com/kahrl/6153470 04:16 kahrl (basically an API for async curl requests) 04:16 hmmmm oh boy, DSTACK() 04:16 hmmmm haven't seen that used for a while 04:19 kahrl I felt like I might use a number of asserts in this code 04:19 kahrl .. didn't end up with as many as I thought 04:19 hmmmm well DSTACK is much more heavyweight than a couple of asserts, and from what i recall it's not very useful anyway 04:21 kahrl it's used for the stacktrace when an assert fails, given the lack of asserts I guess I can remove it 04:22 kahrl (none of these functions should be performance relevant though) 04:22 hmmmm ah.. didn't realize that 04:23 hmmmm we should have a cross between assert and dstack like ASSERTWARN(foobar != NULL, "Something isn't right"); 04:24 hmmmm this way you understand that something went wrong, where it went wrong, but without all the extra stuff with the stacktrace which might not be useful 04:26 kahrl well you can always do if (...) errorstream<<... 04:26 kahrl might not look as nice though 04:27 hmmmm well it's an if, an errorstream print, an abort, and then a closing brace so that's 1 line vs. 4 04:27 hmmmm besides, ASSERTs aren't placed if it's not compiled for debug 04:27 hmmmm or i guess not 04:27 kahrl ah, I thought with the WARN that the program would continue to run 04:28 kahrl oh and yes asserts are checked in release builds 04:29 hmmmm how does DebugStacker even work? I don't see how it keeps a backtrace 04:31 hmmmm oh, you need to have a DSTACK in every single function you'd like to keep track of 04:32 kahrl yep 04:32 hmmmm that's not very helpful though 04:32 hmmmm has DSTACK ever actually helped you solve anything? 04:33 kahrl maybe, I can't remember 04:33 hmmmm i'm thinking, what if libexecinfo is used instead 04:34 hmmmm that way you can get a complete stack traceback, and for release builds you'll still get some useful information (the largest functions will remain after optimization, obviously) 04:34 kahrl are release builds built with symbol info? 04:34 hmmmm maybe i'm underestimating how much the symbols add 04:35 hmmmm currently no 04:35 hmmmm i never actually checked the size of the executable to be honest 04:35 hmmmm alright nevermind 04:37 kahrl in any case you'd have to code this for ELF in all its variants, whatever the different BSDs use, MSVC, mingw 04:37 hmmmm libexecinfo is portable 04:37 hmmmm but nevermind that, seriously. i did not expect an executable with symbols to be 52mb 04:38 kahrl whoa 04:40 kahrl are the debug sections uncompressed? 04:41 hmmmm looks like it 04:41 hmmmm maybe that's just because of my old gcc 06:05 kahrl https://github.com/kahrl/minetest/compare/httpfetch 06:06 kahrl I need to find a server with remote_media to test ^ 06:40 kaeza kahrl, does the server need the patch? 06:41 kahrl kaeza, nope 06:41 kaeza give me a second and I'll put up a temp server 06:42 kahrl cool, thanks 06:43 * VanessaE peeks in 07:01 kaeza kahrl, 186.122.187.35:30000 07:10 kahrl I'm getting stuff like http://paste.dy.fi/Dn8 07:10 kahrl but only a few of the textures have these "ERROR" lines, most are fine 07:12 kaeza hmm... 07:12 kaeza I'm using HDX just for testing 07:13 VanessaE ok, I have a remote media server set up as well, allegedly. 07:14 kaeza could it be that HDX uses JPEG files instead of PNGs? 07:14 VanessaE indeed it does, in places/ 07:14 kaeza s/that/the fact that/ 07:17 kahrl just got an error on http://digitalaudioconcepts.com/vanessa/hobbies/minetest/media_for_curl_server/cart.x 07:17 VanessaE ah, I didn't think to copy the model files over 07:17 VanessaE but at least that means the media server is working. 07:18 kahrl ah 07:19 kahrl it seems a bit slow, though faster than the builtin media fetching, and I never measured remote_media before 07:21 kahrl I'll have to go to bed now, tomorrow I'll connect twice to VanessaE's server (with the old and the new remote_media fetcher) and compare the timings 07:21 thexyz it's probably a good idea to have something like Django's collectstatic 07:21 thexyz which'd copy all media files to some dir 07:21 kahrl VanessaE: is that ok, bandwidth-wise? 07:22 VanessaE sure 07:22 VanessaE my site is unlimited anyway 07:22 kaeza lol unlimited 07:22 VanessaE "unlimited" * 07:22 kaeza sorry, had to say it 07:23 kaeza :P 07:26 kahrl ah yeah, and it seems to be loading the missing files via the builtin method fine 07:26 kahrl I wanted to test that too 07:26 kahrl but ugh, so slow :P 07:29 VanessaE there, the files at the media server should be complete now (I uploaded them in the wrong order, default stuff wasn't being overwritten by third-party mod stuff) 07:29 VanessaE s/uploaded/copied/ 07:30 VanessaE ogg, png, .x, what else? 07:30 nore hi 07:31 VanessaE hi nore 07:31 nore Did anyone ever notice my leaving message? 07:31 VanessaE kahrl: what happens if the game server has a file that's different from what's on the media server? 07:32 kahrl good question 07:33 nore kahrl: were you able to fix the fact that some of the textures were .jpg? 07:35 kahrl nore: what's that about? 07:36 nore 07:14 07:36 nore kaeza 07:36 nore could it be that HDX uses JPEG files instead of PNGs? 07:36 nore from the logs 07:37 kahrl I haven't figured out why the remote_media on kaeza's server reported errors 07:37 kahrl (everything looked fine in-game, though) 07:39 nore From what you posted, it looks like it was that (because default_brick is a .jpg in HDX) 07:40 nore Made API to access biomes, was in the TODO list http://pastebin.com/i9A7DT7w 07:40 nore is it OK? 07:40 kahrl so the file was missing from the remote_media server? 07:41 nore kahrl: yes, it was default_brick.jpg and not default_brick.png 07:41 kahrl well, he could have copied both :P 07:41 nore you should ask him 07:41 kahrl kaeza: ^? 07:42 nore did you look at the biome access API? 07:42 kahrl nore: that pastebin looks like what hmmmm had in mind 07:42 kaeza no only .jpg 07:43 nore Should I send a pull? 07:43 VanessaE serving HDX via remote? insane :) 07:43 kaeza it is running again with only PNG files 07:43 kaeza VanessaE, 64px :P 07:43 VanessaE still insane :P 07:43 kahrl nore: I think you could just ping hmmmm when he's back 07:44 nore kahrl: is there no doc about register_biome? 07:44 kaeza anyway, the client only fetches what it needs 07:44 nore I can't even test my code... 07:44 kahrl looks like there isn't 07:46 kahrl nore: have you tried these? http://pastebin.com/1kjU5tN7 07:47 nore the ID should in fact be the name, I will change that 07:49 kahrl nore: tell hmmmm that if he's okay with your patch, then I'm okay with it too, since it seems simple enough 07:49 kahrl anyway, off to bed 07:51 nore done the change, here is the commit: https://github.com/Novatux/minetest/commit/c94f380e2d1a2af30baa653a01f3b04a2aa6a670 11:17 kaeza not sure if this helps with anything, but got these errors while connecting to a remote_media-enabled server http://pastebin.com/BaUVrwE8 11:17 VanessaE the files are there, they have appropriate permissions, and they can be downloaded via a web browser 11:20 VanessaE (the files are located at http://digitalaudioconcepts.com/vanessa/hobbies/minetest/media_for_curl_server ) 12:30 PilzAdam RealBadAngel, any news on that itemstack:get_metadata() thing? 12:35 PilzAdam https://github.com/minetest/minetest/pull/851 seems good to me, any objections? 12:42 PilzAdam updated lua-api.txt and squashed: https://github.com/PilzAdam/minetest/commit/8fe09af87ea9c902632e915d5c2f92295a24ad4a 13:27 nore What do you think of #860? 14:01 PilzAdam nore, I have tested it and it works 14:01 nore karhl is ok to merge it 14:01 PilzAdam but I wonder if any mods would like to know the biome ID 14:01 nore see the logs 14:01 nore the biome ID is its name 14:01 PilzAdam kahrl is ok to merge it if hmmmm is 14:02 PilzAdam nore, but what if I want to read it from a mod? 14:02 nore yes, do you know when hmmm will be there? 14:02 nore what do you mean, read it from a mod? 14:03 PilzAdam a field "id" in the table 14:03 nore it is field "name" in the biome definition 14:03 nore minetest.registered_biomes[biome.name] = biome 14:04 PilzAdam ah, I though the ID would be an int 14:05 nore that what at made at the beginning, but then I thought it was good like that 14:43 celeron55 DSTACK() could be removed; it hasn't been in actual use in a very long time 14:44 celeron55 it's a bit of an experiment that didn't prove to be useful 14:44 celeron55 maybe i'll do that 14:54 celeron55 328 deletions :---) i 14:54 celeron55 +'ll test if this builds 15:01 jin_xi soo, lets hope hmmmm reads the backlog 15:01 celeron55 no it didn't build; there's even more to delete 8) 15:02 jin_xi i have ported my turtle system to lua, using VoxelManip 15:02 jin_xi some remarks: would be nice if points could be added to lua VoxelAreas, as for the c++ ones 15:03 jin_xi then, if you fuck up your data in the slightest, the VoxelManip places fire 15:03 jin_xi and lots of it... 15:26 celeron55 http://paste.dy.fi/DOr 15:35 celeron55 ^ that gets rid of the DebugStack stuff; 360 lines worth of it 16:11 nore hmmmm, what do you think of #860? 16:51 nore anything about #861 too? 17:03 hmmmm ah 17:03 hmmmm 860 is good 17:03 hmmmm that's precisely what i was looking for somebody to do 17:03 hmmmm i'm surprised people are using mapgen v7 though 17:04 Calinou the same reason a few people use wayland or mir :P 17:04 Exio4 systemd or upstart* 17:05 Calinou no, these are production ready 17:06 hmmmm but v7 is a bunch of crap 17:06 hmmmm it might be better than v6 and it might be better than the older version, but it's still not exactly what i was looking for 17:10 sokomine hi hmmmm. i'm still having some issues with mapgen (flat) and not generated areas while using place_schematic. sometimes, sand and dirt look a bit strange and appear on top of the houses, while two nodes at the floor are missing 17:12 hmmmm perhaps try using mapgen v7 with the flat attribute 17:12 sokomine later on, i want to spawn these villages on a "normal" map. for that to work, i need to get the area concerned flat. what's the best way to do it? voxelmanip? what i need is a flat area of 100-400m in an otherwise non-flat world 17:12 hmmmm i suppose i could also add a v6 attribute to not flow mud 17:13 sokomine ah, so it's flowing mud that's causing the problem? 17:13 hmmmm obviously voxelmanip is the best way to do that 17:14 jin_xi im really impressed with VoxelManip, its fast and cool. Apart from when you do something wrong and it places a huge chunk of fire 17:14 sokomine sounds reasonable. need to change the area in some way anyway.....there have to be fields with corn around the city, and some more paths, and fences...a lot of work left :-/ 17:14 sokomine easy solution: remove the fire-mod :) 17:14 hmmmm jin_xi, i guess that's incentive for you to do it right 17:15 Calinou we should count the number of times jin_xi complains about it :P 17:15 hmmmm well, it's not a bug or anything 17:15 hmmmm it's just a sort of "oh, that's interesting" side effect when doing something wrong 17:16 jin_xi well, it took me some tries to get it right, as i could not find a non mapgen example of how to use it right 17:16 sokomine using voxelmanip on the area might get rid of the flowing mud automaticly i guess? so the only problem left then would be to blend the borders somehow to the rest of the terrain. but that's for the future... 17:16 hmmmm ? 17:17 hmmmm the TNT mod is a good non-mapgen example 17:17 jin_xi well, now i know 17:20 jin_xi anyways, ported the turtle thing. but doing all the matrix math in lua is not so fast 17:20 hmmmm that sucks, luajit is supposed to be great for computational kinds of things 17:21 hmmmm we were lied to :/ 17:21 jin_xi oh, not using it 17:21 jin_xi should give that a try 17:21 jin_xi also its a very naive implementation, but i cant do clever :( 17:22 hmmmm yup, definitely use luajit, your minetest experience will improve a lot 17:31 nore hmmmm, did you look at #861? 17:37 ShadowNinja How about #862. 17:40 nore good idea, but I don't know the code, so I can't tell you whether the coding is good or not 17:49 nore sokomine: to blend the borders, the best would be to use the get_surface function, because it will be difficult without it 17:51 sokomine sounds good. so there is a get_surface function now? 17:55 nore yes, it is a pull request by sapier 17:55 nore I don't think it has been merged now though 17:56 sokomine then i hope that it gets merged 18:01 nore sokomine: I will try something, using a custom mapgen... (single-layer, to test blending) 18:01 nore you will have to blend the terrain then using that method 19:28 VanessaE I've filed an issue for the *.x thing kaeza was having: https://github.com/minetest/minetest/issues/863 19:30 VanessaE bbiab 19:50 ShadowNinja Needs updating: https://forum.minetest.net/viewtopic.php?id=1378 21:14 celeron55 http://paste.dy.fi/DOr <- DebugStack removal; any comments? 21:18 PilzAdam celeron55, that patch does not apply correctly 21:21 celeron55 oh... apparently i made it on top of version bc5db9b02 21:22 celeron55 well whatever; no hurry for that 21:22 kahrl I think it should still at least show which threads are running when an assert fails 21:22 kahrl e.g. useful for stuff like the MeshUpdateThread assertion failure 21:22 celeron55 feel free to iterate on that 8) 21:26 kahrl whoa, is there no mutex for log_threadnames? 21:29 PilzAdam celeron55, here is it rebased: https://github.com/PilzAdam/minetest/commit/5e6f614349488c3c1dc0b98b08055a52e8d75780 21:29 celeron55 kahrl: apparently no :-) 21:30 celeron55 it's probably a considerable problem nowadays as there are more threads 21:30 celeron55 (started and stopped all the time) 21:31 kahrl although just adding a mutex to it might cause enough slow down to be a bad idea 21:31 kahrl maybe use TLS? 21:31 sapier1 tls? 21:31 kahrl thread local storage 21:32 sapier1 oh 21:32 kahrl so that the logger can get the current thread name without having to lock a mutex 21:32 celeron55 do we have a portable implementation for that 21:32 celeron55 if so, go ahead 21:32 kahrl I have one that works with win32 and pthreads, it's in my jthread-1.3.1 patch 21:32 sapier1 hmm at least within linux each thread has its own threadname and can access it's name but not sure if this is true for windows too 21:33 kahrl (well, I only tested it with pthreads) 21:33 sapier1 yea I meant phtreads features 21:34 celeron55 sapier1: i think it's better not use such names directly for logging so that the stuff that goes to log can be logging-optimized 21:34 sapier1 I see 21:34 celeron55 that is, user readable stuff and not some ids or long crap 21:35 sapier1 doing a syscall for each log entry obviously is a bad idea 21:35 sapier1 does jthread use pthreads threadname feature? 21:36 kahrl sapier1: I don't think so 21:37 sapier1 I missed decisio about forking/integrating jthread what has been done? 21:37 kahrl sapier1: nothing ;) 21:37 sapier1 ok :-) 21:40 kahrl https://github.com/kahrl/minetest/commit/681d6df31b672a92cd3e1618668279ad93a6cddc#L6R276 <-- very simplistic ThreadLocal class 21:40 sapier1 what about my fixes 774 640 and 418? ... haven't asked for days now ;-) 21:42 sapier1 another question why don't we just use threadid for logging? 21:43 kahrl because nobody knows what thread has what id? 21:43 sapier1 isn't tls a little bit overkill for storing "some thread type 1" to "some thread type n"? 21:43 sapier1 e.g. ":tid" 21:44 sapier1 threadtype beeing mapgen thread1 21:44 sapier1 -1 21:44 kahrl and how/where would you store type and tid? 21:44 sapier1 ok ok tid would have to be read each time again ... not best idea ... threadtyp is a fixed value that can be compiled in 21:45 sapier1 a mapgen thread will always be of mapgen type 21:45 kahrl erm 21:45 kahrl it's not fixed inside log.cpp 21:45 kahrl unless you mean to add <<"[EmergeThread"<