00:15 <+bridge> [ddnet] <deen> ChillerDragon: it worked in CI and locally for me on 3 machines. do you have an old cmake version? how does it fail?
01:00 <+bridge> [ddnet] <cauldron> https://btp.uber.space/ddnet/ddnet_ideas.html 😅
01:48 <+ChillerDragon> @deen it first says "did the client crash" ? then it launches 2 clients they get stuck in the connecting screen. Then the shell script dies and the clients stay open
01:48 <+ChillerDragon> i tested only on arch
01:52 <+ChillerDragon> https://zillyhuhn.com/cs/.1655509926.png
01:53 <+ChillerDragon> my cmake is up to date i feel like its more a teeworlds settings issue. maybe it still loads some system settings. Well idk what is going on thats the point. So the pr got kinda stale because of that
02:10 <+bridge> [ddnet] <fokkonaut> i get a crash on client shutdown in sdl joystick stuff
02:10 <+bridge> [ddnet] <fokkonaut> i have a joystick connected which i dont use
02:10 <+bridge> [ddnet] <fokkonaut> in tw*
03:10 <+bridge> [ddnet] <Tater> If using this character is bannable why do we allow it to exist https://discord.com/channels/252358080522747904/779761780129005568/987422395671392276
08:02 <+bridge> [ddnet] <Jupstar> any crash logs for @Robyt3 ?
08:17 <+bridge> [ddnet] <murpi> theres no system to ban clantags
09:18 <+ChillerDragon> if my pointer is pointing to `0xfffffffffffffffc` thats bad i guess? Its a bit high ._.
09:20 <+bridge> [ddnet] <Jupstar> yeah doubtfully used as a real memory address, even if its virtual
09:21 <+bridge> [ddnet] <Jupstar> r u subtracting from a nullptr or smth xd
09:21 <+ChillerDragon> so who pooped in ma pointer? -._
09:21 <+ChillerDragon> yes i am
09:21 <+ChillerDragon> OMG YES I AM
09:22 <+ChillerDragon> omg jopstar u so smart
09:22 <+ChillerDragon> send new trading advice i lost this months paycheck and rent on stonk market 
09:23 <+ChillerDragon> aaaaaaaaaaaaa finally
09:23 <+ChillerDragon> ok i guess i was just tired yesterday night
09:23 <+ChillerDragon> such a nobrainer haha
09:28 <+bridge> [ddnet] <Jupstar> dunno hard to say, rtx 4090 might be next hype. else there isnt smth special rn xd
09:28 <+ChillerDragon> nvodia
09:29 <+ChillerDragon> i feel there is something fundamentally wrong in my strat of writing tests
09:29 <+ChillerDragon> i run the program and save the output as test xd
09:29 <+ChillerDragon> now i broke my tests but the output looks actually better :D 
09:30 <+ChillerDragon> its more a insurance of not changing the output than it being correct
09:36 <+ChillerDragon> how did neither asan or clang complain that i was substracting from a nullptr?!
09:36 <+ChillerDragon> jupstar go fix asan
09:37 <+bridge> [ddnet] <Jupstar> do we ignore nullptr claculations?
09:37 <+ChillerDragon> doubt
09:37 <+ChillerDragon> its probably asan being bad and waiting for ur pr
09:37 <+bridge> [ddnet] <Jupstar> null:json.c
09:37 <+bridge> [ddnet] <Jupstar> 
09:37 <+bridge> [ddnet] <Jupstar> maybe the filter is wrong?
09:38 <+ChillerDragon> ou
09:38 <+bridge> [ddnet] <Jupstar> or shift-base:pnglite.c is it probably
09:38 <+ChillerDragon> lemme try in 1 min
09:45 <+bridge> [ddnet] <chillerdragon> ```C
09:45 <+bridge> [ddnet] <chillerdragon> static unsigned const short *spShort = nullptr;
09:45 <+bridge> [ddnet] <chillerdragon> spShort -= 1337;
09:45 <+bridge> [ddnet] <chillerdragon> printf("spShort=%p\n", spShort);
09:45 <+bridge> [ddnet] <chillerdragon> ```
09:46 <+ChillerDragon> ah cmn clang tidy could warn there
09:46 <+ChillerDragon> ah wait asan does!
09:47 <+ChillerDragon> maybe i didnt see it earlier in the flood of opengl errors -.-
09:47 <+bridge> [ddnet] <Jupstar> how bout not using opengl < 3.3
09:47 <+ChillerDragon> old but gold
09:47 <+bridge> [ddnet] <Jupstar> the old backends suck
09:47 <+bridge> [ddnet] <Jupstar> i'd love to remove this bloat
09:47 <+ChillerDragon> idk i got some freezes
09:48 <+ChillerDragon> and i panic downgraded again
09:48 <+bridge> [ddnet] <Jupstar> vulkan is legend
09:57 <+bridge> [ddnet] <chillerdragon> omg poggies finally setup matrix in weechat lets see how it performs
09:58 <+bridge> [ddnet] <chillerdragon> https://zillyhuhn.com/cs/.1655539076.png
09:58 <+bridge> [ddnet] <chillerdragon> user list looks a bit cursed \:D
10:01 <+bridge> [ddnet] <chillerdragon> ah nice i can see github notifications here!
10:06 <+bridge> [ddnet] <chillerdragon> #990 \:justatest\:
10:06 <+bridge> [ddnet] <chillerdragon> meh still no bot
10:06 <+bridge> [ddnet] <chillerdragon> a
10:13 <+bridge> [ddnet] <chillerdragon> ez rank1 ddnet fork https://zillyhuhn.com/cs/.1655539965.png
10:28 <+bridge> [ddnet] <@unexploredtest:kde.org> ChillerTiger? xd
10:34 <+ChillerDragon> its not my mom i swear
10:47 <+ChillerDragon> I wonder if pressing ctrl+c on `./scripts/fix_style.py` could delete code if you kill it while its writing. Or is ctrl+c gracefully enough?
10:48 <+bridge> [ddnet] <Jupstar> probably yes
10:48 <+ChillerDragon> yes wat
10:48 <+ChillerDragon> god bad?
10:48 <+bridge> [ddnet] <Jupstar> maybe u cannot even prevent it with a sigkill
10:48 <+ChillerDragon> so robust
10:48 <+bridge> [ddnet] <Jupstar> maybe it sends one buffer to kernel
10:48 <+ChillerDragon> yea its python u cant kill that
10:48 <+bridge> [ddnet] <Jupstar> and then its not in user space anymore
10:48 <+bridge> [ddnet] <Jupstar> (i am not sure about it, just speculation)
10:49 <+bridge> [ddnet] <Jupstar> well i mean clang-format
10:49 <+bridge> [ddnet] <Jupstar> not the script itself
10:49 <+ChillerDragon> fat python probably takes longer to realize a sigkill is coming than the clang takes to fix the format axaxax
11:34 <+ChillerDragon> `comp=-194 'client2: what??!?!?' 'client2: what??!?!?'` any idea why the two single quoted string have a `str_comp` of -194? xd
11:35 <+ChillerDragon> `dbg_msg("chiller", "comp=%d 'client2: what??!?!?' '%s'", str_comp_nocase("client2: what??!?!?", aBuf), aBuf);`
11:36 <+bridge> [ddnet] <Jupstar> probs how far the characters are "away" from each other mathematically
11:37 <+ChillerDragon> yes
11:37 <+ChillerDragon> but arent those strings identical?
11:38 <+ChillerDragon> `str_endswith(aBuf, "?")` returns `0`._.
11:39 <+ChillerDragon> i feel like there is corrupted memory or shit but then it should print something funny 
11:39 <+bridge> [ddnet] <Jupstar> print both strings as hexa codes then we know
11:39 <+ChillerDragon> any issue with this? `aBuf[str_length(aBuf) - 1] = '\0';`
11:40 <+ChillerDragon> is there some str_hex in tw?
11:40 <+ChillerDragon> there is
11:40 <+bridge> [ddnet] <Jupstar> looks wrong yeah
11:40 <+bridge> [ddnet] <Jupstar> strlen should be without termination null already
11:42 <+ChillerDragon> it somewhat worked well for me so far to chop off the last char
11:42 <+ChillerDragon> until i tocuhed it again
11:42 <+ChillerDragon> OMG THERE IS A C2
11:42 <+ChillerDragon> who dis bitsh xd
11:43 <+ChillerDragon> https://paste.zillyhuhn.com/z7
11:43 <+ChillerDragon> hexorman
11:43 <+bridge> [ddnet] <Jupstar> ez
11:43 <+ChillerDragon> ou
11:43 <+bridge> [ddnet] <Jupstar> and guess what
11:43 <+bridge> [ddnet] <Jupstar> 0xc2
11:43 <+ChillerDragon> is ¿ maybe 2 bytes?
11:43 <+bridge> [ddnet] <Jupstar> = 194
11:44 <+bridge> [ddnet] <Jupstar> yes
11:44 <+bridge> [ddnet] <Jupstar> probably unicode already
11:44 <+ChillerDragon> omaagwd
11:44 <+ChillerDragon> fak
11:44 <+ChillerDragon> can str_len count that as 2?
11:44 <+ChillerDragon> lets see xd
11:45 <+ChillerDragon> indeed
11:45 <+ChillerDragon> wow @Jupstar the hex was sooo good advice
11:45 <+ChillerDragon> fixed
11:46 <+bridge> [ddnet] <chillerdragon> ```C
11:46 <+bridge> [ddnet] <chillerdragon> char aPuncts[][4] = {"?", "!", ".", ",", "¿", " "};
11:46 <+bridge> [ddnet] <chillerdragon> 	for(int i = 0; i < 10; i++) // strip up to 10 alternating punctuations
11:46 <+bridge> [ddnet] <chillerdragon> 		for(auto const &Punc : aPuncts)
11:46 <+bridge> [ddnet] <chillerdragon> 			while(str_endswith(aBuf, Punc)) // cut off punctuation and spaces
11:46 <+bridge> [ddnet] <chillerdragon> 				aBuf[str_length(aBuf) - str_length(Punc)] = '\0';
11:46 <+bridge> [ddnet] <chillerdragon> ```
11:47 <+ChillerDragon> my goal is todo "what?!?!?" -> "what" and it works. Not sure if thats a rly bad implementation xd
11:50 <+bridge> [ddnet] <Jupstar> we probs also have str_lenutf8
13:54 <+bridge> [ddnet] <Mʎɹ シ> What c++ standart ddnet use?
14:03 <+bridge> [ddnet] <Jupstar> 17 currently
14:10 <+bridge> [ddnet] <fokkonaut> @Not Keks appearently he found it :D
14:16 <+bridge> [ddnet] <Mʎɹ シ> starting from what version?
14:20 <+bridge> [ddnet] <Jupstar> dunno, 15 maybe
14:20 <+bridge> [ddnet] <Jupstar> smth around there
14:21 <+bridge> [ddnet] <Mʎɹ シ> Ok, thx
14:24 <+bridge> [ddnet] <Jupstar> nice github down
14:24 <+bridge> [ddnet] <Jupstar> thanks microsoft
15:15 <+ChillerDragon> told ya gh has more downtime than ddnet
15:16 <+ChillerDragon> ddnet just has the bigger/better devops team than micronobs
15:19 <+bridge> [ddnet] <Ryozuki> :BASEDHALT:
17:08 <+bridge> [ddnet] <@unexploredtest:kde.org> Your dummy then?
17:08 <+bridge> [ddnet] <@unexploredtest:kde.org> (<@749222324980416602_=5bquakenet=5d=20=43hiller=44ragon>)
18:07 <+bridge> [ddnet] <c0d3d3v> https://github.com/ddnet/ddnet/blob/cd8706a84ab928a37d11b2c9a18ca4e91c5007e5/src/engine/client/client.cpp#L1946
18:07 <+bridge> [ddnet] <c0d3d3v> 
18:07 <+bridge> [ddnet] <c0d3d3v> I'm I wrong or do I oversee something. But I think this check is partially wrong, because CSnapshot::MAX_PARTS is 64 but m_SnapshotParts[Conn] is `unsigned` and therefor only 32bit?
18:07 <+bridge> [ddnet] <c0d3d3v> https://github.com/ddnet/ddnet/blob/cd8706a84ab928a37d11b2c9a18ca4e91c5007e5/src/engine/client/client.cpp#L1946
18:07 <+bridge> [ddnet] <c0d3d3v> 
18:07 <+bridge> [ddnet] <c0d3d3v> Am I wrong or do I oversee something. But I think this check is partially wrong, because CSnapshot::MAX_PARTS is 64 but m_SnapshotParts[Conn] is `unsigned` and therefor only 32bit?
18:07 <+bridge> [ddnet] <c0d3d3v> https://github.com/ddnet/ddnet/blob/cd8706a84ab928a37d11b2c9a18ca4e91c5007e5/src/engine/client/client.cpp#L1946
18:07 <+bridge> [ddnet] <c0d3d3v> 
18:07 <+bridge> [ddnet] <c0d3d3v> Am I wrong or do I overlook something. But I think this check is partially wrong, because CSnapshot::MAX_PARTS is 64 but m_SnapshotParts[Conn] is `unsigned` and therefor only 32bit?
18:08 <+bridge> [ddnet] <c0d3d3v> https://github.com/ddnet/ddnet/blob/cd8706a84ab928a37d11b2c9a18ca4e91c5007e5/src/engine/client/client.cpp#L1946
18:08 <+bridge> [ddnet] <c0d3d3v> 
18:08 <+bridge> [ddnet] <c0d3d3v> Am I wrong or do I miss something. But I think this check is partially wrong, because CSnapshot::MAX_PARTS is 64 but m_SnapshotParts[Conn] is `unsigned` and therefor only 32bit?
18:46 <+bridge> [ddnet] <Ryozuki> https://github.com/rui314/mold/releases/tag/v1.3.0
18:58 <+bridge> [ddnet] <Learath2> Only the implementation and god himself knows what size unsigned is. So if we are making assumptions about it that’s bad
18:59 <+bridge> [ddnet] <ReiTW> God doesn't have programming knowledge @Learath2
18:59 <+bridge> [ddnet] <Learath2> If he exists he is supposed to be omnipotent and omnipresent. I’m sure he picked up some programming somewhere along the way
19:00 <+bridge> [ddnet] <ReiTW> Where's the manual of that language
19:02 <+bridge> [ddnet] <Chairn> Bible, Quran or Torah depending on your favorite religion
19:05 <+bridge> [ddnet] <Nouaa> :kekjpg:
19:09 <+bridge> [ddnet] <Chairn> hmmpf, can't comment on github...
19:53 <+bridge> [ddnet] <trml> @c0d3d3v btw, what did you mean by left/right and jump keypresses not being sent? I mean, cl_show_direction 1 will show those
20:49 <+bridge> [ddnet] <Jupstar> did we change smth about skins lately?
20:49 <+bridge> [ddnet] <Jupstar> another crash report that Graphics()->LoadPNG failed
20:49 <+bridge> [ddnet] <c0d3d3v> Clients only get the manipulated data from the server. So if the player is not allowed to press Right, the server will not send right to the clients... So If you are freezed the clients do not know what the player is pressing
20:50 <+bridge> [ddnet] <Jupstar> we had this before but since LTO is active the crash logs arent really useful
20:50 <+bridge> [ddnet] <c0d3d3v> I see no real use for LTO anyway
20:50 <+bridge> [ddnet] <trml> oh, during freeze, yes thats true
20:51 <+bridge> [ddnet] <c0d3d3v> the clients also do know when you press fire...
20:51 <+bridge> [ddnet] <c0d3d3v> but only when you are allowed to press
20:51 <+bridge> [ddnet] <Jupstar> he uses skins.tw
20:52 <+bridge> [ddnet] <c0d3d3v> AttackTick
20:52 <+bridge> [ddnet] <trml> how? attacktick is sent, but I think its only the last time you pressed
20:52 <+bridge> [ddnet] <c0d3d3v> yes
20:52 <+bridge> [ddnet] <trml> i.e., you dont know if someone presses fire
20:53 <+bridge> [ddnet] <c0d3d3v> thats more or less the same for jump. Because you can also not use the jump information to say that the player is really pressing jump. Just a little better then fire
20:53 <+bridge> [ddnet] <Chairn> isn't that the new readfile function?
20:54 <+bridge> [ddnet] <trml> hmm, I thought one of the two jump bits indicated jump press
20:54 <+bridge> [ddnet] <c0d3d3v> yes the first
20:54 <+bridge> [ddnet] <c0d3d3v> but You are not always allowed to press jumpt
20:54 <+bridge> [ddnet] <c0d3d3v> but You are not always allowed to press jump
20:54 <+bridge> [ddnet] <c0d3d3v> ... but it is better then fire
20:55 <+bridge> [ddnet] <c0d3d3v> I would also like to have all real input data in the clients, but on the other hand, that would not really improve gameplay
20:55 <+bridge> [ddnet] <trml> yeah, checked it again, it doesn't anymore after you used the last jump
20:55 <+bridge> [ddnet] <Jupstar> i assume its pnglite crashing bcs of an abitary skin or some weird file format
20:56 <+bridge> [ddnet] <c0d3d3v> jup
20:56 <+bridge> [ddnet] <Jupstar> skins.tw is a untested wildcard, and pnglite sucks
20:56 <+bridge> [ddnet] <Jupstar> review #5385 and merge it for 16.2
20:56 <+bridge> [ddnet] <DDNet> https://github.com/ddnet/ddnet/pull/5385
20:59 <+bridge> [ddnet] <trml> that flag might still useful enough for cl_show_direction though (if they are shown if freeze at least)
21:03 <+bridge> [ddnet] <trml> would probably be most useful showing in freeze and/or prediction. btw, is sending real input in freeze planned for next release? I guess it would require some alter changes to char/ddnetchar netobjects if not
21:03 <+bridge> [ddnet] <trml> additional*
21:46 <+bridge> [ddnet] <yume> when add 45 degree slides
21:56 <+bridge> [ddnet] <Itube / Mustafa> big issues: if u do " : bozos" u ping everyone
23:26 <+bridge> [ddnet] <c0d3d3v> not planed for 16.2
23:29 <+bridge> [ddnet] <c0d3d3v> I tried to rework the gamecore to be able to send the real inputs in the charactercore without manipulating them. But it turned out to be a bad idea, because to get the physics correct, so that it works as before is hard, if you do not want to have two diffrent gamecores (one for server, one for client)
23:32 <+bridge> [ddnet] <c0d3d3v> The easiest solution would be to send the real inputs additionally. I had an PR open to send the real Key presses to make the show_direction option show the real presses. But heinrich wanted that I try to refactor gamecore so that we do not need to send them twice (the real and the manipulated)... But I did give up, maybe someone wants to try that in future, or we send them additional.
23:34 <+bridge> [ddnet] <c0d3d3v> <https://github.com/ddnet/ddnet/pull/5148>
23:34 <+bridge> [ddnet] <trml> I actually try to do the exact same thing some time ago (and also avoiding the duplicated input) 😄 however didnt quite finish it so never PRed
23:38 <+bridge> [ddnet] <trml> I could try to take a look again one day to see if I have any ideas (wanted to check if you were working on it atm first)
23:39 <+bridge> [ddnet] <trml> but its perhaps possible that the problems I ran into then are the same as you did now (I think it was getting jump to predict correctly)
23:39 <+bridge> [ddnet] <trml> tried*
23:40 <+bridge> [ddnet] <trml> as, a year or two ago, so don't remember exactly
23:41 <+bridge> [ddnet] <trml> as in*
23:42 <+bridge> [ddnet] <c0d3d3v> I  first tried to do it for jump, part of that is also in master. I did only a small step and thought this could not have changed anything xD And did have 2 physics changes in it, that I needed to fix afterwards 😄 Its really critical to change something input related ^^and hard to test all physics. We would have to write units tests before
23:43 <+bridge> [ddnet] <c0d3d3v> I  first tried to do it for jump, part of that is also in master. I did only a small step and thought this could not have changed anything xD And did have 2 physics changes in it, that I needed to fix afterwards 😄 Its really critical to change something input related ^^and hard to test all physics. We would have to write unit tests before
23:46 <+bridge> [ddnet] <trml> absolutely. this is why I mostly only dare to touch client side stuff related to this 😄
23:47 <+bridge> [ddnet] <trml> although in the long run it would be great to cleanup server physics code a bit