Minetest logo

IRC log for #minetest-dev, 2020-07-08

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

All times shown according to UTC.

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:25 GreenXenith joined #minetest-dev
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
02:52 Lone_Wolf joined #minetest-dev
04:49 fluxflux joined #minetest-dev
05:35 pgimeno a client-side luacontroller?
06:56 calcul0n joined #minetest-dev
07:20 NetherEran joined #minetest-dev
08:00 ShadowNinja joined #minetest-dev
09:49 behalebabo joined #minetest-dev
10:24 lisac joined #minetest-dev
12:53 NetherEran joined #minetest-dev
12:54 absurb joined #minetest-dev
13:14 Fixer joined #minetest-dev
14:12 Lunatrius joined #minetest-dev
14:26 appguru joined #minetest-dev
14:26 NetherEran joined #minetest-dev
15:02 hecks joined #minetest-dev
16:08 hecks slowly getting there https://a.cockfile.com/rhMvbJ_far.jpg
16:16 erlehmann joined #minetest-dev
16:19 celeron55 how much are you running into problems with networking when working with those distances?
16:19 Wuzzy joined #minetest-dev
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:35 fluxflux joined #minetest-dev
17:37 DI3HARD139 joined #minetest-dev
17:43 NetherEran joined #minetest-dev
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:22 oil_boi joined #minetest-dev
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 229Mminetest.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

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