| Time |
Nick |
Message |
| 00:27 |
|
liceDibrarian joined #minetest |
| 00:58 |
|
Noisytoot joined #minetest |
| 01:04 |
|
Noisytoot joined #minetest |
| 01:09 |
|
Verticen joined #minetest |
| 01:20 |
|
smk joined #minetest |
| 02:02 |
|
y5nw joined #minetest |
| 02:19 |
|
v-rob joined #minetest |
| 02:28 |
|
behalebabo joined #minetest |
| 02:30 |
Swift110-mobile |
Ok |
| 02:32 |
|
kamdard joined #minetest |
| 02:37 |
|
panwolfram joined #minetest |
| 02:37 |
DeepThgt |
https://i.imgur.com/Z6HkDrV.png |
| 02:37 |
DeepThgt |
halloween decorations finished :D |
| 02:43 |
|
gxt joined #minetest |
| 03:08 |
|
YuGiOhJCJ joined #minetest |
| 03:51 |
|
Noisytoot joined #minetest |
| 04:00 |
|
MTDiscord joined #minetest |
| 04:11 |
|
Noisytoot joined #minetest |
| 04:16 |
|
Noisytoot joined #minetest |
| 04:27 |
|
Noisytoot joined #minetest |
| 04:39 |
|
Noisytoot joined #minetest |
| 05:11 |
|
Izaya joined #minetest |
| 05:37 |
|
amfl joined #minetest |
| 06:03 |
|
calcul0n joined #minetest |
| 06:10 |
|
v-rob joined #minetest |
| 06:11 |
|
calculon joined #minetest |
| 06:55 |
|
calcul0n_ joined #minetest |
| 07:45 |
|
TomTom joined #minetest |
| 08:26 |
|
gxt joined #minetest |
| 08:33 |
|
mrkubax10 joined #minetest |
| 09:06 |
|
calcul0n joined #minetest |
| 09:07 |
|
calcul0n joined #minetest |
| 09:21 |
|
vampirefrog joined #minetest |
| 09:23 |
|
YuGiOhJCJ joined #minetest |
| 10:02 |
|
e1z0 joined #minetest |
| 10:14 |
|
appguru joined #minetest |
| 10:52 |
|
dibesfer joined #minetest |
| 11:43 |
|
s20 joined #minetest |
| 12:06 |
|
Trifton joined #minetest |
| 12:09 |
|
the_sea_peoples joined #minetest |
| 12:21 |
MTDiscord |
<cosmician> I was thinking about making a small PR adding connected player count to the IRC mod's /player command. What is the course of action for me: just a straight PR? Or is there some formality before that? |
| 12:23 |
MTDiscord |
<cosmician> I believe this is the right channel…since I might find folks who work on that here more |
| 12:30 |
|
definitelya joined #minetest |
| 12:38 |
erle |
how can i mark comments on github offtopic? AFCMS is posting “wah wah your hardware is bad” and not helping in this issue https://github.com/minetest/minetest/issues/13920 |
| 12:39 |
erle |
and it's annoying and shows a lack of respect for my efforts |
| 12:48 |
|
appguru joined #minetest |
| 12:50 |
MTDiscord |
<wsor4035> you dont |
| 12:52 |
erle |
well then not |
| 12:52 |
erle |
i just find it annoying when people are like “minetest can not properly work on your computer and firefox can not too” |
| 12:53 |
erle |
i know that minetest does not work well on that old hardware ON WINDOWS |
| 12:53 |
erle |
but on linux it's generally fine |
| 12:53 |
erle |
and so is firefox |
| 12:54 |
erle |
in any case, i am doing the debugging work (with the help of a friend who apparently used to work in the games industry) and i think it is pointless to ask me to not do it, if fixing this bug can improve general correctness |
| 12:54 |
erle |
after all, i am putting in the work |
| 13:04 |
ROllerozxa |
erle: a coredev or triager would need to mark such comments as offtopic on github |
| 13:05 |
erle |
ah ok |
| 13:06 |
erle |
in any case, seems the problem with inventory rendering being stupidly inefficient has already been noticed explained: https://github.com/minetest/minetest/issues/11305#issuecomment-853113638 |
| 13:08 |
erle |
so what's like areasonable number of drawcalls relating to hardware? |
| 13:08 |
erle |
hmm maybe i should just record the drawing of other games |
| 13:14 |
ROllerozxa |
how old is that computer btw? not asking as a "gotcha", just curious |
| 13:17 |
erle |
lol AFCMS *really* likes to state “I have a modern gaming PC”: “The bare minimum my eyes support for this kind of game is around 40 FPS which ALL of my low end PCs support at 500 viewing range.” |
| 13:18 |
erle |
ROllerozxa i got it less than 5 years ago i think |
| 13:18 |
erle |
ROllerozxa but i have a bunch of old thinkpads from that era which are all fine (if you stick an SSD into them and replace the battery) |
| 13:18 |
erle |
otherwise i have a reform 1 and a reform 2 |
| 13:20 |
|
Sobinec joined #minetest |
| 13:21 |
erle |
> I doubt you could even run CS:GO on lowest settings |
| 13:21 |
erle |
bully detected, opinion rejected |
| 13:22 |
ROllerozxa |
pretty sure source engine games could run decently on a toaster if you're willing to compromise |
| 13:23 |
ROllerozxa |
heh, yes maybe you got it 5 years ago, but I mean how old the laptop model itself is |
| 13:27 |
celeron55 |
erle's laptop is from 2008, with an igpu |
| 13:27 |
celeron55 |
i'm pretty sure it will not run source engine games |
| 13:28 |
erle |
i think the proper response to “can you run cs:go even” is “were you even born when cs 1.6 came out” lol |
| 13:28 |
erle |
celeron55 about the inventory rendering, i think batching is as simple as drawng as many things without changing the materials? |
| 13:28 |
erle |
i mean if that is true, does that mean that creating a texture atlas will speed up rendering because it's the same material? |
| 13:29 |
|
Izaya joined #minetest |
| 13:29 |
celeron55 |
yes a texture atlas would be the classic (some would say legacy) way of doing that. these days of course multi-textures exist (not sure of your laptop though) |
| 13:30 |
celeron55 |
maybe texture array is the proper name |
| 13:30 |
erle |
well i wonder if just reordering the drawcalls would at least fix performance (and maybe my rendering issue) then |
| 13:30 |
erle |
i mean inventory should not have like half the fps of rendering the world hehe |
| 13:31 |
erle |
hmm, if i find a way to force minetest into using the ogles2 renderer, maybe i can debug that too |
| 13:32 |
erle |
it used to work (badly, but it worked) |
| 13:36 |
erle |
so if i render all the backgrounds first hmm |
| 13:36 |
ROllerozxa |
2008 still sounds relatively recent, I thought it was going to be old as me or even older :P |
| 13:36 |
ROllerozxa |
(I was not born when cs 1.6 came out, however) |
| 13:37 |
erle |
ROllerozxa people, especially gamers, are *vastly* underestimating how fast computers are because a bunch of common software becomes slower faster than hardware becomes faster |
| 13:38 |
ROllerozxa |
yeah |
| 13:38 |
erle |
i mean i *probably* would not have fun running GNOME on this box |
| 13:38 |
erle |
but that's on GNOME, XFCE works fine |
| 13:38 |
|
appguru joined #minetest |
| 13:38 |
erle |
this kind of thing used to happen at the mineclone2 issue tracker too |
| 13:38 |
erle |
i vaguely remember that lizzy once had the idea to try to set the texture for some flame entity (?) 66 times or so a second |
| 13:39 |
erle |
which obviously is a bit bad performance-wise |
| 13:39 |
erle |
but when i complained about it, the issue got retitled to “post your computer's specs” and people made fun of my hardware that can not even render a flame lol |
| 13:39 |
erle |
wait let me look it up |
| 13:39 |
erle |
so i don't tell bullshit |
| 13:41 |
erle |
celeron55 i recently found out wat a cheap and useful trick screenspace reflections are, did you ever try that? |
| 13:41 |
erle |
like i had been calling with a girl and she apparently knows a LOT about 3d rendering and so she began infodumping on me about shader tricks |
| 13:41 |
erle |
:3 |
| 13:42 |
rubenwardy |
erle: screen space reflections https://blog.minetest.net/2023/10/17/AugustSeptember/#engine-news |
| 13:43 |
erle |
ah yes thanks |
| 13:44 |
erle |
she also had some things to say about god rays, i have to ask her if that minetest thing is actually okay |
| 13:46 |
ROllerozxa |
up until relatively recently I was still on a computer with an old AMD phenom, it was... not great, but it was not the absolute worst thing either |
| 13:46 |
ROllerozxa |
but discord users cannot even fathom the idea that someone can even exist online with a phenom, let alone play any kind of games on it |
| 13:46 |
erle |
yeah lol |
| 13:46 |
erle |
i think discord is the worst. it is the only website that actually stalled my computer. |
| 13:47 |
erle |
and i know how frontend stuff works. like, you have to put *a lot* of work into making a website that bad :d |
| 13:47 |
erle |
:D |
| 13:48 |
erle |
ROllerozxa i have so far found that everyone who thinks my computer can not possibly be useful for day-to-day use unless i do everything in a terminal (i do not) runs multiple electron apps at all times. |
| 13:48 |
erle |
(among them, discord) |
| 13:49 |
rubenwardy |
web tech is unironically the easiest/best way to make GUIs these days |
| 13:50 |
erle |
easiest maybe, but not necessarily best. i mean gtk and qt still exist, even though gtk got worse. |
| 13:51 |
erle |
on second thought, i think it's definitely not easier to quickly fumble together some GUI using web tech compared to, e.g. making the same in GLADE and using pygtk or so |
| 13:51 |
rubenwardy |
it's the best because it's capable and not weirdly limited |
| 13:51 |
erle |
i'd say it's more approachable |
| 13:51 |
rubenwardy |
and reduces development time |
| 13:52 |
erle |
yes and makes it so that people with 16G RAM say it is not enough ;) |
| 13:55 |
erle |
anyway, i think i'll just reorder the rendering of the inventory and see where that leads |
| 14:06 |
erle |
zughy closed the issue am debugging right now: https://github.com/minetest/minetest/issues/13920 |
| 14:06 |
|
mrkubax10 joined #minetest |
| 14:07 |
erle |
closing every rendering issue does not make them go away |
| 14:07 |
erle |
so much for “general correctness” |
| 14:10 |
ROllerozxa |
wtf |
| 14:10 |
erle |
could anyone please reopen issue #13920 – i am literally working on it right now. no one from the coredevs has offered help. |
| 14:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/13920 -- Massive rendering errors with nodeboxes in inventory |
| 14:10 |
erle |
it is not a ”drain on resources” if i am debugging stuff on my own hardware! |
| 14:11 |
MTDiscord |
<warr1024> "general correctness" doesn't necessarily just go out the window because something doesn't work on one system. I think you'd need to repro the issue in multiple places to be sure it's not a fluke specific to a particularly weird bit of hardware. It's entirely possible your specific machine has a unique problem... |
| 14:12 |
MTDiscord |
<warr1024> The drain on resources is all the off topic shit people start where they make fun of people having weird hardware. If we want to not support older hardware we should at least attempt to specific some kind of boundary. |
| 14:12 |
erle |
look one should warn AFCMS instead of closing an issue i am debugging |
| 14:12 |
MTDiscord |
<warr1024> Otherwise it's perfectly legitimate for someone to open an issue |
| 14:12 |
erle |
these people are a drain on my resources |
| 14:14 |
erle |
okay, can someone else just reopen this and mark all the harassment as offtopic? |
| 14:14 |
erle |
i mean, the only think i am trying to do is improve rendering |
| 14:15 |
MTDiscord |
<warr1024> Eh, the harassment was problematic but "won't fix" is still legitimate; it doesn't mean you can't fix it, and you can even still merge your fix if you can demonstrate that it either fixes something not specific to your system or improves the code in other ways. Some more comment than just "won't fix" would have been better though. |
| 14:17 |
erle |
Warr1024 but the bug is still there and closing it means what exactly? |
| 14:17 |
erle |
i mean i *am* willing to fix it |
| 14:17 |
erle |
after all i have the hardware |
| 14:18 |
MTDiscord |
<warr1024> Closing the bug means that it is not on the to-do list of the Minetest developers. |
| 14:18 |
erle |
what |
| 14:18 |
erle |
look how am i ever going to become a coredev then |
| 14:18 |
erle |
if i finally get into the engine |
| 14:19 |
erle |
and no one else is doing it, but BECAUSE no one else is doing it, it is an issue |
| 14:19 |
MTDiscord |
<warr1024> I wouldn't recommend it, but if you really want to be a core dev, then dress for the job you want. Fix shit. |
| 14:20 |
erle |
it is what i am trying to do |
| 14:20 |
ROllerozxa |
I don't have any powers to do so, but I do think it should be reopened. if someone comes in and derails an issue to talk about how great and fast their gaming rig is then their comments should be hidden as off-topic instead, a valid issue shouldn't have to be thrown out just because of that |
| 14:20 |
erle |
incidentally, fixing this would improve performance |
| 14:20 |
erle |
like, it has been a joke for at least 5 years that minetest inventory rendering is slow |
| 14:20 |
MTDiscord |
<warr1024> Sounds good. You should fix it then, I guess. |
| 14:20 |
erle |
the issue is closed though |
| 14:21 |
erle |
why should i EVER work on something that is closed wontfix? |
| 14:21 |
|
olliy joined #minetest |
| 14:21 |
MTDiscord |
<warr1024> I noticed MT rendering getting slower around 5.6 myself, inventories not being involved even. Some speedups would be great, though inventories in particular I don't care about ... I basically never use them anymore. |
| 14:22 |
MTDiscord |
<warr1024> So if somebody else doesn't promise to fix something then you won't? That's.... a pretty weird attitude. Normally the stuff I do depends on what I say I'll do, not what other people say they'll do. |
| 14:23 |
MTDiscord |
<warr1024> If somebody else refuses responsibility for something then that is MORE likely to make me take responsibility for it, not less. |
| 14:23 |
ROllerozxa |
I think erle is talking about if it's inside the scope of what would be merged, if a fix were to be made |
| 14:24 |
erle |
yes that's the point |
| 14:24 |
MTDiscord |
<warr1024> I don't think that's what "wontfix" means here. There's no way to know what's in scope here because we don't know what the impact of a fix we don't have yet will be |
| 14:24 |
erle |
like no one would say “oh, your fix improves stuff that we don't care about” |
| 14:24 |
ROllerozxa |
by the way, if someone is determined to fix an issue, then there is this great feature in github where you can assign an issue to a user, you do not need to close it just because someone is in the process of fixing it |
| 14:24 |
erle |
Warr1024 the fix is obviously reducing the number of drawcalls which are ridiculous |
| 14:24 |
MTDiscord |
<warr1024> If all it does is fix erle's machine alone, then no, it isn't worth merging. If it does more, as erle says it will, well, I'd want to see that first. |
| 14:24 |
erle |
what |
| 14:24 |
erle |
it fixes every machine if you reduce the number of drawcalls |
| 14:25 |
erle |
i have so far not seen *any* computer on which minetest framerate does not massively go down when you have an inventory with lots of stuff |
| 14:25 |
rubenwardy |
yeah exactly that. I'm interesting in drawcall improvements, but not a fix to an obscure bug on on basically unsupported ogl versions |
| 14:25 |
rubenwardy |
-ing +ed |
| 14:25 |
rubenwardy |
draw calls may be #6905 |
| 14:25 |
ShadowBot |
https://github.com/minetest/minetest/issues/6905 -- FPS in inventories drop drastically if the inventory displays a page with items |
| 14:26 |
erle |
well i think the people who worry about drawcalls are PROBABLY not happy if i post all my debug stuff there. |
| 14:26 |
rubenwardy |
so if you fix that issue and your issue then that would be ideal |
| 14:26 |
erle |
yes i think so too. but then please reopen my issue. obviously i will have zero motivation to improve performance if it is not working at all. |
| 14:27 |
erle |
and it's not the same bug |
| 14:27 |
MTDiscord |
<warr1024> If you want to post your debug stuff here then that's fine, probably. They might mind more on GH though. |
| 14:27 |
erle |
it might be a mesa bug, in which case i will murder that issue myself |
| 14:28 |
MTDiscord |
<warr1024> If you want to track an issue that's relevant only to you then you should use your own bug tracker. I don't let people use bug trackers on my projects for their own personal issues either. |
| 14:28 |
erle |
it is not only relevant to me |
| 14:28 |
erle |
i have seen these kind of rendering errors before |
| 14:28 |
MTDiscord |
<warr1024> If it becomes relevant to someone else then that will change things, but until it does... |
| 14:28 |
erle |
on screenshots from people |
| 14:29 |
MTDiscord |
<warr1024> If you've got some evidence that it was already relevant to not just you then maybe you should submit that as part of your argument that it should be reopened. |
| 14:29 |
erle |
and obv i can't prove it because it was years ago, but the thing is, if you don't want me to fix things, then closing issues i work on is the correct call. if you want me to fix things then it is not. |
| 14:29 |
MTDiscord |
<warr1024> Having evidence doesn't make your case for you, you have to actually share the evidence. |
| 14:29 |
erle |
i hate this. |
| 14:30 |
erle |
i bet if it would not work on the computer of zughy that issue would not be closed |
| 14:30 |
erle |
it's simply an abuse of power |
| 14:30 |
MTDiscord |
<warr1024> Zughy wouldn't be the one to close it, that's pretty certain. |
| 14:32 |
MTDiscord |
<warr1024> Zughy was given that power for a reason and is using it to the best of their ability with limited information and a mountain of old stale issues that are choking the pipeline and preventing anybody from being able to focus on anything important. You can't always expect them to make the right calls, especially when you don't make a persuasive case why something is really important and then make a big deal later citing evidence you didn't |
| 14:32 |
MTDiscord |
share at the time. |
| 14:33 |
MTDiscord |
<warr1024> If it's important to you and you think it should be important to everyone, help us see what the real impact is. |
| 14:34 |
MTDiscord |
<warr1024> Ideally, if you could just demonstrate the fix for it and people could see for themselves it's better, you don't even have to argue your case, it becomes an inevitability. |
| 14:35 |
MTDiscord |
<warr1024> Even if MT rejects a patch, if it improves the engine enough that people end up wanting to use it, MT will eventually just have to find a way to make it work upstream or else deal with nobody running unpatched versions. |
| 14:35 |
erle |
i think i should focus on cheat clients instead |
| 14:36 |
erle |
and the real impact is that one of my mods (studs) does not work on probably a range of intel integrated chipsets for which i know for a fact that people are using this to play minetest. unless my hardware is broken, which could also be. but so far it is unclear. |
| 14:36 |
MTDiscord |
<warr1024> "cheat" client is sometimes even a misnomer; they can fix accessibility issues and such too... |
| 14:36 |
erle |
yes they do |
| 14:36 |
erle |
but that's the name |
| 14:37 |
ROllerozxa |
"make server owners shit themselves" clients |
| 14:37 |
MTDiscord |
<warr1024> If you can make such an impactful fix in a cheat client, it tbh has a much better chance of getting upstreamed, even forcibly... |
| 14:37 |
erle |
i think either cora or lizzy for example just added “toggle rendering particles” as response to “particle rendering is slow” |
| 14:37 |
erle |
that is by no means a fix |
| 14:37 |
erle |
but i think it never got to minetest proper |
| 14:38 |
erle |
even though it made a common method of griefing (spawn many particles) not work |
| 14:38 |
erle |
i think the particles thing was also a drawcall issue |
| 14:38 |
MTDiscord |
<warr1024> It does seem like maybe we should make things less artificially shitty before we resort to having to allow people to disable them : 😅 |
| 14:38 |
erle |
you can basically lag out people with a weak GPU by spawning particles (unless the batching thing was merged, was it?) |
| 14:39 |
ROllerozxa |
x2048's batched particles PR has not been merged, I think it needs someone to adopt it |
| 14:39 |
erle |
well i won't lol |
| 14:39 |
erle |
if all i'm getting for trying to debug shit is hate from gamer guys and closed issues i can just stop again |
| 14:40 |
MTDiscord |
<warr1024> Minetest really needs a product owner or a product ownership team or something, that decides on priorities for what the thing is supposed to accomplish. Right now we have a dev team only and they're probably too focused on what they think is feasible or HOW they think it should work... |
| 14:41 |
erle |
the problem with minetest is that the OGLES2 renderer just flat out does not work on my machine |
| 14:41 |
erle |
the ogl1.4 renderer meanwhile works on a range of devices that AFCMS would consider crap lol |
| 14:47 |
erle |
Warr1024 i am pretty sure that the only thing that would improve things in the short-term would be including people who actually make popular games or cheat clients (e.g. you or cora) but i have suggested this for a while now |
| 14:51 |
MTDiscord |
<warr1024> Yeah, I've suggested the same, like having a "steering group" or something that would give MT core a better picture of the "demand" for the engine. I guess it won't just "materialize" or anything, we'd have to build it. |
| 14:52 |
MTDiscord |
<warr1024> A big obstacle though is probably that all major game devs for MT have very strong personalities that are likely to clash. I think really we may get along worse with each other than with the core team as it is. |
| 14:54 |
MTDiscord |
<warr1024> I imagine I could create a space for such a team, put out a call, and share the impetus for participating, but I don't think I could be the one to set the tone or mediate compromises. |
| 14:58 |
erle |
i am pretty sure that most gamedevs broadly have the same goal. even unfriendly people can get along. |
| 14:59 |
erle |
evidence: ancientmariner and me can discuss tech topics just fine, even though we don't really like each other. |
| 14:59 |
erle |
:P |
| 15:00 |
erle |
Warr1024 i think an issue here is that doing what others want is generally unfun. |
| 15:00 |
erle |
(and unfair, like why should anyone do stuff for free in their free time?) |
| 15:00 |
muurkha |
nice thing about free software is that you can still copy their code even if you don't like them or agree with their direction |
| 15:00 |
erle |
i'll look at mineclone2 how it works with that ”product dev” focus |
| 15:01 |
erle |
what i mean: previous maintainers who burnt out just gave the project to another one. but ancientmariner had this idea of still controlling the focus, but someone else doing the technical work. |
| 15:01 |
erle |
i know why i wouldn't sign up for that, but maybe it works out? |
| 15:09 |
MTDiscord |
<warr1024> I think if you asked game devs if they all wanted the same things, then they would agree that they all do. But if you asked them which same things, they'd all have different lists. |
| 15:11 |
muurkha |
haha |
| 15:12 |
erle |
Warr1024 yes but for stuff like “should we deprecate this or that” or “how should the APi look” |
| 15:13 |
MTDiscord |
<warr1024> We might agree on the answers to those things ... too bad those wouldn't be the questions we'd be answering. I'm talking more about questions like "is it more important that the engine be capable of doing A or B" regardless of how exactly that happens. |
| 15:14 |
MTDiscord |
<warr1024> Like, how important is it to finally fix entity attachments so they don't just randomly go shitty in the middle of a game, vs not lagging to death just because somebody wants to use a big dramatic particle effect? Or how important is supporting a new formspec feature vs. having an API to freely move the camera around (or shit, just to be able to setlookdir with tweening)? |
| 15:18 |
erle |
i have a very simple example |
| 15:19 |
erle |
just compare the minetest.encode_png() function signature with that of tga_encoder's image:encode() – even if those would write the exact same graphics format, one of them requires a bunch of bytes, the other a table of scanlines that contain pixels. |
| 15:19 |
erle |
depending on what kind of use case you have, you might prefer one or the other |
| 15:19 |
erle |
but no one even discussed this before IIRC |
| 15:20 |
muurkha |
probably the formspec vs. camera example is not relevant; these are unrelated |
| 15:20 |
muurkha |
you won't get one by omitting the other |
| 15:20 |
erle |
and these function signature things are pretty common in software in general |
| 15:20 |
erle |
like where devs go for “what is easy to implement” and users want something different |
| 15:21 |
muurkha |
as an individual you might, because they compete for your time, and in a company you might, because you can order people to work on one thing and not the other |
| 15:22 |
muurkha |
but in Minetest the guy who wants to add features to formspecs isn't going to spend time on camera movement APIs because somebody else doesn't like his formspec ideas |
| 15:22 |
muurkha |
if anything the tendency is the other way around |
| 15:22 |
erle |
what exactly do you mean? |
| 15:23 |
erle |
i have seen a bunch of APIs that are really not thought-out well in minetest and it would have been easy to just listen to people |
| 15:23 |
muurkha |
if you like his formspec ideas maybe he'll spend more time working on minetest instead of his website, which improves your chances of him contributing to the camera work |
| 15:23 |
muurkha |
I was talking about warr1024's examples |
| 15:23 |
erle |
oh okay |
| 15:23 |
erle |
they are too far out for me i think |
| 15:24 |
muurkha |
listening is hard, let's go hacking |
| 15:24 |
erle |
yes lol |
| 15:24 |
erle |
and i mean, lots of people do this |
| 15:24 |
erle |
a coworker this morning asked me about his regex |
| 15:24 |
erle |
so i hooked up python's hypothesis to it |
| 15:24 |
erle |
and used hypothesis.strategies.from_regex to hallucinate some strings that are PROBABLY not good inputs |
| 15:25 |
muurkha |
that's awesome |
| 15:25 |
muurkha |
hypothesis is fucking amazing |
| 15:25 |
erle |
but said coworker actually told me that he was a bit grumpy because he did not want to do stuff properly in the first place |
| 15:25 |
erle |
but he also asked me to review it |
| 15:25 |
erle |
so now we have a better solution |
| 15:26 |
erle |
and we will be working on a general proposal for people how to write parsers in the company ig |
| 15:26 |
erle |
i think “use regexes with capture groups” will probably be the default |
| 15:26 |
erle |
because matching the entire input is a good parse. right? |
| 15:26 |
erle |
i.e. recognizing is parsing in one stee |
| 15:26 |
erle |
step |
| 15:27 |
muurkha |
oh, coincidentally, check out monkey-paw-pattern-rewriting.md in http://canonical.org/~kragen/sw/pavnotes2.git/ |
| 15:27 |
muurkha |
I'd love to hear your thoughts on it |
| 15:27 |
muurkha |
it's closely related to what you're talking about |
| 15:28 |
|
Yonle joined #minetest |
| 15:28 |
MTDiscord |
<warr1024> See, TGA vs PNG encoding issues are not really my concern. What I want is something like (1) I want to be able to generate images dynamically at runtime and display them on players' machines, and (2) I want it to scale reasonably well, not have excess costs, etc. The exact details of how it's accomplished, I can compromise on. Really, the more important feature for me would be to be able to dispose of images so that sending clients |
| 15:28 |
MTDiscord |
dynamic images (via texturemod, dynamic media, whatever) doesn't eventually crash things. I'm more worried about the result than the details; I just need something competent first, and then I can worry about how to use it later. |
| 15:28 |
erle |
Warr1024 it is not about TGA vs PNG encoding. it is about the shape of the API. |
| 15:29 |
erle |
Warr1024 like, do you want something to shove bytes into (in RGBA order) or do you want something that you give a pixels table to? |
| 15:29 |
MTDiscord |
<warr1024> Yeah, I wish I had the luxury of worrying about the shape of an API. Right now I just want one that works. |
| 15:30 |
muurkha |
I'm off |
| 15:30 |
muurkha |
bye |
| 15:31 |
erle |
Warr1024 what kind of images are you generating btw? |
| 15:31 |
MTDiscord |
<warr1024> Here's an example of what I'm talking about: in NodeCore, F5 coordinates are disabled, and you're supposed to learn how to navigate using the stars. I had originally designed a system where you'd be able to tell your exact location based on the movements of multiple stars ... but it turns out that doing that will crash the client as they move around because the generated skybox images are leaked and never garbage collected. |
| 15:32 |
MTDiscord |
<warr1024> Now, there are a ton of ways this could be solved. We could have multiple layer skyboxes, or skyboxes could be defined by entities or meshes that can move around, or we could clean up the oldest images to make memory space as needed, or somebody could come up with entirely different ways of approaching the same thing that I haven't thought of yet. |
| 15:33 |
MTDiscord |
<warr1024> hecks was talking about a "sky layer API" when he was still around, and that was something that I was interested in and would solve the issue. IIRC luatic once took a pass at the image GC thing and that would have solved the problem. |
| 15:34 |
erle |
i wonder though |
| 15:34 |
erle |
given that games do change the sky |
| 15:34 |
erle |
how would you be sure that the sky is no longer needed? |
| 15:34 |
MTDiscord |
<warr1024> Texture mods are a bizarre mess of an API, but I don't really care about that kind of problem. At worst, I only have to deal with it once when I build a sane API wrapper around the thing. Just having the functionality is what I'm going for; any kind of superficial sanity around it would be a luxury. |
| 15:35 |
MTDiscord |
<warr1024> Again, doesn't matter. The engine could make its own decision using an MRU. Or I could call player:destroy_image(imgname) to explicitly tell it that it should clear it. I can work with either way, or probably others I haven't thought of. |
| 15:37 |
erle |
then what is the reason that you, yourself are not working on it |
| 15:38 |
MTDiscord |
<warr1024> If I have to maintain an MRU server-side then I'd be a little annoyed, though tbh it'd probably be extra network packets that annoy me more than the inconvenience ... after all, I could be at least a little more predictive about it in ways that MTE can't. But similarly, if they only offer the dumb "images will be destroyed if not displayed on the client for 60 seconds" kind of thing, then whatever, I can live with that. If I have to |
| 15:38 |
MTDiscord |
work around it by maintaining a bunch of near-zero-sized image HUDs to keep images "alive", I can deal with that. If players have to deal with a little stutter when an image they thought was no longer needed is disposed, and I have to tell players to change a setting somewhere, and what to change it TO depends on how much RAM they have so I can't make a good guide ... well, that sucks a bit too, but I already have to do that with things like |
| 15:38 |
MTDiscord |
display gamma, so whatever. |
| 15:38 |
erle |
what's the workaround you have for display gamma? |
| 15:38 |
erle |
i mean i pretty much spelled out what would needed to be done and IIRC offered to do it and then it was rejected lol |
| 15:39 |
MTDiscord |
<warr1024> The reason I myself am not working on it is that (1) the problem is too big for my level of comfort working in C++ in general, and this engine in specific, and (2) if I'm going to fix a problem, I'd rather fix one that's more important to me, and right now the ABM scheduler being a piece of shit is probably foremost. |
| 15:39 |
erle |
it has been a piece of shit for a while |
| 15:39 |
MTDiscord |
<warr1024> My workarounds for display gamma are (1) I tell every player to change it, and give them 2 as a good starting point, and (2) I've been trying the dynamic brightness shader, to limited success. |
| 15:40 |
MTDiscord |
<warr1024> The fact that something has been shitty for a long time doesn't necessarily make it not the biggest obstacle. |
| 15:41 |
erle |
why is gamma so important to you anyway? |
| 15:41 |
MTDiscord |
<warr1024> I had actually been considering the "just replace all ABMs with node timers" thing, despite how much of a logistical nightmare it would be, up until just yesterday, actually, when I got experimental confirmation that node timers are not, as people like to suggest, super fast and efficient and are in fact just about as slow as anything else in the engine. |
| 15:41 |
MTDiscord |
<warr1024> Gamma is important because players tend to like to see when they play video games. If they didn't, I'd just make an audio game. |
| 15:42 |
erle |
oh okay hehe |
| 15:43 |
MTDiscord |
<warr1024> tbh the gamma thing would be less of a problem probably if players could adjust it in-game instead of having to quit and restart for it. That can get very annoying when it results in a lot of leave-rejoin noise in server chat logs. But you could argue a lot of things should be changeable at playtime... |
| 15:46 |
erle |
Warr1024 did you open an issue on this? |
| 15:47 |
MTDiscord |
<warr1024> I dunno, I really curtailed my issue-opening around the paramat days, and now it doesn't even really seem worth it. |
| 15:47 |
|
Izaya joined #minetest |
| 15:48 |
rubenwardy |
the issue is #6722 |
| 15:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/6722 -- Add more settings to the pause menu. |
| 15:48 |
MTDiscord |
<warr1024> Also, MT doesn't want an issue for each problem, they want an issue that covers each problem. |
| 15:48 |
MTDiscord |
<warr1024> So if my problem is a subset of some bigger issue that's already in there, it'd just get marked dupe anyway. |
| 15:49 |
MTDiscord |
<warr1024> case in point. |
| 15:49 |
erle |
i'd say this is an antipattern actually |
| 15:49 |
MTDiscord |
<warr1024> Yeah, that makes sense to me. |
| 15:49 |
erle |
i think each thing that *can* be independently fixed should be it's own issue |
| 15:49 |
erle |
because otherwise you get noise |
| 15:49 |
erle |
or some mega-issues that never get closed |
| 15:49 |
MTDiscord |
<warr1024> You roll your small issues up into big katamari until they're so big nobody can even take a bite out of them. |
| 15:49 |
|
illwieckz joined #minetest |
| 15:49 |
erle |
hahaha |
| 15:50 |
MTDiscord |
<warr1024> But the alternative is that we'd have hundreds of thousands of issues and nobody would even be able to find their way around the issue tracker. |
| 15:50 |
erle |
uh |
| 15:50 |
|
jaca122 joined #minetest |
| 15:50 |
erle |
mozilla is not afraid of having lots of issues |
| 15:50 |
MTDiscord |
<warr1024> so I'm not sure if this is a "this sucks and we should clearly do something better" kind of situation, so much as a "this sucks and I wish there was something better" |
| 15:50 |
erle |
and sometimes someone comes along and fixes stuff that was reported 18 years ago |
| 15:50 |
MTDiscord |
<warr1024> Yeah. Mozilla. We are definitely not Mozilla. |
| 15:51 |
erle |
GNOME on the other hand tends to close stuff |
| 15:51 |
erle |
and oh well |
| 15:51 |
erle |
they rarely get fixes for old issues lol |
| 15:51 |
erle |
they also have this funny thing where substantially refactoring a component (or rewriting it) results in all bugs for that component to be closed without verification |
| 15:51 |
erle |
with a comment of “open this if it still occurs” |
| 15:51 |
MTDiscord |
<warr1024> If you want to run a Mozilla-esque "every known issue affecting MT" kind of space, you're free to, but I think MTE manages their issues more like a backlog of things that are all actually theoretically supposed to be being worked on. |
| 15:52 |
erle |
and yet stuff i was working on was closed. curious. |
| 15:52 |
MTDiscord |
<warr1024> Hoarding issues is also an antipattern. This is one of the reasons why I separate my "working on" and "hoard" sections of my own issue trackers, even though I do hoard issues in general. |
| 15:52 |
erle |
i mean, if it is a backlog, closing it means “do not do the thing”. at least at my workplace. |
| 15:52 |
erle |
that sounds goodt |
| 15:52 |
erle |
i think hoarding is mostly a thing for feature stuff though |
| 15:53 |
erle |
from my POV, every bug is worth consideration. and worth keeping open if you have someone working on it, but i seem to be in the minority there. |
| 15:53 |
MTDiscord |
<warr1024> I don't understand how you can continue to not understand this after so long. Closing the thing from the MT issue tracker means that the MT core team will not work on it. It's not closed in YOUR issue tracker (whether you have a formal one or just keep it in your head) or else you wouldn't still be talking about it, so clearly it's not stopping YOU from working on it. |
| 15:53 |
erle |
i know |
| 15:54 |
erle |
the thing is mostly about discoverability |
| 15:54 |
erle |
there is nothing worse for “find someone to reproduce this” than closing it |
| 15:54 |
erle |
a friend already queried me on IRC that she'll try on her hardware |
| 15:55 |
erle |
you can see issues that stay open for too long in the mineclone2 issue tracker btw |
| 15:55 |
erle |
so i am well aware of the danger |
| 15:55 |
MTDiscord |
<warr1024> For one thing, issues are still discoverable even if they're closed. For another thing, if you want there to be a more curated list of "issues rejected by core but I still think they're valid" then I'd encourage you to go ahead and just make and share one. If there's value to be found in such a thing, I'm sure somebody will find it. |
| 15:56 |
erle |
i was once thinking about making an issue of “PRs that were nice, but were not adopted for reasons other than not being good enough, e.g. not getting reviews” |
| 15:56 |
erle |
i mean a list |
| 15:56 |
erle |
privately |
| 15:56 |
MTDiscord |
<warr1024> Actually, since MT has a "wontfix" code, which generally implies "this is not just bullshit but it's too trivial to make the cut" it should probably be pretty easy to find all those issues that aren't just outright invalid... 🤔 |
| 15:56 |
erle |
but then i started trying to contribute with reviews for those things and it got nowhere |
| 15:57 |
erle |
because i realized that a review from me is worth nothing |
| 15:57 |
erle |
like it will not improve the chance of it getting merged if no coredev is interested enough |
| 15:58 |
erle |
(which does not mean they are not interested) |
| 15:58 |
MTDiscord |
<warr1024> On some level we have been working toward recognizing that the community is not some kind of cohesive whole where we can all just vote on things in some giant general election, but that there are different cohorts of people with different focuses and needs. As an example, CDB now allows people to create and share lists of packages, so they can curate their own reccomendations instead of just having to throw reviews into one central |
| 15:58 |
MTDiscord |
scoring system. We still have a central system as the default but now there is an alternative... |
| 15:59 |
MTDiscord |
<warr1024> "reviews from non-coredevs are worth nothing" <-- yeah, that's actually probably a real problem. |
| 16:00 |
MTDiscord |
<warr1024> But then, it still pales in comparison to the problem of people getting hung up on what the code looks like and not considering what it does or doesn't actually accomplish. But that's also sort of a "cosmic background problem" that you can almost just discount as part of a universal noise floor; if there's nowhere that doesn't have the problem then you'd get better mileage focusing on other ones you can do something about anyway. |
| 16:00 |
erle |
i think a good example for this is this PR: https://github.com/minetest/minetest/pull/11115 it's a feature, sfan5 and krock and me reviewed it – but no one but sfan5 gave it an approval and wuzzy just gave up. i'm pretty sure i spent at least an hour on evaluating this. |
| 16:02 |
erle |
so the thing is: i am the person who originally added CONTENT_RAIL in 2011, in commit 51d308c666dfd023169b7d5e200fbefb3d315d3b – if my opinion does not matter because i am not a coredev, then why should i care about this PR? |
| 16:03 |
MTDiscord |
<warr1024> I get the sense that the "approval" bar is too high to clear. People are too worried about being the person known for giving the final approval to merge the next sneak-glitch-fix and getting derided and harassed by the community for making what only in hindsight would look like a bad call. |
| 16:04 |
MTDiscord |
<warr1024> I bet we'd get more approvals if approval "voting" was blind and anonymous. Each core dev casts a yea or nay without knowing whether anyone else did, and at the end we only know how many total approvals it got. |
| 16:04 |
erle |
i think maybe, just maybe, there should be another way to be able to give approval. e.g. having a popular game that uses a feature. |
| 16:05 |
erle |
minetest now has 6666 closed PRs and 69 open PRs. hehe |
| 16:05 |
MTDiscord |
<warr1024> Well, if we had a gamedev steering group that could vote on "concept approval" type things for non-refactor issues and such, and if they could cast votes on whether feature PRs were merged or not and core devs would only "veto" a PR if there were a code quality or architecture issue... that would also probably fix the "nothing gets merged" problem. |
| 16:06 |
erle |
yeah but for that you first need people to want to actually listen? |
| 16:06 |
MTDiscord |
<warr1024> We'd still be left with the "exactly how unstable are we okay with things getting" problem, but maybe having a handful of people focused on that while not also trying to juggle bug triage, writing code, and reviewing code and architecture, might help. |
| 16:06 |
erle |
listening can be boring and annoying |
| 16:07 |
|
json joined #minetest |
| 16:08 |
MTDiscord |
<warr1024> But if you've only got the equivalent of like 2 or 3 full time people in aggregate across all the people willing to sink their time into a thing, and people get called away for IRL obligations at random times and you can't dedicate any effort within a particular time window, then exactly how you organize roles around that stuff doesn't help much, and it's very easy to have too much bureaucracy. |
| 16:09 |
json |
If only we had designers... |
| 16:09 |
erle |
Warr1024 i wonder what you think of this discussion actually, like do you think it was the correct thing to disregard the comments of velartrill and me or not: https://github.com/minetest/minetest/pull/12614 |
| 16:09 |
json |
A redesign of the main menu would have been implemented long ago |
| 16:10 |
erle |
i think it was the wrong call (since we both want to use this feature and the creator does not), but there is an API now that kinda works (just not as good as it could have been) |
| 16:10 |
erle |
but i wonder what you think |
| 16:11 |
erle |
and obv i am a bit biased lol |
| 16:11 |
MTDiscord |
<warr1024> Looking briefly at the comments in that PR, about a paragraph in I can already see (1) my eyes are glazing over at how much there is to read, it really needs to be more succinct, and (2) there are already side issues being discussed that should probably be filed separately. |
| 16:12 |
MTDiscord |
<warr1024> I can try to dig further but it's a LOT to digest. |
| 16:12 |
erle |
i think maybe just take the state change thing as an example |
| 16:12 |
erle |
like the bow thing velartrill mentioned |
| 16:13 |
MTDiscord |
<warr1024> it says "merged" but I've never actually used the feature. |
| 16:13 |
erle |
> consider what happens when you have a fully-"charged" bow and then switch away without firing. even with full engine support for on_unwield and texture metadata overrides, there will still be a brief, confusing lag before the bow image resets to normal |
| 16:13 |
erle |
the issue that velartrill had that if this is not baked in from the start, it might be unfixable in practice |
| 16:14 |
erle |
i can see both points here, i.e. it is out of scope but also “there is someone who has thought about this deeply and wants to use this API” |
| 16:14 |
MTDiscord |
<warr1024> I mean we have to balance between having sane, maintainable APIs vs. having crisp client-side prediction. |
| 16:14 |
MTDiscord |
<warr1024> I struggle with MT's highly limited node dig prediction all the time. |
| 16:15 |
MTDiscord |
<warr1024> it would be nice if it were at least a map of wielditem->node instead of just a node name. |
| 16:15 |
rubenwardy |
the API works as requested by many other mods. Improvements can be made in the future. Best to get it in than wait for perfection |
| 16:15 |
rubenwardy |
software dev is iterative, it's not perfect from the start |
| 16:15 |
erle |
yeah but in this case we have a classic case of an implementor who just wants to make stuff better (but not use it) vs. mod coders who are worried they get something bad (which is not too unrealistic, given that nothing lasts as long as a temporary solution) |
| 16:15 |
MTDiscord |
<warr1024> but we could argue all day about how an API can be made richer to more exactly provide client-side control, and we just end up in the SSCSM argument again. Which people are imaginging will solve all sorts of problems but all it really does is START to solve some problems. |
| 16:16 |
erle |
i do not necessarily agree with velartrill btw |
| 16:16 |
erle |
i just think it is a neat example for the tension |
| 16:16 |
erle |
and i wanted to know what your default is for that tension Warr1024 |
| 16:16 |
MTDiscord |
<warr1024> Also, I didn't see any comments being "dismissed" in the thread. I saw rubenwardy for example saying "yeah, this is out of scope". That sounded like a "please open this as a separate issue," not a "fuck off" to me. |
| 16:17 |
erle |
dismissed, as in “marked off-topic” (prob. because there was lots of text that addressed different stuff and it was at least partially out of scope) |
| 16:17 |
MTDiscord |
<warr1024> Maybe we shouldn't talk about "tension" in the same context as talking about a drawn bow because the mental imagery is getting all mixed up 😄 |
| 16:17 |
erle |
oh lol |
| 16:18 |
erle |
i mean tension as in: different people want different things. rubenwardy wants to finish the thing. velartrill wants some client-side prediction for different states of items to make item updates lag-independent. |
| 16:18 |
erle |
have a better word? |
| 16:19 |
MTDiscord |
<warr1024> People also have to understand that if they want their stuff to be taken seriously immediately, they need to come with very well-organized thoughts. It's not just enough to dump all the detail on somebody and expect them to pick out the important bits. Rubenwardy said that software development is an iterative process, but sometimes raising an issue is too. Sometimes it makes sense to come back not with more evidence or richer |
| 16:19 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Amend list of planned breakages 15c3fb7 https://github.com/minetest/minetest/commit/15c3fb7b7ab8dfe55d65dbdd911cef8b11221751 (2023-10-24T16:17:18Z) |
| 16:19 |
MTDiscord |
detail, but with a more succinct presentation. |
| 16:19 |
MTDiscord |
<warr1024> My way of resolving the tension between short term and long term needs is usually to do them both. I do the short term thing in the short term, and then I go back and do the long term thing in the long term. |
| 16:20 |
erle |
yeah but i am pretty sure that rubenwardy does not want to realize the long-term plans of velartrill hehe |
| 16:20 |
erle |
you want both |
| 16:20 |
MTDiscord |
<warr1024> I'd have done the rubenwardy thing of just having a single stateless override and we'd live with some network lag for a while, but at least we'd have the option of seeing SOME state changes, and/or other needs could be met. Then the long term thing goes in the backlog and it works its way up as normal. |
| 16:21 |
MTDiscord |
<warr1024> No, my interpretation of what rubenwardy said sounds a lot like what I would do. Make a separate issue. |
| 16:21 |
erle |
btw this is probably the weirdest code velartrill has written and it slightly freaks me out https://c.hale.su/util/file?name=nkvd.c&ci=tip |
| 16:22 |
MTDiscord |
<warr1024> Doing the short term thing is also not necessarily a promise to do the long term thing, and certainly not within any specific time frame. But I would accept the legitimacy of the longer term need, and I'd just trust that it would work its own way up the ladder. |
| 16:22 |
erle |
yes, but velartrill would have to do that thing! |
| 16:22 |
erle |
here she wanted someone else to do it hehe |
| 16:22 |
erle |
(or so it reads to me) |
| 16:22 |
ROllerozxa |
json: a million designers making new main menu designs will be useless if nobody's gonna think about actually implementing them in formspec |
| 16:22 |
MTDiscord |
<warr1024> Well, all I can say about that is "good luck then" |
| 16:22 |
muurkha |
haha, what were velartrill's long-term plans? |
| 16:23 |
muurkha |
maybe we should set up a third-party GNOME bug tracker |
| 16:24 |
muurkha |
to track bugs in GNOME and close them when they are fixed rather than when the developers get tired of them |
| 16:24 |
erle |
if i look at nkvd.c the long-term plan is a stalinist dictatorship |
| 16:24 |
erle |
muurkha i have a funnier idea |
| 16:25 |
erle |
cute date activity: file CVEs regarding GNOME |
| 16:25 |
erle |
it can't be that hard |
| 16:25 |
muurkha |
erle: a way to handle the texture GC problem would be for clients to refetch textures they had discarded that turned out to still be needed |
| 16:25 |
erle |
an acquaintance just suggested a github thing like “twitch plays” |
| 16:26 |
erle |
make a single repo, merge everything hehe |
| 16:26 |
erle |
no long discussions! |
| 16:26 |
erle |
no reviews! |
| 16:26 |
erle |
muurkha i have no knowledge of that part of the engine and can not possibly comment on it. |
| 16:26 |
MTDiscord |
<warr1024> The way I see it, there are just different philosophies about managing a work backlog. Issues tend to get inserted into the queue at randomish places, usually somewhere in the middle, i.e. after triage they're more important than some, less than others. Some issues near the head of the queue are moving upwards, as issues are getting closed faster than any are cutting in line in front of them. Others are moving backwards as more |
| 16:26 |
MTDiscord |
important issues are added in front of them. Realistically, behind a certain threshold is an issue boneyard where they're never actually going to get any traction. Some teams prefer to just cut this portion off as it serves no purpose as a work planning device. Other teams prefer to keep them around since they appease users (your issue is "already being worked on") or because they add historical or documentational value. They can add cost, |
| 16:26 |
MTDiscord |
unless you've got some kind of process of isolating them, e.g. you mark them as "icebox" so you don't include them in your priority sorting. |
| 16:27 |
MTDiscord |
<warr1024> The idea of a "merge evertying" Minetest "chaos edition" has been suggested before, and I bet it's been tried at least in private a few times. If one of those ever actually got anywhere, it would probably be making a very good case for merging the upstream PRs that constitute it, at least. |
| 16:28 |
erle |
Warr1024 as i said before, i fail to see how “someone is working on it” can be of zero importance – there is always a worse case: no one is working on it. |
| 16:28 |
erle |
and in fact, some things are kept open for very long |
| 16:28 |
erle |
even if no one is working on it |
| 16:29 |
erle |
so as i see it, there is also a tension between – is the issue list (or backlog) descriptive or prescriptive |
| 16:29 |
erle |
i want it to be descriptive, obviously |
| 16:29 |
erle |
i am glad though that minetest has no auto-closing |
| 16:30 |
erle |
i think microsoft has closed suppord for curve 25519 on azure 3 or 4 times |
| 16:30 |
erle |
because the issue is always open long enough for it to be considered stale |
| 16:30 |
|
calcul0n joined #minetest |
| 16:30 |
erle |
and then closed |
| 16:30 |
erle |
and then soemone else does it anew |
| 16:35 |
MTDiscord |
<warr1024> 'i fail to see how “someone is working on it” can be of zero importance' <-- somewhere, right now, somebody could be giving Elon Musk a haircut. They are "working on it" and yet it's of zero importance to me. |
| 16:35 |
MTDiscord |
<warr1024> The problem here is that you're talking about "important" or "not important" as if there's a such thing as a thing "being important". There isn't. There are just people, and what's important to them. |
| 16:36 |
MTDiscord |
<warr1024> You do not get to declare that something is universally important just because it's important to you. |
| 16:36 |
|
v-rob joined #minetest |
| 16:36 |
MTDiscord |
<warr1024> If you're working on it, then yes, it's important to you. If you get far in working on it, then I hope you can eventually make it important to the MT core team, as it would be difficult to get it merged if it remains not. |
| 16:37 |
erle |
i get it |
| 16:37 |
MTDiscord |
<warr1024> The core team is composed of humans and you simply can't separate their perspective from the process, no matter how much you might want to ideally. |
| 16:38 |
MTDiscord |
<warr1024> They just have to make the calls based on the way they understand the situation. |
| 16:38 |
erle |
yes and i realize i have different goals (e.g. keep minetest running on my hardware, make it so that my mods do not render weird) |
| 16:39 |
erle |
but i have seen how this goes in other projects, like openra. after like 2 or 3 years people stop reporting the kind of issue that is ”there is a bug on my older hardware” because the project gets a reputation. |
| 16:39 |
erle |
(the hardware still exists, and openra does not run even on some quite recent hardware that it used to run on because they have a very myopic idea about what targets to support) |
| 16:40 |
erle |
i think i can not resolve it |
| 16:40 |
erle |
the natural point to fork is when minetest drops support for like a decade of hardware ig |
| 16:40 |
MTDiscord |
<warr1024> Haha, if you want to talk about things like reputations or cultural issues in MT, I don't think "refusing to support old hardware" would even make the leaderboard, though... |
| 16:40 |
erle |
whenever that may be |
| 16:40 |
erle |
Warr1024 no, not yet |
| 16:40 |
erle |
in fact, it is famous for running on potato |
| 16:40 |
erle |
those people rarely show up on irc obv |
| 16:40 |
erle |
like kids with some old laptop |
| 16:41 |
erle |
i once encountered some kid on a server that did not seem to have access to a *mouse*. they still managed to play. |
| 16:41 |
MTDiscord |
<warr1024> I consider myself part of the "potato demographic" running MT on a ThinkPad T430s... |
| 16:41 |
erle |
it was extremely weird because in the beginning they stole some items from a chest i had made |
| 16:42 |
erle |
and it turns out they had difficulties controlling the interface |
| 16:42 |
erle |
i always think of this article then |
| 16:42 |
erle |
https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiveness-of-simple-html/ |
| 16:42 |
erle |
> a young woman sits on a hard plastic chair. She is surrounded by canvas-bags containing her worldly possessions. She doesn't look like she is in a great emotional place right now. Clutched in her hands is a games console - a PlayStation Portable. |
| 16:43 |
erle |
> I glance at her console and recognise the screen she's on. She's connected to the complementary WiFi and is browsing the GOV.UK pages on Housing Benefit. She's not slicing fruit; she's arming herself with knowledge. |
| 16:43 |
erle |
> The PSP's web browser is - charitably - pathetic. It is slow, frequently runs out of memory, and can only open 3 tabs at a time. |
| 16:43 |
erle |
etc. |
| 16:44 |
MTDiscord |
<warr1024> tbh I tend to see the "run on weak hardware" goal of MT as important, but from more of an "economic justice" kind of standpoint than like an old people who are comfortable with their machines and don't want to upgrade kind of standpoint, even though I'm in the latter demographic. MT being able to run on cheap android phones, in particular, gets access to gaming and social play experiences to parts of the 3rd world that are very badly |
| 16:44 |
MTDiscord |
underserved by the "everyone can afford a $1500 gaming rig" gamerbros of the WEIRD world. |
| 16:44 |
muurkha |
erle: ZeroMQ works (or worked) like "Twitch plays" |
| 16:44 |
MTDiscord |
<warr1024> Oh, you were going to a similar place with it then, actually... |
| 16:44 |
|
fling joined #minetest |
| 16:44 |
MTDiscord |
<warr1024> ...but I think running on a PSP might be a bit too high of a hurdle :-) |
| 16:44 |
muurkha |
they would merge any pull request as fast as they could, then fix whatever bugs it introduced |
| 16:46 |
|
dibesfer joined #minetest |
| 16:47 |
muurkha |
erle: I have played Minetest without a mouse. did have a touchpad, but it only worked when no keys were held down |
| 16:47 |
erle |
muurkha funny. do they have tests? |
| 16:48 |
muurkha |
PSPs are a lot more expensive than Android tablets with gigabytes of RAM and GPUs and manycore CPUs |
| 16:48 |
erle |
muurkha old devices are often gifts |
| 16:48 |
muurkha |
yeah, they do have a lot of tests |
| 16:48 |
erle |
in my case, i actualy have newer devices, but they are reform 1 and reform 2, which i GUESS are similarly disadvantaged because they are not gaming rigs |
| 16:49 |
muurkha |
maybe, not necessarily |
| 16:49 |
muurkha |
last night I was rereading this article from 01994 |
| 16:49 |
MTDiscord |
<warr1024> The problem with expecting economically disadvantaged people to be using old hardware is that it makes assumptions about how material resources flow through society that would have made "trickle down" actually work if they were true :-/ A lot of those old things just end up in landfills, attics, and estate auctions, while people who can't afford fancy new things end up needing to just buy really basic new things instead. |
| 16:49 |
muurkha |
http://www.compression.ru/arctest/descript/fractal.htm "Fractal Image Compression: What’s it all About?" |
| 16:50 |
muurkha |
it mentioned that compressing an image took 100 hours on a Masscomp dual-processor workstation |
| 16:51 |
muurkha |
it turns out that those used 16.7MHz 68020s running at about 2.7 Dhrystone MIPS |
| 16:51 |
muurkha |
so (each of the four CPU cores of) a Raspberry Pi 3 is about 1300x as fast |
| 16:52 |
MTDiscord |
<warr1024> 1.15 minutes then (not accounting for instruction set differences) |
| 16:52 |
erle |
Warr1024 well among the people i know it's more like “here have my old laptop, i got a new one” and then you have people with a 2008 thinkpad or a 2012 macbook which … works perfectly fine with i3 or xfce or so |
| 16:52 |
muurkha |
right |
| 16:53 |
muurkha |
warr1024: "trickle down" economics were about the idea that tax breaks for (presumably wealthy) investors would create more high-paying jobs for the proletariat, nothing about the market for used cellphones |
| 16:54 |
erle |
pinata economics are more plausible anyway |
| 16:54 |
muurkha |
what's that? |
| 16:54 |
erle |
hit whoever has more money with a stick until the wealth trickles down |
| 16:54 |
erle |
:P |
| 16:54 |
MTDiscord |
<warr1024> "trickle down" sort of assumed that those markets would just naturally exist, since that's sort of what markets are supposed to be about: economic exchange just sort of naturally happening. |
| 16:54 |
muurkha |
(Dhrystone is not the best benchmark for this because presumably they were using the Masscomp's floating point hardware) |
| 16:55 |
muurkha |
it wasn't really about markets at all, it was about employment |
| 16:55 |
|
Talkless joined #minetest |
| 16:55 |
MTDiscord |
<warr1024> Your "pinata" reference (damn USA keyboard) kind of reminds me of a discussion recently about "extending an olive branch" and makes me think about the double meaning there... |
| 16:56 |
muurkha |
"trickle down" economics would have made the same amount of sense if people were assigned to jobs by commissars based on their ASVAB scores, rather than competing in a job market |
| 16:56 |
erle |
olive green branch of the armed forces? |
| 16:56 |
MTDiscord |
<warr1024> haha, well, just more along the lines of whatever tree you get a branch from, you could still ostensibly beat somebody to death with it if it's large enough. |
| 16:57 |
muurkha |
haha |
| 17:01 |
|
mrkubax10 joined #minetest |
| 17:08 |
|
Talkless joined #minetest |
| 17:13 |
erle |
ROllerozxa Warr1024 i think the single thing where i notice my laptop is slow is incremental minetest builds. but that's on the atrocious state of the build system really |
| 17:14 |
erle |
and me switching between branches often (which invalidates pretty much everything) |
| 17:17 |
MTDiscord |
<warr1024> probably would make sense to make clones of your repo specifically for build purposes at that point. |
| 17:18 |
MTDiscord |
<warr1024> "multiple clone on one machine" workflows are ... possible, though of course they can take a bit of work to keep organized. |
| 17:18 |
erle |
well, i have actually written a build system that can fix this |
| 17:19 |
erle |
the thing is, i probably just need to update those scripts |
| 17:19 |
erle |
minetest did not want it |
| 17:19 |
erle |
let me look up what the speed difference was |
| 17:22 |
MTDiscord |
<warr1024> I basically just wrote a script that automates around the existing build system, and then I go fix myself a sandwich or something. I imagine that if there were a nicer build system, it might make me more interested in attempting engine work, though... |
| 17:22 |
erle |
well, redo is basically shell scripts + 4 primitives that you all need to specify dependencies (most build systems only have 2 of those, which means they can not specify specific ones) |
| 17:23 |
erle |
i looked at the branch again and the tension was between “use precompiled headers for fast builds” and “get really fast rebuilds” hehe |
| 17:23 |
erle |
if you are interested in evaluating how such stuff looks https://github.com/minetest/minetest/pull/12592 |
| 17:24 |
erle |
like, just check out the build rules and see how it fits your workflow (or not) |
| 17:24 |
erle |
i have since actually improved redo a tiny bit |
| 17:24 |
erle |
so those could be a bit smaller |
| 17:24 |
MTDiscord |
<warr1024> Oh, yeah, the "incremental build speed vs full rebuild speed" trade-off ... how to weight the balance depends a ton on workflow, like, how much you lean on CI... |
| 17:25 |
erle |
well in this case i pretty much can evaluate it |
| 17:25 |
erle |
because i have actual access to the full dependency graph |
| 17:25 |
erle |
which has non-existence dependencies also |
| 17:26 |
erle |
cmake pretty much can not give you this answer to the question “what affects the building of src/ban.o” https://user-images.githubusercontent.com/60905/180919882-1f227ad9-fbe9-46b2-98f7-2fd6685d19cc.png |
| 17:27 |
muurkha |
erle: what did you improve in redo? |
| 17:27 |
erle |
muurkha i introduced a wrapper redo-gcc which invokes redo-ifchange on gcc dependencies automatically |
| 17:28 |
erle |
the -MD -MF thing |
| 17:28 |
erle |
this is something you basically always might want |
| 17:28 |
erle |
but i am not sure yet if i did it correctly |
| 17:28 |
erle |
Warr1024 there is also a more interesting tension: how much dependency checking do you do in the case that nothing changed vs that something chanegd? |
| 17:28 |
muurkha |
erle: aha, nice |
| 17:28 |
erle |
most build systems i have seen actually benchmark well in the case that *nothing* changed |
| 17:29 |
erle |
ninja, for example, is really fast in telling you nothing changed |
| 17:29 |
muurkha |
erle: did you see my link to parsing/pattern-matching stuff above? |
| 17:29 |
erle |
muurkha yes but haven't checked it out yet (tab is open though) |
| 17:29 |
muurkha |
erle: it's a bare git repo, you'll have to clone it |
| 17:29 |
erle |
so the interesting thing is that the ninja tradeoff seems to never work out for me in practice. ninja spends *less* time on dependency checks but then has false positives and building those takes longer than actually checking dependencies. |
| 17:30 |
erle |
so i wonder actually in which cases this might be a good tradeoff |
| 17:30 |
erle |
because it seems stupid, but surely there was probably a reason? |
| 17:30 |
erle |
are there common cases in which a dependency check takes *longer* than rebuilding? |
| 17:30 |
erle |
bc the only case i ever encountered was making a 16GB sparse sd card image |
| 17:30 |
erle |
hashing that is taking much longer than calling truncate(1) |
| 17:31 |
erle |
muurkha http://news.dieweltistgarnichtso.net/bin/redo-gcc |
| 17:31 |
muurkha |
I have definitely had cases, especially with recursive GNU make, where a dependency check took longer than rebuilding |
| 17:32 |
erle |
yeah but GNU make is stupid and doing it recursively is probably a think that makes people think recursive build systems are super stupid |
| 17:32 |
erle |
a think |
| 17:32 |
erle |
a thing |
| 17:32 |
muurkha |
(that is, than running an incremental recompile) |
| 17:32 |
erle |
damn |
| 17:32 |
erle |
so what was it? |
| 17:32 |
erle |
many deps? |
| 17:32 |
MTDiscord |
<warr1024> erle: I see your tension and raise you one: how do you balance between the costs and benefits of doing dependency checking itself? Sufficiently complex dependency management systems can end up spending more time trying to figure out what needs to actually be invalidated than the cost of just rebuilding everything 😆 |
| 17:33 |
erle |
Warr1024 i am trying to track everything and so far the sd card thing is the only one where dependency checking was bad. |
| 17:33 |
erle |
because i have this tooling for the dependency graph (redo-dot) it is easy to figure out though |
| 17:33 |
muurkha |
and I think that most build systems will get to that state with a large enough rebuild and sufficiently light optimization |
| 17:34 |
erle |
i do not track dependencies automatically |
| 17:34 |
MTDiscord |
<warr1024> That's a stroke of luck; I figured that the whole thing was a nasty mess everywhere ... 10+ years can accumulate a lot of baggage. |
| 17:34 |
muurkha |
even if it doesn't happen as soon as it typically does with GNU make |
| 17:34 |
erle |
muurkha there exist a lot of optimization possibilities though that seem okay, but are invalid (i.e. they result in an incremental build not matching a full rebuild) |
| 17:35 |
muurkha |
yeah |
| 17:35 |
muurkha |
it's very difficult to guarantee an incremental build will match a full rebuild byte for byte if you're using an incremental linker |
| 17:36 |
erle |
byte for byte equivalence is not even what i am going |
| 17:36 |
erle |
i think bigger, semantic equivalence hehe |
| 17:36 |
muurkha |
but without an incremental linker, it's common for relinking to be the vast majority of your build time |
| 17:36 |
MTDiscord |
<warr1024> byte for byte makes it much easier to verify equivalence but in most cases it's probably overkill... |
| 17:36 |
muurkha |
semantic equivalence is harder to verify |
| 17:37 |
muurkha |
undecidable of course in the general case |
| 17:37 |
erle |
which is why my redo implementation defaults to byte-equivalence |
| 17:37 |
erle |
but you can override it |
| 17:37 |
erle |
using redo-stamp |
| 17:37 |
muurkha |
so incremental linkers are not as popular now as they were 25 years ago |
| 17:37 |
erle |
which basically means “do not actually rebuild this out of date target and consider it up to date retroactively if the input given to redo-stamp on standard input is the same as the input given the last time someone attempted to build this taregt” |
| 17:38 |
erle |
which is a bit weird |
| 17:38 |
erle |
but very useful |
| 17:38 |
erle |
and there are a few things you can not actually do if you don't have such a primitive that can actually at build-time decide that a target that was considered out of date is actually up-to-date |
| 17:38 |
erle |
(and propagates that decision) |
| 17:38 |
muurkha |
right |
| 17:39 |
erle |
most importantly, the DAG toposort thing is incapable of doing this, since you can't do anything with that information that saves you build time |
| 17:39 |
erle |
but IMO any recursive build system needs this to address some scenarios |
| 17:39 |
muurkha |
it's true that it can't |
| 17:40 |
erle |
well you can use it in the next build, but then you are not saving time |
| 17:40 |
muurkha |
have you looked at Self-Adjusting Computation? |
| 17:40 |
erle |
(because it might be invalidated again unless you build right again) |
| 17:41 |
erle |
you mean excel? :D |
| 17:41 |
erle |
(from my POV excel is a build system that does lots of things right) |
| 17:41 |
muurkha |
no, Umut Acar's work |
| 17:41 |
erle |
ah https://www.umut-acar.org/self-adjusting-computation |
| 17:41 |
muurkha |
yes |
| 17:41 |
erle |
i have casually looked at it but surely not understand much (because i have not dived into it) |
| 17:42 |
erle |
muurkha do you compile minetest btw? |
| 17:42 |
muurkha |
I don't fully understand his algorithms |
| 17:42 |
muurkha |
I compiled Minetest once, last year |
| 17:43 |
erle |
most time of compiling minetest i have spent is actually waiting for some object file to be changed |
| 17:43 |
muurkha |
it was a lot of hassle because the trunk version of IrrlichtMT was incompatible with the tagged release of Minetest I was trying to compile |
| 17:43 |
muurkha |
so I had to search back through IrrlichtMT history until I found a version that would allow the compile to work |
| 17:44 |
erle |
we have git submodules at home hehe |
| 17:44 |
muurkha |
yes, git submodules would probably have solved that problem |
| 17:44 |
erle |
git submodules at home: misc/irrlichtmt_tag.txt |
| 17:45 |
muurkha |
unless someone forgot to commit their submodule hash update |
| 17:45 |
|
v-rob joined #minetest |
| 17:45 |
erle |
Warr1024 btw what do you think of my post-checkout hook here? https://github.com/minetest/minetest/issues/11749 |
| 17:45 |
muurkha |
this is the kind of thing that makes me favor monorepos |
| 17:45 |
erle |
well it could have been a subtree |
| 17:45 |
erle |
v-rob! can you tell me what exactly changed to make the keybinding so weird and if there is a quick fix so i can input a “+” sign again? |
| 17:46 |
erle |
i remember us chatting about that part of the engine some time back |
| 17:46 |
erle |
and me trying out keys on 3 different computers and they were all differently weird |
| 17:46 |
v-rob |
Oh no, keycodes |
| 17:46 |
|
appguru joined #minetest |
| 17:46 |
erle |
v-rob but like look at this funny mess https://github.com/minetest/minetest/issues/13904 |
| 17:46 |
erle |
i have no idea what happens there |
| 17:47 |
erle |
like with SDL, a lot of keys are detected as ”left button” |
| 17:47 |
erle |
and without, num lock is still tab and so on |
| 17:47 |
erle |
maybe you can tell me how to debug? |
| 17:52 |
v-rob |
I don't see anything in keycode.cpp that has changed that might change the behavior of numpad "+" |
| 17:53 |
v-rob |
It's very possibly something has changed in IrrlichtMt |
| 17:53 |
erle |
it is not numpad + |
| 17:53 |
erle |
it is iso shift level 3 + b, which used to input + on neo2 keyboard layout |
| 17:53 |
erle |
basically minetest used to support binding key combinations implicitly if they resulted in a character output |
| 17:54 |
erle |
and i don't know if it even can be fixed |
| 17:54 |
erle |
the other thing (misdetection/mislabeling) is weirder though |
| 17:54 |
erle |
i don't even know how several different keys can end up be detected as one |
| 17:54 |
erle |
maybe ”left button” is the fallback/default key? |
| 17:54 |
erle |
i thought you might know |
| 17:56 |
v-rob |
I don't know off the top of my head. I do know that the SDL keycodes are getting transformed into Irrlicht keycodes, and that transition may not be perfect. |
| 17:56 |
v-rob |
Ideally, we'd be using SDL scancodes for keyboard layout independence, but I don't think we're doing that in the SDL code. |
| 17:56 |
erle |
well keyboard layout independence might give you the wrong label in the interface in the end? |
| 17:57 |
erle |
as it can not tell |
| 17:57 |
erle |
or not? |
| 17:58 |
|
qqq joined #minetest |
| 18:00 |
v-rob |
Scancodes will give you the "wrong" labels for all non-QWERTY keyboards. The point of them is to keep keyboard positions the same, not keyboard labels. So, if I bind to the WASD scancodes on a QWERTY keyboard, they have the same position on a DVORAK keyboard, i.e. the ,AOE keys will be bound. |
| 18:01 |
muurkha |
erle: if you run `sh path/to/redo-gcc` instead of `path/to/redo-gcc` will sh ignore the -eu in the shebang line? |
| 18:01 |
v-rob |
This makes labelling problematic, but it removes all worry about the default keys working differently for different keyboard layouts. Moreover, keys like ß don't have any special rules--they're just a scancode like any other, unlike keycodes where they might do any number of wacky things. |
| 18:02 |
muurkha |
v-rob: aren't scancodes for different keyboard types basically random and arbitrary? |
| 18:02 |
erle |
muurkha probably and this is why i should start writing “set -e” and “set -u” |
| 18:03 |
erle |
muurkha like if you have a test.sh with #!/bin/sh -eu und false;true then running it with sh(1) will make it return true |
| 18:04 |
erle |
und → and |
| 18:04 |
erle |
muurkha i3 does the scancode thing and so far it does it well |
| 18:05 |
v-rob |
Not really. If you remove the labels from your keyboard, keycodes are the random and arbitrary ones. Scancodes will always give you the same code for the same position on the keyboard. Q in QWERTY and A in AZERTY are the same scancode, Q, but different keycodes, Q and A. |
| 18:05 |
v-rob |
Scancodes are simply the correct choice for a game where the position of the WASD keys is what matters, not what characters they have on them |
| 18:06 |
erle |
it does not fix the accidental removal of key combinations, but yeah it is the right way |
| 18:06 |
erle |
and the labeling being wrong is *much* less bad than the detection being wrong |
| 18:07 |
MTDiscord |
<grorp> You can get layout-dependent / correct labels for scancodes using SDL, I think |
| 18:07 |
v-rob |
Keycodes, on the other hand, are the correct choice for keyboard shortcuts, e.g. Ctrl-C. Keycodes are intrinsically less reliable, but hopefully no one ever tries to bind Ctrl-ß in the first place. As long as you stick to very well-known keys, keycodes are workable. |
| 18:07 |
v-rob |
Yes, SDL has scancodes. One of the reasons I want it so much. |
| 18:08 |
erle |
v-rob well ß is the key that on QWERTY has the symbols [( on it |
| 18:08 |
erle |
at least on dutch QWERTY which i use with my german neo2 layout hehe |
| 18:08 |
muurkha |
v-rob: I mean, are SDL scancodes consistent between, like, a USB keyboard and a PS/2 keyboard? (Probably not a lot of people running Minetest on a Sun or SGI these days) |
| 18:08 |
v-rob |
They should be. That's their entire purpose. |
| 18:09 |
muurkha |
I see, thanks! |
| 18:09 |
v-rob |
If they aren't, that's a bug in SDL, ideally. |
| 18:09 |
erle |
muurkha usb keyboards just send PS2 scancodes i think |
| 18:09 |
erle |
it's all a big scam! |
| 18:09 |
muurkha |
erle: no, they have their own mapping |
| 18:09 |
erle |
damn |
| 18:09 |
muurkha |
it's in the HID standard |
| 18:09 |
muurkha |
I think Linux /dev/input does the translation for you? |
| 18:09 |
erle |
oh found the translation table |
| 18:09 |
erle |
thanks! |
| 18:09 |
erle |
https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf |
| 18:10 |
muurkha |
are SDL's consistent with USB's? |
| 18:10 |
v-rob |
Anyhow, if we fully transition to SDL, I want to use scancodes and make the pile of hot garbage that is keycode.cpp disappear. |
| 18:10 |
erle |
what is “Europe 1 (Note 2)”? |
| 18:10 |
muurkha |
piles of hot garbage do eventually disappear |
| 18:11 |
muurkha |
as long as you keep them moist |
| 18:11 |
erle |
well right now i can't bind the + key combo to anything, that will not be magically fixed with SDL ever right? like, it needs additional work? |
| 18:11 |
v-rob |
SDL's scancode enum uses QWERTY labels, like SDL_SCANCODE_Q, but I don't know if the actual numbers of the enum match up to any standard. |
| 18:12 |
erle |
i have a shitty dutch keyboard and a brand new REFORM keyboard and a bunch of old laptops to find out if you need help |
| 18:12 |
v-rob |
As it currently stands, SDL probably won't fix the + key not working on your keyboard since it uses keycodes. Scancodes (hopefully) would fix it. |
| 18:12 |
MTDiscord |
<grorp> Currently, we map SDL keycodes to Irrlicht keycodes. It would be trivial to change the mapping to be between SDL scancodes and Irrlicht keycodes instead. Would that make sense even before a full migration to SDL? |
| 18:13 |
v-rob |
No, keycodes need to stay for now. Otherwise Ctrl-C in formspecs will be a scancode as well. |
| 18:13 |
erle |
well as you can see, right now it is partially broken |
| 18:13 |
v-rob |
Bascially, keycodes for formspecs, scancodes for in-game. |
| 18:14 |
|
dibesfer joined #minetest |
| 18:14 |
erle |
i can in fact still input a + in chat just fine |
| 18:14 |
erle |
or in a formspec |
| 18:14 |
erle |
just not bind it to anything |
| 18:14 |
erle |
and nothing is garbled input-wise |
| 18:14 |
v-rob |
erle: I have to leave for now, but maybe I'll whip up a quick SDL program that displays keycode and scancode symbols so you can test it out on your keyboard and see if it behaves consistently. |
| 18:15 |
erle |
v-rob thanks that would be nice |
| 18:15 |
muurkha |
awesome! |
| 18:15 |
erle |
i have at least 3 keyboards in arms reach i can test on |
| 18:15 |
erle |
(T60, reform external, dutch qwerty) |
| 18:23 |
|
sys4 joined #minetest |
| 18:37 |
|
dibesfer joined #minetest |
| 19:02 |
|
s20 joined #minetest |
| 19:35 |
|
v-rob joined #minetest |
| 19:35 |
v-rob |
erle: Still around? SDL program can be found here: https://gist.github.com/v-rob/4ef28c7ae9f45fcf697dbc0f3a64ee5c |
| 19:36 |
v-rob |
Compilation instructions included. To use, just press keys on the blank window that opens and look at what is printed in the console. |
| 19:39 |
erle |
i am there yes |
| 19:39 |
erle |
but currently trying to understand how cursed item rendering is |
| 19:45 |
|
Sobinec joined #minetest |
| 19:46 |
erle |
v-rob now in return, might you take a look at this? https://github.com/minetest/minetest/issues/13920#issuecomment-1777919525 |
| 19:51 |
erle |
seems whatever it detects as keycode is wrong and whatever it detects as scancode is right … for some keys lol. for others it is exactly the opposite. amazing. |
| 19:51 |
erle |
oh wow |
| 19:52 |
muurkha |
erle: you might enjoy this hack I just wrote: http://canonical.org/~kragen/sw/dev3/wing.pl |
| 19:52 |
erle |
this exists: keycode=Right Alt /scancode=CapsLock |
| 19:53 |
erle |
this also exists: keycode= /scancode=Right Alt |
| 19:53 |
erle |
caps lock is right alt and right alt is nothing |
| 19:53 |
erle |
also num lock IS set to an actual tab key on my layout LOL |
| 19:53 |
erle |
how |
| 19:55 |
erle |
muurkha i took a look at it and i am not executing that |
| 19:57 |
muurkha |
haha, you can see that the most malicious thing it does is get its pid |
| 19:57 |
muurkha |
no eval, no escape sequences, no filesystem access |
| 19:57 |
muurkha |
but if you don't speak Perl I don't blame you, I wouldn't either :) |
| 19:58 |
erle |
no, i do not |
| 20:01 |
muurkha |
GPT-4 offers an explanation and more readable version of the code which I think is subtly broken in a couple of different ways: https://bin.gy/wandialong |
| 20:02 |
muurkha |
the explanation is correct, though |
| 20:49 |
|
gxt joined #minetest |
| 20:54 |
|
sparky4 joined #minetest |
| 22:32 |
|
panwolfram joined #minetest |
| 22:37 |
|
Guest39 joined #minetest |
| 23:09 |
|
Noisytoot joined #minetest |
| 23:13 |
|
Guest39 joined #minetest |
| 23:34 |
|
amfl2 joined #minetest |
| 23:35 |
|
Noisytoot joined #minetest |
