| Time |
Nick |
Message |
| 00:22 |
|
cryne7973 joined #luanti |
| 01:11 |
|
qqe joined #luanti |
| 01:51 |
osin_ |
hey, guys, is there buildbattle minigame somewhere? And does anyone play it? |
| 02:05 |
|
Eragon joined #luanti |
| 02:13 |
[MatrxMT] |
<Blockhead256> closest I can think of is quikbuild on A.E.S https://forum.luanti.org/viewtopic.php?t=26142 |
| 02:33 |
|
SFENCE joined #luanti |
| 02:46 |
|
sfence_ joined #luanti |
| 02:55 |
|
SFENCE joined #luanti |
| 04:00 |
|
MTDiscord joined #luanti |
| 05:53 |
|
SFENCE joined #luanti |
| 06:14 |
|
SFENCE joined #luanti |
| 06:33 |
|
FeXoR joined #luanti |
| 08:22 |
|
Warr1024 joined #luanti |
| 08:47 |
|
Warr1024 joined #luanti |
| 09:19 |
[MatrxMT] |
<twrightsman> Hi all, is there a list of officially supported architectures? Based on GitHub actions this seems to be only amd64 and arm64. I can't upgrade Luanti to 5.14 in Debian until I either drop i386 or #16552 is fixed. If you don't really support i386 then I understand and that makes a strong case for dropping that architecture in Debian's Luanti build. |
| 09:19 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/16552 -- Matrix rotation unit test failing on i386 |
| 09:21 |
sfan5 |
we ship builds for 32-bit windows and 32-bit ARM (on Android) |
| 09:22 |
sfan5 |
the failing unit test is probably an oversight but not a reason to drop i386 |
| 09:29 |
MinetestBot |
[git] corpserot -> luanti-org/luanti: Correct info about ObjectRef:set_attach() bones `""` default value f1c0f29 https://github.com/luanti-org/luanti/commit/f1c0f292fa63d7de645cabecf4ab3872a55cd499 (2025-10-26T09:28:30Z) |
| 09:29 |
MinetestBot |
[git] sfan5 -> luanti-org/luanti: Guard new object from being added at shutdown (#16610) 4f8a847 https://github.com/luanti-org/luanti/commit/4f8a847085f909813b1c11b009ebe8c923f8bd63 (2025-10-26T09:28:41Z) |
| 09:31 |
[MatrxMT] |
<twrightsman> sfan5: Got it, thank you for clarifying; then I'll be more patient, and if I find time to look into the issue I will send a patch |
| 09:31 |
sfan5 |
can't you skip this unit test for debian? |
| 09:31 |
sfan5 |
I don't expect us to prioritize looking into this |
| 09:31 |
pgimeno_ |
sounds like it could be the same cause as #16365 |
| 09:31 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/16365 -- Unittest `getRotationRadians` in `test_irr_matrix4.h` is flakey |
| 09:32 |
[MatrxMT] |
<twrightsman> I could, but would prefer not to make it a habit. I already don't like that we skip the Lua destructor test, though this one seems more justifiable to skip |
| 09:32 |
[MatrxMT] |
<twrightsman> But yeah I absolutely don't expect you to prioritize this for Debian's sake, no worries |
| 09:32 |
pgimeno_ |
I'll take a look |
| 09:33 |
sfan5 |
I would rather have 5.14 in debian and risk some math code bug popping up in production than wait this out |
| 09:34 |
[MatrxMT] |
<twrightsman> Thanks pgimeno, and that seems reasonable to me sfan5; then I will patch this test out and revert if a fix arrives later |
| 09:41 |
pgimeno_ |
Okay, definitely the same issue. I'll work on a patch, but I can assure you that the problem is in the test itself, not in the math code. It fails to account for gimbal lock, where a loss of precision is inevitable. |
| 09:42 |
sfan5 |
thanks |
| 09:43 |
|
YuGiOhJCJ joined #luanti |
| 09:47 |
[MatrxMT] |
<twrightsman> Ok much appreciated for checking |
| 09:50 |
sfan5 |
@twrightsman FWIW since debian has officially reduced the support for i386 I guess dropping it from the package also wouldn't be too bad |
| 09:50 |
sfan5 |
🤷 |
| 09:52 |
|
goat_ joined #luanti |
| 09:53 |
[MatrxMT] |
<twrightsman> True; I will summarize this discussion to the Debian Games team and see what they say, I'm still newer to Debian so there may be some details I'm missing about what "reduced support" means in practice. |
| 09:55 |
repetitivestrain |
the throttling controlled by full_block_send_enable_min_time_from_building is liable to produce very extreme phenomena |
| 09:56 |
repetitivestrain |
https://ibb.co/60jMwWfS |
| 09:56 |
sfan5 |
yeah it's kinda stupid |
| 09:57 |
sfan5 |
at the very least it should only apply to the block that is being built in |
| 09:58 |
repetitivestrain |
has it been demonstrated in practice to address a real problem |
| 09:59 |
sfan5 |
nobody knows |
| 09:59 |
repetitivestrain |
i'll set it to zero and ack |
| 10:05 |
sfan5 |
if you have access to a time machine here's the time you need to go back to: Nov 27, 2010 |
| 10:05 |
sfan5 |
https://github.com/luanti-org/luanti/commit/e8fd5eb8eebbf12b0561d385ef8bc245d87e9ea6 |
| 10:06 |
|
mrkubax10 joined #luanti |
| 10:15 |
sfan5 |
i can only guess that the idea is to avoid re-sending the current block constantly if the player builds. due to node placement prediction the server currently always re-sends the block. |
| 10:16 |
pgimeno |
@twrightsman The test is wrong anyway and could fail under certain circumstances even in a different architecture, so IMO it needs fixed. Are you going to stay around? I don't think anybody else here will be able to test the fix in a 386 machine. |
| 10:18 |
[MatrxMT] |
<twrightsman> pgimeno: Yes, this room is in my Matrix list so I get notified when you ping me |
| 10:18 |
pgimeno |
good, thank you |
| 10:20 |
sfan5 |
repetitivestrain: I just discovered that close blocks are always sent so it literally doesn't do what it was intended to |
| 10:20 |
sfan5 |
zero positive effect |
| 10:21 |
repetitivestrain |
i was under the impression that it was meant to reduce bandwith consumption from the sending of blocks that are distant from the player's edits |
| 10:21 |
repetitivestrain |
so that updates to nearer blocks might arrive sooner |
| 10:25 |
sfan5 |
closer blocks are already always preferred to be sent first: if a closer one is modified the scan loop restarts to send that first |
| 10:26 |
repetitivestrain |
ah, i see your point |
| 10:26 |
sfan5 |
(maybe that wasn't the case when that was added) |
| 10:38 |
|
jaca122 joined #luanti |
| 10:43 |
|
qqe joined #luanti |
| 11:00 |
|
jstein joined #luanti |
| 11:04 |
sfan5 |
code comments suggest that the "send near blocks anway" and "don't send during building" code intentionally exists side-by-side |
| 11:05 |
sfan5 |
then i can only guess that the idea was something like "the player is busy building and isn't looking anyway, so no need to update the world" |
| 11:05 |
sfan5 |
which is a bit weird |
| 11:05 |
sfan5 |
repetitivestrain: how long does the state in your screenshot persist? |
| 11:05 |
repetitivestrain |
two seconds, it is ameliorated immediately after the timeout elapses |
| 11:06 |
sfan5 |
aha that's not so bad |
| 11:06 |
repetitivestrain |
yes, but mind you, i'm physically only ten kilometers from the server |
| 11:07 |
repetitivestrain |
with plenty of bandwidth to go between us |
| 11:07 |
repetitivestrain |
(the RTT in the debug menu is not correct) |
| 11:54 |
sfan5 |
oh the description of the setting actually says "To reduce lag, block transfers are slowed down when a player is building something" |
| 11:54 |
sfan5 |
however that's even more weird |
| 11:54 |
sfan5 |
if there's a performance problem, it should be fixed on the client |
| 12:11 |
|
TeXMaster joined #luanti |
| 12:22 |
|
cx384 joined #luanti |
| 12:31 |
|
mrkubax10 joined #luanti |
| 12:53 |
pgimeno |
@twrightsman Could you test this patch? http://www.formauri.es/personal/pgimeno/pastes/fix-tait-bryan-angles-i386.patch |
| 13:02 |
|
qqe joined #luanti |
| 13:11 |
|
PoochInquisitor joined #luanti |
| 13:16 |
|
lemonzest joined #luanti |
| 13:20 |
|
Talkless joined #luanti |
| 13:26 |
|
mrkubax10 joined #luanti |
| 13:31 |
|
erle joined #luanti |
| 13:38 |
[MatrxMT] |
<twrightsman> pgimeno: Thank you! Yes, will report back |
| 14:07 |
[MatrxMT] |
<twrightsman> pgimeno: I tested locally on amd64 and I think a different test is now failing? https://paste.debian.net/1402816/ |
| 14:07 |
[MatrxMT] |
<twrightsman> I started a full build with i386 here: https://salsa.debian.org/twrightsman/luanti/-/pipelines/963379 |
| 14:08 |
[MatrxMT] |
<twrightsman> The randomness in these tests probably makes them a bit flaky I suppose? Perhaps if I can set a seed that could help with flakiness but not catching bugs |
| 14:10 |
pgimeno |
perhaps gimbal_lock_threshold of 1e-3 was too optimistic |
| 14:10 |
pgimeno |
could you change it to 1e-2 and retest? |
| 14:10 |
[MatrxMT] |
<twrightsman> Sure |
| 14:45 |
[MatrxMT] |
<twrightsman> Passed this time, but the old threshold passed on amd64 on the GitLab (Salsa) CI, i386 failed; running the 1e-2 threshold in this pipeline: https://salsa.debian.org/twrightsman/luanti/-/pipelines/963389 |
| 15:08 |
erle |
twrightsman did you see my suggestion elsewhere to mark the package for luanti 5.11 and above as conflicting with some GPU driver packages for GPUs where there was a huge performance drop or that can't run it anymore? |
| 15:08 |
|
silverwolf73827 joined #luanti |
| 15:10 |
sfan5 |
I don't think debian maintainers are in the position to do performance testing and make decision for their users on whether the performance is "good enough" |
| 15:14 |
erle |
no, but i can tell you about at least two drivers where it used to run fine and now it does not |
| 15:14 |
sfan5 |
what a terrible loss |
| 15:14 |
erle |
and i would be surprised if any system that used xserver-xorg-video-intel or the etnaviv driver *ever* got better performance |
| 15:16 |
[MatrxMT] |
<twrightsman> To my knowledge, Debian does not use "Conflicts" markers on hardware drivers to signal hardware support; but if you feel strongly enough you can try emailing the Games Team mailing list, they would know better about those sorts of details. |
| 15:16 |
[MatrxMT] |
<twrightsman> Definitely not for performance regressions |
| 15:16 |
erle |
yes, i know your stance. i *did* notice that you removed support for my hardware in particular exactly one year after i was banned from the bugtracker after working on fixing regressions affecting older/weaker GPUs. what a crazy random coincidence! but think about it another way: if distributions could keep people on older/weaker hardware on luanti 5.10 you won't get bug reports you are going to close anyway. |
| 15:17 |
sfan5 |
people actually tend to report bugs upstream anyway even if they are on an older version provided by a distro, so this is exactly less than helpful. |
| 15:18 |
erle |
i see |
| 15:18 |
erle |
i guess i only considered “my frame rate is unplayable” bug reports then |
| 15:18 |
sfan5 |
idk if you maintain any foss packages but you usually learn this lesson early |
| 15:20 |
[MatrxMT] |
<twrightsman> If it makes you feel any better (sfan5), Debian volunteers are generally aware (and sad) about the pain they can cause on upstream bug trackers. If possible, I'd add a message to Luanti's main menu on Debian to tell people to submit bugs to Debian first, but that wouldn't stop everyone of course |
| 15:20 |
erle |
twrightsman i see that conflicts is wrong then, so maybe a pre-install check could make sense though? there exists a bunch of hardware that simply won't work for gaming purposes with luanti 5.11. oldest device i have is from 2006, newest from 2021. i think i will try to make my case to the mailing list then. |
| 15:20 |
erle |
yes, debian is very nice and behaved for a distribution |
| 15:21 |
sfan5 |
@twrightsman it's not that much so no need to invest any time into that, it's fine. |
| 15:21 |
erle |
meanwhile, e.g. submitting bugs to arch about wrong packaging, wrong dependencies, my experience is that it is as effective as shouting against a wall |
| 15:28 |
user333_ |
debian 13 comes with 5.10 in it's packages, so that's 4 releases ago of bugs that are going to be reported |
| 15:30 |
user333_ |
they also (likely) won't update it until debian 14 comes out, so any extra documentation to package managers is likely to be ignored.... for 2 years until the next release of debian comes out |
| 15:31 |
erle |
well 5.10 is fine performance-wise, so that's nice |
| 15:32 |
MTDiscord |
<wsor4035> average debian experience being stuck in the dark ages |
| 15:33 |
erle |
wsor4305 you can decide for yourself if you want to run experimental, unstable, testing, stable, oldstable, oldoldstable. |
| 15:33 |
erle |
it's the price of stability, you won't have bleeding edge bugs either |
| 15:34 |
MTDiscord |
<wsor4035> "stability" lol. |
| 15:34 |
sfan5 |
in this case experimental, unstable, testing and stable all have the same version |
| 15:34 |
sfan5 |
i'm sure many people would rather have new features |
| 15:34 |
erle |
compare this to e.g. fedora, which likes to have new stuff immediately and deprecates old things fast. ex gf of mine lost probably years of chat history in a chat messenger due to a bug that never affected other distributions AFAIK |
| 15:35 |
erle |
sfan5 i surely would like to have new features if the focus was on that instead of removing support for hardware i use. ;) |
| 15:35 |
erle |
it's not even that the base game looks any different without any effects on |
| 15:35 |
MTDiscord |
<wsor4035> anyways, talking with erle is futile, so 🤷 im out for now |
| 15:35 |
erle |
it just runs way worse or not at all ._. |
| 15:35 |
[MatrxMT] |
<Blockhead256> debian users who want to be up to date should run flatpak, appimage, portable, compile from source, whatever |
| 15:36 |
erle |
what Blockhead256 says |
| 15:36 |
erle |
i use appimage and compile from source for very few projects but otherwise use debian sta(b)le |
| 15:37 |
sfan5 |
erle: you are clearly not aware of which development happens on Luanti, why and what the goal is |
| 15:38 |
sfan5 |
and I will not attempt to explain it to you as that is futile |
| 15:40 |
erle |
sfan5 i am pretty sure by now that the goal is to a) have cool visual effects and better performance on hardware the devs have or care about (same difference) b) have a general game engine where less stuff is hardcoded to “block game style” (minecraft-likes) c) make the client defer to the server for settings that could be thought of as an intentional choice by game authors (e.g. enabling/disabling fog, coordinate display, eventually probably texture packs) |
| 15:40 |
erle |
i hope that's close enough |
| 15:42 |
erle |
“improve performance on hardware devs don't care about” is clearly not something that's within the goals, since it is evidently possible to about double the framerate on some older/weaker hardware by using legacy opengl (and increase it noticeably on stuff like raspis), but such patch would very likely get rejected, since it used to be that way and you deleted it and closed bugs from users complaining about bad performance. |
| 15:44 |
erle |
which is something i have seen before with e.g. openra. there is no way to make people care about HW they don't have if they delete working code that supports it in the first place. all i want is palliative care to not break existing installs, which is why i was bringing up the idea to twrightsman in the first place. |
| 15:46 |
erle |
well also make existing HW not unusable |
| 15:46 |
[MatrxMT] |
<Blockhead256> you thought Debian, who won't even delete the mods that are horrendously out of date out of their package repo, and has taken multiple months to apply security fixes, will take time to modify upstream source code? |
| 15:46 |
[MatrxMT] |
<Blockhead256> rather "not delete" |
| 15:48 |
MTDiscord |
<wsor4035> dont worry, Debian only modifies code to introduce vulnerabilities or break software see openssl, keepassxc |
| 15:49 |
MTDiscord |
<wsor4035> only half joking |
| 15:50 |
user333_ |
i run debain 12 (going to upgrade to 13 soon) and run my own compiled builds that i update daily, is that enough? :P |
| 15:51 |
erle |
Blockhead256 i would expect that debian would not be likely to accept a ~1000 line performance increasing patch that mostly consistst of reverting stuff that upstream removed |
| 15:52 |
[MatrxMT] |
<twrightsman> Blockhead256: deleting the outdated mods is generally on the games team TODO list, but it relies on volunteered time that isn't currently enough to keep even Luanti up to date |
| 15:52 |
[MatrxMT] |
<Blockhead256> well as long as contentDB is in line with DFSG, it's a pretty clear route to take anyway |
| 15:53 |
erle |
yeah, same thing as openttd basically |
| 15:53 |
erle |
(their BaNaNas system is equivalent to contentDB) |
| 15:54 |
[MatrxMT] |
<Blockhead256> you can actually put nonfree stuff on ContentDB though, but it's hidden inside Luanti |
| 15:54 |
MTDiscord |
<wsor4035> the debian wiki for luanti is still trash. at least they arent as hostle to luanti anymore |
| 15:54 |
erle |
you can also install non-free games using games-data-packager, so … |
| 15:54 |
[MatrxMT] |
<twrightsman> I'm not a Debian lawyer, but to my knowledge users are free to install whatever they want on their systems (ContentDB non-free stuff or not) but Debian would not be allowed to distribute those mods through apt |
| 15:54 |
MTDiscord |
<wsor4035> tho the enable a mod section even for debians outdated version is wrong, and really should only exist for servers |
| 15:55 |
|
seasharp_ joined #luanti |
| 15:55 |
erle |
wsor4035 wdym enable a mod section? |
| 15:56 |
erle |
twrightsman users can download proprietary executable using firefox and execute them using wine! :P |
| 15:57 |
|
book` joined #luanti |
| 15:58 |
[MatrxMT] |
<Blockhead256> I don't really see why you could object to ContentDB as it exists in the menu, again it won't show the nonfree stuff in-game, and it's hard to find on the website. But I'm not 100% up with dfsg |
| 16:00 |
erle |
i think any objection to cdb is strawmanning |
| 16:01 |
erle |
IIRC debian has explicitly set up contrib for stuff that *requires* proprietary game data etc. and luanti does not fall under that |
| 16:01 |
erle |
but e.g. pokemmo-installer is there. proprietary java app that requires at least 1 nintendo DS pokemon black/white ROM. so it goes in contrib. |
| 16:02 |
erle |
openttd was probably in contrib before having fully-free base sets, but idk enough to check |
| 16:06 |
osin_ |
hey, guys, I can't connect to the A.E.S., just receive such error: "Access denied. Reason: Connection timed out." any thoughts? Same for NodeCore community, but to some server I can connect. |
| 16:11 |
erle |
osin_ it might help if you state your client version |
| 16:11 |
erle |
and to which server you *can* connect |
| 16:14 |
osin_ |
I have Luanti 5.14.0 (Linux) and trying to connect to minetest.aes.land:30010 and nodecore.mine.nu:30000 |
| 16:17 |
user333_ |
try the direct IPs, it could be a DNS issue, but i doubt it: '167.86.85.8:30010' and '38.242.238.242:30000' |
| 16:18 |
sfan5 |
!up minetest.aes.land:30010 |
| 16:18 |
MinetestBot |
minetest.aes.land:30010 is up (11ms) (IPv4) |
| 16:18 |
sfan5 |
!up nodecore.mine.nu:30000 |
| 16:18 |
MinetestBot |
nodecore.mine.nu:30000 is up (14ms) (IPv4) |
| 16:19 |
osin_ |
user333_: didn't help |
| 16:19 |
user333_ |
are you downloading/streaming anything on your network? |
| 16:20 |
user333_ |
pause them if so |
| 16:20 |
rubenwardy |
https://content.luanti.org/packages/?flag=nonfree |
| 16:21 |
user333_ |
if it doesn't work with the best possible connection it could be that those servers are blocked in your area, but try connecting later and see if it works |
| 16:24 |
osin_ |
hmm, yep, I can connect using telnet through proxy, but without it: telnet: Unable to connect to remote host: Connection refused |
| 16:27 |
user333_ |
try a VPN if you have one, if you are on one try turning it off/setting it to another location |
| 16:27 |
sfan5 |
you can't use telnet to check for Luanti servers |
| 16:28 |
sfan5 |
it doesn't use TCP |
| 16:31 |
|
___nick___ joined #luanti |
| 16:34 |
osin_ |
:D |
| 16:39 |
[MatrxMT] |
<Blockhead256> does Minecraft, other than Bedrock Marketplace, have a first-party mechanism to download and install worlds? Prior Luanti discussion |
| 16:39 |
[MatrxMT] |
<Blockhead256> https://forum.luanti.org/viewtopic.php?p=439352 |
| 16:39 |
[MatrxMT] |
<Blockhead256> I'm thinking if it exists for Java Edition, it would have to be third-party. Curseforge maybe? |
| 16:43 |
erle |
“does minecraft have it” isn't *really* a convincing argument against/for |
| 16:43 |
erle |
doesn't even have lua mods lol |
| 16:44 |
sfan5 |
we could steal "having enough developers" from minecraft |
| 16:45 |
|
___nick___ joined #luanti |
| 16:46 |
|
SFENCE joined #luanti |
| 16:47 |
erle |
that's kinda self-inflicted though. every single alternate client dev could be a possible coredev. |
| 16:47 |
user333_ |
one of my friends jokes about 'kidnapping minecraft developers and forcing them to code colored lighting for luanti' |
| 16:47 |
erle |
it's just that you don't want *that* kind of contribution or dedication to CSM APIs |
| 16:47 |
|
___nick___ joined #luanti |
| 16:48 |
sfan5 |
the vague notion of "coredevs being big meanies" that seems(?) to be common in the MCL* communities is also self-inflicted |
| 16:48 |
sfan5 |
I'll let bystanders decide which of these take is the hotter take |
| 16:49 |
erle |
look, one response to “particle performance sucks ass” by a dev was “make it possible to toggle rendering particles in the client”, later there were some CSM particle debugging features. we both know luanti would never take this as a patch and would never want people who implement such things. |
| 16:50 |
sfan5 |
just in: coredevs follow their self-decided roadmap |
| 16:51 |
erle |
yes and as i said before, that broadly ensures that everyone who disagrees with that enough will never become one |
| 16:52 |
erle |
also i offered maintaining several parts of the engine that i care about (in terms of: making sure there is no new breakage) and didn't exactly get a “sure, do it” message. |
| 16:52 |
erle |
(rather the opposite) |
| 16:52 |
erle |
years ago btw |
| 16:53 |
erle |
sfan5 the phenomenon is called “evaporation of group beliefs”. if a group does not value dissent (internal and external) enough, over long time scales and in the absence of strong external influences it becomes homogenous if new members of the group have to be approved by existing members. |
| 16:53 |
erle |
it's not groupthink |
| 16:54 |
erle |
but you basically end up with people who regarding a lot of questions in the group end up answering them the same because they are aligned |
| 16:54 |
sfan5 |
we need more devs who share the same vision for Luanti's future, yes. |
| 16:54 |
sfan5 |
this is not a gotcha |
| 16:55 |
erle |
no, it's not. but “devs who share the same vision” is evidently small, while “devs who are willing to do work and do not share the same vision and even disagree on core principles” is a group that i would estimate to be about as twice as big as the coredev group. |
| 16:55 |
erle |
so if you let them in, you get work done, but you might end up with stuff that does not conform to your vision |
| 16:56 |
erle |
some projects chose that path, some another |
| 16:56 |
erle |
IIRC cataclysm dark days ahead takes basically all well-made contributions that do not involve excrement. |
| 16:57 |
erle |
and thus you get stuff like an extra dialog on “how to layer your armor/clothing” |
| 16:58 |
MTDiscord |
<luatic> conversely, if a group values dissent too much, it becomes nothing but a glorified debate club. |
| 16:58 |
erle |
luatic it's about getting work done, which e.g. the MCL* devs and several alternative client devs have proven |
| 16:59 |
MTDiscord |
<luatic> i agree that it's about getting work done, and there is no simple solution to that such as "let everyone contribute whatever" |
| 16:59 |
MTDiscord |
<luatic> quite the opposite. you'll have people working on thing A and people working on mitigating thing A. that's just absurdity. |
| 17:00 |
MTDiscord |
<luatic> the particle example is actually not a bad one in that regard. |
| 17:00 |
erle |
no, but if you took everyone as coredevs who is willing and capable (as in: can vote on project direction and only need one approval), you'd quickly end up with more settings on the client the server can't control and support for hardware you don't want to support. |
| 17:00 |
MTDiscord |
<luatic> for one, there is not really a reason for particles to be terribly inefficient, and there are ways to optimize them; and they have been massively optimized by sfan5 at some point by employing batching. |
| 17:01 |
MTDiscord |
<luatic> for two, in pvp games you often have e.g. smoke particles or similar that are intended to obstruct vision. it's quite obvious that just disabling particles often serves as a cheat. |
| 17:01 |
erle |
luatic actually irrlicht particles were quite fine IIRC, but they couldn't do the rain thing, so unless i am mistaken, they went the way of the dodo |
| 17:01 |
sfan5 |
dEbUgGiNg FeAtUrEs |
| 17:02 |
erle |
instead of, say, patching in the rain tthing |
| 17:02 |
sfan5 |
on a more serious note: where are the statistics on how many users use those alternative clients where "the work has been proven to be done"? |
| 17:02 |
erle |
sfan5 there is a reason that “cheat clients” have this thing where they basically send “i am using a CLIENT SO MODIFIED I CAN CHEAT, BAN ME IF YOU DO NOT WANT IT” |
| 17:03 |
erle |
great way of moving goalposts |
| 17:03 |
sfan5 |
what is the goalpost? you don't ever have a consistent topic |
| 17:04 |
erle |
i have referred to people capable and willing to do work. they have implemented stuff like tracersm and new CSM apis. it doesn't matter how many people *use* that for an assessment if someone is willing and capable to work on the client. |
| 17:04 |
MTDiscord |
<luatic> erle: some clients do, many don't. i think the current hot shit among them kids (it's called something like Mantle v6) doesn't. |
| 17:05 |
sfan5 |
what I was trying to say is that if there is a Luanti fork where the grass is greener then surely they have a lot of users, but I have not seen that happening. |
| 17:05 |
erle |
but that's not what i have been arguing at all |
| 17:05 |
user333_ |
everyone knows about the adware luanti fork for iOS and android |
| 17:05 |
erle |
these people all have their own little things, like my pet peeve is performance on hardware you don't care about and support for features i use like TGA. |
| 17:05 |
sfan5 |
MultiCraft does have a lot of users to be fair |
| 17:06 |
user333_ |
mULtIcrAfT |
| 17:06 |
sfan5 |
not only due to iOS support but also because they have reasonable mobile controls |
| 17:06 |
erle |
there is no technical, only an ideological difference |
| 17:06 |
[MatrxMT] |
<twrightsman> pgimeno: sadly the i386 tests still seem to be failing with the patch and the increased error threshold: https://salsa.debian.org/twrightsman/luanti/-/jobs/8504831/viewer#L4528 |
| 17:06 |
[MatrxMT] |
<twrightsman> I think I will just patch the test out for now and cite this chat as a reason because I still have to get this major version bump reviewed by a full Debian developer with upload rights (I'm not one yet) and that will take some days at least. |
| 17:06 |
user333_ |
and probably some violations of luanti's license too |
| 17:07 |
user333_ |
i have a potato i386 laptop, i can test things on physical hardware if you want |
| 17:07 |
[MatrxMT] |
<birdlover32767> one weird thing i noticed about luanti users is that they tend to say things they don't like by indirectly referencing them (that one game, mine****, ...) |
| 17:07 |
erle |
twrightsman curious, why do you think *patching out a failing test* is appropriate here? |
| 17:08 |
pgimeno |
erle: the test is itself broken |
| 17:08 |
erle |
oh |
| 17:08 |
MTDiscord |
<luatic> yes-ish |
| 17:08 |
erle |
i just remembered that last time a patch broke only on x86 it was the compiler being a bitch |
| 17:08 |
MTDiscord |
<luatic> i think that if this test fails even with large thresholds, it does hint at a real numerical stability problem of the implementation |
| 17:08 |
user333_ |
time to talk to the gcc and clang devs |
| 17:08 |
erle |
(gcc needs SSE on x86 to correctly do floating point, for hysterical reasons) |
| 17:09 |
*Â user333_ |
boots up his potato laptop |
| 17:09 |
erle |
anyway, that was nice i have to go |
| 17:10 |
pgimeno |
@luatic I really think that's not the case, it's a problem of amplification of error near a corner case |
| 17:10 |
erle |
pgimeno there are no corner cases in well-behaved software. there are only cases. |
| 17:11 |
user333_ |
this laptop is so  s l o w, it takes like a full 1m 15s from pushing the power button to getting to the login running debian 12 |
| 17:11 |
MTDiscord |
<luatic> i mean ultimately the cheapest solution is to just exclude the corner cases from testing ;) |
| 17:12 |
MTDiscord |
<luatic> though i guess really the problem then is that the error measure i use is inappropriate |
| 17:12 |
MTDiscord |
<luatic> for gimbal lock |
| 17:13 |
pgimeno |
that's what my patch attempts to address, but it's still failing according to twrightsman http://www.formauri.es/personal/pgimeno/pastes/fix-tait-bryan-angles-i386.patch |
| 17:14 |
user333_ |
huh, i get "All tests passed" when running "./luanti --run-unittests" on i386 |
| 17:15 |
user333_ |
wait lemme test smth |
| 17:15 |
MTDiscord |
<nathan4220776> When you say "i386", do you really mean a 386? Or do you just mean "x86"? |
| 17:15 |
pgimeno |
user333_: with or without a numeric coprocessor? this is an issue of the precision of coprocessor instructions |
| 17:15 |
user333_ |
running "uname -m" returns "i686" -_- |
| 17:16 |
user333_ |
well nvm then |
| 17:16 |
pgimeno |
of trigonometric coprocessor instructions, to be precise |
| 17:17 |
pgimeno |
I assume twrightsman's i386 compilation is using a software library for the calculation of these, one that probably has poor precision in the trigonometric functions |
| 17:17 |
[MatrxMT] |
<twrightsman> I just realized part of this may be that Debian half-dropped "i386" and when they test i386 I think they mean i386 libraries running on amd64. I'm not really an expert in this so I can't give more detail. |
| 17:18 |
[MatrxMT] |
<twrightsman> Since user333_'s tests passed on real "i386" (to use the Debian term) hardware |
| 17:18 |
user333_ |
well i can confirm my laptop is not 64bit... it's from some time between 2000 and 2010 |
| 17:18 |
sfan5 |
the debian build uses SSE |
| 17:18 |
pgimeno |
I think Debian dropped support for 486 a few releases ago |
| 17:19 |
sfan5 |
you can see it in the build logs |
| 17:19 |
pgimeno |
sfan5: you mean twrightsman's build log? |
| 17:19 |
user333_ |
this was i686 apparently... still 32-bit and very slow |
| 17:19 |
sfan5 |
pgimeno: yes |
| 17:24 |
pgimeno |
using -mfpmath=sse -msse does not automatically give you SSE instructions though |
| 17:26 |
pgimeno |
oh I just realized he probably means it's "i386" as opposed to "amd64" |
| 17:26 |
sfan5 |
it does not? |
| 17:27 |
pgimeno |
if you add e.g. -march=i386 it will for sure not use SSE |
| 17:29 |
sfan5 |
>c++ -DMT_BUILDTARGET=2 -DUSE_CMAKE_CONFIG_H [...] -g -O2 -ffile-prefix-map=/build/package/package=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG -Wall -Wextra -Wno-unused-parameter -Werror=vla  -mfpmath=sse -msse -pipe -funroll-loops -O3 -fomit-frame-pointer -fno-math-errno -fno-trapping-math |
| 17:29 |
sfan5 |
-fno-signed-zeros -g -std=gnu++17 -flto=auto -fno-fat-lto-objects -MD -MT .../s_nodemeta.cpp.o -MF .../s_nodemeta.cpp.o.d -o .../s_nodemeta.cpp.o -c .../s_nodemeta.cpp |
| 17:30 |
sfan5 |
doesn't seem to be the case |
| 17:32 |
pgimeno |
yeah I didn't look at the logs before, but now that I've realized that i386 means 32-bit x86 what I said is pointless |
| 17:36 |
user333_ |
then what does i686 mean- |
| 17:38 |
pgimeno |
i686 is not a Debian arch AFAIK |
| 17:39 |
user333_ |
CPU manufacturers want to confuse customers ig |
| 17:39 |
user333_ |
'uname -m' returns 'i686' so... idk |
| 17:40 |
[MatrxMT] |
<twrightsman> pgimeno: There is no Debian architecture label for i686 (though my understanding is this has been attempted), but i386 as of now in Debian means SSE2+ |
| 17:40 |
pgimeno |
thanks for the clarification |
| 17:41 |
user333_ |
i doubt many luanti users use machines this old, and who cares if unittests fail, the game still works, i'd label this bug as 'low priority' |
| 17:42 |
pgimeno |
is it possible to force a 32-bit build? maybe something like cmake -DCMAKE_CXX_FLAGS=-m32 ? |
| 17:47 |
MinetestBot |
[git] Xeno333 -> luanti-org/luanti: Add `default_mapgen` game setting (#16238) dde4636 https://github.com/luanti-org/luanti/commit/dde463635e68ab56070766f032c04ba3f73f1b69 (2025-10-26T17:46:54Z) |
| 17:49 |
MinetestBot |
[git] cx384 -> luanti-org/luanti: Add inventory image animation API (#16538) 93ccb4b https://github.com/luanti-org/luanti/commit/93ccb4b355d45bbdbbcbadcb0d9c1a1dffef5325 (2025-10-26T17:48:53Z) |
| 17:50 |
[MatrxMT] |
<twrightsman> pgimeno: Do you mean for Debian? |
| 17:51 |
pgimeno |
yes I'm using debian, I guess I need a bunch of libs installed |
| 17:51 |
pgimeno |
what happened to debootstrap? |
| 17:52 |
sfan5 |
still exists |
| 17:56 |
pgimeno |
yeah I did a dumb thing (commenting out a line in sources.list that I shouldn't), thanks |
| 17:57 |
user333_ |
maybe don't mess with sources.list ;-; |
| 18:34 |
[MatrxMT] |
<twrightsman> pgimeno: just as a sanity check I cross-built Luanti for i386 (i686) on my amd64 desktop and can reproduce the test failure locally (with your patch and higher threshold) |
| 18:49 |
pgimeno |
I've just finished building it in a chroot with i386 and can't reproduce it, the test passes :( |
| 18:51 |
|
Trifton_ joined #luanti |
| 18:53 |
pgimeno |
@twrightsman how did you do the cross-build? Mine failed to fail. |
| 18:56 |
[MatrxMT] |
<twrightsman> pgimeno: Ugh okay, this is getting spooky. I will write up my instructions in a pastebin |
| 18:57 |
[MatrxMT] |
<twrightsman> Scratch that, better in the GitHub issue |
| 19:06 |
[MatrxMT] |
<twrightsman> pgimeno: Okay I commented on the GitHub issue the way I'm building. I just realized that you probably built with the stable libraries and there could have possibly been a regression between stable and unstable (what I'm using to build) |
| 19:07 |
[MatrxMT] |
<twrightsman> If that's the case, apologies in advance... |
| 19:08 |
[MatrxMT] |
<twrightsman> I will do a stable build in the meantime |
| 19:08 |
pgimeno |
ooh, good point, I built with bookworm in the first place (and there's nothing to apologize about, I'm interested in having a working i386 Debian system) |
| 19:12 |
user333_ |
x86, i386, i686, 32-bit, it all sounds the same to me \_(._.)_/ |
| 19:13 |
user333_ |
i'm currently setting up a debian 13 x86_64 VM for an unrelated purpose, might try an i386 one later (or is it i686... idk) |
| 19:14 |
user333_ |
kind of defeats the 'test on real hardware' part though |
| 19:15 |
[MatrxMT] |
<twrightsman> At least as far as Debian 13+ is concerned, there is no "test on real i386/i686 hardware", from the release notes it sounds like only cross-build for i686 and run on amd64 |
| 19:15 |
[MatrxMT] |
<twrightsman> In case you're curious: https://www.debian.org/releases/stable/release-notes/issues.en.html#reduced-support-for-i386 |
| 19:17 |
user333_ |
i could always set up an older version of debian in a VM, perhaps 10 or 11 |
| 19:18 |
user333_ |
oh yay also no support for my RPi1 other than the bare essentials... |
| 19:30 |
[MatrxMT] |
<twrightsman> pgimeno: Well damn, everything passes on Debian 13/trixie/stable. Then this appears to be a regression in some Luanti dependency between stable and unstable, I guess I can close the GitHub issue at this point |
| 19:31 |
[MatrxMT] |
<twrightsman> Any tips where I should start my search? |
| 19:33 |
user333_ |
uhh... try downgrading packages on unstable to stable until it works (or upgrading stable packages to unstable until it works) |
| 19:33 |
sfan5 |
i don't think luanti has any specific dependency used for math |
| 19:33 |
sfan5 |
except for glibc |
| 19:33 |
user333_ |
or just ignore it and accept that pretty much nobody uses your OS/hardware combo ;) |
| 19:34 |
[MatrxMT] |
<twrightsman> Yeah that's what sfan5 suggested earlier, I generally agree, but it's hard to convince some Debian folks to let go off the strangest architectures :) |
| 19:35 |
[MatrxMT] |
<twrightsman> Either way, thanks everyone for the help, I will investigate within Debian, someone usually knows something |
| 19:45 |
pgimeno |
twrightsman: indeed I've reproduced it in unstable, so I can now work on it ^.^ |
| 19:45 |
user333_ |
no wonder it didnt work for me, i'm on stable |
| 19:46 |
user333_ |
or rather, why it DID work |
| 19:47 |
[MatrxMT] |
<twrightsman> pgimeno: That's awesome :) don't hesitate to ping me if I can help, but I'm off for the night |
| 19:48 |
pgimeno |
a good clue is that exactly one assertion fails and does this every single time |
| 19:48 |
pgimeno |
no worries, I'll look into it |
| 19:56 |
|
SFENCE joined #luanti |
| 20:01 |
|
SFENCE joined #luanti |
| 20:02 |
|
sfence_ joined #luanti |
| 20:17 |
|
SFENCE joined #luanti |
| 20:19 |
pgimeno |
wowza... http://www.formauri.es/personal/pgimeno/pastes/euler-to-quaternion-failure.txt ... where do these NaN's come from?! this appears not to be a Luanti problem at all |
| 20:20 |
sfan5 |
batman |
| 20:21 |
pgimeno |
X'D |
| 20:21 |
user333_ |
if you set your position to 'nan' ingame with a mod, it starts getting REALLY buggy |
| 20:22 |
[MatrxMT] |
<birdlover32767> i have experienced that |
| 20:23 |
user333_ |
if you teleport yourself to the player at nan, nan, nan you get put extremely far out of bounds but not at 'nan' |
| 20:23 |
user333_ |
it's very broken |
| 20:49 |
|
SFENCE joined #luanti |
| 20:50 |
pgimeno |
@twrightsman It's most likely not a Luanti bug, unless it's triggering some uninitialized var or other UB that causes this weirdness, but I somewhat doubt it. When I modify the test to print the values, the result of rot.setRotationRadians() has a bunch of NaN's. When I modify it so that rot.setRotationRadians() is called a second time, the result is correct. Here's the output I've captured including that second result: http://www.formauri.es/personal/pgim |
| 20:50 |
pgimeno |
eno/pastes/euler-to-quaternion-twice.txt |
| 20:50 |
pgimeno |
crap |
| 20:50 |
pgimeno |
http://www.formauri.es/personal/pgimeno/pastes/euler-to-quaternion-twice.txt |
| 20:55 |
pgimeno |
I haven't checked, but a good hypothesis is that the reason why it fails exactly once is that it only fails in the first test. |
| 21:08 |
|
SFENCE joined #luanti |
| 21:36 |
|
SFENCE joined #luanti |
| 21:54 |
|
SFENCE joined #luanti |
| 23:02 |
|
SFENCE joined #luanti |
| 23:33 |
user333_ |
someone explain this lighting bug.... https://filebin.net/whlsa02o71xxfryk/2025-10-26-202859_1920x1080_scrot.png |
| 23:34 |
user333_ |
https://filebin.net/whlsa02o71xxfryk/2025-10-26-202859_1920x1080_scrot.png |
| 23:34 |
|
SFENCE joined #luanti |
| 23:35 |
user333_ |
oops, didnt mean to send that twice, my client is not rendering URLs for some reason |
| 23:41 |
|
panwolfram joined #luanti |
| 23:53 |
user333_ |
2 more screenshots of it, https://filebin.net/fnf7cycct5mvws5k/2025-10-26-204813_1920x1080_scrot.png and https://filebin.net/fnf7cycct5mvws5k/2025-10-26-205100_1920x1080_scrot.png |
