00:01 <+bridge> [ddnet] <c0d3d3v> I will try to bisect it tomorrow, if no one else found the problem
00:05 <+bridge> [ddnet] <cauldron> https://ddnet.tw/downloads/#16.1 😅
00:15 <+bridge> [ddnet] <deen> We should try to make the new version work well and recommend everyone to use it. Old versions won't get fixes and other improvements
01:04 <+bridge> [ddnet] <fokkonaut> 16.2 ping doesnt get updated
01:04 <+bridge> [ddnet] <fokkonaut> https://cdn.discordapp.com/attachments/293493549758939136/994016052528816210/unknown.png
02:05 <+PickleRick> where can i find tutorials for brutal servers
02:15 <+bridge> [ddnet] <Patiga> what kind of tutorials are you looking for?
02:16 <+bridge> [ddnet] <Patiga> play-throughs are on youtube, many mechanics are explained on the wiki :)
02:23 <+bridge> [ddnet] <Sorah> https://github.com/ddnet/ddnet/issues/4508
13:58 < ***> Buffer Playback...
13:58 <+bridge> [11:45:22] [ddnet] <Chairn> oO
13:58 <+bridge> [11:45:27] [ddnet] <Chairn> https://github.com/ddnet/ddnet/runs/7212109106?check_suite_focus=true
13:58 <+bridge> [11:45:36] [ddnet] <Chairn> <https://github.com/ddnet/ddnet/runs/7212109106?check_suite_focus=true>
13:58 <+bridge> [11:46:17] [ddnet] <Chairn> that looks completely unrelated to my pr, but looks frightening
13:58 <+bridge> [12:08:42] [ddnet] <Ryozuki> https://news.ycombinator.com/item?id=31993713
13:58 <+bridge> [12:08:54] [ddnet] <Ryozuki> https://www.openssl.org/news/secadv/20220705.txt
13:58 <+bridge> [12:09:03] [ddnet] <Ryozuki> > OpenSSL Security Advisory [5 July 2022]
13:58 <+bridge> [12:09:03] [ddnet] <Ryozuki> > =======================================
13:58 <+bridge> [12:09:04] [ddnet] <Ryozuki> > 
13:58 <+bridge> [12:09:06] [ddnet] <Ryozuki> > Heap memory corruption with RSA private key operation (CVE-2022-2274)
13:58 <+bridge> [12:09:07] [ddnet] <Ryozuki> > =====================================================================
13:58 <+bridge> [12:09:08] [ddnet] <Ryozuki> > 
13:58 <+bridge> [12:09:09] [ddnet] <Ryozuki> > Severity: High
13:58 <+bridge> [12:09:11] [ddnet] <Ryozuki> > 
13:58 <+bridge> [12:09:12] [ddnet] <Ryozuki> > The OpenSSL 3.0.4 release introduced a serious bug in the RSA
13:58 <+bridge> [12:09:13] [ddnet] <Ryozuki> > implementation for X86_64 CPUs supporting the AVX512IFMA instructions.
13:58 <+bridge> [12:09:15] [ddnet] <Ryozuki> > This issue makes the RSA implementation with 2048 bit private keys
13:58 <+bridge> [12:09:16] [ddnet] <Ryozuki> > incorrect on such machines and memory corruption will happen during
13:58 <+bridge> [12:09:17] [ddnet] <Ryozuki> > the computation. As a consequence of the memory corruption an attacker
13:58 <+bridge> [12:09:20] [ddnet] <Ryozuki> > may be able to trigger a remote code execution on the machine performing
13:58 <+bridge> [12:09:21] [ddnet] <Ryozuki> > the computation.
13:58 <+bridge> [12:09:24] [ddnet] <Ryozuki> :monkalaugh:
13:58 <+bridge> [12:40:14] [ddnet] <Learath2> Hm heap memory corruption
13:58 <+bridge> [12:40:52] [ddnet] <Learath2> And it's in the optimized codepath. I wonder if rust could have stopped this one
13:58 <+bridge> [12:44:04] [ddnet] <Chairn> looks more like they misused (or compiler did) some assembly instruction
13:58 <+bridge> [12:47:39] [ddnet] <heinrich5991> sounded like handrolled assembly, haven't investigated
13:58 <+bridge> [12:47:46] [ddnet] <heinrich5991> if that were the case, rust would not have helped
13:58 <+bridge> [13:07:54] [ddnet] <Ryozuki> Handrolled assembly generated by perl
13:58 <+bridge> [13:07:59] [ddnet] <Ryozuki> Work of art
13:58 < ***> Playback Complete.
14:23 <+bridge> [ddnet] <Ryozuki> https://cdn.discordapp.com/attachments/293493549758939136/994217039117942865/RDT_20220706_1422264600909581534588199.jpg
14:35 <+bridge> [ddnet] <Chairn> nice rant, but does he have any valid argument against c++?
15:46 <+bridge> [ddnet] <Nouaa> https://tenor.com/view/linus-linus-torvalds-nvidia-fuck-you-gif-18053606
16:02 <+bridge> [ddnet] <c0d3d3v> Turns out, it's always been that way O.o 😦
16:10 <+bridge> [ddnet] <ReiTW> obv scratch > c++
16:34 <+bridge> [ddnet] <Ryozuki> @ReiTW how is rust going
16:35 <+bridge> [ddnet] <ReiTW> fine, still have hard time to work with it, but just need more practice, ig i'll go on codingames to practice more
16:36 <+bridge> [ddnet] <ReiTW> the syntax sometimes can be very difficult to read when you're beginning
16:37 <+bridge> [ddnet] <Ryozuki> yeah
16:39 <+bridge> [ddnet] <Ryozuki> recently did a bencode parser in nom
16:39 <+bridge> [ddnet] <Ryozuki> https://cdn.discordapp.com/attachments/293493549758939136/994251296053919784/unknown.png
16:39 <+bridge> [ddnet] <Ryozuki> :PepeA:
16:39 <+bridge> [ddnet] <Ryozuki> https://github.com/edg-l/nom-bencode
16:40 <+bridge> [ddnet] <Ryozuki> bencode is the stuff .torrent files are encoded as
16:49 <+bridge> [ddnet] <ReiTW> Still have hard time understanding the usage of lifetimes
16:50 <+bridge> [ddnet] <heinrich5991> what part of lifetimes do you struggle with?
16:50 <+bridge> [ddnet] <heinrich5991> when taking reference parameters? when passing them?
16:51 <+bridge> [ddnet] <Ryozuki> well lifetimes are hard to understand itself
16:51 <+bridge> [ddnet] <Ryozuki> like when learning pointers
16:51 <+bridge> [ddnet] <Ryozuki> the best way is to practice
16:51 <+bridge> [ddnet] <Ryozuki> atleast for me
16:52 <+bridge> [ddnet] <Ryozuki> i still struggle to wrap my head around https://doc.rust-lang.org/nomicon/hrtb.html sometimes
16:56 <+bridge> [ddnet] <Learath2> Weirdest part about lifetimes for me was probably `'static` meaning two different things in two contexts
16:57 <+bridge> [ddnet] <Learath2> As a trait bound it implies that the type does not contain any non static references, but as a reference lifetime it implies a reference lives for the entire duration of the program
16:57 <+bridge> [ddnet] <Learath2> Subtle but annoying difference 😛
16:58 <+bridge> [ddnet] <Learath2> I guess coercion and elision aren't exactly trivial either
16:59 <+bridge> [ddnet] <Ryozuki> oh yeah
16:59 <+bridge> [ddnet] <Ryozuki> where was the doc i had
16:59 <+bridge> [ddnet] <Ryozuki> it mentioned that
16:59 <+bridge> [ddnet] <Ryozuki> https://github.com/pretzelhammer/rust-blog/blob/master/posts/common-rust-lifetime-misconceptions.md
16:59 <+bridge> [ddnet] <Ryozuki> here
16:59 <+bridge> [ddnet] <Ryozuki> rly good document
17:00 <+bridge> [ddnet] <Ryozuki> https://cdn.discordapp.com/attachments/293493549758939136/994256423527661598/unknown.png
17:03 <+bridge> [ddnet] <Ryozuki> another interesting thing is phantom
17:03 <+bridge> [ddnet] <Ryozuki> https://doc.rust-lang.org/std/marker/struct.PhantomData.html
17:03 <+bridge> [ddnet] <Ryozuki> https://doc.rust-lang.org/nomicon/phantom-data.html
17:28 <+bridge> [ddnet] <Voxel> "c++ sux because bad programmers use it"
17:28 <+bridge> [ddnet] <Voxel> "lego sux because ameture builders use it"
17:40 <+bridge> [ddnet] <k2d222> It is a valid argument imo, I see poor c++ libs every other day with many bugs, mem leaks, etc.
17:40 <+bridge> [ddnet] <k2d222> rust on the other hand attracts a lot of talented programmers because it is a bit niche and sexy, and has a high barrier to entry compared to c++ and it makes it harder to write bad code, and I tend to trust more an unknown lib because of that
17:41 <+bridge> [ddnet] <Jupstar> and yet you use javascript everywhere xd, with infinite bugs and infinite memory usage
17:41 <+bridge> [ddnet] <k2d222> but that's no question of choice XD
17:43 <+bridge> [ddnet] <Jupstar> from my personal experience the best u can do is keep your code modular and easy
17:43 <+bridge> [ddnet] <Jupstar> 
17:43 <+bridge> [ddnet] <Jupstar> logic errors will always haunt you and they often cost lot of time to find
17:44 <+bridge> [ddnet] <Voxel> you lost me at rust LOL
17:45 <+bridge> [ddnet] <Jupstar> rust does prevent certain stuff, but also adds complexity, since you are in a forced system.
17:45 <+bridge> [ddnet] <Jupstar> You could say every memory bug in c++ is just a logic bug in the end. So a language that prevents logic errors would be OP
17:47 <+bridge> [ddnet] <Jupstar> also rusts goal is to be secure, a bug there simply results in a panic
17:47 <+bridge> [ddnet] <Jupstar> that doesnt mean your plain will continue flying if the pilot crashes
17:51 <+bridge> [ddnet] <Ryozuki> Not rly rust enforces you to handle results (provided u dont use unwrap) this handling the path of an error
17:51 <+bridge> [ddnet] <Ryozuki> Thus*
17:54 <+bridge> [ddnet] <Learath2> High barrier of entry compared to C++?? C/C++ are walking pitfalls with shitty stdlibs that don't compare to rusts. The high barrier of entry is just an illusion for us that knew programming before rust existed
17:54 <+bridge> [ddnet] <Ryozuki> *adds a complexity you would otherwise offload to later, when you get a bug prevented by that added complexity
17:55 <+bridge> [ddnet] <k2d222> ye. barrier to entry to "get started with coding", not be efficient at. that's the point
17:56 <+bridge> [ddnet] <Learath2> Maybe you can get to code toys in C++ quicker. But try linking with a library :P The lack of a package manager makes it hell for newbies
17:57 <+bridge> [ddnet] <Ryozuki> > Maybe you can get to code toys in C++ quicker.
17:57 <+bridge> [ddnet] <Ryozuki> i think this is what he means
17:57 <+bridge> [ddnet] <Ryozuki> rust essentially prevents that
17:57 <+bridge> [ddnet] <k2d222> good point lol
17:58 <+bridge> [ddnet] <Learath2> Don't get me wrong. I love my C but I also know it's very painful to make substantial programs in it
17:58 <+bridge> [ddnet] <Ryozuki> well i mean within the scope of c++ not about the tooling
17:58 <+bridge> [ddnet] <Ryozuki> prototypes in rust will always be safer than those in c++
17:59 <+bridge> [ddnet] <Patiga> in rust, most c++ memory errors will simply not compile. those are not runtime errors, so our pilot will never face that issue
17:59 <+bridge> [ddnet] <Ryozuki> @Learath2 rust high barrier of entry is that of "it wont even let you compile your program"
18:00 <+bridge> [ddnet] <Learath2> I guess that's fair. C++ will happily let you leak all over the place and use UB
18:01 <+bridge> [ddnet] <Learath2> ??????
18:02 <+bridge> [ddnet] <Ryozuki> XD
18:02 <+bridge> [ddnet] <Jupstar> thats not my point, you have to redesign your app to archive this
18:04 <+bridge> [ddnet] <Ryozuki> what does redesign mean
18:04 <+bridge> [ddnet] <Learath2> Hm, wym redesign? Apart from having to handle all errors you'll code pretty much the same way
18:04 <+bridge> [ddnet] <Ryozuki> you may even find branches u havent handled
18:04 <+bridge> [ddnet] <Ryozuki> rust enums are pretty dope
18:04 <+bridge> [ddnet] <Learath2> A C++ program doesn't look fundamentally different from a Rust program, atleast in the program structure department
18:05 <+bridge> [ddnet] <Learath2> One thing that might lead to cancer is async callbacks, now that might force you to redesign a bit :P
18:06 <+bridge> [ddnet] <Learath2> I found them much easier to work with in C/C++ where I don't have to spend an hour trying to convince the compiler it's safe
18:06 <+bridge> [ddnet] <Ryozuki> i never seen c++ async code yet
18:06 <+bridge> [ddnet] <Ryozuki> @Learath2 you know there is a cult that goes around saying async itself is the devil
18:06 <+bridge> [ddnet] <Ryozuki> in all languages
18:06 <+bridge> [ddnet] <Ryozuki> i seen that a lot in hackernews
18:06 <+bridge> [ddnet] <Ryozuki> xD
18:07 <+bridge> [ddnet] <Learath2> Even without async, just using threads the callbacks are still annoying to get right
18:07 <+bridge> [ddnet] <Jupstar> what u talking about xD
18:07 <+bridge> [ddnet] <Jupstar> c++ can look the same yes
18:07 <+bridge> [ddnet] <Jupstar> now open ddnet source code
18:08 <+bridge> [ddnet] <Learath2> I've actually had a hunch this might be the case. How is a fair threadpool supposed to know how to thread my program better than me?
18:08 <+bridge> [ddnet] <Ryozuki> u should get to the point whee you write the code already in a way the compiler things its safe
18:09 <+bridge> [ddnet] <Learath2> ? ddnet code rewritten in rust you wouldn't really need to redesign it to get it to work, you just need to clarify some ownership semantics and handle errors we let slip
18:10 <+bridge> [ddnet] <Learath2> Albeit a redesign wouldn't be too bad if we are doing that already, it is still a bit of a mess ngl :D
18:10 <+bridge> [ddnet] <Ryozuki> a multithreaded ECS world
18:11 <+bridge> [ddnet] <Jupstar> mhh i'd say i make it easier than it's actually is, but i'd love to see a rewrite
18:11 <+bridge> [ddnet] <Ryozuki> rewrites require lot of effort
18:12 <+bridge> [ddnet] <Ryozuki> and in ddnet u would need to reproduce the bugs safely
18:12 <+bridge> [ddnet] <Jupstar> mhh i'd say u make it easier than it's actually is, but i'd love to see a rewrite
18:12 <+bridge> [ddnet] <Learath2> Ew forgot we aren't allowed to change anything anyway
18:13 <+bridge> [ddnet] <Voxel> if we were to rewrite the entirety of ddnet would it be possible to actually make some ground changes that wouldnt be possible in the current state of ddnet?
18:15 <+bridge> [ddnet] <Ryozuki> yes
18:15 <+bridge> [ddnet] <Ryozuki> specially if we can ignore the tw protocol
18:15 <+bridge> [ddnet] <Ryozuki> and build a new one
18:15 <+bridge> [ddnet] <Ryozuki> im sure we can do better than 2007
18:15 <+bridge> [ddnet] <Ryozuki> or 2012
18:16 <+bridge> [ddnet] <Ryozuki> first priority = moddable friendly
18:16 <+bridge> [ddnet] <Ryozuki> and thinking with forward compatiblity
18:16 <+bridge> [ddnet] <Ryozuki> thats what i would prioritize
18:16 <+bridge> [ddnet] <Learath2> Mh, everything is pretty much already possible without a rewrite, just need to drop vanilla compatibility
18:16 <+bridge> [ddnet] <Ryozuki> we are also bound by our own back com
18:16 <+bridge> [ddnet] <Ryozuki> comp
18:16 <+bridge> [ddnet] <Ryozuki> e.g we cant make a new map format
18:16 <+bridge> [ddnet] <Learath2> A rewrite would just make it more pleasent to work with
18:17 <+bridge> [ddnet] <Ryozuki> *without monkey patching code
18:17 <+bridge> [ddnet] <Learath2> Sure we can. We can send new map to new clients and old map to old clients
18:17 <+bridge> [ddnet] <Ryozuki> see
18:17 <+bridge> [ddnet] <Ryozuki> thats the stuff i dislike
18:17 <+bridge> [ddnet] <Ryozuki> and all code is cluttered with
18:17 <+bridge> [ddnet] <Voxel> i talked about this but itd be nice in the rewrite for entity arrangements to look different
18:18 <+bridge> [ddnet] <Ryozuki> u mean the pngs?
18:18 <+bridge> [ddnet] <Voxel> yes
18:18 <+bridge> [ddnet] <Ryozuki> a good idea would be to use json files
18:18 <+bridge> [ddnet] <Voxel> time cps take up too much space
18:18 <+bridge> [ddnet] <Ryozuki> describing the tiles in pngs
18:18 <+bridge> [ddnet] <Ryozuki> so we can rearrange
18:18 <+bridge> [ddnet] <Ryozuki> any time
18:18 <+bridge> [ddnet] <Ryozuki> mc does this kinda
18:18 <+bridge> [ddnet] <Learath2> Mmh, this is a recipe for json files mismatching pngs
18:18 <+bridge> [ddnet] <Ryozuki> but gives more flexibility
18:19 <+bridge> [ddnet] <Learath2> If I were to do something like that I'd probably have my own format that pairs a png with a json file just to make sure they never get split up
18:19 <+bridge> [ddnet] <Learath2> Like a zip with a special header probably
18:33 <+bridge> [ddnet] <Learath2> I was coding this and 3 people here called it useless and told me that I was wasting my time so I stopped working on it
18:58 <+bridge> [ddnet] <c0d3d3v> @deen  if you use `/timecp` command, should not also get your time in scoreboard get updated to the time of the requested player? Because with my last change it does show that time in the personal record text xD
18:58 <+bridge> [ddnet] <c0d3d3v> @deen  if you use `/timecp` command, should not also get your time in scoreboard get updated to the time of the requested player?
19:02 <+bridge> [ddnet] <c0d3d3v> mh I see only the CPs are from the requested player... I think thats nice. I just thought there could be some kind of feedback, that the CPs got loaded
19:43 <+bridge> [ddnet] <louis> is it possible to interpolate inputs between ticks
19:43 <+bridge> [ddnet] <louis> so inputs arent bound to 50hz
19:45 <+bridge> [ddnet] <Jupstar> not really
19:48 <+bridge> [ddnet] <louis> why not
19:49 <+bridge> [ddnet] <louis> like theoretically
19:50 <+bridge> [ddnet] <Jupstar> if u dont care about physics change yes
19:55 <+bridge> [ddnet] <louis> i mean ye it will break things like dj in freeze and a lot more
19:56 <+bridge> [ddnet] <Jupstar> it breaks the whole physics
19:57 <+bridge> [ddnet] <Jupstar> real life physics does not rely on ticks
19:57 <+bridge> [ddnet] <Jupstar> but on time
19:57 <+bridge> [ddnet] <Learath2> Interpolate in how many steps. This is just a computer
19:57 <+bridge> [ddnet] <Tater> @c0d3d3v if you want me to submit my implementation of the freeze hud as a PR I can but I held off because kog servers don't  send freezetick so it just uses ninja skin to determine if someone is frozen. But I guess it could just use freezetick on ddnet servers
19:58 <+bridge> [ddnet] <Jupstar> @louis here
19:58 <+bridge> [ddnet] <Jupstar> https://github.com/Jupeyy/ddnet/commit/ba0155c8686e3a3c8ce3c7b5767a0587530d7d85
19:58 <+bridge> [ddnet] <Jupstar> 
19:58 <+bridge> [ddnet] <Jupstar> enjoy 200 ticks ddnet
19:58 <+bridge> [ddnet] <louis> thats not what i meant
19:58 <+bridge> [ddnet] <louis> i mean like
19:58 <+bridge> [ddnet] <louis> idk if interpolate is correct word
19:59 <+bridge> [ddnet] <louis> u dont increase ticks, just get inputs on a higher frequency (for example 500hz)
19:59 <+bridge> [ddnet] <louis> if a jump is done halfway between ticks, it will calculate the next position as so
19:59 <+bridge> [ddnet] <louis> instead of having it start on the next tick
19:59 <+bridge> [ddnet] <Ryozuki> physics are at 50hz but client smoothes it out iirc
19:59 <+bridge> [ddnet] <Ryozuki> intra tick stuff
19:59 <+bridge> [ddnet] <Jupstar> mh its not that ez, how do you apply half gravity etc
20:00 <+bridge> [ddnet] <Jupstar> it simply doesnt work on how the physics was build
20:00 <+bridge> [ddnet] <louis> gravity /= 2 :troll:
20:00 <+bridge> [ddnet] <Jupstar> yeah but there is friction which is a multiplier
20:00 <+bridge> [ddnet] <Jupstar> so at that point it would break the physics completly
20:02 <+bridge> [ddnet] <Learath2> Theoretically I guess you could send the server how many ms before the next tick you made the input and the server could do some magic, but it'd definitely break a lot of things 😄
20:08 <+bridge> [ddnet] <c0d3d3v> I first of all wanted to open an issue so we can have a  little discussion if it is useful. xD that KoG does not send freeze information, but only ninja weapon is also a problem that should be mentioned.
20:10 <+bridge> [ddnet] <Tater> Yeah ninja weapon is an issue but its very rare on gores maps
20:11 <+bridge> [ddnet] <Tater> Also I realize my implementation has like 10 configs because I was not concerned about minimizing them so that would need to be simplified
20:12 <+bridge> [ddnet] <Tater> Also I realize my implementation has like 6 configs because I was not concerned about minimizing them so that would need to be simplified
20:15 <+bridge> [ddnet] <Tater> Sry i would comment on the girhub post but I'm not at pc
20:15 <+bridge> [ddnet] <Tater> Sry i would comment on the github post but I'm not at pc
20:20 <+bridge> [ddnet] <Jupstar> i give you an example:
20:20 <+bridge> [ddnet] <Jupstar> 
20:20 <+bridge> [ddnet] <Jupstar> u need to understand this:
20:20 <+bridge> [ddnet] <Jupstar> first velocity is calculated, then the position is changed
20:20 <+bridge> [ddnet] <Jupstar> 
20:20 <+bridge> [ddnet] <Jupstar> lets start with vel 0 in both cases
20:20 <+bridge> [ddnet] <Jupstar> 
20:20 <+bridge> [ddnet] <Jupstar> v = (0 + gravity) * friction
20:20 <+bridge> [ddnet] <Jupstar> p = p + v
20:20 <+bridge> [ddnet] <Jupstar> 
20:20 <+bridge> [ddnet] <Jupstar> now lets form it to half of it
20:20 <+bridge> [ddnet] <Jupstar> v = (0 + gravity / 2) * friction
20:21 <+bridge> [ddnet] <Jupstar> p = p + v
20:21 <+bridge> [ddnet] <Jupstar> 
20:21 <+bridge> [ddnet] <Jupstar> if you want a similar result generally in a multiplication you need to take the x-root of friction
20:21 <+bridge> [ddnet] <Jupstar> in this case the second root, bcs you apply it twice
20:21 <+bridge> [ddnet] <Jupstar> 
20:21 <+bridge> [ddnet] <Jupstar> (sqrt(friction) * sqrt(friction)) = friction
20:21 <+bridge> [ddnet] <Jupstar> However, as much as you can make it "better"
20:21 <+bridge> [ddnet] <Jupstar> u added the velocity to the position and would need to take the position into account to actually fix it
20:21 <+bridge> [ddnet] <Jupstar> 
20:21 <+bridge> [ddnet] <Jupstar> for a const like gravity what happens in real world(simplified) is:
20:21 <+bridge> [ddnet] <Jupstar> v(t) = gravity * t + v0, where v0 is the start velocity
20:21 <+bridge> [ddnet] <Jupstar> 
20:21 <+bridge> [ddnet] <Jupstar> or depending on the old velocity
20:21 <+bridge> [ddnet] <Jupstar> v(t) = v(last_t) + gravity * (t - last_t)
20:21 <+bridge> [ddnet] <Jupstar> so basically the ellapsed time
20:21 <+bridge> [ddnet] <Jupstar> 
20:21 <+bridge> [ddnet] <Jupstar> and on position side you do basically the same
20:21 <+bridge> [ddnet] <Jupstar> pos(t) = gravity / 2 * t^2 + v0 * t + pos0
20:21 <+bridge> [ddnet] <Jupstar> 
20:25 <+bridge> [ddnet] <Ryozuki> gravity is not even constant around earth
20:25 <+bridge> [ddnet] <Ryozuki> :p
20:25 <+bridge> [ddnet] <Ryozuki> the constant is another thing
20:25 <+bridge> [ddnet] <Ryozuki> i forgot the name
20:26 <+bridge> [ddnet] <louis> gravitational constant G
20:26 <+bridge> [ddnet] <Ryozuki> https://en.wikipedia.org/wiki/Gravitational_constant
20:26 <+bridge> [ddnet] <louis> yeah changing tw physics in any way will break one thing or the other unfortunately
20:27 <+bridge> [ddnet] <louis> but maybe u could hard code a lot of edge cases or smth, but doubt it would ever work
20:27 <+bridge> [ddnet] <Jupstar> gravity is a lie anyway
20:27 <+bridge> [ddnet] <Jupstar> we just constantly bend space time
20:27 <+bridge> [ddnet] <Jupstar> ez
20:29 <+bridge> [ddnet] <Jupstar> https://youtu.be/wrwgIjBUYVc?t=400
21:03 <+bridge> [ddnet] <c0d3d3v> Just to correct myself. The tangling of the velocity is only server side. 
21:03 <+bridge> [ddnet] <c0d3d3v> 
21:03 <+bridge> [ddnet] <c0d3d3v> @Learath2 
21:03 <+bridge> [ddnet] <c0d3d3v> But the Character is very second tick updated. xD I was lost, that is not because if the velocity.
21:03 <+bridge> [ddnet] <c0d3d3v> It is m_Tick that is updated every tick.
21:03 <+bridge> [ddnet] <c0d3d3v> I did a little debug code to figure that out, if someone wants to test it https://github.com/C0D3D3V/ddnet/tree/what_changes_in_netobj_character
21:03 <+bridge> [ddnet] <c0d3d3v> 
21:03 <+bridge> [ddnet] <c0d3d3v> Looks like this:
21:03 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:51][client]: CNetObj_Character changed
21:03 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:51][client]:  0 35500 35502
21:03 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:51][client]: CNetObj_Character changed
21:03 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:51][client]:  0 35502 35504
21:03 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:51][client]: CNetObj_Character changed
21:03 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:51][client]:  0 35504 35506
21:04 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:52][client]: CNetObj_Character changed
21:04 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:52][client]:  0 35506 35508
21:04 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:52][client]: CNetObj_Character changed
21:04 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:52][client]:  0 35508 35510
21:04 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:52][client]: CNetObj_Character changed
21:04 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:52][client]:  0 35510 35512
21:04 <+bridge> [ddnet] <c0d3d3v> Just to correct myself. The tangling of the velocity is only server side. 
21:04 <+bridge> [ddnet] <c0d3d3v> 
21:04 <+bridge> [ddnet] <c0d3d3v> @Learath2 
21:04 <+bridge> [ddnet] <c0d3d3v> But the Character is very second tick updated. xD I was lost, that is not because of the velocity.
21:04 <+bridge> [ddnet] <c0d3d3v> It is m_Tick that is updated every tick.
21:04 <+bridge> [ddnet] <c0d3d3v> I did a little debug code to figure that out, if someone wants to test it https://github.com/C0D3D3V/ddnet/tree/what_changes_in_netobj_character
21:04 <+bridge> [ddnet] <c0d3d3v> 
21:04 <+bridge> [ddnet] <c0d3d3v> Looks like this:
21:04 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:51][client]: CNetObj_Character changed
21:04 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:51][client]:  0 35500 35502
21:04 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:51][client]: CNetObj_Character changed
21:04 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:51][client]:  0 35502 35504
21:04 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:51][client]: CNetObj_Character changed
21:04 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:51][client]:  0 35504 35506
21:04 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:52][client]: CNetObj_Character changed
21:04 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:52][client]:  0 35506 35508
21:04 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:52][client]: CNetObj_Character changed
21:04 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:52][client]:  0 35508 35510
21:04 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:52][client]: CNetObj_Character changed
21:04 <+bridge> [ddnet] <c0d3d3v> [2022-07-06 20:57:52][client]:  0 35510 35512
21:05 <+bridge> [ddnet] <c0d3d3v> I do not even think we would need that update. But I guess that was made to prevent package loss.
21:07 <+bridge> [ddnet] <heinrich5991> I don't see what this has to do with package loss
21:07 <+bridge> [ddnet] <heinrich5991> can you explain?
21:18 <+bridge> [ddnet] <heinrich5991> meh
21:18 <+bridge> [ddnet] <heinrich5991> why is rust so bloated
21:27 <+bridge> [ddnet] <heinrich5991> ```
21:27 <+bridge> [ddnet] <heinrich5991> $ touch a.rs
21:27 <+bridge> [ddnet] <heinrich5991> $ rustc a.rs --crate-type staticlib -C opt-level=z
21:27 <+bridge> [ddnet] <heinrich5991> $ ls -lh liba.a
21:27 <+bridge> [ddnet] <heinrich5991> -rw-r--r-- 1 19M Jul  6 21:26 liba.a
21:27 <+bridge> [ddnet] <heinrich5991> ```
21:31 <+bridge> [ddnet] <Ryozuki> static lib?
21:32 <+bridge> [ddnet] <Ryozuki> https://github.com/johnthagen/min-sized-rust
22:06 <+bridge> [ddnet] <c0d3d3v> I thought maybe the character gets resend with new tick to prevent that a player did not get an old character snap... But I guess that is unnecessary because the client would request a resend anyway because of missing delta
22:06 <+bridge> [ddnet] <c0d3d3v> maybe we could try not to send characters if nothing changes
22:07 <+bridge> [ddnet] <c0d3d3v> except tick
22:08 <+bridge> [ddnet] <c0d3d3v> or better keep the old tick, to keep the snap in the snapshot
22:08 <+bridge> [ddnet] <c0d3d3v> so we could introduce a snapshot tick....
22:08 <+bridge> [ddnet] <c0d3d3v> so we could introduce a snapshot tick.... for characters
22:55 <+bridge> [ddnet] <heinrich5991> @Ryozuki yes, static lib
22:56 <+bridge> [ddnet] <heinrich5991> perhaps it's intrinsic in the static library format that I can't get it smaller?
22:59 <+bridge> [ddnet] <Ryozuki> did u strip it?
23:00 <+bridge> [ddnet] <Ryozuki> codegen-units = 1 may help too
23:00 <+bridge> [ddnet] <Ryozuki> basically the link i sent
23:00 <+bridge> [ddnet] <heinrich5991> I don't think so, but nothing is going to reduce an empty library from 20 MB to something sane
23:01 <+bridge> [ddnet] <Ryozuki> maybe
23:01 <+bridge> [ddnet] <Ryozuki> https://github.com/johnthagen/min-sized-rust#optimize-libstd-with-build-std
23:01 <+bridge> [ddnet] <Ryozuki> if u check this part
23:01 <+bridge> [ddnet] <Ryozuki> build using build-std
23:01 <+bridge> [ddnet] <Ryozuki> https://cdn.discordapp.com/attachments/293493549758939136/994347480915390505/unknown.png
23:01 <+bridge> [ddnet] <heinrich5991> after stripping, it's 'only' 10 MB
23:02 <+bridge> [ddnet] <Ryozuki> whats the comparision with say c++?
23:02 <+bridge> [ddnet] <heinrich5991> 1.1 KB
23:02 <+bridge> [ddnet] <Ryozuki> try doing what i sent u
23:02 <+bridge> [ddnet] <Ryozuki> it should remove unused parts of the std
23:03 <+bridge> [ddnet] <heinrich5991> I mean an empty library is an unfair comparison, I don't expect rust to go down to 1.1 KB
23:04 <+bridge> [ddnet] <Learath2> Why not?
23:04 <+bridge> [ddnet] <heinrich5991> or at least it's not important
23:04 <+bridge> [ddnet] <Learath2> Nothing is nothing, no matter the language 😛
23:04 <+bridge> [ddnet] <heinrich5991> but I was trying to generate a minimal example where the rust library is still that big
23:04 <+bridge> [ddnet] <heinrich5991> and that's where I ended up
23:04 <+bridge> [ddnet] <heinrich5991> I'll try the build-std thing
23:05 <+bridge> [ddnet] <Ryozuki> iirc
23:05 <+bridge> [ddnet] <Ryozuki> its definitly possible
23:06 <+bridge> [ddnet] <heinrich5991> ah, is the problem that I can't dynamically link rust and hence can't dynamically link the standard library (which would unfortunately not be present anyway), but libc++ is present on distributions?
23:06 <+bridge> [ddnet] <heinrich5991> what would that look like on windows?
23:07 <+bridge> [ddnet] <Learath2> How big is libc anyway? I doubt it's 10M
23:07 <+bridge> [ddnet] <Ryozuki> oh
23:07 <+bridge> [ddnet] <Learath2> But yes probably that is the issue, and the only way to go smaller is probably some sort of LTO
23:07 <+bridge> [ddnet] <Ryozuki> i thought u were statically linking the libstdc++
23:07 <+bridge> [ddnet] <Ryozuki> for a fair comp
23:08 <+bridge> [ddnet] <heinrich5991> I'm going for a 'how much size will ddnet gain' comparison
23:08 <+bridge> [ddnet] <heinrich5991> @Learath2 20 MB, for that matter 😄
23:09 <+bridge> [ddnet] <heinrich5991> /usr/lib/libstdc++.so.6.0.30
23:09 <+bridge> [ddnet] <Learath2> Hm, having to have libstd in every module of rust we add sounds like a significantly bad deal, we'd have to go for a non modular approach for that to be remotely acceptable
23:09 <+bridge> [ddnet] <Ryozuki> u can dynamically link rust tho i think
23:09 <+bridge> [ddnet] <Ryozuki> its just not the norm
23:09 <+bridge> [ddnet] <Learath2> Like one big rust blob interacting with the one big C++ blob
23:12 <+bridge> [ddnet] <heinrich5991> I get 2.5 MiB for the stripped build-std build
23:12 <+bridge> [ddnet] <Learath2> Is that still an empty lib?
23:12 <+bridge> [ddnet] <heinrich5991> yes
23:13 <+bridge> [ddnet] <Learath2> What part of std is even being pulled in, that's so weird
23:13 <+bridge> [ddnet] <heinrich5991> perhaps the formatting stuff
23:13 <+bridge> [ddnet] <Ryozuki> did u remove
23:13 <+bridge> [ddnet] <Ryozuki> the panic
23:13 <+bridge> [ddnet] <Ryozuki> to abort
23:13 <+bridge> [ddnet] <Ryozuki> > Even if panic = "abort" is specified in Cargo.toml, rustc will still include panic strings and formatting code in final binary by default. An unstable panic_immediate_abort feature has been merged into the nightly rustc compiler to address this.
23:14 <+bridge> [ddnet] <heinrich5991> I can try that; removing the formatting code is probably a no-go for ddnet though
23:14 <+bridge> [ddnet] <Learath2> As long as we have a single copy of a 3ish MB libstd that sounds fine to me aswell, no need to make the panics ugly
23:14 <+bridge> [ddnet] <Ryozuki> and codegen-units = 1 ?
23:15 <+bridge> [ddnet] <Ryozuki> i mean 3mb is fine to me
23:15 <+bridge> [ddnet] <Ryozuki> we shouldnt sacrifice too much for it
23:15 <+bridge> [ddnet] <Ryozuki> otherwise jsut not use rust
23:15 <+bridge> [ddnet] <Ryozuki> xD
23:16 <+bridge> [ddnet] <Learath2> 3M is definitely acceptable, even up to 5M, but if we can't split libstd and link to that dynamically then we can't have rust "modules" we'll need to settle for a blob
23:25 <+bridge> [ddnet] <heinrich5991> ah, I accidentally produced a 14 KiB .so
23:37 <+bridge> [ddnet] <heinrich5991> okay, with `crate-type = ["cdylib"]` and `build-std`, I get < 32 KiB .sos
23:38 <+bridge> [ddnet] <empty> Hello, Is this channel only for server and client? I have idea/question about site
23:40 <+bridge> [ddnet] <Ryozuki> for everything dev related
23:40 <+bridge> [ddnet] <heinrich5991> this channel is about all development
23:40 <+bridge> [ddnet] <Ryozuki> web included
23:47 <+bridge> [ddnet] <empty> afaik client accepts any skin size, recently I found out uhd skins are added separately to db. wasn't simpler just update tee.js (the skin assembler) to make correct previews for uhd?
23:59 <+bridge> [ddnet] <heinrich5991> it'd be good to update tee.js if it doesn't work with higher definition skins