| Time |
Nick |
Message |
| 00:15 |
|
Sokomine joined #minetest |
| 00:27 |
|
ShadowBot joined #minetest |
| 00:41 |
erle |
Warr1024 btw do you know, culturally, where this thing comes from where people believe that ALL deleted code is debugged code? |
| 00:42 |
erle |
same question to muurkha |
| 00:42 |
MTDiscord |
<warr1024> If you delete code, then that code can no longer introduce bugs đ |
| 00:43 |
MTDiscord |
<warr1024> I don't think it's a "cultural" thing, I think it's just from observation: Some of the biggest bugs I've fixed have been from just deleting somebody's 1800 lines of "what the fuck were they even trying to do" and replacing it with the 10 obvious ones that actually work. |
| 00:43 |
erle |
well the thing is i noticed it in a bunch of projects, like minetest, but also others, that people assume that ALL complex code is needless complexity |
| 00:43 |
erle |
which obviously fails when the problem is complex |
| 00:44 |
erle |
but even a complex problem might have a too-complex solution that can be simplified |
| 00:44 |
erle |
like that thing with build systems that DJB figured out with redo |
| 00:45 |
erle |
redo is a great example actually. there are a number of toy implementations that implement only 1 or 2 of the 4 primitives you need to handle all cases that i know. |
| 00:45 |
erle |
because those are the easy ones |
| 00:45 |
MTDiscord |
<warr1024> Not everyone deletes code though because they assume they're making the situation better. Â Sometimes we just delete code because there's no way to know for sure without carrying out an actual experiment. |
| 00:45 |
erle |
the linux kernel way hehe |
| 00:46 |
erle |
i read about it |
| 00:46 |
MTDiscord |
<warr1024> I'm not familiar with the kernel workflow specifically |
| 00:46 |
erle |
they had some WLAN drivers and wanted to figure out which were still used |
| 00:46 |
erle |
so they were like âwhat if we just delete them but keep the infra around and if just ONE user complains for a driver we put it backâ |
| 00:46 |
erle |
which neatly sidesteps all the minetest discussions about if the complaint is actually legit etc. |
| 00:47 |
erle |
like if you need the driver, you get it |
| 00:47 |
MTDiscord |
<warr1024> That would be actually pretty cool if we could simplify MT that way |
| 00:47 |
erle |
but if no one complains, either users are never updating |
| 00:47 |
erle |
not with the current dev team lol |
| 00:47 |
erle |
first thing they would do is drop support for my hardware, then never put it back |
| 00:47 |
erle |
or rather, the dev team is not the issue here |
| 00:47 |
erle |
the attitude is |
| 00:48 |
erle |
the thing is, kernel devs have a history of actually considering outcomes |
| 00:48 |
erle |
they still break stuff |
| 00:48 |
|
Trifton joined #minetest |
| 00:48 |
erle |
but they *normally* don't have silly ideas about ânah let's not fix itâ |
| 00:48 |
erle |
and if stuff is broken on purpose, there must be some tangible benefit |
| 00:48 |
erle |
like the itanium thing i think |
| 00:48 |
MTDiscord |
<warr1024> I don't think they'd be willing to put anything back on an "if just one user complains" standard because they know that there are certain users who are highly likely to complain just because they saw the change, not because they necessarily actually were using it ... and MT isn't as big and complex of a project as Linux where changes like that are easily drown out in the noise. |
| 00:49 |
erle |
well the thing is, if one user complains, you have dozens of them that never even figured out why shit stopped working. sometimes hundreds. |
| 00:49 |
erle |
so i think it is a good standard |
| 00:49 |
erle |
i have had this experience from both sides |
| 00:50 |
erle |
like as a project maintainer, personally talking to people and they were like âyeah shit stopped working but i never bothered to file a reportâ |
| 00:50 |
MTDiscord |
<warr1024> On the flip side, the attitude the MT devs get from parts of the userbase that sound like "how could you be so stupid as to try to make a change like this" really doesn't motivate them to do the extra work necessary or to want to actually interact with user feedback. |
| 00:50 |
erle |
and as a bug reporter, KNOWING that some bug affected a lot of people, but being the only one who filed it and then the maintainer saying âwell you are the only one who complained so far, can't be importantâ |
| 00:52 |
erle |
IMO it's not about stupidity, it's about hybris. not wanting to do things âthe right wayâ (e.g. TDD, or always adding a regression tests, or having liskov-substitutable function signatures) because âwe are already doing this corerctly, most of the time (except if not, then it was a clear mistake)â. |
| 00:53 |
erle |
this is not special, most software devs are like this actually |
| 00:53 |
erle |
including me obviously |
| 00:53 |
erle |
just look at the tilted horizon in xcam (that is fixed now) |
| 00:53 |
erle |
no tests, no plan, but ⌠also no users to inconvenience since i wrote it from srcatch |
| 00:53 |
erle |
scratch |
| 00:55 |
MTDiscord |
<warr1024> Not wanting to do things "the right way" isn't about hubris, it's about humility, i.e. not assuming that you can solve all the problems if you just sit down and think about it hard enough. Â The fact that you read other people's humility as arrogance is one of the things that makes you come off as arrogant yourself, and makes it harder for you to come to agreements with people about these things. |
| 00:55 |
erle |
just because you can't solve all problems does not mean being careful is a vice |
| 00:55 |
erle |
i am indeed arrogant and i hope ppl like you call me out on it without getting angry |
| 00:55 |
erle |
so i can be more humble |
| 00:56 |
erle |
please explain though how ânot wanting to do things the right way an breaking stuff in the process, repeatedlyâ is about humility? |
| 00:56 |
MTDiscord |
<warr1024> No, there is a balance between caution and boldness, and it's been pretty clear for a long time that MT suffers from way too much caution in general. Â If you want to see more caution in places where it's misallocated, you will probably need to be more nuanced in what you ask for, because it just sounds like you want MT to progress even slower than it already is. |
| 00:56 |
erle |
or making fun of me when i suggest to have test cases |
| 00:57 |
erle |
well, i want minetest to progress. which is why i made this thing as easy as possible for the devs. test mod. PR, issue only opened after i have a fix ready. |
| 00:57 |
erle |
i can't really make it easier |
| 00:57 |
erle |
not with a release coming up |
| 00:57 |
|
ShadowBot joined #minetest |
| 00:58 |
erle |
and also i *have* in the past reviewed code and it has not helped because my reviews don't count. same for others btw. |
| 00:58 |
MTDiscord |
<warr1024> You really can't make it easier, and that in itself may be a problem: the minimum effort any change can take from core devs has a pretty high floor. |
| 00:58 |
erle |
minetest would not even have âcheat clientsâ if the devs would be a bit more accepting of patches |
| 00:58 |
erle |
like most of the cheat client stuff really is what would pass as a debugging help in other games |
| 00:59 |
erle |
like âgive me all particle spawners that are sent on the network that i can not seeâ (to reduce packet spam). can't do that with vanilla minetest. |
| 00:59 |
erle |
but it helps a lot to e.g. make sure your game has no location exploits and does not send all particle spammers to all players |
| 01:00 |
erle |
or being able to script a player |
| 01:00 |
MTDiscord |
<warr1024> The perception (and possible reality) that non-core-dev reviews "don't count" also seems to be a problem. Â It seems like MT has a necessity to have people who are "in" and everybody else being "out", just to manage the technical need of access control to the repo, but that has bred a dichotomy between core devs and other contributors, and the distance between them is an obstacle to cooperation. |
| 01:01 |
erle |
Warr1024 but they *do* not count. i remember for example that wuzzy (an important contributor) improved rail drawtype endings. sfan5 reviewed it, i reviewed it ⌠and then without two approvals, wuzzy just gave up at some point. |
| 01:01 |
MTDiscord |
<warr1024> hmm, I guess I better try one of those cheat clients myself. Â I've been meaning to try to intercept and analyze the network traffic (MT tells me how many packets, but not by type, nor do I get an idea of average packet size by type)... |
| 01:02 |
erle |
don't be too excited. just know that lizzy and cora will *probably* be happy to accept your patches. |
| 01:02 |
erle |
and yes, it's a nice idea to try |
| 01:02 |
|
smk joined #minetest |
| 01:02 |
erle |
a funny thing was like cora once telling me i should stop aiming at her |
| 01:02 |
erle |
apparently one of the debug views showed her the view direction of other players ;) |
| 01:03 |
MTDiscord |
<warr1024> Reviews do count toward what reviews are supposed to count toward, i.e. increasing everyone's confidence the code is good. Â What they don't do is get past a process that has certain pathological failure modes, i.e. that 2 core devs must "sign off" on something, which means not only does the code need to look good, and it need to pass any testing they can do, and it fulfill a chance they support ... but they have to also be willing to |
| 01:03 |
MTDiscord |
suffer the backlash if the change breaks somebody's spacebar heating. |
| 01:03 |
erle |
i think the spacebar heating thing is overblown. there have been changes where complaints really made a difference, but the feature was removed after all. |
| 01:04 |
MTDiscord |
<warr1024> I'm just saying that maybe if we, from the community side, could tone down the backlash when something happens that we don't like, and if we don't panic about it and make a huge flamewar over it, then maybe we can meet in the middle somewhere. |
| 01:04 |
erle |
well if it was EASILY fixable, maybe that backlash would be a bit less |
| 01:04 |
erle |
or if there wasn't a âoh you are not a coredev and your change is not on the roadmap GUESS IT SUCKSâ |
| 01:05 |
erle |
like take map enlargement. proller tried. and got a âclosed, maybe some time in the futureâ |
| 01:05 |
erle |
it is one of the most requested features â and proller was trying to do important infrastructure work before addressing it. |
| 01:06 |
erle |
but obviously, with a HUGE amount of work and no coredev interest, it died |
| 01:06 |
MTDiscord |
<warr1024> I don't think it's dead, I think it's in 6.0 limbo. |
| 01:06 |
erle |
oh yes, like turning the moon upside down lol |
| 01:06 |
erle |
(that's the funniest bullshit proposal) |
| 01:07 |
erle |
or take alpha-correct rendering. i made some test cases, explained how it would work and said i would want to work on it ⌠and the dev team committed to never do alpha-correct rendering. |
| 01:07 |
erle |
which, incidentally means some blending bugs are NEVER going to be fixed until this decision is revised |
| 01:07 |
MTDiscord |
<warr1024> Somebody basically needs to say "okay, I'm sick of all this incremental shit, we're getting diminishing returns, it's time to do something crazy" ... which probably requires the intersection of somebody both experienced enough to do the work and yet somehow has the time on their hands. |
| 01:07 |
erle |
well proller *did* the work, did you see it? |
| 01:07 |
erle |
it was not finished or polished |
| 01:07 |
MTDiscord |
<warr1024> "commited to never do" <-- got a reference for this? Â It sounds like a pretty bold claim... |
| 01:08 |
erle |
yeah wait |
| 01:08 |
erle |
i mean it is actually work |
| 01:08 |
MTDiscord |
<warr1024> Right, proller did the work, but it would not have been a big compatibility break, so hence 6.0 |
| 01:08 |
erle |
to do alpha-correct stuff *all* of your pipeline needs to be |
| 01:08 |
erle |
Warr1024 wdym âwould not have been a big compat breakâ? |
| 01:09 |
erle |
IIRC you can actually do this without breaking compatibillity too much |
| 01:09 |
erle |
at least on the lua side |
| 01:09 |
MTDiscord |
<warr1024> methinks perhaps the MT devs were not entirely happy about how the 0.4 to 5.0 transition went either, so maybe 6.0 is not something they're pushing to do any time soon either. Â There were various forms of pain in the last compat break. |
| 01:10 |
MTDiscord |
<warr1024> IIRC hash |
| 01:10 |
MTDiscord |
<warr1024> _node_position would have been an issue, and network packets would have been. |
| 01:10 |
MTDiscord |
<warr1024> the latter would be the obvious 6.0 breakpoint |
| 01:10 |
erle |
well maybe not break compat then and do small incremental improvements like ⌠uh, HTTP, XMPP, Email, CSS, any browser. |
| 01:10 |
MTDiscord |
<warr1024> if you're going to break compat for network reasons anyway then the lua compat becomes less critical anyway |
| 01:10 |
erle |
Warr1024 here is the gamma thing https://github.com/minetest/minetest/pull/12089#issuecomment-1107927711 |
| 01:11 |
erle |
Warr1024 but you don't actually have to break compat i think? a bigger map server-side *can* already be faked (but the simplest way i know breaks client side map saving and prob some other things). |
| 01:11 |
erle |
you could also have the bigger map only accessible to newer clients |
| 01:12 |
MTDiscord |
<warr1024> Oh, okay, I misread "gamma correct" as "alpha correct", i.e. handling stacked transparent things (which we currently do to a limited degree by sorting surfaces). |
| 01:12 |
erle |
okay so you agree this reads like âwe are not going to do gamma correct rendering ever, until we reconsiderâ? |
| 01:12 |
MTDiscord |
<warr1024> I ... guess I can kind of understand sfan5 suggesting that it's unlikely that enough players are even going to NOTICE gamma incorrectness to make it worth the implementation work... |
| 01:13 |
erle |
oh, gamma incorrectness is easily noticeable all the time |
| 01:13 |
erle |
every time you blend something actually |
| 01:13 |
erle |
every time you have a color gradient |
| 01:13 |
MTDiscord |
<warr1024> It's noticeable if you have "perfect pitch" for luma, which I guess maybe you do and I don't. |
| 01:13 |
erle |
no |
| 01:13 |
erle |
i fetch some examples, you will see it |
| 01:14 |
MTDiscord |
<warr1024> Don't show me side by side, just show me the "wrong" way |
| 01:14 |
MTDiscord |
<warr1024> and see if I can even guess |
| 01:14 |
MTDiscord |
<warr1024> because IRL in normal gameplay you can't expect players to be playing alongside reference samples, so that would be kind of unfair. |
| 01:14 |
erle |
okay guess which one is gamma-correct: https://blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma/img/color-blending.jpg |
| 01:15 |
erle |
(this has nothing to do with reference samples) |
| 01:16 |
erle |
same here, guess which one is gamma-incorrect? https://blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma/img/opacity.png |
| 01:16 |
erle |
i am sorry for showing side by side |
| 01:16 |
erle |
i must have skipped that and this means i am too sleepy to continue |
| 01:17 |
erle |
i still would like to know which one looks *correct* to you |
| 01:17 |
erle |
for both of them |
| 01:17 |
MTDiscord |
<warr1024> The weird thing is that I could swear I fixed a very similar visual artifact myself, and have subsequently noticed NO artifacts like that before... |
| 01:17 |
MTDiscord |
<warr1024> In the top example I can tell that something is off. Â In the bottom one, I would not have noticed it if I didn't have the side by side. |
| 01:17 |
erle |
also every time you move away from something and the mipmap gets darker â that's gamma-incorrect scaling |
| 01:17 |
erle |
yeah but these artifacts in the top example |
| 01:17 |
erle |
those are things people notice |
| 01:18 |
erle |
blending to black, like ⌠uh, in that screenshot lol |
| 01:18 |
erle |
about the filtering :D |
| 01:18 |
erle |
the effects of wrong gamma are subtle, but go everywhere |
| 01:18 |
erle |
it can even affect antialisiasing for text and stuff |
| 01:19 |
erle |
like if you get gamma wrong your antialiased text may appear too strong, e.g. bold |
| 01:19 |
erle |
users will *probably* not figure out this is a gamma problem |
| 01:19 |
erle |
but it will look âoffâ in some way |
| 01:19 |
MTDiscord |
<warr1024> 'At this point this PR becomes a disguised feature request that is better titled "Revise the rendering pipeline to be gamma correct"' < -- seems like this might be the real crux of the issue here. |
| 01:20 |
erle |
that is something else i dislike about minetest |
| 01:20 |
erle |
test cases for bugs are generally not accepted unless you deliver the fix |
| 01:20 |
MTDiscord |
<warr1024> It doesn't sound like sfan5 is saying "no we will never support gamma correctness", so much as "no, you can't merge your regression test that we automatically fail without us actually having a solution for it." |
| 01:20 |
MTDiscord |
<warr1024> Yeah |
| 01:20 |
MTDiscord |
<warr1024> I mean, TDD is simply not the religion here. |
| 01:21 |
erle |
yeah but *I* made these as the first step towards gamma correct rendering. then saying âno we will not everâ proves that TDD was correct here. |
| 01:21 |
erle |
if i had actually written code |
| 01:21 |
erle |
that would have been a bit worse if then they would say âno we won't do thatâ |
| 01:21 |
erle |
now i know i never need to try |
| 01:22 |
erle |
(unless that policy is revised) |
| 01:22 |
MTDiscord |
<warr1024> I've actually never worked somewhere where they did the test-before-code thing, tbh. Â I've worked on projects where they try to make regression tests very quickly after making changes, and I've worked on projects where all testing is manual only ... but I've never actually seen the "write the code to resolve already-existing failing tests" thing actually done in the wild. |
| 01:22 |
erle |
i mean gamma is way more important for physically-based rendering than for pixel art comic book look |
| 01:22 |
erle |
so i see the point |
| 01:23 |
erle |
Warr1024 i suggest to do it for some toy problem, like âwrite a parser for roman numeralsâ. it is infuriating at first. |
| 01:23 |
erle |
we had these games at work, âcoding dojoâ |
| 01:23 |
erle |
where the idea was: you have a few people in a group, a shared codebase and a toy problem, like that roman numeral parser |
| 01:23 |
erle |
everyone has 5 minutes |
| 01:23 |
MTDiscord |
<warr1024> I see every rejection on GH as being subject to circumstances. Â If somebody were to have an actual PR for gamma correctness, and MT were interested in maybe merging that, then that would change your PR's circumstances, and invalidate any "never" implied there. Â But I think sfan5 is fair to say "never" in that case as a reasonable estimate how how highly unlikely that is... |
| 01:23 |
erle |
if all tests pass, you add a new failing test |
| 01:24 |
erle |
if any test fails, you try to make it pass |
| 01:24 |
erle |
after 5 minutes you commit and the next person is âitâ |
| 01:24 |
erle |
added dificulty level and more interaction you get with the following rule: the person who is currently the coder may only code, but others need to guide them as a group |
| 01:24 |
erle |
i found it bizarer at first |
| 01:25 |
erle |
but like other stuff (e.g. LANGSEC) intuition is entirely misleading here |
| 01:25 |
|
ShadowBot joined #minetest |
| 01:25 |
MTDiscord |
<warr1024> I'm not saying I couldn't imagine writing code that way at all, it would just take me a while before I'm doing it for anything non-trivial. Â You can't just throw TDD on top of an existing workflow. |
| 01:25 |
erle |
writing tests after-the-fact is ABSURDLY more difficult than writing them before |
| 01:25 |
erle |
no you can't, but you can develop single features that way |
| 01:25 |
erle |
like e.g. gamma-correct stuff |
| 01:26 |
erle |
you can also prototype APIs very well that way, because the tests double as an exploration of the possiblity space |
| 01:26 |
MTDiscord |
<warr1024> I dunno if "single feature" works in MT with the way stuff like that is bound to be so heavily tentacled. |
| 01:26 |
erle |
have you seen the irrlicht shadows thing that lizzy made? |
| 01:26 |
MTDiscord |
<warr1024> (in any event, you didn't convince the core devs on that thread to accept your stealth feature request OR switch to TDD) |
| 01:26 |
erle |
it basically just enables the stencil buffer and adds some âadd_shadow_volumeâ or how the function is called to some meshes |
| 01:26 |
erle |
it was not a stealth feature request. i actually wanted to make PNG test nodes after the TGA test nodes. |
| 01:27 |
erle |
i still want to, i just have to make all possible TGA test nodes first (i think i may be done with that actually, except for submitting them to minetest). |
| 01:27 |
MTDiscord |
<warr1024> It smelled to the core devs like a stealth feature request, and when I look at it from their perspective, without the benefit of you telling me that, it smells that way to me too. Â Maybe you just didn't present it the right way or something, or there was some other miscommunication. |
| 01:28 |
erle |
well i told them âthis is how i would implement itâ because they thought it would be easier |
| 01:28 |
erle |
so i think i did my part here ;) |
| 01:28 |
MTDiscord |
<warr1024> In any event, if you actually fix gamma-correct blending, it looks like it wouldn't be hard to just include your test suite as part of that PR anyway... |
| 01:28 |
erle |
i think the thing that swayed the opinion against handling gamma correctly was when i pointed out that you actually need to do all operations differently |
| 01:29 |
erle |
and i can understand that |
| 01:29 |
erle |
it just goes back to the âonly what coredevs like will be mergedâ thing |
| 01:30 |
erle |
it does not matter that. e.g. dragonfire and waspsaliva have better CSM apis, the parts of it that are never useful for cheating are not going to be merged if the are not even *submitted* because the authors are so alienated |
| 01:30 |
erle |
this is, by the way, largely invisible unless you look at those projects from the outside |
| 01:31 |
erle |
like if i did not *know* there were clients where you could actually do stuff like script a fake player to build a schematic in game to test something i would think that simply did not exist |
| 01:31 |
erle |
because i don't see it proposed in minetest |
| 01:32 |
erle |
for me this is actually an example of stuff that can not easily be used to cheat, because detecting someone putting lots of nodes in some space in a short time is trivial. and also they need to actually get these materials. |
| 01:33 |
MTDiscord |
<warr1024> I mean handling gamma correctly sounds like it's close to the mathematical equivalent of doing relativistically-correct kinematics instead of just newtonian. Â Granted the difference would be more visible, but the added complexity to the math involved in like EVERY operation of certain types seems like it would get annoying if you're already used to not needing an abstraction to handle it. |
| 01:33 |
erle |
uh what? |
| 01:33 |
erle |
you just need to do the operations in different spaces, gamma vs linear |
| 01:34 |
MTDiscord |
<warr1024> relativity: you can't just add velocities, you need to use a special function; gamma correctness: you can't just add colors, you need to use a special function. |
| 01:34 |
erle |
uh, you can just add colors. but like, different addition function. |
| 01:34 |
MTDiscord |
<warr1024> "do the operation in different spaces" ... yeah, that space being an abstraction. Â If you expect people to do it without that abstraction that'd be even WORSE. |
| 01:34 |
erle |
consider the following though, non-gamma-correct stuff is highly unintuitive |
| 01:35 |
erle |
for example if you do PWM for an LED and it is not gamma-correct, then it looks like the LED becomes brightar fast ⌠and then no longer. |
| 01:35 |
erle |
you basically waste a huge amount of brightness range |
| 01:36 |
erle |
but if you do it gamma-correct then the LED becomes linearly brighter |
| 01:36 |
erle |
i mean this is a stupid example, but you simply can not expect good results when âadding colors togetherâ naively |
| 01:36 |
erle |
like, if you wanted to invert a black and white image for example, you can just do ( 255 - value ) for each pixel |
| 01:37 |
erle |
but i bet that won't look right |
| 01:37 |
erle |
i mean i actually know it will not look right because i did that and failed |
| 01:38 |
erle |
i think why i am against the comparison with relativistic things is because newtonian mechanics are âgood enoughâ |
| 01:38 |
erle |
gamma-unaware graphics operations though? almost every thing will look âslightly offâ at least, always |
| 01:38 |
erle |
like it makes no sense that downscaling an image makes it darker or that you get a black seam when blending from one bright color to another bright color |
| 01:39 |
erle |
that it is harder to implement, yeah |
| 01:39 |
erle |
but like ⌠most engines do this correctly. most graphics programs do this correctly. |
| 01:39 |
erle |
at least most i know |
| 01:40 |
erle |
CSS actually does it wrong IIRC and it makes color gradients weird |
| 01:40 |
MTDiscord |
<warr1024> Considering that MT[G] doesn't have a cap on velocity because you just accelerate as you fall with no air resistance, newtonian mechanics aren't necessarily "good enough" đ |
| 01:40 |
erle |
the cap is how fast you can get sent blocks though |
| 01:41 |
erle |
in any case, i'd rather work in some space where the values from 0 to 255 linearly map to my perception of brightness |
| 01:41 |
erle |
and not in some space where they do not (which is what you get when not accounting for gamma) |
| 01:41 |
erle |
simply because that way i get more dynamic range out of the 8 bits of of brightness i have |
| 01:41 |
MTDiscord |
<warr1024> The failure to load mapblocks fast enough is the actual c speed in MT, not some theoretical value inherited from IRL ... đ¤ |
| 01:42 |
erle |
btw, was the LED example a good one in your opinion? |
| 01:42 |
erle |
for how gamma can matter even in the stupidest of cases? |
| 01:42 |
MTDiscord |
<warr1024> not ... really? Â Like, I can't really picture noticing it. |
| 01:43 |
erle |
okay, but you know what PWM is or not? |
| 01:43 |
MTDiscord |
<warr1024> Like, if you want to have a linear correspondence between LED perceived brightness and something else then maybe, but when I look at the brighness of an LED I'm used to not assuming linearity in any case. |
| 01:43 |
erle |
yeah but assume you have a dimmer or so |
| 01:44 |
erle |
or a color fade effect |
| 01:44 |
MTDiscord |
<warr1024> You're just talking about changing the overall brightness of the LED by changing the duty cycle, which is a pretty reasonable way to do it when you can't e.g. directly control analog voltage or current ,sure. |
| 01:44 |
erle |
yes |
| 01:44 |
erle |
so in the non-gamma-aware world linearly changing the duty cycle does not linearly change brightness |
| 01:44 |
erle |
and your dimmer will make it look brighter until about the 50% mark or so |
| 01:45 |
erle |
and then you can turn it âbrighterâ but nothing much happens perception-wise |
| 01:45 |
MTDiscord |
<warr1024> you're just explaining what gamma correction IS though, I thought you wanted an example that demonstrates why it's so important. |
| 01:45 |
erle |
well you *probably* want your dimmer to actually result in a noticable change overall |
| 01:45 |
MTDiscord |
<warr1024> I don't think gamma curves come as a surprise to anyone who knows Weber's law or anything; human perception is notoriously non-linear. |
| 01:45 |
erle |
or your fade-out effect not look like âit gets a bit darker than cuts offâ |
| 01:46 |
erle |
yeah |
| 01:46 |
erle |
and implementing it is not magic. it is just work. work that is unglamorous. |
| 01:46 |
erle |
and i have seen with the map increase stuff what happens to huge chunks of unglamorous work. |
| 01:46 |
erle |
if it has no coredev approval, nothing happens |
| 01:47 |
erle |
so, back to that thing? you see an âoutâ? |
| 01:47 |
erle |
i don't |
| 01:47 |
MTDiscord |
<warr1024> I'm pretty sure the dimmer on the lights in my dining room aren't linear at all and it doesn't bother me all that much. Â I don't expect to turn the dial twice as far and perceive twice as much light; I just expect to turn the dial until it reaches the light level I want and then stop, regardless of how "linear" the path was to get there. |
| 01:47 |
erle |
they don't need to be linear perfectly |
| 01:47 |
erle |
95% okay is okay most of the time |
| 01:47 |
erle |
but you prob don't want the dimmer that does nothing perceptually for a huge chunk of its range? |
| 01:48 |
erle |
like going from 0 to 10 PROBABLY is a lot brightness wise |
| 01:48 |
erle |
but going from 245 to 255 almost nothing |
| 01:48 |
erle |
(non-gamma-correct world) |
| 01:49 |
erle |
in any case, i wish to get back to the topic of âi did as much as i could and still the barrier is too highâ |
| 01:49 |
MTDiscord |
<warr1024> You "out" would probably be just to submit a feature request for gamma-correct rendering, and being willing to do the work yourself. I don't know if your feature request would have been rejected if it were an issue seeking concept approval rather than a PR seeking to be merged. Â Then, once you had a PR, it would already have some core dev support behind it getting merged, and you could just merge the work and the test at the same |
| 01:49 |
MTDiscord |
time. |
| 01:49 |
erle |
if something as simple as fixing several rendering regressions is facing this amount of backlash i am actually surprised that features make it lol (okay i am being WAY too sarcastic here) |
| 01:50 |
erle |
oh but i already stated how i would do it and that was the reason to not do it |
| 01:50 |
erle |
i see no point in actually doing the work if my plans to do it get shot down with ânope not doing itâ |
| 01:50 |
erle |
not âcome to us with a proof of conceptâ |
| 01:50 |
MTDiscord |
<warr1024> Looking at the issue, it's like 1.5 years old now, and I don't remember what the process was at the time. Â I know that now, you're supposed to open the issue first, to get discussion and buy-in on the concept first, and then PRs are only considered after that. |
| 01:50 |
erle |
just âthis is too much, not doing itâ |
| 01:51 |
MTDiscord |
<warr1024> Those two things sound like they mean the same to me. |
| 01:51 |
erle |
to me no |
| 01:51 |
MTDiscord |
<warr1024> "WE are not doing this. Â I'm not saying anything definite about what will happen if YOU do." |
| 01:51 |
erle |
did you read the chatlogs? |
| 01:51 |
erle |
i have seen well-thought out PRs die because of no coredev support |
| 01:51 |
MTDiscord |
<warr1024> No, I read the issue thread |
| 01:52 |
MTDiscord |
<warr1024> I don't particularly want to dig up ALL the dirty laundry on each issue đ |
| 01:53 |
erle |
well if you were a coredev i would totally do it if you personally supported it |
| 01:53 |
erle |
or if you had a viable fork |
| 01:54 |
erle |
like it does, for example, not make sense to contribute stuff like this to dragonfire |
| 01:54 |
erle |
lizzy did actually work on an alternative minetest client written from the ground up though |
| 01:54 |
erle |
no idea if she ever finishes it |
| 01:54 |
erle |
but she listened to me ranting about gamma stuff and realized it is important |
| 01:54 |
erle |
so maybe i just need to way 10 years or so and the issue fixes itself :D |
| 01:55 |
|
ShadowBot joined #minetest |
| 01:55 |
erle |
Warr1024 btw do YOU have things you would like to see in the engine that have no coredev support? |
| 01:55 |
MTDiscord |
<warr1024> I actually was a core dev, briefly. Â I think I was the only one who never made it as a "current" dev in the project credits, I went directly from contributor to former core dev. |
| 01:56 |
erle |
funny |
| 01:57 |
erle |
so what contribution was it that made you coredev? |
| 01:57 |
erle |
(last time i asked my contributions were all too far in the past) |
| 01:57 |
MTDiscord |
<warr1024> The official reason I was removed was because I didn't submit any PRs (I was focused on reviewing some, and then had to go away for a couple of months or something) but tbh I don't really know all the motivations necessarily behind that decision. |
| 01:58 |
erle |
well so can you become one again? |
| 01:58 |
erle |
surely that would raise the quality a bit |
| 01:58 |
erle |
or do you not have time? |
| 01:58 |
MTDiscord |
<warr1024> I think a big factor in having made me a core dev in the first place was that at the time they were trying to hear from gamedevs more, so they wanted gamedevs to have more influence... |
| 01:58 |
erle |
you mean devs of minetest games? |
| 01:59 |
MTDiscord |
<warr1024> I mean, I have the time under the standard I was told at the time I started in that there is no minimum time, you just participate as you are able. Â Sometimes I am able, sometimes not so much. |
| 01:59 |
MTDiscord |
<warr1024> yeah, MT gamedevs, devs of MT games |
| 01:59 |
erle |
bc the ppl i have talked to who develop other game stuff have ⌠uh ⌠less than nice opinions about the dev process of minetest :D |
| 01:59 |
erle |
who else was recruited though? |
| 01:59 |
erle |
and when was it? |
| 02:01 |
MTDiscord |
<warr1024> I've seen this kind of things happen before, anyway, at work. Â You have one team that's the "grunts" who deal with day to day customer requests, and you have one team that's the "ivory tower" that builds the architecture the grunts consume. Â Then there's all this annoyance from the fact that the ivory tower thinks they're serving the grunts' customers but they're just ignoring the grunts themselves, so they try to "integrate the teams" or |
| 02:01 |
MTDiscord |
some shit, but it just doesn't work because the skillsets don't match up well enough, and that just reinforces a cultural divide. |
| 02:02 |
erle |
well if you put it in work terms, maybe you can understand where i come from |
| 02:02 |
erle |
i once was a developer, but i do IT security now |
| 02:02 |
MTDiscord |
<warr1024> 2021-06-21 was when I was nominated for coredevship, at least that much I was able to find in search. |
| 02:02 |
erle |
so i get literally paid for âthis is shitâ, âthis is not tested enoughâ and writing reports on what kind of bugs to prevent if you do things 100% correct |
| 02:03 |
erle |
i actually don't think that the reason i can do this is that i am very smart (when ever i write âi am very smartâ it is a joke) |
| 02:03 |
erle |
but because i have a somewhat lower tolerance for inconsistent mental models of how a software ecosystem works |
| 02:04 |
erle |
like i am much more irritated by things others gloss over, they recognized it, but i put work in bc it might be important (often it is not) |
| 02:05 |
erle |
and i have noticed this with other people too who focus on security or QA. |
| 02:05 |
erle |
a lot of them would not actually be good developers, but are good reviewers |
| 02:05 |
erle |
but for QA for example only in terms of âyou can't do thatâ, not in terms of âthis is how to do it betterâ |
| 02:06 |
erle |
(as a security person who was a dev i can actually say âthis is how to do it betterâ in cases about which i know enough, but i often can not) |
| 02:06 |
erle |
Warr1024 so how does it end at work? ever saw it have a good ending? |
| 02:12 |
MTDiscord |
<warr1024> I left that company and went to another company that has the same problem but on a much smaller scale đ |
| 02:12 |
MTDiscord |
<warr1024> I couldn't tell you if an optimal outcome is possible, but I haven't observed one yet. |
| 02:17 |
erle |
i think a good thing would be if everyone had âskin in the gameâ so to say |
| 02:18 |
erle |
new API? let it be designed by people who make mods that would use it |
| 02:18 |
erle |
or at least listen to them |
| 02:18 |
erle |
deprecate something that is used? not unless you provide an upgrade path that is deemed acceptable by the people using the API |
| 02:19 |
erle |
i think the WHATWG vs the W3C showed this difference |
| 02:19 |
erle |
and now with chrome dominance all of that is sadly becoming less relevant |
| 02:19 |
erle |
i need to sleep though |
| 02:19 |
MTDiscord |
<warr1024> Making it stakeholder-driven would make for a better product, but implementing something that somebody else can design and you have limited influence over is less fun, which makes for a harder time finding volunteers in a hobby project, probably... |
| 02:19 |
erle |
thanks for the what Warr1024 |
| 02:19 |
erle |
btw i am surprised that you never did TDD |
| 02:19 |
erle |
i wonder what worked for you to get to results fast |
| 02:21 |
erle |
hmm, i wonder if a fork could succeed if it promised to listen more to actual gamedevs and had a lower barrier to entry for contributions of functionals and a higher one for contributions of nonfunctionals. |
| 02:22 |
erle |
there is probably some very concrete thing missing |
| 02:22 |
erle |
like bigger map size or so |
| 02:22 |
MTDiscord |
<warr1024> Evaluating who counts as a "gamedev" for purpose of voting share, and what counts as "functional" for purposes of threshold, sounds challenging. |
| 02:22 |
erle |
a functional is easy |
| 02:23 |
MTDiscord |
<warr1024> For my purposes, I don't really need a ton of new features or expansions of existing features, but I'd like to see some bugs fixed. Â Like entity attachments, the ABM scheduler, or ent/particle draw performance. |
| 02:23 |
erle |
i remember the PR for particle draw performance that used the irrlicht particle system that was much more performant. guess what got deleted from irrlichtmt! :D |
| 02:24 |
erle |
the reason it was not accepted is because it could not do the vertical rain particles |
| 02:24 |
erle |
(to which i would ask: could they not be special-cased?) |
| 02:24 |
erle |
(no idea) |
| 02:24 |
MTDiscord |
<warr1024> Whatever it was about irrlicht's particles that made them able to perform better seems like it should be able to be fitted into MT somewhere, seeing as how the projects are now intertwined anyway. |
| 02:25 |
erle |
well it was simply less stupid |
| 02:25 |
MTDiscord |
<warr1024> Moving things from irrlicht to MT is probably the right overall direction, under the theory that Irrlicht itself could someday be eliminated. |
| 02:25 |
MTDiscord |
<warr1024> If it's just about less stupid then we should just delete some of the stupid from MT then đ |
| 02:25 |
erle |
given how the irrlicht maintainer has been much nicer than the irrlichtmt maintainers i think all of it was a mistake, but also my opinion does not count |
| 02:26 |
erle |
i don't think the stupid can simply be deleted |
| 02:26 |
erle |
i mean think about the inventory rendering stuff |
| 02:26 |
erle |
it is insanely wasteful, but you need something better |
| 02:27 |
erle |
for the particles, well. i think it is the same thing as with the shadows. |
| 02:28 |
MTDiscord |
<warr1024> Well ... I don't need something better, at least đ |
| 02:28 |
erle |
it had always been possible, but no one ever tried |
| 02:28 |
erle |
hard enough |
| 02:28 |
erle |
i think you are spot on with âstuff must be funâ |
| 02:29 |
erle |
btw, my personal way to figure out if someone is i legit gamedev would be to simply see if they have a mod on cdb that has 1000 downloads (adjust that number as you wish) |
| 02:30 |
erle |
even a low-effort-but-useful mod like mcl lever status indicator achieved that |
| 02:30 |
MTDiscord |
<warr1024> I tend to think of mod devs and game devs separately. Â A mod dev usually has to focus on adding a specific feature ... a game dev needs to think about overall experience... |
| 02:31 |
MTDiscord |
<warr1024> I'm also wary of downloads as a metric, that's like choosing people to govern based on how good they are at campaigning đ |
| 02:31 |
erle |
maybe that is true for your game, but at least the stuff i have seen (mesecraft, mineclone2, mineclonia) are more mod soup |
| 02:31 |
erle |
Warr1024 having a popular mod simply means you have done *something* |
| 02:32 |
MTDiscord |
<warr1024> Not all mod soups are necessarily equal, and the good mod soups tend to do a lot of integration work. |
| 02:32 |
erle |
indeed |
| 02:32 |
erle |
that's i think one difference between mineclone2 and the new mineclonia. the latter even has some workaround mod IIRC to fix some of the bugs the former never fixed. |
| 02:32 |
MTDiscord |
<warr1024> I "don't like soups" mainly because I don't like the assumptions that it feeds, like that more = better. |
| 02:33 |
erle |
oh, did you ever play mesecraft though? |
| 02:33 |
erle |
i think it was the first good mod soup i encountered |
| 02:34 |
erle |
Warr1024 i can make it even clearer: stakeholders who should be listened to when changing an API are people who have published mods that use an API before any change to that API got proposed. |
| 02:34 |
MTDiscord |
<warr1024> No disrespect to mesecraft itself but I was never all that interested in the "soup genre" per se ... in essence, I left MC and came to MT back in like 2013ish to get away from soupism. |
| 02:35 |
erle |
which btw cleanly maps to the frustration |
| 02:35 |
erle |
because obviously the people who use an API complain the most |
| 02:35 |
|
___nick___ joined #minetest |
| 02:35 |
erle |
and with stuff like ârotate the moonâ you have one person (zughy) who wants it one way and a lot of other people (who have mods that have moons) who do not |
| 02:35 |
MTDiscord |
<warr1024> We do need to consider serious prospective users of API changes though, even though they haven't used the old API in the past, because otherwise we may have too strong of a bias toward just keeping things as they are. |
| 02:36 |
MTDiscord |
<warr1024> People who use an API are a great source of suggestions for bugs but they won't necessarily be exhaustive about what new features or refactors should be considered. |
| 02:36 |
erle |
oh but they *will* complain about an API upgrade being too timid |
| 02:36 |
erle |
i have seen that again and again and i am doing it myself |
| 02:37 |
erle |
(and all complaints i can come up with right now were being ignored) |
| 02:37 |
|
ShadowBot joined #minetest |
| 02:37 |
erle |
(maybe it does not sting so much when i am actually heard hehe) |
| 02:37 |
|
___nick___ joined #minetest |
| 02:38 |
erle |
Warr1024 so far i think minetest has gotton a LOT of âi want to to this with the API but i can notâ |
| 02:38 |
erle |
take dual wielding |
| 02:39 |
erle |
or movement prediction |
| 02:40 |
MTDiscord |
<warr1024> It's hard to tell how much benefit each one of those may have on the ecosystem though. Â Like, even if you get gamedevs to vote on it, it's hard to say how much it will actually count for in the long run. |
| 02:40 |
erle |
Warr1024 anyway i have a NEED FOR SLEEP |
| 02:40 |
erle |
i don't say âlet gamedevs vote on itâ |
| 02:41 |
erle |
i say âtake their contributions and/or listen to them when designing a featureâ |
| 02:41 |
erle |
it would also be nice if regressions would not be tolerated lol |
| 02:41 |
MTDiscord |
<warr1024> I don't think core devs DON'T take our feedback, it's just not consistent ... and without a system (like voting) it's hard to ensure consistency. |
| 02:42 |
erle |
well, not only is it not consistent, it is skewed |
| 02:42 |
erle |
like if a coredev wants something they can get it with one more person to support them |
| 02:42 |
erle |
if a non-coredev wants something, tough luck |
| 02:43 |
MTDiscord |
<warr1024> Zughy is conducting an interesting experiment, at least. I've been poking around in the issues and such trying to decide what I want to put on my Top 3. Â I don't know how much of a difference gamedev clout will make, but maybe it's something... |
| 02:43 |
erle |
i find it interesting that i seem to be the only one who has listed 2 things that don't affect themselves so far |
| 02:44 |
erle |
but do affect a lot of users |
| 02:45 |
erle |
i am always wary of votes in issue trackers though |
| 02:45 |
MTDiscord |
<warr1024> It depends on what criteria you have for voting access, I guess. |
| 02:45 |
MTDiscord |
<warr1024> Like, there's a reason citizens are allowed to vote but temporary residents not so much. |
| 02:45 |
erle |
IIRC ancientmariner got voted as the new maintainer of mineclone2. with a 24 hour voting period. and a funny message afterwards that âso few people voted, no idea whyâ. |
| 02:45 |
erle |
:D |
| 02:46 |
erle |
i always wonder in these cases, why not just skip the voting. it's not like as if any previous maintainer was elected democractically (and i consider this election being a sham lol) |
| 02:46 |
erle |
it's not a democracy after all |
| 02:46 |
MTDiscord |
<warr1024> everyone expects democracy, even when there's no real reason you should. |
| 02:47 |
erle |
yeah but you could at least make it believable |
| 02:47 |
erle |
like you can still rig it |
| 02:47 |
erle |
but 24 hour voting period directly after an announcement, lol |
| 02:47 |
erle |
anyways |
| 02:47 |
erle |
i need to sleep |
| 02:48 |
erle |
and i strongly suggest to do a TDD experiment focused on entirely useless code to see how it feels for a few hours. if you have that time. i consider it a meditative practice. |
| 02:48 |
erle |
but then again i also consider writing quines a lesson. |
| 02:48 |
MTDiscord |
<warr1024> I guess it also depends on whether I'm familiar enough with testing tools to make it work. |
| 02:48 |
erle |
when i suggested writing a quine to my ex girlfriend she became first confused and then intensely angry. |
| 02:49 |
erle |
that is the frustrating part, you are not at the start. |
| 02:49 |
erle |
only once you are familiar with the tooling you can truly evaluate if this is for you |
| 02:49 |
erle |
but how do you test right now? |
| 02:49 |
MTDiscord |
<warr1024> Haha, I just basically rig my own tooling in essence |
| 02:50 |
erle |
i mean the simplest test function can be something like assert( foo(x) == bar ) |
| 02:50 |
MTDiscord |
<warr1024> like if I'm making a library, I'll just make a program that uses the library, calls shit in there with inputs, and then asserts and compares outputs. |
| 02:50 |
erle |
that passes for tdd reasons |
| 02:50 |
erle |
then you are, essentially, doing stuff the TDD way (if you write that program before the library) |
| 02:50 |
erle |
i mean, the trick is to actually do it before |
| 02:50 |
MTDiscord |
<warr1024> I also don't know how I'm supposed to test a test if I haven't written an implementation that I believe is correct đ |
| 02:50 |
erle |
to not be influenced by the library design |
| 02:51 |
erle |
oh |
| 02:51 |
erle |
that may be a bit more difficult, yes |
| 02:51 |
erle |
one way you can do is property-based testing |
| 02:51 |
erle |
but i really need to sleep |
| 02:51 |
erle |
look into python's hypothesis framework if you want to know more |
| 02:51 |
MTDiscord |
<warr1024> I tend to write the program and the library together, though I add the feature to the library first, and then write the test for it, and then test and release them together. |
| 02:51 |
erle |
i see |
| 02:52 |
MTDiscord |
<warr1024> so maybe I'm not THAT far off of TDD, since I tend to do them logically simultaneously in some cases at least. |
| 02:52 |
erle |
do you do screencasts or development reports? |
| 02:52 |
erle |
i wish to witness the development |
| 02:52 |
erle |
not only because nodecore is well-thought-out but also because i want to know what you do that i do not and that works for you |
| 02:52 |
MTDiscord |
<warr1024> Hmm, this is mostly for stuff I do for work, so all proprietary stuff I can't share. |
| 02:52 |
erle |
oh i see |
| 02:52 |
MTDiscord |
<warr1024> For nodecore I rarely did like livestreaming or anything |
| 02:53 |
erle |
well if you ever do, pls tell |
| 02:53 |
erle |
i bet i would not be the only person looking |
| 02:53 |
MTDiscord |
<warr1024> and nodecore is also not as testy as some stuff for work (it tends to be all integration work rather than complex units that are easily decoupled) |
| 02:54 |
erle |
btw, the big lesson from TDD for me was that people who think writing tests is hard usually write tests after programs (or even for programs they have not written) |
| 02:54 |
erle |
and some code is just untestable |
| 02:54 |
erle |
for example the translation helper script in the utils folder |
| 02:54 |
erle |
can't unit test that |
| 02:54 |
MTDiscord |
<warr1024> The good part about nodecore dev that I think I would encourage peopel to emulate is probably more general attitudes, like how I balance progress and stability, handle communication about changes, or handle feedback from users ... but not necessarily how I wrangle code or architecture đ |
| 02:55 |
erle |
well the floor is low |
| 02:55 |
erle |
and the ceiling too |
| 02:55 |
erle |
if you want to feel better about yourself, read 10 things from the mineclone2 bug tracker ;) |
| 02:56 |
erle |
btw, what was the best user feedback you got, in terms of âhelpful for developmentâ? |
| 02:56 |
MTDiscord |
<warr1024> Oh wow, that's a lot to think back through... |
| 02:57 |
erle |
well maybe later |
| 02:57 |
erle |
good night |
| 02:57 |
MTDiscord |
<warr1024> o/ |
| 02:57 |
erle |
(for real now) |
| 03:43 |
|
Boingo joined #minetest |
| 03:49 |
|
YuGiOhJCJ joined #minetest |
| 04:19 |
|
YuGiOhJCJ2 joined #minetest |
| 05:00 |
|
MTDiscord joined #minetest |
| 06:00 |
|
calcul0n joined #minetest |
| 06:25 |
|
e1z0 joined #minetest |
| 06:57 |
|
sometalgoo joined #minetest |
| 07:10 |
|
calcul0n_ joined #minetest |
| 07:31 |
|
Norkle joined #minetest |
| 07:36 |
|
Talkless joined #minetest |
| 07:36 |
|
BuckarooBanzai1 joined #minetest |
| 07:36 |
|
cryne0 joined #minetest |
| 07:37 |
|
Den4ikRus_ joined #minetest |
| 07:37 |
|
SpaceMan1ac joined #minetest |
| 07:37 |
|
Noisytoot joined #minetest |
| 07:37 |
|
panwolfram_ joined #minetest |
| 07:39 |
|
dabbill_ joined #minetest |
| 07:39 |
|
tel4 joined #minetest |
| 07:40 |
|
TeXMaster joined #minetest |
| 07:43 |
|
mmuller_ joined #minetest |
| 09:13 |
|
krupa1 joined #minetest |
| 09:18 |
|
jaca122 joined #minetest |
| 09:33 |
|
definitelya joined #minetest |
| 09:35 |
|
Waffelo joined #minetest |
| 10:02 |
|
mrkubax10 joined #minetest |
| 10:46 |
|
vampirefrog joined #minetest |
| 10:48 |
|
appguru joined #minetest |
| 10:54 |
|
s20 joined #minetest |
| 11:03 |
|
TomTom joined #minetest |
| 11:05 |
|
Alnotz joined #minetest |
| 11:10 |
|
Sobinec joined #minetest |
| 11:30 |
|
YuGiOhJCJ2 joined #minetest |
| 12:03 |
erle |
quick question: from the ones not already having commented, who here uses bilinear or trilinear filtering or anisotropic filtering on an intel GPU? see https://github.com/minetest/minetest/issues/14007#issuecomment-1817489184 if you don't know what i mean (last one is current broken state with aniso on intel GPU). |
| 12:04 |
|
YuGiOhJCJ2 joined #minetest |
| 12:06 |
|
fluxionary joined #minetest |
| 12:08 |
erle |
ROllerozxa if minetest does not take that patch, would rollertest want to unfuck the filtering? i am trying to evaluate the options and see what is the most viable fork rn. |
| 12:08 |
erle |
and i think dragonfire is too far off from vanilla minetest |
| 12:09 |
erle |
tbh i hate it that most of my energy going into minetest is âunbreak stuffâ :( |
| 12:09 |
erle |
and that ppl seem to think breaking stuff is necessary in the name of progress |
| 12:10 |
erle |
(if that was the case, firefox would have stopped working on my machine by now) |
| 12:33 |
|
krupa1 joined #minetest |
| 12:42 |
|
Thelie joined #minetest |
| 13:10 |
|
MTDiscord joined #minetest |
| 13:25 |
|
Sobinec joined #minetest |
| 14:33 |
|
hifi joined #minetest |
| 14:44 |
|
s20 joined #minetest |
| 15:30 |
|
s20 joined #minetest |
| 15:38 |
|
jaca122 joined #minetest |
| 15:45 |
|
mrkubax10 joined #minetest |
| 15:50 |
|
mmuller joined #minetest |
| 16:11 |
|
mmuller joined #minetest |
| 16:18 |
|
Desour joined #minetest |
| 17:02 |
|
sometalgoo joined #minetest |
| 17:04 |
|
Sobinec joined #minetest |
| 17:56 |
|
Desour joined #minetest |
| 18:12 |
|
sparky4 joined #minetest |
| 18:16 |
|
lissobone joined #minetest |
| 18:16 |
lissobone |
MINETEST HAS FALLEN |
| 18:16 |
lissobone |
BILLIONS MUST CRAFT |
| 18:16 |
|
lissobone left #minetest |
| 18:26 |
|
Desour joined #minetest |
| 18:42 |
|
s20 joined #minetest |
| 18:43 |
sometalgoo |
This is the weirdest thing. Â I updated from 5.6.1 to 5.7 for my server. Â Everything seemed to run very well. Â I then updated my client to 5.7. Â As I moved around, some blocks and things I built just disappeared. Â I'm monitoring the debug logs and there is no entries showing any blocks being removed or anything like that. Â I simply move around my character in the game, and things just disappear. Â It doesn't appear to be a GUI thing e |
| 18:43 |
sometalgoo |
er. Â If I exit the game and join again, the blocks that disappeared in the game don't come back. Â Same if I try joining from another client. |
| 18:44 |
|
sometalgoo joined #minetest |
| 18:50 |
sometalgoo |
This is so weird. Â It's almost like the mapgen is just starting all over and overwriting areas that were already generated. |
| 18:51 |
rubenwardy |
is the worlds folder writable? |
| 18:55 |
sometalgoo |
Looks like it's writable. Â I just did an ls -l command and I see the worlds folder having rwxrwxr-x. |
| 19:10 |
|
Thelie joined #minetest |
| 19:23 |
|
sometalgoo joined #minetest |
| 19:42 |
|
iamweasel joined #minetest |
| 20:06 |
|
iamweasel joined #minetest |
| 20:17 |
|
appguru joined #minetest |
| 20:52 |
erle |
sometalgoo this could be a mistake with worldgen, which game is it? |
| 20:53 |
erle |
sometalgoo you can get this effect in some games too if you join some downloaded map and your mapgen is not singlenode |
| 21:04 |
|
imi joined #minetest |
| 21:16 |
|
krupa1 joined #minetest |
| 22:03 |
|
Lastick joined #minetest |
| 22:25 |
|
liceDibrarian joined #minetest |
| 22:30 |
|
Peter101 joined #minetest |
| 22:30 |
|
Peter101 left #minetest |
| 22:49 |
|
imi joined #minetest |
| 22:53 |
|
imi joined #minetest |
| 23:24 |
|
Sokomine joined #minetest |
| 23:28 |
|
maeve joined #minetest |
| 23:35 |
|
panwolfram joined #minetest |
