00:10 < bridge_> The amount of pull requests have grown concerning, we should go through these before it goes completely out of hand 00:27 < bridge_> so pplz will create one big instead 5 small.It is even worse. 00:32 < bridge_> I think @learath2 is calling for maintainers to go through the PRs 00:32 < bridge_> I'll try to go through the PRs tomorrow 00:46 < bridge_> #8386 is quite interesting 00:46 < bridge_> `actual 1127695164: 01000011 00110111 01000011 00111100` 00:46 < bridge_> `expect 1127629628: 01000011 00110110 01000011 00111100` 00:46 < bridge_> 00:46 < bridge_> `actual -514903197: 11100001 01001111 00110011 01100011` 00:46 < bridge_> `expect 3779998307: 11100001 01001110 00110010 01100011` 00:46 < bridge_> https://github.com/ddnet/ddnet/issues/8386 00:46 < bridge_> It's one bit flips 00:57 < bridge_> is this a two's complement thing 00:59 < bridge_> oh 00:59 < bridge_> i didn't see the first pair were different 01:00 < bridge_> tbf I don't understand this bizarre encoding at all, `"öüä"` is just 4 bytes of utf8, why is it ending up in 2 ints? 01:01 < bridge_> why is it just the 16th and 24th bits 01:02 < bridge_> tbf I don't understand this bizarre encoding at all, `"öüä"` is just 3 bytes of utf8, why is it ending up in 2 ints? 01:02 < bridge_> ```py 01:02 < bridge_> >>> len("öüä".encode()) 01:03 < bridge_> 6 01:03 < bridge_> ``` 01:03 < bridge_> python (and my internal UTF-8 encoder) disagrees 01:03 < bridge_> those might be ligatures 01:03 < bridge_> OH I had my encoding wrong on this stupid tool 01:03 < bridge_> äöü are non-ASCII, thus taking up at least 2 bytes 01:03 < bridge_> äöü are non-ASCII, thus taking up at least 2 bytes in UTF-8 01:03 < bridge_> python len measures bytes and not chars of a string? 01:03 < bridge_> concerning 01:04 < bridge_> "chars" of a string is ill-defined 01:04 < bridge_> but python does indeed measure something ill-defined for strings 01:04 < bridge_> I asked for the length of a byte string though (`"äöü".encode()`) 01:04 < bridge_> for utf8 encoded strings 01:04 < bridge_> for ascii encoded strings it's not so ill-defined 😄 01:04 < bridge_> i think the foob is to have this guy run a test on an older version of ddnet 01:05 < bridge_> ASCII yes, "characters" seems simple enough there 01:05 < bridge_> but in Unicode (irrespective from the encoding, be it UTF-8 or UTF-16), "character" is quite ill-defined 01:06 < bridge_> This test failure really makes no sense to me, did they re run it? Maybe it's cosmic rays? 🙃 01:06 < bridge_> not gamma rays 01:07 < bridge_> http://2143.christmas/f/d5xf.png 01:07 < bridge_> probably this 01:07 < bridge_> I had a theory but that's probably not it 01:07 < bridge_> Is adding 128 there even well defined for a signec char? 01:07 < bridge_> Is adding 128 there even well defined for a signed char? 01:07 < bridge_> I think it is because it should get promoted to int 01:08 < bridge_> there's "code unit" (byte for UTF-8, 16 bit-integer for UTF-16), "code point" (number between 0 and 0x10ffff, excluding 0xd800-0xdfff) and "user-perceived character" ("grapheme" in unicode parlance) 01:08 < bridge_> but idk maybe they are compiling with a weird compiler 01:08 < bridge_> fedora rawhide 01:08 < bridge_> gcc 01:08 < bridge_> yes, it's promoted to `int` first 01:08 < bridge_> lets also blame this one on cosmic rays ^^ 01:08 < bridge_> https://github.com/ddnet/ddnet/issues/8172 ☀️ ☀️ ☀️ 01:11 < bridge_> quakenet is still posting stuff to their blog: https://www.quakenet.org/news/375-port80se-delink 01:12 < bridge_> (they still don't support TLS btw) 01:12 < bridge_> First thing that caught my eye was that it only happened with unicode, I wonder if it is a compiler reading the file wrong problem 01:12 < bridge_> port80/"ip only" does give this impression 01:13 < bridge_> wouldn't be the first time i've seen that, i just always escape 01:13 < bridge_> port80 was just a sponsor, I think 01:13 < bridge_> or file encoding issue 01:13 < bridge_> but i think git should keep that proper 01:14 < bridge_> unlikely. it's just bytes to the compiler 01:16 < bridge_> But there is nothing special to unicode that we do in `StrToInts` 01:16 < bridge_> The only other entity involved is the compiler 01:17 < bridge_> I can't spot any potential UB either except for the `+ 128` that sussed me out at the start 01:18 < bridge_> There are some absurd machines with 9 bit chars that might break it but I very much doubt this would be the only test to break 😄 01:20 < bridge_> `(aBuf[0] + 128) << 24` this is UB 01:20 < bridge_> shifting into the sign bit 01:20 < bridge_> Yep, damn 01:21 < bridge_> looks like it happens on 16 too 01:21 < bridge_> How did I miss that, I was thinking about why these things werent unsigned to start with but didn't spot that 01:21 < bridge_> i would have expected ubsan to find this 01:22 < bridge_> I don't know whether we run the test suite with ubsan, nor if we have the correct flag enabled 01:24 < bridge_> We do run tests with asan/ubsan, I wonder why it doesn't pick it up 01:27 < bridge_> gamma rays 01:29 < bridge_> that's interesting lmao 01:30 < bridge_> is there an intrinsic or builtin for packing bytes into a u/int_*t? 01:31 < bridge_> LOL after we run the unit tests with asan and ubsan, we don't check their output properly because we don't export `ASAN_OPTIONS` and `UBSAN_OPTIONS`.... 01:33 < bridge_> professional 01:33 < bridge_> unrelated but im trying to switch to arch/artix asap 01:33 < bridge_> but i'm not sure what to do 01:33 < bridge_> currently my OS is split across 3 nvme drives 01:34 < bridge_> but my 2nd pcie 16x slot (which i plan to use for GPU passthrough) is switched with the third nvme slot due to pcie lane constraints 01:35 < bridge_> so i wonder if i should just split my system across the first 2 drives and use the gpu, or if I should do what i'm doing rn and only use 1 16x slot 01:35 < bridge_> problem is then i have a completely unused drive lol 01:36 < bridge_> also still torn between arch and artix. have you ever had any systemd-related issues using arch repos on artix? 01:37 < bridge_> though I do find it hard to imagine what the compiler would emit that makes this happen, but would be worth fixing 01:38 < bridge_> You'll need to be comfortable with getting your own init files sometimes as artix is a small project that doesn't always have it packaged properly 01:38 < bridge_> sounds exactly like what I want to avoid 01:38 < bridge_> Usually just a matter of getting it from gentoos repo 01:39 < bridge_> Honestly, I'm not the best person to ask this. I would not have systemd on anything I own, no matter how annoying it is to not have it 01:39 < bridge_> I would sooner code my own 01:39 < bridge_> is compartmentalizing systemd really so far from reality 01:40 < bridge_> i don't know too much about its issues 01:40 < bridge_> because i generally use its features 01:40 < bridge_> all at once or not at all 01:40 < bridge_> Well things like init files are hard, since systemd in their infinite wisdom decided moving away from shell scripts is the best idea 01:41 < bridge_> So any distro that wants to offer multiple init systems, has to offer a shell script for every init system ever, and a systemd unit file for systemd 01:42 < bridge_> but unit files can very easily wrap shell scripts 01:42 < bridge_> But then you can't use the fancy functions of unit files 01:42 < bridge_> OpenRC offers the fancy features using extensions to the shell scripts in the form of annotations and functions, as it should be 01:43 < bridge_> Systemd offers fancy features by breaking every other init system support, definitely not in an attempt to push out competition for world domination 01:44 < bridge_> Anyway, only a few distros offers both properly. For distros that are small forks that remove systemd, you'll usually always need some manual labour to get stuff like init files 01:44 < bridge_> s\/offers/offer/ 01:45 < bridge_> offer 01:45 < bridge_> i think hating systemd because it works differently is silly 01:46 < bridge_> maybe sometimes it's inconvenient but i think most of the issues people have with it should be fixed in systemd 01:46 < bridge_> There are many reasons I hate systemd, so many that it would take us hours 01:47 < bridge_> So I'll give you the most important one. I don't even need to consider the others after this one. I ideologically disagree with this tumor-like development strategy and the resulting nasty monolith 01:47 < bridge_> I see 01:48 < bridge_> so what makes you say that their goal is to "conquer" the world of init systems 01:48 < bridge_> i think they made a project that was fundamentally different and naturally as more people used it, it grew 01:49 < bridge_> They made a project that was fundamentally different. Then they started a marketing campaign targeting distro maintainters, they pushed their way onto mailing lists 01:50 < bridge_> They didn't convince the userbase, they just convinced fedora maintainers 01:50 < bridge_> were they themselves not fedora maintainers 01:50 < bridge_> (because Poettering literally worked at Red Hat) 01:51 < bridge_> This is all disgusting backroom bs 01:52 < bridge_> if somehow the users were involved in the decision making process, things probably would have gone the same way, no? 01:53 < bridge_> i think systemd hatred is a somewhat new thing 01:53 < bridge_> Not even close to being new, I was there when these people infected debian too 01:54 < bridge_> There was always sane voices telling people the convenience was not worth introducing a million line monolith onto our computers 01:54 < bridge_> But linux users are not fundamentally different than users of any software. Most users only care about convenience, nothing else 01:55 < bridge_> i think people will do nearly anything in the interest of time 01:56 < bridge_> maybe distro maintainers could have staged systemd differently or offered an alternative version that still used sysvinit. but that's much more work 01:56 < bridge_> and i think in the end most people would still want systemd 01:57 < bridge_> most people don't even understand what systemd is, let alone have an opinion 01:58 < bridge_> they can use more software, and very rarely have to mess around with init scripts and the like, even if it takes them another second or two to boot 01:58 < bridge_> that's exactly what they leveraged in their marketing campaign, a less transparent piece of software that justworks(tm) 01:58 < bridge_> i agree i don't like the way it is rn 01:59 < bridge_> systemd was faster because legacy sysvinit didn't parallelize well, that's how they convinced the ubuntu people 01:59 < bridge_> It can't be worse than sysvinit 01:59 < bridge_> systemd unit files were readily available and declarative, that's how they convinced the debian maintainers who were already struggling 01:59 < bridge_> but I also don't think it's inherently flawed, if it was the same software package presented in a more modular fashion then people wouldn't have issues with it 01:59 < bridge_> poettering worked at red hat, that's how they got it into fedora 01:59 < bridge_> Out of all the software complaints I have systemd doesn't rank high 01:59 < bridge_> But I'm not a demanding user 02:00 < bridge_> I would just out of pure ideology use sysvinit and spend an extra minute booting 02:01 < bridge_> I'm using systemd-boot and systemd for DHCP and I think DNS 02:01 < bridge_> And it has "just worked" as much as it can 02:01 < bridge_> But I'm not defending it on some experienced level 02:01 < bridge_> i don't think systemd does dns 02:01 < bridge_> network-manager or dhcpcd 02:02 < bridge_> What's even more disgusting is how systemd slowly absorbed other projects into it. Such as udev, they promised it wouldn't become dependant on systemd. It was dependant immediately the next version. Gentoo had to maintain eudev for a decade 02:02 < bridge_> I think it does 02:02 < bridge_> https://wiki.archlinux.org/title/systemd-resolved 02:02 < bridge_> This thing 02:02 < bridge_> systemd does everything worry not 02:02 < bridge_> oh i see 02:02 < bridge_> it's a nasty tumor that just has it's hand in every pie so that it becomes undissectable 02:03 < bridge_> i guess it's more, like 02:03 < bridge_> backdoor prone 02:03 < bridge_> "had to maintain" are they still maintaining it? 02:03 < bridge_> they ate consolekit, they ate polkit, they even ate cgroups support from the kernel 02:03 < bridge_> Wasn't the xz thing related to systemd in some way? 02:04 < bridge_> A few volunteers are still keeping it kinda up to date, but systemd gracefully allowed us to have udev back so we can use systemd-udev without systemd too 02:06 < bridge_> Why on gods green earth does my init system need to be connected to my dns resolver in any way? Why is my dns resolver going over dbus? Why is my init system involved in spawning containers? Why is my init system booting my computer? Why is my init system doing ntp? 02:07 < bridge_> ofcourse it is, just imagine the attack surface 02:07 < bridge_> good luck backdooring sysvinit, it's not connected to anything, it won't interpret anything itself 02:08 < bridge_> I think for DHCP I'm actually using whatever thing iwd has built in for it 02:09 < bridge_> Anyway, I don't really need any of these logical reasons to not like systemd. It completely goes against everything I believe fundamentally. It's like saying "autocracy is good because a good dictator can make better decisions faster than a democracy" 02:09 < bridge_> I still wouldn't want to live in a dictatorship 02:10 < bridge_> You already do 02:10 < bridge_> But... lets keep it technical I guess 02:10 < bridge_> It's a hypothetical 02:17 <+ws-client> ddnet 9 finds no ger servers? @heinrich5991 did we drop support for 10 yr old ddnet versions? xd 02:17 <+ws-client> @rafael8192 I sent you the exact code. I sent you two projects that implemented dummies and are ready to use. And the command you can use to get ddnet up and running with dummies. If you have trouble with any of those let me know some details. 02:17 <+ws-client> but if you keep asking for a func name you won't progress here. 02:19 <+ws-client> @fury0908 i don't remember seening a svg template but maybe this helps https://github.com/TeeworldsDB/graphictemplates/blob/master/grids/grid_skins_07.png 02:21 < bridge_> Yeah, see these people there is something wrong with them. Added Kay Sievers to my list of prayers 02:21 <+ws-client> @fury0908 here is greensward as svg maybe that helps you too :) https://github.com/teeworlds/teeworlds/files/3294053/greensward.zip 02:23 < bridge_> I don't remember if the fix was done on the kernel side or not 02:23 < bridge_> But just... Not prefixing your own configuration seems ridiculous 02:25 < bridge_> I'll tell you my opinion on it, they are entitled. This is the behaviour I've observed from these people ever since that first blog post about "Reimagining PID 1". They would eat the kernel whole if they had the development capacity 02:29 < bridge_> And regarding the init systems, is openrc or runit better? Any opinions there? 02:29 < bridge_> Regarding systemd-boot I think it might be the only part of systemd that can kind of be described as "minimal" 02:29 < bridge_> I've been using openrc, on everything, for a decade, it works, it's fast, it doesn't overreach 02:30 < bridge_> It's basically just a menu that lets you pick a boot entry, nothing more 02:30 < bridge_> Way better than grub ime 02:30 < bridge_> But of course grub sucking doesn't excuse systemd 02:30 < bridge_> I've used it before and it is surprisingly well isolated, but I've moved back to refind nowadays 02:31 < bridge_> Grub is absolutely terrible and I hate how it's pushed on new users 02:31 <+ws-client> lmao lerato and the big systemd conspiracy 02:31 < bridge_> It's the source of one of my 3 full arch breakages so far 02:31 < bridge_> Mostly because again, I find the way systemd and it's main developers conduct themselves abhorrent. Don't want anything conjured up by them anywhere near me 08:10 < bridge_> I wish UI could adapt to strings 08:10 < bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1244533048356372570/b187caa3c7497e53.png?ex=66557539&is=665423b9&hm=6f95666789bf05631f0f8add5f66ec5b9a383d0c72b3f38d95e4968dd19c35fc& 08:13 < bridge_> Also, I think that reused "Spectate" string at the right bottom should be it's own "Spectating" string instead - it would just make more sense! 08:13 < bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1244534024894939256/6850cca7f541a004.png?ex=66557621&is=665424a1&hm=7d902d40c5c1ae388870e202b0580933217e353d0e05d15dfd94313e778469d8& 08:14 < bridge_> morning 08:19 < bridge_> But for now, I'll do with what I have... 08:45 < bridge_> submit a pull request 09:20 < bridge_> Can't submit a pull request, can only make an issue 09:23 < bridge_> Why 09:26 < bridge_> If you are going to use gnome, you almost have to use systemd. Gnome developers are the worst at isolating themselves. They link to everything and make it a dependency, including the tumor that is systemd 09:29 < bridge_> Can't code :^( 09:43 < bridge_> There isn't that much coding involved, try searching the code base for `"Spectate"` which should lead you to a line in `hud.cpp` that you can change. 10:07 < bridge_> Those two are different, so changing the line in `hud.cpp` is fine. The button you are talking about can be found in `menus_ingame.cpp`. 10:07 < bridge_> Okay... then I need to also add this string into l10n files, right? 10:14 < bridge_> But now we have SearXNG 10:15 < bridge_> Now we have SearXNG 10:15 < bridge_> Now we have SearXNG (and it's kinda good) 10:17 < bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1244565012391919636/GOg-VPoWMAAGGJ7.jpg?ex=665592fd&is=6654417d&hm=e756c39a9dcfa5b2bbcc408e55e5f716902d376ecc9281061bd5e06c0d364569& 10:18 < bridge_> You could, but what's wrong with name? 10:18 < bridge_> I think so 10:21 < bridge_> In Ukrainian (and other Slavic languages too), we have two words: "ім'я" (first/given name) and "назва" (proper noun) 10:25 < bridge_> For example, "Andrew" is ім'я, and "DDNet" is назва 10:31 < bridge_> @ryozuki do u know who did aur pkg for ddnet 10:32 < bridge_> cargo and discord game sdk are hard deps even tho u should be able to use rustup & entirely disable the discord integration 10:34 < bridge_> Hm, I guess changing the "name" string in server browser to "server name" should be fine? 10:40 < bridge_> furo: have you checked the widths of the text fields? 10:40 < bridge_> (you also don't need to change the original strings to have two different strings in a translation) 10:40 < bridge_> Yeah, it's gonna be fine. Thanks for help! 10:42 < bridge_> rafaelff 10:42 < bridge_> i see 10:42 < bridge_> maybe i will work on it later 10:47 < bridge_> if the light rays were not shot perfectly orthogonal, then it's probably very hard to say how big red is 10:48 < bridge_> 😬 10:49 < bridge_> We live in a perfect world 🌎🌍 10:49 < bridge_> We live in a perfect world 10:58 < bridge_> hmm no u can know the ratio from green 11:03 < bridge_> true, we could measure if the shadow outlines are parallel to figure that out 11:03 < bridge_> there could be material in the air that makes it look like it is perfect just for the camera 11:04 < bridge_> and if u'd move it 1cm it would look completely different 11:04 < bridge_> similar to how water bends stuff visually 11:04 < bridge_> i'd give such an answer in a math test and probably fail xD 11:05 < bridge_> who even says that green and red are lighted by the same light source at all 11:06 < bridge_> lit 11:20 < bridge_> anyone know the state of the nvidia-open driver? 11:20 < bridge_> u mean nouveuououooum 11:20 < bridge_> ? 11:20 < bridge_> No 11:20 < bridge_> i mean the official nvidia oss driver 11:20 < bridge_> ah, the kernel module? 11:20 < bridge_> remember when that hacker threatened to leak 11:20 < bridge_> and nvidia was like okay okay we will open source 11:21 < bridge_> yeah there was smth 11:21 < bridge_> 11:21 < bridge_> but someone still has to write the integration for it into mesa i guess 11:21 < bridge_> ah 11:21 < bridge_> i think i will try them 11:22 < bridge_> if nvidia drivers ever get as good as amd would be epyc 11:22 < bridge_> one day 11:23 < bridge_> competition in the graphics card market for linux 11:23 < bridge_> 😬 11:23 < bridge_> properietary performance is fine but integration is terrible 11:23 < bridge_> seems to make my gnome shit bricks 11:23 < bridge_> Thanks to the valiant efforts of the gentoo team to keep it all working 11:23 < bridge_> yeah 11:24 < bridge_> wonder if i can make the wm use my integrated graphics 11:24 < bridge_> I don't think it's in a usable state 11:29 < bridge_> Ah, I need to compile it... oh well. 11:29 < bridge_> afaict i am using them rn but i think the modules are called the same thing 11:29 < bridge_> seems to be working just as well 11:29 < bridge_> still shitty in gnome 11:30 < bridge_> man i really wanted this thing to mature https://github.com/jpochyla/psst/graphs/code-frequency 11:34 < bridge_> wtf, i did not expect teamspeak3 to be in the extra repo 11:43 < bridge_> Im Home in Like 4 1/2 hours @egyt, If you struggle with doing a PR I can do that for you 11:43 < bridge_> "written in Rust, without Electron' I love it already 11:45 < bridge_> For now not, but still thanks! 11:56 < bridge_> technically feature complete but it’s missing stuff like discovery that makes it rly viable for using instead of the official app 12:11 < bridge_> I compiled it and, well, no changes that I made 0\_0 12:15 < bridge_> ``` 12:17 < bridge_> ewan@machine ~ [127]> DDNet 12:17 < bridge_> 2024-05-27 04:15:22 I engine: running on unix-linux-amd64 12:17 < bridge_> 2024-05-27 04:15:22 I engine: arch is little endian 12:17 < bridge_> 2024-05-27 04:15:22 I engine: operating system version: Linux 6.9.2-arch1-1 (x86_64, #1 SMP PREEMPT_DYNAMIC Sun, 26 May 2024 01:30:29 +0000); "Arch Linux" 12:17 < bridge_> 2024-05-27 04:15:22 I storage: couldn't open storage.cfg 12:17 < bridge_> 2024-05-27 04:15:22 I storage: using standard paths 12:17 < bridge_> 2024-05-27 04:15:22 I storage: added path '$USERDIR' ('/home/ewan/.local/share/ddnet') 12:17 < bridge_> 2024-05-27 04:15:22 I storage: added path '$DATADIR' ('/usr/share/ddnet/data') 12:17 < bridge_> 2024-05-27 04:15:22 I storage: added path '$CURRENTDIR' ('/home/ewan') 12:17 < bridge_> 2024-05-27 04:15:22 I console: executing 'settings_ddnet.cfg' 12:17 < bridge_> 2024-05-27 04:15:22 I client: adding 72.204.22.162:6629 to favorites 12:17 < bridge_> 2024-05-27 04:15:22 I sdl: SDL version 2.30.3 (compiled = 2.30.3) 12:17 < bridge_> 2024-05-27 04:15:22 I gfx: Created Vulkan 1.1 context. 12:17 < bridge_> 2024-05-27 04:15:22 I gfx: GPU vendor: NVIDIA 12:17 < bridge_> 2024-05-27 04:15:22 I gfx: GPU renderer: NVIDIA GeForce RTX 3060 12:17 < bridge_> 2024-05-27 04:15:22 I gfx: GPU version: Vulkan 1.3.277 (driver: 550.78.0.0) 12:17 < bridge_> /usr/include/c++/14.1.1/bits/stl_vector.h:1130: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = std::vector; _Alloc = std::allocator >; reference = std::vector&; size_type = long unsigned int]: Assertion '__n < 12:17 < bridge_> fish: Job 1, 'DDNet' terminated by signal SIGABRT (Abort) 12:17 < bridge_> ``` 12:17 < bridge_> ☹️ 12:17 < bridge_> bt 12:17 < bridge_> true. 12:17 < bridge_> index out of range? maybe a problem of our code? 12:17 < bridge_> `CCommandProcessorFragment_Vulkan::SDelayedBufferCleanupItem` sounds like ddnet graphics code 12:17 < bridge_> I hope running grep \~/ddnet won't ruin my system... 12:18 < bridge_> Vulkan mentioned, @jupeyy_keks pinged 12:18 < bridge_> :kek: 12:19 < bridge_> is that latest ddnet code? 12:19 < bridge_> from aur which builds from upstream 12:19 < bridge_> upstream latest? 12:19 < bridge_> or upstream latest version 12:19 < bridge_> by default latest release 12:19 < bridge_> 18.2-1 12:20 < bridge_> so not master branch 12:20 < bridge_> try ddnet-git 12:20 < bridge_> arch dist flags are also known to screw things up 12:20 < bridge_> no 12:20 < bridge_> fortify source and whatnot 12:20 < bridge_> yes 12:20 < bridge_> it looks like the thing melon already reported 12:20 < bridge_> but it should be fixed 12:21 < bridge_> Ewan are you using X11 or wayland ? It happened on my hyprland setup, worked on cinnamon x11 12:21 < bridge_> waylon 12:21 < bridge_> im building from ddnet-git rn 12:21 < bridge_> ah much better 12:21 < bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1244596408145805333/image.png?ex=6655b03b&is=66545ebb&hm=f07b6681a895807767c5ab938e3386d751b9d2b3a8f3b8729c639de57c4bc243& 12:22 < bridge_> we fortify source in ddnet as well. also, if that breaks anything, it's usually a bug in the project 12:22 < bridge_> yes 12:22 < bridge_> it can expose bugs that devs didnt know about 12:22 < bridge_> fortify source means adding more bounds checks, so less unnoticed out of bounds writes 12:22 < bridge_> ah yeah LTO 12:27 < bridge_> tja 12:27 < bridge_> this close to going back to xorg 12:27 < bridge_> wayland still beta after 20 years 12:27 < bridge_> yea 12:27 < bridge_> you can tell the compiler that `Localize` passes through the string as-is 12:27 < bridge_> also doesn't help it makes all my xorg apps blurry n shit 12:28 < bridge_> lmao 12:28 < bridge_> soon kde6 releases, with wayland on default 12:28 < bridge_> already super hyped to have a broken wm 12:28 < bridge_> 😬 12:29 < bridge_> i seriously wonder why they struggle so much with wayland 12:36 < bridge_> it has already released 12:37 < bridge_> thanks for beta testing 12:37 < bridge_> all of this stuff is just so fucking close to working properly 12:38 < bridge_> but the tiny bugs go the furthest 12:38 < bridge_> and make things completely unusable 12:38 < bridge_> maybe middleware devs can’t handle wayland’s low level nature 12:39 < bridge_> so much more room for error 12:39 < bridge_> 🤣 13:25 < bridge_> @heinrich5991 how did you end up sending the messages back into C++? 13:25 < bridge_> I expose a C API 13:25 < bridge_> modelled a bit after curl's 13:26 < bridge_> probably only publishers can use them @avolicious https://discord.com/channels/252358080522747904/745926398140612678/1244612429422526475 13:26 < bridge_> Yeah, thought so 13:26 < bridge_> thanks 13:27 < bridge_> On which side? 13:27 < bridge_> on rust's side 13:28 < bridge_> it's basically a rust library with an optional C API 13:29 < bridge_> (https://github.com/ddnet/ddnet/pull/6961 for an older version of it) 13:29 < bridge_> Did you make it asynchronous somehow? We can't really block waiting on two network stacks one after the other, so I'm guessing you did find a way 🙃 13:29 < bridge_> I'll have a couple of design questions in the end 13:29 < bridge_> I'm only blocking on the socket, feeding the stuff to the right network protocol once it comes from the socket 13:30 < bridge_> We already do that I think: 13:30 < bridge_> ``` 13:30 < bridge_> extern const char *Localize(const char *pStr, const char *pContext = "") 13:30 < bridge_> GNUC_ATTRIBUTE((format_arg(1))); 13:30 < bridge_> ``` 13:30 < bridge_> The build failure seems related to the `str_format` template 13:31 < bridge_> But are you even allowed to block on that? The game code needs to keep going even if there are no packets coming in, no matter how unlikely that is 13:31 < bridge_> ah. we might need to tell the compiler to disable the warning for the release build, I guess 13:31 < bridge_> I'm doing the same thing as before. blocking with a timeout that the game code dictates 13:32 < bridge_> Oh wait is it one socket for both udp and quic? 13:32 < bridge_> yes 13:32 < bridge_> Ah that's a cool way to do it 13:32 < bridge_> (otherwise, you could select (or more modern alternatives) on two sockets) 13:32 < bridge_> I would have probably moved quic to 9304 and used two sockets with select/epoll 13:33 < bridge_> 8304* 😄 13:33 < bridge_> the tricky stuff is all the edge cases 13:33 < bridge_> e.g. local serverbrowser. how's that supposed to work 13:34 < bridge_> No broadcast in quic? 13:34 < bridge_> no connection-less messages in quic 13:34 < bridge_> broadcast is probably not impossible, but currently not possible with the quic library I'm using 13:35 < bridge_> Well if we keep the udp thing forever. I guess just using it for discoverability wouldn't be the worst 13:35 < bridge_> you talking about ddnet quic pr? 13:35 < bridge_> ye 13:35 < bridge_> meh, I'd like to move away from that ^^ 13:35 < bridge_> i.e. support turning off the teeworlds net protocol entirely 13:36 < bridge_> Well if quic doesn't support it, quic doesn't support it. Can't do any better than that 13:36 < bridge_> getting the server info could be a thign you do with a connection 13:36 < bridge_> If broadcasts are somehow possible maybe you could make something work 13:37 < bridge_> Or abuse something like bonjour. Don't most OSs run some daemon for it? 13:38 < bridge_> broadcasts are possible in any network protocol, as you can just broadcast the first network message and treat each answer individually 13:38 < bridge_> btw. design questions: 13:38 < bridge_> - review protocol for segmenting messages, is there some sort of standard maybe? 13:38 < bridge_> - review protocol for disconnects, could we maybe get a two-way disconnect? 13:38 < bridge_> Not on windows unless explicitly installed (or by iTunes) 13:38 < bridge_> we get a byte stream from quic. how do we segment messages? 13:39 < bridge_> on disconnects: I'm currently tending towards two-way disconnects to make them reliable 13:40 < bridge_> and then I'd limit the amount of connections in pre-connect and disconnecting state to like 1 or 2 per IP address 13:41 < bridge_> oh, and then there's getting server info from favorites not listed on the masterservers. also an interesting question. might get the same treatment as the local server 13:42 < bridge_> Isn't segmenting already handled by CNetChunk and whatever we bundle chunks in? 13:42 < bridge_> the problem is that we get more features in QUIC 13:43 < bridge_> we get unreliable messages (used for unreliable ddnet `CNetChunk`s) 13:43 < bridge_> and we get byte streams (used for reliable ddnet `CNetChunk`s) 13:44 < bridge_> but we need to segment these byte streams again. using the old structure would work, but it's kinda unnecessary because they contain an ID and some flags we don't need 13:44 < bridge_> Ah, so you can root out all the reliabile delivery we have to implement over udp 13:44 < bridge_> yes! 13:45 < bridge_> I would just send bare CNetChunks, don't they contain enough information in the header to know when one is complete? 13:46 < bridge_> they contain unnecessary IDs though, and unnecessary flagds 13:46 < bridge_> they contain unnecessary IDs though, and unnecessary flags 13:48 < bridge_> Heh, true nothing in there is needed anymore flagwise tbh. So I guess might aswell google around to learn if there is a segmentation standard somewhere 13:48 < bridge_> I would just use length prefixed messages, but doesn't hurt to check around 13:48 < bridge_> yea, that's what I'm currently using 13:49 < bridge_> What is the benefit of a two way disconnect btw? 13:50 < bridge_>