Time Nick Message 00:01 Warr1024 hmmmm: I thought about making "smart" defaults, but wasn't sure if the feature was mature enough... 00:02 VanessaE Warr1024: regarding the scaling, I'd personally have chosen 64px as the "sane default" also 00:03 VanessaE (though I'll still turn it up for my own box) 00:04 Warr1024 I guess it could be ok to set min_size to 1 and clean_trans to off, but set them to 64 and true if anything besides mips are enabled. 00:05 est31 what is the problem now? 00:06 VanessaE est31: no problem, per se. just a matter of the game choosing sane defaults 00:06 VanessaE Warr1024: good idea. 00:06 Warr1024 The whole "aniso implies linear" seems to be more common than not in my experience 00:06 VanessaE does setting it to 1 in fact actually "skip" the prescaling code? 00:06 VanessaE (if not, it should) 00:07 Warr1024 not explicitly, but it's a short path in practice anyway 00:07 VanessaE also I noticed where you were pulling from the settings in multiple places, instead of doing it just once and referencing the result 00:07 VanessaE you may want to fix that 00:08 Warr1024 it should be only once per image, but I wasn't sure the convention for doing it once per game 00:09 Warr1024 zeno mentioned that too, but said it'd br easy enough to fix later... 00:09 VanessaE yeah. there's a push to just do *all* of the settings in some kind of once-at-the-start construct, but idk what the final decision is on that 00:10 VanessaE (well all of those which can be done only at the start anyway) 00:11 Warr1024 might not be too bad to have a few caches by type of the already-parsed values, and invalidate them upon setting one 00:12 Warr1024 would be a nice encapsulation too... 00:17 est31 hmmmm, can you close #2449 please? Commit at latest head fixes that. 00:17 ShadowBot https://github.com/minetest/minetest/issues/2449 -- Eating not updating hud 00:31 WarrTab Progress on the gui scaling 00:31 WarrTab It now kinda works a little on android 00:31 WarrTab Rtt's don't work 00:32 WarrTab Though inventorycube was always broken, but now rtt's are too... 00:32 WarrTab But all 2d stuff seems to be good... 00:32 VanessaE sapier ended up having to resort to a really nasty hack with RTT: 00:32 VanessaE exploit the screenshot function. 00:33 VanessaE at least at one point he did 00:33 WarrTab I think it's still quite hacky 00:33 WarrTab I wonder how inventorycube differs 00:33 VanessaE I forget why he did that, though 00:34 WarrTab And why it never worked 00:34 WarrTab I think fixing gui scaling might involve fixing rtt on android 00:35 WarrTab I might try just writing a really simple naive renderer to prove its doable... 00:47 WarrTab Oh god why does ^[inventorycube not use the rtt code above that at least has working hacks, even if they're hacks? 00:47 VanessaE why is anything still *using* ^[inventorycube at all? 00:48 WarrTab I used it 00:48 VanessaE you shouldn't need it at all anymorpe 00:48 VanessaE anymore* 00:48 WarrTab I wanted a craftitem that looked like a node, bit wasn't 00:48 VanessaE ah 00:48 VanessaE well I guess for that, it's useful 00:49 WarrTab also if you want yo overlay some 2d over a fake-3d node 00:49 VanessaE but for example default glass still uses it for no reason 00:49 WarrTab Though it won't work with nodebox 00:49 VanessaE inventory_image = minetest.inventorycube("default_glass.png"), 00:49 WarrTab Or really most drawtypes 00:50 WarrTab no, that inventorycube on glass actually DOES have an effect... 00:50 WarrTab ...it pisses off android users :-) 00:50 VanessaE HAHA 00:51 WarrTab In principle I should be able to make inventorycube work on android, though, by refaccing and reusing the hacked-but-working code above 00:52 WarrTab When sapier tested this, he must have ised bars in his windows instead of glass :-) 00:53 WarrTab I suspect that the issue with the rest of shit might be memory aliasing... 00:56 VanessaE lol 01:06 WarrTab Or use-after-free, maybe 01:06 WarrTab The irrlicht refcounting stuff is a bit arcane 01:48 WarrTab Ok, I'm tempted to just say "doesn't work on android for now" and leave it at that... 01:49 WarrTab Basically, I don't know if the bug in guiscaling on android can be fixed without fixing the other bugs anyway 01:50 WarrTab Fixing rtt and inventorycube on android might be beyond me 01:51 WarrTab Or at least I'll need to make incremental builds for android work for me 01:53 WarrTab Maybe if I ger it working well enough for desktop, one of the android experts in here can help me figure out the android issues 04:02 hmmmm https://github.com/kwolekr/minetest/commit/2267313eb0343ffa6a7586aab93afad1b00358c5 04:19 Zeno` https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/rand_r.c;h=1098ffb7451b3f4ea042cac83f14a47470db21ce;hb=HEAD 04:19 hmmmm ? 04:19 Zeno` The example in K&R actually seems to be that used by ANSI-C :-o 04:19 Zeno` (that's the re-entrant version) 04:20 hmmmm what why... 04:20 hmmmm there are so many BETTER random algos out there 04:20 Zeno` I suppose so that rand() is consistent across platforms :/ 04:21 Zeno` I never realised rand() was so bad 04:21 hmmmm well 04:22 hmmmm I took the bottom 8 bits of that rand's output for each byte printed to stdout when I tested it using dieharder 04:22 hmmmm and it failed over half the tests 04:22 hmmmm imagine if i used all 15 bits of enthropy 04:24 Zeno` yeah. BSD uses the same 04:24 hmmmm *freebsd*? 04:25 hmmmm I tested my libc's rand too and it passed everything 04:25 Zeno` weird 04:25 hmmmm the way glibc and bsd libc use it must make a huge difference 04:25 Zeno` must do 04:25 Zeno` anyway your fork looks good 04:26 hmmmm now all I need to do is convince modders to use PcgRandom instead 04:26 Zeno` http://svnweb.freebsd.org/base/head/lib/libc/stdlib/rand.c?view=markup 04:26 Zeno` there is an #ifdef 04:27 hmmmm yeah 04:27 hmmmm oh yeah I remember looking at this when I was doing tests initially 04:27 hmmmm Zeno`, you should try running glibc rand() in dieharder since you use linux :-) 04:28 Zeno` i think I might :) 04:28 hmmmm #include #include int main(int argc, char *argv[]) { srand(time(NULL)); while (1) putc(rand() & 0xFF); } 04:28 hmmmm then ./yourprog | dieharder -a -d 200 04:29 hmmmm or, well, maybe you should use more than the bottom 8 bits, but you get the idea 04:29 Zeno` grrr... is there a non-svn link to download dieharder? 04:30 Zeno` meh, I have svn installed anyway 04:30 hmmmm no idea.. i got it from pkg 04:31 Zeno` oh 04:31 Zeno` I can as well :) 04:31 Zeno` didn't expect it to be there 04:33 Zeno` I will use putchar instead of putc 04:34 Zeno` seems to take a while to run 04:34 hmmmm oh yeah it does 04:34 hmmmm about 40 minutes on my xeon e3-1230v2 04:35 Zeno` everything passed so far 04:35 hmmmm btw read http://www.pcg-random.org/pdf/toms-oneill-pcg-family-v1.02.pdf if you're interested 04:35 Zeno` wait a sec... is this working? 04:36 Zeno` I'll dpaste 04:36 Zeno` http://dpaste.com/39F1J18 04:36 Zeno` why is it using mersene twister? 04:37 hmmmm did i give you the wrong command line params? uh oh 04:37 * hmmmm checks 04:37 hmmmm yes i did. should be -a -g 200 :( sorry 04:37 Zeno` ok restarting :) 04:38 Zeno` MT is doing well though 04:38 hmmmm ahh I said -d 04:38 hmmmm yeah of course 04:38 hmmmm personally, when i tried it, it only got two "weak" ratings 04:39 Zeno` only had one weak when i stopped it: sts_serial| 15| 100000| 100|0.99649720| WEAK (obviously would be the same as your result) 04:39 Zeno` I'm guessing glibc must do something different as well because they're all passing for now 04:39 * Zeno` downloads glibc source so he can look more closely 04:40 hmmmm i doubt it changed from the link you pasted 04:40 hmmmm how are you printing it to stdout? 04:40 Zeno` putchar 04:40 Zeno` int main(int argc, char *argv[]) { srand(time(NULL)); while (1) putchar(rand() & 0xFF); } 04:40 hmmmm oh okay 04:40 hmmmm so you're only using the low 8 bits too 04:41 Zeno` perhaps fedora uses a modified glibc (wouldn't surprise me, lol) 04:41 hmmmm unless i'm misunderstanding something, the only difference between the glibc and the minetest rand is that glibc is skipping 2 numbers per call 04:41 hmmmm or maybe that RNG is a lot stronger than we thought, and minetest just implemented it in a weak manner 04:45 hmmmm shoot =] 04:45 hmmmm I just noticed a problem I introduced when cleaning up PseudoRandom 04:45 Zeno` maybe 04:46 Zeno` it's doing the rgb tests now and only one failure 04:49 hmmmm https://github.com/kwolekr/minetest/commit/3993093f51544d4eb44efb57c973e29107ea2f7a 04:49 hmmmm I keep using uintXX_t instead of uXX 04:51 Zeno` wtf are these rgb_lagged_sum tests doing 04:51 Zeno` they take longer than the rest combined 04:55 hmmmm I think it's trying to correlate X length bitstrings with the rest of the output 04:56 Zeno` unless something else is "weak" from this point on everything but one passed 04:57 * Zeno` wonders if glibc uses something different... it must 04:57 Zeno` after this I'll copy paste some algorithms 04:58 hmmmm yeah, minetest's rendition had almost half of the results as failures 04:58 Zeno` second failure 04:58 hmmmm and as far as i can tell there's no functional difference between the two aside from glibc skipping two randoms 04:59 Zeno` http://dpaste.com/1SQ794C 05:00 Zeno` This is annoying. Now I have to find out what rand() is using :( 05:02 Zeno` err 05:02 Zeno` https://github.com/lattera/glibc/blob/master/stdlib/random_r.c 05:02 Zeno` https://github.com/lattera/glibc/blob/master/stdlib/random_r.c#L371 05:02 Zeno` I wonder how it chooses what "type" to use 05:03 hmmmm well it looks like you were testing "our fancy trinomial stuff" 05:04 Zeno` yes I think so :D 05:08 Zeno` god I hate the GNU brace style 05:18 Zeno` lol 05:18 Zeno` I am getting much better results now 05:19 Zeno` http://dpaste.com/0NADT7P 05:19 Zeno` (src included). Nothing passed so far. This is great 06:11 hmmmm argh 06:12 hmmmm dammit, paramat, why didn't you make generate_ores/decorations have p1 p2 be optional 06:25 Zeno` https://github.com/kwolekr/minetest/commit/3993093f51544d4eb44efb57c973e29107ea2f7a#diff-394cf121b2cc4085d04fc6487fdfadbfR109 06:25 Zeno` Please put semicolon on next line :) 06:26 Zeno` hmmmm ^^ 06:26 hmmmm okay 06:34 Zeno` hmmmm, what is randNormalDist() ? 06:34 hmmmm hey i thought you reviewed it already 06:34 Zeno` and why is accum u32? 06:34 Zeno` I am re-reviewing :) 06:35 hmmmm good catch 06:35 hmmmm i had an internal debate on what datatypes i should be using 06:35 hmmmm i must've changed my mind 50 times over 06:35 hmmmm "naw, let the caller adjust the range if they want something negative" 06:35 hmmmm "naw, let's be consistent with PseudoRandom" 06:36 hmmmm "yeah, but this interface is imposed on the lua api too 06:38 Zeno` lol 06:39 Zeno` *sigh* /me writes types.h so he can extract the code and test it outside of minetest 06:39 Zeno` I was re-reviewing because I read some articles about the method you're using btw ;) 06:39 hmmmm use uint32_t instead, i dare ya 06:39 Zeno` it's pretty interesting 06:40 hmmmm watch the reports about "it doesn't compile on debian Slow Snail v7.0 06:40 Zeno` it doesn't have stdint.h? 06:41 hmmmm the stdint.h include doesn't propogate its way to where it's being used *on their system* 06:41 Zeno` their system must be broken 06:41 hmmmm due to some very specific combination of platform and standard header versions 06:41 Zeno` next! 06:41 hmmmm also: windows. 06:42 Zeno` broken 06:43 Zeno` seems I already have a types.h 06:43 hmmmm #include 06:44 Zeno` http://dpaste.com/3A7WKXF 06:44 Zeno` broken on windows and debian 06:46 hmmmm whoops. I see a bug 06:47 hmmmm great job, you were supposed to review my code! 06:47 Zeno` I found one bug 06:47 Zeno` umm, why is github not letting me look at the raw file :/ 06:48 hmmmm didn't update len if out is unaligned in PcgRandom::bytes() 06:48 hmmmm ooops. 06:58 Zeno` hmm 06:59 Zeno` hmmmm, is it updated now? 06:59 hmmmm https://github.com/minetest/minetest/commit/761b127060b924a43a79c72d5488dbe9c186acc0 07:04 Zeno` nope it's no goof 07:04 Zeno` good* 07:04 Zeno` diehard_operm5| 0| 1000000| 100|0.99994079| WEAK 07:04 hmmmm all prngs get at least 4 weaks 07:04 Zeno` ok I'll let it have a few 07:05 hmmmm the point is that it's a massive improvement over minetest's original algorithm that were half failures 07:05 Zeno` of course ;) 07:06 Zeno` Is it fast enough? 07:07 hmmmm i dunno it's just a bunch of bitshifts 07:07 hmmmm it should be okay 07:07 Zeno` nevermind, starting test again (forgot -O2) 07:08 Zeno` yeah it's fast 07:08 hmmmm F... i see another bug 07:09 hmmmm dammit zeno i thought you reviewed my stuff!!! 07:10 hmmmm heh, can you find it? it's in PcgRandom::bytes() again 07:11 Zeno` I didn't know the algorithm in first review! :P 07:11 hmmmm well this doesn't have to do with the algorithm itself, just how i blit data 07:12 Zeno` r = next()? 07:13 Zeno` nope I can't see it 07:14 hmmmm endianness 07:14 Zeno` ok, yes :) 07:14 hmmmm i can see the PR, "help, on android all my maps are different!" 07:15 hmmmm "there's a cave always at (x, y, z) using seed = 123 when I play on android, but it's different on PC!" 07:15 Zeno` feature? 07:16 hmmmm oh no no 07:16 hmmmm i keep forgetting, minetest PR == Pull Request, work PR == Problem Report 07:17 Zeno` haha 07:17 hmmmm well I suppose we love adding problem reports here at minetest inc. 07:17 VanessaE well with minetest, doesn't the former lead to the latter anyway? :P 07:17 Zeno` true, true 07:18 hmmmm VanessaE: yeah it does 07:19 hmmmm oh. yeah. 07:19 hmmmm VanessaE: you should switch from PseudoRandom to PcgRandom in your mods 07:20 VanessaE that would be plants_lib, only place I use random numbers. ok, will do. 07:20 hmmmm also take a look at PcgRandom.rand_normal_dist(). in laymans terms, you won't have an equal number of cacti that have height of 1, height of 2, etc. 07:21 VanessaE are you employing that algo in things like the spawn_tree() call also? 07:21 hmmmm you'd have by far the most of them "in between" min and max, and as the values get more extreme, they occur rarer 07:21 hmmmm not yet, still need to do that 07:21 VanessaE ok 07:22 VanessaE actually you know what, I actually use math.random() everywhere, not even PseudoRandom. 07:22 hmmmm oh, that's totally uniform then 07:23 hmmmm well, you can do the same thing that rand_normal_dist does internally to get the same kind of bell-curved distribution of random samples 07:25 Zeno` this is much faster than math.rand() (well, excluding the rand_normal_dist()) 07:25 Zeno` heaps faster 07:25 VanessaE sounds like a good idea to switch then. 07:25 Zeno` that means a lot 07:25 hmmmm scratches head 07:25 VanessaE (I've no real need for uniform distribution) 07:26 hmmmm math.random() is that slow??? 07:26 Zeno` it's not *that* slow, but compared to this it is 07:26 hmmmm that's incredible. i never would have expected that 07:26 Zeno` must be those fancy trinomials 07:26 hmmmm lol 07:29 Zeno` rand() calls three libc functions: rand, random and random_r with a summed cost of 50.5% 07:30 Zeno` PcgRandom::next() costs 20.6% 07:31 Zeno` (these are self costs) 07:31 hmmmm heh you certainly do love your callgrind 07:31 Zeno` which in this case is the same as inclusive anyway 07:31 Zeno` well, I had to check! 07:31 Zeno` can't have slow crap being added 07:31 Zeno` heh 07:32 * Zeno` will give it a tick of approval 07:32 Zeno` it's like a stamp of zenoness 07:33 hmmmm you know i actually put PseudoRandom into its own executable and, lo and behold, even after -O3 on the most current gcc and clang available to me, it will not inline 07:33 Zeno` VanessaE, I'm talking about rand() because Lua uses standard C's rand() C-side 07:33 hmmmm i tried even using the inline keyword and it simply won't take the hint 07:33 Zeno` I dunno if it needs any inlining :P 07:34 Zeno` C-side, by the C-shore 07:34 hmmmm yeah.. that was part of the internal debate 07:34 hmmmm should PcgRandom be a derived class of PseudoRandom 07:34 hmmmm "but wait, then I'd have to either change PseudoRandom's output or truncate PcgRandom's output" 07:34 hmmmm "but it's so much neater!" 07:35 Zeno` The only thing I might potentially worry about is the 64-bit operations but I had a huge debate with someone over this when I was doing my mersene twister and it wasn't really resolved 07:35 Zeno` worry about performance wise* 07:35 Zeno` but *shrug*; I doubt it matters 07:36 hmmmm most of the world is on 64 bit by now i think 07:36 Zeno` well, my watch isn't! 07:36 Zeno` actually my watch is analogue 07:36 Zeno` probably won't affect my watch 07:37 hmmmm the first time I installed a 64 bit operating system 07:37 hmmmm i though, phew, i have arrived into the future! 07:37 VanessaE ...and then you had to install win32codecs or flash plugin. :) 07:37 hmmmm wine was the big killer for me 07:37 Zeno` fedora doesn't even install 32-bit compat libs by default anymore 07:37 hmmmm i somehow got it working 07:38 VanessaE (those fucking things kept me from going 64bit for the longest time, until distro maintainers figures out the whole multiarch thing) 07:38 Zeno` VanessaE, there's no 64-bit flash plugin? 07:38 hmmmm FreeBSD 32 bit Linuxulator works fine :) i don't think i ever had a flash problem with 64 bit 07:38 VanessaE Zeno`: not sure, but there wasn't back then 07:38 Zeno` oh back then... yeah 07:40 * Zeno` hopes this new PRNG doesn't affect his framerate when playing on his Eee PC 07:40 Zeno` it's already only 1fps; could make it unplayable 07:40 hmmmm don't get why people try to play minetest on these super low-end machines 07:40 VanessaE Zeno`: oh that reminds me, Warr* mentioned that his guiscaling patches may have caused a framerate drop because of the compositing workaround e.g. signs. can you confirm that? 07:41 hmmmm they probably think it works in theory 07:41 VanessaE (I can't be sure) 07:41 hmmmm why would that cause a framerate drop? it's only applied during texture loading, isn't it? 07:42 VanessaE hmmmm: because part of it has to be deferred until after all of the compositing stuff has been done (e.g. ^[combine and the like). 07:42 hmmmm surely the result would become cached 07:42 hmmmm i hope 07:42 VanessaE idk what effect that has in the end, if any 07:42 VanessaE I don't think so 07:42 hmmmm sweet 07:42 VanessaE if RBA were here he'd know the answer to that 07:43 VanessaE his theory is that the client burns through all of the compositing commands in realtime, every frame, and doesn't cache/reuse the results 07:43 VanessaE and that *that* is why lots of signs_lib signs will kill FPS (e.g. VE-S spawn area) 07:44 hmmmm i sort of accepted a long time ago that i'm never going to get a decent play experience on multiplayer 07:47 VanessaE I think Warr's observed lower FPS (if legit) is probably just the result of having higher resolution textures everywhere including the signs' entities, probably nothing to do with where the scaling is in the compositing chain 07:48 Zeno` VanessaE, I'll look later 07:48 Zeno` right now I am heading off to do stuff outside (*gasp*) 07:48 Zeno` sleep well 07:49 hmmmm night 07:49 hmmmm i should get going tooo 07:49 hmmmm night vaness 07:49 hmmmm a 07:49 VanessaE night 07:49 VanessaE I'm off also 07:49 hmmmm need to make my new bedtime be 3 am instead of 4 07:49 hmmmm hard to break the habit though, nawmean? 07:49 VanessaE yup 07:49 VanessaE but if you did that, 07:50 VanessaE we wouldn't have had this chat ;) 07:50 hmmmm :D 07:50 VanessaE anyway, night 07:50 hmmmm night 08:53 nrzkt new stats: 185 installations on playstore :) 09:23 nrzkt can somes help me to find a function name for #2525 ? :) 09:23 ShadowBot https://github.com/minetest/minetest/issues/2525 -- Some builtin cleanup since recent changes by nerzhul 09:39 nrzkt VanessaE ? 09:39 VanessaE hm? 09:39 nrzkt i looked at the spawnpoint bug you mentionned, and i think it's older clients only 09:40 nrzkt because the 0.4.10-12 clients use the spawnpoint given by the server, but not older clients 09:41 VanessaE ohh 09:41 nrzkt but i think we can "cheat" and force the position after _init to restore the function for older clients, but i need to test if this doesn't glitch the client 09:42 nrzkt for < 0.4.10 haven't checked, but look at this as a proof: https://github.com/minetest/minetest/blob/master/src/network/clientpackethandler.cpp#L106 09:43 nrzkt pktSize > 7 on the recent clients, but not olders which ignore this param and following too 09:43 VanessaE well it happens with current HEAD also 09:43 VanessaE (client) 09:43 nrzkt oh ? okay, then, i need to find the real issue. Is this random or can i reproduce it easily ? 09:44 VanessaE it's random-ish. try joining my creative server. it will take several tries because of the ghost entity delete bug causing you to time out. you'll eventually find yourself spawned at 0,0,0 09:44 VanessaE (that bug is not your fault) 09:44 nrzkt strange, the static_spawnpoint param is only used un builtin lua, not in core itself 09:45 nrzkt then it's not a bug with network but with core 09:45 nrzkt core-lua 09:45 VanessaE (you'll know it's 0,0,0 because there will be a sign on a gold block saying something about "an 'original'" something. 09:45 VanessaE ) 09:47 Zeno` why is it 7? 09:47 nrzkt https://github.com/minetest/minetest/blob/master/builtin/game/static_spawn.lua 09:47 nrzkt it's handled here 09:48 nrzkt it's correct for me, i look at the register_on_newplayer in core 09:48 nrzkt register_on_newplayer doesn't exist in core ? 09:49 VanessaE it isn't limited to new players actually 09:49 nrzkt we have an api but no call, i look at this, how can this be working 09:49 VanessaE regular players get teleported there too 09:49 VanessaE idk why I said new players before, that was a mistake. 09:50 nrzkt in stable-0.4 register_on_newplayer isn't in core too 09:50 nrzkt how can this be working 09:56 Zeno` looks like it's a Lua callback 09:56 nrzkt yes, but this callback doesn't exist in core 09:56 nrzkt neither in master nor in stable-0.4 09:56 Zeno` doesn't have to... it's registered 09:56 Zeno` so the C++ calls the registered function on server step 09:57 Zeno` registered Lua function* 09:57 nrzkt but where does the core call it ? 09:58 Zeno` builtin/game/register.lua:core.registered_on_newplayers, core.register_on_newplayer = make_registration() 09:58 nrzkt oh i understand now :) 09:58 nrzkt registered_on_newplayers :) 10:01 nrzkt then the problem is on player creation/load 10:01 nrzkt because position is correctly sent to client, then the position isn't correctly collected 10:01 nrzkt it's not the network 10:01 Zeno` seems like a strange way to do it, but I don't know much about Lua 10:02 kilbith you're too old :P 10:02 Zeno` haha :P 10:02 Zeno` thanks gcu 10:02 Zeno` err, I mean kilbith 10:02 nrzkt the problem is here i think: Server::emergePlayer 10:04 nrzkt i think we must rework the player handling on server, we have two way to manage them it's not good and can cause problems in handling. We can manage them by name or by peer_id 10:04 Zeno` add infostream << "Client: received player pos" << ......... 10:04 nrzkt findSpawnPos 10:04 Zeno` so that we can get more detailed information 10:04 nrzkt just lol :p 10:04 nrzkt / Try to find a good place a few times 10:04 nrzkt for(s32 i=0; i<1000; i++) 10:05 nrzkt after 1000 attemps, the nodepos is set to 0,0,0 10:05 nrzkt i think the problem is here :) 10:05 nrzkt the static_spawnpoint is not used here 10:06 nrzkt it's why the problem is so random 10:06 nrzkt this function is called by emergePlayer when create a player 10:06 Zeno` I don't get it 10:06 nrzkt and also on respawn 10:07 nrzkt server.cpp L3183 10:07 Zeno` how was it ever working in that case? 10:07 nrzkt since a long long time 10:07 nrzkt the bug is present since many months as users reports 10:10 nrzkt then, i will fix the problem with this function and show you a patch Zeno` 10:11 Zeno` It's not a race condition is it? 10:12 nrzkt it's not a concurrence problem, no 10:13 nrzkt in fact there are two cases on which this function is called and can setp layer to 0,0,0: if he's a new player and we don't find a random place or if player respawn but we don't find a lua call which permit to replace the player 10:24 fz72 Something related to spawnpoint. Is it possible to set a static spawnpoint per world? I thought of implement an option for this in world.mt 10:25 Zeno` errr. you can have different minetest.conf for every world 10:25 nrzkt i think it's possible if we can do it with enable_damage 10:26 nrzkt yes, but some settings are set to world.mt now :) 10:26 nrzkt it's useful for regular clients 10:30 nrzkt Zeno`: okay for https://github.com/nerzhul/minetest/commit/0e446b4b371b6c0a6744076887c1f0d202d76c09 ? 10:33 nrzkt or nore, or kahrl or anybody eslse 10:33 nrzkt this commit set the spawnPoint to static_spawnpoint. If the server doesn't find a proper spawnpoint for players after 1000 loop occurences we return static_spawnpoint instead of 0,0,0 10:34 Zeno` not really; why does it have to do the loop if it's already know? 10:34 nrzkt because the server spawn you randomly 10:34 Zeno` so it ignores static_spawnpoint? 10:34 nrzkt if you die on non creative servers you spawn at different points 10:34 nrzkt yes, it was always like this. Mods can override this 10:35 fz72 I'm voting for more world specific configs. For example you change freemove or fastmove for all worlds and not only for the actual world. 10:35 Zeno` err, https://github.com/nerzhul/minetest/blob/0e446b4b371b6c0a6744076887c1f0d202d76c09/src/server.cpp#L3191 <-- what does that actually achieve then? 10:36 nrzkt we look if static_spawnpoint is set and transform the V3F to V3S16 because we cannot read V3S16 into the config and static_spawnpoint is a V3F 10:37 nrzkt if no static_spawnpoint set, then the 0,0,0 stays, because nobody tells us what is the spawnpoint :) 10:39 nrzkt it's the correct answer to you question ? 10:40 Zeno` well not really; I'm not sure how this makes a difference because of https://github.com/nerzhul/minetest/blob/0e446b4b371b6c0a6744076887c1f0d202d76c09/src/server.cpp#L3215 10:40 nrzkt this is not the problem 10:41 Zeno` well it is because the value you set earlier for nodepos is overwritten for every iteration of the loop isn't it? (well, those when the two continues were not triggered) 10:41 nrzkt you are right... 10:42 nrzkt then maybe we need to set the test at the end of the function 10:42 nrzkt i don't see any other spawn check in the code it's the only place where we spawn player 10:44 nrzkt hmmm Zeno 10:44 nrzkt if we match every continue that can happen 10:44 nrzkt then the fix is correct 10:45 nrzkt the problem can happen in rare cases, if the 1000 loop occurences match the underwater and high places 10:45 nrzkt nodepos is not overwritten in that case 10:47 Zeno` well yeah 10:47 Zeno` I guess I just don't understand that whole function 10:47 Zeno` I don't mean the code 10:47 nrzkt but the behaviour of static_spawnpoint is not to respawn on spawnpoint when a player is created ? 10:48 nrzkt and when player die ? 10:48 Zeno` well that's what I mean... isn't a new player always supposed to go to static_spawnpoint? 10:48 nrzkt https://forum.minetest.net/viewtopic.php?pid=93479 10:49 nrzkt PilzAdam uses a mod, but we have the function in core too 10:49 Zeno` # If this is set, players will always (re)spawn at the given position 10:49 Zeno` #static_spawnpoint = 0, 10, 0 10:49 nrzkt and if the mod sets the spawnpoint this function is not matched. 10:50 nrzkt right, then i think we must change the code, no ? 10:50 nrzkt it's a bug on the parameter, we doesn't respect its behaviour 10:50 Zeno` but your change will not behave like that 10:50 nrzkt no, right, but older code no 10:51 Zeno` your change will put the player at static spawnpoint only if none of the random ones are ok 10:51 nrzkt right 10:51 nrzkt like the previous code do, i only fix the 0,0,0 problem here 10:51 Zeno` Well I officially don't understand :) 10:53 Zeno` i.e. why send to a random location if static spawnpoint is set? 10:53 nrzkt because we don't do what we should do ? :p 10:54 nrzkt https://github.com/nerzhul/minetest/commit/3ed403a7a4b6c09347c323cd816da1b1e1919886 10:54 nrzkt i changed the code to respect static_spawnpoint function 10:55 Zeno` well, that makes more sense to me 10:55 nrzkt VanessaE, fz72, kilbith, other guys does this make sense for you ? 10:56 Zeno` why is the other return intToFloat(nodepos, BS); ? 10:56 Zeno` oh I see 10:56 nrzkt because pos = pos * BS 10:57 nrzkt and the function also do the conversion 10:57 Zeno` yeah 10:58 Zeno` I can't agree to the change because I don't know enough about what's going on here, but at least it makes sense now :) 10:59 nrzkt i do a PR, then 10:59 Zeno` probably best. I actually don't even know the issue number you're fixing :D 10:59 Zeno` although I read the logs so I know generally what you're doing 10:59 Zeno` hehe 10:59 nrzkt :) 11:03 nrzkt Zeno` can you review #2525 11:03 ShadowBot https://github.com/minetest/minetest/issues/2525 -- Some builtin cleanup since recent changes by nerzhul 11:03 nrzkt the fix we talked about is #2526 11:03 ShadowBot https://github.com/minetest/minetest/issues/2526 -- findSpawnPos must use the static_spawnpoint to set the player position by nerzhul 11:08 Zeno` The thing I don't get is why static_spawnpoint has worked in the past without this fix 11:09 nrzkt maybe because everybody uses mods ? 11:11 Zeno` but it's part of builtin 11:11 Zeno` isn't it? 11:12 nrzkt yes: look at void Server::RespawnPlayer(u16 peer_id) => bool repositioned = m_script->on_respawnplayer(playersao); is prior to this function 11:15 nrzkt i will push a little cleanup on network code, an unused function and i make oldForgePacket more atomic, using Buffer instead of SharedBuffer, it's a first step 11:17 Zeno` the code is all over the place :/ 11:17 nrzkt :p 11:21 Zeno` server.cpp line 3335 11:21 Zeno` that *should* handle the static spawnpoint 11:21 nrzkt in the dedicated_server_loop ? 11:22 Zeno` in emergePlayer() 11:22 nrzkt it's already done, we call findSpawnPos for new players 11:22 nrzkt the spawn point is for new or dead players, not connecting players 11:22 Zeno` yeah and then it's run/reset again 11:23 Zeno` I can't even trace this code, lol 11:23 * Zeno` gives up 11:23 nrzkt we call on_newplayer there... this function call lua which looks at the static_spawnpoint if i remember, then the Lua code has problems ? 11:24 Zeno` not 100% sure 11:24 Zeno` it calls the registered_on_newplayers Lua function 11:33 Zeno` well, I have a headache now so I think I must lie down for a bit. bbl 12:04 Calinou can the Calinou server either be renamed or banned from the list? 12:04 Calinou it's not started by me 12:15 Calinou nevermind 12:28 fz72 maybe all settings that are changed and are world related should be saved in the world specific minetest.conf 13:06 nrzkt somes have already experience view range problems on specific accounts ? 13:08 Krock view range problems like...? 13:09 nrzkt my wife has a problem, she view at 30m range with her account but if she use another account she doesn't have problem. Only her account is affecter, also after a server reboot... 13:15 Calinou force a specific view range 13:15 Calinou viewing_range_nodes_min = 100 13:17 nrzkt client side, right ? 13:18 nrzkt but it's very strange this occurs only on my server with her account, not other accounts, is there any cache somewhere for this ? 13:23 Calinou yes, viewing range is client-side 13:23 Calinou there is no cache 13:23 Calinou the autotuner bases itself on framerate, compared to wanted_fps (default: 30) 13:28 nrzkt i see 14:05 Zeno` Any comments on #2402? 14:05 ShadowBot https://github.com/minetest/minetest/issues/2402 -- Clean up and tweak build system by ShadowNinja 14:06 nrzkt no new comment for me 14:09 Zeno` any reason why it hasn't been merged? 14:10 nrzkt last comments 5 days ago, no new discussion about it 14:18 hmmmm i wonder why proller is mad about this 14:20 Zeno` lmao... github has gone mad 14:21 hmmmm >:-(!! 14:21 Zeno` they must have hired a junior 14:22 Zeno` anyway referring to your comment, hmmmm, I find the #else inline with the rest of the code kind of makes it hard to read 14:22 Zeno` s/inline/in line 14:22 hmmmm if you want to change it, we can make a decision to change it from here on 14:22 Zeno` It should be discussed 14:23 hmmmm sure.. it's just that i don't have enough of an opinion to care 14:23 Zeno` :D 14:23 hmmmm it's the standard that # is the first character of the line, so we should be standards compliant 14:23 hmmmm anybody have a rebuttal? :/ 14:23 Zeno` it's pre-89 "standard" 14:23 Zeno` but many, many, many, people still follow it 14:24 hmmmm don't think it was ever changed. 14:24 hmmmm lemme check 14:24 Zeno` I think it has but I think that the pre-ANSI requirement made more sense 14:25 Zeno` so, I'd vote for adding it as a style guideline for sure 14:25 hmmmm yeah, you're right 14:25 hmmmm that rule is outdated and clearly not the case these days 14:26 hmmmm A preprocessing directive consists of a sequence of preprocessing tokens that begins with a # preprocessing token that (at the start of translation phase 4) is either the first character in the source file (optionally after white space containing no new-line characters) or that follows white space containing at least one new-line character, and is ended by the next new-line character. 140) 14:28 hmmmm ugh when is this ever gonna get fixed https://github.com/minetest/minetest/commit/61f2d0ca3417b2a18a60015bf5423629d81bb754#diff-4f2cf5d1d78044ecd5922286ee4d371bL2917 14:29 Zeno` yep. I really only CC'd you because I thought we were talking about it the other day (but it may have been someone else I was talking to) 14:29 hmmmm we were 14:55 nrzkt hmmmm can you look at #2526, we talk about the static_spawnpoint feature 14:55 ShadowBot https://github.com/minetest/minetest/issues/2526 -- findSpawnPos must use the static_spawnpoint to set the player position by nerzhul 15:02 nrzkt do you agree with reverting 467fc0ddc912ae38c3bf9fcb99e0b66d7478eec0 ? 15:28 Zeno` heh, paramat reopened a PR and just about when I was about to close it again he re-closed it 15:31 Zeno` unrelated, but I am very wary of 2526 (sorry nrzkt) 15:32 Zeno` It really doesn't seem to be the root cause of the issue 15:32 Zeno` what issue does it address anyway? 15:33 nrzkt you may be right because lua code is correct 16:00 Zeno` nrzkt? 16:00 nrzkt yes ? 16:00 Zeno` what is the issue/bug report that 2526 is trying to fix? 16:01 nrzkt new players and respawning players which are teleported to 0,0,0 instead of static_spawnpoint 16:01 Zeno` link? 16:01 est31 #2526 16:01 ShadowBot https://github.com/minetest/minetest/issues/2526 -- findSpawnPos should use the static_spawnpoint to set the player position by nerzhul 16:01 nrzkt read at IRC logs, nobody made issue 16:01 nrzkt or talk with vanessaE 16:01 Zeno` ok, if there is not issue it's unconfirmed I think 16:01 Zeno` VanessaE, please open an issue 16:02 nrzkt i can confirm the issue, i had the issue on my server sometimes 16:02 Zeno` I'd rather something more than "this sometimes happens" :) 16:02 nrzkt it's not reproducable, sometimes that arrives, sometimes not 16:03 nrzkt create many players on your server, you'll se the issue if you are lucky , but i see this issue 5 times, players are at 0,0,0 instead of spawn, and i also get this issue 1 time 16:03 Zeno` ok, but without more data it's impossible to tell if the PR is even addressing the right thing 16:03 Zeno` add some more infostream output :P 16:04 Zeno` I, personally, would like to know *where*/*how* they are ending up at 0,0,0 16:05 Zeno` instead of tracing, because this is kind of complex with Lua involved 16:05 nrzkt the only location where 0,0,0 is possible is the code i mentionned, we already review the Lua code 16:06 Zeno` is the Lua code actually being called? 16:06 Zeno` is the new position being reset by "anti cheat"? 16:06 nrzkt yes, because static_spawnpoint works many times, but not every time 16:06 nrzkt no 16:06 Zeno` but I see no proof of this :( 16:07 Zeno` I have never seen it on my server, as an example 16:07 Zeno` So I think we need more data 16:09 Zeno` I don't really like the PR because: a) it reads static_spawnpoint directly (my server has more than one static spawnpoints); b) I can't see why the Lua is failing; and c) I can't see proof 16:09 Zeno` So it warrants more investigation IMO 16:24 Warr1024 I figured out why RTT works on android but [inventorycube doesn't 16:24 Warr1024 at least, I'm pretty sure the theory is sound. 16:25 Warr1024 normal node images are RTT, which is actually done as render to image, then image to texture 16:25 Warr1024 but the inventorycube needs an image as output, not a texture, so it tries to grab it back from the video adapter 16:25 Warr1024 that's the main variable. 16:26 Warr1024 so what it's doing is render->image->texture->image, which can be short-circuited 16:26 Warr1024 the complicated part is that I think desktop might actually use render->texture, so it needs to keep the render->texture->image process. 16:33 nrzkt no 16:33 nrzkt oops :) not for you 16:48 ShadowNinja Zeno`: It isn't merged because I waited and then got busy. 16:50 est31 merged 16:50 est31 ow 16:50 * est31 forgot the ctrl-f 16:51 est31 regarding #2402 16:51 ShadowBot https://github.com/minetest/minetest/issues/2402 -- Clean up and tweak build system by ShadowNinja 16:52 est31 nrzkt, do you know how the build system behaves on BSD when you enable freetype 16:52 est31 does it fail by default, or only show a warning? 16:54 nrzkt if i remember i have a fail 16:54 nrzkt but i can't remember if it's freetype or gettext 16:54 est31 there is #2403, which points to freetype errors on BSD 16:54 ShadowBot https://github.com/minetest/minetest/issues/2403 -- Fix freetype detection by AMDmi3 16:54 nrzkt in fact no, i haven't any error 16:55 nrzkt jenkins works then it's good 16:55 est31 yes 16:55 nrzkt cmake . -DENABLE_GETTEXT=1 -DENABLE_FREETYPE=1 -DENABLE_LEVELDB=1 -DENABLE_REDIS=1 -DCMAKE_BUILD_TYPE=Debug 16:55 est31 thats good 16:55 est31 so then it works 17:02 nrzkt reverting 467fc0ddc912ae38c3bf9fcb99e0b66d7478eec0 as discussed with ShadowNinja 17:03 est31 can you give me a link? 17:04 est31 https://github.com/minetest/commit/467fc0ddc912ae38c3bf9fcb99e0b66d7478eec0 17:04 est31 404 4 me 17:04 nrzkt the apply_damage lua call. reverted. 17:05 est31 ah yes seen 17:45 paramat hmmmm, saw your comment, i'll fix 'generate ores/decorations'. i'll make p1, p2 optional and default to chunk minp/maxp. but then, would we ever need positions other than chunk minp/maxp? 17:50 paramat i'll push #2519 in an hour or so 17:50 ShadowBot https://github.com/minetest/minetest/issues/2519 -- Mgv7: 1 up , 1 down overgeneration for chunk border continuity by paramat 17:50 hmmmm hmm I don't know 17:51 hmmmm maybe they'd like to only generate ores within a certain area 17:51 hmmmm like from (-100, -100, -100) -> (100, 100, 100) 17:51 hmmmm you know what.. speaking from past experiences, it's probably a bad idea to give the option to the user at all unless somebody specifically requests it 17:52 hmmmm every time i give a p1, p2 parameter in an api, people mess it up and they get black shadows across most of their map 17:52 paramat yeah okay i'd prefer to fix it to minp/maxp, will do 17:53 hmmmm in any case there is one more problem with your changes: 17:54 hmmmm you don't sort pmin/pmax input. this could cause a crash if somebody enters messed up parameters 17:54 paramat ah okay, i know how to sort 17:55 hmmmm also, debatable, but you take getBlockSeed of vm->m_area.MinEdge... is that *correct*? 17:55 hmmmm I'm not sure myself it matters that much and it's hard to come up with a clean solution 17:55 hmmmm also you don't check for pmin/pmax validity before passing them along to the api 17:56 hmmmm so that way core.generate_ores(vm, "foobar") would do something strange 17:56 paramat the blockseed thing was there already i left it as it is =) 17:57 hmmmm yes, but before it was assumed the minedge was always going to be thing passed to placeAllOres 17:57 paramat okay so in future i'll sort p1/p2 and check validity 17:58 paramat ah i see 17:58 paramat it should be chunk minp instead? 17:58 hmmmm well wait, how do I do error checking in other similar functions 17:58 hmmmm hmm I don't 17:58 VanessaE nrzkt: the player being spawned at 0,0,0 also happens with old players joining a world they've been to before. It's not limited to new players or to respawn on death. 17:59 paramat lol 17:59 hmmmm paramat: hold up 17:59 hmmmm we should fix all areas where it's assumed the pos parameters will be both present and valid 17:59 paramat anyway, it's good to actually have you around to point out my mistakes 18:00 nrzkt VanessaE: noted 18:00 hmmmm we should use check_v3s16() everywhere those parameters aren't optional instead of read_v3s16() 18:01 hmmmm yeah, sorry, I don't know why I used read_v3s16() 18:01 hmmmm this might break some peoples' mods but that's fine because they were relying on undefined behavior 18:01 hmmmm i have no sympathy for people who rely on UB 18:02 paramat okay for now though i should just edit generate ores/decos to be fixed to minp/maxp and get blockseed at minp? 18:02 hmmmm yes and yes 18:03 paramat okay 18:03 hmmmm and then I suppose the switch from push_v3s16 -> check_v3s16 should come in a separate commit 18:03 hmmmm as for the overgeneration 18:03 hmmmm i still have my doubts whether this is the best way to accomplish this fix, but it works for now 18:04 hmmmm still trying to come up with a way to fix this entire class of bugs 18:04 paramat thanks 18:04 paramat overgen is actually simple, lightweight and elegant, not ugly ;P 18:05 hmmmm it's not realistic to assume we can make all features defined by point-polled values 18:05 paramat but that comes from tackling it for years in lua mapgen 18:05 paramat for example all my road and path-generating mapgens rely on horizontal overgen 18:06 paramat there's no simpler way to do it 18:06 hmmmm perhaps we could have like certain blocks generating having a prerequisite block 18:06 hmmmm and then the prerequisite block is generated first 18:06 hmmmm i don't know 18:07 hmmmm the emergethread queue is messed up the way it is 18:07 paramat the alternatives to overgen always seem complex and too theoretical to me 18:07 hmmmm perhaps 18:08 hmmmm but overgen only solves the issue of soil layering 18:08 paramat .. and trees, dust, path generation etc 18:08 hmmmm i want to have one solution that solves every situation where we have "oh gosh, I need to know what's up there in order to know if I should generate what's down here" 18:09 paramat (see my lua mapgens) 18:09 hmmmm hmm 18:09 hmmmm how does overgen solve tree generation? 18:09 hmmmm and yeah dust is the same category as dust 18:09 hmmmm erm, as soil 18:09 paramat allowing trees to grow into the chunk above 18:10 paramat anyway back soon.. 18:45 nrzkt on stable-0.4 and master i can experience this issue on my server void Game::processClientEvents(CameraOrientation*, float*): An engine assumption 'new_id == id' failed. 18:47 nrzkt assert is trigger by hunger mod by blockmen, the triggered event is: else if (event.type == CE_HUDADD) 18:47 nrzkt but that doesn't happen everytime 18:47 hmmmm known issue: https://github.com/minetest/minetest/issues/2484 18:48 nrzkt right, who work on Hud ? 18:48 hmmmm i don't think anybody does at the moment 18:49 hmmmm blue42u created the remote hud commands, i created the Hud class and maintained it for a little bit 18:49 hmmmm it's basically anybody at this point, though 18:49 nrzkt if you want to reproduce it happen often with https://github.com/BlockMen/hud 18:50 nrzkt i have added this mod to my server today, sometimes trigger some nil Lua exception and 1/3 login => client crash 18:50 hmmmm well we don't know what the cause of the desynchronization is 18:50 nrzkt if you connects to my server you can reproduce sometimes the issue 18:50 hmmmm but a server should not be able to cause a client to crash like that 18:50 hmmmm it should print to errorstream and recover 18:51 nrzkt sanity_check(new_id == id); is the cause, but at this moment we have done u32 new_id = player->addHud(e); 18:51 nrzkt what is the impact of the id modification on the client ? is this really important ? 18:52 hmmmm it's just a sanity check 18:52 hmmmm that's an indication the client and server aren't in sync 18:52 nrzkt but it crash my client with an assert 18:52 hmmmm so any time the server tries to modify some hud stat, it'll modify the incorrect one 18:52 hmmmm right, so print to the errorstream instead of assert 18:53 hmmmm with regard to #2526: respecting the static_spawnpoint setting is a correct and good thing, but it's definitely not the source of the bug you're trying to fix 18:53 ShadowBot https://github.com/minetest/minetest/issues/2526 -- findSpawnPos should use the static_spawnpoint to set the player position by nerzhul 18:54 nrzkt right, if you want to merge this PR why not, if you have comments and you find the real bug we can add it to PR 18:54 hmmmm before you do merge it though, how was it expected that static_spawnpoint would work when it added? 18:55 hmmmm i am not familiar with this code so I'm just guessing 18:55 hmmmm but there might be some kind of on_respawn() callback where the player is teleported 18:55 hmmmm if that's the case, then 2526 shouldn't be merged at all and rather the above thing should be fixed 18:55 nrzkt in fact the code is in Lua also, but sometimes it's not called and the findSpawnPos function is called 18:56 hmmmm that's not a good thing 18:56 nrzkt it's how i understand the thing 18:56 hmmmm unless I'm mistaken, the fact that the lua callback isn't being triggered for whatever reason is the root cause of the bug 18:57 nrzkt but Zeno` does more investigation than me. findSpawnPos shouldn't return 0,0,0 it should return static_spawnpoint instead because it's the function goal 18:57 hmmmm why do you multiply nodeposf by BS 18:57 nrzkt for the Hud problem i suspect a non locked variable 18:57 nrzkt because the function return nodepos*BS 18:57 hmmmm ....why..... 18:58 hmmmm i can see it returns that, but why does it return that 18:58 nrzkt i don't know, i respect the way and do same thing :p 18:58 hmmmm do you realize what "BS" is for? 18:58 nrzkt BS = 10 18:58 hmmmm it's for translating player coordinates to 3d space coordinates in irrlicht 18:58 nrzkt okay 18:59 hmmmm so i see it returns intToFloat(nodepos, BS); at the bottom 18:59 hmmmm that might be wrong 19:00 nrzkt ok i'm pretty sure that the problem is we don't have lock on hud 19:01 hmmmm alright I just checked it out a bit more, multiplying by BS is correct 19:02 hmmmm but when you're making some kind of modification to existing code, you should try to figure out why it does what it does 19:02 nrzkt EmergeThread can modify hud (at player load, it's the only case where it modify the hud for a player) for a player and serverthread can do it too 19:03 nrzkt maybe, but i tested the change and it worked like i want, i'm not very familiar with mapgen and i already see this BS many times in other parts, then i thought it was normal :p 19:03 hmmmm why would anybody modify it in both 19:03 hmmmm that's horrible 19:03 hmmmm BS is only normal when you're talking about player/item coordinates 19:04 hmmmm for map coordinates, it's never multiplied by BS 19:04 hmmmm anyway, good theory, but does blockmen's code modify hud in an on_generate callback? 19:05 hmmmm I don't see any 19:06 nrzkt in the mod you mean ? no 19:06 nrzkt but it's possible to modify the vector from 2 threads at same time, i will add a PR to add a mutex to protect the hud 19:06 hmmmm okay 19:07 hmmmm that is needed, even though it's very odd for anybody to modify hud in an on_generate callback 19:12 nrzkt hmmmm: can you review #2529 please 19:12 ShadowBot https://github.com/minetest/minetest/issues/2529 -- Protect Player::hud from concurrent modifications by nerzhul 19:14 hmmmm the lock in maxHudId shouldn't be there 19:14 hmmmm hrmm i wonder what calls that 19:16 hmmmm nrzkt: remove the lock from maxHudId and instead add a lock in Hud::drawLuaElements 19:16 nrzkt Hud::drawLuaElements 19:16 hmmmm er wait 19:16 hmmmm that's not needed because that's the client 19:16 hmmmm so just remove the lock from that function 19:16 nrzkt right 19:16 hmmmm otherwise, approved 19:17 nrzkt do you agree for a merge ? 19:17 nrzkt it's updated on github, if you're okay for a merge i can do it 19:19 nrzkt i wait for the builds to be sure :) 19:26 paramat okay while you're waiting i'll push 2519 now 19:26 nrzkt i need to fix the compilation issue before, but the design is here :) 19:32 nrzkt okay this is fixed :) 19:33 ElectronLibre I got this on a server compiled with yesterday's afternoon's HEAD, with clients HEAD and 0.4.12-release : http://pastebin.ubuntu.com/10654682/ . Have this been reported? 19:36 hmmmm nrzkt, yes, i do 19:36 Krock ElectronLibre, interesting error :3 19:36 hmmmm ouch 19:37 hmmmm ElectronLibre, change texture_clean_transparent = false for now 19:37 ElectronLibre Client or server side? 19:37 hmmmm client 19:37 ElectronLibre Good. 19:37 ElectronLibre Thank you. 19:37 hmmmm np 19:37 nrzkt hmmmm: what did you want to do ? sorry i missed a thing :p 19:38 hmmmm nrzkt: approve for merge 19:38 nrzkt okay, i do it 19:38 paramat wait 19:38 paramat 5 mins 19:38 hmmmm when I say "approved", or "LGTM", or something similar, then yes I signed off on the commit 19:38 hmmmm paramat, ?? 19:38 paramat im pushing 2519 19:38 nrzkt okay, i'm waiting for u 19:38 hmmmm oh 19:39 hmmmm lazy guy doesn't want to pull and rebase 19:41 paramat okay done 19:41 hmmmm ElectronLibre: did that config setting work for you?? 19:42 ElectronLibre I'm connecting again right now. 19:43 paramat pushing takes me 10-15mins because i clone, wget, git am, compile and test the mapgens 19:44 paramat i teleported to a mountainous location to test overgen 19:48 nrzkt okay, pushing now 19:54 paramat i wonder if it's expected of me to compile and test mapgens during a push? 19:55 hmmmm i don't know 19:55 hmmmm whenever i make a modification to the mapgen I aimlessly wander around a map for a while 19:55 ElectronLibre hmmmm, the configuration you gave me fixed the issue. 19:55 hmmmm ElectronLibre: awesome, thanks! 19:57 paramat then after a push i update, compile and test everything again *=/ 19:58 paramat pushing still makes me really anxious 20:05 est31 nrzkt, can you review #2531 ? 20:05 ShadowBot https://github.com/minetest/minetest/issues/2531 -- Fix cmake po detection bug by est31 20:07 nrzkt i agree, this is a pain :p 20:09 est31 at other places, timestamp should be tolerated 20:09 Krock Finally a cleanup in the cmake variables :) Well done, ShadowNinja! 20:14 nrzkt why are we copying the loaded player into the remote player instead of loading directly to the remoteplayer ? Somes can look at ServerEnvironment::loadPlayer ? 20:21 ElectronLibre Latest build freezes on full grey world, no HUD, minetest process frozen, any idea? :/ 20:22 nrzkt server or client ? 20:22 nrzkt or twice ? 20:22 ElectronLibre Server frozen, have to kill minetest. 20:22 nrzkt the lock has problems ? can you check if the process is stucked in lock state ? 20:22 ElectronLibre Client frozen, on grey screen with no HUD, just hotbar loaded, no world loaded. Someone else just compiled and reported it. 20:23 ElectronLibre How can I check if it is in lock state? 20:23 nrzkt ps ax|grep minetest 20:23 ElectronLibre Ok. 20:24 nrzkt it's always the case or only one time ? 20:24 ElectronLibre Always. 20:24 nrzkt have you got some HUD mods ? 20:24 ElectronLibre Yes. 20:24 nrzkt wait a minute i recheck 0e5e49736c0a5fa29bca257bafc02d7c7a7171c9 20:24 ElectronLibre HUD mod by blockmen, the one you were applying a fix for right now. 20:25 nrzkt okay i see, i install it on my devel env 20:27 nrzkt deadlock, right, i check the issue 20:30 nrzkt oh... i seee 20:30 nrzkt u32 getFreeHudID() wait the addHud lock but it's already locked... 20:31 nrzkt misfollowed the code path for getFreeHudID, will be fixed soon 20:32 nrzkt i push the fix now. 20:32 ElectronLibre I will test it. 20:33 nrzkt i tested it with hud by blockmen. worked for me now 20:33 nrzkt you can test 20:54 ElectronLibre No more problems nrzkt. 20:58 nrzkt normal :) 21:22 paramat okay hmmmm here's my initial code, needs checking #2533 21:22 ShadowBot https://github.com/minetest/minetest/issues/2533 -- lua_api/l_mapgen: Fix volume of minetest.generate_ores/decorations to mapchunk volume by paramat 22:52 WarrTab Ugh, so apparently my android device supports rtt correctly, and was NOT using the rtt screenshot hack... 22:53 WarrTab ...but it does NOT support texture->image capture correctly.