| 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 |
| 03:37 |
|
MTDiscord1 joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:23 |
|
Alias joined #minetest-dev |
| 04:52 |
|
YuGiOhJCJ joined #minetest-dev |
| 05:43 |
|
fossdev2 joined #minetest-dev |
| 05:46 |
|
book` joined #minetest-dev |
| 05:48 |
|
rubenwardy joined #minetest-dev |
| 05:49 |
|
calcul0n joined #minetest-dev |
| 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 |
<ROllerozxa> 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:15 |
|
Fixer joined #minetest-dev |
| 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 |
| 09:42 |
|
HuguesRoss0 joined #minetest-dev |
| 10:01 |
sfan5 |
timestamps and other randomness (in certain cases) can affect build output, so it's not that easy |
| 10:05 |
|
appguru joined #minetest-dev |
| 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 |
| 12:43 |
|
proller joined #minetest-dev |
| 13:20 |
|
proller joined #minetest-dev |
| 15:48 |
|
Fixer_ joined #minetest-dev |
| 17:00 |
|
Baytuch joined #minetest-dev |
| 17:05 |
|
Baytuch joined #minetest-dev |
| 18:00 |
|
Wuzzy joined #minetest-dev |
| 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:17 |
|
proller joined #minetest-dev |
| 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 |
<x2048> Pexin: I'm around, I remember the problem, but I lost track of where it was reported. Can you remind me? |
| 22:17 |
|
behalebabo joined #minetest-dev |
| 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 |
<x2048> #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 |
|
panwolfram joined #minetest-dev |
| 22:34 |
Pexin |
will try it |
| 22:41 |
Pexin |
yes, fixes drawers and billboards. but not hand. interesting. |
| 22:49 |
MTDiscord |
<x2048> 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 |
<x2048> Can you file an issue? I'm off now. |
| 22:53 |
Pexin |
ok |
| 22:53 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> Of course that could be the problem, or it could be a separate problem :-D |
| 22:54 |
Pexin |
hmmm |
| 22:55 |
MTDiscord |
<Jonathon> 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 |
<Jonathon> ? its the one warr is refering to anyways |
| 22:59 |
MTDiscord |
<Warr1024> 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 |
<Jonathon> no one has "confirmed" it or provided a reproducable example |
| 23:05 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> Last time I tested was maybe the 5.2 or 5.3 era or something? |
| 23:08 |
MTDiscord |
<Warr1024> https://gitlab.com/sztest/nodecore/-/commit/8f452a48fe0222f4fae88bd72ea15e81ec41d2aa |
| 23:09 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> "loosen it" as in turn cobble into loose cobble, as the commit mentions. |
| 23:15 |
MTDiscord |
<Warr1024> "drop as an item" is a minecraftism/minecloneism. |
| 23:15 |
erle |
are you saying we can instadig |
| 23:16 |
MTDiscord |
<Warr1024> I don't know about insta |
| 23:16 |
MTDiscord |
<Warr1024> I'm just saying that I've observed phenomena that looks an awful lot like what was reported in that issue. |
| 23:17 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> (or there were circumstances; it's been 1 year+ since I put the workaround in place in NC) |
| 23:19 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> The code isn't super helpful but you get the idea from the title. |
