01:05 < bridge> <zhn> i think yup
01:06 < bridge> <zhn> he wants to concat asm lines without using r# for whatever reason
01:17 < bridge> <meloƞ> :justatest:
02:56 < ws-client> <ChillerDragon> @Patiga not sure if i asked you already. But any plans on adding python type hints to the twmap bindings? My IDE is panicing.
04:55 < bridge> <peter0x44> `gcc -o whatever.c -lm`
04:55 < bridge> <peter0x44> has anyone else been trolled by this before?
06:23 < bridge> <Ewan> yes
06:25 < bridge> <peter0x44> `gcc -o whatever.c -lm`
06:25 < bridge> <peter0x44> has anyone else been trolled by this before? :trollet:
07:03 < bridge> <milkeeycat> 2nd one
07:21 < bridge> <milkeeycat> Because it looks ugly
09:19 < bridge> <milkeeycat> i found a perfect macro i was looking for 🥹
09:19 < bridge> <milkeeycat> ```rust
09:19 < bridge> <milkeeycat> fn main() {
09:19 < bridge> <milkeeycat>     let foo = 0x45;
09:19 < bridge> <milkeeycat>     let bar = indoc::formatdoc!(
09:19 < bridge> <milkeeycat>         "
09:19 < bridge> <milkeeycat>         foo
09:19 < bridge> <milkeeycat>             {foo}
09:19 < bridge> <milkeeycat>                 baz
09:19 < bridge> <milkeeycat>         "
09:19 < bridge> <milkeeycat>     );
09:19 < bridge> <milkeeycat> 
09:19 < bridge> <milkeeycat>     println!("{}", bar);
09:19 < bridge> <milkeeycat> }
09:19 < bridge> <milkeeycat> ```
09:19 < bridge> <milkeeycat> ```
09:19 < bridge> <milkeeycat> foo
09:19 < bridge> <milkeeycat>     69
09:19 < bridge> <milkeeycat>         baz
09:19 < bridge> <milkeeycat> ```
09:20 < bridge> <Ewan> woah is that actually how string literal indentation works in rust
09:20 < bridge> <milkeeycat> it would usually intend like 3x
09:20 < bridge> <milkeeycat> but this formatdoc thingy indents everything related to first line
09:21 < bridge> <Ewan> so fucking cool
09:21 < bridge> <Ewan> need that
09:22 < bridge> <milkeeycat> im so glad i don't have to go to macros land to write it myself 😬
09:22 < bridge> <meloƞ> Oh wow thats cool
09:34 < bridge> <milkeeycat> it would usually indent like 3x
09:45 < ws-client> <ChillerDragon> @peter0x44 lol the error message of that is horrible :D but no i have not been trolled by that because i only manually linked a C lib 3 times in my life :D 
11:10 < ws-client> <ChillerDragon> @milkeeycat nice rust is catching up to bash
11:10 < ws-client> <ChillerDragon> https://zillyhuhn.com/cs/.1713431408.png
11:12 < bridge> <milkeeycat> chillerdragon wanna try to make a compiler in bash? 😬
11:12 < ws-client> <ChillerDragon> im too lazy to read up on compiler theory
11:12 < bridge> <milkeeycat> Ah gg
11:13 < ws-client> <ChillerDragon> also im busy debugging ddnet 0.7 demos since a week omg
11:50 < bridge> <meloƞ> Lmao
13:41 < bridge> <fokkonaut> chillerdragon: troll
14:11 < bridge> <jsaurusrex> @robyt3 question about this, its been a while so i don't quite remember. But with the new chunktype did you mean to add the info required for different tickrates to work with demos
14:11 < bridge> <jsaurusrex> pr in question: https://github.com/ddnet/ddnet/pull/7555
14:11 < bridge> <jsaurusrex> https://cdn.discordapp.com/attachments/293493549758939136/1230490765575323658/image.png?ex=663382d3&is=66210dd3&hm=802173052072c83af01076bbef54d187d5c9e3e8e574ee50606c392edbce5495&
15:50 < bridge> <patiga> that is not on my to-do list. it seems like the type-hint file would need to be created manually. I'd ofc happily accept a pull request for that ^^
19:27 < bridge> <Ewan> send link
19:27 < bridge> <learath2> Huuh?
19:28 < bridge> <milkeeycat> https://varkor.github.io/blog/2018/07/03/existential-types-in-rust.html
19:29 < bridge> <learath2> Type theoretic :pepeW:
19:29 < bridge> <learath2> Computer Science people need to be stopped
19:29 < bridge> <milkeeycat> i understand stuff only when i can see an example xD
19:30 < bridge> <milkeeycat> few lines of code -> 10 pages of docs
19:30 < bridge> <milkeeycat> few lines of code > 10 pages of docs
19:31 < bridge> <learath2> It also depends on the depth of the docs and the depth you want to understand something on
19:32 < bridge> <learath2> You don't need a type theoretical discussion of impl Trait to understand what it does and how to use it
19:34 < bridge> <Ewan> what about dyn Trait
19:35 < bridge> <ryozuki> https://llvm.org/docs/Passes.html#argpromotion-promote-by-reference-arguments-to-scalars
19:35 < bridge> <ryozuki> @learath2
19:40 < bridge> <learath2> I'm sure there is documentation out there that explains it without invoking intuitionist logic principles and the Curry-Howard correspondence
19:40 < bridge> <Ewan> but is it scholarly
19:40 < bridge> <Ewan> not a big enough flex to read
19:41 < bridge> <robyt3> I meant that the demo format is already hacky enough as it is and we should first add something like UUID support to make future extensions of the format less hacky. But I see now that just adding another chunk type to demos is likely impossible, since the demo format only supports 3 chunk types. Adding a ghost chunk type for the tick rate is definitely cleaner than the current solution for demos and it's also more feasible since the maximum number 
19:41 < bridge> <learath2> If you are interested in theory, it is a nice read. If you just want to learn what impl and dyn do in different places it is far too deep
19:42 < bridge> <Ewan> True
19:43 < bridge> <learath2> I do admit it is a cute way to look at it though. I wouldn't have ever considered to look at it like that
19:48 < bridge> <learath2> I can imagine being completely lost if I had no idea what the logic argument was because it's not one that is immediately obvious, especially in that notation
19:49 < bridge> <jsaurusrex> the few physics functions i had to genuinely change i made copies of which get used when its not 50hz
19:49 < bridge> <jsaurusrex> the rest should all be a bunch of math changes canceling each other out
19:49 < bridge> <jsaurusrex> 
19:49 < bridge> <jsaurusrex> in case of floating point precision limitations i can add special logic to make sure it always just returns the original 50hz value when at 50hz
19:49 < bridge> <jsaurusrex> ahh the classic rewrite xd
19:50 < bridge> <jsaurusrex> like i said in an earlier message it should be checkable with desyncs in player position, i already noticed this when i intentionally fucked something up and realised this was a way to check
19:52 < bridge> <Jupstar ✪> but a serious attempt 😉
19:52 < bridge> <jsaurusrex> like i said in an earlier message it should be checkable with desyncs in player position with a mix of clients, i already noticed this when i intentionally fucked something up and realised this was a way to check
19:52 < bridge> <jsaurusrex> o:
19:52 < bridge> <robyt3> I don't think arguments can convince me on this, this would need a solid test suite to ensure no behavior is changed
19:52 < bridge> <jsaurusrex> a friend of mine suggested a demo like format which just records a set of inputs (might be doable with normal demos) to ensure no change in physics
19:52 < bridge> <jsaurusrex> only thing to do then is note down a bunch of tricks and test them out
19:53 < bridge> <jsaurusrex> would be easily testable and repreducable in that case
19:54 < bridge> <robyt3> Zwelf is working on a comprehensive physics tests so maybe I'll be more inclined for this change once we have that
19:55 < bridge> <robyt3> Zwelf is working on comprehensive physics tests so maybe I'll be more inclined for this change once we have that
19:55 < bridge> <jsaurusrex> this would also be a nice to have regardless of this change, considering somebody might accidentally change physics for other reasons
19:56 < bridge> <jsaurusrex> is there a pr or something for zwelfs work?
19:56 < bridge> <Jupstar ✪> https://gitlab.com/ddnet-rs/twgame
19:56 < bridge> <jsaurusrex> this is the rewrite>?
19:56 < bridge> <jsaurusrex> this is the rewrite?
19:56 < bridge> <Jupstar ✪> this is the ddnet physics rewrite
19:56 < bridge> <jsaurusrex> how do you test for these cases?
19:56 < bridge> <jsaurusrex> just by hand
19:56 < bridge> <Jupstar ✪> as for what i don't have a name for and just call ddnet-next
19:56 < bridge> <Jupstar ✪> 
19:57 < bridge> <Jupstar ✪> it has it's own implementation of physics that is allowed to break ddnet physics
20:04 < bridge> <jsaurusrex> if you delay all the inputs locally by 1 you might get it to sync up
20:04 < bridge> <jsaurusrex> until somebody has a slight ping jump
20:05 < bridge> <jsaurusrex> which happens so annoyingly often
20:05 < bridge> <Jupstar ✪> yeah but delaying local input wont work xD
20:05 < bridge> <Jupstar ✪> that feels like shit then
20:06 < bridge> <jsaurusrex> i mean it already is delayed for 20ms
20:06 < bridge> <zhn> making it multiline is uglier tho
20:06 < bridge> <jsaurusrex> well up to
20:06 < bridge> <Jupstar ✪> yes and no
20:06 < bridge> <jsaurusrex> well, up to
20:06 < bridge> <zhn> yo jsaurus!
20:06 < bridge> <Jupstar ✪> the prediction makes it feel smooth
20:06 < bridge> <jsaurusrex> hello o/
20:06 < bridge> <jsaurusrex> true, but your inputs will not get processed until at least 20ms
20:06 < bridge> <Jupstar ✪> also the input could be sent just before the server tick happens
20:06 < bridge> <jsaurusrex> yeah, average would be 10ms
20:06 < bridge> <Jupstar ✪> yes
20:07 < bridge> <Jupstar ✪> wazzup man, u still alive
20:07 < bridge> <zhn> yoo jupjopjapsti
20:07 < bridge> <milkeeycat> that's my final way of doing it, maybe it's not the best but it's good enough for me
20:07 < bridge> <milkeeycat> https://cdn.discordapp.com/attachments/293493549758939136/1230580501224489070/image.png?ex=6633d666&is=66216166&hm=c76fa2d132f470a5ddb090823786500c9b892b3f8b92da6970bcd55690020c40&
20:08 < bridge> <jsaurusrex> funnily enough i could actually notice the decreased input latency at 200hz (or just anything about 50)
20:08 < bridge> <zhn> i did a little website by the way, took me like 2 day to mess up with tide and askama xd
20:08 < bridge> <zhn> still ugly
20:08 < bridge> <zhn> inspired by j3s.sh
20:08 < bridge> <Jupstar ✪> yeah
20:08 < bridge> <jsaurusrex> very minor tho
20:10 < bridge> <zhn> huh
20:10 < bridge> <milkeeycat> even tho that macro removes tabs it still has to be tabbed xDDDD
20:10 < bridge> <jsaurusrex> anyway i can contribute to this? or check upon its progress
20:11 < bridge> <robyt3> Ask Zwelf if he is looking for contributions
20:12 < bridge> <jsaurusrex> @zwelf2 yo i heard you were working on some physics tests
20:12 < bridge> <zhn> inspired by https://j3s.sh
20:17 < bridge> <learath2> https://youtu.be/wLHXn8IlAiA
20:18 < bridge> <learath2> I just love everything about this era of computing. I really wish I was born just a little earlier
20:21 < bridge> <zhn> ^ same
20:21 < bridge> <jsaurusrex> same ^
20:22 < bridge> <milkeeycat> sa ^ me
20:52 < bridge> <meloƞ> sam x² e
20:56 < bridge> <Jupstar ✪> how is that different from today?
20:56 < bridge> <learath2> Have you seen a modern capsule based collision algorithm?
20:58 < bridge> <Jupstar ✪> i dunno what u want to imply by that
20:58 < bridge> <Jupstar ✪> that modern games do that?
20:58 < bridge> <learath2> They are much much more complicated than what quake does
20:58 < bridge> <learath2> Sure they are better and more performant, but you need to be able to read basically a math paper to understand and implement them
20:59 < bridge> <learath2> They lack the elegance of earlier solutions (IMO)
20:59 < bridge> <Jupstar ✪> so for you it's just about collision detection itself
20:59 < bridge> <learath2> it's just one example
21:00 < bridge> <Jupstar ✪> no i mean like, BSP trees is a data structure
21:00 < bridge> <Jupstar ✪> but bounding boxes are basically the math
21:05 < bridge> <Jupstar ✪> https://en.wikipedia.org/wiki/Bounding_volume_hierarchy
21:05 < bridge> <Jupstar ✪> 
21:05 < bridge> <Jupstar ✪> this is what ray tracing usually uses afaik
21:09 < bridge> <learath2> Sure, I'd also say it's less elegant of a solution
21:10 < bridge> <learath2> you wouldn't understand, you view it from a completely different angle than I do
21:15 < bridge> <Jupstar ✪> the irony is. I agree with you that electron is shit, and i also hate slow shit
21:15 < bridge> <Jupstar ✪> 
21:15 < bridge> <Jupstar ✪> but IMHO RAM is much easier to scale than e.g. single core performance. and writing multi threaded apps is much harder than single threaded.
21:15 < bridge> <Jupstar ✪> 
21:15 < bridge> <Jupstar ✪> 
21:17 < bridge> <Jupstar ✪> the industry could EASILY scale RAM as we see in m1 macbooks
21:17 < bridge> <Jupstar ✪> so IMO it's a problem of the industry
21:17 < bridge> <Jupstar ✪> so i dont hate electron purely bcs it uses much RAM, but because it doesn't use it to gain reasonable enough speed from using so much ram
21:17 < bridge> <Jupstar ✪> it feels kinda wasted
21:18 < bridge> <learath2> I hate electron on two separate levels at the same time, it's both inelegant AND performs like shit
21:25 < bridge> <s3vage> can someone explain why i have 230 ping\
21:26 < bridge> <Jupstar ✪> do you live in brazil?
21:26 < bridge> <s3vage> no
21:26 < bridge> <s3vage> on ger10 i usually get 60 ms
21:26 < bridge> <s3vage> now i got 220
21:26 < bridge> <s3vage> its not my internet
21:27 < bridge> <Jupstar ✪> what else? xd
21:27 < bridge> <s3vage> wym
21:31 < bridge> <Ewan> or change your plan, or move houses, etc..
21:31 < bridge> <s3vage> i switched MTU if that makes any difference
21:31 < bridge> <Ewan> how
21:31 < bridge> <s3vage> through 192.168.1.1
21:32 < bridge> <s3vage> uh
21:32 < bridge> <s3vage> ok nvm
21:32 < bridge> <s3vage> it was a problem in a client
21:32 < bridge> <Ewan> "a client'
21:32 < bridge> <Ewan> "a client"
21:32 < bridge> <s3vage> i switched to a different DDnet client and its fixed
21:33 < bridge> <Ewan> :monkalaugh:
21:33 < bridge> <Ewan> not cheating right
21:33 < bridge> <s3vage> its cactus client
21:33 < bridge> <s3vage> :justatest:
21:33 < bridge> <Ewan> that dude has a client
21:33 < bridge> <Ewan> ??
21:33 < bridge> <s3vage> it has no cheats
21:33 < bridge> <s3vage> so idk
21:33 < bridge> <Ewan> fair enough
21:37 < bridge> <s3vage> had to restart it for the 5th time tho
21:37 < bridge> <Ewan> that is kinda sus honestly
21:37 < bridge> <Ewan> client shouldn't just arbitrarily become stupid
21:37 < bridge> <s3vage> it is indeed
21:37 < bridge> <s3vage> definitely not a crypto mining app :justatest:
21:39 < bridge> <Ewan> seems cactus client is not by cactus
21:40 < bridge> <Ewan> yeah i mean
21:40 < bridge> <Ewan> there's no saying it isn't
21:40 < bridge> <Ewan> because it's closed source
21:40 < bridge> <Ewan> there is no good explanation for your ping hitting 220 as a result of the client
21:40 < bridge> <Ewan> i would guess something unsavory is happening
21:40 < bridge> <s3vage> ok now im worried
21:41 < bridge> <s3vage> tater client works too :brownbear:
21:41 < bridge> <Ewan> yes because tater client is awesome and open source
21:41 < bridge> <Ewan> that's not actually why
21:41 < bridge> <Ewan> but he'd probably have a hard time sticking a crypto miner in there if it was closed source
21:42 < bridge> <Ewan> tbh i think the block feature should be added to tclient
21:42 < bridge> <s3vage> yeah but i dont think tater is into block xd
21:42 < bridge> <Ewan> he plays gores
21:43 < bridge> <Ewan> he doesn't play much of anything anymore tho
21:43 < bridge> <Ewan> haven't seen him in a few months
21:43 < bridge> <s3vage> same
21:45 < bridge> <Ewan> btw
21:45 < bridge> <Ewan> every time i see u in my server browser i get hard baited
21:45 < bridge> <Ewan> there's a south american savage that i used to play with a lot
21:45 < bridge> <Ewan> went by keun
21:45 < bridge> <Ewan> so u guys share points or what xD
21:46 < bridge> <s3vage> the chile savage?
21:46 < bridge> <Ewan> yea
21:46 < bridge> <s3vage> no mine has a dot
21:46 < bridge> <s3vage> its "Savage."
21:46 < bridge> <Ewan> there must be a third savage then
21:46 < bridge> <Ewan> http://2143.christmas/f/4DmJ.png
21:46 < bridge> <s3vage> maybe
21:48 < bridge> <s3vage> if its multeasy then its a faker
23:34 < bridge> <zwelf2> Not sure how good you are with Rust/C++, but writing Rust bindings for the C++ DDNet physics would help you the most. That way DDNet could be tested against all the test cases that I've recorded. I'm interested in doing that project at some point, but didn't have the time for it yet. This would be the interface that needs to implemented: https://gitlab.com/ddnet-rs/twgame/-/blob/fff836cb209497a022abeb7c431560cddb0ccc6e/twgame/src/lib.rs#L127
23:37 < bridge> <jsaurusrex> ty ^^
23:39 < bridge> <jsaurusrex> mostly a C programmer, how have you recorded ddnet?
23:40 < bridge> <jsaurusrex> mostly a C programmer, how have you recorded ddnet physics?
23:44 < bridge> <zwelf2> I usually plan to record physics test for specific features (I currently am doing switch layer). For each specific thing I want to test, I start a server and do that specific thing, shutdown the server and move the teehistorian file (server side demo that records all player inputs + tee positions after each tick) into https://gitlab.com/ddnet-rs/twgame/-/tree/a0a685b6058fd8afb138302e321c89e1db5965be/validator/res where it then gets run on each commi
23:46 < bridge> <jsaurusrex> so the idea is to load the teehistorian file and tee position every tick?