Time  Nick         Message
00:08 pgimeno      um, getmetatable?
00:10 pgimeno      I know the caveats about getmetatable("") but I think we worked out a safe way to handle it, by protecting the string metatable
00:11 pgimeno      and getmetatable is often used for OOP, to find a parent class and stuff like that
00:13 pgimeno      I'm not sure about setfenv being safe
00:14 pgimeno      I don't think its use goes beyond setting up sandboxes
00:16 pgimeno      well maybe reading configuration files (which is a form of sandboxing) but is that even possible with CSM?
00:35 rubenwardy   setfenv is useful for lua microcontrollers in mesecons
00:36 rubenwardy   perhaps running arbitrary user code from other users should be encouraged, is loadstring even available?
00:36 rubenwardy   *shouldn't
05:35 pgimeno      a client-side luacontroller?
16:08 hecks        slowly getting there https://a.cockfile.com/rhMvbJ_far.jpg
16:19 celeron55    how much are you running into problems with networking when working with those distances?
16:20 celeron55    at one point i was working on a more robust block transfer thing but didn't get to weeding out some annoying bugs
16:21 celeron55    hmm, maybe robust isn't the right word
16:21 hecks        well this is an interesting question because
16:21 hecks        minetest actually has a problem with block amnesia
16:21 hecks        it discards a lot of the data that's received
16:21 celeron55    yeah that's one of the things it fixed
16:22 celeron55    now where's the branch
16:22 hecks        do you have that branch uploaded somewhere?
16:22 hecks        I could reintegrate it into this one
16:22 hecks        batching visually fixes block amnesia but it's still happening in the background, eating a lot of resources (because it triggers batch updates now)
16:24 hecks        now network transfer isn't as much of a problem as it sounds; I once played a server that gladly fed me blocks at 300+ distance
16:24 celeron55    i doubt it's easily mergeable these days, but i think it's this https://github.com/celeron55/minetest/tree/block_transfer_v2
16:24 hecks        and the only one having any problem with that was the client
16:24 hecks        it's fine, I can rewrite it
16:24 celeron55    block selection happens completely differently in that
16:25 hecks        now would also be a good time to revisit farmap
16:25 celeron55    that branch was part of the farmap work
16:25 hecks        since we're hitting distances where textures mip to 1x1 size
16:26 celeron55    i separated it from farmap at the end
16:26 hecks        at this point one can render untextured vertex color blocks (which makes *everything* batchable)
16:26 hecks        and beyond that, point clouds
16:26 hecks        since irrlicht has decent support for GL_POINTS
16:26 celeron55    so it will work as support for future farmap efforts
16:26 celeron55    if it's taken into use
16:26 hecks        yeah that's kinda my roadmap for this
16:27 hecks        make batching, fix the block management mess, make the mesher spit out leaner geometry, and then do LODs
16:28 celeron55    that's ambitious, but perfectly doable in a few weeks with enough skill
16:28 celeron55    8)
16:29 celeron55    https://github.com/celeron55/minetest/commit/62ab93aa321c8d6b0caffc8d886401fec5774726#diff-d6c71fb6c2c5e2ad979f39a0422f7786R905
16:29 celeron55    the core of that branch is there
16:29 celeron55    the client tells the server what kind of block radius it wants the server's block sending code to maintain at the client
16:30 celeron55    the protocol still contains the farmap stuff too
16:32 hecks        bruh, I'm skill incarnate :] https://a.cockfile.com/uEEvw0_Clipboard01.jpg
16:36 celeron55    one of the reasons i had to make that was that when you want to transfer farmap stuff (basically lower resolution blocks), it competes with normal blocks and the server has to select which one is more important at each point in time
16:36 celeron55    that code creates a priority queue where each type of block has a priority value
16:36 hecks        I think they should just be sent incrementally, with coarsest mips having the highest priority
16:37 hecks        before the server even gives the client a "big" block, it should have already served a kilometer of point clouds
16:37 celeron55    usually a block 200 nodes away will have a lower priority than a farblock 300 nodes away, but the client can change that by varying its far_weight value in the TOSERVER_SET_WANTED_MAP_SEND_QUEUE packet
16:37 hecks        so that there are never any gaping holes in the map, this is a big issue currently https://a.cockfile.com/uMnVOV_52.jpg
16:37 celeron55    maybe it should have more levels (i.e. point cloud in addition)
16:38 hecks        I was thinking of octree-like mips at first but they might not be necessary
16:39 hecks        because at that point you can render fat points and it'll look just as good and be even cheaper
16:39 celeron55    i think it should be kept as simple as possible, it's not going to look perfect anyway and having too many levels will create more network usage and processing than it will help
16:39 hecks        sure, but consider the theory of mipmaps; a bitmap with mips will only be 33% bigger than the original
16:40 hecks        and that's without simplifying the data further, which you can do
16:40 celeron55    well that's true
16:40 celeron55    do anything you feel comfortable with
16:40 hecks        far blocks don't need param2, very far ones don't need light, in fact they can just be RGB332 8 bit color
16:40 celeron55    i think that's what most would say
16:40 hecks        :]
16:42 celeron55    one thing i noticed when doing the farmap stuff is that once you have any kind of level-of-detail optimization towards the client, the map generator's slowness becomes painfully obvious as it always has to generate at highest detail
16:42 celeron55    loading from disk is mostly fast enough even if it's at way too high detail
16:43 hecks        the mapgen being able to sample more coarsely would be very useful
16:43 hecks        I mean, is there a reason why it shouldn't be? just feed it scaled noise
16:43 celeron55    well the output won't be perfect but the basic noise will of course work
16:44 hecks        decos won't work but those can also be faked to some degree, maybe
16:44 celeron55    maps consist of trees and whatnot, those are more difficult and they add a lot of color the landscape
16:44 hecks        also, at least for built in mapgens, the client can predict some of it
16:44 hecks        as long as the server tells it the mapgen id and seed
16:44 hecks        so virgin mapblocks need not ever be sent
16:44 celeron55    that works for built-in mapgens yeah
16:45 celeron55    if we ever have threaded lua mapgens in a separate lua environment, the mapgen lua code could be sent to the client for the purpose
16:45 hecks        yup
16:45 hecks        well if I was stubborn enough I could already have threaded lua mapgen, only using on_generate to blit a result
16:46 celeron55    well i think it's not a priority right now
16:46 celeron55    mapgens aren't MT's weak point atm
16:46 hecks        at least not until someone takes pity on sscsm and finishes it
16:48 celeron55    we even have mapgens that look good at view ranges like 1000 or 2000 even while we actually don't have view ranges like that
16:49 hecks        yup, though the default params are tuned for short vision ranges
16:50 hecks        I'd show you how a decently sized v7 world looks like but someone broke noise sampling in 5.3 :]
16:51 hecks        I did a thing using dynamically sent skyboxes once, however https://a.cockfile.com/pi0eho_high.png
16:52 hecks        this was done by server side raymarching the noise https://a.cockfile.com/aToKdX_farmap.mp4
16:53 pgimeno      ISTR someone having worked on rendering to the skybox a sort of outline of the perlin noise used for the map, so that it looked much larger
16:53 hecks        https://a.cockfile.com/aOwuu0_farmap3.png
16:53 pgimeno      is that what a farmap is?
16:53 hecks        farmap is what we call any sort of LOD around here
16:54 celeron55    yeah i used the name for a thing and kind of stuck
16:54 celeron55    well that would describe pretty much every term we use...
16:55 hecks        just another day in the mese mines 8)
16:57 celeron55    how much server resources does server-side noise raymarching use?
16:57 hecks        surprisingly little because it's a 2D height only raymarch
16:57 hecks        and luajit is fast
16:57 pgimeno      hm, I think that was you hecks, now that I check the logs :)
16:58 hecks        the bottleneck was the client side decoding of the network message containing the huge ^[combine: texture string
16:58 hecks        https://a.cockfile.com/11LQCi_skybox.mp4
16:58 celeron55    oh it's even in lua, well that's ridiculous
16:58 appguru      MT needs a proper texture API
16:58 hecks        which prompted me to write a ^[raw: texture modifier that sent compressed bitmaps in the string
16:58 celeron55    yeah go on, just do something, it'll be great
16:58 hecks        I need to revive ^[raw as a PR because it's pretty useful
16:59 appguru      Texture modifiers as part of identifiers are no good
16:59 appguru      Identifiers should be IDs or names and not instructions on how to generate the texture
16:59 celeron55    yeah it's something you can make a proof of concept in but not actually use
16:59 hecks        for ephemeral textures like temp skyboxes or captchas, sending raw textures is very useful
17:00 appguru      We should have `minetest.register_texture_alias("aliasname", "texturename")
17:00 celeron55    eh
17:00 hecks        this should probably be handled opaquely by the server to avoid resending the texstring as part of something's properties, but no more
17:00 appguru      precisely
17:00 hecks        but I like texstrings, they're a very cool system, it's almost like a little Substance
17:01 appguru      TBH I don't like them too much
17:01 hecks        then you don't have taste :^)
17:01 appguru      I don't want to be an OOP zealot, but a Texture class would've been the right thing here
17:01 appguru      (in the Lua API)
17:02 hecks        I mean, sure, having a texture combining graph API would probably be nicer
17:02 hecks        but there's nothing wrong with texstrings as a raw graph format for transfer over the network, and it's a good thing they're human readable
17:02 hecks        and you can always wrap them in your own API which is what I do
17:02 appguru      roughly:
17:02 appguru      Texture("media identifier" or resolution):modifier(params)
17:03 celeron55    don't mix lua api into networking and certainly don't mix it into what the client does
17:03 appguru      The serialization should be handled by MT tho
17:03 appguru      Modders should be given need abstractions instead of building serialization formats by hands
17:03 appguru      Formspecs are another instance of this
17:03 hecks        formspecs already have a toolkit though, don't they?
17:04 celeron55    the lua api design really doesn't have much to do even with what api the server C++ publishes to lua, it can always be wrapped
17:04 appguru      There are mods and engine-side attempts AFAIK
17:04 hecks        and you can be nice and make people a mod to build texstrings too :]
17:04 hecks        https://a.uguu.se/cA25s5ssCXD5_api.jpg
17:04 hecks        brag brag brag
17:07 celeron55    i do like ^[raw, as long as the performance problems are somehow neatly solved. Maybe the server should convert it into a hash and transfer the actual data to the client through a different channel
17:08 hecks        the point of ^[raw is things that are not sent twice though, or to more than one client
17:09 hecks        how I optimized it instead was, I made it use indexed color (palettes) and zlib
17:09 hecks        finally crunching it into a base64 string
17:09 hecks        making it a pseudo-PNG
17:09 celeron55    if there are no real performance issues with the intended use, then i guess who cares
17:09 celeron55    i certainly won't
17:10 celeron55    that's the way i code myself anyway
17:10 hecks        nah, the intended use is captchas and private formspec elements
17:10 hecks        the only problem was that MT leaks those kinds of textures
17:10 celeron55    yeah the client never unloads textures
17:10 celeron55    it may or may not be possible to use irrlicht's reference counting to fix that
17:13 celeron55    not that it actually would become a problem with the intended use even if it never would unload them
17:13 celeron55    as long as one sticks to low resolution
17:19 hecks        yeah you normally don't notice this, only when I tried doing the skybox thing it started to matter
17:20 hecks        proper use of grab and drop will solve it
17:25 hecks        sampling noise in lua is pretty useful https://a.cockfile.com/vUa0Ke_v7.jpg
17:28 rubenwardy   merging web#204 in 10
17:28 ShadowBot    https://github.com/minetest/minetest.github.io/issues/204 -- Add latest version information by rubenwardy
17:44 rubenwardy   #10109 needs a solution
17:44 ShadowBot    https://github.com/minetest/minetest/issues/10109 -- Android water rendering issue
17:52 rubenwardy   I'm looking into it now, I suspect it's similar to other issues I've had with rendertexture on Android
17:52 rubenwardy   which I also didn't manage to fix
18:11 rubenwardy   ok, I can't reproduce the bug actually
18:11 rubenwardy   I was confused by the default hotbar_selected image
18:28 sfan5        huh?
18:30 rubenwardy   So, #10109 is caused by a bug fix to fix black backgrounds on inventory images
18:30 ShadowBot    https://github.com/minetest/minetest/issues/10109 -- Android water rendering issue
18:30 rubenwardy   I can't reproduce the black backgrounds on inventory images afterall
18:31 pgimeno      in GLES2?
18:31 rubenwardy   yes
18:31 rubenwardy   err
18:31 Krock        I observed black backgrounds in the wield item when the shaders were not up to date
18:31 rubenwardy   or ES 1
18:32 rubenwardy   Android doesn't have shaders
18:32 sfan5        gles2 always uses shaders, but not ours
18:32 rubenwardy   yeah, fixed shaderd
18:32 sfan5        are you testing with the SMaterial 0.5f commit reverted?
18:34 rubenwardy   yes
18:34 rubenwardy   I also reverted it on the repo
18:34 appguru      Couldn't we do this using an IFDEF in the shaders?
19:06 rubenwardy   celeron55: what was your vision for the default game in Minetest?
19:28 hecks        does anyone know if time of day sunlight updates trigger remeshes?
19:37 hecks        https://a.cockfile.com/Yjeflm_faaaar.jpg gonna have to start thinking about extending the map size too at this rate
19:38 rubenwardy   nice, is that a natural view distance?
19:38 hecks        depends on what do you mean by natural
19:38 rubenwardy   good FPS, experienced during runtime without lots of flying around
19:39 hecks        no this still chugs, but at least it's viewable now
19:39 hecks        problem is that normally minetest doesn't even let you load this much without punching holes in it and forgetting blocks
19:39 hecks        and also it would die trying to render this
19:40 rubenwardy   a higher view range is my number 1 wish for graphics, before anything fancy
19:40 rubenwardy   well, also z-ordering
19:40 rubenwardy   for alpha
19:40 hecks        I'll do distance sorting as a part of this
19:40 hecks        this might become one mutha' big PR but it has to, because of how it's all connected
19:41 rubenwardy   uh oh
19:41 hecks        the "natural" view distance as you call it is roughly doubled at the moment
19:41 hecks        but I yet to have start doing basic things like frustum culling
19:41 rubenwardy   PR title:   Bug fixes and performance improvements
19:42 hecks        pretty much
19:42 hecks        sure caught some bugs along the way
19:42 hecks        there's also structural changes like how camera_offset is handled
19:42 hecks        in fact it's been deleted from a lot of places since it's no longer needed
19:43 hecks        the blocks are being rendered using plain transform matrices now, it works very well at the map's edge after some adjustment
19:43 hecks        no more statically shifting block geometry around
19:43 hecks        the same thing should be done for entities eventually
19:45 hecks        this is a "natural" view distance, officially 350 but by necessity it's padded to more https://a.cockfile.com/aFJwAP_natural.jpg
19:45 hecks        so about half of the previous image
19:46 hecks        also my PC is getting old and you could surely pull off more on something more recent
19:56 rubenwardy   that's nice
20:04 pgimeno      hecks: I'm right now working on frustum culling for OpenMiner and I'm interested in the algos for that, mind if I PM you?
20:04 hecks        go ahead
20:05 rubenwardy   All 5.3.0 blockers have been cleared
20:17 sfan5        then, can we release now?
20:29 sfan5        I guess I now is the time to import translation stuff again
20:32 sfan5        Wuzzy: instead of changing broken "needs_fallback_font" translations on weblate to be empty you could just have fixed them
20:33 sfan5        but doesn't really matter
20:33 Wuzzy        as i dont speak the language, i do not make decisions about the "correct" value. others must decide
20:33 Wuzzy        so the only "safe" thing i can do is delete the value
20:34 Wuzzy        as far i remember, an empty value equals "no"
20:34 sfan5        then you could also have left the broken value
20:34 Wuzzy        noooooo
20:34 sfan5        it's also equivalent to no
20:35 Wuzzy        ugh
20:35 Wuzzy        we just have to wait for translators to insert the correct value
20:35 Wuzzy        but if we keep the broken one it wont get fixed
20:35 Wuzzy        unless you speak the language in question, empty is better than broken
20:40 rubenwardy   I agree with empty > broken
20:41 sfan5        whether it's empty or gibberish doesn't change anything about the end result
20:41 sfan5        anyway I am fixing the values in cases where I can determine how it's supposed to look
20:43 rubenwardy   sure
20:45 rubenwardy   it would be useful to have a tool to verify that translations aren't malicious
20:45 rubenwardy   like, show translations that don't look quite right against google translate
20:46 rubenwardy   although, carefully crafted sentences may look ok in google translate but be foul to a native reader
21:00 sfan5        ok translations pushed
21:05 sfan5        util/bump_version.sh is refusing to work, how nice
21:08 rubenwardy   could be my android change
21:19 sfan5        Could not open file of texture: Z:tmpxminetest-5.3.0-win32texturesbasepacknext_icon.png
21:19 sfan5        uh
21:20 sfan5        the icons are invisble but not sure if this is wine's fault
21:23 rubenwardy   what
21:23 rubenwardy   yay windows
21:30 sfan5        yep same issue on real windows
21:32 rubenwardy   maybe the texture isn't escaped in formspecs?
21:34 sfan5        yeah that fixes it
21:35 sfan5        rubenwardy: http://sprunge.us/gbSk21?diff
21:35 rubenwardy   lgtm
21:35 * rubenwardy slaps himself
21:35 sfan5        if that looks okay i'll include that commit before tag.. alright
21:35 rubenwardy   my bad
21:40 sfan5        the 32-bit build crashes reliably when existing a world
21:40 sfan5        that must mean nobody actually uses it
21:41 rubenwardy   there may be an issue for that
21:41 sfan5        really?
21:41 rubenwardy   #10137
21:41 ShadowBot    https://github.com/minetest/minetest/issues/10137 -- "Exit to menu" button causes Minetest to close/crash
21:41 rubenwardy   I'd forgotten
21:42 sfan5        you accidentally linked the 32-bit twice in the rc2 topic
21:42 sfan5        +build
21:42 rubenwardy   doh
21:48 sfan5        229M	minetest.exe
21:48 sfan5        debugging symbols ✔
22:11 sfan5        after messing around with both winedbg and gdb+wine and finally just installing gdb on windows I get a partial backtrace that points to a std::set<unsigned long long> destructor with this being NULL
22:14 sfan5        ./src/script/common/c_converter.cpp:	static thread_local std::set<u64> warned_msgs;
22:14 sfan5        only u64 set we have
22:29 sfan5        rubenwardy: thoughts on this workaround http://sprunge.us/2rYb9s?diff
22:30 sfan5        turning it into an std::vector<u64> like l_deprecated_function uses (also thread-local) didn't fix it though I didn't verify the backtrace
22:32 pgimeno      is it OK in linux 32 bit?
22:40 sfan5        works here
22:42 pgimeno      so it looks like a a mingw32-specific bug
22:44 hecks        compiling minetest with symbols, yum
22:44 hecks        linking the damn thing is so slow I just revert to shotgun debugging because it's literally faster
23:22 sfan5        release happens tomorrow then, I guess
23:38 appguru      yay
23:38 appguru      finally