11:01 <+bridge> [ddnet] send help mi map is broken 11:01 <+bridge> [ddnet] 11:01 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/564374164149108746/ChillBlock5_exp.map 11:01 <+bridge> [ddnet] crashes my ddnet client if i try to join or open in editor 11:02 <+bridge> [ddnet] works in vanilla 0.6.4 tho 11:04 <+bridge> [ddnet] ah no it crashes my ddnet server on join and client on editor open 11:09 <+bridge> [ddnet] k saved it with vanilla client and fixed speedups/front and tele manually. Cant remember exactly but i think i did some experiments with tml back then. So i got the map back. But still a crash bug that ddnet has and vanilla doesnt. So if somebody is bored pls fix xd 11:16 <+bridge> [ddnet] Crashing servers and client with maps is extremely easy, I tried fuzzing it once 11:16 <+bridge> [ddnet] ya 11:16 <+bridge> [ddnet] all the accesses seemed to be reads instead of writes so it's probably not THAT bad 11:16 <+bridge> [ddnet] but even vanilla 0.6.4 can handle this map 11:16 <+bridge> [ddnet] basically we trust the map to report its data correctly and then just read over borders 11:17 <+bridge> [ddnet] didnt some guy reported is as security vuln latley in vanilla? 11:17 <+bridge> [ddnet] vanilla doesn't support many of the game layers ddnet does 11:17 <+bridge> [ddnet] oh? 11:17 <+bridge> [ddnet] link please 11:17 <+bridge> [ddnet] lemme check 11:18 <+bridge> [ddnet] https://github.com/teeworlds/teeworlds/issues/2071 11:28 <+littlething> hey guys can someone help me a quide ? about in network.py I think you can only add whole 32 bit ints at a time. right? 11:32 <@deen> I guess 11:33 <@deen> There's a NetIntRange, but that still seems to put a full int in 11:34 <+bridge> [ddnet] @ChillerDragon sounds good, want to cherry-pick that over to ddnet? 11:35 <+bridge> [ddnet] do i look like a git wizard? 11:35 <+bridge> [ddnet] xd but i can try 11:35 <+bridge> [ddnet] you can start learning 11:36 <+bridge> [ddnet] and you can also test if that fixes your issue 11:37 <+littlething> so can i add more ? 11:41 <+bridge> [ddnet] dont think so tho @deen because their fix is like a few days old and i tested in 0.6.4 but ye lez see 12:02 <+bridge> [ddnet] @ChillerDragon yea, it was our tml test, wasnt it? 12:06 <+bridge> [ddnet] no even way older think it was my first test 12:22 <+bridge> [ddnet] @deen i guess it is easier to copy over the few lines manually instead of using git magic 12:23 <+bridge> [ddnet] but we loose the real authors of the commits then ._. 12:39 <+bridge> [ddnet] i dont think ddnet is affected by this anways. Because vanilla added way more code to the Load() function . 12:39 <+bridge> [ddnet] 12:39 <+bridge> [ddnet] Left ddnet, right vanilla 12:39 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/564398942482071552/unknown.png 12:57 <+bridge> [ddnet] aaaah fuck 12:57 <+bridge> [ddnet] -.- 12:58 <+bridge> [ddnet] wtf where did the commits go? I did cherry pick solved the conflicts and git said i should commit. And now im the only commit there and the one i cherrypicked disapeared 13:12 <+bridge> [ddnet] call me git wizard! Bitch pls 13:14 <+bridge> [ddnet] @ChillerDragon git wizard 15:50 <+bridge> [ddnet] bois? 15:50 <+bridge> [ddnet] the copy and pasting is not working on linux huh? 15:51 <+bridge> [ddnet] or am i pressing the wrong key? 15:51 <+bridge> [ddnet] 😜 16:09 <+bridge> [ddnet] does anyone know a fix for tabbing back into ddnet client on debian10 ? The window is not centered anymore 16:12 <+bridge> [ddnet] 16:12 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/564452401029971978/image0.jpg 16:28 <+bridge> [ddnet] 16:28 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/564456528606789632/niczdwkq2uq21.png 16:29 <+bridge> [ddnet] epic 😃 16:30 <+bridge> [ddnet] sharing in a GNOME group. 16:31 <+bridge> [ddnet] zoozti 16:31 <+bridge> [ddnet] xd 16:33 <+bridge> [ddnet] remove solotiles -> problem solved 16:33 <+bridge> [ddnet] <ᶰ°Konͧsti> :f3: 17:19 <+bridge> [ddnet] @ᶰ°Konͧsti "Should not be too hard to fix i guess?" go fix it then 17:19 <+bridge> [ddnet] mean 17:19 <+bridge> [ddnet] no, he is the mean one 17:23 <+bridge> [ddnet] how does he come to this conclusion 🤔 17:25 <+bridge> [ddnet] i guess cus it already works correctly in some places so it could be a simple fix that doesnt require alot of new code 17:25 <+bridge> [ddnet] where does anything related to solo prediction work? 17:26 <+bridge> [ddnet] probably in gameclient.cpp, players.cpp, maybe gamecore.cpp 17:50 <+bridge> [ddnet] don't think client knows whether another player is in solo or not 17:56 <+bridge> [ddnet] does /showothers hide people who are in solo 17:56 <+bridge> [ddnet] if so then doesnt it know somehow 17:57 <@heinrich5991> all / commands are handled by the server 17:57 <@heinrich5991> this only indicates that the server knows that ^^ 17:58 <+bridge> [ddnet] oo right 18:51 <+bridge> [ddnet] @ᶰ°Konͧsti https://media.discordapp.net/attachments/314776480880132097/564492483791290399/fixed-0.jpg?width=1216&height=684 18:51 <+bridge> [ddnet] is this what u wanted 18:55 <+bridge> [ddnet] <ᶰ°Konͧsti> This is what i mean Ye xd 18:55 <+bridge> [ddnet] <ᶰ°Konͧsti> Or idk 18:56 <+bridge> [ddnet] ok now pay me 10€ 18:56 <+bridge> [ddnet] <ᶰ°Konͧsti> its just when ur in solopart and watch people playing u will not see the hookcoll yellow when they aim a tee 19:02 <+bridge> [ddnet] ryozooz 19:03 <+bridge> [ddnet] wtf 3000 fps 19:03 <+bridge> [ddnet] <ߊɲʄɘɾɳɔ> *ryozoOz* 19:03 <+bridge> [ddnet] <ߊɲʄɘɾɳɔ> *ryozoOoz* 19:08 <+bridge> [ddnet] @onby linux + good pc 19:08 <+bridge> [ddnet] xd 19:14 <+bridge> [ddnet] linux + potato pc + no design + overclock 19:14 <+bridge> [ddnet] it's funny cuz Gameclient on a method named OnRender is sending packets to the server, gg 19:17 <+bridge> [ddnet] also in vanilla ._. 19:17 <+bridge> [ddnet] (src/game/clinet/components/chat.cpp, `CChat::OnRender`) 19:17 <+bridge> [ddnet] vanilla no lag 19:20 <+bridge> [ddnet] HADOKEN!!! 19:20 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/564499823743467540/unknown.png 19:21 <+bridge> [ddnet] weeb code 19:21 <+bridge> [ddnet] what's hadoken? 19:21 <+bridge> [ddnet] https://www.urbandictionary.com/define.php?term=hadoken 19:21 <+bridge> [ddnet] its the thing that the guy that fights people spams 19:37 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/314776480880132097/564504123471429655/fixed-0.jpg 19:38 <+bridge> [ddnet] alpha for solo players! 19:38 <+bridge> [ddnet] yay 19:38 <+bridge> [ddnet] now i just have to fix the colision bug and the hook moving a little 19:41 <+bridge> [ddnet] fixed nameplate alpha too xd 19:42 <+bridge> [ddnet] what does it change 19:42 <+bridge> [ddnet] from /showothers 19:42 <+bridge> [ddnet] @Ryozuki 19:42 <+bridge> [ddnet] ? 19:43 <+bridge> [ddnet] on solo players 19:43 <+bridge> [ddnet] before it was u see him or not 19:43 <+bridge> [ddnet] now if u have showothers it appliues the alpha 19:43 <+bridge> [ddnet] from teams 19:43 <+bridge> [ddnet] idk if i explain good 19:43 <+bridge> [ddnet] no 19:43 <+bridge> [ddnet] xd 19:43 <+bridge> [ddnet] xd 19:43 <+bridge> [ddnet] before u could see fully or not at all solo players 19:43 <+bridge> [ddnet] u get that 19:43 <+bridge> [ddnet] ah 19:43 <+bridge> [ddnet] i get it 19:43 <+bridge> [ddnet] gud 20:00 <+bridge> [ddnet] im wondering where does the client checks for colisions i want to fix the bug where if u are not in solo and other is u see a weird collision 20:00 <+bridge> [ddnet] intersectcharacter doesnt do this 20:00 <+bridge> [ddnet] Well, how would you know that the other player is in solo=? 20:00 <+bridge> [ddnet] That information is not sent to client yet 20:00 <+bridge> [ddnet] i added it 20:00 <+bridge> [ddnet] ok 20:01 <+bridge> [ddnet] i got m_IsSolo on cnet CNetObj_Character 20:01 <+bridge> [ddnet] that sounds like it would break compatibility with vanilla? 20:01 <+bridge> [ddnet] hmm 20:01 <+bridge> [ddnet] I thought we should use the new protocol extension thing 20:01 <+bridge> [ddnet] if you explain me how i can try 20:02 <+bridge> [ddnet] what is it 20:02 <+bridge> [ddnet] and maybe send a single uint64 where each bit says whether a tee is in solo 20:02 <+bridge> [ddnet] I don't know 20:02 <+bridge> [ddnet] the network character by hmh 20:02 <+bridge> [ddnet] was closed 20:02 <+bridge> [ddnet] see protocol_ex_msgs.h 20:03 <+bridge> [ddnet] :o 20:03 <+bridge> [ddnet] the @DDNet.tw things I thin 20:04 <+bridge> [ddnet] what domain i put? ddnet.tw 20:04 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/564510927127314432/unknown.png 20:05 <+bridge> [ddnet] yes 20:05 <+bridge> [ddnet] if your goal is ddnet server/client 20:05 <+bridge> [ddnet] y 20:09 <+bridge> [ddnet] how to convert a unsigned char * to uin64 xD 20:10 <+bridge> [ddnet] (uint64_t) 20:10 <+bridge> [ddnet] int SoloPlayers = (uint64_t)Unpacker.GetRaw(64); 20:10 <+bridge> [ddnet] this easy? 20:10 <+bridge> [ddnet] GetRaw(64)? 20:10 <+bridge> [ddnet] const unsigned char *CUnpacker::GetRaw(int Size) 20:10 <+bridge> [ddnet] i can only get this 20:10 <+bridge> [ddnet] or a int 20:11 <+bridge> [ddnet] (or a string) 20:11 <+bridge> [ddnet] I'd assume Size is number of bytes, not bits 20:11 <+bridge> [ddnet] oh 20:11 <+bridge> [ddnet] so 8 20:12 <+bridge> [ddnet] the way we usually do it is not that pretty 20:12 <+bridge> [ddnet] unsigned GhostMapCrc = (m_Header.m_aCrc[0] << 24) | (m_Header.m_aCrc[1] << 16) | (m_Header.m_aCrc[2] << 8) | (m_Header.m_aCrc[3]); 20:12 <+bridge> [ddnet] is for 4 bytes for example 20:13 <+bridge> [ddnet] uhm 20:13 <+bridge> [ddnet] `uint64_t SoloPlayers = (uint64_t)Unpacker.GetRaw(8);` 20:13 <+bridge> [ddnet] xD 20:13 <+bridge> [ddnet] so you get out each byte and shift them so that they all fit together 20:13 <+bridge> [ddnet] what you're doing casts the pointer 20:13 <+bridge> [ddnet] ok 20:13 <+bridge> [ddnet] not the actual content 20:13 <+bridge> [ddnet] i get what u mean 20:14 <+bridge> [ddnet] You could cast the content straight to uint64_t and probably it would mostly work, but it's probably not standard compliant 20:16 <+bridge> [ddnet] and about collision, I'd look for occurences of the player_collision tune 20:17 <+bridge> [ddnet] that leads to gamecore.cpp:417 20:17 <+bridge> [ddnet] sounds good: // handle player <-> player collision 20:17 <+bridge> [ddnet] thanks 20:18 <+bridge> [ddnet] iff i shift << 56 clang tidy says it has more width than a unsigned char, i guess i should cast every array memeber to uint64? xD 20:19 <+bridge> [ddnet] or it isnt needed 20:22 <+bridge> [ddnet] The behavior is undefined if the right operand is negative, or greater than or equal to the length in bits of the promoted left operand. 20:22 <+bridge> [ddnet] so yes i have to cast 20:22 <+bridge> [ddnet] yeah 20:22 <+bridge> [ddnet] ugly code (tm) 20:22 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/564515461883232297/unknown.png 20:22 <+bridge> [ddnet] told you 20:33 <+bridge> [ddnet] not even a unicode ™ 20:34 <+bridge> [ddnet] @heinrich5991 do you remember if copy_mem for the same thing would be fine on all kinds of platforms? 20:34 <+bridge> [ddnet] @heinrich5991 also, want the walkthrough now? 20:34 <+bridge> [ddnet] no, because of big-endian vs little-endian 20:34 <+bridge> [ddnet] ah, right 20:35 <+bridge> [ddnet] yea, let me look at the PR again 20:35 <+bridge> [ddnet] I think we still have locations that do it with mem_copy though 20:35 <+bridge> [ddnet] might have to fix them then 20:35 <+bridge> [ddnet] yes 20:35 <+bridge> [ddnet] we have faulty code for big-endian machines, at least in the map reading code 20:36 <+bridge> [ddnet] weird, no one noticed on debian? 20:36 <+bridge> [ddnet] i thought on debian we're built for dozens of platforms or something like that 20:36 <+bridge> [ddnet] possibly elsewhere as well, if no one tests it, it doesn't work 20:36 <+bridge> [ddnet] I don't know if anyone actually executes the stuff or whether they just build it 20:36 <+bridge> [ddnet] we don't have a test suite for datafiles yet, that might uncover it 20:37 <+bridge> [ddnet] true enough 20:37 <+bridge> [ddnet] probably no one tests it 20:37 <+bridge> [ddnet] https://packages.debian.org/sid/ddnet see ports at the bottom 20:37 <+bridge> [ddnet] mips is le 20:39 <+bridge> [ddnet] @deen okay, so the idea behind OnCompletion is that it can close the file and thus check whether we wrote correctly? 20:39 <+bridge> [ddnet] if that fails, we just go to the generic error path? 20:40 <+bridge> [ddnet] eh, big endian, sorry 20:40 <+bridge> [ddnet] we're on little endian by default (x86, arm, …) 20:40 <+bridge> [ddnet] :frozen: 20:41 <+bridge> [ddnet] I changed OnCompletion? 20:41 <+bridge> [ddnet] yes, you did. and you're also claling it in the error path 20:42 <+bridge> [ddnet] whats the reason behind putting everything on a interface and on a class ? IServer CServer Iwathever and Cwathever 20:42 <+bridge> [ddnet] double work 20:42 <+bridge> [ddnet] so that they have a cleanly defined interface, in theory 20:42 <+bridge> [ddnet] @heinrich5991 oops, that seems unintentional, let me take another look 20:42 <+bridge> [ddnet] doesnt look at that clean :twintri: 20:42 <+bridge> [ddnet] doesnt look that clean :twintri: 20:43 <+bridge> [ddnet] it's kinda clean in vanilla, ddnet kinda walks over it due to casting it to CServer anyway 20:43 <+bridge> [ddnet] ah, the idea is that if you don't call OnCompletion then the updater is just stuck 20:43 <+bridge> [ddnet] and nothing will be shown 20:43 <+bridge> [ddnet] so you need to call it and OnCompletion can then do something depending on whether m_State is HTTP_DONE/ERROR/whatever 20:45 <+bridge> [ddnet] and before it was called in most error paths, just not all consistently 20:45 <+bridge> [ddnet] okay 21:10 <+bridge> [ddnet] ```cpp 21:10 <+bridge> [ddnet] void CServer::GetSolos(unsigned char *aPlayerSolos) 21:10 <+bridge> [ddnet] { 21:10 <+bridge> [ddnet] for(int i = 8; i > 0; i--) { 21:10 <+bridge> [ddnet] unsigned char x = 0; 21:10 <+bridge> [ddnet] for(int j = 8; j >= 0; j--) { 21:10 <+bridge> [ddnet] x |= m_aClients[64 - (i * 8 + j)].m_Solo << j; 21:10 <+bridge> [ddnet] } 21:10 <+bridge> [ddnet] aPlayerSolos[i] = x; 21:10 <+bridge> [ddnet] } 21:10 <+bridge> [ddnet] }``` is this clever, or really stupid 21:10 <+bridge> [ddnet] :twintri: 21:11 <+bridge> [ddnet] sounds much more expensive than the previous solution 21:11 <+bridge> [ddnet] wich one is it? 21:11 <+bridge> [ddnet] which 21:11 <+bridge> [ddnet] the cast? 21:11 <+bridge> [ddnet] yeah 21:12 <+bridge> [ddnet] xD 21:12 <+bridge> [ddnet] i spend 10 mins to do this 21:12 <+bridge> [ddnet] :twinbop: 21:13 <+bridge> [ddnet] also this limits us to 64p 21:13 <+bridge> [ddnet] yes 21:13 <+bridge> [ddnet] u can only send 1 int with the packet extension? 21:13 <+bridge> [ddnet] hmm 21:14 <+bridge> [ddnet] I'd guess you can send anything 21:14 <+bridge> [ddnet] i can put a int with the client size 21:17 <+bridge> [ddnet] this is more complicated than i expected 21:17 <+bridge> [ddnet] just to keep vanilla compat :cammostripes: 21:18 <+bridge> [ddnet] adding m_IsSolo to network.py is way easier and faster :monkaS: 21:18 <+bridge> [ddnet] not just vanilla compat, also compat with other clients and old ddnetclients, right? 21:19 <+bridge> [ddnet] @heinrich5991 the protocol extensions are the way to go for that, right? 21:22 <+bridge> [ddnet] hmm 21:22 <+bridge> [ddnet] better to add a new netobj with the protocol extensions 21:22 <+bridge> [ddnet] demos need that thing available in every tick 21:23 <+bridge> [ddnet] it would be cool to have packet extensions too 21:23 <+bridge> [ddnet] instead of brand new packet 21:25 <+bridge> [ddnet] 21:25 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/564531118439661579/tyf81c5c2vq21.png 21:28 <+bridge> [ddnet] @Ryozuki how would you do that? 21:30 <+bridge> [ddnet] I may be ignorant, but maybe checking the packet length 21:30 <+bridge> [ddnet] and having a default 21:30 <+bridge> [ddnet] if the server doesnt support the extended 21:30 <+bridge> [ddnet] it would work for this m_solo case maybe 23:32 <+bridge> [ddnet] it would probably work if you'd introduce a new netobject 23:32 <+bridge> [ddnet] old netobjects have a fixed size due to the way they're compressed 23:33 <+bridge> [ddnet] maybe add a `CNetObj_CharacterExtended` or so