01:32 < bridge> tested harpoon and water from the teeworlds pr and they dont seem to do much 01:32 < bridge> harpoon would be useless in ddnet 01:32 < bridge> posted the videos in #9973 if anyone wants to see without compiling it 01:32 < bridge> https://github.com/ddnet/ddnet/issues/9973 01:33 < bridge> not everything needs a unique gameplay niche 01:33 < bridge> water is better than any combination of tunes imo, it also dampens velocity more waterlike 01:36 < bridge> yea its better than tunes, the visuals especially 01:36 < bridge> but not by a lot 02:11 < bridge> feel free to ask questions 02:14 < bridge> i agree 02:15 < bridge> okay, then more switches 07:17 < bridge> my trivial prs are appreciated 🥺 10:12 < bridge> Good morning :owo: who is ASKLL-STAR and how does he find nightly issues so fast? 10:15 < bridge> He is chinese so the nightly is his daily xd 10:16 < bridge> daily quest: break nightly, poetic 11:01 < bridge> https://paste.pr0.tips/W1Q 11:01 < bridge> 11:01 < bridge> I wrote an Imhex pattern for teehistorian files. It doesn't work great for teehistorian files sadly. It takes 20G of memory to apply the pattern to a 2.6M file 11:02 < bridge> I did use it to look into the random unknown items. It well and truly looks like it just randomly decides to record a completely wrong thing 11:11 < bridge> do you have an error rate? 11:26 < bridge> 1 file in about 30k seems to have some sort of error, and for whatever reason it seems more likely on chinese servers 11:26 < bridge> They don't responsibility dispose of nuclear waste 11:26 < bridge> Leading to higher chances of cosmic rays 11:26 < bridge> Well not cosmic anymore 11:27 < bridge> For reasons of not getting smote by the Chinese government, that's was a /j 11:30 < bridge> They responsibly dispose it right into our server it seems 11:31 < bridge> Cosmic rays would be even rarer, maybe some kind of network issue edge case? 11:32 < bridge> I doubt it's a network issue, the files are transferred over with rsync, over tcp, at both layers there are checksums 11:32 < bridge> It's more likely that the file was created wrong to begin with 11:34 < bridge> do they appear 'at the same place' meaning is there some pattern to it? (Is that the Imhex pattern you're talking about?) 11:34 < bridge> The Imhex pattern is basically a rudimentary teehistorian parser, that marks in the hex editor all the chunks 11:37 < bridge> There doesn't really seem to be much of a pattern to where it happens 11:38 < bridge> we don't have any OS info or something do get stats about? :justatest: 11:39 < bridge> CHINA wants the monopoly on spyware. They have their own working teehistorian and corrupt yours 11:41 < bridge> It seems to somehow be a "malformed" PlayerDiff item 11:42 < bridge> The only pattern I've noticed is that it's always amongst other playerdiff items where I get the broken item 11:44 < bridge> Chn servers have hdd filled up twice recently 11:45 < bridge> FYI 11:45 < bridge> Actually that might do it 11:46 < bridge> Gets filled up, writes fail, we don't disable teehistorian, we get these malformed files that seemingly keep going normally 11:46 < bridge> After write failure the server should be dead tho 11:47 < bridge> Which is the case of the last two incidents 11:47 < bridge> Hm, how dead? Completely restarted? 11:48 < bridge> When you vote to change map, it tries to flush teehistorian and fails and don't start anymore 11:48 < bridge> Prompts cannot write teehistorian file or something 11:48 < bridge> And anyone cannot connect anymore 11:53 < bridge> But the server keeps running, right? I wonder what happens when the disk has space 11:53 < bridge> Also these issues are very hard to debug when there are millions and millions of ticks in there 11:54 < bridge> Like not many tools handle this well 12:00 < bridge> Another thing I noticed is that as the files get larger it's more likely they are broken: 12:00 < bridge> `141625e2-904c-4cbc-ad71-178aac2dd91c.teehistorian: Teehistorian(PlayerDiffWithoutNew)` this is a 1.2G one 12:11 < bridge> I assume the fwrite calls will fail and only write as much as possible. We don't check the result in many places so I guess it just assumes that it was written correctly. More correct would be to retry the write and if it fails repeatedly then shutdown the server to prevent malformed teehistorian files. 12:13 < bridge> I would rather just stop recording the teehistorian file instead of killing the entire server as I said in #5670 12:13 < bridge> https://github.com/ddnet/ddnet/issues/5670 12:14 < bridge> Perhaps even try seek back a little and write a special pattern in the file to mark that the file is truncated due to a write issue 12:40 < bridge> https://www.csoonline.com/article/3963190/cve-program-faces-swift-end-after-dhs-fails-to-renew-contract-leaving-security-flaw-tracking-in-limbo.html 12:40 < bridge> @learath2 look! vulnerabilities no more! its safe to use C now 12:41 < bridge> they will dissolve CVE 12:41 < bridge> there is a eu one tho https://euvd.enisa.europa.eu/ 12:42 < bridge> kek Web site created using create-react-app 12:42 < bridge> https://osv.dev/ 12:43 < bridge> Elon is saving the govt billions oer year wooo 13:04 < bridge> :justatest: 13:16 < ws-client> I just found some old gem while cleaning my flat xd 13:17 < ws-client> Back in the days I decided to print out the entire openCV cpp documentation in color ... who knows why 13:17 < ws-client> https://zillyhuhn.com/cs/.1744802189.png 13:17 < ws-client> any recommendations what to do with it? xd 13:17 < bridge> read it 13:18 < ws-client> kek 13:18 < bridge> Donate it to the kindergarten, so they have paper to draw on 13:19 < ws-client> actually good recommendation jupstar 13:19 < ws-client> maybe the accidentally learn opencv 13:19 < bridge> donate it to the kindergarten, so they can learn openCV 13:19 < bridge> Burn it all with fire 13:19 < bridge> fock 13:54 < bridge> Yoo nice can i have em chiller? xd 13:54 < bridge> Or is it outdated already 14:31 < ws-client> @teero777 its giga outdated but sure come pick it up your are invited to tonights cooking night again! 14:32 < ws-client> @avolicious i have the feeling your initial chat delay breaks my login. Initial chat delay should not be applied for login commands. 14:40 < ws-client> oh my login request is pending forever maybe thats the issue 14:43 < ws-client> @zhn is he trolling me? "we call a person playing with a cheat natural" 14:54 < bridge> what's a good tool to navigate in git blame output ? Like go back one commit after i've found the line ? 14:55 < bridge> i think tig 14:59 < bridge> ah yes, thank you 🙂 14:59 < bridge> just need to find the keyboard shortcut to go back one commit now : 14:59 < bridge> just need to find the keyboard shortcut to go back one commit now 😄 15:00 < bridge> okya, it's ',' 15:38 < bridge> I should try tig for that! I use GitHub or GitHub wrappers for that .\_. 15:56 < bridge> It applies for everything, an exclusion for commands is currently not GA only dev 16:00 < ws-client> whats GA 16:01 < ws-client> maybe not all commands you dont want /rank spammers 16:01 < ws-client> but ideally login should be whitelisted and then unlock the chat too 16:02 < ws-client> "One of our engineers came across your profile as the contributor to Github daily trending project [..] and thought to reach out!" 16:02 < ws-client> common chiller gh influencer moment 16:02 < bridge> wasnt there a scam going around with something similar? 16:02 < ws-client> with what? 16:03 < bridge> something something github contributor invitation closed source ssh key 16:03 < ws-client> missed that 16:03 < ws-client> but i noticed that if you spam gh contributions into the void some people will mail you :D 16:03 < bridge> :kek: 16:09 < bridge> ppl mail me 16:09 < bridge> cuz gh 16:09 < bridge> can anyone take a look at #10078 as it's a bugfix for my merge yesterday 🙈 just 4 lines of code 16:09 < bridge> https://github.com/ddnet/ddnet/pull/10078 16:10 < bridge> donete 16:11 < bridge> thankete :owo: 17:46 < bridge> in regard to my c toolchain problem from yesterday, I needed to set the ACLOCAL_PATH to point /usr/share/aclocal which contains a pkg.m4 file which is part of the system's pkg-config. 17:46 < bridge> and that file defines the macro 17:50 < ws-client> @jxsl13 cring why does it not find it on its own? 17:50 < bridge> because I build my own toolchain probably 17:50 < bridge> which is located at /usr/local 17:50 < bridge> and not at /usr 17:51 < ws-client> ln -s /usr/local /usr 17:51 < bridge> noo 17:51 < bridge> that's intentional 17:52 < bridge> to prevent my built software to even remotely think about having any system dependencies 👀 17:52 < bridge> might be a wrong approach, who knows 17:52 < bridge> to not even think* 17:53 < bridge> but here I needed the system's pkg-config cuz I am not going to compile pkg-config from scratch 18:27 < bridge> they stole mah job! ( i wrote 100 loc and let it rot for hours) 18:27 < bridge> they stole mah job! ( i wrote 100 loc and let it rot for weeks) 18:31 < bridge> tja 18:32 < bridge> fill tool sounds hot 18:32 < bridge> ctrl+right click aswell 18:32 < bridge> and oh mah gawd destructive mode 18:34 < bridge> dunno how useful it is, but yeah it's fun xd 18:34 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1362103828543177005/Bildschirmaufnahme_20250416_183332.webm?ex=68012d8b&is=67ffdc0b&hm=7feec1b70ccac5f8ba9bc0a25fd5de949facdb00c3cb312b08f3902530b0b090& 18:34 < bridge> holy 18:34 < bridge> you dont understand HOW useful this is for certain things 18:34 < bridge> agree 18:34 < bridge> you dont understand HOW useful this is for certain things ???? 18:35 < bridge> like what 18:35 < bridge> when remove ddnet-rs and just call it ddnet-editor and ship it with the regular client as a standalone? 18:35 < bridge> :cat_cracked_hehe: 18:35 < bridge> xdd, ddnet editor still has some features that ddnet-rs does not have tho 18:36 < bridge> But it's close now 18:36 < bridge> given its a bucket tool, imagine us using that on the 2025 photoshoot map 18:36 < bridge> it for sure could've saved time 18:37 < bridge> ohhh its a bucket tool 18:37 < bridge> i thought it was just a selection thing 18:37 < bridge> a combination of paint and minesweeper in one. 18:37 < bridge> sounds good 18:37 < bridge> lowkey i still wanna make automapper turing complete 18:38 < bridge> ddnet's automapper? 18:38 < bridge> or the format 18:38 < bridge> :kek: 18:39 < bridge> ddnet-rs has wasm auto mapper support 18:39 < bridge> so it is xd 18:39 < bridge> :kek: 18:40 < bridge> wtf i randomly tried the bucket tool and it generated a mouse 18:40 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1362105475990159650/image.png?ex=68012f14&is=67ffdd94&hm=52ec2cb5f2871ef69c8a509f033dcabc5e9b295a3e87c14893c1e4f3ed54e346& 18:40 < bridge> I am such an ultra artist 18:41 < bridge> what does that mean 18:41 < bridge> But yeah the bucket tool defs needs some threshold value for tiles like this 18:41 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1362105747001049369/image.png?ex=68012f54&is=67ffddd4&hm=7621306636b6167701414282813f3a933db35ecb929e3ad27c7c4379770f8c07& 18:42 < bridge> that means it can run rules that are literally whole programs 18:44 < bridge> Can it run doom? Yes it can, if you fire up the auto mapper manually, every "run automap" can generate a new frame 18:44 < bridge> with the live-automap you could even simulate player input, since it has coordinates where you clicked the mouse 18:45 < bridge> i need to try this out 18:58 < bridge> Looks like konsti 19:05 < bridge> HOLY FUCK WHEN 19:07 < bridge> dunno half hour ago 19:09 < bridge> mouse with a huge ballsack 19:16 < bridge> its so goooooood need 19:55 < bridge> HOP ON DDNET-RS 19:56 < bridge> if someone makes this gif I will use every day 19:57 < bridge> mouse inflation 20:10 < bridge> holy shit u are a wizard 20:13 < bridge> hmm, bringing gimp toolbar to ddnet editor 🤔 20:14 < bridge> make ddnet a better image editor than gimp 20:15 < bridge> can't automap an image 20:15 < bridge> already better than Gimp 20:15 < bridge> i see 20:15 < bridge> we just need a python Integration and then it's turing complete :justatest: 20:16 < bridge> :saddo: 20:16 < bridge> technically we have that with twmap but external 21:34 < bridge> i see that we move `dbg_msg` to `log_error`, but i'm curious why and how that started 21:35 < bridge> they seem to do the exact same thing, just different syntax - and given we still use `dbg_assert` for example i'm curious ._. 21:35 < bridge> `log_*` functions have multiple log levels so you can filter the output, `dbg_msg` is always info level 21:35 < bridge> they seem to do the exact same thing,- and given we still use `dbg_assert` for example i'm curious ._. 21:36 < bridge> oh so its log_info log_error log_trace etc? 21:36 < bridge> okay yeah that makes much more sense 21:36 < bridge> also dbg_ prefix sux for stuff that is not compiled away in release mode xd 21:36 < bridge> same with dbg_assert 21:38 < bridge> @teero777 21:38 < bridge> > my first thought was a shop to pay admins to merge your prs 21:38 < bridge> 21:38 < bridge> That's horrifying 21:38 < bridge> assertions in release code would be interesting 21:39 < bridge> wait is dbg_ not compiled away? 21:39 < bridge> yes 21:39 < bridge> that is already the case 21:39 < bridge> 🫣 21:40 < bridge> asserts are fine, it's just the name that sucks 21:40 < bridge> huh 21:40 < bridge> also _if_ you want to do expensive asserts for debug only would be nice to have that 21:40 < bridge> there are non dbg_ asserts? 21:40 < bridge> do we have macros for release/debug detection? 21:41 < bridge> yea 21:41 < bridge> I actually will need one for optimization 21:41 < bridge> i think even in std 21:41 < bridge> hm 21:41 < bridge> would be nice if you keep such code low 21:42 < bridge> yes but fps are holy for some ppl. I don't know how to force a compiler optimization 21:43 < bridge> usually there are other ways to get more fps 21:43 < bridge> Well I otherwise need to write the code myself but it's kinda ugly 21:43 < bridge> e.g. optimize smth that is slow in the profiler 21:43 < bridge> yeah it's a hot path 21:44 < bridge> I don't understand what you want that a debug macro would help 21:44 < bridge> more context! 21:44 < bridge> setting the unreachable code attribute in release mode else dbg_assert 21:45 < bridge> just use assert 21:45 < bridge> asserts are unreachable code 21:46 < bridge> or simply use unreachable if that is std 21:46 < bridge> `dbg_assert(false, ...)` is already no-return, but some compilers don't know that so you need `dbg_break` as well 21:46 < bridge> RenderTilesetWithBuffering is a switch and a hotpath and I want to make sure the compiler makes a O(1) function array optimization with it 21:46 < bridge> it probably does 21:47 < bridge> does it for unsorted keys in the range from -1 to 5 with a fallover and a default with dbg_assert? 21:47 < bridge> I also prefer real `dbg_assert` to detect bugs instead of invoking undefined behavior 21:48 < bridge> i can tell you that whatever you do currently is not the hottest path 21:48 < bridge> if you want more fps optimize somewhere else first 21:48 < bridge> With C++20 we could mark the case as `[[unlikely]]` as well I guess 21:48 < bridge> please point him to a location to optimize 👀 21:48 < bridge> Make network theaded on Windows :justatest: 21:49 < bridge> 😂 21:49 < bridge> This will be a cpu optimization and we at least both measured some benefit in fps @jupeyy_keks 21:49 < bridge> when will we make the jump to c++20 anyway 21:49 < bridge> i remember ryo's PR which was closed 21:50 < bridge> more constructive optimization answers pls. just saying no is not constructive :/ 21:50 < bridge> It all depends on the oldest debian version that deen builds the releases on 21:50 < bridge> but I must admit that there are multiple changes and this is just one possible 21:50 < bridge> oh boi I habe a Debian 7 docker container with glibc 2.13 21:51 < bridge> have 21:51 < bridge> is deen's older 😄 21:51 < bridge> yes but e.g. robytes suggestion is good. 21:51 < bridge> 21:51 < bridge> windows is like a factor of 2 slower than our linux runtime 21:51 < bridge> btw what is the GLEW backend? 🙈 21:51 < bridge> bcs kernel calls on windows are evil 21:51 < bridge> the "future" 21:51 < bridge> winapi 21:52 < bridge> 32 21:52 < bridge> .dll 21:52 < bridge> Debian 12 it seems https://github.com/ddnet/ddnet/issues/6552#issuecomment-1627069478 21:52 < bridge> that's bookworm? 21:52 < bridge> that's new 21:53 < bridge> 2 only :nouis: 21:53 < bridge> 2 only? :nouis: 21:53 < bridge> you got old stuff when you need to tell apt-get to use archived repos for fetching packages :kek: 21:53 < bridge> > I'm on Debian 10 which includes GCC 8 21:54 < bridge> :( 21:54 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1362154146400309520/image.png?ex=68015c68&is=68000ae8&hm=806bbc812a6e134f3d83b911eddd23e756e6409cc46617b7752ec5ced1b69cfa& 21:54 < bridge> and disable ssl cert verification, cuz your ca-bundle is outdated :kek: 21:54 < bridge> glibc is somewhat shit 21:55 < bridge> not gonna lie 21:55 < bridge> Sorry 2 on all PCs except Teeros, which apparently got optimized after being abandoned by intel 30 years ago 21:55 < bridge> hmm 21:56 < bridge> when you think teero codes in c99 for fun ,but its just his PC unable to run anything above glibc 1.09 21:56 < bridge> guess who optimized it :troll: 21:57 < bridge> im inlining glibc already for my usecases :monkalaugh: 21:58 < bridge> @teero777 static linking would give more performance 21:58 < bridge> i even tried to static link openmp, but it has weird deps 21:58 < bridge> ^ talk to me when you reach 600M tps single threaded ty 21:58 < bridge> static link + lto is killer 21:58 < bridge> statically link glibc 21:58 < bridge> the end boss 21:58 < bridge> no no i mean i take the glibc functions, inline them and take out the features that i don't want 21:58 < bridge> cursed 21:59 < bridge> "to run this, all you need is something that can write ./main into something that remotely looks like a console" 21:59 < bridge> im writing directly to your harddrive 22:00 < bridge> is it just ```#ifdef DEBUG```? We have a dbg_assert for example in RenderTileLayer which is called each frame for each tilelayer of a map 22:01 < bridge> sounds like a prime candiate for me 💀 22:01 < bridge> there is optimization potential in ddnet by statically linking stuff :0? 22:01 < bridge> is that what you are saying @jupeyy_keks ? 22:01 < bridge> ofc 22:01 < bridge> lto profits only from static linking 22:02 < bridge> 🤔 22:02 < bridge> But spoiler it won't be so much that you probs get more than 1-2% 22:02 < bridge> our self written algorithms are still the bottleneck 22:03 < bridge> hmm or CONF_DEBUG 22:03 < bridge> DDNet 22:03 < bridge> ``` 22:03 < bridge> Dynamic Section: 22:03 < bridge> NEEDED libfreetype.so.6 22:03 < bridge> NEEDED libSDL2-2.0.so.0 22:03 < bridge> NEEDED libdl.so.2 22:03 < bridge> NEEDED libvulkan.so.1 22:03 < bridge> NEEDED libGL.so.1 22:03 < bridge> NEEDED libnotify.so.4 22:03 < bridge> NEEDED libgdk_pixbuf-2.0.so.0 22:03 < bridge> NEEDED libgio-2.0.so.0 22:03 < bridge> NEEDED libgobject-2.0.so.0 22:03 < bridge> NEEDED libglib-2.0.so.0 22:04 < bridge> NEEDED libcurl.so.4 22:04 < bridge> NEEDED librt.so.1 22:04 < bridge> NEEDED libm.so.6 22:04 < bridge> NEEDED libpthread.so.0 22:04 < bridge> NEEDED libc.so.6 22:04 < bridge> NEEDED ld-linux-x86-64.so.2 22:04 < bridge> ``` 22:04 < bridge> ddnet-rs 22:04 < bridge> ``` 22:04 < bridge> Dynamic Section: 22:04 < bridge> NEEDED libx264.so.164 22:04 < bridge> NEEDED libm.so.6 22:04 < bridge> NEEDED libwayland-client.so.0 22:04 < bridge> NEEDED libasound.so.2 22:04 < bridge> NEEDED libgcc_s.so.1 22:04 < bridge> NEEDED libc.so.6 22:04 < bridge> NEEDED ld-linux-x86-64.so.2 22:04 < bridge> ``` 22:04 < bridge> libz 22:04 < bridge> easy candidate 22:04 < bridge> ok that is probs only for map opening 22:04 < bridge> so not useful 22:04 < bridge> yea 22:04 < bridge> a starting point 22:04 < bridge> SDL2 is probs most useful for ddnet 22:04 < bridge> maybe also freetype 22:04 < bridge> the only useful stuff would be libc and libm xD 22:05 < bridge> what tool do you use for that section outputting? 22:05 < bridge> objdump -p 22:05 < bridge> k, ty 22:07 < bridge> @teero777 https://musl.libc.org/ 22:07 < bridge> hehe 22:07 < bridge> :OMEGALUL: 22:07 < bridge> curl looking at you like `http: https://master3.ddnet.org/ddnet/15/servers.json failed. libcurl error (6): Could not resolve host: master3.ddnet.org` 22:08 < bridge> already saw 22:08 < bridge> there is `musl-clang` 22:08 < bridge> xd 22:08 < bridge> epyc gemer moment 22:10 < bridge> there is a musl - glibc translation layer somewhere flying around on alpine linux ._. 22:37 < bridge> ``` 22:37 < bridge> DDNet.js:3667 Uncaught RuntimeError: unreachable 22:37 < bridge> at DDNet.wasm.a_crash 22:37 < bridge> at DDNet.wasm.__stack_chk_fail 22:37 < bridge> at DDNet.wasm.CCommandProcessorFragment_OpenGLES3::Cmd_Init(CCommandProcessorFragment_GLBase::SCommand_Init const*) 22:37 < bridge> at DDNet.wasm.CCommandProcessorFragment_OpenGLES::RunCommand(CCommandBuffer::SCommand const*) 22:37 < bridge> at DDNet.wasm.CCommandProcessor_SDL_GL::RunBuffer(CCommandBuffer*) 22:37 < bridge> at DDNet.wasm.CGraphicsBackend_Threaded::RunBufferSingleThreadedUnsafe(CCommandBuffer*) 22:37 < bridge> at DDNet.wasm.CGraphicsBackend_Threaded::RunBuffer(CCommandBuffer*) 22:37 < bridge> at DDNet.wasm.CGraphicsBackend_SDL_GL::Init(char const*, int*, int*, int*, int*, int*, int, int*, int*, int*, int*, IStorage*) 22:37 < bridge> at DDNet.wasm.CGraphics_Threaded::IssueInit() 22:37 < bridge> at DDNet.wasm.CGraphics_Threaded::InitWindow() 22:37 < bridge> ``` 22:37 < bridge> :pepeW: 22:48 < bridge> mhh, sad that it is so hard 22:49 < bridge> yeah, I have a list of more than 10 emscripten issues that have been closed as stale often without a solution available 22:52 < bridge> downgrade to whatever version i used back then xDD 22:52 < bridge> stale closing is actually so stupid 22:52 < bridge> it's funny so many repos do it 22:52 < bridge> Maybe also impossible with SDL2 alone. Tried to backport two relevant PRs from SDL3 to SDL2. Also made the graphics non-threaded. Launch then fails with 22:52 < bridge> ``` 22:52 < bridge> I gfx: Created OpenGL ES 3.0 context 22:52 < bridge> I gfx: Unable to create graphic context: Could not create webgl context 22:52 < bridge> I gfx: out of ideas. failed to init graphics 22:52 < bridge> E client: couldn't init graphics 22:52 < bridge> ``` 22:52 < bridge> Also had to fix a bug still present in SDL3 to even get the error message `Could not create webgl context` because they handle a return value incorrectly. 22:54 < bridge> So `PROXY_TO_PTHREAD` is not an option? 22:54 < bridge> for me it at least solved the hanging issue, but the toolchain file also mentions that SDL2 has to fix smth with it (whatever that was xd) 22:55 < bridge> I ported two PRs from SDL3 that seems to fix the pthread stuff for SDL. And `PROXY_TO_PTHREAD` fixed the hanging for HTTP. Together with that and making the graphics threaded the webgl context creation fails for unknown reason. 22:56 < bridge> Without `PROXY_TO_PTHREAD` I get a context and black screen but the above crash 22:56 < bridge> Without `PROXY_TO_PTHREAD` (and by removing HTTP init) I get a context and black screen but the above crash 22:56 < bridge> @jupeyy_keks is there anyway to make my dummy reset when i switch? 22:56 < bridge> like not hold down inputs when i switch 22:57 < bridge> on ddnet-rs 22:57 < bridge> not yet 22:57 < bridge> With `-O1` I get a bit more debug log, but the operator delete is never used in this function: 22:57 < bridge> ``` 22:57 < bridge> DDNet.js:3667 Uncaught RuntimeError: memory access out of bounds 22:57 < bridge> at DDNet.wasm.emscripten_builtin_free 22:57 < bridge> at DDNet.wasm.operator delete(void*) 22:57 < bridge> at DDNet.wasm.operator delete(void*, unsigned long) 22:57 < bridge> at DDNet.wasm.CCommandProcessorFragment_OpenGLES3::Cmd_Init(CCommandProcessorFragment_GLBase::SCommand_Init const*) 22:57 < bridge> ``` 22:57 < bridge> I still have the old ddnet-libs for wasm xD 22:58 < bridge> how hard would it be for a person that doesnt know rust to imploment it? 22:58 < bridge> mhh probably not too hard™️? 22:58 < bridge> 22:58 < bridge> you just release all keys? 22:58 < bridge> yea 22:58 < bridge> release hook 22:58 < bridge> fire 22:59 < bridge> jump 22:59 < bridge> left and right 22:59 < bridge> gimme 5 min 22:59 < bridge> also a command to make your dummy reset would be nice 22:59 < bridge> what is that? 23:00 < bridge> so u can make it stop holding all inputs 23:00 < bridge> when your not controling it 23:00 < bridge> when your not controlling it 23:00 < bridge> without switching? 23:00 < bridge> ye 23:00 < bridge> then why not only add that? 23:00 < bridge> true 23:00 < bridge> because ddnet has option for both 23:00 < bridge> i guess to make binds less complex 23:00 < bridge> yeah, but i prefer only have one solution to one problem 23:01 < bridge> go fore it 23:01 < bridge> go for it 23:02 < bridge> The problem with `PROXY_TO_PTHREAD` and rendering in a thread is also that you can only use the canvas from one thread and you need to enable offscreen canvas support which just doesn't seem to be implemented by anyone 23:02 < bridge> dummies in ddnet-rs are too op anyway (tho e.g. the dummy_hook in ddnet is completely broken, since it always tripple fly like a cheat) 23:02 < bridge> yea 23:03 < bridge> in ddnet-rs you can make your dummy aim at you and hook 23:03 < bridge> But we don't even render in a thread 23:03 < bridge> you cant do that in ddnet 23:03 < bridge> i disabled the threaded stuff for wasm afaik 23:03 < bridge> But there's a separate thread started for commands? 23:03 < bridge> not that i am aware of 23:03 < bridge> it uses main thread 23:03 < bridge> if it's started then it's unused 23:04 < bridge> yeah, there was some ifdef for emscripten before, but that alone also causes crashes now 23:04 < bridge> i tried to replicate that in ddnet, but instead of allowing the hook cheat it allows tripple fly.. 23:04 < bridge> 23:04 < bridge> So I kinda hate both xDD 23:04 < bridge> but I fixed that by removing all the thread related stuff from the backend 23:04 < bridge> yeah, there was some ifdef for emscripten before, but that alone also causes hangs now 23:04 < bridge> yeah, there was some ifdef for emscripten before, but that alone also causes hangs now because you are still starting and waiting for the thread 23:05 < bridge> compiling with ASAN now 23:05 < bridge> tripple fly is thing u cant really stop if you have copy moves 23:07 < bridge> But the ppl don't use copy moves 23:07 < bridge> they use the broken cl_dummy_hook 23:07 < bridge> which for whatever reason always hooks down 23:07 < bridge> they do use copy moves 23:07 < bridge> Mh 23:08 < bridge> it hooks in the direction you set it to 23:08 < bridge> In any case, this is just a massive cheat 23:08 < bridge> for that alone we should ban all existing ddnet clients 23:09 < bridge> i kinda made a fix for dummy_reset 23:09 < bridge> it just binds all actions 23:09 < bridge> and it acts as it 23:09 < bridge> remove dummy 23:09 < bridge> note: if you are planning on banning current clients i'd like to fix some exploits 23:10 < bridge> `bind e +dummy.hook;+dummy.left;+dummy.right;+dummy.jump;+dummy.fire;echo dummy reset!` 23:10 < bridge> xd 23:16 < bridge> no dummy servers when 23:24 < bridge> @alw5 cl_dummy_resetonswitch also works on player? 23:25 < bridge> 1 = dummy 23:25 < bridge> 2 = player 23:25 < bridge> yea 23:25 < bridge> 2 means 23:25 < bridge> when you switch the player 23:25 < bridge> it resets 23:25 < bridge> inputs 23:25 < bridge> Made the first optimization draft, I think especually opengl 1 benefits since it doesn't do layercounting anymore 23:25 < bridge> so i can simply add a reset +reset_input 23:25 < bridge> yea 23:25 < bridge> which automatically exist for dummy 23:25 < bridge> ok 23:25 < bridge> +reset_input would be fine 23:25 < bridge> i can just make it toggle that when i switch 23:27 < bridge> check https://github.com/ddnet/ddnet/pull/3715 23:28 < bridge> yes 23:28 < bridge> and #1949 23:28 < bridge> https://github.com/ddnet/ddnet/pull/1949 23:41 < bridge> @alw5 https://github.com/ddnet/ddnet-rs/pull/107 23:41 < bridge> 23:41 < bridge> i think you have to use +reset_input to clear the dummy input since the toggle_dummy happens at a later time. So at the moment of reset it's still not the dummy 23:51 < bridge> `AddressSanitizer: nested bug in the same thread, aborting.` seems like ASAN doesn't work with Emscripten even though the documentation says it should be compatible 23:52 < bridge> is emscripten abandoned or smth. how can we have so many obvious issues xD 23:54 < bridge> I assume minimal examples would work but adding SDL makes it complex immediately 23:54 < bridge> Maybe try again after porting to SDL3 23:55 < bridge> Looks like SDL maintainers don't want to backport the fixes to SDL2 23:55 < bridge> mh ok, but shouldnt old sdl2 simply work? 23:55 < bridge> I tried the old SDL2 version at some point but that also didn't work 23:56 < bridge> did it simply not build or not work at runtime? 23:57 < bridge> Had the same issues as the newer SDL versions 23:57 < bridge> But I didn't test all combinations of the several workarounds I found 23:57 < bridge> Just making the graphics non-threaded entirely seems promising, except for this random crash 23:58 < bridge> The pthreads stuff kept getting changed in SDL and emscripten, maybe it only works in a specific old version of emscripten as well because they reverted something 23:59 < bridge> If the pthread stuff would work then graphics could just be threaded but GL context creation and usage is more complicated