| 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 |
