01:08 <+bridge> [ddnet] @Learath2 could you look at / merge https://github.com/ddnet/ddnet-discordbot/pull/25 please? 03:32 <+bridge> [ddnet] @Learath2 it seems the easiest way to fix this particular problem would be to move the SnapFindItem method into the snapshot class and do the reverse lookup from the external type to the internal type and then compare each snapshot object with the internal type 03:32 <+bridge> [ddnet] (the current fix doesn't work if you look for extended snapshot objects) 03:33 <+bridge> [ddnet] I agree that in the long term, a hashmap of ((typeid, id) -> offset) in the snapshot would be nice, this doesn't break iteration because it's just an additional offset map 03:37 <+bridge> [ddnet] the approach in the PR works for vanilla types, which are the only ones we search for anyway(?) 03:37 <+bridge> [ddnet] but it breaks down if you search for extended net objects 03:41 <+bridge> [ddnet] with pr you mean https://github.com/ddnet/ddnet/pull/4300 ? 03:41 <+bridge> [ddnet] yes 03:41 <+bridge> [ddnet] can you explain why it breaks it? 03:42 <+bridge> [ddnet] okay, it doesn't fix the problem if you search for extended net objects 03:42 <+bridge> [ddnet] it does fix the problem if you search for vanilla net objects 03:42 <+bridge> [ddnet] (i.e. it doesn't break anything, it fixes half of the things (and maybe all of the things we care about?)) 03:42 <+bridge> [ddnet] yeah its there to minize the uuid lookup, currently only ddnet\_projectiles is the only one that uses snapfinditem and is uuid 03:43 <+bridge> [ddnet] the approach mentioned above works the same on non-extended net objects and has similar performance for extended ones (AFAICT) 03:44 <+bridge> [ddnet] i.e. translate the external type into the internal snapshot type (which is a no-op for vanilla snapshot types, and a one-time search for extended snapshot types) 03:44 <+bridge> [ddnet] i think the best would be to split the keys and have too snapfinditem branches 03:44 <+bridge> [ddnet] bcs the mapping is also only useful for uuid items 03:46 <+bridge> [ddnet] two\* xd 03:46 <+bridge> [ddnet] which mapping? 03:46 <+bridge> [ddnet] but yeah i agree the mapping could be useful 03:46 <+bridge> [ddnet] 03:46 <+bridge> [ddnet] and generally having binary search too 03:46 <+bridge> [ddnet] mapping from external type to snapshot type 03:46 <+bridge> [ddnet] or extended typ to external type to be precise 03:47 <+bridge> [ddnet] this approach doesn't need said mapping 03:47 <+bridge> [ddnet] at least not in an efficient way 03:48 <+bridge> [ddnet] it's an optimization. instead of looking up the external type of each item, it translates the external type we're looking for into the internal type so each item type comparison is a cheap integer comparison 03:48 <+bridge> [ddnet] yeah 10:45 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/906116969114271754/unknown.png 10:45 <+bridge> [ddnet] Windows 11 can run linux version of ddnet now 10:45 <+bridge> [ddnet] mouse doesn't work tho 10:45 <+bridge> [ddnet] heh, that's cool 10:46 <+bridge> [ddnet] Didn't know WSL supports X11 10:46 <+bridge> [ddnet] ye it just did 10:47 <+bridge> [ddnet] it is gpu accelerated too apparently 10:49 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/906118099789574194/unknown.png 13:34 <+bridge> [ddnet] WSL runs graphical applications in Weston with an RDP backend 13:34 <+bridge> [ddnet] It sounds like a horrible idea but apparently it works well enough 16:52 <+bridge> [ddnet] I think 15.6 wasn't pushed on Steam yet? Running without beta only gives me 15.5.4 16:54 <+bridge> [ddnet] i think its rc only rn 16:54 <+bridge> [ddnet] yes, I reverted it since there were bugs 16:56 <+bridge> [ddnet] I'm waiting for https://github.com/ddnet/ddnet/pull/4300 and https://github.com/ddnet/ddnet/issues/4301 forthe release 16:58 <+bridge> [ddnet] I'll try to hotfix pnglite later today or tomorrow, but I don't mind if someone else wants to give it a try. Should be pretty straightforward 🙂 16:58 <+bridge> [ddnet] I'll try to hotfix pnglite usage later today or tomorrow, but I don't mind if someone else wants to give it a try. Should be pretty straightforward 🙂 17:03 <+bridge> [ddnet] I'll try 17:52 <+bridge> [ddnet] https://www.ncameron.org/rfcs/3123.html 17:52 <+bridge> [ddnet] they added this on nightly rust 17:52 <+bridge> [ddnet] :poggers: 18:06 <+bridge> [ddnet] @Learath2 a list with all the tiles with a direction is here https://gitlab.com/Patiga/twmap/-/blob/master/src/bin/check_ddnet.rs#L100 18:10 <+bridge> [ddnet] @Learath2 if you want to approach this: would you rather do it in python or rust? 18:15 <+bridge> [ddnet] :poggers: 18:17 <+bridge> [ddnet] I don't like the way the github bot looks when I add a new tag 18:21 <+bridge> [ddnet] rust ofc, may god never leave anyone in a situation where they are forced to use python 18:22 <+bridge> [ddnet] :poggers: 18:22 <+bridge> [ddnet] learath said it 18:22 <+bridge> [ddnet] I can filter tags if you want 18:22 <+bridge> [ddnet] but leave master on 18:22 <+bridge> [ddnet] and maybe stagging 18:22 <+bridge> [ddnet] But I never tag on master 18:22 <+bridge> [ddnet] ah its just for tags 18:23 <+bridge> [ddnet] Ah, actually I doubt it's the tag causing the message, isn't it more likely the branch? 18:23 <+bridge> [ddnet] i meant for when it shows new commits 18:23 <+bridge> [ddnet] ye 18:23 <+bridge> [ddnet] it shows new commits for x branch 18:23 <+bridge> [ddnet] just filter for master and stagging 18:23 <+bridge> [ddnet] Wait, you don't branch for rc's 18:23 <+bridge> [ddnet] staging* 18:23 <+bridge> [ddnet] Um, where do you tag these @deen ? 😄 18:24 <+bridge> [ddnet] maybe the fault is that I tag them both in my fork and on upstream 18:46 <+bridge> [ddnet] https://therecord.media/gitlab-servers-are-being-exploited-in-ddos-attacks-in-excess-of-1-tbps/ 18:46 <+bridge> [ddnet] wew