00:16 < eeeee> i played a bit with freeze prediction and was like ewww when i tried ddnet client w/o it
00:16 <@deen> sounds better than what we had
00:16 < eeeee> but after a while you kinda stop noticing it
00:17 < eeeee> also while you might not use it for prediction you can still have the freeze timer on client
00:17 < eeeee> so that you can draw the ice cube thing
00:17 < eeeee> not sure if you've seen it
00:19 <@deen> ah yeah
00:19 <@deen> I've tried that some time as well
00:19 <@deen> don't even remember how it was
00:27 < Nimda> Reason by mikey12 just released on Brutal at 2014-12-05 19:11
00:56 < ddnet-commits> [ddnet] def- pushed 1 new commit to DDRace64: http://git.io/aaEQGA
00:56 < ddnet-commits> ddnet/DDRace64 2e7e4cf def: Code piece to convert race stoppers to ddrace stoppers
01:09 <@deen> http://bellard.org/bpg/
01:09 <@deen> Full of segfaults, not sure if I should report them
01:10 <@deen> tried to fix them myself but it's weird
01:11 <@deen> really cool format though
01:37 <@heinrich5991> deen: why not report them?
01:40 <@deen> heinrich5991: really new tool, proably not meant to be stable or bug free
01:40 <@deen> it crashed even on a random png for me
01:41 <@heinrich5991> mhk
01:41 <@deen> so he probably knows that it's unstable
01:41 <@deen> did you see the demos?
01:41 <@deen> http://bellard.org/bpg/lena.html
01:41 <@deen> pretty impressive
01:42 < eeeee> yeah
01:42 <@deen> much smaller than webp even
01:42 <@deen> he used emscripten to make the javascript decoder^^
01:42 <@heinrich5991> :)
01:42 <@deen> oh yeah, and Fabrice Bellard is probably very well aware of fuzzing, since he made ffmpeg
01:42 < eeeee> makes sense, they say it's usually faster than handcoded js
01:43 <@deen> and google is hugely involved in fuzzing ffmpeg
01:43 <@deen> so once this goes stable i'm pretty sure it will be fine
01:44 < RafaelFF> Hi there. Sorry to interrupt you guys here. I have a question about programming in Teeworlds, and I'm bringing it here hoping that someone with more knowledge than can figure out.
01:44 < RafaelFF> Currently storage.cfg is searched in same folder as the TW binary or in a path passed as first argument (argv[0]). That's what says "src/engine/shared/storage.cpp"
01:44 <@deen> and BPG can be hardware accelerated with existing hardware!
01:44 < RafaelFF> Does anyone how I could set a specific folder for storage.cpp or even pass it the source storage.cpp?
01:44 <@deen> now i want to build something with opus and BPG
01:44 < eeeee> can't accelerate shit until browsers support it though
01:45 <@deen> eeeee: yeah, of course
01:45 <@deen> hi RafaelFF 
01:45 < eeeee> wanna add it to teeworlds?
01:45 < eeeee> could compress mapres (and maps themselves since it supports lossless)
01:46 <@deen> eeeee: can't imagine that it works well with maps :P
01:46 < eeeee> why not?
01:46 <@deen> mapres would be cool, yes
01:46 <@deen> do maps have the same characteristics as images?
01:46 < eeeee> same as png for sure
01:46 <@deen> hm, maybe BPG is not even fit for mapres
01:47 <@deen> it's mostly supposed to be used as lossy 
01:47 < eeeee> yeah did you find any benchmarks for lossless mode?
01:47 <@deen> eeeee: nope
01:47 < eeeee> oh the alpha channel ones are lossless
01:47 < eeeee> http://bellard.org/bpg/gallery2.html
01:47 <@deen> but Bellard himself said to stay away from lossless 
01:48 < eeeee> hm okay then
01:48 <@deen> RafaelFF: cd to the directory and run TW from there?
01:51 < eeeee> man i wish my camera supported bpg
01:52 <@deen> haha, what?
01:52 < eeeee> currently i have to save 30-megabyte raw images to get full bit depth
01:52 <@deen> aaah
01:52 <@deen> yeah, BPG supports nice bit depths
01:52 < RafaelFF> deen: That's feasible, indeed.  But currently the binary is already in /usr/bin/teeworlds and that's the binary called to start TW. So I would like to avoid this kind of workaround and make it the with nice way (build with correct path set)...
01:53 <@deen> RafaelFF: just call it as "teeworlds"
01:53 <@deen> without path
01:53 <@deen> or PATH=/usr/bin/ teeworlds
01:53 <@deen> I've always copied the binary into the directory where I want to run it
01:53 <@deen> because I recompile it all the time anyway
02:00 <@deen> eeeee: tried to compile ddnet with emscripten today. i think the freetype fixes are not up yet, are they?
02:02 < eeeee> hmm
02:03 < eeeee> yeah i think i stopped pushing out stuff at some point
02:03 < eeeee> lemme do that
02:03 < eeeee> deen: no it should all be there
02:04 < eeeee> can you elaborate on what was the problem?
02:04 <@deen> eeeee: just saw freetype header error messages scroll by
02:04 <@deen> actually tested it on another computer, don't have access to it
02:07 < eeeee> did the normal non-js build succeed?
02:07 <@deen> yes
02:07 <@deen> did it in another directory
02:08 <@deen> but there it workeed
02:08 <@deen> should have done it in the ddnet-js directory too?
02:08 < eeeee> yeah
02:08 <@deen> then update your documentation, it said bam -c
02:09 < eeeee> well i mean you don't actually have to do this
02:09 < eeeee> and it doesn't compile anyway
02:09 < eeeee> but you'd be able to see if it complains about freetype
02:10 < eeeee> because both js and non-js should use the same headers
02:11 <@deen> hm, ok
02:14 < eeeee> i'll try to fix the compilation so that you can actually build a semi-working x86 client from that source
02:15 <@deen> oh, so we maybe just didn't have x86 freetype libraries?
02:16 < eeeee> only windows freetype libs are bundled
02:17 < eeeee> on linux it should use system ones
02:17 < eeeee> which you should have had if build succeeded in another dir
02:17 <@deen> but other build was x86_64
02:20 < eeeee> hmm idk
02:21 < eeeee> how would the actual lib even matter during the compilation
02:21 < eeeee> it only uses the bundled headers
02:21 <@deen> no idea
02:22 < eeeee> maybe in your case it tried to use system headers though
03:17 <@deen> hi maple 
03:17 < maple> hey
03:21 <@deen> nice, my wavpack segfault made it to the tropy case: http://lcamtuf.coredump.cx/afl/
03:25 < maple> grats
05:52 < Maple> lol mikey doesnt want skeith to have top1's so he beat careless with me again
11:37 < Nimda> Snowzz by Ama & iCookie just released on Moderate at 2014-12-06 11:34
12:02 <@deen> oh, that's cool. you can analyze coredumps in gdb! Why didn't you tell me, EastByte ?
12:04 <@EastByte> that's why I wanted you to store coredumps :P
12:04 <@deen> enabled them on all servers
12:04 <@deen> but do i need to restart the run scripts?
12:04 <@EastByte> I don't think so
12:05 <@deen> let's hope
12:05 <@deen> Some big attack on DDNet was announced so I'd like to prepare a bit at least
12:06 <@EastByte> you should add an assert rcon command for testing
12:06 <@EastByte> I always had problems with coredumps
12:06 <@EastByte> arch linux is doing strange things and in the end never stores them
12:06 <@EastByte> better test it :)
12:06 <@deen> yeah, I've seen that with afl-fuzz as well
12:06 <@deen> had to set something in archlinux so coredumps don't get redirected to systemd
12:07 <@deen> echo core > /proc/sys/kernel/core_pattern
12:07 <@EastByte> I tried to use coredumpctl
12:07 <@EastByte> but the only time I needed the coredump, it didnt store it
12:08 <@EastByte> like always
12:08 <@deen> the ddnet server fuzzing didn't lead to any results
12:08 <@deen> instead I found a segfault in zsh
12:08 <@deen> ^^
12:08 <@EastByte> isn't fuzzing more like bruteforcing?
12:08 <@deen> what I did was bruteforce fuzzing on ddnet server, yes
12:08 <@deen> but afl is a bit more intelligent regularly
12:08 <@EastByte> I mean, all commands are invalid anyways
12:09 <@deen> it analyzes the paths taken through the program and chooses the interesting ones
12:09 <@EastByte> I don't thinkyou can find crashes like that in tw
12:09 <@EastByte> hm
12:10 <@EastByte> so it's not 'dumb' bruteforcing
12:10 <@deen> well, making ddnet server crash with maps was easy :P
12:10 <@EastByte> ...
12:10 <@deen> it found hundreds of separate segfaults
12:10 <@deen> i tried fixing a few, but not sure how to do it...
12:11 <@EastByte> "I don't care about vulns in glibc, give me teeworlds segfaults" :D
12:11 <@deen> says who?
12:11 <@EastByte> relating to "it found hundreds of separate segfaults"
12:11 <@deen> don't understand
12:11 <@EastByte> no one said it
12:12 <@EastByte> nvm
12:17 <@deen> ok, didn't work
12:17 <@deen> have to restart the run scripts to get the new coredump settings
12:28 <@deen> seems to have worked, should have coredumps on ddnet servers now
12:29 <@EastByte> great
13:32 <@deen> well, got a few coredumps already
13:32 <@deen> but without debug symbols they're not that useful^^
13:32 <@EastByte> haha
13:32 <@deen> #1  0x000000000043073b in ?? ()
13:32 <@deen> yay!
13:32 <@deen> hi Savander 
13:33 <@deen> debug symbols would make the server slower I presume
13:33 <@EastByte> I not sure whether using bam debug might slow it down
13:33 <@EastByte> debug symbols it self I don't think so
13:33 <@EastByte> they have nothing to do with runtime
13:34 <@deen> hm, then I should just try adding -g
13:34 <@EastByte> ^
13:35 <@deen> EastByte: full server on EUR
13:35 <@deen> EastByte: also, chairn says "some servers appear twice with different ip"
13:36 <@EastByte> whaat
13:36 < Savander> hi :)
13:36 <@deen> in the serverlist i guess
13:37 <@deen> hm, only EUR segfaults all the time^^
13:37 <@deen> EastByte: ah, EUR runs an old server version without my fixes!
13:38 <@deen> EastByte: you should update your repo
13:38 <@EastByte> well I wanted to keep multibind uptodate
13:38 <@EastByte> okay mom
13:39 <@EastByte> now it's up to date
13:40 <@EastByte> hm I can't see any eur server twice
13:41 <@deen> ask Chairn I guess
13:43 <@deen> hm, EUR still the only one to coredump
13:43 <@EastByte> okay chairn was talking about the fav list
13:44 <@EastByte> so he added some twice
13:44 <@deen> ^^
13:45 <@EastByte> "some are more laggy then others" ^^
13:48 <@deen> huh, I use -g and see no debug symbols
13:48 <@EastByte> meh
13:50 <@deen> ah, my bad^^
13:50 <@deen> I strip the binaries :P
13:54 <@EastByte> haha
13:55 <@deen> FifoConsole::ListenFifoThread (pUser=0xc26d50) at src/engine/shared/fifoconsole.cpp:28
13:56 <@deen> this segfaults still
13:56 <@deen> while (!pData->m_pFifoFile || str_comp(pData->m_pFifoFile, "") == 0)
13:56 <@deen> the call to str_comp segfaults, hm
13:56 <@deen> (somewhere deep in libc)
13:57 <@deen> probably because the program has shut down already and this thread is still running
14:01 <@deen> should probably nicely tell the thread to stop running before it gets there
14:07 <@EastByte> deen: when overlay entities is on 100%, still everything is rendered?
14:07 <@deen> you mean the invisible ones?
14:07 <@deen> no
14:07 <@EastByte> quads also ignored?
14:07 <@deen> i have check for that somewhere
14:08 <@deen> yeah
14:08 <@EastByte> because it's laggy for me 
14:08 <@deen> lots of teleporters?
14:08 <@deen> text on teleporters renders slowly
14:08 <@EastByte> hm not sure
14:08 <@EastByte> the lagg was issued by the snow
14:08 <@deen> ah
14:09 <@EastByte> but that shouldnt happen when overlay entities 100%
14:09 <@deen> i just tested
14:09 <@deen> I assume you're talking about the Snowzz map
14:09 <@EastByte> ea
14:09 <@EastByte> yea
14:10 <@deen> with HD and quads on: 145 fps
14:10 <@deen> HD off: 280 fps
14:10 <@deen> quads off: 490 fps
14:10 <@deen> entities: 500 fps
14:10 <@deen> so it seems to work fine 
14:11 <@deen> maybe you have overlay_entities on 99^^
14:11 <@EastByte> hm now I can't reproduce it
14:14 <@EastByte> maybe it was 99, not sure
14:14 <@deen> i'm surprised I can get 500 fps =)
14:14 <@EastByte> ^^
14:15 <@deen> EastByte: try merging again please
14:15 < ddnet-commits> [ddnet] def- pushed 1 new commit to DDRace64: http://git.io/j4jwvg
14:15 < ddnet-commits> ddnet/DDRace64 b334c46 def: Try to explicitly close fifo console
14:15 <@deen> have to test on EUR since only it segfaults^^
14:16 <@EastByte> done
14:16 <@heinrich5991> have you checked whether it finds the 0.6.3 bug?
14:16 <@deen> heinrich5991: yes, didn't find it^^
14:16 <@heinrich5991> and yes, the map format is horrible un-error-checked
14:16 <@heinrich5991> meh
14:16 <@deen> maybe the number format is too complicated for it
14:16 <@deen> teeworlds numbers are variable size
14:16 <@deen> it tries fixed number size arithmetic
14:17 <@deen> and my testing methodology was hacked together for networking
14:17 <@deen> would need file input instead of network input for a proper fuzz
14:19 < ddnet-commits> [ddnet] def- pushed 1 new commit to DDRace64: http://git.io/wS2MSg
14:19 < ddnet-commits> ddnet/DDRace64 6b1666d def: Next try
14:20 <@deen> ok, that one should work^^
14:21 <@EastByte> uptodate
14:22 <@deen> i don't get it...
14:22 <@deen> anyone else have a fix?
14:23 <@EastByte> busy
14:35 < ddnet-commits> [ddnet] def- pushed 1 new commit to DDRace64: http://git.io/Vp4-zQ
14:35 < ddnet-commits> ddnet/DDRace64 8275f2d def: Finally working...
14:37 <@EastByte> uptodate
14:37 <@deen> EastByte: I tested manually already, it works. thanks
14:37 <@EastByte> okay....
14:37 <@deen> didn't want you to upload 20 more versions^^
14:37 <@deen> expected this to be easier
14:37 < Nimda> Hookthrough by [A] Awesome & ٭ıƞdex'<3 just released on Moderate at 2014-12-06 14:34
14:38 <@EastByte> git fetch def && git merge def/DDRace64 && git push ddneteast multibind
14:38 <@deen> yay, map testing area looks pretty cleaned up: http://forum.ddnet.tw/viewforum.php?f=9
14:39 <@EastByte> I guess we are prepared for further attacks? :D
14:39 <@EastByte> oh wow
14:40 <@deen> oldest unreleased map has been in forum for 10 days
14:40 <@deen> that's good =)
14:40 <@deen> shouldn't have 2 months waiting times
14:41 <@deen> i'm wondering if we'll get any christmas special tournament^^
14:46 <@EastByte> hopefully
16:01 <@deen> my testing methodology sucked, heinrich5991 
16:01 <@deen> Forgot that the kernel just drops udp packets with wrong checksums
16:01 <@heinrich5991> yes
16:01 <@deen> now i'm recalculating the checksum
16:01 <@heinrich5991> or just send random UDP payloads instead of random UDP packets?
16:02 <@deen> still have to recalculate the checksum if i change the payload, right?
16:03 <@heinrich5991> yes, but why don't you let the kernel do that?
16:04 <@deen> i'm just using tcpreplay right now
16:04 <@heinrich5991> ah
16:05 <@deen> really fun to watch now
16:05 <@deen> how the bits get flipped everywhere
16:05 <@deen> even visible in the log output of the server
16:07 <@deen> proper way would be to adapt afl-fuzz to work with network
16:08 <@deen> have to understand it a bit better for that I think
16:09 <@heinrich5991> deen: if you have specific questions, I can probably answer them
16:09 <@deen> about afl-fuzz?^^
16:09 <@heinrich5991> nah
16:09 <@heinrich5991> about TW network I thought
16:09 <@deen> no, i have to understand afl-fuzz
16:09 <@heinrich5991> ah
16:09 <@deen> how does it read out the instrumentation output
16:10 <@deen> maybe I should just try it, might be worthwhile to fuzz other network programs as well
16:11 <@deen> any thoughts on moving a few servers up to 256 players?
16:11 <@deen> block in GER, block in Chile and Tournament in GER probably
16:12 <@deen> that's where we regularly get full servers
16:17 < ddnet-commits> [ddnet] def- pushed 1 new commit to DDRace64: http://git.io/6Ph4OA
16:17 < ddnet-commits> ddnet/DDRace64 366f028 def: Fuzzing options
17:24 <@deen> working 128 player scoreboard in 128players branch
17:24 <@deen> and no more coredumps so far
17:50 <@EastByte> cool
17:50 <@EastByte> "Hookthrough" is a nice map bytheway
17:51 <@EastByte> simple and short
17:51 <@EastByte> and tricky for noobies
17:53 <@deen> =)
17:53 <@deen> Glad to hear
17:53 <@deen> I've seen that Index has improved its design
19:20 < ddnet-commits> [ddnet] def- pushed 1 new commit to DDRace64: http://git.io/k2kT6g
19:20 < ddnet-commits> ddnet/DDRace64 9e1ed24 def: Fuzzable server
19:30 < ddnet-commits> [ddnet] def- pushed 1 new commit to DDRace64: http://git.io/B13ueg
19:30 < ddnet-commits> ddnet/DDRace64 f32b092 def: Fuzzing optimization
19:43 <@heinrich5991> deen: how much was huffman_init?
19:43 <@deen> heinrich5991: 50%
19:44 <@heinrich5991> what is this, in seconds?
19:44 <@deen> but I'm just starting the server, connecting to it, and shutting the server down again
19:44 <@deen> about 20 ms i think
19:46 < ddnet-commits> [ddnet] def- pushed 1 new commit to DDRace64: http://git.io/PNr8hA
19:46 < ddnet-commits> ddnet/DDRace64 6ecd02d def: No threaded debug output with fuzzing
19:58 <@deen> running it on vanilla 0.6 as well now
19:58 <@deen> starts up twice as fast as ddnet
20:00 <@deen> the only result so far: there are a huge amount of paths in the server
20:00 <@deen> is*
20:01 <@deen> more than I've seen in audio codecs
23:38 < eeeee> what, they're now announcing attacks ahead of time?
23:38 < eeeee> those kids sure have fun playing a terrorist organization :D
23:40 <@deen> they don't announce the attacks to me
23:40 <@deen> i think they're more internally planning
23:41 <@deen> and i just hear birds sing
23:43 < eeeee> oh i see. didn't know you have an intelligence network established.
23:43 <@deen> haha
23:43 < eeeee> do they at least claim the responisibility for the attacks after they happen?
23:43 <@deen> it's more the other way around. some of their people feel bad about it, but don't dare to speak out, so they come to me
23:43 < eeeee> releasing videos of masked men on youtube with arabic letters and stuff
23:43 <@deen> don't know, there were no major attacks recently
23:43 <@deen> ^^
23:44 <@deen> Teerrorists
23:44 < eeeee> :D
23:49 <@deen> 2 million executions of the server now, now crashes. nice to see
23:49 <@deen> no*
23:57 <@heinrich5991> deen: sorry for the nag: have you found the bug yet?
23:59 <@deen> heinrich5991: forgot to add it back again^^
23:59 <@deen> heinrich5991: don't think I would find it (within a few days), because ints are variable size in the protocol
23:59 <@heinrich5991> oh okay