Time Nick Message 01:32 paradust Was the win64 release produced from a sealed environment? Someone in discord is reporting Avast is alerting on zlib1.dll and libintl-8.dll 02:10 paradust It's "Win64:Evo-gen [Susp]" though. Appears to be a heuristic rather than anything specific. 02:33 erle paradust https://forum.avast.com/index.php?topic=125057.0 07:18 nrz_ sfan5, what's the idea behind benchmark repository ? can you be more precise about the needs ? i maybe have some spare time to contribute on it ? 07:26 MTDiscord paradust: Avast is being avast, nothing that can be done about it other than telling people to switch to windows defender instead 07:26 nrz_ i undersstand idea is to do benchmarks, but maybe you have some governance ideas about it ? 07:47 paradust nrz_: It produces unit benchmarks: https://www.minetest.net/benchmarks/dev/bench/ 07:48 paradust It's a separate repo for security reasons. It's generated by a 3rd party action, and it needs write access to push .html back into the repo 08:01 nrz_ ok for the security i thinik it's due to the fact it's published on the website right ? 08:01 nrz_ rah i like rust and golang internal tooling to run bench on unittests directly ? 08:01 nrz_ when C++ wil limplement a such thing 08:50 sfan5 paradust: all libraries were built from source on a system I consider secure 09:01 paradust Could be useful to have the build system generate and publish tip-of-tree versions for people who want to be on the bleeding edge 09:02 paradust Also if done carefully, the build would be sealed and reproducible 09:07 sfan5 we have gitlab-ci pipelines that produce downloadable builds but I they recently broke for some reason 09:09 sfan5 still those just use the same pre-built libraries I also use 09:18 nrz_ CMake Error: The source directory "/builds/minetest" does not appear to contain CMakeLists.txt. 09:19 nrz_ did we moved the CMakeLists.txt somewhere else ? ? 09:19 erle how did you build? 09:20 erle nrz_ it would help if you would put the entire build log from and including your command up until to the error into https://mister-muffin.de/paste and put the link to it here or so 09:24 nrz_ read .gitlab-ci.yml 09:37 paradust sfan5: Still, it's not possible to reproduce the build without knowing your exact setup. (gcc ver, system lib versions, etc). Even the path of the source and build directories ends up inside the .exe file. 09:38 paradust If it is built from a container (e.g. Docker) with a fixed config, it could be reproduced exactly by anyone... I think 09:39 paradust I'm not sure if time stamps or other transients end up affecting the output. I don't believe so 10:01 sfan5 timestamps and other randomness (in certain cases) can affect build output, so it's not that easy 10:23 erle sfan5 paradust https://reproducible-builds.org/tools/ 10:25 erle https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/minetest.html 10:25 erle FYI 10:26 erle hmm, according to this page, minetest is reproducible with the same build path, maybe? 10:30 paradust would seem so. that's pretty impressive that their build system deduces this automatically 10:31 paradust but they also assume the same exact build environment 18:16 sfan5 even though I have read through the initial post and have a rough idea what to write I can't bring myself to spend time replying to the "Eventually move to a free git platform" issue 18:27 Pexin >Do you also always ask your baker their bread recipe in order to buy it? 18:27 Pexin um..... yes. of course. 18:27 Pexin who eats stuff without knowing what's in it? 18:31 rubenwardy I'd hope that it has bread in it 19:14 sfan5 can someone look at #12313 and #12301 and #12263 so we can get this over with 19:14 ShadowBot https://github.com/minetest/minetest/issues/12313 -- Replace all uses of core::list with std::list by paradust7 19:14 ShadowBot https://github.com/minetest/minetest/issues/12301 -- Use std::map instead of core::map by paradust7 19:14 ShadowBot https://github.com/minetest/minetest/issues/12263 -- Fixes needed to use irrArray backed by std::vector by paradust7 20:21 Pexin x2048 around? or anyone else working on shadows? is the drawer entity issue still being analyzed? (specifically day/night affects lighting on some entities even when underground AND dynamic shadows are disabled) 20:22 Pexin I know what commit introduced this (cef252b755277cf5b9eb0605629f294087ebb344), but the core cause is clearly deeper. 22:06 MTDiscord Pexin: I'm around, I remember the problem, but I lost track of where it was reported. Can you remind me? 22:20 Pexin x2048 I'm not even sure it's the same problem. there seem to be multiple things happening 22:21 Pexin probably #11326 22:21 ShadowBot https://github.com/minetest/minetest/issues/11326 -- Shadow mapping breaks visuals in minetest-mod-drawers 22:22 Pexin I'm not convinced this is the same issue though. what I'm experiencing depends on time of day 22:22 Pexin and there's no difference whether dynamic shadows are enabled in .conf or not 22:25 Pexin it affects drawer entities and the playerhand, at least 22:33 MTDiscord #12336 fixes upright_sprite entities (drawers, devtest player model etc.). Not sure how player hand is related. 22:33 ShadowBot https://github.com/minetest/minetest/issues/12336 -- Fix lighting of upright_sprite entities by x2048 22:34 Pexin will try it 22:41 Pexin yes, fixes drawers and billboards. but not hand. interesting. 22:49 MTDiscord If you mean wield mesh, lighting seems to work fine - dark in dark places. 22:49 Pexin the hand is dark at night, even in a bright basement 22:53 MTDiscord Can you file an issue? I'm off now. 22:53 Pexin ok 22:53 MTDiscord Re: the dark hand issue, I had that for a while, but found that setting paramtype="light" on the hand nodes fixed it for me. 22:54 MTDiscord Of course that could be the problem, or it could be a separate problem :-D 22:54 Pexin hmmm 22:55 MTDiscord https://github.com/minetest/minetest/issues/12180 actual issue 22:56 Pexin seems different, as this is related to time of day 22:57 MTDiscord ? its the one warr is refering to anyways 22:59 MTDiscord Ah, interesting, still unconfirmed, huh... 23:00 Zughy[m] if someone wants to help, can you please test if this thing still works? #8180 23:00 ShadowBot https://github.com/minetest/minetest/issues/8180 -- Tools without groups match to node can sometimes still dig the node 23:01 MTDiscord no one has "confirmed" it or provided a reproducable example 23:05 MTDiscord Re: 8180, I'm not sure I can exactly confirm it, but I've had players manage to "dig" air in NodeCore by just digging something that already got dug on the server side but hasn't reached the client yet due to lag. I ended up working around this by just setting diggable=false explicitly on all nodes that don't have dig groups. I think this MIGHT have been the same issue... 23:06 MTDiscord Last time I tested was maybe the 5.2 or 5.3 era or something? 23:08 MTDiscord https://gitlab.com/sztest/nodecore/-/commit/8f452a48fe0222f4fae88bd72ea15e81ec41d2aa 23:09 MTDiscord The steps to repro in that example I don't think were ever proven to work, but matched the anecdotal evidence. It required digging a node to it's dig-predicted node, then digging THAT node, while on the server side, the dig-prediction was skipped and it actually dropped the node into player inv. 23:12 erle Warr1024 does that mean you can only dig nodes that way that are dig-predicted? 23:12 erle fleckenstein once gave out free air items hehe 23:13 erle i got like 412 air or so 23:13 erle (he was not an admin on the server where he did it hehehe) 23:13 MTDiscord Dig prediction is per-node, not per-node-per-tool, so I have to register nodes with dig prediction based on the most common tools. This basically forces prediction misses for cases where you have one of the rare tools that can actually pick up the node, not just loosen it. 23:14 erle “loosen it”? 23:14 erle you mean drop it as an item 23:14 MTDiscord Apparently if you can trick a client into sending a "dig complete" packet, then the server can accept that for any node that's diggable=true|nil, rather than checking for matching groups. 23:14 MTDiscord "loosen it" as in turn cobble into loose cobble, as the commit mentions. 23:15 MTDiscord "drop as an item" is a minecraftism/minecloneism. 23:15 erle are you saying we can instadig 23:16 MTDiscord I don't know about insta 23:16 MTDiscord I'm just saying that I've observed phenomena that looks an awful lot like what was reported in that issue. 23:17 MTDiscord It seems like there are circumstances under which you can dig a node that was intended not to be diggable based on groups, and that it doesn't necessarily require a cheat client or somethign. 23:18 MTDiscord (or there were circumstances; it's been 1 year+ since I put the workaround in place in NC) 23:19 MTDiscord In any event, the steps to repro are basically: (1) start to dig a node on the client, (2) swap the node on the server with one that you can dig, but not with that tool, (3) finish the dig on the client, which hasn't received the swap yet due to lag. 23:21 erle that *might* explain why some fun-haters lagged clamity a lot and then there was a hole in the bedrock 23:23 MTDiscord You have to be able to dig the node that's there to start with though, so I'm not sure how it could be used to dig bedrock. Presumably bedrock starts and stays where it is, so wouldn't be vulnerable. 23:24 erle Warr1024 what if i place a no 23:24 erle de on the client in an unloaded area, then dig that before it gets update 23:25 erle well, i guess using a cheat client is a faster way lol 23:25 MTDiscord yeah, cheat client would be a good way to test this. It seems like if a legit client shouldn't be able to dig it, then there's no reason to allow a cheat client to either... 23:25 erle i find breaking bedrock using tricks much more interesting if it can be done without a cheat client though 23:26 MTDiscord Can you place nodes in unloaded areas? I thought you weren't supposed to be able to... 23:26 erle ha-ha :D 23:26 erle i think the client might not acknowledge them, but it is perfectly possible 23:26 MTDiscord I suppose you could make a "cheat client" pretty easily out of a legit client with some clever proxying. You only really need to be able to trick the client about the existence of some very specific data... 23:27 erle have you looked at the anon5 minetest go library? 23:27 erle it is the thing for exactly these kind of tricks 23:27 MTDiscord Of course you can lag the shit out of an entire server to take advantage of lag exploits, but you'd fly under the radar a lot easier if you could just use a proxy that just happens to drop the mapblock receive packet for one very specific mapblock or something. 23:28 erle i really really hate bugs that incentivize griefers to lag the server 23:28 MTDiscord I've actually been hoping to find a good "profiling" proxy that would give me an idea how efficient my network usage is, where the main costs are, etc. I ended up coming pretty close to writing one myself, but if there's something out there that's already mature... 23:28 erle Warr1024 https://github.com/anon55555/mt 23:31 MTDiscord Heh, last time I poked around in my network traffic, I found this stupid bug XD https://gitlab.com/sztest/nodecore/-/commit/c4f41348e0341000cf4eecc7a0c372604fd93fab 23:32 MTDiscord The code isn't super helpful but you get the idea from the title.