00:13 <+bridge> [ddnet] URRRRR 00:13 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/990741677599772692/unknown.png 00:28 <+bridge> [ddnet] those are some pretty graphs 00:28 <+bridge> [ddnet] atleast its not a flat line! ;p 00:31 <+bridge> [ddnet] rofl we have an spy as contributor ^^spy090@yandex.ru 00:32 <+bridge> [ddnet] @ДяДя_ДеН 00:32 <+bridge> [ddnet] how can we add tooltips to `DoButton_CheckBoxAutoVMarginAndSet` 00:33 <+bridge> [ddnet] oh my god this was the wrong channel 01:33 <+bridge> [ddnet] you can count the snowflakes 01:33 <+bridge> [ddnet] if you count 15 snowflakes you are unfreezed 01:34 <+bridge> [ddnet] 😉 jk 08:19 <+bridge> [ddnet] https://lunduke.substack.com/p/linus-torvalds-threatens-to-punish 08:19 <+bridge> [ddnet] @Ryozuki :franzj_kek: 08:20 <+bridge> [ddnet] gigachad 08:20 <+bridge> [ddnet] but probs fake 11:06 <+bridge> [ddnet] @Ryozuki I am tempted to switch to rust for what I do... there's some cool crates https://crates.io/crates/libbpf-sys 11:07 <+bridge> [ddnet] & since I have to do C wrapping in python & ik in python it's pain in ass, I'm thinking about learning rust 11:07 <+bridge> [ddnet] rust always there..; 11:07 <+bridge> [ddnet] rust always there.. 11:08 <+bridge> [ddnet] cool snowflake thingies u got going on 11:08 <+bridge> [ddnet] wot 11:09 <+bridge> [ddnet] Do it 11:10 <+bridge> [ddnet] Did u expect another answer from me? :TOOBASED: 11:10 <+bridge> [ddnet] no, just that when I have to mess with smth I always see that rust is a solution 11:19 <+bridge> [ddnet] they like 11:19 <+bridge> [ddnet] made the freeze put snowflakes 11:19 <+bridge> [ddnet] instead of onion rings 11:20 <+bridge> [ddnet] hoo 11:20 <+bridge> [ddnet] that's good idea 11:21 <+bridge> [ddnet] @ReiTW 11:21 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/990909805621280788/unknown.png 11:22 <+bridge> [ddnet] @cyberfighter yeah find it cool 11:22 <+bridge> [ddnet] only that bar hope u can disable it 11:22 <+bridge> [ddnet] i like it too 11:22 <+bridge> [ddnet] i think its straight up impossible 11:22 <+bridge> [ddnet] ah ig it replaces the star 11:22 <+bridge> [ddnet] ah ig it replaces the stars 11:23 <+bridge> [ddnet] i think u can hide for urself with opacity settings but its not working yet 11:24 <+bridge> [ddnet] ah nvm its only when ur in freeze 12:00 <+bridge> [ddnet] xD I see a request comming for opacity outside of freeze 12:38 <+bridge> [ddnet] 21:9 12:39 <+bridge> [ddnet] @Not Keks is there 21:9 in ddnet? 12:44 <+bridge> [ddnet] why not just edit the hud itself then 12:44 <+bridge> [ddnet] like, the hud image 16:09 <+bridge> [ddnet] i want to ask here before i create an issue. there is a bind for joining team with dummy and lock it. how about a shortcut for joining an empty server with low ping, vote for a pre specified dummy map, joining dummy, joining team and lock. cause those steps i do manually every time. 16:09 <+bridge> [ddnet] or as a quick win: is is possible to put a condition on the "run on join command" to execute the dummy setup bind only when joining dummy servers 16:11 <+bridge> [ddnet] another idea: have an option that you can checkmark (but default is opt out) "automatically connect dummy and join empty team on dummy servers" 16:14 <+bridge> [ddnet] what do you think? 16:14 <+bridge> [ddnet] im already using the bind and maybe its enough, i mean after all you just press one button and are with dummy in locked team 16:20 <+bridge> [ddnet] is there a workaround for running the "dummy setup" bind only when joining dummy servers? or is there an f1 command for connect dummy as well, so my manual steps would be one less? (one bind for connecting dummy and joining empty team together and lock it) 16:20 <+bridge> [ddnet] is there a workaround for running the "dummy setup" bind only when joining dummy servers? and is there an f1 command for connect dummy as well, so my manual steps would be one less? (one bind for connecting dummy and joining empty team together and lock it) 16:57 <+bridge> [ddnet] @heinrich5991 do we need 5520 if we are already getting 5521? 16:58 <+bridge> [ddnet] I can just not serve incompatible pngs on skins1 17:25 <+bridge> [ddnet] I guess using a normal bind is enough. It is not like you would waste a lot of time not having such a bind or not having a game feature for exactly that case 17:25 <+bridge> [ddnet] @Learath2 I answered in the PR 17:26 <+bridge> [ddnet] @heinrich5991 should I ask for more reviewers for ? 17:27 <+bridge> [ddnet] yea sorry, I will review 17:27 <+bridge> [ddnet] @c0d3d3v so did we end up sending the input back to the client btw? Is targetx and targety still being sent? 17:27 <+bridge> [ddnet] targetx and targety is still there 17:28 <+bridge> [ddnet] no other inputs 17:28 <+bridge> [ddnet] I briefly saw that the PR increases the number of game #includes, we'll probably have to come up with a solution that doesn't do it 17:28 <+bridge> [ddnet] game #includes in engine 17:28 <+bridge> [ddnet] Can you give me a run-down on why this has to be sent back? It’s a fairly large amount of extra data 17:31 <+bridge> [ddnet] The only real good reason is that it improves the target angle other player can see. So you know that the hookline is not correct of other players... Now it is correct, because the calculation uses the same coordinates the server also uses. It could be used in demos to show the cursor possition the player had used... 17:31 <+bridge> [ddnet] 17:31 <+bridge> [ddnet] If there are votes against it we could remove it. These values will change a lot, so the diff will always contain not only 0 17:32 <+bridge> [ddnet] What extra information does the server use that we don’t have on the client? 17:32 <+bridge> [ddnet] clients get the angle, server gets targetx targetx 17:32 <+bridge> [ddnet] clients get the angle, server gets targetx targety 17:33 <+bridge> [ddnet] now also clients get targetx targety 17:33 <+bridge> [ddnet] the angle is rounded 17:33 <+bridge> [ddnet] and so wrong 17:34 <+bridge> [ddnet] but only marginal 17:34 <+bridge> [ddnet] because we don't use the rounded angle serverside, but the x, y coordinates 17:34 <+bridge> [ddnet] ? 17:34 <+bridge> [ddnet] yes 17:34 <+bridge> [ddnet] angle is only send to clients 17:34 <+bridge> [ddnet] not used on the server 17:34 <+bridge> [ddnet] yea, sounds like a bug 17:34 <+bridge> [ddnet] How about increasing the precision for the angle? Would we require 8 entire extra bytes for that? 17:35 <+bridge> [ddnet] we could also stop sending the angle and only send the x, y coordinates ^^ 17:35 <+bridge> [ddnet] I will look into it.... 17:35 <+bridge> [ddnet] no, don't 17:35 <+bridge> [ddnet] This is probably even better 17:35 <+bridge> [ddnet] this is just thought experiments so far 17:35 <+bridge> [ddnet] Yeah don’t bother, just thinking out loud here 17:36 <+bridge> [ddnet] I guess the ground truth is indeed the target x and y 17:38 <+bridge> [ddnet] Though dropping angle is probably not very easy, we could always send 0 to new ddnet clients and let delta compression get rid of the extra data 17:40 <+bridge> [ddnet] the basic calculation is 17:40 <+bridge> [ddnet] ``` 17:40 <+bridge> [ddnet] 17:40 <+bridge> [ddnet] float TmpAngle = atan2f(m_Input.m_TargetY, m_Input.m_TargetX); 17:40 <+bridge> [ddnet] if(TmpAngle < -(pi / 2.0f)) 17:40 <+bridge> [ddnet] { 17:40 <+bridge> [ddnet] m_Angle = (int)((TmpAngle + (2.0f * pi)) * 256.0f); 17:40 <+bridge> [ddnet] } 17:40 <+bridge> [ddnet] else 17:40 <+bridge> [ddnet] { 17:40 <+bridge> [ddnet] m_Angle = (int)(TmpAngle * 256.0f); 17:40 <+bridge> [ddnet] } 17:40 <+bridge> [ddnet] ``` 17:40 <+bridge> [ddnet] 17:40 <+bridge> [ddnet] this creates values from ~ -402 < 0 < 1204 17:40 <+bridge> [ddnet] 17:40 <+bridge> [ddnet] so it does not even use the complete 32 bit. If we would shift the calculations from 0 to 360° then we could use a lot more precission 17:40 <+bridge> [ddnet] The only reason I was concerned is that I think it’s like an extra kilobyte of data per snap for a 64p server 17:41 <+bridge> [ddnet] Huh, I wonder why the weird range 17:41 <+bridge> [ddnet] vanilla teeworlds 0.6 17:42 <+bridge> [ddnet] 0.7 uses -180° to 180° 17:42 <+bridge> [ddnet] I made a beautiful graphics here https://github.com/ddnet/ddnet/pull/4972 17:43 <+bridge> [ddnet] they did not really thought about such stuff long, I guess 17:43 <+bridge> [ddnet] Back in the days 17:43 <+bridge> [ddnet] Angle probably compresses better then targetx targety 17:46 <+bridge> [ddnet] But interesting that matricks didn’t just use all the precision available to him in those 4 bytes. I wonder if it was an attempt to get it to compress better 17:47 <+bridge> [ddnet] who knows what he thought 15 years ago 17:48 <+bridge> [ddnet] This rounded Angle does also not change so often as targetx targety. You can also see that in the snap updates 17:52 <+bridge> [ddnet] @Learath2 I guess that is max 64 (players) * 2 (x, y) * 4 Bytes = 512Bytes per snap. With probably a lot of leading 0 Bytes because target X, Y also does not get to big. We probably could also only use 2 bytes for each. or are there monitors with more then 65536*2 pixel in each direction 17:53 <+bridge> [ddnet] @Learath2 I guess that is max 64 (players) * 2 (x, y) * 4 Bytes = 512Bytes per snap. With probably a lot of leading 0 Bytes because target X, Y also does not get to big. We probably could also only use 2 bytes for each. or are there monitors with more then 32768*2 = 65536pixel in each direction 17:53 <+bridge> [ddnet] @Learath2 I guess that is max 64 (players) * 2 (x, y) * 4 Bytes = 512Bytes per snap. With probably a lot of leading 0 Bytes because target X, Y also does not get to big. We probably could also only use 2 bytes for each. or are there monitors with more then 32768*2 = 65536 pixel in each direction 17:55 <+bridge> [ddnet] If we would only use 2 bytes... we could also use the old angle field for new clients xD 17:55 <+bridge> [ddnet] for target x, y 17:57 <+bridge> [ddnet] then we'd need to decrease the accuracy of input fields on the server to 16 bit 17:57 <+bridge> [ddnet] I guess this doesn't change anythign in the normal configuration 17:58 <+bridge> [ddnet] Ah thinking about that, I have to test what happens if you zoom out a lot. maybe target x y is not per pixel but per unit. I will test that. 17:58 <+bridge> [ddnet] it's not per pixel AFAIK 17:59 <+bridge> [ddnet] then 16 bit is probably not enough (at least if you reallly zoom very far out, what does not happen often) 17:59 <+bridge> [ddnet] I will test it 18:00 <+bridge> [ddnet] ah 18:00 <+bridge> [ddnet] no, I mean it doesn't change if you zoom out 18:00 <+bridge> [ddnet] I guess that makes it per pixel 18:04 <+bridge> [ddnet] long long double for most atoms in the universe and u are fine 18:05 <+bridge> [ddnet] just as an aside. I don't know if you're really interested in the bandwidth @Learath2 (I personally do not think these data will get us in trouble, But I'm a optimist too) . But we've been sending targetx and targety on the servers for weeks to the clients. So since the merge of the hud... Maybe you could look in the stats if that has made any difference, if we have any useful stats in this regard ^^. 18:05 <+bridge> [ddnet] just as an aside. I don't know if you're really interested in the bandwidth @Learath2 (I personally do not think these data will get us in trouble, But I'm a Optimizer too) . But we've been sending targetx and targety on the servers for weeks to the clients. So since the merge of the hud... Maybe you could look in the stats if that has made any difference, if we have any useful stats in this regard ^^. 18:05 <+bridge> [ddnet] if bandwidth would be a problem, we wouldn't send UUIDs xd 18:06 <+bridge> [ddnet] they are a one time cost basicly 18:06 <+bridge> [ddnet] except the id and type that needs to be send always 18:06 <+bridge> [ddnet] but uuid is 1 byte 18:07 <+bridge> [ddnet] oh i thought they are literally strings 18:07 <+bridge> [ddnet] oh i thought they are literaly strings 18:07 <+bridge> [ddnet] 16 bytes yes... but compressed in delta snapshot 18:07 <+bridge> [ddnet] to 1 byte 18:07 <+bridge> [ddnet] no, 0 bytes 18:07 <+bridge> [ddnet] One time large chunks isn’t bad. But data being sent all the time could be an issue on servers where bandwidth is tight like china 18:07 <+bridge> [ddnet] changed objects aren't sent 18:07 <+bridge> [ddnet] true 18:07 <+bridge> [ddnet] na not 0 18:07 <+bridge> [ddnet] mh no 18:07 <+bridge> [ddnet] 0 is true 18:08 <+bridge> [ddnet] xD 18:08 <+bridge> [ddnet] but also only if all players are active and moving cursor or whatever u talk about rn 18:08 <+bridge> [ddnet] I was lost 18:08 <+bridge> [ddnet] Yeah, that’s why I’m unsure, I might take a look at a couple servers, see if there is any significant increase 18:09 <+bridge> [ddnet] but tbh, if thats really an issue, just create another VPS instead? 18:09 <+bridge> [ddnet] i mean u dont need to waste 18:09 <+bridge> [ddnet] but most stuff in tw breaks bcs it wasn't thought well enough in the past 18:09 <+bridge> [ddnet] or not breaks, but sucks 18:10 <+bridge> [ddnet] "just create another VPS instead" has costs 18:10 <+bridge> [ddnet] Like in china we host 32p servers at some locations, so it can get fairly tight 18:11 <+bridge> [ddnet] what causes most traffic rn? 18:11 <+bridge> [ddnet] We could also say we don't want the target.x and target.y data. I find the interpolation between the x,y values is nicer than between the angles and they are very precise. 18:11 <+bridge> [ddnet] 18:11 <+bridge> [ddnet] On the other hand, we have been able to do without this precision for the last years. 18:12 <+bridge> [ddnet] could just decrease snapshot rate to every 3/4 ticks if its such a bottleneck 18:12 <+bridge> [ddnet] I guess x y is good because it's the ground truth, as Learath2 says 18:12 <+bridge> [ddnet] that would make the game less smooth, no? 18:12 <+bridge> [ddnet] does that matter a lot in ddrace? 18:12 <+bridge> [ddnet] maybe for insane it does 18:13 <+bridge> [ddnet] guess for most stuff it wouldn't too much 18:13 <+bridge> [ddnet] Yeah I think there is no harm in x,y unless we think it might be a privacy issue. We could look into deopping angle too later. I think it’s okay as is for now 18:13 <+bridge> [ddnet] Mh, it might change how movement feels. Which is a nono for a game this precise 18:14 <+bridge> [ddnet] what do we even do to get 14kb/s, is the debug hud accurate? 18:14 <+bridge> [ddnet] for 1 player 18:14 <+bridge> [ddnet] why should movement feel different? 18:14 <+bridge> [ddnet] only if u get laggs it sucks 18:14 <+bridge> [ddnet] for single player it'd be fine 18:14 <+bridge> [ddnet] other players teleport on movement tho 18:14 <+bridge> [ddnet] but you'd get input updates for other players later 18:15 <+bridge> [ddnet] that'd look bad 18:15 <+bridge> [ddnet] yeah its like higher ping 18:15 <+bridge> [ddnet] yeah but i mean, why is it 14kb/s on my local server when i am standing around 18:15 <+bridge> [ddnet] why is it so huge 18:15 <+bridge> [ddnet] that's a lot 18:15 <+bridge> [ddnet] hmm 18:16 <+bridge> [ddnet] Say you are catching someone falling e.g., it might say look different. That’ll change visual timings for the players 18:16 <+bridge> [ddnet] I guess I should get out wireshark at some point and look at the packets ^^ 18:16 <+bridge> [ddnet] i played insane gores in chile server, i know what sucks 18:16 <+bridge> [ddnet] Probably a better idea to look at it in the debug hud, see what is getting constantly updated in the snap 18:16 <+bridge> [ddnet] Dropping the angle by setting it to just 0 is easy, and no problem for backward compatibility. changing the field to 16 byte xy target each. would require us to act soon or we would have compatibility discussion if we remove target xy from ddnet character 18:16 <+bridge> [ddnet] but on russia server i can play almost "normal" 18:16 <+bridge> [ddnet] its not that drastically 18:17 <+bridge> [ddnet] Wait, we need more than 4 bytes for targetx? 18:17 <+bridge> [ddnet] 16 bit, I think 18:17 <+bridge> [ddnet] bit sorry 18:18 <+bridge> [ddnet] Eh, 32 each is fine too, we have int compression if we only send 16bit precision and think it’s enough 18:19 <+bridge> [ddnet] I do not know how fast snaps are send, I guess per tick? so 50 ticks per second is 35byte per snap if you get 14kbbit per second 18:19 <+bridge> [ddnet] I do not know how fast snaps are send, I guess per tick? so 50 ticks per second is 35byte per snap if you get 14kbit per second 18:20 <+bridge> [ddnet] 25 per second 18:20 <+bridge> [ddnet] is it 14KB or 14Kb? 18:20 <+bridge> [ddnet] Yes I thought it is every second snap 18:20 <+bridge> [ddnet] I guess it is bits 18:20 <+bridge> [ddnet] Are our snaps not empty while we stand still? 18:20 <+bridge> [ddnet] At least the snap sizes are stored in bits 18:21 <+bridge> [ddnet] no because 1 bit is tangling 18:21 <+bridge> [ddnet] 2 18:21 <+bridge> [ddnet] x and y 18:21 <+bridge> [ddnet] I mean truly stand still, no mouse movement either 18:21 <+bridge> [ddnet] yes 18:21 <+bridge> [ddnet] velocity is broken 18:21 <+bridge> [ddnet] tangles between 0 and 1 18:22 <+bridge> [ddnet] is a problem of our quantisation 18:22 <+bridge> [ddnet] Tangle? As in just randomly changes? 18:22 <+bridge> [ddnet] no they flip every snap 18:22 <+bridge> [ddnet] What sort of unholy ub is that? 18:22 <+bridge> [ddnet] at least thats how it was as I looked into it the last time 18:23 <+bridge> [ddnet] it is a rounding problem 18:23 <+bridge> [ddnet] we do not send the float 18:23 <+bridge> [ddnet] but multiply it and convert it to int 18:23 <+bridge> [ddnet] If nothing is changing why would it round differently tho? 18:23 <+bridge> [ddnet] then convert it back ot float 18:23 <+bridge> [ddnet] and so on 18:23 <+bridge> [ddnet] No input = vel 0. 0 * anything is 0, even with inaccurate floats 18:23 <+bridge> [ddnet] I already explained it here ... 18:23 <+bridge> [ddnet] it is something like 0.494 18:24 <+bridge> [ddnet] * 250 18:24 <+bridge> [ddnet] Yeah, I’ll just take a look at it later, that’s just a bizarre behaviour 18:24 <+bridge> [ddnet] It is actually used I think by the locic for wall jumps xD 18:24 <+bridge> [ddnet] It is actually used I think by the logic for wall jumps xD 18:26 <+bridge> [ddnet] :sadOkayCat: 18:26 <+bridge> [ddnet] It is actually used I think by the logic for wall jumps xD (not sure about it) Would probably also work if we force cut it to 0 18:27 <+bridge> [ddnet] It gets not 0 because the friction can not lower it to 0 18:27 <+bridge> [ddnet] ... but you can inverstigate in it 😄 I had give up on it 18:27 <+bridge> [ddnet] ... but you can investigate in it 😄 I had give up on it 18:28 <+bridge> [ddnet] But it should attain a minimum stable value after a set amount of time or at the very least keep decreasing towards 0, I don’t see how it should ever round back up after a certain time t 18:28 <+bridge> [ddnet] but if you walk at a wall it is 0 18:28 <+bridge> [ddnet] against a wall and stand still 18:28 <+bridge> [ddnet] but the state of "in which direction did the tee move last" is saved somehow though, pretty sure. Speeders with max speed behave differently depending on the direction you moved last 18:28 <+bridge> [ddnet] Yeah walls set your velocity to 0 directly 18:29 <+bridge> [ddnet] it is basicly the velocity itself. 18:29 <+bridge> [ddnet] and we store in "left" if you just left a wall 18:30 <+bridge> [ddnet] but I thought you said that the velocity fluctuates, no? 18:30 <+bridge> [ddnet] only for the client 18:30 <+bridge> [ddnet] the server knows the true state 18:30 <+bridge> [ddnet] ah, so there should be a prediction error there as well? 18:30 <+bridge> [ddnet] Mh another thing that can never be fixed right there. If we were to round to 0 after a certain minimal threshold this behaviour would change 18:31 <+bridge> [ddnet] fix would be to remove max_speed for stoppers, never worked properly ever 18:31 <+bridge> [ddnet] :d 18:31 <+bridge> [ddnet] He says it’s in the snap, so it can’t be a predicted value, no? 18:32 <+bridge> [ddnet] I bet they all work subtly different with different previous velocities, breaking some precision part made a decade ago :p 18:32 <+bridge> [ddnet] ah, I don't know much about how prediction works internally 18:33 <+bridge> [ddnet] heh, max_speed needs to be activated though, so it shouldn't break existing maps 18:34 <+bridge> [ddnet] but they only send every second tick 18:35 <+bridge> [ddnet] yes heinrich corrected me 18:35 <+bridge> [ddnet] It is also true that uuids are not send a second time 🙂 as long as the previous snap arrived. So they are really a one time cost 18:36 <+bridge> [ddnet] I will just check if it is really 14 kbit/sec or 14 kbyte/sec 18:37 <+bridge> [ddnet] i'd still assume value close to 0 when standing still, but well 18:37 <+bridge> [ddnet] 18:37 <+bridge> [ddnet] is it 18:37 <+bridge> [ddnet] kilo bytes 18:37 <+bridge> [ddnet] kibi bytes 18:37 <+bridge> [ddnet] kilo bits 18:37 <+bridge> [ddnet] kibi bits 18:37 <+bridge> [ddnet] 18:37 <+bridge> [ddnet] dunno if our naming is consistent 😄 18:37 <+bridge> [ddnet] it says kbps 18:37 <+bridge> [ddnet] yes wait I look into the code 😄 18:41 <+bridge> [ddnet] (RecvTotal * 8) / 1024 18:41 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/991020469614436413/unknown.png 18:42 <+bridge> [ddnet] but `RecvTotal = RecvBytes + RecvPackets * 42;` do not know what the magix 42 is 18:42 <+bridge> [ddnet] Oh wow, who commited that? Using the correct format specifiers 18:42 <+bridge> [ddnet] deen changed most i think 18:42 <+bridge> [ddnet] deen 18:42 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/991020809491464192/unknown.png 18:43 <+bridge> [ddnet] correct would be streamed tho, bcs faster than printf xd 18:45 <+bridge> [ddnet] C++ `std::format` is even cuter 18:45 <+bridge> [ddnet] but also slower 18:45 <+bridge> [ddnet] bcs it has to parse text still 18:46 <+bridge> [ddnet] I wonder the difference actually 18:46 <+bridge> [ddnet] probs not lot, but maybe it is 18:46 <+bridge> [ddnet] so at least we know it it kbit per second 18:47 <+bridge> [ddnet] still do not know what it counts xD 18:48 <+bridge> [ddnet] with variadic templates you can now even use comma seperated type safe arguments 18:48 <+bridge> [ddnet] 18:48 <+bridge> [ddnet] print("print 0: ", 0, "whatever", CSomeFormatThatCanBeConstrained(0.0f)) 18:48 <+bridge> [ddnet] the best 18:48 <+bridge> [ddnet] c++20 when 18:48 <+bridge> [ddnet] Hm, this one totally trustworthy benchmark says if printing objects is involved it doesn’t matter much 18:48 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/991022183163781150/IMG_0184.png 18:48 <+bridge> [ddnet] note for cout 18:48 <+bridge> [ddnet] u have to disable sync 18:48 <+bridge> [ddnet] sadly c++ standard fucked it up 18:49 <+bridge> [ddnet] but string_streams are fast af, and boost probs has some alternative to std::cout 18:50 <+bridge> [ddnet] std::ios::sync_with_stdio(false); 18:50 <+bridge> [ddnet] this is the weird call xD 18:51 <+bridge> [ddnet] and dont use std::endl 18:51 <+bridge> [ddnet] that flushes xd 19:09 <+bridge> [ddnet] so is 1,75 kilo bytes per second now a lot or not 😄 19:09 <+bridge> [ddnet] for standing around still 😄 19:16 <+bridge> [ddnet] 1750 / 25 = 70 byte per snap 19:17 <+bridge> [ddnet] I guess it could be optimized 19:17 <+bridge> [ddnet] 70 bytes are quite something 19:17 <+bridge> [ddnet] for saying 'nothing changed' 19:17 <+bridge> [ddnet] i wonder if the packet headers count too 😄 19:20 <+bridge> [ddnet] wireshark tells me 30bytes per packet, so we send 2 packets always? 19:20 <+bridge> [ddnet] or 70bytes with full UDP header etc. 19:20 <+bridge> [ddnet] full frame 19:20 <+bridge> [ddnet] 14kbit per second = 14*1024/8/25 = 72 Bytes per snap 19:20 <+bridge> [ddnet] 19:20 <+bridge> [ddnet] 4 Byte Message ID 19:20 <+bridge> [ddnet] 19:21 <+bridge> [ddnet] ( 4 Byte Game Tick 19:21 <+bridge> [ddnet] 4 Byte Delta Tick 19:21 <+bridge> [ddnet] 4 Bytes Num Parts 19:21 <+bridge> [ddnet] 4 Bytes Part Number 19:21 <+bridge> [ddnet] 4 Byte CRC 19:21 <+bridge> [ddnet] 4 Byte Part Size ) times Num Parts (if you do nothing you would excpect 1 snap) 19:21 <+bridge> [ddnet] 19:21 <+bridge> [ddnet] = 28 bytes 19:21 <+bridge> [ddnet] 19:21 <+bridge> [ddnet] + Delta Snapshot header 19:21 <+bridge> [ddnet] 4 Bytes m_NumDeletedItems 19:21 <+bridge> [ddnet] 4 Bytes m_NumUpdateItems 19:21 <+bridge> [ddnet] 4 Bytes m_NumTempItems 19:21 <+bridge> [ddnet] = 12 Bytes 19:21 <+bridge> [ddnet] 19:21 <+bridge> [ddnet] + Snapshot header 19:21 <+bridge> [ddnet] 4 Byte Data Size 19:21 <+bridge> [ddnet] 4 Byte Num Items 19:21 <+bridge> [ddnet] = 8 byte 19:21 <+bridge> [ddnet] 19:21 <+bridge> [ddnet] 19:21 <+bridge> [ddnet] in total 48 Header bytes 19:21 <+bridge> [ddnet] 19:21 <+bridge> [ddnet] 19:21 <+bridge> [ddnet] + at least the character that has the flipping velocity 19:21 <+bridge> [ddnet] but doubt we care about that xd 19:21 <+bridge> [ddnet] arent we using some integer packing?= 19:21 <+bridge> [ddnet] if you are on a map that has no other entities 19:21 <+bridge> [ddnet] always thought that 19:21 <+bridge> [ddnet] huffman or smth 19:21 <+bridge> [ddnet] yes that is unpacked size of cause 19:21 <+bridge> [ddnet] ah ok 19:22 <+bridge> [ddnet] I guess compressed size is counted 19:22 <+bridge> [ddnet] @c0d3d3v small integers use just one byte 19:22 <+bridge> [ddnet] before huffman compression 19:25 <+bridge> [ddnet] 14kbit per second = 14*1024/8/25 = 72 Bytes per snap 19:25 <+bridge> [ddnet] 19:25 <+bridge> [ddnet] 4 Byte Message ID 19:25 <+bridge> [ddnet] 19:25 <+bridge> [ddnet] ( 4 Byte Game Tick 19:25 <+bridge> [ddnet] 4 Byte Delta Tick 19:25 <+bridge> [ddnet] 4 Bytes Num Parts 19:25 <+bridge> [ddnet] 4 Bytes Part Number 19:25 <+bridge> [ddnet] 4 Byte CRC 19:25 <+bridge> [ddnet] 4 Byte Part Size ) times Num Parts (if you do nothing you would excpect 1 snap) 19:25 <+bridge> [ddnet] 19:25 <+bridge> [ddnet] = 28 bytes 19:25 <+bridge> [ddnet] 19:25 <+bridge> [ddnet] + Delta Snapshot header 19:25 <+bridge> [ddnet] 4 Bytes m_NumDeletedItems 19:25 <+bridge> [ddnet] 4 Bytes m_NumUpdateItems 19:25 <+bridge> [ddnet] 4 Bytes m_NumTempItems 19:25 <+bridge> [ddnet] = 12 Bytes 19:25 <+bridge> [ddnet] 19:25 <+bridge> [ddnet] + Snapshot header 19:25 <+bridge> [ddnet] 4 Byte Data Size 19:25 <+bridge> [ddnet] 4 Byte Num Items 19:25 <+bridge> [ddnet] = 8 byte 19:25 <+bridge> [ddnet] 19:25 <+bridge> [ddnet] 19:25 <+bridge> [ddnet] in total 48 Header bytes 19:25 <+bridge> [ddnet] 19:25 <+bridge> [ddnet] 19:25 <+bridge> [ddnet] + at least the character that has the flipping velocity 19:25 <+bridge> [ddnet] 4 Bytes Type + ID 19:26 <+bridge> [ddnet] 14kbit per second = 14*1024/8/25 = 72 Bytes per snap 19:26 <+bridge> [ddnet] 19:26 <+bridge> [ddnet] 4 Byte Message ID 19:26 <+bridge> [ddnet] 19:26 <+bridge> [ddnet] ( 4 Byte Game Tick 19:26 <+bridge> [ddnet] 4 Byte Delta Tick 19:26 <+bridge> [ddnet] 4 Bytes Num Parts 19:26 <+bridge> [ddnet] 4 Bytes Part Number 19:26 <+bridge> [ddnet] 4 Byte CRC 19:26 <+bridge> [ddnet] 4 Byte Part Size ) times Num Parts (if you do nothing you would excpect 1 snap) 19:26 <+bridge> [ddnet] 19:26 <+bridge> [ddnet] = 28 bytes 19:26 <+bridge> [ddnet] 19:26 <+bridge> [ddnet] + Delta Snapshot header 19:26 <+bridge> [ddnet] 4 Bytes m_NumDeletedItems 19:26 <+bridge> [ddnet] 4 Bytes m_NumUpdateItems 19:26 <+bridge> [ddnet] 4 Bytes m_NumTempItems 19:26 <+bridge> [ddnet] = 12 Bytes 19:26 <+bridge> [ddnet] 19:26 <+bridge> [ddnet] + Snapshot header 19:26 <+bridge> [ddnet] 4 Byte Data Size 19:26 <+bridge> [ddnet] 4 Byte Num Items 19:26 <+bridge> [ddnet] = 8 byte 19:26 <+bridge> [ddnet] 19:26 <+bridge> [ddnet] 19:26 <+bridge> [ddnet]