Minetest logo

IRC log for #minetest-dev, 2022-05-02

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

All times shown according to UTC.

Time Nick Message
00:09 rubenwardy I'm not sure blog readers are the right audience really
00:10 rubenwardy The update blog should be targeted towards users, which includes players and modders
00:11 rubenwardy Maybe you could do a post about how to get involved
00:12 rubenwardy Those adoption needed PRs aren't good tasks though
00:13 rubenwardy I'd like to see the gettext one and the node text render one done
00:21 rubenwardy *good first takes
00:21 rubenwardy **tasks
01:28 v-rob joined #minetest-dev
01:58 Toothless joined #minetest-dev
02:14 v-rob joined #minetest-dev
02:21 v-rob joined #minetest-dev
03:25 v-rob joined #minetest-dev
04:00 MTDiscord joined #minetest-dev
04:25 paradust joined #minetest-dev
04:29 loggingbot_ joined #minetest-dev
04:29 Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. https://dev.minetest.net/ https://github.com/minetest
04:33 v-rob joined #minetest-dev
04:34 programmerjake joined #minetest-dev
05:41 calcul0n joined #minetest-dev
07:00 Pexin joined #minetest-dev
08:20 v-rob joined #minetest-dev
08:44 MTDiscord Command sent from Discord by criticalfault42:
08:44 MTDiscord !tell celeron55 May I have be a Minetest engine issue triager as well? I'd like to confirm some bugs.
08:44 ShadowBot MTDiscord: OK.
08:44 MTDiscord <luatic> s/have//
09:49 Fixer joined #minetest-dev
10:04 HuguesRoss joined #minetest-dev
10:33 YuGiOhJCJ joined #minetest-dev
10:57 Wuzzy joined #minetest-dev
12:15 rubenwardy #12185 is ready for review
12:15 ShadowBot https://github.com/minetest/minetest/issues/12185 -- Add login/register dialog to separate register and login by rubenwardy
12:34 celeron55 what's the coredev opinion overall about adding triagers? should i ask here about everyone who asks or should i add them by my own opinion only, and is there a need for many triagers to begin with?
12:37 celeron55 as criticalfault42 says there's some opportunity for confirming bugs at least, which does require work, but also requires some trust
12:39 Zughy[m] My two cents: I really prefer to keep the repo in order (labels, closing when needed, asking people if they're gonna continue) rather than confirming bugs. So if there is someone just for testing bugs, that'd be best
12:41 Zughy[m] also because we're talking about 111 issues labelled as "unconfirmed bug", that's.. a lot of work
12:46 MTDiscord <luatic> I'm appgurueu/luatic for the record (the bridge shows the Discord nickname instead of the Discord username it seems).
12:47 Zughy[m] Also, not to shit on people or anything, but the triagers before me (Calinou and Wuzzy) did basically nothing
12:47 MTDiscord <luatic> All roles should be without obligation. Core devs aren't forced to "do something" either.
12:48 Zughy[m] I mean, Calinou is busy with Godot, it makes sense
12:49 Zughy[m] no, but they should do something once in a while. In fact there is a "former core dev" section in the client for a reason
12:50 Zughy[m] My point was, rather than adding people, you can also consider replacing them
12:50 MTDiscord <luatic> Why? Neither Wuzzy nor Calinou have lost any trust.
12:50 MTDiscord <luatic> There is no need to replace them.
12:51 Zughy[m] I mean https://github.com/minetest/minetest/pull/11463#issuecomment-1114626426
12:51 MTDiscord <luatic> The core dev example was probably a bad one, because core devs are (rightfully) credited; triagers don't earn any credit though.
12:57 Wuzzy i'm a triager only on paper. I have never used my reviewer powers because I'm scared and not well-versed in the codebase. as for labels, I was waiting for gh to add support for labels
12:58 Wuzzy spearking of labels... what are the rules for confirmed bugs?
12:59 Wuzzy because we have 111 unconfirmed bugs which is not good
12:59 Zughy[m] uhm.. according to the wiki, triaging != reviewing powers https://dev.minetest.net/Git_Guidelines#Triagers
13:00 Wuzzy i didnt know this was an official term
13:01 Wuzzy ohhhh I have "closing powers"...
13:01 Wuzzy okay yes i actually did not mean i had review powers. I had a brainfart 😀
13:06 Wuzzy ahh dang. I don't have renaming powers. some issues have very bad titles and need better names
13:07 _Zaizen_[m] joined #minetest-dev
13:35 celeron55 github is very limited in being able to fine tune the privileges of different teams
13:55 rubenwardy Triagers should be able to edit the title and first post, but GitHub doesn't give that freedom
14:00 Wuzzy and the worst part is we can do nothing about it (not even writing own code), except beg microsoft for it. sucks to depend on a proprietary platform, right? 😛
14:02 MTDiscord <ROllerozxa> lol yeah
14:08 rubenwardy Could make a bot
14:09 Taoki joined #minetest-dev
14:25 Zughy[m] Wuzzy: we shouldn't confirm our own bugs I think https://github.com/minetest/minetest/issues/8920
14:36 qur joined #minetest-dev
14:46 sfan5 if you are reasonably sure that your repro steps will absolutely lead to confirming the bug (and it's not questionable whether bug or not) then feel free to confirm your own bugs
14:48 rubenwardy yeah, that's ultimately the difference between unconfirmed and confirmed - there needs to be understandable repro steps, repro'd by someone else, and it needs to be certain it's a bug (and not eg: bad UX)
14:53 Zughy[m] Wuzzy: if it can help you busting unlabelled issues, that's what I use (in this case for Feature Request)
14:53 Zughy[m] ```
14:53 Zughy[m] is:issue is:open label:"Feature request" -label:"@ Builtin","@ Network","@ Mainmenu","@ Documentation","@ Content/PkgMgr","@ Translation","@ Script API","@ Client / Controls / Input","@ Build","@ Client / Audiovisuals","@ Mapgen","@ Client Script API","@ Startup / Config / Util","@ Server / Client / Env."
14:53 Zughy[m] ```
14:55 Wuzzy ah, nice. really shows how much github's bugtracker sucks if we need absurd workarounds like these 😀
14:55 Wuzzy i will make a bookmark out of htis
15:03 qur joined #minetest-dev
15:12 TheCoffeMaker joined #minetest-dev
15:14 panwolfram joined #minetest-dev
15:26 TheCoffeMaker joined #minetest-dev
15:29 qur joined #minetest-dev
15:40 appguru joined #minetest-dev
16:06 panwolfram joined #minetest-dev
16:18 panwolfram joined #minetest-dev
16:20 TheCoffeMaker joined #minetest-dev
16:26 sfan5 164Mbin/minetest
16:26 sfan5 debugging info takes lots of space 🤔
16:31 Pexin is there a syntax to github search PRs that are closed but not merged?
16:47 TheCoffeMaker joined #minetest-dev
16:48 v-rob joined #minetest-dev
16:58 Yad joined #minetest-dev
17:25 qur joined #minetest-dev
17:42 x2048 joined #minetest-dev
17:49 TheCoffeMaker joined #minetest-dev
18:05 qur joined #minetest-dev
18:07 TheCoffeMaker joined #minetest-dev
18:19 sfan5 rubenwardy: I addressed your review comments on #11131, do you want to have another look or is it okay to merge?
18:19 ShadowBot https://github.com/minetest/minetest/issues/11131 -- [MANUAL MERGE] Async environment for mods to do concurrent tasks by sfan5
18:22 rubenwardy I'm fine with the code. Was going to test but no need if knock has
18:23 sfan5 did you have anything specific in mind you wanted to test
18:24 MTDiscord <luatic> Knock knock, who's there? Knock.
18:24 rubenwardy I was probably going to do something expensive with logging, and see if I got any issues in the terminal or with user experience
18:24 MTDiscord <luatic> I love autocorrect xD
18:24 rubenwardy Hadn't really thought about testing too much, you clearly have that
18:24 rubenwardy *though
18:25 sfan5 give /flip a try though, it's fun
18:26 sfan5 (you can do it in normal MT if you edit out the async part, too)
18:33 sfan5 merging #11131 in about 15m
18:33 ShadowBot https://github.com/minetest/minetest/issues/11131 -- [MANUAL MERGE] Async environment for mods to do concurrent tasks by sfan5
18:33 MTDiscord <luatic> :o it's happening
18:34 sfan5 whose idea was it have both src/serialization.cpp and src/util/serialize.cpp
18:57 sfan5 Pexin: even if you could that'd be unrealize because we used to merge PRs by closing them and manually applying them
18:57 sfan5 unreliable*
18:57 sfan5 derp
19:11 behalebabo joined #minetest-dev
19:32 BuckarooBanzai Krock: sorry for the ping but i'm having trouble with understanding the following code in the block-sending mechanism: https://github.com/minetest/minetest/blame/c7bcebb62856ae5fdb23a13e6fa1052eae700ddf/src/server.cpp#L2299
19:33 BuckarooBanzai `maxd` is calculated with `far_d_nodes * BS` so it _should_ be 100*16 = 1600, but i'm not sure if the player distance calculation does the BS-multiplication too :/
19:34 BuckarooBanzai (sorry, i might be up too long and this has been bothering me:)
19:35 Krock bold of you to assume I'd have any memory about this commit after 4 years
19:35 BuckarooBanzai :D
19:35 sfan5 player_pos is in BS-units; intToFloat(pos, BS) is also in BS units; and you say maxd is too
19:36 sfan5 I don't see a problem
19:36 BuckarooBanzai don't bother if it takes too long, i'll take a fresh look at it tomorrow ;)
19:36 rubenwardy sfan5: any plans for the async env now? ie: IPC, more APIs, etc
19:36 BuckarooBanzai ok then, somehow i made the calculations multiplies with 16 in my head and it didn't make sense...
19:37 sfan5 BS=10 :)
19:37 rubenwardy unfortunately, the BS multiplier in Minetest is >1
19:37 BuckarooBanzai ah right: sfan5, nice work on the async PR \o/
19:37 sfan5 rubenwardy: I don't plan to work on new stuff there unless someone opens an issue and convinced me they need something
19:37 sfan5 convinces*
19:38 BuckarooBanzai oh right: `BS=10` somehow i associated the node-to-mapblock ratio with it
19:39 BuckarooBanzai sorry for the trouble :)
19:40 Krock MAP_BLOCKSIZE is 16
19:49 MTDiscord <x2048> I'm getting broken FPS, draw time and dtime jitter info with the latest master. Like, fps always 0, draw time of 127000 ms and jitter <0
19:50 sfan5 eh, me too
19:50 sfan5 and it's my fault
19:50 sfan5 the values stabilize after about 30s though
19:51 MTDiscord <x2048> for me, fps and jitter keep being garbage, but I force 5 FPS to save battery.
20:00 sfan5 -       RunStats stats;
20:00 sfan5 +       RunStats stats = {};
20:00 sfan5 not sure why I didn't do this
20:02 MTDiscord <x2048> good you could find it so fast 🙂
20:04 behalebabo joined #minetest-dev
20:10 panwolfram joined #minetest-dev
20:18 v-rob joined #minetest-dev
20:29 HuguesRoss joined #minetest-dev
20:58 rubenwardy (Just to clarify, by IPC I meant the ability for async threads to communicate with mods in the server thread using message queues and something like the mod channel API)
21:06 rubenwardy Minetest staff:   would anyone like a Jetbrains open source license?  Products include CLion, IntelliJ, and PyCharm
21:07 rubenwardy hmmm, they may have changed the rules. Looks like you don't need to be a MT staff member, just an active contributor in minetest/minetest
21:08 rubenwardy also it's a license for open source use, not an open source license. It's still very proprietary, apologies
21:45 paradust sfan5: Is there any reason not to bring irrlicht into the minetest repo at this point?
21:46 erle paradust it would certainly sabotage any plans of making a better irrlichtmt
21:46 erle erle but also it would make it clear which version of irrlichtmt is to be used
21:46 sfan5 wat
21:46 paradust how?
21:48 paradust I'm under the impression irrlicht upstream is dead? Or no?
21:48 erle i wanted to make an irrlichtmt variant with a longer irrlicht history for better rendering issue bisecting. if you can't change irrlichtmt independently of minetest, that's a bit harder. but i suggest you ignore that, i haven't even started doing anything.
21:48 erle paradust, irrlicht upstream is not dead at all.
21:48 paradust why can't you just bisect off the minetest repo
21:49 erle the part of the history where some bugs were introduced is simply missing from the history of irrlichtmt
21:49 erle forget about it
21:49 paradust oh, i see. there are a lot of historical bugs you are still tracking down?
21:49 erle paradust the situation is as follows: irrlicht is developed, but makes releases once in a blue moon. also minetest goals do not align with irrlicht goals.
21:49 erle no, not a lot. but like the slime UV thing (unless it got fixed some time)
21:50 erle it seems to be newer than irrlicht in debian and older than wherever irrlichtmt forked from irrlicht
21:50 erle and ig it is an irrlicht bug or behaviour change. as i said, forget about it.
21:50 erle and btw: git subtree is nice
21:51 erle paradust the thing with irrlicht upstream is, it is actively developed, but makes releases only very rarely (because they are work, same as minetest). up until recently, when sfan5 showered them with patches, there was AFAIK no activity to upstream anything https://irrlicht.sourceforge.io/forum/viewtopic.php?p=306516#p306516
21:52 erle and irrlicht only rejected one patch that was wrong anyway, so i don't think irrlicht is at fault here
21:52 sfan5 the patch is not wrong
21:52 paradust It would solve (i) build desync, make it easier to do refactors that touch both minetest and irrlicht. Given the current situation, irrlicht is a bit harder to modify. That'd be a good thing if we're hoping to switch back to upstream, but...
21:54 erle sfan5, it is “wrong” in the sense of “you might not care, but the irrlicht author worries about it running on windows 98”
21:55 sfan5 your forum post sounds a lot different than just "this does not work on w98"
21:55 sfan5 paradust: there's no exact plan on when to do that but roughly irrlicht should be stripped down as much as possible and perhaps parts even rewritten before it's merged into the engine repo
21:55 MTDiscord <MisterE> At this point, windows 98 is run pretty exclusively for curiosity purposes, I think
21:56 paradust sfan5: Do you have an idea of what kind of rewrites you want? I was just thinking I could/need to rewrite large parts of this engine to faster, but doing that while they are separate repos is going to be 2x as hard
21:56 erle sfan5, well, the documentation is partially wrong and your fix is wrong and i was also wrong, windows will *usually* fall back to ACPI HPET stuff but that might break as well. i still think that the real solution is to only pin i thread to a core it is already running, to reach exactly the goal you want to reach (no spurious rescheduling).
21:56 erle regardless, irrlicht is not having it and you are also not convinced to throw it away
21:56 paradust every change is going to require 2 pull requests, 2 commits, a backwards compatibility plan...
21:57 erle the ”having everything in lockstep” thing is horrible, yes
21:57 erle it's like systemd where you have “components” but they all need to be upgraded at the same time
21:57 erle “modular”
21:58 erle sfan5 given the amount of patches irrlicht upstream took, how likely do you think rendering improvements could lead to minetest building with irrlicht upstream ever again?
21:58 sfan5 exactly zero
21:58 erle they are not responsive enough or the goals diverge too much?
21:58 sfan5 latter
21:59 erle have you looked at antarctica, the supertuxkart irrlicht fork?
21:59 sfan5 no but it is guaranteed to diverge just as much
21:59 sfan5 erle: if you find QPC to not work on a system newer than windows xp you can open an issue on Microsoft's doc repo and have them adjust their documentation
21:59 sfan5 paradust: stuff like getting rid of non-STL containers, for everything else I'd have to take a closer look
21:59 sfan5 you can also discuss ask other coredevs for their opinion
22:00 sfan5 do you have any specific things in mind with "I could/need to rewrite large parts of this engine"?
22:01 erle supertux vendored irrlicht and made everything be based on ogl3.1, i.e. throwing away support for everything old, doing a shader thing etc. – that is why i am asking. i wonder what they did “right” that can be emulated, org-wise.
22:01 paradust looking at PartialMeshBuffer for example. It's a hard that doesn't really work well. Because Irrlicht doesn't allow multiple index buffers to be used in combination with a single vertex buffer
22:01 paradust *it's a hack
22:02 paradust In general Irrlicht isn't using VAOs or UBOs, that may be a large change
22:02 sfan5 hm
22:04 sfan5 well if it's a single class you're rewriting directly moving it to the engine source can work, then it's just 1 PR, 1 commit and no compat
22:05 sfan5 erle: no idea, that sounds worth looking into
22:06 sfan5 paradust: there's no hard requirement for backwards compatibility btw, if it's easy to do it's just a nice thing to have
22:08 sfan5 if you can convince people that irrlicht should be imported into the repo right now to accomodate rewrites then that's also possible
22:08 sfan5 few things are absolute
22:09 erle also if you do it please use the subtree merge strategy
22:09 erle oh no wait
22:09 erle maybe don't put it in the main repo. the -200k lines commits is guaranteed to break some tooling.
22:09 erle gitg for example just crashes
22:10 sfan5 point of removing all the cruft before is that we don't import 600k lines into our main repo
22:10 sfan5 and speaking of "new" OpenGL features it's also clear that one day we will be dropping OpenGL 1 / shader-less support
22:10 sfan5 anyway, I'm off
22:11 erle uh, should i work on forking minetest before then or can i just wait?
22:11 erle (i don't want more work)
22:11 erle (like what would i even prepare)
22:12 erle paradust regardless of how you plan to integrate code in the main repo, please make sure that tooling doesn't fold on itself.
22:12 sfan5 btw here's current irrlichtmt:
22:12 sfan5 SLOCDirectorySLOC-by-Language (Sorted)
22:12 sfan5 65529   source          cpp=65529
22:12 sfan5 23335   include         cpp=19805,ansic=3530
22:12 erle paradust like, it's bad enough that i can't use some of my usual tools on the irrlichtmt repo.
22:12 erle paradust you def don't want to import that in a way it ruins the main repo, i'm certainly not the only one.
22:13 erle paradust so forget about subtree please
22:13 sfan5 nobody except you has ever mentioned this but okay
22:13 erle well, that's the standard response to me complaining by people who don't encounter the bugs. the truth is: >90% of people just go like “fuck this” and don't say shit.
22:14 erle like i said, using gitg in the irrlichtmt repo leads to a gitg crash. yes that's the fault of gitg. but also it's not easily fixable.
22:15 erle and irrlichtmt is much less used than minetest repo
22:15 erle (and gitg is not the only thing that is a pain to use if you have giant commits)
22:15 erle (or impossible to use)
22:16 erle anyway, my goal here is to complain before the shit hits the fan so that the trajectory can be altered to miss the fan
22:16 erle i have no idea how to solve this though, except carefully reconstructing the irrlichtmt history and then doing a subtree merge, which i am reasonably certain no one is willing to be.
22:16 erle to do
22:16 erle damn
22:16 erle good night
22:19 HuguesRoss Haven't read the rest of the convo, but I can confirm that "the truth is: >90% of people just go like “fuck this” and don't say shit." is pretty accurate in software dev. As a tools prog, cultivating an environment where users are willing to go complain is an important part of my professional life
22:21 erle i have seen this even in non-software circles. for example, a conference org did some major changes that alienated a group of regular speakers. i talked to the orga years later and *they did not know* even though me and a bunch of other speakers just dropped out from one year to the next and never did a talk there again.
22:26 erle or at work – the “the elves leave middle earth” phenomenon. new management introduces something, a few people complain, a bunch of people quietly go on a job search, a year or so later entire teams that were stable for many years have over 50% turnover. for legal reasons i will not go into details.
22:27 erle mcl2 had something like this as well when fleckenstein was maintainer. the devs used discord to coordinate, so they just never took performance bugs seriously.
22:27 erle well, as i said before: good night
22:29 erle oh btw, the conference managed to pivot to other topics successfully, so at *some* level they must have had an understanding the rats were leaving the sinking boat. it's not like alienating people does necessarily doom a project. but it is unfortunate and often can be avoided.
22:34 panwolfram joined #minetest-dev
22:46 paradust erle: The reason why most bugs will get no developer attention is because developers have very limited time, they need to focus on top issues and their roadmap.
22:48 paradust erle: "Getting `gitg` working in the irrlicht repo" is at the bottom of a very long list. You could be the only person in the world who ran into that problem
22:48 paradust In any case, it is more of a gitg issue. Did you send them a bug report?
22:58 Zughy[m] sfan5: shouldn't #10891 be closed? Like, shouldn't be up to player_api or whatever to implement such an animation? You can mess with bones with the API since a few releases
22:58 ShadowBot https://github.com/minetest/minetest/issues/10891 -- Sneak has no visual feedback, which is confusing
23:01 MTDiscord <Warr1024> That feels very much up to the game and not the engine.
23:01 MTDiscord <Warr1024> Oh wow, 2015
23:02 erle paradust just forget about anything i said before. both “you are the only person who complains, so probably the only person encountering the bug” and “introducing new bugs carelessly is justified because we introduced similar bugs in the past and have not fixed them” are most of the time just shibboleths for “none of the arguments you make for software QA interest me on principle”.
23:03 erle i.e. it doesn't make much sense to discuss those things to me
23:04 erle paradust i don't want to annoy you. and i guarantee we are going to annoy each other and others with a discussion where we disagree on such fundamentals.
23:05 erle (i mean, i believe “introducing a new bug” is something else than “not fixing an existing bug“, but other people disagree strongly)
23:07 erle Zughy[m] there are games in which sneak has visual feedback and games in which it has not and i believe it is deliberate?
23:08 MTDiscord <Warr1024> It's not always deliberate.  In NodeCore there is no visual feedback.  I'd sort of like there to be ... but it's not in the budget :-)
23:09 erle Warr1024 making a hud indicator or changing eye height or so is not in budget? :D
23:10 MTDiscord <Warr1024> No, it's the player model that's the issue.
23:10 MTDiscord <Warr1024> and yeah, I'm already over my HUD budget.
23:12 Zughy[m] yeah what I meant is, how is that an engine issue?
23:13 erle Zughy[m] it is as rubenwardy said, a minetest_game issue if any
23:13 erle and sneaking is not crouching in every game
23:15 AliasStillTaken joined #minetest-dev
23:16 MTDiscord <Warr1024> > Local animations however are in the engine, where this would/should be implemented too.
23:17 MTDiscord <Warr1024> Okay, that does make more sense to me now
23:17 MTDiscord <Warr1024> Sounds like the problem might be that the title/description of the issue no longer matches what sfan5 actually intends for it
23:18 MTDiscord <Warr1024> i.e. it sounds like expanding the "set local animation" API to account for sneakitude might be the intended engine involvement here.
23:18 MTDiscord <Warr1024> Yeah, clarification of that would be nice.
23:34 Baytuch joined #minetest-dev

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