00:05 < bridge> Hi, I removed a bug from the winter_main rules and improved them by using the NoLayerCopy option. Now you only have to automap it once instead of spamming the rules. 00:05 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/762325668851089418/winter_main.rules?ex=685eaf9a&is=685d5e1a&hm=3eca88b77c498dffd7e333671997a282a23c47c234c862d3f53134e4acab8130& 03:22 < bridge> <_fresh_0> SHES SHOWING HER BODY ON CAM AND TOUCHING HERSELF IN VC JOIN https://discord.gg/DMTPa4hu https://cdn.discordapp.com/attachments/1376627483293520082/1387960997595189308/image.png?ex=685f3ee8&is=685ded68&hm=2bb377c4d5e0f8d3bf5fece00a34cf962ef0399fcbff5bd95e7047a471e23de3& @everyone 07:34 < bridge> morning 07:37 < bridge> morning people blindly merging prs about clang tidy 20 and others 07:48 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1388033127808630804/image.png?ex=685f8216&is=685e3096&hm=e073131b7922a9eedf6f91ac1db66c79a011d5b88f957b92e62c089e8d76c9e0& 08:34 < bridge> ``` 08:34 < bridge> /* C99: An integer type that can be accessed as an atomic entity, 08:34 < bridge> even in the presence of asynchronous interrupts. 08:34 < bridge> It is not currently necessary for this to be machine-specific. */ 08:34 < bridge> typedef int __sig_atomic_t; 08:34 < bridge> ``` 08:34 < bridge> mfw int is just atomic now 08:36 < bridge> ill miss u :v 08:36 < bridge> ): 10:17 < bridge> On x86 ints are by default atomic 10:18 < bridge> What does that even mean? 10:18 < bridge> Atleast atomic enough for the requirements of `__sig_atomic_t` 10:18 < bridge> All ints are thread safe on regular machines? Xd 10:18 < bridge> Atomic != thread safe 10:19 < bridge> What is it 10:19 < bridge> Huh? You previously had an incoherent reply comment there 10:20 < bridge> Full-size loads and stores are just atomic in x86. That is you will never observe a half updated value. You'll always see either the old value or the new value 10:20 < bridge> i kept trying to explain the same thing to the same response but it kept being dropped or put on the wrong one 10:20 < bridge> Ah ok that’s also nice @learath2 10:21 < bridge> I think you can't reply with an open review, you need to be on the main page of the PR and not /files to make comments immediately 10:21 < bridge> i was on mobile and sketchy internt 10:21 < bridge> Thread-safe defined in the usual way implies that there is some sort of defined order of operations, which just the int being atomic cant guarantee 10:22 < bridge> Also explictly atomic declared ints are harder to optimize for the compiler 10:22 < bridge> why 10:22 < bridge> One of the reasons is what learath says 10:22 < bridge> The order of execution 10:23 < bridge> atomic doesnt mean it has defined order of execution 10:23 < bridge> unless you use the functions which set them 10:23 < bridge> But generally even relaxed atomics, since the compiler has to assume it's used somewhere outside of the current scope 10:23 < bridge> static 😍 10:24 < bridge> static? 10:24 < bridge> static is most liikely the worst to use in any case 10:24 < bridge> if its in 1 translation unit and not volatile then it cant be assumed to be used outside 10:24 < bridge> (idk why the IsInterupted is volatile) 10:24 < bridge> a static variable is not the same as a static function 10:25 < bridge> also with scope i did not mean a cpp file 10:25 < bridge> you can have name conflicts across translation units though 10:25 < bridge> I meant the scope that is implied by runtime 10:25 < bridge> you can have name conflicts across translation units though (it feels like they are similar) 10:25 < bridge> ehmm 10:25 < bridge> https://tenor.com/view/wtff-cat-confused-orange-gif-25858653 10:26 < bridge> E.g. calling a function creates a scope 10:26 < bridge> Or every { .. } 10:26 < bridge> yeah 10:26 < bridge> is a compiler not allowed to assume that weird stack shenangs wont happen 10:27 < bridge> ```cpp 10:27 < bridge> int main() { 10:27 < bridge> int a = 3; 10:27 < bridge> { 10:27 < bridge> int b; 10:27 < bridge> *(&b - 1) = 5; 10:27 < bridge> } 10:27 < bridge> printf("%d\n", a); 10:27 < bridge> } 10:27 < bridge> ``` 10:27 < bridge> i wonder what this compiles to 10:27 < bridge> and if it works 10:27 < bridge> I think as long as all your loads and stores are relaxed ones `std::atomic` should basically be equivalent to an `int` (on x86). Except for the fact that unsynchronized loads and stores to it from different threads is not UB 10:27 < bridge> if you build without optimizations 10:27 < bridge> it will most likely build and work 10:28 < bridge> But afaik the compiler cannot keep this atomic inside a register 10:28 < bridge> why arent we using an std::atomic for that, we dont really care about order 10:28 < bridge> Well always depends on the size of the program anyway 10:29 < bridge> why arent we using an std::atomic for IsInterupted, we dont really care about order 10:29 < bridge> with -O3 the compiler just ommits the = 5 bit?? 10:29 < bridge> with -O1/2/3 the compiler just ommits the = 5 bit?? 10:29 < bridge> What? 10:30 < bridge> cuz it moves a and b to registers 10:30 < bridge> With O1 the compiler will probs remove anything that isn't the printf 10:30 < bridge> (already) 10:30 < bridge> ```asm 10:30 < bridge> main: 10:30 < bridge> push rax 10:30 < bridge> lea rdi, [rip + .L.str] 10:30 < bridge> mov esi, 3 10:30 < bridge> xor eax, eax 10:30 < bridge> call printf@PLT 10:30 < bridge> xor eax, eax 10:30 < bridge> pop rcx 10:30 < bridge> ret 10:30 < bridge> 10:30 < bridge> .L.str: 10:30 < bridge> .asciz "%d\n" 10:30 < bridge> ``` 10:30 < bridge> Tja 10:30 < bridge> no syntax highlighting \: 10:30 < bridge> undefined behavior 10:30 < bridge> hehe 10:31 < bridge> well int b isnt optimized to a register, infact its just dead code 10:31 < bridge> It's not dead code 10:31 < bridge> It's UB 10:31 < bridge> It is definitely UB, your pointer arithmetic is not allowed to go outside the object (except for the special case of one past an array, and only as long as you don't do anything with the pointer) 10:32 < bridge> yayyy 10:32 < bridge> volatiles can be in registers? 10:33 < bridge> Oh, yeah. I guess maybe if it can somehow prove that an atomic is not reachable from outside this thread 10:33 < bridge> vm 10:33 < bridge> misread 10:33 < bridge> nvm 10:34 < bridge> Do we have an IsInterrupted somewhere? 10:34 < bridge> ```cpp 10:34 < bridge> volatile sig_atomic_t InterruptSignaled = 0; 10:34 < bridge> 10:34 < bridge> bool IsInterrupted() 10:34 < bridge> { 10:34 < bridge> return InterruptSignaled; 10:34 < bridge> } 10:34 < bridge> 10:34 < bridge> void HandleSigIntTerm(int Param) 10:34 < bridge> { 10:34 < bridge> InterruptSignaled = 1; 10:34 < bridge> ``` 10:34 < bridge> Because only `volatile sig_atomic_t` is allowed to be used in a signal handler 10:34 < bridge> `volatile __sig_atomic_t` is atomic enough for this 10:35 < bridge> whaaa 10:35 < bridge> > An integer type which can be accessed as an atomic entity even in the presence of asynchronous interrupts made by signals. 10:35 < bridge> why do signal handlers have this restriction 10:35 < bridge> Surely `std::atomic_flag` is also legal 10:36 < bridge> Probably because they perform some dark magic 10:36 < bridge> they just push the current regs to stack, do stuff, pop from stack i thought 10:36 < bridge> > Until C++11, which introduced std::atomic and std::atomic_signal_fence, about the only thing a strictly conforming program could do in a signal handler was to assign a value to a volatile static std::sig_atomic_t variable and promptly return. 10:36 < bridge> Ah, I remember why the restriction. Because `std::atomic`s are not guaranteed to be lockfree 10:37 < bridge> signal handlers arent allowed locks? 10:37 < bridge> So after C++11 it's fine to have an atomic? At least that's how I read it 10:37 < bridge> ive never run into this restriction, ive been able to do everything inside signal handlers x-x 10:38 < bridge> Main thread starts writing to non-lockfree atomic. It gets interrupted. The interrupt handler starts waiting on the lock. Deadlock 10:38 < bridge> yeah, the sources originally stating that only `sig_atomic_t` is safe might be outdated since C++11 10:38 < bridge> oh i see 10:39 < bridge> I do not remember or know if the standard explicitly forbids it. But I do remember that's why you are not supposed to do it 10:39 < bridge> but if its another thread which does anything with the lock it should be fine 10:39 < bridge> You are only allowed to use async-signal-safe functions as well: https://man7.org/linux/man-pages/man7/signal-safety.7.html 10:41 < bridge> If you do not want to summon nasal demons, your best bet is to just message your main thread through some lock-free signal-safe means and just return from your interrupt handler 10:42 < bridge> TIL sometimes if are better if cpu can predict it, however a miss prediction is way WORSE than if u use a cmov, which doesnt benefit from branch pred cuz there are no branches but it cant miss 10:42 < bridge> i guess llvm and gcc already take care of this anyway 10:43 < bridge> i wonder if llvm has a model to know when predictions are succesful 10:43 < bridge> it would be cool if a function taking a function ptr could say "this is a callback, im going to call this so you better not assume anything abt this value either at all or while this function is being called" 10:43 < bridge> You mean a conditional jump can be better than a cmov? I can see it being the case. I wonder on average what is better 10:43 < bridge> rather than pushing it to the porgammer 10:43 < bridge> ye 10:43 < bridge> cond jump has a better best case and a worst worst case 10:44 < bridge> u could say cmov is more "predictable" 😉 10:44 < bridge> Is a cmov 0 cost if the mov doesn't happen? 10:44 < bridge> (Ignoring the constant overhead of decoding an instruction) 10:45 < bridge> I wanted to see what the rust compiler does, but it's just chaos for me lmao: 10:45 < bridge> 10:45 < bridge> Or I use godbolt incorrectly lol 10:45 < bridge> 10:45 < bridge> https://godbolt.org/z/84bPsvMjr 10:45 < bridge> > They are instructions that are executed to compute the result based on condition codes, i.e. predicated instructions. Some architectures (like ARM) can predicate many forms of instructions based on condition codes, but x86 can only do "mov", that is, the conditional move (CMOV). These are decoded, and executed with latency in order to determine the result of the instruction. 10:45 < bridge> any1 know why this test is failing 10:45 < bridge> 10:45 < bridge> I'm no good at decoding assembly generated by rust 10:45 < bridge> > Branches, on the other hand, are predicted and actually steer the execution of instructions. The branch predictor "looks ahead" of the instruction "fetcher", specifically looking for branch instructions, and predicts the path by steering the flow 10:45 < bridge> I can usually read C, some Obj-C and some go 10:46 < bridge> > CMOVs used to be really bad (very high latency) but have since improved to be pretty fast, making them a lot more usable and performance-worthy. 10:47 < bridge> @jupeyy_keks i recommend u use std::hint::black_box 10:47 < bridge> to avoid optimizing constants 10:48 < bridge> Looks about sane? It didn't put the atomic in a register though, so not that smart 10:48 < bridge> https://godbolt.org/z/7nM54n36q 10:48 < bridge> Yeah c looks similar 10:50 < bridge> Actually the c asm looks worse even 10:50 < bridge> If it was a normal int the compiler would optimize this down to just a constant return 10:50 < bridge> I put the normal int on right side 10:50 < bridge> Can you not see it? 10:50 < bridge> Maybe in mobile it doesn't work lol 10:51 < bridge> Ah, nope, not on mobile 😄 10:51 < bridge> why are u using relaxed? 10:51 < bridge> Bcs that is the "fastest" 10:51 < bridge> To get rid of intra-thread requirements 10:51 < bridge> > fetch_add takes an Ordering argument which describes the memory ordering of this operation. All ordering modes are possible. Note that using Acquire makes the store part of this operation Relaxed, and using Release makes the load part Relaxed. 10:51 < bridge> I can't find my testserver in Teeworlds 0.7, what do I need to activate to be found there? 10:52 < bridge> If there is no intra-thread ordering requirements then the compiler is free to pretty much make it an int on x86 afaict 10:52 < bridge> `sv_sixup` 10:53 < bridge> You also need to provide a map7 map 10:54 < bridge> ``` 10:54 < bridge> > sv_sixup 1 10:54 < bridge> 2025-06-27 10:54:10 I server: ClientId=0 rcon='sv_sixup 1' 10:54 < bridge> 2025-06-27 10:54:10 I register/7/ipv4: deleting... 10:54 < bridge> 2025-06-27 10:54:10 E sixup: couldn't load map maps7/ctf1.map 10:54 < bridge> 2025-06-27 10:54:10 I sixup: disabling 0.7 compatibility 10:54 < bridge> 2025-06-27 10:54:10 I register/7/ipv4: successfully registered 10:54 < bridge> 2025-06-27 10:54:10 I server: player has entered the game. ClientId=0 addr=XXX sixup=0 10:54 < bridge> 2025-06-27 10:54:10 I ddnet: cid=0 version=19030 10:54 < bridge> 2025-06-27 10:54:10 I dbg: record holder: Assa 10:54 < bridge> > sv_sixup 10:54 < bridge> 2025-06-27 10:54:12 I server: ClientId=0 rcon='sv_sixup' 10:55 < bridge> 2025-06-27 10:54:12 I config: Value: 0 10:55 < bridge> ``` 10:55 < bridge> oh yes 10:55 < bridge> eugh 😦 10:55 < bridge> Once upon a time I did think about just generating the map7 on mapchange if not found 10:55 < bridge> But it was useless for ddnet, so I didn't bother. And it is not trivial iirc 10:56 < bridge> I mean we have a converter, but it would defs have runtime overhead 10:56 < bridge> my_fancy_convert_tool --input imap --output omap :justatest: 10:56 < bridge> But yeah doesnt matter on map change probs 10:56 < bridge> We have a converter 10:56 < bridge> Do you think deen does it by hand? XD 10:56 < bridge> no ofc not 10:57 < bridge> `map_convert_07` 10:57 < bridge> he probs has a crontab doing this automatically if you add a map to your map directory 10:59 < bridge> beatiful, 0.7 player joins, but is in endless loading screen 11:00 < bridge> The server also rewrites the entire map as a temporary on load if a `cfg` file with settings exists. Not sure if that is a good idea. 11:01 < bridge> hmm it works if I set the gamemode to ddnet .___. 11:03 < bridge> I don’t like the ddnet map converter tool 11:04 < bridge> Rewrite in rust 11:04 < bridge> It just embeds everything instead of using native 0.7 textures 11:04 < bridge> I rewrote in python 11:04 < bridge> 🫠 11:06 < ws-client> its troll to embed grass_doodads 0.6 as external image and show it to 0.7 clients 11:06 < ws-client> they want native grass_doodads 0.7 11:06 < ws-client> just rearrange using https://github.com/ChillerDragon/twmap_6to7 11:06 < bridge> Ok, but when make it faster 11:06 < ws-client> its fast enuff 11:07 < bridge> Oke 11:10 < bridge> Isn't the idea to make sure the map looks the same on both sides of the bridge? 11:12 < ws-client> no @learath2 11:12 < ws-client> native > same 11:12 < ws-client> you dont upgrade to 0.7 to get a 0.6 look 11:12 < bridge> You don't downgrade to 0.7 at all 11:13 < ws-client> also you can tell the script to throw warnings if it cant reflect it exactly 11:13 < ws-client> many maps can be made look exactly the same just using a smaller map size 11:13 < bridge> anybody an idea why this could be? 11:13 < bridge> "upgrade" :kekW: :Kleek: :KEK: :Keking: 11:13 < bridge> :KEKW: :kekw: :KEK4K: :kekfu: :Feelskekman: 11:13 < ws-client> are you saying 0.6 is better? 11:14 < ws-client> its old ass client 11:14 < bridge> Note that ddnet uses fixed 0.6 assets anyway 11:14 < ws-client> doesnt even properly support 4k on windows irrc 11:14 < bridge> 11:14 < bridge> :CursedKek: 11:15 < bridge> Ok, enough. Thanks for bringing some laughter into my breakfast 11:15 < ws-client> send breakfast 11:15 < ws-client> im stuck here starving 11:15 < ws-client> not caffeinated 11:15 < ws-client> im about to go crazy 11:15 < bridge> Here have a coffee 11:15 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1388085375041540198/rn_image_picker_lib_temp_5719f018-8033-458c-86d9-06d39cb502c8.jpg?ex=685fb2be&is=685e613e&hm=f6960646176d094cf2ed944923f3f8608b0481fb6a874eea1df93566b1ea7afe& 11:15 < ws-client> pog 11:15 < bridge> Automatika Munich, come! 11:15 < ws-client> u there rn? 11:16 < bridge> Ye 11:16 < ws-client> is it hot? 11:16 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1388085490439159978/PXL_20250627_084329123.jpg?ex=685fb2da&is=685e615a&hm=70f04d924bcb03b63aef1199751c11df22a449cf09895845698efb35c0080328& 11:16 < bridge> Nah its great 11:16 < ws-client> is it free? 11:16 < bridge> No 11:16 < bridge> wait I was sending 1 wrong snap for the flags 11:16 < bridge> as chillerdragon pointed out 11:16 < bridge> and it was causing the 0.7 client NOT TO CONNECT AT ALL? 11:17 < ws-client> hmm not sure 11:17 < ws-client> yea maybe if you send a corrupted snap it will drop it 11:18 < ws-client> i wouldnt know i only ever write perfect code 11:20 < bridge> now race works, but fastcap is not, but I don't send any different snaps oO 11:20 < ws-client> @melon messestadt riem? 11:20 < ws-client> too far, otherwise i would have stream sniped you 11:20 < ws-client> @Assa go make ur server public 11:21 < bridge> Messestadt süd 11:21 < ws-client> wallah krise 11:21 < bridge> Sad, I would've bought you a coffee 11:21 < ws-client> epic 11:22 < bridge> it is already 11:22 < ws-client> send ip 11:22 < bridge> Localhost:8000 11:23 < bridge> it wasn't because I restarted in between ... 11:23 < bridge> ``` 11:23 < bridge> Darkchips TestServer 11:23 < bridge> Address: ddnet://93.244.26.92:8303 11:23 < bridge> ``` 11:23 < ws-client> darkchiüs 11:23 < ws-client> wot 11:23 < bridge> You can take a look at the last bite of this granola bowl with blackberries 11:23 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1388087352022536243/rn_image_picker_lib_temp_956ef73d-2e4a-4496-a4c4-5d429b18345a.jpg?ex=685fb496&is=685e6316&hm=bd7f419db22d6d2f4ba37fc0cfbb8fd24b98307406d2349b506f2cb9e44df898& 11:23 < bridge> guess the pw on the test server for testing 11:23 < ws-client> its encrypted server 11:23 < ws-client> with cyber lock 11:23 < ws-client> thanks lerato i feel better now 11:24 < bridge> Well now it's technically a granola bowl with one blackberry 11:24 < ws-client> @Assa it was not ilikehentai 11:31 < ws-client> @Assa https://paste.zillyhuhn.com/Q1 11:31 < bridge> do I need to study egyptology? 11:31 < ws-client> lgtm 11:32 < ws-client> wait no 11:32 < ws-client> this is the first snap your server sends https://paste.zillyhuhn.com/k4 11:34 < ws-client> u just dont snap Characters 11:34 < ws-client> thats why we dont see any tees xd 11:34 < ws-client> look at this healthy snap of ddnet gametype https://paste.zillyhuhn.com/PJ 11:35 < ws-client> maps with pickups are always annoying when looking at the snap 11:35 < ws-client> you gotta snap those characters 11:36 < ws-client> or maybe the client drops them because you snap invalid characters but that should log 11:36 < ws-client> where is your code? 11:36 < ws-client> is the old branch up to date? 11:38 < bridge> well at least at this place, I fixed the flag snap as you pointed out in my review 11:40 < bridge> The only thing I see, which you also pointed out, is that snapping client might be -1 and this is not handled in the pickup 11:40 < bridge> but this shouldn't affect character snap, should it? 11:44 < ws-client> no 11:44 < ws-client> this will just crash your server if you turn on demos 11:47 < bridge> this is so cryptic for me, like why only on sv_fastcap 1 11:50 < bridge> I have to pickup my gf, I am already late, sorry chiller, I'll let the server open 11:55 < ws-client> https://zillyhuhn.com/cs/.1751018107.png 11:55 < ws-client> i see flagen 11:57 < bridge> ich seh zwei 11:59 < bridge> Is this a joke about me being a red flag? Or do you see blue? 11:59 < bridge> Oh no 11:59 < bridge> It’s country flag? 12:09 < ws-client> @Assa so in fast cap you force the spawn to be either red or blue and your test server was dm1 ... 12:11 < bridge> reminds me of your comment on one of my videos. was funny xd 12:12 < ws-client> wot 12:12 < ws-client> a 12:12 < ws-client> i remember 12:34 < bridge> wot? D: 12:41 < bridge> I made this skin to show the square size of the tee against the map, the round size of the tee against other tees and the hitbox which is the big circle. Coincidentally the hitbox also almost exactly defines the hammer range(when the hitboxes touch: tees are within hammer range). It also shows center lines(when the center of the cross enters freeze the tee is frozen) and i tried to make the eye point accurately in the direction of aiming. 12:41 < bridge> 12:41 < bridge> Initially I just had the question "how big is a tee really?" when drawing a skin which lead me to make this. It can be helpful to play with but also to use as a basis to make skins with more accurate dimensions. 12:41 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/808898683320008714/screenshot_2021-02-06_16-09-18.png?ex=685f5e1a&is=685e0c9a&hm=0db00ee11b59cef59b6b4860427a3c8c8bdbd67a954d804ac7b7e3ee56b3108c& 12:42 < bridge> lol why does the teeworlds client not handle this properly 12:42 < bridge> snaps flag at stand, but flag stand doesn't exist, 12:43 < bridge> @chillerdragon thank you very much, I was able to fix it now :deen_star: 12:43 < bridge> 12:43 < bridge> Here also have a virtual cookie 🍪 12:43 < bridge> @chillerdragon thank you very much, ~~I was able to fix it now :deen_star: 12:43 < bridge> 12:43 < bridge> Here also have a virtual cookie 🍪~~ 12:43 < bridge> ctf 1 still doesn't work :/ 12:47 < bridge> Is this netobj wrong for sixup? 12:47 < bridge> ``` 12:47 < bridge> CNetObj_Flag *pFlag = (CNetObj_Flag *)Server()->SnapNewItem(NETOBJTYPE_FLAG, TEAM_RED, sizeof(CNetObj_Flag)); 12:47 < bridge> if(!pFlag) 12:47 < bridge> return FLAG_MISSING; 12:47 < bridge> pFlag->m_X = (int)SnapFlagPos.x; 12:47 < bridge> pFlag->m_Y = (int)SnapFlagPos.y; 12:47 < bridge> pFlag->m_Team = TEAM_RED; 12:47 < bridge> ``` 13:01 < bridge> now I see, i don't know what tim did there, but it was a hacky workaround 13:01 < bridge> here take your virtual cookie chiller, this time a big one: 13:01 < bridge> 🍪 13:02 < bridge> I ended up copying the snap of your ddnet-insta code which uses the protocol7 netobjects 13:12 < bridge> Did I already recommend to base fastcap on ddnet-insta? @essigautomat 13:14 < bridge> @ryozuki: you forgot to merge epic test pr 13:14 < bridge> While at it also merge more 13:29 < bridge> yes, I am only afraid of the gamebreaking stuff I also added to the mod 🙈 13:29 < bridge> like introducing millisecond times counting fractions of ticks 13:30 < bridge> and I am afraid to have a layer in between, because then it's you who have to keep ddnet-insta up-to-date. Not that I don't trust you, but what if you get hit by a bus tomorrow? 14:35 < bridge> another day of bs ddnet physics behaviour.... 14:35 < bridge> If you fire a weapon and then switch to a different weapon and back to the original weapon within the reload time of the fired weapon then after the reload time is over the weapon you tried to switch to will be switched in for 1 tick 14:35 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1388135583636787362/2025-06-27_14-33-34.mp4?ex=685fe181&is=685e9001&hm=a4ccf19a45976fa6bf37779a4d860f9ab1bf530e73a2f7ecbb774e1be3964e08& 14:37 < bridge> the thing is it is possible to fire within that exact tick so instead of firing the original weapon it will fire the weapon you accidentally selected while the reload time wasn't over yet 14:38 < ws-client> @Assa if i get hit by a bus you switch your upstream 14:38 < ws-client> git is flexible like that 14:39 < ws-client> yo @teero777 do you know why the aim target in demos seems wrong? Like lagging one tick behind 14:39 < bridge> interpolation between the previous and current tick probably 14:40 < bridge> you'd have to ask freddie tho. i think he made that feature right? 14:40 < ws-client> a right its the thing that was complained about 14:40 < ws-client> ye fred should know i just forgot his discord name and you are online and pro 14:40 < bridge> this is fixable tho. the gun seems to work just fine 14:40 < ws-client> rly? 14:40 < bridge> @tsfreddie 14:40 < ws-client> thanks 14:41 < ws-client> if i watch demos in slow mo the flying hook or projectiles do not seem to match the cursor position 14:41 < ws-client> feels like the cursor is delayed 14:42 < bridge> what did I do this time? 14:42 < ws-client> notin 14:42 < ws-client> u just know 14:42 < ws-client> if i watch my self shoot a laser for example in the demo the laser does not hit the cursor 14:42 < bridge> Oh cursor 14:43 < bridge> It uses three frames 14:43 < bridge> Instead of two 14:44 < bridge> client doesn't send target every tick unless it fire or hooks. So there is no way to know if the current target is leftover or current 14:44 < bridge> ```cpp 14:44 < bridge> void CCharacter::HandleJetpack() 14:44 < bridge> { 14:44 < bridge> vec2 Direction = normalize(vec2(m_LatestInput.m_TargetX, m_LatestInput.m_TargetY)); 14:44 < bridge> 14:44 < bridge> bool FullAuto = false; 14:44 < bridge> if(m_Core.m_ActiveWeapon == WEAPON_GRENADE || m_Core.m_ActiveWeapon == WEAPON_SHOTGUN || m_Core.m_ActiveWeapon == WEAPON_LASER) 14:44 < bridge> FullAuto = true; 14:44 < bridge> if(m_Core.m_Jetpack && m_Core.m_ActiveWeapon == WEAPON_GUN) 14:44 < bridge> FullAuto = true; 14:44 < bridge> 14:44 < bridge> // check if we gonna fire 14:44 < bridge> bool WillFire = false; 14:45 < bridge> if(CountInput(m_LatestPrevInput.m_Fire, m_LatestInput.m_Fire).m_Presses) 14:45 < bridge> WillFire = true; 14:45 < bridge> 14:45 < bridge> if(FullAuto && (m_LatestInput.m_Fire & 1) && m_Core.m_aWeapons[m_Core.m_ActiveWeapon].m_Ammo) 14:45 < bridge> WillFire = true; 14:45 < bridge> 14:45 < bridge> if(!WillFire) 14:45 < bridge>