08:49 <+bridge> [ddnet] @Jupstar ✪ i am getting this "not dividable by 4" warning on 6 skins, how can i remove the warning without removing the skins? 08:52 <+bridge> [ddnet] fix the skins 08:58 <+bridge> [ddnet] and maybe also tell whoever uploaded these skins to fix them too, so they wont be used 09:05 <+bridge> [ddnet] i got neovim to show me this directly in the editor :monkalaugh: 09:05 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/811146281408790538/unknown.png 09:05 <+bridge> [ddnet] vim master race 09:05 <+bridge> [ddnet] @Jupstar ✪ if i knew who did it xD 09:05 <+bridge> [ddnet] random skins 09:06 <+bridge> [ddnet] i collected them 09:06 <+bridge> [ddnet] @fokkonaut use convert maybe 09:06 <+bridge> [ddnet] :monkalaugh: 09:06 <+bridge> [ddnet] xd ye 09:06 <+bridge> [ddnet] Does anyone have an idea for rewriting the draggers in a less ressource eating way? 09:07 <+bridge> [ddnet] hm we have to be careful with changing these things 09:08 <+bridge> [ddnet] physics stuff 09:08 <+bridge> [ddnet] it wont be hard redo the behaviour 09:08 <+bridge> [ddnet] i think 09:08 <+bridge> [ddnet] > placing one single dragger tile from editor, will create MAX_CLIENTS new draggers 09:08 <+bridge> [ddnet] lol 09:08 <+bridge> [ddnet] xd 09:08 <+bridge> [ddnet] yea, for every team one 09:08 <+bridge> [ddnet] and in one CDragger there is an array for all solo players in one team 09:08 <+bridge> [ddnet] xD 09:08 <+bridge> [ddnet] its hilarious i think 09:09 <+bridge> [ddnet] i guess there is ways to improve this 09:09 <+bridge> [ddnet] but i never touched that code 09:09 <+bridge> [ddnet] definetely, i checked with vs, even if i add a return to the snap function of CDragger, it still eats up 5% of the CPU 09:09 <+bridge> [ddnet] with > 100 tees 09:10 <+bridge> [ddnet] i dont have insanely many draggers 09:10 <+bridge> [ddnet] because in my case it creates 128 draggers per dragger 09:10 <+bridge> [ddnet] xd 09:12 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/811148058644840448/unknown.png 09:12 <+bridge> [ddnet] :monkaS: 09:13 <+bridge> [ddnet] i dont even know what to say 09:14 <+bridge> [ddnet] i tried kind of a rework yesterday but i really gave up, ok it was evening and i already was up the whole day 09:14 <+bridge> [ddnet] but still, it gave me a lot of cancer 09:14 <+bridge> [ddnet] its a relatively small class tho 09:14 <+bridge> [ddnet] u can see this is old code 09:14 <+bridge> [ddnet] it doesnt even comform to naming standards 09:14 <+bridge> [ddnet] xd 09:14 <+bridge> [ddnet] yes 09:15 <+bridge> [ddnet] check CGameController::OnEntity 09:15 <+bridge> [ddnet] it creates a new CDraggerTeam 09:15 <+bridge> [ddnet] which will create max_clients new CDraggers, for each team one xD 09:16 <+bridge> [ddnet] u mean IGameController 09:16 <+bridge> [ddnet] yes, of course 09:16 <+bridge> [ddnet] sorry 09:17 <+bridge> [ddnet] for each door it also creates 8 CDoor s 09:17 <+bridge> [ddnet] xd 09:17 <+bridge> [ddnet] no 09:17 <+bridge> [ddnet] 2 CDoors 09:17 <+bridge> [ddnet] for a double door 09:17 <+bridge> [ddnet] ah ye 09:18 <+bridge> [ddnet] i know what you thought tho 09:19 <+bridge> [ddnet] CDraggerTeam has 64 CDraggers 09:19 <+bridge> [ddnet] i see 09:19 <+bridge> [ddnet] @heinrich5991 i am unable to fix this, even if i ignore the error 09:19 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/811149841580163142/unknown.png 09:20 <+bridge> [ddnet] at least their functions are returned if the team is not active, but the calls are expensive still 09:21 <+bridge> [ddnet] well 09:21 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/811150137728565288/unknown.png 09:21 <+bridge> [ddnet] u can see 09:21 <+bridge> [ddnet] the dragger has a target 09:21 <+bridge> [ddnet] if there are multiple teams 09:21 <+bridge> [ddnet] the target has a very weird handling 09:21 <+bridge> [ddnet] it has to handle more than 1 target 09:21 <+bridge> [ddnet] yes, thats the soloents 09:21 <+bridge> [ddnet] in general, in Team X there can only be one target 09:21 <+bridge> [ddnet] thats m_Target 09:22 <+bridge> [ddnet] i guess soloents is when in the same team a tee is in solo 09:22 <+bridge> [ddnet] but to have it working for everyone separated, there is m_asoloents 09:22 <+bridge> [ddnet] yes 09:22 <+bridge> [ddnet] used to handle more than 1 09:22 <+bridge> [ddnet] but see how weird m_Target is handled xD 09:22 <+bridge> [ddnet] ye i agree this is not good 09:22 <+bridge> [ddnet] if there is no target, it chooses one of the soloents as target 09:22 <+bridge> [ddnet] xD 09:22 <+bridge> [ddnet] to have the checks still be valid 09:22 <+bridge> [ddnet] hmm 09:23 <+bridge> [ddnet] i think it takes the closest entity as target then 09:23 <+bridge> [ddnet] it looks like the old CDragger just got extended by m_soloents 09:23 <+bridge> [ddnet] and by CDraggerTeam 09:27 <+bridge> [ddnet] it looks like the entities in ddrace are just hacked together xD 09:28 <+bridge> [ddnet] xd 09:28 <+bridge> [ddnet] do you think you can get something for the draggers? they are really the worsr 09:28 <+bridge> [ddnet] do you think you can get something for the draggers? they are really the worst 09:29 <+bridge> [ddnet] buy better VPS xd 09:29 <+bridge> [ddnet] u 09:29 <+bridge> [ddnet] any raspberry 4 is better xd 09:30 <+bridge> [ddnet] well you can also crash ddnet servers if you place a few more draggers 09:30 <+bridge> [ddnet] i think 09:31 <+bridge> [ddnet] maybe not crash 09:53 <+bridge> [ddnet] is a std::vector inefficient? 10:02 <+bridge> [ddnet] for what 10:02 <+bridge> [ddnet] accessing and iterating should be fast 10:16 <+bridge> [ddnet] std::vector should be nearly equal to an array 11:51 <+bridge> [ddnet] An std::vector has the same performance as an array if you don't use the bound checking accessors 11:54 <+bridge> [ddnet] Oh and you also pre reserve the space. Growing is obv overhead 16:15 <+bridge> [ddnet] @timakro I think the sentence in the book is correct. is it still a question? 16:16 <+bridge> [ddnet] (btw) lifetimes exist separately from variables and scopes, when you mention a lifetime it doesn't have to refer to a lifetime of a specific variable or scope 16:50 <+bridge> [ddnet] @heinrich5991 Yes, I still don't get it. So my understanding of what they're saying is: It compiles iff there is any lifetime 'a that satisfies those criteria: 16:50 <+bridge> [ddnet] > The function signature now tells Rust that for some lifetime 'a, the function takes two parameters, both of which are string slices that live at least as long as lifetime 'a. The function signature also tells Rust that the string slice returned from the function will live at least as long as lifetime 'a. 16:50 <+bridge> [ddnet] So it's like you say in this case 'a doesn't refer to the lifetime of any specific variable or scope. It's just that if the compiler can fill any lifetime for 'a which satisfies the criteria, then it compiles. 16:50 <+bridge> [ddnet] 16:50 <+bridge> [ddnet] Further context: 16:50 <+bridge> [ddnet] > Remember, when we specify the lifetime parameters in this function signature, we’re not changing the lifetimes of any values passed in or returned. Rather, we’re specifying that the borrow checker should reject any values that don’t adhere to these constraints. Note that the longest function doesn’t need to know exactly how long x and y will live, only that some scope can be substituted for 'a that will satisfy this signature. 16:51 <+bridge> [ddnet] Am I making sense up till this point? 16:54 <+bridge> [ddnet] yes 16:54 <+bridge> [ddnet] that sounds correct @timakro 17:11 <+bridge> [ddnet] So my problem is with those criteria that 'a has to satisfy from the sentence I question. If those were the only criteria it's trivial to find a valid lifetime to substitute for 'a, you could do it even in cases where it's obvious that it doesn't compile. Because the criteria are 1. the parameter string slices live at least as long as 'a 2. the returned string slice lives at least as long as 'a. So 'a could be tiny, like imagine a' starting 17:11 <+bridge> [ddnet] 17:11 <+bridge> [ddnet] ``` 17:11 <+bridge> [ddnet] fn main() { 17:11 <+bridge> [ddnet] let in1 = String::from("foo"); // lifetime of in1 starts here 17:11 <+bridge> [ddnet] let in2 = String::from("bar"); // lifetime of in2 starts here 17:11 <+bridge> [ddnet] let out = longest(&in1, &in2); // 'a starts and ends here (just this line), lifetime of out starts here 17:11 <+bridge> [ddnet] drop(in1); // lifetime of in1 ends here 17:11 <+bridge> [ddnet] drop(in2); // lifetime of in2 ends here 17:11 <+bridge> [ddnet] println!("{}", out); 17:11 <+bridge> [ddnet] } // lifetime of out ends here 17:11 <+bridge> [ddnet] ``` 17:11 <+bridge> [ddnet] So my problem is with those criteria which 'a has to satisfy from the sentence I question. If those were the only criteria it's trivial to find a valid lifetime to substitute for 'a, you could do it even in cases where it's obvious that it doesn't compile. Because the criteria are 1. the parameter string slices live at least as long as 'a 2. the returned string slice lives at least as long as 'a. So 'a could be tiny, like imagine a' startin 17:11 <+bridge> [ddnet] 17:11 <+bridge> [ddnet] ``` 17:11 <+bridge> [ddnet] fn main() { 17:11 <+bridge> [ddnet] let in1 = String::from("foo"); // lifetime of in1 starts here 17:11 <+bridge> [ddnet] let in2 = String::from("bar"); // lifetime of in2 starts here 17:11 <+bridge> [ddnet] let out = longest(&in1, &in2); // 'a starts and ends here (just this line), lifetime of out starts here 17:12 <+bridge> [ddnet] drop(in1); // lifetime of in1 ends here 17:12 <+bridge> [ddnet] drop(in2); // lifetime of in2 ends here 17:12 <+bridge> [ddnet] println!("{}", out); 17:12 <+bridge> [ddnet] } // lifetime of out ends here 17:12 <+bridge> [ddnet] ``` 17:12 <+bridge> [ddnet] So my problem is with those criteria which 'a has to satisfy from the sentence in question. If those were the only criteria it's trivial to find a valid lifetime to substitute for 'a, you could do it even in cases where it's obvious that it doesn't compile. Because the criteria are 1. the parameter string slices live at least as long as 'a 2. the returned string slice lives at least as long as 'a. So 'a could be tiny, like imagine a' starti 17:12 <+bridge> [ddnet] 17:12 <+bridge> [ddnet] ``` 17:12 <+bridge> [ddnet] fn main() { 17:12 <+bridge> [ddnet] let in1 = String::from("foo"); // lifetime of in1 starts here 17:12 <+bridge> [ddnet] let in2 = String::from("bar"); // lifetime of in2 starts here 17:12 <+bridge> [ddnet] let out = longest(&in1, &in2); // 'a starts and ends here (just this line), lifetime of out starts here 17:12 <+bridge> [ddnet] drop(in1); // lifetime of in1 ends here 17:12 <+bridge> [ddnet] drop(in2); // lifetime of in2 ends here 17:12 <+bridge> [ddnet] println!("{}", out); 17:12 <+bridge> [ddnet] } // lifetime of out ends here 17:12 <+bridge> [ddnet] ``` 17:14 <+bridge> [ddnet] @heinrich5991 17:15 <+bridge> [ddnet] So my problem is with those criteria which 'a has to satisfy from the sentence in question. If those were the only criteria it's trivial to find a valid lifetime to substitute for 'a, you could do it even in cases where it's obvious that it doesn't compile. Because the criteria are 1. the parameter string slices live at least as long as 'a 2. the returned string slice lives at least as long as 'a. So 'a could be tiny, like imagine 'a starti 17:15 <+bridge> [ddnet] 17:15 <+bridge> [ddnet] ``` 17:15 <+bridge> [ddnet] fn main() { 17:15 <+bridge> [ddnet] let in1 = String::from("foo"); // lifetime of in1 starts here 17:15 <+bridge> [ddnet] let in2 = String::from("bar"); // lifetime of in2 starts here 17:15 <+bridge> [ddnet] let out = longest(&in1, &in2); // 'a starts and ends here (just this line), lifetime of out starts here 17:15 <+bridge> [ddnet] drop(in1); // lifetime of in1 ends here 17:15 <+bridge> [ddnet] drop(in2); // lifetime of in2 ends here 17:15 <+bridge> [ddnet] println!("{}", out); 17:15 <+bridge> [ddnet] } // lifetime of out ends here 17:15 <+bridge> [ddnet] ``` 17:15 <+bridge> [ddnet] ah, I see 17:15 <+bridge> [ddnet] let me think 17:18 <+bridge> [ddnet] I think the interesting point is that caller and callee have different constraints on the return value 17:18 <+bridge> [ddnet] the callee (the function) has to guarantee that the return value will live at least as long as 'a 17:19 <+bridge> [ddnet] Omg why is everything saying this, I'm so confused xD 17:19 <+bridge> [ddnet] but the caller (your main) may only, as a result of that, assume that the return value will live for 'a (at most) 17:19 <+bridge> [ddnet] everyone 17:19 <+bridge> [ddnet] sorry, what's the word I shouldn't say? ^^ 17:19 <+bridge> [ddnet] urn value will live at least as long 17:19 <+bridge> [ddnet] at least as long as anything 17:19 <+bridge> [ddnet] No! 17:19 <+bridge> [ddnet] Nobody cares if the return value dies 17:20 <+bridge> [ddnet] It can die instantly after the function returns 17:20 <+bridge> [ddnet] you do, you want to use the return value in the println later on 17:20 <+bridge> [ddnet] Nobody cares 17:20 <+bridge> [ddnet] Ah ok 17:20 <+bridge> [ddnet] if you wouldn't use the value, it would be okay to use that very short lifetime you specified 17:21 <+bridge> [ddnet] (and the compiler actually does that to fix some otherwise annoying problems, "non-lexical lifetimes") 17:24 <+bridge> [ddnet] On another note what I also think is not clear from the explanation in the book or what confuses me: It seems to me it is very important to distinguish when we talk about "the lifetime of the parameter" we really mean the lifetime of the thing the reference is referring to, not the lifetime of the reference. But when we talk about "the lifetime of the return value" we mean the lifetime of the returned reference, not the lifetime of the thin 17:25 <+bridge> [ddnet] The book just says "the lifetime of the parameter" and "the lifetime of the return value". I assume it means by that what I just said 17:26 <+bridge> [ddnet] I think the lifetime (on a reference) always talks about the pointed-to value 17:27 <+bridge> [ddnet] But as parameter and returned value point to the same thing it wouldn't make sense to compare them, would it? 17:27 <+bridge> [ddnet] (They'd have the same lifetime) 17:28 <+bridge> [ddnet] yes, in this case they have to adhere to the same restriction, live longer than 'a 17:28 <+bridge> [ddnet] but the following function also satisfies this 17:33 <+bridge> [ddnet] ```rust 17:33 <+bridge> [ddnet] fn max<'a>(x: &'a str, y: &'a str) -> &'a str { 17:33 <+bridge> [ddnet] if x > y { 17:33 <+bridge> [ddnet] x 17:33 <+bridge> [ddnet] } else { 17:33 <+bridge> [ddnet] "abc" 17:33 <+bridge> [ddnet] } 17:33 <+bridge> [ddnet] } 17:33 <+bridge> [ddnet] ``` 17:33 <+bridge> [ddnet] sorry, got distracted 17:34 <+bridge> [ddnet] here, you can see that it makes sense that the return value only has to live "at least as long" as the parameter 'a 17:34 <+bridge> [ddnet] the else branch has a string that lives for 'static, the longest possible lifetime 17:36 <+bridge> [ddnet] Okay, I see what you mean and how this works when you assume 17:36 <+bridge> [ddnet] > I think the lifetime (on a reference) always talks about the pointed-to value 17:37 <+bridge> [ddnet] But I'm not sure if that's really what lifetime means because of this from later in the same chapter of book: 17:37 <+bridge> [ddnet] ``` 17:37 <+bridge> [ddnet] { 17:37 <+bridge> [ddnet] let x = 5; // ----------+-- 'b 17:38 <+bridge> [ddnet] // | 17:38 <+bridge> [ddnet] let r = &x; // --+-- 'a | 17:38 <+bridge> [ddnet] // | | 17:38 <+bridge> [ddnet] println!("r: {}", r); // | | 17:38 <+bridge> [ddnet] // --+ | 17:38 <+bridge> [ddnet] } 17:38 <+bridge> [ddnet] ``` 17:38 <+bridge> [ddnet] But I'm not sure if that's really what lifetime means because of this from later in the same chapter of book: 17:38 <+bridge> [ddnet] ``` 17:38 <+bridge> [ddnet] 17:38 <+bridge> [ddnet] 17:38 <+bridge> [ddnet] { 17:38 <+bridge> [ddnet] let x = 5; // ----------+-- 'b 17:38 <+bridge> [ddnet] // | 17:38 <+bridge> [ddnet] let r = &x; // --+-- 'a | 17:38 <+bridge> [ddnet] // | | 17:38 <+bridge> [ddnet] println!("r: {}", r); // | | 17:38 <+bridge> [ddnet] // --+ | 17:38 <+bridge> [ddnet] } // ----------+ 17:38 <+bridge> [ddnet] 17:38 <+bridge> [ddnet] ``` 17:38 <+bridge> [ddnet] hm to be fair it's quite simialr 17:39 <+bridge> [ddnet] hm to be fair it's quite similar 17:39 <+bridge> [ddnet] both lifetimes 17:39 <+bridge> [ddnet] they could mean the same 17:39 <+bridge> [ddnet] We all agree on how it works, I think it's actually very intuitive. The "explanation" paragraph from the book should just be removed in my opinion ^^ 17:40 <+bridge> [ddnet] ah ^^ 20:10 <+bridge> [ddnet] @Learath2 found ur alt :monkalaugh: 20:10 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/811313579814420490/p473hba16uh61.png 20:13 <+bridge> [ddnet] hahahahaha 20:13 <+bridge> [ddnet] 🥴 20:16 <+bridge> [ddnet] how did you??? 20:16 <+bridge> [ddnet] remove this 20:26 <+ChillerDragon> classic love those prs 20:26 <+ChillerDragon> UwU 20:26 <+ChillerDragon> *starts twerking* killed me _D 20:39 <+bridge> [ddnet] nice meme steal ryozuki 21:23 <+bridge> [ddnet] i just stole from someone who probs stole it too 21:23 <+bridge> [ddnet] thats t he internet for u 21:23 <+bridge> [ddnet] :monkalaugh: 22:56 <+bridge> [ddnet] @Learath2 i tried something with the draggers, to handle the teams inside of one dragger, not one dragger per team. if one player is in a team and another one isnt the pull strength seems to be different somehow, any ideas? https://github.com/fokkonaut/F-DDrace/commit/1c19aad782946c06b5610e2904ec4ac025525864?w=1 23:03 <+bridge> [ddnet] ah okay no, it was like that before too 23:04 <+bridge> [ddnet] nice, then i did not break anything