02:17 < bridge> 🤓 02:21 < bridge> deen doesn't even approve prs anymore 💔 02:21 < bridge> unless it's roby's 02:22 < bridge> bro has a job and a kid 🙏 03:10 < bridge> I was thinking about this. Does the client correctly handle player ID mapping as it is currently? There's some amount of state that gets saved to each client, but if you're mixing the client IDs then the client will mix the state from other clients. 03:12 < bridge> I guess this doesn't have any major effects right now but it's a new constraint that the client didn't have before 03:19 < bridge> unless I'm blind and I'm missing somewhere that the ``CClientData`` for each client gets reset ID mapping is a rather terrifying prospect because the client seems to just assume that the ``CClientData m_aClients[MAX_CLIENTS];`` array is always stable. 03:19 < bridge> unless I'm blind and I'm missing somewhere that the ``CClientData`` for each client gets reset, ID mapping is a rather terrifying prospect because the client seems to just assume that the ``CClientData m_aClients[MAX_CLIENTS];`` array is always stable. 08:20 < bridge> real gamers would join me on nujabes rn 09:39 < ws-client> i sent a vital message from antibot and got no response from the client? Happend like 2 out of 80 times. Is that technically possible or am i stupid? 09:39 < ws-client> the net message sending goes through the main server and should be stored in the resend backup buffer. If the client does not ack the vital message the server should automatically resend right? 09:40 < bridge> udp is udp 09:40 < bridge> packet loss go brr 09:40 < ws-client> yes 09:40 < ws-client> but resend 09:40 < bridge> or do vitals get resend 09:40 < ws-client> yes 09:40 < bridge> oke 09:40 < ws-client> but sometimes during stronger lags i feel like even chat messages get lost somtimes 09:41 < ws-client> not sure if my assumptions about resend reliability were correct 09:59 < ws-client> i just merged 2 commits into chillerbot and get cp on join gg 10:02 < ws-client> i dont get it @robyt3 sos 10:03 < ws-client> ddnet master works fine for me but in my fork i get instant connection problems when joing a server 10:03 < ws-client> reverting https://github.com/ddnet/ddnet/pull/10383 fixes it 10:03 < ws-client> it merged without conflicts skimming the pr i dont see what i missed. Do i need to apply some changes somewhere? 10:04 < bridge> "cp"? 10:04 < bridge> connection problems 10:07 < bridge> ChillerDragon: what server did you join 10:07 < ws-client> my fng 10:07 < ws-client> lemme try other 10:08 < ws-client> yea i basically cant stay online on any server for longer than 1 tick 10:08 < ws-client> how does that make any sense? 10:08 < ws-client> i dont recall editing any interesting in my client that should be related to such low level networking 10:17 < ws-client> this is my entire diff to ddnet how can the networking break in my client? https://paste.zillyhuhn.com/xd @robyt3 10:23 < ws-client> the most crazy thing i pull in is curses but even unlinking that does not help 10:41 < bridge> Are you sure you merged it completely? The only files you changed that seems relevant are probably `client.h/cpp` and `system.h/cpp`. Did you change anything network related there? 10:43 < bridge> Did you change `NETTYPE` constants maybe and now a value is duplicated? 10:45 < bridge> Being able to connect but not stay is weird though, no idea how this low-level change cause such a high level problem. 10:45 < ws-client> the network traffic also looks healthy at first glance 10:46 < ws-client> my diff in system.h/cpp is as simple as it gets its only 2 lines for logger 10:47 < ws-client> wdym merged completley? ``git merge`` just ran through 10:48 < bridge> I mean without conflicts and potentially losing changes during conflict resolution 10:48 < ws-client> no there was no conflict 10:48 < ws-client> because all the network stuff is untouched 10:50 < bridge> hmm, you might have to add some more detailed log messages to figure out what breaks. I don't see how this PR would effect it at such a high level, as it doesn't change anything about the protocol. It only removed a branch for websockets from the network server, but websockets should be irrelevant for you. 10:50 < ws-client> my client.h diff is also tiny af 10:50 < ws-client> yea it makes no sense to me either @robyt3 10:50 < ws-client> not sure what to log 10:51 < bridge> Try to figure out which is the first message that is broken or the last message that works 10:51 < bridge> I guess wireshark would be useful 10:51 < ws-client> wireshark looks good 10:51 < ws-client> how do you define broken in that context? 10:51 < bridge> When you get connection problems 10:52 < bridge> Is there no noticable change in wireshark? 10:52 < ws-client> at first glance it looks good 10:52 < ws-client> i send inputs and get snaps 10:52 < ws-client> https://zillyhuhn.com/cs/.1750323159.png 10:53 < ws-client> i tested ipv6 and ipv4 no diff 10:53 < bridge> Have you tried ASAN/UBSAN/Valgrind already? Maybe some undefined behavior surfacing now for some reason. 10:53 < ws-client> nah 10:53 < ws-client> lemme try 10:54 < ws-client> i wish i could revert the pr line by line and test but its such a big refactor 10:55 < ws-client> i thought somehow removing the ``struct`` unlocked some wonkeyness cuz i linked curses or something like that 10:55 < bridge> I tried to split non-websocket changes, but in the end it wasn't really worth it 10:56 < ws-client> uhm ... 10:56 < ws-client> asan works 10:56 < ws-client> as in no cp 10:56 < ws-client> xxxxxxxxxxxxxxD? 10:56 < bridge> :justatest: 10:56 < ws-client> lemme delete build dir 10:57 < ws-client> ok nvm now other works too 10:57 < ws-client> i messed something up 10:58 < bridge> It's not very new tbh. Large servers have been mapping ids forever now 10:58 < ws-client> wait was this really a cmake/make error? 10:58 < ws-client> i had it going back and forth with reverting and resetting the commit 10:58 < ws-client> in a fork and a fork of a fork 10:58 < ws-client> ??? 10:59 < bridge> Maybe it was an entirely unrelated network problem that has also been fixed 11:00 < ws-client> okay so in my fork of the fork i reverted the revert and i can still reproduce xd 11:00 < ws-client> lemme try make clean 11:01 < ws-client> didnt help 11:01 < ws-client> hm maybe its release vs debug 11:02 < ws-client> yes it is 11:02 < ws-client> its not cmake cache issue 11:02 < ws-client> its a release only issue 11:02 < ws-client> ok asan with relwithdebinfo it is then 11:04 < ws-client> issue does not exist in relwithdebinfo either? 11:05 < ws-client> ????????????????? 11:05 < bridge> Does relwithdebinfo use full optimizations? 11:05 < ws-client> idk i always thought its the ultimate hack for release only bugs 11:05 < ws-client> ok i have some interesting NEWS 11:05 < ws-client> good for 11:05 < ws-client> bad for u 11:06 < ws-client> i can reproduce on ddnet master 11:06 < ws-client> the only difference was my ddnet build was debug and my chillerbot gaming build was release 11:06 < ws-client> so i blamed my fork 11:08 < bridge> I had a weird issue that I needed to debug in the Ubuntu CI where the compiler in release mode with stack protector found an out-of-bounds memcpy that did not make sense in `sockaddr_to_netaddr`. I fixed it by using `sockaddr_storage` for the addresses, which was apparently previously overshadowed by much larger char buffer. 11:13 < ws-client> lets increase our CI times from 200 minues to 400 minutes to also cover release only bugs xd 11:13 < bridge> LOL no way its actually bound to release 11:13 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1385185742090797106/image.png?ex=68552640&is=6853d4c0&hm=8402c61d973921f0dc5edb190244e0b5b3cfff5759d919f97ebb168141b778d3& 11:13 < bridge> can reproduce kekekekekek 11:14 < ws-client> we burned down half the amazonas with the bloat ass CI that has full on integration end to end big ass tests and somehow a bug that makes connecting impossible slipped through? 11:14 < ws-client> such a waste 11:14 < bridge> xd 11:14 < bridge> Yeah but that's not the same as supporting it as an official feature. It happens to work fine right now without and visible issues because none of the features are too sensitive too it 11:14 < bridge> Yeah but that's not the same as supporting it as an official feature. It happens to work fine right now without any visible issues because none of the features are too sensitive too it 11:15 < ws-client> @blaiszephyr i used to do gaming in debug mode when my client had crashes. But now i use release mode to increase my tw skill by 20% 11:15 < bridge> (i always build in debug because i want to know when stuff goes boom) 11:16 < bridge> Real pros play with valgrind 11:17 < ws-client> jupstar 2fps enjoyer confirmed 11:21 < bridge> Is it really the clients that are broken? I think its the server 11:22 < bridge> Well it's not but if we break anything about it fokkonaut will show up and complain 11:22 < bridge> It works with server in relwithdebug and client in release 11:23 < bridge> can reproduce with release && releasewithdebinfo 11:23 < bridge> cant reproduce in debug 11:23 < bridge> can reproduce with release && releasewithdebinfo 11:23 < bridge> cant reproduce in debug (client only) 11:23 < bridge> Also somewhat broken for me on Windows with MSYS2 in release mode, but works in relwithdebug. When I keep connecting and disconnecting it sometimes gets stuck on the connecting screen and sometimes I get ingame and there is still an old player of me online. 11:23 < bridge> But Chiller says it breaks on any server, how can it be the servers fault? 11:24 < bridge> isnt, it crashes on Teeworlds source based servers aswell 11:24 < bridge> (blockworlds for example) 11:24 < bridge> yes exactly, you can't blame a server that hasn't been rebuilt in the last 5 years 11:24 < bridge> It crashes even? 11:25 < bridge> "timeouts*" 11:25 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1385188617512681531/image.png?ex=685528ed&is=6853d76d&hm=4baba7db616f6618c602b5ae05b67554a39d1df535cf911839cf8500defb6f04& 11:25 < bridge> wording paired with quick typing is hard - sorry 11:25 < bridge> Seems like the client works on Windows with MSYS2 but there are weird issues with the server 11:25 < bridge> consequences are very much faced, as long as ther eis an attempt to keep visible players the same id its fine 11:29 < bridge> I think it probably only works reasonably well because there's never a huge pile of 128 tees, if you were swapping clients close to every snapshot I think it would be visibily horrible 11:30 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1385189895974158426/image.png?ex=68552a1e&is=6853d89e&hm=90af0d23204f0de92f2aa1470916e99f3e3f62ac0cc02784f702d6b53d145a38& 11:30 < bridge> the client supports 128 tees anyway now 11:30 < bridge> well yeah 11:30 < bridge> but 256? 11:30 < bridge> i think the server would die 11:30 < bridge> it could handle it 11:30 < bridge> if it was good enough 11:30 < bridge> O(n^2) collisions go brrr 11:30 < bridge> those are not that hard to fix 11:31 < bridge> if you don't need flawless accuracy on your 256 player server you can have it fixed in a few minutes 11:31 < bridge> surely grid just works 11:31 < bridge> of width hook length / 2 or something 11:31 < bridge> yeah it does except for those rotating laser beam things 11:32 < bridge> the new ones? 11:32 < bridge> no 11:32 < bridge> you can check multiple points along the lazer 11:32 < bridge> :Sure: 11:32 < bridge> for potential tees 11:33 < bridge> you should check every half grid width just to be sure even though that will probably have duplicates 11:33 < bridge> (well if your lazer is near a 90 degree interval you can do every grid width) 11:33 < bridge> I mean it's either going to be O(n(tees) * n(lasers)) or it's going to be O(n(number of tiles the laser occupies)*n(tees)) 11:33 < bridge> (i doubt its much of a save) 11:34 < bridge> but most maps don't have a huge number of those so you can just leave it on the old physics 11:34 < bridge> the collision is done by a min distance to lazer < tee width 11:34 < bridge> which is O(1) per tee no matter the length 11:34 < bridge> (i hope) 11:34 < bridge> O(1) per tee, per laser = O(n*m) 11:34 < bridge> laser = n, tees = m? 11:35 < bridge> sure 11:35 < bridge> the thing we are trying to reduce is m by using a grid 11:35 < bridge> you only check tees on the grid spaces along points of the lazer 11:35 < bridge> looks to me like a range based kd tree 11:35 < bridge> i dont think it makes much of a difference 11:35 < bridge> the current collision? 11:36 < bridge> it's not that important, you can solve it in various ways 11:36 < bridge> idk why I brought it up 11:36 < bridge> it's just the most annoying part of O(n) physics 11:36 < bridge> a partitioning thing is harder and probably wont offer much benefit 11:36 < bridge> maps are quite small 11:37 < bridge> quad tree is overkill yeah 11:37 < bridge> just do what ddnet-rs does, direct array or hashmap if the map is really big 11:37 < bridge> yep 11:37 < bridge> oh no virtual call!!! 11:37 < bridge> grp not really 11:38 < bridge> you dont have to do it with oop xd 11:38 < bridge> virtual call? 11:38 < bridge> if(m_usinghaashmap)...else... 11:38 < bridge> mmm 11:38 < bridge> I think the hashing part is the slow part 11:38 < bridge> im oop pilled 11:38 < bridge> for just 2 small ints you can probably get a pretty good fast hash 11:38 < bridge> true ig 11:39 < bridge> not using standard containers would make a huge difference, but that difference is probably from the order of nanoseconds to less nanoseconds 11:39 < bridge> idk I'm endlessly annoyed that the std hash containers are 10-30x slower than every other implementation for seemingly no good reason 11:39 < bridge> why... are they like that 11:39 < bridge> I don't know 11:39 < bridge> unordered_map seems really minimal 11:40 < bridge> they are the worst containers the stl provides 11:40 < bridge> bye bye 11:41 < bridge> ChillerDragon: Do you also get large FPS drops when pressing the Disconnect button with the PR reverted? I confirmed that reverting it would fix it, but I noticed when I press the Disconnect button it hangs for a while. It doesn't hang in debug and relwithdebug modes. 11:41 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1385192730434469928/image.png?ex=68552cc2&is=6853db42&hm=50590d1af0219e1345eeb8e37607fb6bff2fb1c4f60ed83a4cbb3112898ed0e4& 11:51 < bridge> The delay was probably from websockets 12:06 < ws-client> @robyt3 im in a gores run now cant rly check :/ 12:07 < ws-client> how do you confirm can u reproduce on windows? 12:07 < bridge> It's fine, I think it was just from additionally adding websockets, which are TCP 12:07 < bridge> When connecting repeatedly to a server it doesn't work or I connect but my previous player is still connected 12:07 < bridge> I've reduced the problem to `1 file changed, 76 insertions(+), 65 deletions(-)` 12:09 < ws-client> yikes still a lot 12:10 < bridge> yeah, trying to split it into the last two somewhat separate changes 12:27 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1385204209699258449/image.png?ex=68553773&is=6853e5f3&hm=1f89ea8af1b022ea176427f8768fa6c995b5d7f4262b5970f347e4ab01a7d198& 12:27 < bridge> waiting a billion seconds for dummy to connect is not fun 12:29 < bridge> yes 12:29 < bridge> its not connecting idk y 12:29 < bridge> i cant play with hoomans if i wanted to cuz ping 12:29 < bridge> what happened to my spectate button? 12:29 < bridge> I ate it 12:29 < bridge> why 12:29 < bridge> i wanted that 12:29 < bridge> Yummy 12:29 < bridge> noo 12:30 < bridge> can you eat the dummy connection not working 12:30 < bridge> Not yummy 12:30 < bridge> ill give u spectate buttons if u do 12:30 < bridge> balanced diet 12:31 < bridge> Is it the ger10 or whatever number with the extra ddos protection 12:31 < bridge> ger1 12:31 < bridge> Idk 12:31 < bridge> i can connect fine 12:32 < bridge> connecting 2 clients is fine 12:32 < bridge> just no dummy 12:32 < bridge> connecting dummy on second client worked 12:32 < bridge> x-x 12:44 < bridge> I need some compiler experts. How does this patch fix the complex issue of not being able to connect? (#10384) 12:44 < bridge> 12:44 < bridge> ```patch 12:44 < bridge> static void sockaddr_to_netaddr(const sockaddr *src, socklen_t src_len, NETADDR *dst) 12:44 < bridge> { 12:44 < bridge> - *dst = NETADDR_ZEROED; 12:44 < bridge> + mem_zero(dst, sizeof(NETADDR)); 12:44 < bridge> if(src->sa_family == AF_INET && src_len >= (socklen_t)sizeof(sockaddr_in)) 12:44 < bridge> ``` 12:44 < bridge> https://github.com/ddnet/ddnet/issues/10384 12:58 < bridge> I mean there is potentially a 2-byte padding in NETADDR which is not zero with the NETADDR_ZEROED 12:58 < bridge> But I dunno, makes no sense to me 12:59 < bridge> I checked with mem_comp and they should both be identical 12:59 < bridge> Might be strict aliasing because using sockaddr is always undefined behavior apparently 13:02 < bridge> Do asan&ubsan not find the issue here or what? 13:03 < bridge> It doesn't happen without optimization I think 13:03 < bridge> If it did, it should have caught it in the CI 13:21 < bridge> https://i.imgur.com/U6CMP9y.png 13:21 < bridge> I thought if I added someone as friend its shows only if name + clan is the same? 13:21 < bridge> Now its shows me all who have the same name but not the same clan? 13:21 < bridge> 13:21 < bridge> Is that a bug? 13:21 < bridge> 13:21 < bridge> @Deleted User stop bot :troll: 13:24 < bridge> 1) Declares an unscoped enumeration type whose underlying type is not fixed (in this case, the underlying type is an implementation-defined integral type that can represent all enumerator values; this type is not larger than int unless the value of an enumerator cannot fit in an int or unsigned int. If the enumerator-list is empty, the underlying type is as if the enumeration had a single enumerator with value 0. If no integral type can repr 13:24 < bridge> https://en.cppreference.com/w/cpp/language/enum.html 13:24 < bridge> I think this is the issue 13:24 < bridge> I think this is the cause of the issue 13:26 < bridge> ``` 13:26 < bridge> enum 13:26 < bridge> { 13:26 < bridge> /** 13:26 < bridge> * The maximum bytes necessary to encode one Unicode codepoint with UTF-8. 13:26 < bridge> */ 13:26 < bridge> UTF8_BYTE_LENGTH = 4, 13:26 < bridge> 13:26 < bridge> IO_MAX_PATH_LENGTH = 512, 13:26 < bridge> 13:26 < bridge> NETADDR_MAXSTRSIZE = 1 + (8 * 4 + 7) + 1 + 1 + 5 + 1, // [XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX]:XXXXX 13:26 < bridge> 13:26 < bridge> NETTYPE_INVALID = 0, 13:26 < bridge> NETTYPE_IPV4 = 1 << 0, 13:26 < bridge> NETTYPE_IPV6 = 1 << 1, 13:26 < bridge> NETTYPE_WEBSOCKET_IPV4 = 1 << 2, 13:26 < bridge> NETTYPE_WEBSOCKET_IPV6 = 1 << 3, 13:26 < bridge> NETTYPE_LINK_BROADCAST = 1 << 4, 13:26 < bridge> /** 13:26 < bridge> * 0.7 address. This is a flag in NETADDR to avoid introducing a parameter to every networking function 13:26 < bridge> * to differenciate between 0.6 and 0.7 connections. 13:26 < bridge> */ 13:26 < bridge> NETTYPE_TW7 = 1 << 5, 13:26 < bridge> 13:26 < bridge> NETTYPE_ALL = NETTYPE_IPV4 | NETTYPE_IPV6 | NETTYPE_WEBSOCKET_IPV4 | NETTYPE_WEBSOCKET_IPV6, 13:26 < bridge> NETTYPE_MASK = NETTYPE_ALL | NETTYPE_LINK_BROADCAST | NETTYPE_TW7, 13:26 < bridge> }; 13:26 < bridge> ``` 13:26 < bridge> it seems to fit in 2 bytes 13:27 < bridge> idk 13:28 < bridge> Doesn't seem related to that enum to me 13:29 < bridge> Something is weird about the `NETADDR_ZEROED` though. It also works if I do `*dst = NETADDR_ZEROED2;` and initialize the variable with `mem_zero(&NETADDR_ZEROED2, sizeof(NETADDR_ZEROED2));` in `net_init`. 13:35 < bridge> How is NETADDR_ZEROED initialized? 13:36 < bridge> https://github.com/Robyt3/ddnet/tree/Testing-Netaddr 13:37 < bridge> It doesn't work if `NETADDR_ZEROED` is static const or extern const 13:37 < bridge> You can also attempt to observe the result. Observe the memory at dst. See what happens to it after assignment 13:38 < bridge> Hm, something about the way static initialization is done? It is a rather quirky thing 13:39 < bridge> But also related to optimization of the const value I guess 13:44 < bridge> Good idea, looks like there are garbage bytes at the end of the address sometimes 13:45 < bridge> So I guess @jupeyy_keks was right and it's padding 13:45 < bridge> So why is what is meant to be padding changing observable behaviour? 😄 13:46 < bridge> Because net address comparison considers the entire size of the NETADDR 13:46 < bridge> Ah 13:46 < bridge> Should we change the comparison or ensure the padding is zeroed? 13:47 < bridge> I wanted to replace all `mem_zero(addr, sizeof(NETADDR));` with `*addr = NETADDR_ZEROED;` separately 13:48 < bridge> Guess I should have done that first, which would have been easier to pinpoint 13:48 < bridge> Hm, I'd fix the comparison honestly, it is IMO fundamentally flawed 13:49 < bridge> But it might come at a performance penalty if the padding isn't one continuous block. Is it? 13:50 < bridge> Might impact performance if we reimplement the address comparison without mem_comp 13:51 < bridge> If the padding is one continuous block, the compiler should be smart enough to optimize it back up for us 13:55 < bridge> ```diff 13:55 < bridge> typedef struct NETADDR 13:55 < bridge> { 13:55 < bridge> unsigned int type; 13:55 < bridge> unsigned char ip[16]; 13:55 < bridge> unsigned short port; 13:55 < bridge> + unsigned char _padding[2]; 13:55 < bridge> 13:55 < bridge> bool operator==(const NETADDR &other) const; 13:55 < bridge> bool operator!=(const NETADDR &other) const; 13:55 < bridge> bool operator<(const NETADDR &other) const; 13:55 < bridge> } NETADDR; 13:55 < bridge> ``` 13:55 < bridge> 13:55 < bridge> ```diff 13:55 < bridge> - const NETADDR NETADDR_ZEROED = {NETTYPE_INVALID, {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, 0}; 13:55 < bridge> + const NETADDR NETADDR_ZEROED = {NETTYPE_INVALID, {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, 0, {0, 0}}; 13:55 < bridge> ``` 13:55 < bridge> Works for me. 14:04 < bridge> I guess that also works, but it's not exactly completely portable 14:05 < bridge> Yeah, adjusting the comparison functions is a lot cleaner 14:05 < bridge> Not like any of the implementations it wouldn't work on still exist, nor the rest of our code can cope with them 14:27 < bridge> if theres no padding between the elements 14:27 < bridge> ``` 14:27 < bridge> a.type == b.type && 14:27 < bridge> mem_cmp(a.ip, b.ip, sizeof(a.ip)) == 0 && 14:27 < bridge> a.port == b.port 14:27 < bridge> ``` 14:27 < bridge> should optimize down to a memcmp anyway 14:27 < bridge> or whatever a memcmp optimizes down to 14:46 < bridge> i made solid stoppers :) 14:46 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1385239415747641394/solid_stoppers.mp4?ex=6855583d&is=685406bd&hm=637aa45cce6d09c676547f26acf854bc8a84d2f9cfff98530d6d85d5a6102fb6& 14:48 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1385239733512179772/image.png?ex=68555888&is=68540708&hm=214d57eea39eb3e01feaee3721dd8e0035c35c1449a4c6c8a68d654cce7f620f& 14:48 < bridge> what happened to my name 14:49 < bridge> it doesnt and i have no clue why 14:49 < bridge> что делать если забанили до 12 а уже 15 14:49 < bridge> what 14:51 < bridge> #✉-create-a-ticket 14:51 < bridge> what to do if you're banned before 12 p.m. and it's already 3 p.m. 14:54 < bridge> Why do you get a coolname? 14:54 < bridge> it is gone 14:54 < bridge> sans didnt like the colors 14:54 < bridge> something less.. galring would be nice 14:55 < bridge> what to do if you're banned before 12 p.m. and it's already 3 p.m. 14:57 < bridge> #✉-create-a-ticket 15:03 < bridge> https://en.wikipedia.org/wiki/Coordinated_Universal_Time 15:07 < bridge> oh or that 15:07 < bridge> wow i dont get fancy name 15:07 < bridge> scam 15:07 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1385244706472071259/image.png?ex=68555d2a&is=68540baa&hm=3533b0a18f4489c94f7e13ed5159dcf6fc91c61002903e9393003b328a465e4c& 15:10 < bridge> @jupeyy_keks i have access to a Intel Xeon E-2386G (12) @ 5.100GHz server 15:10 < bridge> is that cpu special or smth 15:10 < bridge> yooo wtf happened to the dev role 15:10 < bridge> nice colors 15:10 < bridge> yoo 15:10 < bridge> im special lol 15:11 < bridge> :owo: 15:11 < bridge> epyc 15:11 < bridge> i wish i had one 15:11 < bridge> i also want a epyc 15:12 < bridge> just looked, the intel cpu is from 2021 15:12 < bridge> not special 15:12 < bridge> 5ghz in 2021 is dope tho 15:13 < bridge> Intel® SSE4.1, Intel® SSE4.2, Intel® AVX2, Intel® AVX-512 15:13 < bridge> it actually has avx 512 lol 15:14 < bridge> using avx512 can actually make my physics lib even faster but like only 0.5% of cpus support it so it doesn't make much sens 15:14 < bridge> using avx512 can actually make my physics lib even faster but like only 0.5% of cpus support it so it doesn't make much sense 15:15 < bridge> okay nvm it seems to have gotten up a bit 15:15 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1385246600812560464/image.png?ex=68555eee&is=68540d6e&hm=a88ac5e3f9fb75091dee558f939078c7a22df5faaa5137ef21cf866c9a73c675& 15:16 < bridge> there are ways to use simd if cpu supports via detection 15:16 < bridge> and fallbacks 15:17 < bridge> ffmpeg does it 15:17 < bridge> i have avx512 at home 15:17 < bridge> all new lines of amd do have it 15:17 < bridge> why is only devrole special 15:17 < bridge> the main reason is that my cpu doesnt support avx512 so i can't test it xD 15:17 < bridge> xd 15:17 < bridge> make it 15:17 < bridge> i test it 15:17 < bridge> yes im donwloading avx512 to my cpu 15:18 < bridge> yes im downloading avx512 to my cpu 15:18 < bridge> u can code without having the cpu xd 15:18 < bridge> download more ram 15:18 < bridge> well ofc i can but who knows if it works 15:18 < bridge> then i have to ask jupstar again 15:18 < bridge> wtf u got cool color on ur roles 15:18 < bridge> thats where i come 15:18 < bridge> i have avx512 i just said i can test for u 15:18 < bridge> kk 15:18 < bridge> :feelsbadman: 15:18 < bridge> when i do make i'll let you test 15:19 < bridge> when i do make it i'll let you test 15:19 < bridge> :owo: 15:19 < bridge> ripbozo 15:21 < bridge> first i need to fix horrible physics issues that have never happened in any of my tests but happen only when im not looking 15:22 < bridge> when i independently test the issue it doesn't happen in the physics. So there must be something else to trigger it from the algorithm layer. And it's not memory corruption or anything that is easily detected 15:22 < bridge> i have no idea why 15:23 < bridge> but the character and projectiles just phase through walls if projectiles are fired and it isn't even consistent. and if i try the physics in my tas tool they work just fine 15:24 < bridge> when i independently test the issue it doesn't happen in the physics. So there must be something else to trigger it from the algorithm layer. And it's not memory corruption or anything that is easily detectable. 15:25 < bridge> heinsenbug 15:26 < bridge> heisenbug* 15:26 < bridge>