00:00 < bridge> <Jupstar ✪> You work until night? :lol:
00:02 < bridge> <patiga> pipeline is running again :)
00:38 < bridge> <totar> does ddnet want freeze stars back? tclient will have it next update. It's like 10 lines of code
00:49 < bridge> <sans._.> Is it possible to order the spec view by player id? would greatly appreciate it
00:51 < bridge> <totar> what is the current ordering?
00:51 < bridge> <totar> alphabetical
00:51 < bridge> <totar> alphabetical?
00:59 < bridge> <kebscs> yes
01:00 < bridge> <patiga> o.o I would've bet player id
02:11 < ws-client> <ChillerDragon> nice patiga
02:18 < ws-client> <ChillerDragon> @Jupstar ✪ иди is not NAN not a number its idi and it means "go". In this case its followed by "нахуй" nahui which means dick. Its classic insult "go to dick"
02:21 < ws-client> <ChillerDragon> @milkeeycat which protocol? I hope you are implementing 0.7 I personally always start with the first message that is sent. And then make sure the server responds correctly and then respond to that.
02:21 < ws-client> <ChillerDragon> you can get pretty far without the int packer
06:02 < bridge> <jxsl13> theoretically, you could do cloudflare warp -> your cheap vps as vpn
06:03 < bridge> <jxsl13> my assimption being that cloudflare wrap does not give you a fixed ip address which could be whitelistef
06:03 < bridge> <jxsl13> assumption
06:03 < bridge> <jxsl13> whitelisted*
07:02 < bridge> <milkeeycat> chillerdragon: im already implementing packer xd
07:28 < bridge> <chillerdragon> Doesn’t hurt having packer is good
08:41 < bridge> <milkeeycat> my implementing of packer started with fixing bugs in the compiler 😬
08:41 < bridge> <milkeeycat> https://cdn.discordapp.com/attachments/293493549758939136/1283316571044974643/image.png?ex=66e28d31&is=66e13bb1&hm=69992a1942bae26f3e34ad9a342d76775d8c7c236d72f0304d2f1aa6334791df&
08:43 < bridge> <animepdf> how ddnet manages global bans? I peeked thru scripts and I don't get how they are not getting reapplied, bans.cfg that exec'd by every server contain `ban ip duration reason`, when, by who, and how expired bans will be removed, if bans contain only duration, but not any kind of timestamp
08:59 < bridge> <learath2> We do but I have a feeling that it should be more than 10 lines. Which gives me the feeling that I won't like how you added them back. Which means I'll make a comment on the PR and fokkonaut will call me a seaslug
09:00 < bridge> <totar> what functionality do you need out of them that requires more than 10 lines
09:00 < bridge> <totar> they need prediction?
09:00 < bridge> <learath2> They still need to be timed like the old ones, do you have that covered?
09:01 < bridge> <totar> https://cdn.discordapp.com/attachments/293493549758939136/1283321398072311861/image.png?ex=66e291b0&is=66e14030&hm=cd2ed7a36a866b2f7e7bdd4d95474b27abf0ca6caee1d8d8224da4569747fbc9&
09:02 < bridge> <learath2> This looks about right, but I'll have to take a look at the original code
09:02 < bridge> <totar> the only issue is that because the client receives 25tps they are randomly out of sync by 1 tick half the time
09:03 < bridge> <totar> but the previous ones might have also been idk
09:07 < bridge> <totar> but they're not predicted so it's impossible to notice anyway
09:07 < bridge> <totar> unless you have <10ms ping
09:09 < bridge> <Ewan> def not impossible
09:13 < bridge> <0xdeen> Make a PR with an option please, I don't think it's a hill worth dying on, so we could add an option for it for the 0.1% of people who don't upgrade because of it.
09:15 < bridge> <learath2> I already promised the star people I'd add it back as an option. I just didn't have the time for it :/
09:17 < bridge> <totar> I was rather shocked how easy it was relative to how much arguing occurred
09:17 < bridge> <totar> the freezebar basically implemented everything required to have the stars clientside
09:21 < bridge> <learath2> It's not that it was hard. Any config option was a huge issue at that moment in time
09:22 < bridge> <learath2> I think it still is to heinrich, but something this small is very maintainable and doesn't need constant testing. So I'm sure he won't mind that much
09:30 < bridge> <totar> It would be nice if there was some clarification on this. It seems like tiny features with a single config option that are trivial to maintain get rejected very often.
09:32 < bridge> <totar> I've managed to maintain like 60 such tiny features downstream without having to rewrite any of them due to upstream changes.
09:32 < bridge> <totar> the upstream devs weren't even aware they exist
09:37 < bridge> <totar> I think what heinrich actually wants is to avoid feature creep/bloat but he should simply say that instead instead of claiming "maintainability" is difficult
09:51 < bridge> <fokkonaut> It's simply that some people prefer the teeish look and the fact the stars stick to the gameworld, not the tee
09:52 < bridge> <Jupstar ✪> It's simply that some ppl make a religion out of everything
09:52 < bridge> <fokkonaut> Bad argument
09:52 < bridge> <Jupstar ✪> If we'd have forced everyone to use the newest version this discussion wouldn't exist today
09:52 < bridge> <fokkonaut> It would make no difference
09:53 < bridge> <Jupstar ✪> Old freeze stars were not even predicted
09:53 < bridge> <Jupstar ✪> They logically make no sense
09:54 < bridge> <fokkonaut> And people still enjoyed them, just because they don't make sense to you or "logically" doesnt mean they are bad, useless or harmful
09:55 < bridge> <Jupstar ✪> I'd say bloat is harmful
09:55 < bridge> <Jupstar ✪> If there is a clear advantage in freeze stars we can still make the bar better
09:55 < bridge> <fokkonaut> And: The discussion whether we want to add them back is over already. We will, (Learath2 wanted to do that a long time ago and just didn't have the time. @totar please make a PR)
09:55 < bridge> <fokkonaut> Its not about that
09:55 < bridge> <Jupstar ✪> If someone think you can solve the freeze bar thing by simply replacing a texture, that would be a good workaround
09:56 < bridge> <Jupstar ✪> If someone thinks that you can solve the freeze bar thing by simply replacing a texture, that would be a good workaround
09:57 < bridge> <Jupstar ✪> At this point why not add 0.5 support
09:57 < bridge> <fokkonaut> Whataboutism
09:57 < bridge> <Jupstar ✪> no
09:57 < bridge> <fokkonaut> Ye
09:57 < bridge> <Jupstar ✪> That is your POV
09:57 < bridge> <fokkonaut> This is objectively
09:57 < bridge> <Jupstar ✪> ^
09:57 < bridge> <Jupstar ✪> This is objectively
09:57 < bridge> <fokkonaut> 0.5 is not used, not wanted and not maintained
09:58 < bridge> <fokkonaut> the stars are wanted, said to be implented by learath already, and by many people (if you remember, I made some votes)
09:58 < bridge> <fokkonaut> But it's simply not about that
09:58 < bridge> <fokkonaut> Its not that the freeze bar is bad, or not good enough
09:58 < bridge> <Jupstar ✪> They clearly said they want the "OLD" freeze stars back.
09:58 < bridge> <Jupstar ✪> 
09:58 < bridge> <Jupstar ✪> Indicating they don't understand the problem with freeze stars
09:59 < bridge> <fokkonaut> Could you elaborate
09:59 < bridge> <fokkonaut> What Problems?
09:59 < bridge> <fokkonaut> Prediction?
09:59 < bridge> <Jupstar ✪> For example lack of prediction
09:59 < bridge> <fokkonaut> How does it matter if they are rendered clientside just like the freezebar
09:59 < bridge> <Jupstar ✪> Freeze stars were simply wrong
09:59 < bridge> <fokkonaut> Bad argument
09:59 < bridge> <Jupstar ✪> Could aswell remove them visually completely
10:00 < bridge> <Jupstar ✪> Nope
10:00 < bridge> <totar> freeze bar also lacks prediction currently
10:00 < bridge> <fokkonaut> K
10:00 < bridge> <Jupstar ✪> that is a logical argument
10:00 < bridge> <fokkonaut> You dont seem to have good arguments today
10:00 < bridge> <Jupstar ✪> You never even started to argument
10:00 < bridge> <Jupstar ✪> Like always basically
10:00 < bridge> <fokkonaut> If you say so
10:01 < bridge> <Jupstar ✪> Then that should be fixed too, because otherwise it's not a complete feature
10:01 < bridge> <totar> the lack of prediction is kind of a feature
10:01 < bridge> <fokkonaut> Exactly
10:02 < bridge> <fokkonaut> And there is no point in predictig it
10:02 < bridge> <totar> that's not true
10:02 < bridge> <fokkonaut> True
10:02 < bridge> <fokkonaut> But it's not really required
10:02 < bridge> <Jupstar ✪> ???
10:02 < bridge> <Jupstar ✪> fokko bro
10:02 < bridge> <Jupstar ✪> Everything should be predicted
10:02 < bridge> <Jupstar ✪> Otherwise it's a bug..
10:03 < bridge> <totar> the issue is that when you have high ping it makes the position of other tees very inaccurate so they enter/leave freeze a lot. So you will see someone enter freeze, change skin, get freeze bar. Then the next tick they are not in freeze.
10:03 < bridge> <totar> presumably someone decided to not predict freeze for that reason
10:03 < bridge> <totar> visually
10:03 < bridge> <totar> in the physics they are still frozen
10:03 < bridge> <Jupstar ✪> Sure but that is a different issue. You cannot foresee the future.
10:03 < bridge> <Jupstar ✪> 
10:04 < bridge> <Jupstar ✪> The task of prediction is as the name suggest to predicts what happens
10:04 < bridge> <totar> I've tested it before it subjectively looks worse
10:04 < bridge> <fokkonaut> Not really
10:04 < bridge> <Jupstar ✪> Also human input is not really fast, so in many cases prediction will be right
10:04 < bridge> <totar> it makes it impossible to tell if someone next to you in gores is actually frozen or just antiping frozen because their skin will show frozen 90% of the time
10:04 < bridge> <Jupstar ✪> I dunno, it's like the fast input discussion
10:04 < bridge> <Jupstar ✪> Theoretically that is a bug
10:05 < bridge> <Jupstar ✪> But the fewer input lag still feels good
10:05 < bridge> <totar> fast input has not even been discussed lol
10:05 < bridge> <Jupstar ✪> Well we discussed it
10:05 < bridge> <fokkonaut> jupey, did you read that? :D
10:05 < bridge> <totar> the way that ddnet does it atm is industry standard. fast input is the weird way
10:05 < bridge> <totar> but it's not bad
10:06 < bridge> <Jupstar ✪> Fact is most ppl play with ping 20 and not 300.
10:06 < bridge> <Jupstar ✪> 
10:06 < bridge> <Jupstar ✪> With ping 300 everything teleports around
10:06 < bridge> <Jupstar ✪> So this is not as bad as you make it seem
10:06 < bridge> <fokkonaut> But thats the point where antiping is really required
10:06 < bridge> <fokkonaut> Imo you dont seem to have that full picture. Many people will complain
10:06 < bridge> <Jupstar ✪> Antiping is in first step a way to make the game feel smooth for a local player
10:06 < bridge> <Jupstar ✪> So your assumption is already wrong
10:07 < bridge> <fokkonaut> But it wont be smooth by that
10:07 < bridge> <fokkonaut> LIL
10:07 < bridge> <fokkonaut> LOL*
10:07 < bridge> <Jupstar ✪> If you remove prediction completely it will look be unsmooth too
10:07 < bridge> <fokkonaut> Anyways you only try to push your opinion today without arguments. Have a good day
10:07 < bridge> <Jupstar ✪> because you suddenly teleport around when hitting someone that isn't there
10:08 < bridge> <Jupstar ✪> No, you very clearly don't understand what antiping and prediction are
10:08 < bridge> <Jupstar ✪> That's a simple fact
10:08 < bridge> <learath2> Your entire job is to maintain the 60 tiny features for your client. We have to make sure the entire client is maintained
10:08 < bridge> <fokkonaut> Assuming things are a fact is a dangerous thing
10:08 < bridge> <Jupstar ✪> If turning off prediction could fix anything, why shouldn't we do it?
10:08 < bridge> <Jupstar ✪> That is the result of your non existing arguments
10:08 < bridge> <fokkonaut> No need to get personal
10:08 < bridge> <totar> that's fair
10:08 < bridge> <fokkonaut> Mr. mad
10:08 < bridge> <Jupstar ✪> no need to get personal
10:09 < bridge> <fokkonaut> Ha-ga
10:09 < bridge> <fokkonaut> Ha-ha
10:10 < bridge> <fokkonaut> And you clearly dont have the full picture, understanding people's needs are different from "what is logically and programatically ''''correct''''."
10:10 < bridge> <fokkonaut> And thats a fact
10:10 < bridge> <Jupstar ✪> That is your _fact_
10:10 < bridge> <fokkonaut> Ah, based on your 'argumenrs'
10:10 < bridge> <Jupstar ✪> If you dislike prediction, do cl_predict 0
10:10 < bridge> <Jupstar ✪> 
10:10 < bridge> <Jupstar ✪> good luck playing the game
10:11 < bridge> <fokkonaut> Whataboutism
10:11 < bridge> <learath2> Actually this specific thing probably looks better without prediction except for the specific case of 2 local tees, dummy + yourself
10:11 < bridge> <Jupstar ✪> That is still not the point
10:12 < bridge> <Jupstar ✪> Everything should be predicted
10:12 < bridge> <Jupstar ✪> If you want to opt-out, good luck
10:12 < bridge> <fokkonaut> maybe start clarifying your point instead
10:12 < bridge> <Jupstar ✪> If you predict half of the game and not the other, that is bad
10:12 < bridge> <Jupstar ✪> inconsistent
10:12 < bridge> <fokkonaut> .
10:12 < bridge> <fokkonaut> Tater made a good point here
10:12 < bridge> <fokkonaut> which you didnt even say anything to yet :)
10:12 < bridge> <learath2> Well if it feels better, why does consistency matter? Prediction is for UX, no?
10:12 < bridge> <Jupstar ✪> You ignored all my points about high ping
10:13 < bridge> <Jupstar ✪> Because they are arguments.
10:13 < bridge> <fokkonaut> @jupeyy_keks something's very off with you today
10:13 < bridge> <Jupstar ✪> Yeah
10:13 < bridge> <Jupstar ✪> I am trolled by random ppl in the internet
10:13 < bridge> <learath2> @totar if you've implemented predicted freezebar can we take a look? I'm curious how it feels
10:13 < bridge> <fokkonaut> Like me or Learath2?
10:13 < bridge> <fokkonaut> ^
10:14 < bridge> <fokkonaut> Maybe you should try not to be that triggered, lol. Just trying to clarify things, asking questions, but you're mad
10:14 < bridge> <Jupstar ✪> I played this game a lot in my life. The lack of prediction for lot of things was always a downer.
10:14 < bridge> <Jupstar ✪> I personally think that predicting everything, and other players should be the default, because that is the clostest to what _probably_ happens ingame
10:15 < bridge> <fokkonaut> Maybe you should try not to be that triggered, lol. Just trying to clarify things, asking questions, but you seem to be mad
10:15 < bridge> <Jupstar ✪> (esp. if anti-ping is on)
10:15 < bridge> <fokkonaut> I think you didn't even understand the issue Tater mentioned
10:15 < bridge> <Jupstar ✪> I do
10:15 < bridge> <totar> I didn't save the code but it wasn't that hard, probably worth having as a checkbox in tclient so I'll do it again.
10:15 < bridge> <Jupstar ✪> i played gores on chile servers a lot
10:16 < bridge> <Jupstar ✪> And i can ensure you, you don't concentrate on others anyway at that point anymore.
10:16 < bridge> <Jupstar ✪> They teleport like crazy
10:16 < bridge> <totar> it's not just predicted freeze bar but also predicted tee skin for other players which was the main thing imo
10:16 < bridge> <totar> it's possible that just freeze bar could be predicted
10:16 < bridge> <totar> idk how that would be
10:16 < bridge> <totar> idk how that would feel
10:16 < bridge> <learath2> Maybe predict freezebars for only local tees?
10:17 < bridge> <Jupstar ✪> Sure but not even your own freeze is predicted currently
10:17 < bridge> <Jupstar ✪> I think at least this is very bad
10:17 < bridge> <Jupstar ✪> No matter the other arguments
10:17 < bridge> <Jupstar ✪> The moment u touch someone with ping 300, u are doomed anyway
10:17 < bridge> <Jupstar ✪> Then not predicting it makes it no better
10:17 < bridge> <totar> I have an unfinished new version of the antiping smoothing algorithm which might fix this
10:18 < bridge> <totar> tclient has "ghosts" feature for other tees which makes it easy to avoid bumping them on high ping in gores
10:18 < bridge> <Jupstar ✪> The problem is always, e.g. in ddrace it can defs make sense to predict others.. Often they don't move, or you do a "normal" ddrace part
10:18 < bridge> <Jupstar ✪> And in these cases prediction will be correct even with high ping
10:18 < bridge> <Jupstar ✪> That is why I'd say there should be prediction
10:19 < bridge> <Jupstar ✪> And if ppl in gores really, which i personally doubt, are annoyed by it. Then it could be opt-out
10:19 < bridge> <Jupstar ✪> I am mostly talking about anti-ping here
10:19 < bridge> <totar> the issue with antiping is that past a certain point it's actually worse than no antiping. by extrapolating the tee position for >10 ticks you remove all the "signal" from their position which makes it impossible to figure out where they actually are.
10:20 < bridge> <totar> antiping smoothing should account for this but it doesn't really do anything
10:20 < bridge> <Jupstar ✪> Sure, but at that point the game is kinda unplayable anyway, IMHO.
10:20 < bridge> <Jupstar ✪> 
10:20 < bridge> <Jupstar ✪> If u play with chile players you simply avoid other players. That is how you play it
10:20 < bridge> <Jupstar ✪> At best you don't interact with them
10:20 < bridge> <totar> I don't think it's that unplayable
10:21 < bridge> <Jupstar ✪> Well you do up and down saves only
10:21 < bridge> <Jupstar ✪> 
10:21 < bridge> <Jupstar ✪> and stay 10 tiles away from them
10:21 < bridge> <Jupstar ✪> to not touch them
10:21 < bridge> <totar> the reason it's unplayable is because antiping is hiding all the information the server is actually telling you
10:21 < bridge> <Jupstar ✪> But the information of the server is 300ms old
10:21 < bridge> <totar> it basically teleports the tees to a random position and you have no chance to figure out where they are
10:22 < bridge> <totar> 300ms old is much better than random
10:22 < bridge> <Jupstar ✪> If someone suddenly stopped and you run into him, you are 100% doomed xD
10:22 < bridge> <Jupstar ✪> with or without antiping
10:22 < bridge> <Jupstar ✪> but 300ms is a lot of time in a high action game like gores
10:22 < bridge> <totar> you simply have not tried the tclient features that fix it lol
10:23 < bridge> <totar> hold on I'll make a video
10:29 < bridge> <totar> ok I have an issue to fix the video is delayed slightly
10:56 < bridge> <totar> normal antiping
10:56 < bridge> <totar> https://cdn.discordapp.com/attachments/293493549758939136/1283350342574145567/Base_Profile_2024.09.11_-_03.53.55.116.DVR.mp4?ex=66e2aca5&is=66e15b25&hm=1aeb396e1f2627659b5e508aac4d00e2ae119087b580625d05918087d2f174a0&
10:56 < bridge> <totar> with unpredicted ghost
10:56 < bridge> <totar> https://cdn.discordapp.com/attachments/293493549758939136/1283350376401338409/Base_Profile_2024.09.11_-_03.55.06.118.DVR.mp4?ex=66e2acad&is=66e15b2d&hm=e1a85c3d9c9c567865a003bf46d42aad162533c0606e7a79ffc0650e8d90a3d4&
10:56 < bridge> <totar> @jupeyy_keks
10:57 < bridge> <totar> when playing you just ignore the antiping player unless you're dragging them
10:57 < bridge> <totar> and I bump much less
10:57 < bridge> <totar> your brain is also much better at predicting their next 300ms of movement than the prediction is
10:59 < bridge> <totar> the bigger issue is actually not the real player bumping you but the predicted player bumping you when the bump never even happened
11:05 < bridge> <Jupstar ✪> Yes that is undoubtedly an issue.
11:05 < bridge> <Jupstar ✪> At these pings prediction ofc also misspredicts stronger. The non-prediction is still not what is actually happening in the game tho. So in this situation opt-out probably makes sense.
11:05 < bridge> <Jupstar ✪> 
11:05 < bridge> <Jupstar ✪> Funnily enough the last freeze then was correctly predicted 😄
11:05 < bridge> <Jupstar ✪> 
11:05 < bridge> <Jupstar ✪> 
11:05 < bridge> <Jupstar ✪> I'd still like to test freeze prediction with low ping (<40) to see how annoying it is there. That is still the normal experience for most players
11:06 < bridge> <totar> > Funnily enough the last freeze then was correctly predicted 😄
11:06 < bridge> <totar> 2% overall accuracy 😄
11:06 < bridge> <totar> this problem is fixable in antiping smoothing though
11:06 < bridge> <totar> as you can see even with it enabled there is almost zero smoothing
11:08 < bridge> <Jupstar ✪> What i wonder tho. let's assume only the freeze skin is predicted, not the position:
11:08 < bridge> <Jupstar ✪> Sure most of the time it would incorrectly change skin.
11:08 < bridge> <Jupstar ✪> 
11:08 < bridge> <Jupstar ✪> But the last freeze you would probably see the player is about to die (bcs close to freeze), I wonder if a visual feedback like freeze skin could make you react faster, or if the fact that skin often changes wrongly is more important
11:08 < bridge> <totar> it makes it look like you're playing in a team of ninjas
11:08 < bridge> <totar> xd
11:12 < bridge> <totar> it's unfortunately a very complicated problem. because you are must convey 2 gamestates to the player on 1 monitor. and with 1 camera position
11:14 < bridge> <totar> and then they will still have 300ms of latency on top of your 2 gamestates issue
12:01 < bridge> <shibastik> What programming language is better to learn if I want to make programs for myself, for example, a messenger with a friend
12:01 < bridge> <shibastik> Or #developer only for ddnet?
12:03 < bridge> <learath2> #developer for all developer is fine
12:03 < bridge> <learath2> Is it your first programming language you are learning?
12:03 < bridge> <shibastik> Yes
12:05 < bridge> <bebrik14._70852> https://media.discordapp.net/attachments/791748998687227964/1201960623471341689/2024-01-30_214159481.gif
12:06 < bridge> <learath2> I would usually suggest C to any starter, but if your intention is to start making useful things quickly it's not a very quick process.
12:06 < bridge> <learath2> Python is probably the easiest to get started with and start making useful stuff in
12:06 < bridge> <milkeeycat> I would choose C if I woke up one day and forgot everything I learned xd
12:07 < bridge> <shibastik> :justatest:
12:07 < bridge> <learath2> C is very good for learning no matter what the new nerds say. It forces you to learn at least some computer science
12:07 < bridge> <learath2> You need a vector, hashmap, list? Tough tits, make your own
12:07 < bridge> <milkeeycat> I remember how hard to me was to understand how to use pointers
12:08 < bridge> <shibastik> C++ or c# Is there a difference?
12:08 < bridge> <learath2> Very different languages
12:08 < bridge> <learath2> C# is closer to Java
12:08 < bridge> <shibastik> And which one to choose?
12:09 < bridge> <learath2> Depends on what you want to do. If you want to write business software for small-medium businesses targetting windows C# is much better
12:09 < bridge> <milkeeycat> https://wheelofnames.com/ type languages here and spin
12:09 < bridge> <learath2> If you want to contribute to ddnet, make your own game engine, do high performance computing C++ is the way to go
12:10 < bridge> <learath2> (Or Rust really, probably much easier to work with for a beginner)
12:10 < bridge> <meloƞ> choose a language that fits what you want to achieve, or choose one of the known "beginner" languages, (eg scripting languages like Python) - it doesn't matter what you begin with, after learning one language it's much easier to adapt to others
12:10 < bridge> <shibastik> Do I understand that C and C++ are different languages?
12:10 < bridge> <learath2> C/C++ are riddled with pitfalls. Very hard to learn properly and make useful production ready software in
12:11 < bridge> <learath2> Yes
12:11 < bridge> <learath2> Very different
12:11 < bridge> <learath2> C++ is C with many modern new features like object oriented programming support and advanced metaprogramming
12:12 < bridge> <milkeeycat> wat's meta programming :justatest:
12:12 < bridge> <learath2> templates and macros and stuff
12:12 < bridge> <shibastik> Woow im want macros hehe:kek:
12:13 < bridge> <shibastik> Im know it not allowed in ddnet
12:13 < bridge> <learath2> C has macros, but no template blackmagic
12:13 < bridge> <milkeeycat> I always thought of templates as ugly generics
12:14 < bridge> <learath2> Heinrich coming back in hot
12:15 < bridge> <learath2> I wonder what sorts of mean words I'll be called for agreeing with it this time, can't wait for a nice fruitful discussion
12:15 < bridge> <shibastik> If im want made client for ddnet me need know c++
12:16 < bridge> <learath2> Yes, C++ is essential for anything ddnet related
12:16 < bridge> <milkeeycat> but if he wants to make his own client he can choose any language he wants
12:16 < bridge> <meloƞ> dd-pg is rust based btw :cat_hehe: - but yes for regular ddnet you'd want c++ knowledge
12:17 < bridge> <learath2> Well, technically yes, but I doubt someone learning their very first programming language can reimplement teeworlds/ddnet without being able to read C++
12:26 < bridge> <shibastik> How to download c++ and where better coding? In visual studio code?
12:31 < bridge> <meloƞ> you're better of finding a video online on a develop environment for c++ using visual studio / visual studio code - when you've familiarized yourself with it look into the GitHub readme to see how to use visual studio/ visual studio code to build and run ddnet
12:31 < bridge> <learath2> Yeah, it's really hard to guide someone through the initial setup
12:33 < bridge> <Jupstar ✪> I'd suggest to start with GUI coding, because you have visual feedback directly. E.g. typescript.
12:33 < bridge> <Jupstar ✪> 
12:33 < bridge> <Jupstar ✪> When you understand some basics of coding, I'd switch to c to get a proper understanding of what programming languages do under the hood.
12:33 < bridge> <Jupstar ✪> 
12:33 < bridge> <Jupstar ✪> At last switch to rust and contribute to twgame & create a launcher
12:34 < bridge> <Jupstar ✪> I'd suggest to start with GUI coding, because you have visual feedback directly. E.g. typescript.
12:34 < bridge> <Jupstar ✪> 
12:34 < bridge> <Jupstar ✪> When you understand some basics of coding, I'd switch to c/c++ to get a proper understanding of what programming languages do under the hood.
12:34 < bridge> <Jupstar ✪> 
12:34 < bridge> <Jupstar ✪> At last switch to rust and contribute to twgame & create a launcher
12:35 < bridge> <ryozuki> got this book home from work
12:35 < bridge> <ryozuki> https://cdn.discordapp.com/attachments/293493549758939136/1283375446750400605/PXL_20240911_103524570.jpg?ex=66e2c406&is=66e17286&hm=6d46daccee87bd6abbed5e4d8530afb02cf4d7291b91fbd02990853c39e07bea&
12:48 < bridge> <shibastik> how to make two while true
12:48 < bridge> <shibastik> https://cdn.discordapp.com/attachments/293493549758939136/1283378558433235045/image.png?ex=66e2c6ec&is=66e1756c&hm=8acf0f2b7f5c88961ca3961a5b9c3d691be982f1e0e419ffe234bb181fc2b88e&
12:48 < bridge> <shibastik> or im cant?
12:50 < bridge> <shibastik> huh red cube
12:50 < bridge> <shibastik> https://cdn.discordapp.com/attachments/293493549758939136/1283379231824416811/image.png?ex=66e2c78c&is=66e1760c&hm=701fa65cea651c2f71fd8b74eb8a09253d1f32e1b322b33521c38670d7313556&
12:51 < bridge> <Jupstar ✪> In python u have to be careful with idention
12:52 < bridge> <Jupstar ✪> Your second while loop never executes, bcs it's not part of the first
12:52 < bridge> <Jupstar ✪> But while True is usually bad
12:52 < bridge> <shibastik> oke
12:52 < bridge> <shibastik> im founded c++
12:53 < bridge> <shibastik> https://cdn.discordapp.com/attachments/293493549758939136/1283379766438789170/image.png?ex=66e2c80c&is=66e1768c&hm=1668ce5d9676256af306034543e9a94da492ea71a9ca993e57a60619821b5b9f&
12:53 < bridge> <Jupstar ✪> in c++ it is also bad to use while true.
12:53 < bridge> <Jupstar ✪> 
12:53 < bridge> <Jupstar ✪> while true means "for ever"
12:53 < bridge> <Jupstar ✪> for ever:
12:53 < bridge> <Jupstar ✪>    print(r).
12:53 < bridge> <Jupstar ✪> 
12:53 < bridge> <Jupstar ✪> 
12:53 < bridge> <Jupstar ✪> It will never do anything than printing r
13:04 < bridge> <shibastik> https://cdn.discordapp.com/attachments/293493549758939136/1283382537900658710/image.png?ex=66e2caa1&is=66e17921&hm=5c66dc87e136e15d2c27133c2639876298ac37b28e0f6eaeed6dc745bd5dd771&
13:04 < bridge> <shibastik> this is c++
13:04 < bridge> <shibastik> https://cdn.discordapp.com/attachments/293493549758939136/1283382615620976733/image.png?ex=66e2cab3&is=66e17933&hm=d939f27cbbf68214e90b75fbb3f55f833f758a1fcfb89ac81a3b36f1fb553cf9&
13:04 < bridge> <meloƞ> While true
13:04 < bridge> <meloƞ> 
13:04 < bridge> <meloƞ> True is always 1
13:04 < bridge> <meloƞ> 
13:04 < bridge> <meloƞ> So this while loop is an endless loop, a bad one to be exact because there is no way for you to escape this endless loop
13:05 < bridge> <meloƞ> Ah gg Internet
13:06 < bridge> <meloƞ> Download the visual studio build tools with c++ support and the windows sdk appropriate to your system
13:07 < bridge> <shibastik> https://visualstudio.microsoft.com/ru/vs/features/cplusplus/ it?
13:07 < bridge> <meloƞ> Looks good ye
13:10 < bridge> <shibastik> I didn't really understand how I need to work in visual studio code or visual studio 2022
13:10 < bridge> <shibastik> <a:catkiss:1199448915410423988>
13:11 < bridge> <shibastik> im try using youtube
13:11 < bridge> <shibastik> lol
13:14 < bridge> <learath2> https://www.youtube.com/watch?v=DMWD7wfhgNY this looks about right for visual studio code
13:14 < bridge> <learath2> for visual studio you don't need to do anything, it's a full IDE that comes with a compiler, you can just install and use that too
13:47 < bridge> <screeeny> even comes with this :troll:  https://badoption.eu/blog/2023/01/31/code_c2.html
14:06 < bridge> <simon_1603> https://cdn.discordapp.com/attachments/293493549758939136/1283398362992869396/20240911140005_1.jpg?ex=66e2d95e&is=66e187de&hm=a997f1b25d6b3491cd6a25aa8c2f7feaff3b22d4baf96162318efa739e7469fd&
14:09 < bridge> <simon_1603> when client side chat filter?
14:21 < bridge> <Jupstar ✪> @Discord Mod ^ ban
14:24 < bridge> <shibastik> Lmao
14:26 < bridge> <Jupstar ✪> you should report that in #✉-create-a-ticket if that is serious, bcs now you just do advertisement for a cheat
14:26 < bridge> <jxsl13> "get good with cheat"
14:26 < bridge> <jxsl13> pfff
14:27 < bridge> <jxsl13> might delete the screenshot
14:27 < bridge> <shibastik> I didn't quite understand, I thought he was using krx
14:29 < bridge> <meloƞ> don't post the name of bot clients publicly please, we don't filter chat because chiller would go crazy
14:30 < bridge> <Jupstar ✪> 😂
14:30 < bridge> <simon_1603> why would u not want a chat filter?
14:30 < bridge> <Jupstar ✪> You can discuss the feature without such a screenshot
14:31 < bridge> <Jupstar ✪> We all know how chat spam looks like
14:31 < bridge> <simon_1603> it is the first time someone is actually spamming me since pepe died
14:32 < bridge> <Jupstar ✪> 🫠
14:32 < bridge> <simon_1603> there was occasionally a single message with a krx idiot
14:32 < bridge> <simon_1603> this one is the first in years to spamm 100+ messages in the chat
14:32 < bridge> <Jupstar ✪> you still shouldn't break the rules by mentioning it 😄
14:32 < bridge> <Jupstar ✪> see #7
14:33 < bridge> <Jupstar ✪> Yeah it sucks, I agree
14:33 < bridge> <simon_1603> theres not even a rule channel?
14:33 < bridge> <Jupstar ✪> Ah it's in #welcome i think
14:34 < bridge> <simon_1603> so u are saying i am not allowed to properly report krx faggots because it is against the rules?
14:34 < bridge> <Jupstar ✪> #✉-create-a-ticket
14:34 < bridge> <Jupstar ✪> promoting cheats is not allowed in public chat
14:34 < bridge> <Jupstar ✪> by mentioning it you promote it
14:34 < bridge> <simon_1603> this is the developer channel not the public chat
14:34 < bridge> <Jupstar ✪> This is the public developer channel
14:35 < bridge> <Jupstar ✪> I don't want to discuss this. Simply don't do it, because if you do it (even in good faith)
14:35 < bridge> <Jupstar ✪> others will do so too in bad faith
14:35 < bridge> <learath2> You can say whatever you want in reports, no bot client names in any channel that everyone can see
14:36 < bridge> <learath2> Not the worst idea, some people just prefer not to see certain stuff. If we don't have an issue for it we can create one
14:37 < bridge> <simon_1603> how is there not an issue for it when stepfunn already talked about a client side chat filter 2 years ago
14:37 < bridge> <learath2> https://github.com/ddnet/ddnet/issues/2304
14:37 < bridge> <learath2> Heh, you were the one that got it bumped last time too
14:37 < bridge> <learath2> I wonder why no one implemented it yet, it's a quick feature
14:38 < bridge> <Jupstar ✪> and can be cleanly separated from rest of code
14:38 < bridge> <Jupstar ✪> string in, string out
14:38 < bridge> <learath2> and is I think already implemented for serverside so just a copy paste job
14:40 < bridge> <simon_1603> how about u make a setting where ppl can add custom words to the filter for a solution to the 'creative wording'
14:40 < bridge> <learath2> In conclusion, it is my professional opinion that this feature isn't implemented because of a severe lack of developer
14:41 < bridge> <learath2> I would definitely just ship a simple list and people can add whatever they want to it as an extra
14:41 < bridge> <simon_1603> i know some python, but not how to actually program
14:42 < bridge> <learath2> We also have `str_utf8_to_skeleton` that we can use for it if we want to make it a little harder to get through with creative letters
14:43 < bridge> <learath2> We also have `str_utf8_to_skeleton` that we can use for it if we want to make it a little harder to get through with creative spelling
16:49 < bridge> <murpi> Serverside requires a server restart for the wordlist to apply (would be nice if we could change that)
16:49 < bridge> <learath2> For the serverside too?
16:50 < bridge> <murpi> Yee, I think I tested it a year ago or so
16:50 < bridge> <murpi> I had to shutdown the server first for the worldlist to apply
16:50 < bridge> <learath2> No I mean do you think there is value in it getting updated for serverside too?
16:50 < bridge> <murpi> Definitely
16:51 < bridge> <murpi> We'd be able to censor bad spam messages, without relying on the antibot (or heinrich)
16:52 < bridge> <murpi> We'd be able to censor bad spam messages, without restarting the server // relying on the antibot (or heinrich)
16:52 < bridge> <learath2> fwiw that serverside list is only used in china for now, and idk if it censors phrases or hides messages entirely
16:52 < bridge> <learath2> It might not be ideal for catching repetitive spam
16:52 < bridge> <murpi> It replaces the bad words with asterisks
16:53 < bridge> <murpi> > fwiw that serverside list is only used in china for now
16:53 < bridge> <murpi> And that's what I don't get at all, why only use it for china
16:54 < bridge> <zhn> people are creative, ull find out why all this stuff doesn't work as it should :kek:
16:54 < bridge> <murpi> This claim that people can bypass the issue by changing a few letters is a seriously weak argument overall.
16:55 < bridge> <murpi> I can't imagine that every single person who happens to be a uber racist, has a word list with every variation of the n word saved in a text document just for ddnet. It's just too silly.
16:55 < bridge> <zhn> what about rcon command to reload censored words list?
16:55 < bridge> <zhn> as we have with language client side
16:55 < bridge> <zhn> ask rei
16:55 < bridge> <zhn> :justatest:
16:55 < bridge> <murpi> The claim that people can bypass the issue by changing a few letters is a seriously weak argument overall.
16:56 < bridge> <zhn> the epic comeback of 5991
16:57 < bridge> <learath2> It was a legal requirement in china to not get us into big trouble with the big Xi
17:46 < bridge> <timakro> can someone explain why we assign `BindAddr.type` after parsing the `bindaddr` config variable using `net_host_lookup`  [here](https://github.com/ddnet/ddnet/blob/9f278979e56df5ca3791b750e62189ea3cbbb3ec/src/engine/server/server.cpp#L2722-L2727)?
17:46 < bridge> <timakro> 
17:46 < bridge> <timakro> same thing with `ec_bindaddr` for econ  [here](https://github.com/ddnet/ddnet/blob/9f278979e56df5ca3791b750e62189ea3cbbb3ec/src/engine/shared/econ.cpp#L77-L83).
17:46 < bridge> <timakro> 
17:46 < bridge> <timakro> as far as i understand it `net_host_lookup` is supposed to parse the value and set `BindAddr.type` either to `NETTYPE_IPV4` or `NETTYPE_IPV6` and this determines how the 16 bytes in `BindAddr.ip` are to be interpreted.
17:46 < bridge> <timakro> 
17:46 < bridge> <timakro> but if `BindAddr.type` is afterwards set to `NETTYPE_ALL` like in the econ code, this causes subsequent code to interpret it as both ipv4 and ipv6. when `ec_bindaddr` is `localhost` (the default) then `net_host_lookup` returns `::1` and when the first 4 bytes are interpreted as ipv4 this results in `0.0.0.0`. so by default econ is exposed publicly...
17:46 < bridge> <timakro> 
17:46 < bridge> <timakro> at first i thought this was just a bug in the econ code, but the standard server startup code does the same pattern of first calling `net_host_lookup` and then overwriting `BindAddr.type`. am i missing something?
17:49 < bridge> <jxsl13> @Chilleroni Makkaroni, you online?
17:52 < bridge> <jxsl13> what is that supposed to do, the 10hz part? on one hand you got every 2 seconds a keepalive and this is every1 second input sending?
17:52 < bridge> <jxsl13> https://cdn.discordapp.com/attachments/293493549758939136/1283455151109181562/Bildschirmfoto_2024-09-11_um_17.51.23.png?ex=66e30e41&is=66e1bcc1&hm=f3ab45a0e8e2846f5332cd6b4fb3e8737c9fd5c4db12dbcc6586919a8809c736&
17:52 < bridge> <jxsl13> @chillerdragon
18:07 < bridge> <Jupstar ✪> Looks weird, i'd create an issue on GH
18:09 < bridge> <Jupstar ✪> I wonder how you bind an addr to `NETTYPE_ALL` tho
18:09 < bridge> <timakro> i'm sending a PR
18:09 < bridge> <timakro> the code interprets the same 16 bytes as ipv6 and ipv4 (only first 4 bytes here) and binds to both
18:10 < bridge> <timakro> which is nonsense
18:10 < bridge> <Jupstar ✪> And how will you bind NETTYPE_ALL in your PR?
18:10 < bridge> <timakro> the fix is to not set `NETTYPE_ALL`
18:11 < bridge> <Jupstar ✪> and how to bind ipv6 & 4 at the same time?
18:11 < bridge> <timakro> you don't
18:11 < bridge> <timakro> at least not for econ, which is the only thing i'm touching
18:11 < bridge> <timakro> not sure how the server.cpp code works
18:11 < bridge> <Jupstar ✪> mh k
18:14 < bridge> <Jupstar ✪> "The value AF_UNSPEC indicates that
18:14 < bridge> <Jupstar ✪>               getaddrinfo() should return socket addresses for any
18:14 < bridge> <Jupstar ✪>               address family (either IPv4 or IPv6, for example)"
18:14 < bridge> <Jupstar ✪> 
18:14 < bridge> <Jupstar ✪> This would then be lost
18:22 < bridge> <timakro> it's not lost, you can specify either ipv4 or ipv6 but not both
18:28 < bridge> <meloƞ> nice catch :o
18:31 < bridge> <jxsl13> nice
18:33 < bridge> <Jupstar ✪> but then it's lost
18:34 < bridge> <Jupstar ✪> it's not both at the same time xd
18:35 < bridge> <timakro> ah but getaddrinfo() is still called on the value of `ec_binaddr` and parses the address
18:35 < bridge> <timakro> it tells us whether the address in `ec_binaddr` is an ipv4 or an ipv6 address
18:38 < bridge> <Jupstar ✪> ah right you can still use/disable `IPV6_V6ONLY` to allow ipv4 connections
18:39 < bridge> <timakro> that's totally separate but yeah
18:39 < bridge> <Jupstar ✪> yes
18:39 < bridge> <Jupstar ✪> i thought that is what we mean with ALL
18:39 < bridge> <Jupstar ✪> xd
18:39 < bridge> <timakro> my take is what i wrote in the PR:
18:39 < bridge> <timakro> > In general having a NETADDR instance with the type field set to NETTYPE_ALL never makes sense. These 16 bytes are either an ipv4 address or an ipv6 address but not both.
18:40 < bridge> <timakro> hoping there is not some black magic in the code i'm not understanding ...
18:40 < bridge> <Jupstar ✪> Yes, you are right. The black magic is that flag already
18:55 < bridge> <Jupstar ✪> @timakro will you not fix it for the other sockets? Should at least create an issue ig
18:56 < bridge> <timakro> i can open an issue
18:59 < bridge> <robyt3> Seems wrong to do it for UDP sockets, don't we currently support connecting to servers both with IPv4 and IPv6? 8930 makes it so econ only binds on either, whereas previously you could connect with both if you used `ec_bindaddr "localhost"`.
19:00 < bridge> <timakro> true, but i think it's unrelated to udp vs tcp
19:00 < bridge> <Jupstar ✪> But it's kinda weird to have a bindaddr that makes it bind to other formats
19:00 < bridge> <Jupstar ✪> maybe our bindaddr should be an array
19:00 < bridge> <timakro> i mean ip addresses are either ipv4 or ipv6 by definition. but you could make a case for a string like `localhost` to bind to both
19:01 < bridge> <robyt3> servers can bind to two different interfaces with ipv4 and ipv6 though, which seems to be the default if you don't specify a bindaddr
19:02 < bridge> <timakro> yeah we cannot lose that behavior, you're right
19:03 < bridge> <robyt3> yeah, or a separate bindaddr6 would be enough
19:05 < bridge> <timakro> binding to everything, i.e. 0.0.0.0 and [::] is actually one of the few things that can be represented using a NETADDR with NETTYPE_ALL because both are just all zeros in binary representation
19:05 < bridge> <Jupstar ✪> but that also looks hacky
19:05 < bridge> <Jupstar ✪> we should give clear solutions
19:06 < bridge> <timakro> separate bindaddr6 seems like a good solution
19:06 < bridge> <Jupstar ✪> yeah
19:06 < bridge> <Jupstar ✪> i guess that is the best xd
19:06 < bridge> <timakro> you can create an issue if you want
19:07 < bridge> <Jupstar ✪> xd
21:31 < bridge> <cellegenrih> Cool, found a bug with the `hot_reload` xd
21:32 < bridge> <Jupstar ✪> Cool
21:32 < bridge> <Jupstar ✪> Or in tux's words:
21:32 < bridge> <Jupstar ✪> Ok cool
21:38 < bridge> <cellegenrih> is there a local server crashlog that I can use?
21:42 < bridge> <Jupstar ✪> r u on windows?
22:35 < bridge> <spyres.> use pest repellent to kill the bug
22:36 < bridge> <spyres.> https://cdn.discordapp.com/attachments/293493549758939136/1283526498749382787/image.png?ex=66e350b4&is=66e1ff34&hm=dfa70ac67dc455623bd53fc257d30045846c47edd32b2e4da644a8412b45c780&
22:36 < bridge> <cellegenrih> Yes but I don't see how a gameplay feature is being affected depending on OS xd
22:40 < bridge> <furo> So, what's the bug?
22:41 < bridge> <Jupstar ✪> yes but then there should be a crashdump
22:42 < bridge> <cellegenrih> Somehow I managed to crash the server with the hot_reload feature by placing teleport to the tee's position in the editor and hot reloading upon save
22:42 < bridge> <cellegenrih> I cannot replicate it and I thought maybe by using a crashlog, I can identify it
22:43 < bridge> <cellegenrih> Upon further tests, in some cases it just doesn't teleport the player to the desired teleto position, but instead to the spawn position
22:46 < bridge> <Jupstar ✪> %appdata%/ddnet/dumps
22:47 < bridge> <cellegenrih> there is one
22:47 < bridge> <cellegenrih> https://cdn.discordapp.com/attachments/293493549758939136/1283529293359743006/DDNet-Server_win64-steam_crash_log_2024-09-11_20-35-52_9324_bae736293a2bd1921dfc121e9c730c3d8e15bc70.RTP?ex=66e3534e&is=66e201ce&hm=0a8374b7e59698fb78b37a816e453e8f267d8f33ccd9a844354a9f15ca88f381&
22:48 < bridge> <cellegenrih> It seems to match with the crash I had
22:52 < bridge> <furo> Did you `hot_reload` while in `super`? This should already be fixed in nightly.
23:10 < bridge> <Jupstar ✪> Wow
23:10 < bridge> <Jupstar ✪> _Wow_
23:10 < bridge> <Jupstar ✪> 
23:10 < bridge> <Jupstar ✪> Today i worked on the graphics card dropdown in ddpg. I opened the game over the debugger and saw that only amdvlk was in the list. I thought: ok weird, where is radv and lavapipe, like in ddnet cpp.
23:10 < bridge> <Jupstar ✪> 
23:10 < bridge> <Jupstar ✪> I assumed steam somehow modifies the env vars.
23:10 < bridge> <Jupstar ✪> 
23:11 < bridge> <Jupstar ✪> I created a release build and started without debugger and there they were.
23:11 < bridge> <Jupstar ✪> 
23:11 < bridge> <Jupstar ✪> That made me curious about a completely different problem I have since around one year. Whenever I debug the game with the sound backend on, it disconnects the debugger for an unknown reason 50% of the time.
23:11 < bridge> <Jupstar ✪> 
23:11 < bridge> <Jupstar ✪> Graphic drivers have hdmi support, hdmi has audio support. my debugger only loads amdvlk.
23:11 < bridge> <Jupstar ✪> 
23:11 < bridge> <Jupstar ✪> I uninstalled amdvlk.
23:11 < bridge> <Jupstar ✪> 
23:11 < bridge> <Jupstar ✪> The fcking sound debugger disconnect problem is gone.
23:11 < bridge> <Jupstar ✪> 
23:11 < bridge> <Jupstar ✪> 
23:11 < bridge> <Jupstar ✪> Omg dude, I just cannot believe this randomness sometimes.
23:11 < bridge> <Jupstar ✪> Completely randomly suffered for 1 year with a random weird non-sense problem. I always said radv is better than amdvlk, but i never was hostile against amdvlk. that changed today :lol: :lol: :lol: :lol:
23:11 < bridge> <Ewan> crazy
23:23 < bridge> <Jupstar ✪> nice they apparently fixed it in the q3 update from 2 weeks ago.
23:23 < bridge> <Jupstar ✪> 
23:23 < bridge> <Jupstar ✪> so if u have q2 directly purge.
23:23 < bridge> <Jupstar ✪> 
23:23 < bridge> <Jupstar ✪> man i blamed pipewire, i blamed the rust lib. i blamed everything i had. the graphics driver was really the last thing i thought about 😄
23:51 < bridge> <louis> @totar did u ever write smth on the tas algo you use ("search and refinement")?