00:01 <+bridge_> [ddnet] I just tested my suggested change, that would break the complete physics... so we probably should leave it as it is 00:14 <+bridge_> [ddnet] why do i suddenly have 180+ ping on ger2? 00:15 <+bridge_> [ddnet] im in the middle of a map and suddenly i have a constant 180 ping 00:15 <+bridge_> [ddnet] did i get rerouted in the middle of playing? 00:19 <+bridge_> [ddnet] can /practice in a team with your dummy require only 1 vote instead of 2 00:21 <+bridge_> [ddnet] sounds like it 00:22 <+bridge_> [ddnet] no, server doesn't know the difference between another player and dummy 00:22 <+bridge_> [ddnet] why? 03:17 <+bridge_> [ddnet] have you ever had a computer that shuts down just like there was a power cut? 03:17 <+bridge_> [ddnet] my old thinkpad just did that, and it's not the first time 03:18 <+bridge_> [ddnet] all kernel logs show nothing, except sometimes the last line before reboot is truncated and filled with null bytes 03:18 <+bridge_> [ddnet] time to save my work on usb stick 🙂 03:21 <+bridge_> [ddnet] perhaps the hardware powered down because it was overheating 03:47 <+bridge_> [ddnet] nah, laptop is cold, and overheating would have a trace in kernel logs 03:47 <+bridge_> [ddnet] i was just typesetting some latex, nothing fancy 03:48 <+bridge_> [ddnet] why would overheating turn up in kernel logs? 03:48 <+bridge_> [ddnet] isn't that mostly hardware stuff? 03:48 <+bridge_> [ddnet] i suppose there might be a shortcut because it happend when i layed down my hands on the keyboard quite fast 03:48 <+bridge_> [ddnet] nah, it triggers an interrupt first 03:49 <+bridge_> [ddnet] when the interrupt is fired, the kernel has like 15ms before going down 03:49 <+bridge_> [ddnet] oh 03:49 <+bridge_> [ddnet] TIL 03:49 <+bridge_> [ddnet] at least, it's the case in most embedded cpu i worked on 03:50 <+bridge_> [ddnet] temperature cinetic allows this stuff 03:55 <+bridge_> [ddnet] this is final message in `/var/log/kern.log`: 03:55 <+bridge_> [ddnet] ```shell 03:55 <+bridge_> [ddnet] May 3 03:08:30 hostname kernel: [36837.329504] [UFW BLOCK] IN=enp0s25 OUT= MAC=12:34:56:78:9a:bc:de:f0:12:34:56:78:9a:bc SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2 03:55 <+bridge_> [ddnet] May 3 03:10:30 hostname kernel: [ 0.000000] microcode: microcode updated early to revision 0x2f, date = 2019-02-17 03:55 <+bridge_> [ddnet] ``` 04:14 <+bridge_> [ddnet] there's also an interrupt when power goes down 04:14 <+bridge_> [ddnet] first there's brown out interrupt 04:15 <+bridge_> [ddnet] then there's black out interrupt 04:15 <+bridge_> [ddnet] black out interrupt typically state, cpu can execute at x instructions (not guarenteed) 04:15 <+bridge_> [ddnet] black out interrupt typically ste, cpu can execute at x instructions (not guarenteed) 04:15 <+bridge_> [ddnet] black out interrupt typically state, cpu can execute at x instructions (not guarenteed) 04:15 <+bridge_> [ddnet] black out interrupt typically state, cpu can execute x instructions (not guarenteed) 09:05 <+ChillerDragon> bra Ac1dBeef stap reconnecting :/ 10:06 <+bridge_> [ddnet] does anyone know if using references within functions has disadvantages? 10:06 <+bridge_> [ddnet] https://www.tutorialspoint.com/cplusplus/cpp_references.htm 10:06 <+bridge_> [ddnet] 10:06 <+bridge_> [ddnet] E.g. if I do something like `vec2 &ViewPos = pGameServer->m_apPlayers[SnappingClient]->m_ViewPos;` so I don't have to write the long expression repeatedly? Is it better to use a reference than a pointer? 10:28 <+ChillerDragon> use a macro :trol: 10:29 <+ChillerDragon> i think jupstar once said that refrences are the better pointers 10:29 <+bridge_> [ddnet] <ᶰ°Konͧsti> Could be just fixed by one vote per IP to use practice 10:30 <+ChillerDragon> ddnet/2021-09-15.log:38:12:01 <+bridge> [ddnet] reference is bascially same as pointer, just without uglyness and NULL xd 10:30 <+ChillerDragon> @c0d3d3v ^ 10:31 <+ChillerDragon> https://ddnet.tw/irclogs/2021-02-15.log 11:06 <+bridge_> [ddnet] if anything you can actually gain (at least on msvc) from using a reference/pointer instead of writing long chains everywhere 11:15 <+ChillerDragon> omagwad im too stopid to write collision code -.- send brain 11:15 <+bridge_> [ddnet] if anything you can actually gain (at least on msvc) from using a reference/pointer instead of writing long chains everywhere, but other than that no difference 11:18 <+bridge_> [ddnet] if anything you can actually gain (at least on msvc) from using a reference/pointer instead of writing long chains everywhere 11:28 <+bridge_> [ddnet] i think its better to use the reference 13:36 <+ChillerDragon> this guy 13:37 <+ChillerDragon> I think i need a better irc client or filter out connection messages in weechat -.- 13:47 <+bridge_> [ddnet] ``` 13:47 <+bridge_> [ddnet] /set irc.look.smart_filter on 13:47 <+bridge_> [ddnet] /filter add irc_smart * irc_smart_filter * 13:47 <+bridge_> [ddnet] ``` 13:47 <+bridge_> [ddnet] https://blog.weechat.org/post/2008/10/25/Smart-IRC-join-part-quit-message-filter 13:57 <+ChillerDragon> ye i also did that but then i realized i wanna see those messages 13:58 <+ChillerDragon> but this guy is literally flooding it -.- 13:58 <+ChillerDragon> https://zillyhuhn.com/OpenTube/videos/users/chiller/chichilku3_collision.mp4 13:58 <+ChillerDragon> bad collision code? or awesome walljump feature? :D 13:59 <+ChillerDragon> Ac1dBeef:! 14:02 <+bridge_> [ddnet] while revising and testing the dragger.cpp I noticed that two different ranges are used in the old code. 14:02 <+bridge_> [ddnet] First the characters nearby are selected here: 14:02 <+bridge_> [ddnet] Here the range g_Config.m_SvDraggerRange is used but in the function FindEntities the m_ProximityRadius = 28 of a char is added. 14:02 <+bridge_> [ddnet] And later in the code the tee is droped (so not pulled) because of this line, because the m_ProximityRadius was not added: 14:02 <+bridge_> [ddnet] 14:02 <+bridge_> [ddnet] 14:02 <+bridge_> [ddnet] Should I also ignore the m_ProximityRadius in the new dragger? I do not think any map would suffer if we would add m_ProximityRadius but it is a physics change 14:20 <+bridge_> [ddnet] This basicly increases the range of a dragger by ~half a tee 14:27 <+bridge_> [ddnet] This would basically increases the range of a dragger by ~half a tee 14:29 <+bridge_> [ddnet] If someone wants to give his opinion on this please tag me or write it on the PR https://github.com/ddnet/ddnet/pull/5063 so I can read it later.... 15:28 <+bridge_> [ddnet] when i have problem with lag, someone let me download 16.0-rc1 beta with vulkan, but now i don't receive new update, what i need to do :d 15:59 <+bridge_> [ddnet] download the latest client 15:59 <+bridge_> [ddnet] from the web 15:59 <+bridge_> [ddnet] it has vulkan too 15:59 <+bridge_> [ddnet] and better 15:59 <+bridge_> [ddnet] https://ddnet.tw/ 16:02 <+bridge_> [ddnet] one thing i noticed is lot of ppl force push on pull requests, but specially on large prs this makes revieweing harder 16:02 <+bridge_> [ddnet] because you don't have a diff from your last review 16:02 <+bridge_> [ddnet] so u gotta check all over again 16:02 <+bridge_> [ddnet] imho i would rebase when its finally reviewed into a clean commit 16:14 <+bridge_> [ddnet] xD do you mean me? 16:14 <+bridge_> [ddnet] xd in general 16:14 <+bridge_> [ddnet] but in this case i said this cuz i noticed heinrich 16:14 <+bridge_> [ddnet] force pushed the master server pr 16:16 <+bridge_> [ddnet] I think he published it as draft just that we can have a sneek preview... Was not ready for review 16:16 <+bridge_> [ddnet] ah 16:16 <+bridge_> [ddnet] ok xd 17:48 <+bridge_> [ddnet] 🇮🇳 18:08 <+bridge_> [ddnet] A question about prediction. 18:08 <+bridge_> [ddnet] Other players hooks are predicted? 18:08 <+bridge_> [ddnet] What if a tee near you is hooking another tee out of camera? 18:08 <+bridge_> [ddnet] Is prediction broken? 18:08 <+bridge_> [ddnet] Or is hook predicted with destination point too? 20:55 <+bridge_> [ddnet] the prediction needs the hooked character, so if the hooked character is network clipped the hook won't get predicted