06:48 <+bridge> [ddnet] xD 07:50 <+bridge> [ddnet] @timakro what about russian unique servers? im glad to host them too 08:19 <+bridge> [ddnet] With russian discord unique race server too?:poggers: 08:39 <+bridge> [ddnet] nah 08:42 <+bridge> [ddnet] sad 08:42 <+bridge> [ddnet] No unban for me:feelsbadman: 10:18 <+bridge> [ddnet] Not so good yet. 10:19 <+bridge> [ddnet] Trying to work with deen on improving the handshaking a little, that would make filtering a lot easier. 10:19 <+bridge> [ddnet] However I'm onto something atm that should work pretty good 10:19 <+bridge> [ddnet] yay breaking protocol changes 10:19 <+bridge> [ddnet] No. 10:20 <+bridge> [ddnet] \:) 10:20 <+bridge> [ddnet] Handshaking itself wouldn't be changed, I suggested introducing a "force reconnect packet" 10:20 <+bridge> [ddnet] however, I can also just abuse the "server is full" reconnect 10:20 <+bridge> [ddnet] however, I can also just abuse the "server is full" reconnect, which of course isn't transparent, but would stop pretty much anything currently leaking. 10:20 <+bridge> [ddnet] Im not sure what you are on to tbh :D 10:21 <+bridge> [ddnet] -> validate handshake using a custom challenge 10:21 <+bridge> [ddnet] -> whitelist flow, reconnect player and allow traffic to acutally pass through to the game server 10:21 <+bridge> [ddnet] How much incoming traffic is guaranteed on secured.gg? 10:22 <+bridge> [ddnet] Attack ,or clean trafifc? 10:22 <+bridge> [ddnet] both 10:22 <+bridge> [ddnet] Clean traffic just as much as the actual server can handle of course. 10:22 <+bridge> [ddnet] which in this case, is 10Gbps in both USA & DE 10:23 <+bridge> [ddnet] Attack traffic? Depends. 10:23 <+bridge> [ddnet] Amplification attacks generally don't cause any trouble, and are filtered upstream. 10:23 <+bridge> [ddnet] 10:23 <+bridge> [ddnet] L7 filtering 100Gbps, can however be upgraded pretty fast on our end. 10:23 <+bridge> [ddnet] Attack traffic? Depends. 10:23 <+bridge> [ddnet] Amplification attacks generally don't cause any trouble, and are filtered upstream. 10:23 <+bridge> [ddnet] 10:23 <+bridge> [ddnet] L7 (game) filtering 100Gbps, can however be upgraded pretty fast on our end. 10:23 <+bridge> [ddnet] Well vali not only uses normal DDoS, also sends spoofed packets 10:23 <+bridge> [ddnet] We're aware 10:23 <+bridge> [ddnet] with player ips 10:23 <+bridge> [ddnet] that's no problem 10:23 <+bridge> [ddnet] It's the first handshake packet which is being sent 10:24 <+bridge> [ddnet] It's the first handshake packet which is being sent, which is not challengeable or cachable on our end. 10:24 <+bridge> [ddnet] which makes things a little problematic. 10:24 <+bridge> [ddnet] However, introducing a reconnect packet to implement a custom challenge, should work perfectly. 10:24 <+bridge> [ddnet] which would be seamless for the client 10:25 <+bridge> [ddnet] "first handshake packet" being "\x10\x00\x00\x01TKEN\xff\xff\xff\xff" 10:25 <+bridge> [ddnet] yea but game traffic doesnt use tokens iirc 10:25 <+bridge> [ddnet] only in 0.7 10:25 <+bridge> [ddnet] Ok, that doesn't really matter 10:26 <+bridge> [ddnet] We don't expect game traffic before handshaking 10:26 <+bridge> [ddnet] true 10:26 <+bridge> [ddnet] but if he sends spoofed packets with ips from connected players 10:26 <+bridge> [ddnet] A flow consists of 10:26 <+bridge> [ddnet] iph id, source ip, source port, dest port, dest ip 10:26 <+bridge> [ddnet] yea 10:26 <+bridge> [ddnet] Chances are a few packets will then still leak due to them perfectly matching that 10:26 <+bridge> [ddnet] but it'd be so low volume, it can't cause issues. 10:28 <+bridge> [ddnet] and you can of course also rate limit that traffic, even though I'm not a huge fan of rate limits 10:28 <+bridge> [ddnet] problem on my server right now is, that OVH limits incoming traffic to a very low amount during an attack, that means the custom firewall cant filter all packets because also legit packets are being filtered 10:28 <+bridge> [ddnet] I'll move soon, then its not a problem anymore 10:28 <+bridge> [ddnet] great to see other servers working on a solution too 10:29 <+bridge> [ddnet] If @deen can implement what I suggested, it shouldn't be a huge issue for servers that are with us 10:29 <+bridge> [ddnet] If he can't implement that, I'll abuse the reconnect mechanism that already exists 10:29 <+bridge> [ddnet] If he can't implement that, I'll abuse the reconnect mechanism that already exists, also not a huge issue. 10:29 <+bridge> [ddnet] Just use that I think 10:29 <+bridge> [ddnet] older clients are still around 10:29 <+bridge> [ddnet] anyways^ 10:30 <+bridge> [ddnet] It'll display that "server is full, reconnecting in 4 seconds" message 10:30 <+bridge> [ddnet] so it wouldn't be super transparent 10:30 <+bridge> [ddnet] but it'd work 11:07 <+bridge> [ddnet] It works 11:07 <+bridge> [ddnet] 🙂 11:08 <+bridge> [ddnet] -0 [004] ..s. 19300946.505675: 0: generated and saved challenge: 454029306 11:08 <+bridge> [ddnet] -0 [004] ..s. 19300946.644496: 0: success! 11:08 <+bridge> [ddnet] -0 [004] ..s. 19300946.644505: 0: yes 11:42 <+bridge> [ddnet] @Fän do you mind elaborating on what is missing on ddnet's initial token handshake? Why do you need a custom challenge? 11:42 <+bridge> [ddnet] Nothing's missing, to be fiar. 11:42 <+bridge> [ddnet] Nothing's missing, to be fair. 11:43 <+bridge> [ddnet] Ideally, our filtering environment should be able to issue challenges, which it is. However, as of right now, we can't make the server "state-aware". 11:43 <+bridge> [ddnet] For this we'd a) require new gear, which is coming in some time october or b) simply make the player reconnect. 11:44 <+bridge> [ddnet] that's interesting. Well, I hope it works 🙂 11:44 <+bridge> [ddnet] Try connecting to a GER1 server and you should notice 11:44 <+bridge> [ddnet] Try connecting to a GER1 server and you should notice how it'll reconnect you 11:45 <+bridge> [ddnet] yea, it does 11:46 <+bridge> [ddnet] Only happens once though. 11:46 <+bridge> [ddnet] so, at that point my ip address is whitelisted? 11:47 <+bridge> [ddnet] The flow, not the IP directly 11:47 <+bridge> [ddnet] there's more to it, but yes, your client is whitelisted at that point. 11:48 <+bridge> [ddnet] the thing is, when I open a second client, the dialog also doesn't appear again 11:48 <+bridge> [ddnet] Agreed 12:27 <+bridge> [ddnet] @Fän how does that thing work? I currently have a website https://f.zillyhuhn.com running to validate an ip address via tcp handshake, could that be replaced by ur reconnect thing? 12:27 <+bridge> [ddnet] If you're asking if you can run this with your dedicated server / vps, then likely not 12:28 <+bridge> [ddnet] wym? 12:28 <+bridge> [ddnet] It uses xdp / eBPF 12:28 <+bridge> [ddnet] whats that 12:28 <+bridge> [ddnet] https://en.wikipedia.org/wiki/Express_Data_Path 12:28 <+bridge> [ddnet] and why shouldnt i be able to use this? 12:28 <+bridge> [ddnet] VPS gets killed even with XDP xd 12:29 <+bridge> [ddnet] Not all NICs support this, especially not in a virtualized environment. 12:29 <+bridge> [ddnet] Not on my vps 12:29 <+bridge> [ddnet] And even then, there's the capacity issue. 12:29 <+bridge> [ddnet] but the firewall infront 12:29 <+bridge> [ddnet] If you have a 1Gbps link, and that gets blasted, there's nothing you can do 12:29 <+bridge> [ddnet] I 12:29 <+bridge> [ddnet] k* 12:29 <+bridge> [ddnet] An interesting article about that from CF https://blog.cloudflare.com/how-to-drop-10-million-packets/ 12:30 <+bridge> [ddnet] We do all our filtering in XDP / eBPF, and it's great, however not everyone can just "set that up" 12:30 <+bridge> [ddnet] I know, but I know someone who could 12:30 <+bridge> [ddnet] can you explain me how it works, maybe in dm 12:30 <+bridge> [ddnet] ^ 12:31 <+bridge> [ddnet] idk wym 12:31 <+bridge> [ddnet] Or in what relation this is 12:31 <+bridge> [ddnet] I've explained how the whole thing works a few msgs above 12:31 <+bridge> [ddnet] ah 12:31 <+bridge> [ddnet] however, open sourcing this as example won't work 12:32 <+bridge> [ddnet] as your server still can't handle > 1Gbps or whatever its capacity is, and even if we did open source this or smiliar, attackers will be able to find a way around. 12:32 <+bridge> [ddnet] vali will anyways xd 12:32 <+bridge> [ddnet] Good luck! 12:32 <+bridge> [ddnet] @Fän maybe instead of disconnecting with "full" you could instead display something like "Please wait..." 12:33 <+bridge> [ddnet] not possible 12:33 <+bridge> [ddnet] ^Yes possible 12:33 <+bridge> [ddnet] Not how it is rn 12:33 <+bridge> [ddnet] deen already mentioned it, and I've made the changes 12:33 <+bridge> [ddnet] ah, okay 12:33 <+bridge> [ddnet] just need to push it live. 12:33 <+bridge> [ddnet] Isnt that message clientside? 12:33 <+bridge> [ddnet] Not at all. 12:33 <+bridge> [ddnet] Oh didnt know 12:33 <+bridge> [ddnet] That's how we force the reconnect 12:37 <+bridge> [ddnet] ah, the client uses the keyword "full" for detecting whether it is full 12:38 <+bridge> [ddnet] now, everything makes sense 12:38 <+bridge> [ddnet] yea 12:40 <+bridge> [ddnet] correct. 12:40 <+bridge> [ddnet] ```cpp 12:40 <+bridge> [ddnet] if(g_Config.m_ClReconnectFull > 0 && (str_find_nocase(ErrorString(), "full") || str_find_nocase(ErrorString(), "reserved"))) 12:40 <+bridge> [ddnet] m_ReconnectTime = time_get() + time_freq() * g_Config.m_ClReconnectFull;``` 13:00 <+bridge> [ddnet] hum, "please wait four full seconds" contains "full" 🤔 13:26 <+bridge> [ddnet] Oh god, hpw did we leave that in there? String matching EW 13:26 <+bridge> [ddnet] s\/hpw/how/ 13:26 <+bridge> [ddnet] Works great for me 🙂 13:27 <+bridge> [ddnet] I mean it worked out, but still it’s very meh software engineering 😄 13:27 <+bridge> [ddnet] Agreed 13:27 <+bridge> [ddnet] but it does help a lot now 😉 13:28 <+bridge> [ddnet] So what is the idea btw? How does making people reconnect help? 13:28 <+bridge> [ddnet] I explained above 13:28 <+bridge> [ddnet] upon first connection, our xdp mitigation will challenge the connectio 13:28 <+bridge> [ddnet] upon first connection, our xdp mitigation will challenge the connection 13:28 <+bridge> [ddnet] upon first connection, our xdp mitigation will challenge the connection, instead of the game server 13:28 <+bridge> [ddnet] once that's verified, it'll reconnect the player to "sync" states 13:29 <+bridge> [ddnet] upon first connection, our xdp mitigation will challenge the connection, instead of the game server doing so 13:30 <+bridge> [ddnet] Ah, that’s a nice idea. I had a PoC that used an xdp filter on the server and I instead used a bpf map 13:31 <+bridge> [ddnet] Well, bpf maps aren't the issue here 13:31 <+bridge> [ddnet] As we're intercepting the initial handshake challenge, the actual game server won't receive it 13:31 <+bridge> [ddnet] that's why we're reconnecting the player 13:31 <+bridge> [ddnet] to whitelist the flow, we're of course still storing data in bpf maps 13:32 <+bridge> [ddnet] Well, I was talking about what I did. I did let he game server receive the initial handshake. I can see how handling that entire flow in xdp would be more efficient 13:34 <+bridge> [ddnet] As a generic solution I would be really happy if some hosters provided a way to upload custom xdp into some upstream firewall. 13:34 <+bridge> [ddnet] That won't ever be a thing. 13:34 <+bridge> [ddnet] It's a liability that no hoster will willingfully take. 13:35 <+bridge> [ddnet] Yeah, too flexible 13:35 <+bridge> [ddnet] You can cause quite a lot of trouble otherwise. 13:35 <+bridge> [ddnet] Then some reasonable subset language 13:35 <+bridge> [ddnet] I just wish I could configure the firewall without having to ask a hoster to do it for thousands of dollars 13:36 <+bridge> [ddnet] Well, there's also the issue of most hosting providers not even knowing what eBPF / XDP is. 13:36 <+bridge> [ddnet] Which is the reason as to why custom ddos protection providers are so successful nowadays. 13:36 <+bridge> [ddnet] Its rather "new" 13:36 <+bridge> [ddnet] "new" technology from 2016 13:36 <+bridge> [ddnet] Some companies are using JAVA 6 13:37 <+bridge> [ddnet] I’m not sure a reasonable subset exists, an upstream firewall would have access to traffic not even destined for you. I could see it maybe being a thing on an “upstream” firewall that is right before your server 13:37 <+bridge> [ddnet] Which no sane provider would allocate >10Gbps to 13:38 <+bridge> [ddnet] Yeah, I don’t see it happening. Maybe a very crippled verifiable language that gets compiled down to bpf 13:39 <+bridge> [ddnet] Maybe just use "standardized" stateful protocols instead 🤔 13:40 <+bridge> [ddnet] As in? 13:41 <+bridge> [ddnet] The solution that would work on most hosters without much friction would be to mimic the protocol of some popular game 13:42 <+bridge> [ddnet] Even then, providers like Hetzner have basically no protection. 13:43 <+bridge> [ddnet] The only provider I could think of would be OVH 13:43 <+bridge> [ddnet] The only provider I could think of would be OVH, which most servers are still being attacked on 13:43 <+bridge> [ddnet] Hetzner offers ddos protections, but mostly you end up nullrouted 😄 13:44 <+bridge> [ddnet] I don’t think hetzner null routed us even once the last 3 years 13:44 <+bridge> [ddnet] We got nullrouted twice in 6 months already, not KoG 13:44 <+bridge> [ddnet] https://www.hetzner.com/unternehmen/ddos-schutz 13:45 <+bridge> [ddnet] But you right, hetzner isnt the best player out there 13:45 <+bridge> [ddnet] This is just for amp-related floods 13:45 <+bridge> [ddnet] Anything actually spoofed won't be stopped at all. 13:47 <+bridge> [ddnet] @Fän btw did you consider the 2 other protocols we support when you wrote your rules? 13:47 <+bridge> [ddnet] "DNS reflection, NTP reflection or UDP floods on port 80." 13:47 <+bridge> [ddnet] basically things that were blocked using static ACLs in 2010 already 13:47 <+bridge> [ddnet] I haven't tested older clients 13:47 <+bridge> [ddnet] If you're talking about the info request (i don't have a sample of that atm), then yes, that's passing just fine. 13:48 <+bridge> [ddnet] Vanilla 0.6 doesn’t have a token, 0.7 doesn’t use the same layout for the header (e.g. the token isn’t in the same place) 13:49 <+bridge> [ddnet] If you are only deploying this filter while under attack it’s fine to drop these, but if it’ll be always deployed we might have to allow those flows through albeit with a ratelimit 13:49 <+bridge> [ddnet] Of course I'm not very deep into all this, but isn't it granted to assume that most players would use the newest version? 13:49 <+bridge> [ddnet] (found at https://ddnet.tw) 13:50 <+bridge> [ddnet] Yep, a very large percentage of players would be using either the ddnet client or derivative clients that will use our version of the handshake 13:52 <+bridge> [ddnet] But the servers support all 3 versions of the handshake, so we probably should allow those through aswell 13:53 <+bridge> [ddnet] Or if this is only deployed during attacks maybe we should just not advertise on the 0.7 master during that time 13:54 <+bridge> [ddnet] I can likely add support for 0.7 13:55 <+bridge> [ddnet] not entirely sure about vanilla 0.6 though 13:55 <+bridge> [ddnet] You can just let that through with a ratelimit and let it drop in userland? 13:55 <+bridge> [ddnet] Just to get complaints about "server getting ddos"? 13:55 <+bridge> [ddnet] Rather not 13:55 <+bridge> [ddnet] I'll see what I can do 13:56 <+bridge> [ddnet] Let's say a newer client uses the protocol 0.6 uses, however sends their version as newest (afaik a certain packet contains the ddnet client version), will it allow that to pass through? 13:57 <+bridge> [ddnet] The server doesn’t really pass things through 13:57 <+bridge> [ddnet] Not sure what you mean 13:57 <+bridge> [ddnet] ok, let me rephrase 13:57 <+bridge> [ddnet] Right now, the newest version connects using an initial challenge 13:57 <+bridge> [ddnet] if the client did not send the challenge, but connected smiliar to how 0.6 connects, would it still allow the player to join? 13:58 <+bridge> [ddnet] It won’t take up a slot. The server has a “handshake” built for 0.6 clients that abuses a behaviour of the client. So it will get a tad deeper into the netcode then will get dropped 13:59 <+bridge> [ddnet] I can tell you the path it takes in code if you want to take a look 14:00 <+bridge> [ddnet] Sure! 14:05 <+bridge> [ddnet] So `SECURITY_TOKEN_MAGIC` iow `TKEN` is what we use to indicate a client supports the ddnet protocol. In `CNetServer::Recv` `IsDDNetControlMsg` will check if the magic is in the packet. If not it will take the 0.6 path. Which is in `CNetServer::OnPreConnMsg`, this will simulate an accept, there is a nice comment there you can read about what it does 14:07 <+bridge> [ddnet] It basically abuses the fact that the client will return the gametick in it's input packets. So we send a generated gametick, and in the input packet we check that it is the same generated gametick we sent 14:09 <+bridge> [ddnet] Cool, can add support for that. 14:10 <+bridge> [ddnet] How are you thinking of doing it? Will you re-implement it in XDP or will you pass it through? 14:10 <+bridge> [ddnet] Assuming that it doesn't support the same reconnect mechanism 14:10 <+bridge> [ddnet] I'll have to wait for the new gear to come in 14:11 <+bridge> [ddnet] and I then can mess with it, and send custom generated responses to the server and such 14:11 <+bridge> [ddnet] which will make the entire "reconnect" thing useless as we can handle it in an easier way 14:11 <+bridge> [ddnet] well, instead of auto reconnect you can also instruct players to reconnect 14:11 <+bridge> [ddnet] ^^ 14:12 <+bridge> [ddnet] fan is the guy from secured.gg right? 14:13 <+bridge> [ddnet] i feel grateful but i cant stop thinking about the day he will abandon us 14:13 <+bridge> [ddnet] xd 14:13 <+bridge> [ddnet] if this works out 14:13 <+bridge> [ddnet] +1 14:13 <+bridge> [ddnet] Hm, what easier way? Don't think storing the handshake packets is viable 14:13 <+bridge> [ddnet] It's not. 14:14 <+bridge> [ddnet] As of right now, we reconnect the player to send another handshake packet 14:14 <+bridge> [ddnet] to forward to the server, after validating the actual connection as legitimate 14:14 <+bridge> [ddnet] with the new gear, we can instead generate packets and send them as a "replacement" handshake packet 14:14 <+bridge> [ddnet] that way we won't have to reconnect players at all 14:15 <+bridge> [ddnet] Hm, so the firewall/the system in between will do a handshake with the client, if it's a legit connection it'll do another one with the server then let them speak with eachother? I guess that works since we don't have tokens in actual game packets iirc 14:15 <+bridge> [ddnet] Correct. 14:15 <+bridge> [ddnet] it's nice to finally have someone that knows what they are doing with xdp and has access to some decent hardware 😄 14:16 <+bridge> [ddnet] ye but that doesnt remove my worries xd 14:16 <+bridge> [ddnet] That's how our Rust filter works aswell, to some extent 14:16 <+bridge> [ddnet] Obviously there's more to it, but that's one of its main functionalities 14:16 <+bridge> [ddnet] @Learath2 do u have access to said xdp code? 14:16 <+bridge> [ddnet] We've all been messing around with this kind of solution but with our peasant 1g links it's just too easy to overwhelm 14:17 <+bridge> [ddnet] this is rly great, but with such a long lived game as ddnet people come and go you know it 14:17 <+bridge> [ddnet] @Ryozuki nope, not sure what the conditions are around that one 14:17 <+bridge> [ddnet] its better to be prepared 14:18 <+bridge> [ddnet] I'm guessing they keep the firewall stuff a bit of a secret, which is fair, given the nature of this kind of thing 14:23 <+bridge> [ddnet] btw if this solution proves useful we should probably implement a reconnect message so people don't get the "full" 14:23 <+bridge> [ddnet] It won't be required with the new hardware anyway 14:24 <+bridge> [ddnet] We're having trouble with a vendor, so things might take another week or two, but at that point we'll have a lot more control over traffic flow 14:25 <+bridge> [ddnet] Will you officially support teeworlds/ddnet filters for all customers? 14:25 <+bridge> [ddnet] So this whole "reconnect" thing is just temporary 14:25 <+bridge> [ddnet] Once we consider the filter as fully functional, yes. 14:25 <+bridge> [ddnet] cool, I want one 14:25 <+bridge> [ddnet] (which means support for 0.6, 0.7 and current version) 14:26 <+bridge> [ddnet] but will u need a dedicated or just a vps? 14:26 <+bridge> [ddnet] VPS will do just fine 14:26 <+bridge> [ddnet] thats nice 14:26 <+bridge> [ddnet] We'll probably sooner or later move to 0.7 protocol ourselves 14:26 <+bridge> [ddnet] So another protocol change? 14:26 <+bridge> [ddnet] anyway, can add support for 0.7 if someone can provide me a download 14:27 <+bridge> [ddnet] https://github.com/teeworlds/teeworlds 14:27 <+bridge> [ddnet] Ah I see 14:27 <+bridge> [ddnet] ddnet is a mod of teeworlds 14:27 <+bridge> [ddnet] it ended up being more popular 14:27 <+bridge> [ddnet] I know, just not fully aware of all versions 14:27 <+bridge> [ddnet] ah ok 14:27 <+bridge> [ddnet] well teeworlds changed protocol from 0.6 to 0.7 14:27 <+bridge> [ddnet] Well I wouldn't hold my breath, I've been intending to port ddnet to 0.7 for 2 years now. I just don't have the time for it 14:27 <+bridge> [ddnet] but ddnet stayed at 0.6 14:27 <+bridge> [ddnet] i wouldnt rush the 0.7 stuff 14:28 <+bridge> [ddnet] this will take lot of time 14:28 <+bridge> [ddnet] and lot of angry people 14:28 <+bridge> [ddnet] :monkalaugh: 14:28 <+bridge> [ddnet] We do support the 0.7 protocol though, the filter should probably allow it 14:28 <+bridge> [ddnet] We just don't use it in the client 14:28 <+bridge> [ddnet] porting to 0.7 fully would mean new skin system etc lot of changes and lot of ppl who dislike changes 14:28 <+bridge> [ddnet] xd 14:29 <+bridge> [ddnet] @Ryozuki yeah the skin thing is going to be a huge issue 14:29 <+bridge> [ddnet] We'd probably have an extra netmsg to allow people to use legacy skins 14:29 <+bridge> [ddnet] also we should never ever take their text rendering stuff 14:29 <+bridge> [ddnet] it sucks ass 14:29 <+bridge> [ddnet] it looks rly bad 14:30 <+bridge> [ddnet] ᵃᶜᶜᵒᵘⁿᵗˢ 14:30 <+bridge> [ddnet] @TsFreddie @Ryozuki is insulting your text renderer 14:30 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/893474944552415283/unknown.png 14:30 <+bridge> [ddnet] cmon 14:30 <+bridge> [ddnet] u know it 14:30 <+bridge> [ddnet] this is rly bad 14:30 <+bridge> [ddnet] what's this 14:30 <+bridge> [ddnet] teeworlds 0.7 chat 14:31 <+bridge> [ddnet] ough 14:31 <+bridge> [ddnet] its like it went to 2000's 14:31 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/893475202212712448/unknown.png 14:31 <+bridge> [ddnet] the skin system is nice tho 14:31 <+bridge> [ddnet] the only BIG downside 14:31 <+bridge> [ddnet] is we got lot of skins 14:31 <+bridge> [ddnet] that would be lost 14:31 <+bridge> [ddnet] hm, ours does look prettier, why is that? 14:31 <+bridge> [ddnet] @Learath2 ours looks like 0.6 teeworlds 14:31 <+bridge> [ddnet] 0.7 changed it 14:31 <+bridge> [ddnet] to use the shadow weird 14:32 <+bridge> [ddnet] and it looks rly bad 14:32 <+bridge> [ddnet] nah, not my fault that i kept the look 14:32 <+bridge> [ddnet] but screw Ryozuki anyway 14:32 <+bridge> [ddnet] outline > shadow 14:33 <+bridge> [ddnet] heh, I found a bug with `cl_chat_old` funny how I predicted this the second we were forced to include yet another config to keep old players happy 14:33 <+bridge> [ddnet] we can remove it 14:33 <+bridge> [ddnet] im sure at this point only konsti and ravie use it 14:33 <+bridge> [ddnet] most ppl are 2 lazy to change 14:33 <+bridge> [ddnet] it 14:33 <+bridge> [ddnet] if you turn it on and off you'll get messages without a tee on the left 14:33 <+bridge> [ddnet] proximity voice chat ddnet when 14:33 <+bridge> [ddnet] @murpi i wanted to look into that 14:33 <+bridge> [ddnet] that would be so toxic 😄 14:33 <+bridge> [ddnet] always wanted to learn voip 14:34 <+bridge> [ddnet] i can see sp someone already 14:34 <+bridge> [ddnet] with a soundboard 14:34 <+bridge> [ddnet] and the nazi anthem 14:34 <+bridge> [ddnet] Do I have to modify anything to allow 0.7 players to join? 14:34 <+bridge> [ddnet] imagine having to moderate voice chat :/ 14:34 <+bridge> [ddnet] my server doesn't seem joinable on 0.7 14:34 <+bridge> [ddnet] ur ddnet server? 14:34 <+bridge> [ddnet] actually, nvermind! 14:34 <+bridge> [ddnet] actually, nevermind! 14:34 <+bridge> [ddnet] put map in maps07 folder 14:34 <+bridge> [ddnet] integrate intels bleep system 14:34 <+bridge> [ddnet] @Fän yes, you need to generate the 0.7 map, there is a tool included in the zip for it, and you need to enable `sv_sixup` 14:35 <+bridge> [ddnet] if there are any issues enabling the compatibility layer there will be a warning on the command line 14:36 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/893476456099901501/IMG_20211001_124636.jpg 14:36 <+bridge> [ddnet] Q: Restarting the client should be changing the src port, do you think maybe you have a bug there? I only got the double connect the first time 14:38 <+bridge> [ddnet] A: Had to limit flows to ip saddr temporarily 14:38 <+bridge> [ddnet] is this some fake nintendo 14:38 <+bridge> [ddnet] why does it have to be nintendo 14:38 <+bridge> [ddnet] its just a arm device with controller 14:39 <+bridge> [ddnet] xd 14:39 <+bridge> [ddnet] does anyone want to donate a steam deck to me so i can test ddnet there? (for dev purposes obviously) :monkalaugh: 14:40 <+bridge> [ddnet] sure y not 14:40 <+bridge> [ddnet] our company's publisher got the dev kit 14:40 <+bridge> [ddnet] might as well donate to ddnet 14:40 <+bridge> [ddnet] don't think there is much that needs to be done specially for the steam deck 14:40 <+bridge> [ddnet] if it works on linux it should work, no? 14:41 <+bridge> [ddnet] @Learath2 shh 14:41 <+bridge> [ddnet] other than making a better controller support 14:41 <+bridge> [ddnet] :thonk: 14:41 <+bridge> [ddnet] :feelsbadman: 14:41 <+bridge> [ddnet] besides why would you donate it to ryozuki, you should donate it to @Jupstar ✪ if anything is broken it'll be the gfx 14:42 <+bridge> [ddnet] :pepeH: 14:42 <+bridge> [ddnet] i always thought L and R to move and left stick gun right stick hook might be better than using stick to move btw 14:42 <+bridge> [ddnet] with a controller its hard to hook + hammer + aim at same time 14:43 <+bridge> [ddnet] something quite frequent in ddnet 14:43 <+bridge> [ddnet] and move 14:43 <+bridge> [ddnet] auto aim for switch to make it easier :kekw: 14:43 <+bridge> [ddnet] well but move would be on the other hand 14:43 <+bridge> [ddnet] our ddnet rip off has aim assist lol 14:43 <+bridge> [ddnet] lol 14:44 <+bridge> [ddnet] bitcoin got back to 40.000 there goes my hopes for normal gpu prices 14:45 <+bridge> [ddnet] imagine using bitcoin 14:45 <+bridge> [ddnet] you just tap other's avatar to auto hook. and hook aim will change angle to snap to a hookable surface if it is right at the edge of an unhookable surface. 14:46 <+bridge> [ddnet] I feel like switch players will get banned on noby fng guaranteed 14:54 <+bridge> [ddnet] hm, following people is still quite hard with the new serverlist, I wonder if we can do anything about that 14:55 <+bridge> [ddnet] @Learath2 shareable server links 14:55 <+bridge> [ddnet] the server browser can have a extra button 14:56 <+bridge> [ddnet] "share server link in chat" 14:56 <+bridge> [ddnet] joining should require confirmation 14:56 <+bridge> [ddnet] and it should be heavily rate limited 14:56 <+bridge> [ddnet] Hm, how would you click the link tho? 14:56 <+bridge> [ddnet] ddnet would provide the functionality 14:56 <+bridge> [ddnet] a special packet 14:56 <+bridge> [ddnet] not an actual link 14:57 <+bridge> [ddnet] just something u can click 14:57 <+bridge> [ddnet] That part is easy, I was more thinking UX 14:57 <+bridge> [ddnet] maybe add a new tab 14:57 <+bridge> [ddnet] on the esc menu 14:57 <+bridge> [ddnet] We dont have a cursor while playing to click with 14:57 <+bridge> [ddnet] to see shared servers 14:57 <+bridge> [ddnet] by people 14:57 <+bridge> [ddnet] so its not intrusive in the chat 14:57 <+bridge> [ddnet] and can be easily ignored 14:57 <+bridge> [ddnet] by non interested people 14:58 <+bridge> [ddnet] If we had accounts we could do parties. Everyone follows the party leader 14:58 <+bridge> [ddnet] eh 14:58 <+bridge> [ddnet] we could do that already 14:58 <+bridge> [ddnet] parties dont need accounts 14:58 <+bridge> [ddnet] well it would only last a single server 14:59 <+bridge> [ddnet] at this point it would be easier to just join a team 14:59 <+bridge> [ddnet] and make a command 14:59 <+bridge> [ddnet] /flw 14:59 <+bridge> [ddnet] /accept 14:59 <+bridge> [ddnet] gg 15:00 <+bridge> [ddnet] Minecraft flashbacks. 15:00 <+bridge> [ddnet] i find it amusing you add a dot to all sentences 15:00 <+bridge> [ddnet] The server dictating the next ip to contact is dangerous 15:00 <+bridge> [ddnet] but its just me maybe 15:00 <+bridge> [ddnet] xdd 15:01 <+bridge> [ddnet] Habit 15:02 <+bridge> [ddnet] Actually this could work 15:03 <+bridge> [ddnet] flw would send a netmsg to all clients in the team, accept would be a clientside command 15:03 <+bridge> [ddnet] accept wouldnt even be a command actually, just a popup 15:03 <+bridge> [ddnet] @Fän lol searching about people who add full stops on instant messaging apps i found this https://www.theguardian.com/technology/shortcuts/2015/dec/09/science-has-spoken-ending-a-text-with-a-full-stop-makes-you-a-monster 15:04 <+bridge> [ddnet] the internet is crazy 15:04 <+bridge> [ddnet] Oh no 15:04 <+bridge> [ddnet] “send nudes.” 15:04 <+bridge> [ddnet] > Linguist reveals why the punctuation mark is making you look 'passive aggressive' 15:04 <+bridge> [ddnet]