07:57 <+bridge_> [ddnet] <Learath2> I have a new macbook pro from 2017
07:58 <+bridge_> [ddnet] <Learath2> But the superior design of apple computers allow them to become toasters when under any cpu stress, like compiling code or running a game thats supposed to run on even a banana
08:21 <+bridge_> [ddnet] <archimede67> That's pretty useful
08:22 <+bridge_> [ddnet] <archimede67> If you want to make some toasts :troll:
09:36 <+bridge_> [ddnet] <n000b> :troll:
10:47 <+bridge_> [ddnet] <ChillerDragon> wat? again a reverted donation
10:47 <+bridge_> [ddnet] <archimede67> xd
10:54 <+bridge_> [ddnet] <deen> I just forgot that I had added it already 😄
12:49 <+bridge_> [ddnet] <Learath2> @heinrich5991 curl is 7.65.0 on their computer, so I guess it's not that
12:49 <+bridge_> [ddnet] <Learath2> But it's shockingly similar. I don't get it
13:57 <+bridge_> [ddnet] <Learath2> @fokkonaut what's the idea behind your pr for projectiles in tune zones?
14:00 <+bridge_> [ddnet] <Learath2> Also when adding tunezones why wasn't tunezone 0 the default tune zone? 😄
15:29 <+bridge_> [ddnet] <Learath2> who in gods name thought it was important that cmake gets filenames alphabetically sorted
15:30 <+bridge_> [ddnet] <Learath2> Why can't the computer, which has upwards of 27000000 clock cycles per second available to it just sort the list itself and not complain like a little baby?
15:31 <+bridge_> [ddnet] <deen> Either heinrich or I thought so 😃
15:32 <+bridge_> [ddnet] <deen> In large projects keeping them sorted reduces the chance of conflicts compared to always appending your new file at the bottom.
15:33 <+bridge_> [ddnet] <Learath2> I guess... TIL . comes after the entire alphabet
15:35 <@heinrich5991> just use :sort in vim :P
15:42 <+bridge_> [ddnet] <Learath2> FINALLY
15:42 <+bridge_> [ddnet] <Learath2> After 3 decades of experimentation, the damn json library links
17:24 <+Learath2> as expected I ended up with a shitty getter in CHMasterServer that just returns a masterserver object from the array
17:25 <+Learath2> I'm way too bored of restructuring all of this, so we are keeping it, if anyone wants to rewrite it down the line they are welcome to
18:47 <+bridge_> [ddnet] <fokkonaut> @Learath2 The odea is that you can see projecties of people in tune zones without them looking buggy, so that they dont just disappear and hit you and yyou dont know why
18:48 <+bridge_> [ddnet] <fokkonaut> Often it looks weird if there are tune zones next to normal players
18:51 <+bridge_> [ddnet] <Learath2> @fokkonaut I meant as in, what's the idea behind your solution
18:54 <+bridge_> [ddnet] <fokkonaut> What do you mean?
18:54 <+bridge_> [ddnet] <fokkonaut> Oh
18:54 <+bridge_> [ddnet] <fokkonaut> ye
18:55 <+bridge_> [ddnet] <I'm not cheater> What the best visual studio?
18:55 <+bridge_> [ddnet] <fokkonaut> So, it will calculate the velocity using the original Tunings (the one that the server sends the client) and will then calculate the position with the tunings from the tunezone
18:56 <+bridge_> [ddnet] <fokkonaut> and we need to reset the projectile every 4th tick, otherwise it would fail and would look buggy again
18:57 <+bridge_> [ddnet] <Learath2> oh, every 4th tick you re-do the calculation?
18:57 <+bridge_> [ddnet] <fokkonaut> If ddnet client gets support, maybe like sending the tune value of the projectiles tune zone through the FillExtraInfo, we can easily show ddnet clients the projectiles without them being reset
18:57 <+bridge_> [ddnet] <fokkonaut> Yes, it does
18:58 <+bridge_> [ddnet] <Learath2> I'm not sure we can fit it in extrainfo
18:58 <+bridge_> [ddnet] <Learath2> but with the extended protocol i'm not sure whether we need to fit it anyway
18:59 <+bridge_> [ddnet] <Learath2> @nuborn can you take a look when you have some free time at hand? 🙂
18:59 <+bridge_> [ddnet] <nuborn> @Learath2 I was just thinking about looking at it:P
19:00 <+bridge_> [ddnet] <nuborn> are tunes stored in the map?
19:00 <+bridge_> [ddnet] <fokkonaut> Yes
19:07 <+bridge_> [ddnet] <nuborn> then the client (in theory) has what it needs to predict tunezones. perhaps it could be possible to add tunezone prediction to the client? (Im not sure how easy that would be though)
19:08 <+bridge_> [ddnet] <Learath2> Well the position of the projectile is known, and you can find whether the position is in some tunezone
19:08 <+bridge_> [ddnet] <Learath2> it shouldn't be too har
19:08 <+bridge_> [ddnet] <Learath2> d
19:08 <+bridge_> [ddnet] <fokkonaut> But
19:09 <+bridge_> [ddnet] <fokkonaut> Make sure to use the position where it started
19:09 <+bridge_> [ddnet] <fokkonaut> not where it is atm
19:13 <+bridge_> [ddnet] <Learath2> Oh is that how they work>
19:13 <+bridge_> [ddnet] <Learath2> ?
19:14 <+bridge_> [ddnet] <Learath2> It would have been so cool if the projectile could change tunezones as they go 😛
19:14 <@heinrich5991> well, the server and client only communicate the first position and only store that
19:14 <@heinrich5991> so guess how they were implemented :P
19:14 <+Learath2> ah yes, vanilla compatibility
19:17 <+bridge_> [ddnet] <fokkonaut> @Learath2 yes, it uses the position where it spawns
19:18 <+bridge_> [ddnet] <fokkonaut> (which is sometimes not the position where the player is, for example if you are on the edge of a tunezone and shoot to the open ending of the zone, then it is spawned in the Other block and therefore not in your tunezone)
20:29 <+bridge_> [ddnet] <deen> how come the mastersrvrs don't work btw? i see no attack
20:36 <+bridge_> [ddnet] <Learath2> @deen I guess ours is just completely blocked
20:44 <+bridge_> [ddnet] <deen> where?
21:08 <+bridge_> [ddnet] <Learath2> @deen I thought we had a rule for it on the firewall at nfo
21:17 <+bridge_> [ddnet] <Learath2> @deen do you know of a way to zero-initialize a object within it's constructor?
21:17 <+bridge_> [ddnet] <deen> using the initializer list and setting each member to 0
21:18 <+bridge_> [ddnet] <Learath2> I mean something that's more elegant
21:18 <+bridge_> [ddnet] <deen> or if you want to do it dirty and have no virtual functions etc, memset(0, sizeof(Class))? 😄
21:18 <+bridge_> [ddnet] <deen> with this
21:18 <+bridge_> [ddnet] <onby> memset(this, 0, sizeof(*this));
21:19 <+bridge_> [ddnet] <heinrich5991> `mem_zero` in tw
21:19 <+bridge_> [ddnet] <Learath2> `class Child : public Parent { Child(const Parent &p) : Child(), Parent(p) {}; };` I was trying sth like this
21:19 <+bridge_> [ddnet] <onby> what is the difference between mem_zero and memset
21:19 <+bridge_> [ddnet] <deen> mem_zero is always 0
21:19 <+bridge_> [ddnet] <Learath2> @onby mem_zero passes the 0 for you 😛
21:19 <+bridge_> [ddnet] <onby> ooh lol
21:19 <+bridge_> [ddnet] <heinrich5991> @onby eliminating the useless parameter that is in a weird order
21:19 <+bridge_> [ddnet] <heinrich5991> gcc even has a warning for it
21:20 <+bridge_> [ddnet] <onby> is it weird order?
21:20 <+bridge_> [ddnet] <heinrich5991> buffer, value, size
21:20 <+bridge_> [ddnet] <Learath2> @heinrich5991 it's not too unusual of an order, "dst, src, size" is pretty common in the c stdlib
21:20 <+bridge_> [ddnet] <heinrich5991> instead of grouping buffer and size together
21:20 <+bridge_> [ddnet] <heinrich5991> @Learath2 the size is usually next to a buffer of that size
21:20 <+bridge_> [ddnet] <Learath2> well memcpy and strcpy would beg the differ 😛
21:21 <+bridge_> [ddnet] <heinrich5991> not memcpy *shrug8
21:21 <+bridge_> [ddnet] <heinrich5991> not memcpy *shrug*
21:21 <+bridge_> [ddnet] <Learath2> anyways, we are drifting, is anything like what I'm trying possible short of initializing every member that only belongs to Child?
21:21 <+bridge_> [ddnet] <Learath2> `void *memcpy(void *dest, const void *src, size_t n);`
21:22 <+bridge_> [ddnet] <heinrich5991> copy n bytes from src to dest
21:22 <+bridge_> [ddnet] <heinrich5991> mem_zero(((unsigned char *)this) + sizeof(Parent), sizeof(*this) - sizeof(Parent));
21:22 <+bridge_> [ddnet] <heinrich5991> `mem_zero(((unsigned char *)this) + sizeof(Parent), sizeof(*this) - sizeof(Parent));`
21:23 <+bridge_> [ddnet] <Learath2> @heinrich5991 that's worse lol
21:23 <+bridge_> [ddnet] <Learath2> is that ever safe?\
21:23 <+bridge_> [ddnet] <heinrich5991> I guess it's as safe as `mem_zero`ing a structure at all
21:23 <+bridge_> [ddnet] <Learath2> it's not a structure, it's a class, it has a vtable
21:24 <+bridge_> [ddnet] <heinrich5991> then don't do it I guess
21:24 <+bridge_> [ddnet] <heinrich5991> I mean what I suggested
21:24 <+bridge_> [ddnet] <heinrich5991> I guess initialize all the members explicitly
21:26 <+bridge_> [ddnet] <deen> it's safe for a pod
21:26 <+bridge_> [ddnet] <Learath2> I mean I'm not retarded, I asked because you people are more familiar with c++
21:26 <+bridge_> [ddnet] <Learath2> I can obviously initialise it explicitly
21:26 <+bridge_> [ddnet] <deen> initialize all explicitly and add the compiler warning that warns about uninitialized members, then you won't forget them
21:26 <+bridge_> [ddnet] <deen> (maybe it was a clang-tidy)
21:26 <+bridge_> [ddnet] <heinrich5991> (what I wanted to say is that I don't see a better way than initializing the members manually)
21:27 <+bridge_> [ddnet] <Ryozuki> wdym by pod
21:27 <+bridge_> [ddnet] <heinrich5991> plain old data
21:27 <+bridge_> [ddnet] <deen> you could also list all members like "int x{0};"
21:27 <+bridge_> [ddnet] <heinrich5991> i.e. nothing with constructors etc.
21:27 <+bridge_> [ddnet] <deen> then the constructor doesn't have to init them, will happen implicitly
21:27 <+bridge_> [ddnet] <Ryozuki> ah
21:27 <+bridge_> [ddnet] <heinrich5991> https://en.cppreference.com/w/cpp/named_req/PODType