01:21 < bridge> are MOTDs visible in demos? 01:22 < bridge> ok they aren't 01:30 < bridge> are votes even shown? 02:15 < bridge> ```cpp 02:15 < bridge> bool demo_w_write_msg_sv_chat(dd_demo_writer *dw, int team, int client_id, const char *message) { 02:15 < bridge> char buffer[DD_MAX_MESSAGE_SIZE]; 02:15 < bridge> dd_msg_packer packer; 02:15 < bridge> demo_msg_init(&packer, buffer, sizeof(buffer)); 02:15 < bridge> demo_msg_add_int(&packer, DD_NETMSGTYPE_SV_CHAT << 1); 02:15 < bridge> demo_msg_add_int(&packer, team); 02:15 < bridge> demo_msg_add_int(&packer, client_id); 02:15 < bridge> demo_msg_add_string(&packer, message); 02:15 < bridge> int size = demo_msg_finish(&packer); 02:15 < bridge> return (size >= 0) && demo_w_write_msg(dw, buffer, size); 02:15 < bridge> } 02:15 < bridge> ``` 02:15 < bridge> does anyone have an idea how the teams value is transformed? 02:16 < bridge> ``` 02:16 < bridge> [01:59:41] [INFO] [what] team: -2, msg: TEAM_ALL 02:16 < bridge> [01:59:41] [INFO] [what] team: -1, msg: TEAM_SPECTATOR 02:16 < bridge> [01:59:41] [INFO] [what] team: 0, msg: TEAM_RED 02:16 < bridge> [01:59:41] [INFO] [what] team: 1, msg: TEAM_BLUE 02:16 < bridge> [01:59:41] [INFO] [what] team: 2, msg: WHISPER_SEND 02:16 < bridge> [01:59:41] [INFO] [what] team: 3, msg: WHISPER_RECV 02:16 < bridge> ``` 02:16 < bridge> I have been searching through the code for half an hour and i couldn't find out why the teams of the messages are wrong 02:16 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1450657678731776144/image.png?ex=694355be&is=6942043e&hm=fb418b113c1b169bda7014a1964770520ad710d16bd513a5a7b31f5b5739900b& 03:23 < bridge> That looks gorjus, I love C 03:26 < bridge> https://github.com/Teero888/ddnet_demo/blob/70bd679c3d2bf31085bc661d9682f99348e7cb98/ddnet_demo.h#L2038-L2048 03:26 < bridge> :owo: 04:05 < bridge> !remindme 86400 fix demo tests 04:05 < chillerbot12> Helo teero777 I will remind you at Wed Dec 24 2025 04:05:04 GMT+0100 (Central European Standard Time) about your matter again. 04:06 < bridge> !remindme 1440 fix demo tests 04:06 < chillerbot12> Helo teero777 I will remind you at Thu Dec 18 2025 04:06:30 GMT+0100 (Central European Standard Time) about your matter again. 04:08 < bridge> im so stupid. why would i stay up all night when to fix issues when i could just decide to not care and go to sleep 04:08 < bridge> i literally forgot to eat anything after breakfast 07:54 < bridge> why does a missing formatter stop you from working on files? 🙂 07:59 < bridge> Because I have to do it manually an that's tedious. Also I keep pressing autoformat and need to undo it 🙈 08:00 < bridge> I wrote a full PR in Pep8 standard just to be stopped by the pipeline afterwards 08:25 < bridge> From all the projects I ever worked on, I have never seen a weird python format like in ddnet. It's not following any "industry standard" in formatting 08:35 < bridge> I am sure I could help ddnet maintain the python files as well - as it's my best programming language besides C++ (and my most used) - but I need the right tooling in place and have the basics done 08:47 < bridge> I'm currently doing a minimal version of https://github.com/ddnet/ddnet/pull/11417 08:47 < bridge> which will probably do what you need 08:49 < bridge> I'll gladly review, I assumed that the version from byfox is already minimal, but I learned that I should remove all my assumptions from reviews 08:50 < bridge> a minimal formatter would be something that changes as little as possible from the existing codebase IMO 08:50 < bridge> also mostly doing default stuff 08:51 < bridge> yes, I am still following that PR and reading what you said there 👍 the only thing I'd really ask you is to go from 1 space to 4 08:51 < bridge> from 1 tab to 4 spaces? 08:51 < bridge> even that would be a followup IMO 08:51 < bridge> because the point of adding a formatter is not reformatting the whole codebase now 08:52 < bridge> but rather first find good common style that we currently have 08:52 < bridge> okay, fair 08:53 < bridge> Did we have a demo renderer, which could render demo to video file 08:53 < bridge> the client can do this - or do you mean as headless cli tool? 08:53 < bridge> we do, in the client 08:54 < bridge> I think the client is just a recorder 08:54 < bridge> where's the difference? 08:55 < bridge> I think u have to be focused / tabbed in the client to render 08:55 < bridge> Yeah, I want a headless tool 08:55 < bridge> which can be annoying 08:55 < bridge> It would be useful when you need to render a lots of demos. 08:55 < bridge> every recorder is a renderer, but not every renderer is a recorder - also you automatically get the resolution of your client in the video file 08:56 < bridge> you could still write a script around the client to do this 08:56 < bridge> it would just open the client for all demos 08:57 < bridge> or can you 🤔 is there an f1 command to start recording a video? 08:57 < bridge> I don't think that's good enough. 08:58 < bridge> if you have an idea how to add it as a tool, I'd review it 🙂 08:58 < bridge> I think @patiga might already has such a tool? 08:58 < bridge> as part of twgpu 08:58 < bridge> @teero777 also may have it 08:58 < bridge> if it exists already, I'd not want to duplicate it tbh 08:59 < bridge> AFAICT twgpu is only for maps 08:59 < bridge> Oh yeah 09:00 < bridge> TWGPU has this tool. 09:00 < bridge> oh there is a twgpu-demo-viewer 09:00 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1450759481398001734/image.png?ex=6943b48e&is=6942630e&hm=7978fa7b7fb058f6f84270c86c80c9d3d5a796eb3632102f16da1616c4265706& 09:00 < bridge> i don't yet, i haven't recreated all of the rendering yet, it is going to be part of frametee some day though 09:00 < bridge> since I don't want to rely on the client for rendering 09:00 < bridge> why did the pipeline stop you? 09:00 < bridge> btw 09:01 < bridge> the pylint step was _very_ unhappy, because I did everything different as I formatted with black 🙂 09:01 < bridge> soo the problem was that we had a linter 09:01 < bridge> it was just the "wrong" one 09:01 < bridge> and the solution is to use another linter 09:02 < bridge> I guess 09:02 < bridge> it's a bit ironic though 09:02 < bridge> There is no way to automatically fix a wrong formatted PR 09:02 < bridge> I'd now fix everything by hand 09:02 < bridge> with a formatter, it's often impossible to fix a wrongly formatted PR by hand 09:02 < bridge> because it'll complain if you don't use its suboptimal style 09:03 < bridge> and now you have to work against the autoformatter to find the style it'll accept and still look sane 09:03 < bridge> yes - and that's why I want ruff 09:03 < bridge> ruff also has that problem 09:04 < bridge> but I'm trying to make it work for the existing code at least 09:04 < bridge> there is no autoformatter, that is formatting into the ddnet style. 09:04 < bridge> yes — but most autoformatters take existing code and make it worse in some places 09:04 < bridge> and then one has to either accept the worse style in those places as god-given (it comes from the autoformatter after all!) or try to work around the bad style from the autoformatter 09:06 < bridge> or you put an exception in the line or we adress the wrong values of the formatter 09:07 < bridge> IMO the python file need some love - as I said I am gladly waiting for your PR 09:07 < bridge> IMO the python file need some love - as I said I am gladly waiting for your PR - because currently I wouldn't say the code is formated in a good style 09:10 < bridge> I would say that using python script to generate code is annoying, IntelliSense wouldn't work until the code is generated. And you would get lots of error in the editor. 🙁 09:10 < bridge> I must say, Pycharm has shown me the tabs as 1 spaces, so it's not looking _as bad_ as I initially thought 09:10 < bridge> that's beside the point, we do _not only_ use python to generate code. 09:11 < bridge> tbh, reading no-lint, especially in c++ code just makes me want to commit a felony crime :justatest: 09:11 < bridge> Yeah, I just have a mention of some parts of it. 09:11 < bridge> do we pretend false positives don't exist? 09:12 < bridge> false positives can be addressed upstream, like we did with the template args thing from solly 09:13 < bridge> or was that chiller? I forgot 09:13 < bridge> How do I adress wrong security warnings upstream? Or clang-format false positives upstream? 09:13 < bridge> you can't fix all false positives 09:13 < bridge> How do I adress wrong github security warnings upstream? Or clang-format false positives upstream? 09:13 < bridge> I agree. 09:13 < bridge> but even there, it was a struggle to get the author to accept that this might be a false positive in the tool 09:13 < bridge> the ddnet PR author 09:14 < bridge> not the tool author 09:14 < bridge> it seems there's too much blind trust in linters/formatters 09:14 < bridge> Different compiler (in the different version) would give different false positives. 09:15 < bridge> and in the future the AI complains about unsafe code because it's hallucinating :pepeW: 09:16 < bridge> @heinrich5991 btw the server browser feels now blazingly fast 09:16 < bridge> did you rewrite it In rust?? 🚀 🚀 🚀 09:16 < bridge> @heinrich5991 btw the server browser feels now blazingly fast 🥳 09:16 < bridge> :monkalaugh: 09:17 < bridge> shouldn't have a noticeable perf impact oO 09:17 < bridge> we rewrote it into a vector instead of weird dynamic memory 09:17 < bridge> it was doing memcopy for every 100 new servers 09:17 * bridge maybe I am hallucinating 09:17 < bridge> which is like what? 30 memcpys? 09:18 < bridge> shouldn't be noticeable 09:18 < bridge> the network request should be taking more than 1000x that time 09:18 < bridge> I wonder if using list would be faster than vector 09:19 < bridge> :thonk: 09:19 < bridge> it uses a heapmap in the background already - the vector is just another representation 09:19 < bridge> it's a vector of pointers 09:20 < bridge> linked lists are almost always slower than vectors 09:20 < bridge> in practice 09:21 < bridge> I'd assume a list is only worth if you have someone adding and removing a few thousand servers from the browser every second xd 09:21 < bridge> I means just for the serverlist. 09:21 < bridge> I do not, currently. twgpu sadly still doesn't have a proper dead reckoning implementation. I still need someone to explain me properly how to implement that ^^ 09:22 < bridge> hmmm. I need to talk to you about that. in my mind it's quite simple, but it's probably not if you can't implement it ^^ 09:22 < bridge> the problem is memcaching, a vector is usually faster, because it's organized in one memory block 09:23 < bridge> Thanks for explaination. :3 09:24 < bridge> I'd which we'd have basic tools in ddnet as well, like a map-to-image or demo-renderer - but I don't know how to do this headless 09:25 < bridge> I'd wish we'd have basic tools in ddnet as well, like a map-to-image or demo-renderer - but I don't know how to do this headless 09:25 < bridge> map-to-image is probably not that hard, since the map renderer is now already "standalone" in the codebase 09:29 < bridge> I think we can just create one based on a headless-client. 09:30 < bridge> I don't know if it can do screenshots 09:31 < bridge> because the map renderer sends graphics calls to the pipeline obviously 09:32 < bridge> We are currently converting .teehistorian and with `tee-hee replay` to a .demo, the only missing piece is the viewer, which I would like to have as Emscripten, but the current master doesnt compile without changes 🙁 09:32 < bridge> Thats my showstopper, else the UI would be done for a webviewer of .teehistorian files 09:33 < bridge> time to register some servers 🧌 09:33 < bridge> time to register some servers :troll: 09:33 < bridge> #masterban incoming 09:34 < bridge> But I guess this is not monitored automatically, just all by hand 09:34 < bridge> So you have a chance of doing this 09:34 < bridge> you're gonna master ban 2000 ips ;P 09:34 < bridge> you're gonna master ban 2000 ips? ;P 09:34 < bridge> Mostly server ips, no? 09:34 < bridge> You cant register if your server doesnt respond to the ping request from master 09:35 < bridge> You could only avoid this if you register a lot of chn servers & ask heinrich to add them 😄 09:35 < bridge> just do actualy servers over a botnet of toasters 09:35 < bridge> because chn great fw is blocking the requests 09:36 < bridge> why real servers? you can easily register fake servers, if you have a big botnet this shouldn't be that hard to pull off 09:37 < bridge> because they are harder to ban 09:37 < bridge> Pycharm can detect and adapt to the style of a particular file. 09:37 < bridge> the challenge is that you need so many servers that the client lags for enough time for the servers to refresh so the client freezes eternally 09:37 < bridge> That is why I am against HTTP master. 09:38 < bridge> No, the HTTPS master is fine 09:38 < bridge> HTTPS is cacheable, well-defined & battle-tested 09:38 < bridge> soo... you agree? 09:38 < bridge> Same problem in HTTPS master. 09:38 < bridge> xd 09:38 < bridge> not a custom, udp self-built, game protocol message 09:39 < bridge> idk why, but obviously, the backcompat mastersrv should be able to received the packet from CHN servers. 09:40 < bridge> Maybe there's something wrong with it. :3 09:40 < bridge> UDP traffic isn't blocked. 09:40 < bridge> Its filtered by the great firewall 09:41 < bridge> Sometimes it gets through, a few minutes later it doesnt 09:41 < bridge> The same happening with wireguard as well 09:41 < bridge> I don't think so. You can always get my server info in the server browser. 09:41 < bridge> The teeworlds mastersrv also reports that `no firewall problem detected.` 09:42 < bridge> Because your server is most likely allowlisted to just register & no more interaction 09:42 < bridge> Or you are just lucky & are in Hong Kong 😄 09:53 < bridge> the HTTPS masters sends you a UDP packet that you don't seem to receive 09:53 < bridge> the problem is the great firewall, likely 09:54 < bridge> and you don't do that, because you're a nice person who doesn't want to cause admin work 09:54 < bridge> I guess that because the server send a HTTP request, and then the next UDP packet would be blocked. 09:54 < bridge> it's too much effort with no gain 09:55 < bridge> but you're not nice? sad 09:55 < bridge> @remakepower the old-style masterserver has a much bigger problem: it can easily be DDoSed 09:56 < bridge> Yeah, that's correct 09:56 < bridge> if we'd still be using the old masterserver, you'd get no servers at all 09:56 < bridge> because it was constantly DDoSed 09:56 < bridge> you're only lucky with the old masterserver because no one cares about it anymore 10:01 < bridge> Do we have other HTTPS master now? 10:01 < bridge> (Not mirror) 10:02 < bridge> mostly blocked by https://github.com/ddnet/ddnet/issues/5156 10:02 < bridge> the idea isn't new, but no one fixes that issue 10:03 < bridge> I remembered that I have seen that issue 3 years ago. 10:03 < bridge> :frozen: 10:20 < bridge> It did not work 10:20 < bridge> 🙁 10:20 < bridge> i am :( 10:20 < bridge> Sad 10:21 < bridge> I'm bad at client-side codes. :3 10:27 < bridge> what's the error? 10:31 < bridge> idk why, but it told me that width and height is private field. 10:31 < bridge> https://gitlab.com/ddnet-rs/twgpu/-/blob/master/twgpu-tools/src/ff.rs#L313 10:33 < bridge> deen remaking a whole game as a hobby and for fun 10:33 < bridge> ai using half the planets power trying be him 10:34 < bridge> deen? 10:37 < bridge> ye d double e 10:38 < bridge> he might have copied everything but he made moves 10:39 < bridge> I can't understand what did you say. 10:41 < bridge> what exactly did he do? 10:41 < bridge> ddnet-rs is from jupstar 10:41 < bridge> or what do you mean? 10:44 < bridge> @essigautomat here you go ^ 10:51 < bridge> what was the idea... 10:51 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1450787400765804696/image.png?ex=6943ce8e&is=69427d0e&hm=cacd66d580137aa1936d1741d486cf6ac954cd56e479c6d91f6a0f410aec0a7d& 10:51 < bridge> i can't get perf to work anymore smh 10:51 < bridge> the annotations don't wrok 10:51 < bridge> the annotations don't work 11:07 < bridge> okay i downgraded to 6.15 and now it works again 11:54 < bridge> We are what you might call a trendsetter. Function over form python, blazing efficient development 11:57 < bridge> This is what keeps me up at night. People just trust tooling soooo much 11:59 < bridge> Jupstar, before leaving, had mentioned that it would be easy for the VK backend to do the rendering headlessly, maybe you can investigate that. VK only headless rendering would be okay too 11:59 < bridge> almost missed it due to the doublepings 😄 12:03 < bridge> ddnet-rs already allows headless rendering 12:03 < bridge> but i don't think there is a cli tool 12:08 < bridge> I guess I could, if I wasn't sooo buuusy maintaining all the open pull requests I have 😉 12:11 < bridge> I’d guess it’s just a matter of copying the image from a framebuffer to a host visible place, which it already probably does for the current recorder. So maybe it’s even as simple as just not creating a surface 12:11 < bridge> in theory the screenshoting should already do this 12:12 < bridge> what is the current behavior of the client if you try to open it with a map? 12:12 < bridge> open in editor, probably? 12:12 < bridge> oh yes that's true I use that I remember now xD 12:18 < bridge> Pretty sure you could hack in a way for ddnet-rs to do headless rendering without much trouble. 12:18 < bridge> 12:18 < bridge> Could just open an issue, jupstar answers there 12:18 < bridge> Pretty sure you could hack in a way for ddnet-rs to do headless rendering via cli without much trouble. 12:18 < bridge> 12:18 < bridge> Could just open an issue, jupstar answers there 13:30 < bridge> I have a question 13:30 < chillerbot12> Any coding or ddnet related questions are welcome here, just ask. See https://dontasktoask.com/ for more info 13:30 < bridge> Why the prefix of teeworlds tl array is `l`. 13:31 < bridge> :thonk: 13:36 < bridge> And then 13:36 < bridge> ``` 13:36 < bridge> sorted_array m_Strings; 13:36 < bridge> ``` 13:36 < bridge> is not 13:36 < bridge> ``` 13:36 < bridge> sorted_array m_lStrings; 13:36 < bridge> ``` 13:37 < bridge> In DDNet codes, there's no any prefix for `std::unordered_map` 13:38 < bridge> noticed that yesterday, just pushed the fix :) 13:42 < bridge> ```bash 13:42 < bridge> > make -j$(nproc) movebox 13:42 < bridge> [ 33%] Merging PGO raw profiles... 13:42 < bridge> [ 33%] Built target ddnet_map_loader 13:42 < bridge> [ 33%] Built target pgo-merge-data-movebox 13:42 < bridge> [ 77%] Built target ddnet_physics 13:42 < bridge> [ 88%] Building C object benchmarks/movebox/CMakeFiles/movebox.dir/movebox.c.o 13:42 < bridge> warning: /home/teero/software/frametee/libs/ddnet_physics/benchmarks/movebox/movebox.c: function control flow change detected (hash mismatch) main 13:42 < bridge> Hash = 209100687108012539 up to 100002516 count discarded [-Wbackend-plugin] 13:42 < bridge> 1 warning generated. 13:43 < bridge> [100%] Linking C executable movebox 13:43 < bridge> /usr/bin/ld: error: LLVM gold plugin: linking module flags 'ProfileSummary': IDs have conflicting values: '<0x56340da40f00> = !{<0x56340d9b2810>, <0x56340da3f68 13:43 < bridge> 0>, <0x56340da3f6c0>, <0x56340da3f700>, <0x56340da3f740>, <0x56340d9b2f60>, <0x56340d9b2fa0>, <0x56340d9b2fe0>, <0x56340d9b3020>, <0x56340da40e80>}' from ../../ 13:43 < bridge> libddnet_physics.a.llvm.2110.collision.c, and '<0x56340d9b5400> = !{<0x56340d9b2810>, <0x56340d9b2850>, <0x56340d9b2890>, <0x56340d9b28d0>, <0x56340d9b2910>, <0 13:43 < bridge> x56340d9b2f60>, <0x56340d9b2fa0>, <0x56340d9b2fe0>, <0x56340d9b3020>, <0x56340d9b5380>}' from ld-temp.o 13:43 < bridge> clang: error: linker command failed with exit code 1 (use -v to see invocation) 13:43 < bridge> make[3]: *** [benchmarks/movebox/CMakeFiles/movebox.dir/build.make:107: benchmarks/movebox/movebox] Error 1 13:43 < bridge> make[2]: *** [CMakeFiles/Makefile2:365: benchmarks/movebox/CMakeFiles/movebox.dir/all] Error 2 13:43 < bridge> make[1]: *** [CMakeFiles/Makefile2:372: benchmarks/movebox/CMakeFiles/movebox.dir/rule] Error 2 13:43 < bridge> make: *** [Makefile:234: movebox] Error 2 13:43 < bridge> ``` 13:43 < bridge> lol i've never had this error before, cool. 13:43 < bridge> chillerdragon: I may be an uneducated swine but isn't absolute returns positive value, so `Diff < 0` will never be true? xd 13:45 < bridge> there is 0 way chiller did that on accident 13:47 < bridge> it takes so much effort to make a new branch, find a commit name, push, and then open a pull request 13:50 < ws-client> **** oops 13:52 < bridge> https://tenor.com/view/james-doakes-james-doakes-doakes-meme-doakes-suspicious-gif-496833742737182965 13:52 < bridge> sabotaging finishes 13:53 < ws-client> **** yea i really dont want to touch that code actually 13:53 < ws-client> **** heinrich forces me to do shit again i dont want to do 14:07 < bridge> I think that 14:07 < bridge> > Adding new abstractions without cleaning up the old ones is not a good idea. 14:17 < bridge> what prefix would you give it? In the end everything is an object anyways, could be m_hStrings for hashmap 14:17 < bridge> C++ is really missing a proper hashmap ,_; 14:17 < bridge> C++ is really missing a proper hashmap ;_; 14:30 < bridge> @learath2 you there? 😮 14:31 < bridge> A little here, doing crypto exercises 14:32 < bridge> Are you winning 14:32 < bridge> `std::unordered_map` is about as close as you get, it is better nowadays, but depends on how you define "proper", it definitely isn't "modern" 14:32 < bridge> can you take a look at ? It's just a small bugfix and really easy :owo: ❤️ 14:33 < bridge> do you know if it has const lookup time for int? Because I use two unordered_maps in the envelope PR 14:33 < bridge> and the documentation is not helpful: "CONST or O(log(n)) 14:33 < bridge> and the documentation is not helpful: "CONST or O(log(n))" 14:35 < bridge> This doesn't sound right, it should be const or linear worst case 14:35 < bridge> Are you sure you aren't looking at `std::map`? 14:35 < bridge> oops, I just reviewed it before seeing your message 14:35 < bridge> maybe I read the right thing 14:36 < bridge> maybe I mean the right thing 14:36 < bridge> thank you ❤️ doesn't really matter who reviews it 14:36 < bridge> Any hashmap on earth should have const time average lookups for any key, the problem is hash collisions, which gives the worst case 14:37 < bridge> ah, there are no collisions, so it's always const 14:37 < bridge> For the STL unordered_map, the spec sadly forces closed addressing, thus you get the worst case of all keys colliding into one and a linear lookup 14:37 < bridge> For the STL unordered_map, the spec sadly forces closed addressing, thus you get the worst case of all keys colliding into one bucket and a linear lookup 14:37 < bridge> no collisions? I doubt it ^^ 14:37 < bridge> I put unique ints in there as key, how would they collide? 14:38 < bridge> Maybe he precalculated a perfect hash function, you never know 🙃 14:38 < bridge> You'd need infinite buckets 14:38 < bridge> collisions aren't about equal keys. all hashmaps only ever have different keys 14:38 < bridge> by design, you can't have more than ~65.000 envelope triggers 14:38 < bridge> you put the keys into different buckets based on hash(key) % bucket 14:38 < bridge> you put the keys into different buckets based on something like `hash(key) % bucket` 14:39 < bridge> you put the keys into different buckets based on something like `hash(key) % num_bucket` 14:39 < bridge> you put the keys into different buckets based on something like `hash(key) % num_buckets` 14:39 < bridge> since you probably don't know what `hash` nor what `num_buckets` is, you can't make a statement about no collisions 14:39 < bridge> yeah probably true 14:39 < bridge> and I can guarantee you that you have some, otherwise the hashmap would be far too large 14:40 < bridge> It would be about 65000 buckets, otherwise you'd run into the pigeonhole issue 😛 14:40 < bridge> I guess most of the time we don't have 65k envelope triggers 14:45 < bridge> @heinrich5991 can you explain this to me? https://github.com/ddnet/ddnet/pull/11442/files#r2627092250 14:45 < bridge> @heinrich5991 can you explain this to me? 14:46 < bridge> yes hopefully 😄 I made it this way, because I bet people will do > 255, and delay is otherwise unused and shouldn't be used for this 15:14 < bridge> I just noticed how bad the floats in the database are for times 15:14 < bridge> and the decimals PR is closed 15:14 < bridge> @essigautomat can you give me an example of a `float` that would break with `roundf` but not with `llroundf`? 15:14 < bridge> didn't I write one? 15:15 < bridge> 15:15 < bridge> 15:15 < bridge> 16,777,217 15:15 < bridge> but `m_BestTime` is a float value 15:15 < bridge> rounding this float doesn't give you a proper decimal anymore, it's really hard to tell if this continues to work in such a case or not 15:15 < bridge> so it can't be `16_777_217` 15:16 < bridge> currently it's rounded before it has been send to the client 15:16 < bridge> currently it's rounded before it has been send to the client (yeah stating the obvious) 15:17 < bridge> so I don't think your example is an example 15:17 < bridge> rounding to the nearest float is not rounding to the nearest int 15:18 < bridge> that is my issue with this, we can't round to an integer with a float, that can't represent it 15:19 < bridge> if we had std::int64_tround I'd happily use it 15:20 < bridge> what is the correct representation of a time a player has? The float in the database, the number of ticks he took from start fo finish? 15:20 < bridge> because converting the ticks to the float is already lossy 15:20 < bridge> ```c++ 15:20 < bridge> #include 15:20 < bridge> #include 15:20 < bridge> 15:20 < bridge> int main() { 15:20 < bridge> float f = 16'777'217.0f; 15:20 < bridge> int64_t i1 = llroundf(f); 15:21 < bridge> int64_t i2 = (int64_t)roundf(f); 15:21 < bridge> std::cout << i1 << "\n" << i2 << "\n"; 15:21 < bridge> return 0; 15:21 < bridge> } 15:21 < bridge> ``` 15:21 < bridge> ``` 15:21 < bridge> 16777216 15:21 < bridge> 16777216 15:21 < bridge> ``` 15:21 < bridge> I don't think there's a difference between `(int64_t)roundf(float_value)` and `llroundf(float_value)` 15:22 < bridge> the PR was not well thought out. I'd guess the easiest fix would be using centiseconds or milliseconds and storing as int 15:23 < bridge> I think `(int64_t)roundf(float_value)` gives the exact same answer for every `float_value` as your hypothetical `int64_troundf` 15:24 < bridge> I am checking 15:37 < bridge> The proper proper solution would be to not involve floats at all in this mess 15:37 < bridge> I guess you're right, I checked a lot of big numbers and iterated over the next 15:37 < bridge> Store it as integer amount of ticks and along with a small note that we operate at 50Hz 15:37 < bridge> the proper proper solution would be to not use floats for game physics 15:37 < bridge> or anywhere near this game 15:38 < bridge> You'd ideally only ever go to floats for gfx 15:38 < bridge> I also felt like I had a proof ^^ 15:38 < bridge> so it's good that real-world edge cases agree with me 15:39 < bridge> What are you guys looking for? I'm good at having knowledge of mostly useless edge cases 15:40 < bridge> why does `lroundf`/`llroundf` exist in the C standard? `roundf` and then casting to `long`/`long long` should produce the same result in all cases 15:41 < bridge> that has really weirded me out — normally the C standard doesn't have borderline useless function 15:41 < bridge> that has really weirded me out — normally the C standard doesn't have borderline useless functions 15:46 < bridge> > Computes the nearest integer value to num (in floating-point format), rounding halfway cases away from zero, regardless of the current rounding mode. The library provides overloads of std::round for all cv-unqualified floating-point types as the type of the parameter num 15:46 < bridge> 15:46 < bridge> > Computes the nearest integer value to num (in integer format), rounding halfway cases away from zero, regardless of the current rounding mode. The library provides overloads of std::lround and std::llround for all cv-unqualified floating-point types as the type of the parameter num 15:46 < bridge> 15:46 < bridge> What are cv-unqualified floating point types? 15:46 < bridge> const volatile 15:46 < bridge> i.e. floating point types without `const` and `volatile` 15:48 < bridge> I wonder, if we round a float to the nearest integer, but we can't hit it perfectly, because we can't represent it as a float, wouldn't we round down in the next step with the cast to int_64? 15:49 < bridge> if you can't hit the integer perfectly, you'll get another integer instead 15:49 < bridge> `roundf` always outputs an integer 15:50 < bridge> roundf always outputs a float 15:50 < bridge> a float that represents an integer (the mathematical concept) 15:50 < bridge> not the type 15:52 < bridge> Actually quite interesting, I can't think of anything except the slightly different error semantics lround and llround have to round 15:53 < bridge> I think my thinking mistake lies in the fact, that the smallest float that every float, that has parts behind a comma, can always be perfectly rounded to the nearest integer 15:53 < bridge> I think my thinking mistake lies in the fact, that every float, that has parts behind a comma, can always be perfectly rounded to the nearest integer 15:53 < bridge> yea, error semantics was also something I found 15:53 < bridge> apparently `llround` returns unspecified values, but I think casting is UB instead? 15:54 < bridge> yes, `fround` is an exact function 15:54 < bridge> it always outputs the exact mathematical result 15:54 < bridge>