00:53 < ws-client> I thought a working /mapinfo was the only requirement for points to work <:tee_thinking:478629518358085653> are you using sqlite or mysql @kdaniel ? 00:54 < bridge> mysql 00:55 < ws-client> i think these days even sqlite works but mysql works for sure 00:55 < ws-client> no errors in the logs? 00:55 < ws-client> and you gave the map also more than 0 points? :D that show in /mapinfo 00:58 < bridge> that's not what i wanted to say but that the maps are entered in %s_maps and successfully recognised by /mapinfo so should be yes 00:58 < bridge> ``` 00:58 < bridge> str_format(aBuf, sizeof(aBuf), 00:58 < bridge> "INSERT INTO %s_points(Name, Points) " 00:58 < bridge> "VALUES (?, ?) " 00:58 < bridge> "ON DUPLICATE KEY UPDATE Points=Points+?", 00:58 < bridge> GetPrefix()); 00:58 < bridge> ``` 00:58 < bridge> also work 00:58 < bridge> that's not what i wanted to say but that the maps are entered in %s_maps and successfully recognised by /mapinfo so should be yes 00:58 < bridge> ``` 00:58 < bridge> str_format(aBuf, sizeof(aBuf), 00:58 < bridge> "INSERT INTO %s_points(Name, Points) " 00:58 < bridge> "VALUES (?, ?) " 00:58 < bridge> "ON DUPLICATE KEY UPDATE Points=Points+?", 00:58 < bridge> GetPrefix()); 00:58 < bridge> ``` 00:58 < bridge> should also work 00:58 < bridge> that's not what i wanted to say but that the maps are entered in %s_maps and successfully recognised by /mapinfo so should 00:58 < bridge> ``` 00:58 < bridge> str_format(aBuf, sizeof(aBuf), 00:58 < bridge> "INSERT INTO %s_points(Name, Points) " 00:58 < bridge> "VALUES (?, ?) " 00:58 < bridge> "ON DUPLICATE KEY UPDATE Points=Points+?", 00:59 < bridge> GetPrefix()); 00:59 < bridge> ``` 00:59 < bridge> also work 00:59 < bridge> Yes :O then there's something going on with game.png 00:59 < ws-client> at this point i would add some ``dbg_msgs``s around this ``INSERT INTO`` statement and see where it goes wrong 01:00 < bridge> But shotgun etc. aren't affected 01:00 < ws-client> is it unmodified latest ddnet code base @kdaniel ? 01:01 < bridge> ah yes okay thought here are so common stupid questions known that it may be due to something like gametype etc as with random_votes but then I'll look for the error myself 01:02 < ws-client> did you change sv_gametype? 01:02 < bridge> ups sorry i mean sv_server_type 01:03 < bridge> Nope 01:03 < bridge> this should be changed to get working random_votes 01:04 < ws-client> wtf @ryozuki https://github.com/ddnet/ddnet/pull/8925 01:05 < ws-client> now i have to put non ascii characters in my gametype or what -.- 01:07 < bridge> damn i forgot that i changed one statement to get points even after first finish: 01:07 < bridge> ``` 01:07 < bridge> int NumFinished = true; //pSqlServer->GetInt(1); 01:07 < bridge> if(NumFinished == 0) 01:08 < bridge> ``` 01:08 < bridge> will be never true xDD 01:13 < bridge> Also I want to report that this isn't just me 02:12 < bridge> Restarting the client fixes it only for some people 05:16 < bridge> 9000! 05:23 < ws-client> yes its over 9000! 05:42 < bridge> 8,09958998668719085829131208009794E31681 05:50 < bridge> where i can find firedelay 06:11 < ws-client> i tunes 06:12 < ws-client> rcon ``tune grenade_fire_delay 0`` 06:12 < ws-client> see also ``tunes`` 06:12 < ws-client> @notzxpixty 06:13 < bridge> tunes ok ,where i can find lines of this? 06:25 < ws-client> wat 06:26 < bridge> nvm 06:30 < ws-client> @patiga can there be no gamelayer? 06:30 < ws-client> https://zillyhuhn.com/cs/.1726806627.png 08:36 < bridge> Yo, anyone knows why there's no `gmock.h` header file :\ (I did steps described in `Running tests (Debian/Ubuntu)` part in readme) 08:37 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1286576828991017043/image.png?ex=66ee698b&is=66ed180b&hm=196029b76520a4680bed53da828abb82de219f31dbec1c7b0e192d27363269c2& 08:45 < bridge> probably because you didn't install it? 08:45 < bridge> Isn't this some lib? xd 08:46 < bridge> i have `google-mock` lib package installed 08:46 < bridge> i have `google-mock` package installed 08:57 < bridge> Try the download gtest cmake flag. Check what the CI does 08:58 < bridge> Also deleting the build directory might help 08:58 < bridge> deleted it already 3 times xd 08:58 < bridge> Which cmake command did you run? 08:59 < bridge> `cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=1 -DDEV=ON .. && make run_tests` 09:02 < bridge> Try the GTEST one 09:05 < bridge> with `-DDOWNLOAD_GTEST=ON` it works 09:05 < bridge> thanks xd 09:23 < bridge> @ryozuki 09:23 < bridge> https://github.com/edg-l/ddstats/blob/86940cd45074ea440bee048f8551252bd08eb557/src/routes/events/%2Bpage.svelte#L42 09:23 < bridge> The close code must be either 1000, or between 3000 and 4999 otherwise switching between pages breaks (i.e. going from the /Events page to any other page raises an InvalidAccessError) 09:39 < bridge> :O 10:00 < bridge> only when you create a map from scratch, you cant save a map without a gamelayer 10:11 < ws-client> hm okay then the optional makes sense. Bit annoying for type checking if a map is loaded hmm.. 10:12 < ws-client> maybe it would be nicer if making a map from scratch creates a game layer for you? like the editor does. 10:23 < bridge> you should then pass everything for gamelayer to appear 10:24 < bridge> current approach is not sane, but making default gamelayer for ::new(...) is kinda meh 10:50 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1286610486204563466/image.png?ex=66ee88e3&is=66ed3763&hm=ce8832388448f5548325b9e1f491b50a3c3b18395d68a185997862c84cf779eb& 10:50 < bridge> feels good 10:56 < ws-client> where did the input field for envelope values go in the editor? 10:58 < ws-client> and how to resize the envelopes field in general? 11:00 < bridge> Right click the envelope point 11:01 < bridge> Mouse wheel and Shift+mouse wheel 11:01 < ws-client> woah segfault xd 11:01 < ws-client> @robyt3 that seems to zoom not make the view port bigger 11:02 < ws-client> last time i used the editor clicking on "envelopes" multiple times would open it in 3 different sizes 11:02 < bridge> You can drag the envelope menu up to make it larger 11:02 < ws-client> a 11:02 < bridge> You can also drag the setting editor and layers 11:03 < ws-client> i see nice 11:03 < ws-client> thanks 11:09 < bridge> n flips the tile, why shift+n doesnt 11:16 < bridge> In general I'd say it's better if hotkeys are only activated when no additional unnecessary modifiers are pressed, so we can more easily add new hotkeys in the future without breaking users' existing workflow 11:20 < bridge> yeah, and thats cool actually 11:20 < bridge> i got used to these hotkeys tbh 12:03 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1286628754205970454/image.png?ex=66ee99e7&is=66ed4867&hm=8d886537e9178d24e5fbd3599fcd6df710a5acf3be04dcd3e87003139e6fa1d3& 12:03 < bridge> not me but funny 12:22 < bridge> This might not be as bad as it seems with context. Hetzner offers dedicated system configurations where a tech has to setup and make changes for you. So it's probably not a vps, maybe someone asked for extra hard drives and they forgot to plug it back in. 12:26 < bridge> Basically a non event if that's the case since your downtime was planned an unspecified duration so who cares. 12:26 < bridge> Basically a non event if that's the case since your downtime was planned and an unspecified duration so who cares. 14:04 < bridge> go ddnet. 14:04 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1286659284561694730/image.png?ex=66eeb656&is=66ed64d6&hm=ef16aac335a5fcbbbe41ea95911528a32c28bc2176dc186db51fc21a404f1f08& 14:04 < bridge> what the fxxkin' 14:05 < bridge> nightly builds 14:12 < bridge> Yes ? You're toggling it from 0 to 1 or 1 to 0 14:12 < bridge> That's how a toggle works ^^ 14:14 < bridge> the info data should be treated as free-form 14:17 < bridge> move restriction 14:18 < bridge> https://github.com/ddnet/ddnet/issues/6754 14:20 < bridge> <_kemel_> how can I find hammer's hitbox implementation in source? 14:21 < bridge> :think_bot: 14:22 < bridge> Yes ? You're toggling it from 0 to 1 or 1 to 0 (NVM I didn't see the 100) 14:23 < bridge> <_kemel_> what 14:26 < bridge> ech is great. change my mind. you just put anything into the client outer, it doesn't matter 14:28 < bridge> maybe we could try reducing the size of the json a little. 128 bytes per player doesn't sound too little, but I guess json is verbose… 14:31 < bridge> ChillerDragon: if you want to maintain 0.7, it might be possible. the problem is that we have literally no one who wants to do that currently 14:32 < bridge> <0xfaulty> Are you suggesting to add another endpoint to the master server and shorten the names of the json parameters? 14:32 < bridge> How does it not matter? How is the "client-facing server" supposed to handle the case of ech rejection otherwise? 14:32 < bridge> im doing 0 <-> 100, but it's 0 <-> 1 14:34 < bridge> <0xfaulty> It would of course be nice to use grpc serialisation, but it's not really appropriate in our case 😅 15:10 < bridge> nice 15:16 < bridge> check out the older version that worked with wireshark 4.0 15:16 < bridge> i already compiled 4.2 xd 15:24 < bridge> ChillerDragon: why would you be against quic? 15:29 < bridge> report a bug 🙂 15:35 < bridge> is quic quick enough? did u see the reports from cloudflare? 15:35 < bridge> ok not cloudflare 15:35 < bridge> https://dl.acm.org/doi/10.1145/3589334.3645323 15:35 < bridge> that was about file downloads, probably doesn't matter for ddnet 15:35 < bridge> IIRC 15:36 < bridge> the diagrams show that current QUIC impls don't manage to saturate a data link if it has more than 500 Mb/s 15:37 < bridge> I hope we don't have server-client connections with more than 1 Mb/s 15:43 < bridge> I don't understand what you said. if the server gets a request from a client that doesn't do ECH, they'll include the normal SNI. if they don't, the server unpacks the actual SNI from the inner handshake, the outer one doesn't matter 15:46 < bridge> What if the server can not decrypt the inner hello? Then a connection is supposed to be established with the outer hello, through which the "client-facing server" needs to give out an ECHConfig to be used 15:50 < bridge> 6.3.2.1: When the server rejects ECH or ..., it continues with the handshake using the plaintext "server_name" extension instead. Clients that offer ECH then authenticate the connection with the public name, as follows: 15:50 < bridge> - The client MUST verify that the certificate is valid for `ECHConfigContents.public_name`. If invalid, it MUST abort the connection with the appropriate alert. 15:51 < bridge> ... 15:52 < bridge> So I can't just put "anything" in there. I need to put a valid SNI for which I can produce a certificate as far as I understand. Now if you are behind cloudflare or akamai or whatever, that's great. You put `cloudflare.com` in there, `cloudflare.com` provides the ECHConfig great. 15:52 < bridge> 15:52 < bridge> What am I supposed to do with my topology? I'm forced to expose the one domain that I own in plaintext 15:54 < bridge> lmaooo 15:55 < bridge> Unless I grossly misunderstand something. ESNI definitely had the better idea when they used DNS for the keys. ECH's approach seems to be designed around funneling people to using some "client-facing server" provider 15:56 < bridge> Or making no assumptions about intent, at the very least completely designed around that usecase 15:59 < bridge> @heinrich5991 15:59 < bridge> > Issue 1. When downloading the same file, the in-kernel UDP stack issues much more packet reads (netif_receive_skb) than TCP, leading to a significantly higher CPU usage. This is because none of the QUIC implementations we examine uses UDP generic receive offload (GRO) where the link layer module combines multiple received UDP datagrams into a mega datagram before passing it to the transport layer. This is in sharp contrast to the wide deployment 15:59 < bridge> > • Issue 2. In the user space, QUIC incurs a higher overhead when processing received packets and generating responses. This overhead can be attributed to multiple factors: the excessive packets passed from the kernel (Issue 1), the user-space nature of QUIC ACKs, and the lack of certain optimizations such as delayed ACK in QUIC. 15:59 < bridge> it looks like some issues are also bad implementations 15:59 < bridge> or not optimized 15:59 < bridge> It's more of a wireshark from brew does seem to be amd64 and my problem was cross compilation from arm64 to amd64 16:00 < bridge> https://loco.rs/ 16:00 < bridge> loco 16:01 < bridge> I've grown to dislike ORMs in general over the course of the last 5 months 16:02 < bridge> Any value I used to see in them has been destroyed by how annoying to use `GORM` was in golang 16:03 < bridge> it's great 16:03 < bridge> that the Go community discourages ORMs 16:03 < bridge> cuz gorm is literally shit 16:03 < bridge> as are all orms that do more than basic crud 16:04 < bridge> easier to debug sql than some orm (cough Java) 16:05 < bridge> this is not a orm tho i think 16:05 < bridge> I think in the future I only want something that wraps the idea of a transaction, query and a row 16:05 < bridge> it uses sqlx 16:05 < bridge> its builts around axum + sqlx iirc 16:05 < bridge> its built around axum + sqlx iirc 16:06 < bridge> oh it has some kind like orm thing 16:06 < bridge> It was talking about SeaORM in it's page that's why I wanted to talk about ORMs. Yeah this thing seems rather interesting and not an ORM 16:06 < bridge> maybe its sea orm 16:06 < bridge> sea orm is kind of dope tho 16:06 < bridge> It'll take a long while to take the taste of GORM out of my mouth 😄 16:07 < bridge> xd 16:07 < bridge> AIUI, if you know the server supports ECH, you don't need to hope for a fallback 16:08 < bridge> what does AIUI mean 16:08 < bridge> (Internet slang) Initialism of as I understand it. 16:08 < bridge> ECH also uses DNS for keys 16:08 < bridge> But where are you supposed to get the keys to encrypt the inner hello? 16:08 < bridge> DNS 16:09 < bridge> preferably over some encrypted transport 16:09 < bridge> I see 16:09 < bridge> I gave up, cuz dunno no rust toolchain 16:09 < bridge> eh 😦 16:09 < bridge> would be cool if there was an example for cross compilation 16:10 < bridge> too lazy xD 16:10 < bridge> I haven't done cross compilation except from linux 16:10 < bridge> from there it was pretty easy 16:10 < bridge> did you install rust with rustup? 16:10 < bridge> yeah 16:10 < bridge> maybe you can simply add a target there 16:10 < bridge> ehm, let.me see 16:10 < bridge> btw, this fallback is something that can happen say as you rotate keys, or some ISP DNS server misbehaves 16:11 < bridge> `rustup target add aarch64-apple-darwin` 16:11 < bridge> ah, you want cross-compilation 16:11 < bridge> so 16:11 < bridge> `rustup target add x86_64-apple-darwin` 16:11 < bridge> ehm, it's seemingly the one from brew, so no rustup command. 16:12 < bridge> uninstall that and use rustup 16:12 < bridge> k 16:14 < bridge> hmmm 16:14 < bridge> I seem to have missed this part of the proposal because it delegated it to another rfc, my bad. So it's not as insane as I thought it initially was 16:14 < bridge> it makes sense to encrypt the whole handshake, because otherwise data would leak left and right 16:15 < bridge> and having an inner and an outer handshake is incredibly clever IMO 16:15 < bridge> since it makes it hard to block ECH without blocking all connections that are pretending to do ECH 16:15 < bridge> since it makes it hard (impossible?) to block ECH without blocking all connections that are pretending to do ECH 16:15 < bridge> It's very clever, it allows this fallback, allows middleboxes to handle this easily and backwards compatibility in one fell swoop 16:16 < bridge> but the chain of trust needs to hold so the fallback is only possible if you can produce a certificate for the outer hellos sni 16:16 < bridge> I was thinking that this is impossible. until I read that RFC. it was amazing. crypto people just sprinkle some magic pixie dust and the impossible works 16:16 < bridge> yes 16:17 < bridge> and now the sni is no longer hidden unless you are behind cloudflare or fastly or akamai or whatever 16:17 < bridge> or if you give up the fallback 16:17 < bridge> I guess you could always buy a throwaway domain 16:17 < bridge> (just like there would be no fallback with ESNI, as I understand it) 16:17 < bridge> I wonder if the RFC allows the server to behave that way 16:21 < bridge> is the teeworlds programming playlist still a good resource? the first video looks 4 years old 16:22 < bridge> I don't know the teeworlds programming playlist 16:22 < bridge> care to share a link? 16:23 < bridge> Found it at the development wiki page 16:23 < bridge> https://youtube.com/playlist?list=PLhJkqAQmOh5LyYOfnMy4PJB6CSZltQyTc 16:25 < bridge> ohh 16:25 < bridge> ddnet code is so retarded 16:25 < bridge> they use sin() for the x component 16:25 < bridge> whoever did that 16:28 < bridge> What do you mean even? 16:29 < bridge> done, and currently in the wireshark-dissector directory :0 what's the command for cross compilationm 16:29 < bridge> stay without sin, son. 16:30 < bridge> https://github.com/ddnet/ddnet/blob/b34edb64c0a20373214bdc28d666ba445f43263d/src/game/server/entities/door.cpp#L19 16:31 < bridge> 2010 type of code 16:31 < bridge> It doesn't matter there, just makes the rotation start from 90degree up 16:31 < bridge> and go cw instead of ccw 16:32 < bridge> i used direction() from vmath since i didn't see the difference 16:32 < bridge> suddenly everything is wrong 16:33 < bridge> btw i have a question. can i just remove door.cpp/h entirely or are some mods somehow using that entity? 16:33 < bridge> it only initializes itself and is uselessly ticked afterwards 16:33 < bridge> i put it in the initialization process of CCollision so it also gets predicted by the client. 16:34 < bridge> wanted to make a pr for that 16:34 < bridge> bugs are used as features and you think a complete file is unused D: 16:34 < bridge> What? It is the laser doors that many maps use 16:34 < bridge> yea bro look at the code 16:35 < bridge> you dont need to store that entity in the gameworld 16:35 < bridge> it literally sets stoppers with a switch number 16:35 < bridge> nothing else 16:35 < bridge> It's snapped, what do you mean you don't need to store it 16:35 < bridge> it can never change 16:36 < bridge> it is static. 16:36 < bridge> atleast in normal ddnet 16:36 < bridge> moving doors 16:36 < bridge> thats not a thing... 16:36 < bridge> right?? 16:36 < bridge> just a thought of what you actually mean 16:36 < bridge> moving doors doesnt work. 16:36 < bridge> the door is stationarry 16:36 < bridge> Where do you propose to move that code even? Where will you snap it? 16:37 < bridge> Sure when I’m piss drunk Heinrich decides to return to \#develööper 16:37 < bridge> -r 16:37 < bridge> why even snap it? the client doesn't use it 16:37 < bridge> chilleroni, pepperoni 16:37 < bridge> heino is back 16:37 < bridge> `cargo build --release --target=x86_64-apple-darwin` 16:37 < bridge> Ofc it does, it's a normal laser entity, where did you get the idea that the client doesn't use it? 16:37 < bridge> Sounds backwards compatibility breaking. And hard to implement in assembly 16:38 < bridge> Maybe the very new clients now have prediction for them and don't use it 16:38 < bridge> okay then it's fine. 16:39 < bridge> can the collision check if it is used by the server or client? 16:39 < bridge> i mean my change works fine and the client predicts the doors now but it would be basically double initializing the doors on the server. which does not cause any issues but it not that nice 16:40 < bridge> no more backcompat breaking than 0.7. just use a library in asm 16:40 < bridge> the boomerang, chiller 16:40 < bridge> it's hitting 16:40 < bridge> Libraries are. Bloat 16:40 < bridge> I don't get it, sorry 16:41 < bridge> np, i will open a pr and describe it more carefully 16:41 < bridge> 0.6 is backwards and 0.7is forward 16:41 < bridge> debatable 16:41 < bridge> and quic is even more forward 16:41 < bridge> chillerdragon: you already depend on third-party code, e.g. the linux kernel, to send UDP packets 16:41 < bridge> quic as in: an additional protocol, not a replacement? 16:41 < bridge> remove it from brew install with rustup 16:41 < bridge> You likely can't remove that file unless I had whiskey instead of tea this morning and didn't notice. It would break all clients that don't have door prediction 16:41 < bridge> brew cargo cant do stuff like "cargo +nightly fmt" 16:42 < bridge> i won't dw 16:42 < bridge> I got it to compile the x86_64 target 16:42 < bridge> (Y) will check how wireshark likes that 16:42 < bridge> well. it's supposed to be a replacemet in the long run, but I'd support 0.6 for now 16:42 < bridge> are u sure he wants x86 darwin? 16:42 < bridge> pretty 16:42 < bridge> urgh :'/ 16:42 < bridge> Omg 16:43 < bridge> check out https://github.com/cross-rs/cross 16:43 < bridge> my wireshark (from bew) seemingly is x64 16:43 < bridge> buut? 16:43 < bridge> so it dislikes my shared library which was arm64 16:43 < bridge> I actually don't remember, is it literally as simple as `teeworlds over udp` and `teeworlds over quic`? As in after getting the raw bytes out is the protocol still the same? 16:43 < bridge> seems unrelated, we're just trying to cross compile on macos between different arches 16:44 < bridge> that's why I need a x64 shared library 16:44 < bridge> The kernel is different imo 16:44 < bridge> yes 16:44 < bridge> When ring0 real mode tw client? 16:44 < bridge> ahh 16:44 < bridge> I have high hopes that you come up with an abstraction in order to make protocols plug and play 🙏 16:45 < bridge> cough heinrich 16:45 < bridge> UEFI ddnet 16:45 < bridge> yes, that's actually implemented 16:45 < bridge> probably not the higher layer, but after his changes I think the lower layer will be completely abstracted away 16:45 < bridge> it can be a interesting challenge 16:45 < bridge> xdd 16:45 < bridge> yes 16:46 < bridge> Yew heino how is the abstraction layer progressing? 16:46 < bridge> then the maintenance of 0.6/0.7 and quic would be pretty "easy" and one would not necessarily need to throw away old workin protocols 16:46 < bridge> @learath2 actually nvm my approach is bad. i should add the door collision when a snap with a door comes in and remove them when it's not there anymore ig 16:46 < bridge> I have a small question about that. We have optimizations like `recvmmsg` for UDP, will those still be possible? I imagine recv for quic and udp would be quite different 16:47 < bridge> If you tell me what you are trying maybe I can give you an idea? Door prediction and issues have been talked about for a decade now 🙃 16:47 < bridge> just usual door prediction 16:48 < bridge> the plan™ is to do the steam proxy thing next maybe, once we have the transparent protocol abstraction 16:48 < bridge> chillerdragon: not at all, I postponed it after the 0.7 PR got merged 16:48 < bridge> both are UDP, not sure what would be different there 16:51 < bridge> Can I help? I have time until December 16:51 < bridge> do you like coding in rust? I could push my current state 16:51 < bridge> it's not much more than a skeleton 16:51 < bridge> it can translate messages 16:52 < bridge> but I guess it needs some architectural things first, still 16:52 < bridge> so maybe not the best moment to open it to contributions 16:52 < bridge> what do you do in december? 16:52 < bridge> No idea what you are replying to. Element iOS says (null) but yes I will maintain 0.7 until January then I will return to fulltime gaming 16:53 < bridge> Return to Germany 16:53 < bridge> 5991 is alive! 16:54 < bridge> Do the architectural 16:55 < bridge> I don't think this is the way to go, we already send switches and extended laser objects have their switch numbers assigned to them. So first time you spot them in the snap, add them to the world according to the switch. Then toggle them on switch changes instead. 16:55 < bridge> 16:55 < bridge> Atleast that's how I'd go about it. Keeping track of laser entities is janky 16:55 < bridge> LETSGOOOOO 16:56 < bridge> yea 16:56 < bridge> doing it rn. my problem is how do i remove them once they are not in the snapshot anymore? 16:56 < bridge> maybe the custom server removed them 16:56 < bridge> we dont want mispredictions 16:57 < bridge> The interface is what I was thinking about. idk what `quic_recv` looks like in whatever library you used but can you unify that with our `udp_recv`? 16:57 < bridge> ah, rip 16:57 < bridge> `udp_recv` is gone 16:57 < bridge> That's fair, maybe you do have to keep track of the lasers afterall. Mh 16:57 < bridge> only `CNetServer::Recv` remains 16:58 < bridge> @jxsl13: rip teeworlds-go 16:58 < bridge> noooo 16:58 < bridge> why 16:58 < bridge> and different lower layers implement their own `CNetServer::Recv`? 16:58 < bridge> also on the master branch the "toggle" bind apparently doesnt work 16:58 < bridge> xddd 16:58 < bridge> Are you adding quic support? Xd 16:59 < bridge> can't toggle entities anymore lmao 16:59 < bridge> Robyt3 said he'd fix it I think 16:59 < bridge> ok :D 16:59 < bridge> Fix is already merged 16:59 < bridge> https://discord.com/channels/252358080522747904/757720336274948198/1286663676496973906 16:59 < bridge> I mean, it's probably 5 lines of code in Go 16:59 < bridge> no, all the different protocols pop out from there 16:59 < bridge> I was not talking about quic 16:59 < bridge> within the last hour? xd 16:59 < bridge> oke 16:59 < bridge> just more fun with wireshark 16:59 < bridge> and they provide some sort of `mytransportlayer::recv`? 17:00 < bridge> https://discord.com/channels/252358080522747904/293493549758939136/1286680911030653071 17:00 < bridge> yes, wait a sec 17:00 < bridge> @heinrich5991: why have you been afk so long? 17:01 < bridge> vacation (and taking time off of ddnet for my own sanity) 17:02 < bridge> fking discord 17:02 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1286703969883783240/image.png?ex=66eedff4&is=66ed8e74&hm=6ffe1dc5b45711fc591dd3e64ed829447319519a545f6a50dfcb374fb9604afe& 17:02 < bridge> can never load the message 17:02 < bridge> Where did you do vacation? 17:02 < bridge> i hope u had a good vacation heinrich 17:02 < bridge> Lmao same problem 17:02 < bridge> https://github.com/ddnet/ddnet/pull/6961/files#diff-de4e64f3ca4835ed9aef1c5d33c0ceb26f52c0599a85da35b8d92eb60c9e5fb0R831-R842 17:02 < bridge> I guess you could say yes to your question 17:03 < bridge> ah btw doors should also extend into infinity since their collision does 17:03 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1286704180899217570/image.png?ex=66eee026&is=66ed8ea6&hm=fbd11a6cea9d7d17c56b167329fd5eee797951c8932fa9af356a415f265c6640& 17:03 < bridge> ah btw door rendering should also extend into infinity since their collision does 17:03 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1286704180899217570/image.png?ex=66eee026&is=66ed8ea6&hm=fbd11a6cea9d7d17c56b167329fd5eee797951c8932fa9af356a415f265c6640& 17:03 < bridge> now it's saying the dissector was compiled for wireshark 4.2 ._. and I got 4.4 17:03 < bridge> lol 17:03 < bridge> @0xdeen I vaguely remember you trying to implement postgres for ddnet, what went wrong there? Was the abstraction not abstract enough? 17:04 < bridge> libtw2 blaze it 420 17:04 < bridge> I think @zwelf2 is currently rewriting the db stuff in rust 17:04 < bridge> woah Postgres for ddnet I didn’t know that 17:05 < bridge> Zwelf better not be breaking my two forks that depend on the db code xd 17:06 < bridge> <0xdeen> I started a new job and had a baby I think 😄 17:06 < bridge> lol 17:06 < bridge> Ah, that also explains it 😄 17:07 < bridge> deen is only here to click merge button 17:07 < bridge> <01000111g> If someone is interested in adding more customization to the skin system in an easy maintable idea, here is my idea: https://discordapp.com/channels/252358080522747904/1286427778744586350 17:07 < bridge> sometimes with a different finger 17:07 < bridge> xd 17:08 < bridge> lerato also didn’t send a commit since 666 17:08 < bridge> nice 17:08 < bridge> makes sense 17:08 < bridge> congratulations 17:08 < bridge> can't get any better than 666 17:08 < bridge> true 17:09 < bridge> Oh you handle the udp socket yourself for quic too 17:09 < bridge> yes 17:12 < bridge> Can I just say seeing ddnet capitalized like this doesn't spark joy in me? `typedef struct DdnetNetEvent CNetEvent;` 😄 17:13 < bridge> @heinrich5991 so how functional is this nowadays? Can I join a server yet? 17:14 < bridge> Ddnet 17:14 < bridge> https://go.dev/wiki/CodeReviewComments#initialisms <-- 17:14 < bridge>