14:14 <+bridge> [ddnet] <c0d3d3v> for what? freeze only sets freeze time every second
14:19 <+bridge> [ddnet] <c0d3d3v> @deen  do release tags match the last commit of a version? So If I checkout to tag 15.9.1 I get all commits in that version?
14:21 <+bridge> [ddnet] <c0d3d3v> Mh even if not, should be close enough, for my investigation
14:22 <+bridge> [ddnet] <deen> yes, they should match (modulo mistakes by me)
14:26 <+bridge> [ddnet] <Jupstar> i just saw weird flickering of the freezebar when dummy falls through 1 bar of freeze
14:27 <+bridge> [ddnet] <c0d3d3v> on latest master?
14:28 <+bridge> [ddnet] <c0d3d3v> I thought I have patched it
14:28 <+bridge> [ddnet] <Jupstar> yeah relativly latest master
14:28 <+bridge> [ddnet] <Jupstar> master from like today morning xd
14:28 <+bridge> [ddnet] <c0d3d3v> can you reproduce?
14:29 <+bridge> [ddnet] <c0d3d3v> can you reproduce it?
14:29 <+bridge> [ddnet] <Jupstar> https://cdn.discordapp.com/attachments/293493549758939136/980085434958901308/test.mp4
14:31 <+bridge> [ddnet] <c0d3d3v> Thats expected behaviour
14:31 <+bridge> [ddnet] <Jupstar> the 2nd to be precise
14:32 <+bridge> [ddnet] <Jupstar> mh ok looks really weird imo
14:32 <+bridge> [ddnet] <Jupstar> bcs the bar continues where it stopped pretty much
14:32 <+bridge> [ddnet] <Jupstar> but flickers
14:32 <+bridge> [ddnet] <c0d3d3v> The freeze bar is turend off if you are in a freeze bar. We could vote to let it stay on or we add a option.
14:32 <+bridge> [ddnet] <c0d3d3v> The freeze bar resets to full if you get contact with freeze after 1 second
14:32 <+bridge> [ddnet] <c0d3d3v> The freeze bar is turend off if you are in a freeze blocl. We could vote to let it stay on or we add a option.
14:32 <+bridge> [ddnet] <c0d3d3v> The freeze bar resets to full if you get contact with freeze after 1 second
14:32 <+bridge> [ddnet] <c0d3d3v> The freeze bar is turend off if you are in a freeze block. We could vote to let it stay on or we add a option.
14:32 <+bridge> [ddnet] <c0d3d3v> The freeze bar resets to full if you get contact with freeze after 1 second
14:32 <+bridge> [ddnet] <Jupstar> yeah thats weird ddrace logic, not ur fault ^^
14:33 <+bridge> [ddnet] <Jupstar> but stars are also always visible arent they
14:33 <+bridge> [ddnet] <Jupstar> not even sure rn xd
14:33 <+bridge> [ddnet] <c0d3d3v> yes
14:33 <+bridge> [ddnet] <c0d3d3v> you can also see the stars in the video, as soon as the bar refilled 3 new stars poped up
14:34 <+bridge> [ddnet] <Jupstar> yeah
14:36 <+bridge> [ddnet] <c0d3d3v> actually it does not even refill in the video xD I did not see the tee unfreeze at the floor... It just refreeze again
14:37 <+bridge> [ddnet] <Jupstar> well if we replace stars anyway probs should always show this bar
14:37 <+bridge> [ddnet] <c0d3d3v> you probably only mean the freeze bar disapear in the block
14:37 <+bridge> [ddnet] <Jupstar> yes
14:38 <+bridge> [ddnet] <c0d3d3v> I would like a option for it, because I do not like it if a lot of tees sit next to each other in freeze and nothing happens except a lot of freeze bars refilling every second
14:39 <+bridge> [ddnet] <Jupstar> well idc, can u turn that thing off?
14:39 <+bridge> [ddnet] <Jupstar> then u can also just add a third option there
14:39 <+bridge> [ddnet] <c0d3d3v> currently nothing happens except a lot of stars getting animated
14:39 <+bridge> [ddnet] <c0d3d3v> yes
14:40 <+bridge> [ddnet] <c0d3d3v> there is already a option to turn it off, because some asked for it
14:40 <+bridge> [ddnet] <c0d3d3v> Also have to think if we somehow can get the server inform, that freezebar is of, so he sends stars instead
14:41 <+bridge> [ddnet] <c0d3d3v> Also have to think if we somehow can get the server inform, that freezebar is off, so he sends stars instead
14:41 <+bridge> [ddnet] <trml> maybe hackish, but maybe you could generate the stars in the client in that case?
14:42 <+bridge> [ddnet] <c0d3d3v> yes I also thought about that, but probably requiers prediction?
14:45 <+bridge> [ddnet] <trml> it would be a bit like airjump I think (which is also not sent), so it could be done without it. the code for it wouldnt be as clean as for just showing the freezebar though
15:49 <+bridge> [ddnet] <Jupstar> what was the reason again that we overwrite system defaults linker?
15:49 <+bridge> [ddnet] <Jupstar> 
15:49 <+bridge> [ddnet] <Jupstar> I dont think this is good style, also it probs wont help for packaging, bcs their CI always downloads packages they need, doubt they download smth like lld for no reason
16:10 <+bridge> [ddnet] <deen> People complaining that their local build is slow with IPO
16:10 <+bridge> [ddnet] <deen> since we enabled IPO by default
16:11 <+bridge> [ddnet] <deen> but now IPO is off by default, so probably doesn't matter much
16:11 <+bridge> [ddnet] <Jupstar> i already said it in the pr, CMAKE has a parameter for that too 😄
16:11 <+bridge> [ddnet] <Jupstar> we can just enable it for our full release builds
17:23 <+bridge> [ddnet] <Kaffeine> The issue is that the option is a cache variable.
17:23 <+bridge> [ddnet] <Kaffeine> You've turned it off, but for those who updated to a prev version with it being `ON` by default, it kept `ON` after the update to current `master`.
17:23 <+bridge> [ddnet] <Kaffeine> The issue is that the option is a cache variable.
17:23 <+bridge> [ddnet] <Kaffeine> You've turned it off, but for those who updated to "prev version with it being `ON` by default", it kept `ON` after the update to current `master`.
17:23 <+bridge> [ddnet] <Kaffeine> The issue is that the option is a cache variable.
17:24 <+bridge> [ddnet] <Kaffeine> You've turned it off, but for those who updated to "prev version with it being `ON` by default", it is kept `ON` after the update to current `master`.
17:24 <+bridge> [ddnet] <Kaffeine> The issue is that the option is a cache variable.
17:24 <+bridge> [ddnet] <Kaffeine> You've turned it off, but for those who updated to "prev version with it being `ON` by default", it is still `ON` after the update to current `master`.
17:24 <+bridge> [ddnet] <Kaffeine> The issue is that the option is a cache variable.
17:24 <+bridge> [ddnet] <Kaffeine> You've turned it off, but for those who updated to "prev version with it being `ON` by default", it is still `ON` after update to the current `master`.
17:33 <+bridge> [ddnet] <c0d3d3v> @bencie  could you test this PR if you have time <https://github.com/ddnet/ddnet/actions/runs/2401463925> (as soon as it has compiled)
17:34 <+bridge> [ddnet] <bencie> yeah ^^
17:37 <+bridge> [ddnet] <c0d3d3v> with a local server and the map Fall into the Future
17:40 <+bridge> [ddnet] <Learath2> Mh, how did an dragger rework even get merged without a side by side comparison to check the draggers behaviour?
17:41 <+bridge> [ddnet] <c0d3d3v> I did do a side by side comparison
17:41 <+bridge> [ddnet] <c0d3d3v> Its was one tick off... that was hard to see
17:42 <+bridge> [ddnet] <c0d3d3v> one tick to slow activated
17:42 <+bridge> [ddnet] <c0d3d3v> one tick to slow deactivated
17:43 <+bridge> [ddnet] <c0d3d3v> and https://github.com/ddnet/ddnet/pull/5245 made it worth xD ... but that was not my initial rework
17:43 <+bridge> [ddnet] <c0d3d3v> and <https://github.com/ddnet/ddnet/pull/5245> made it worth xD ... but that was not my initial rework
17:43 <+bridge> [ddnet] <c0d3d3v> and <https://github.com/ddnet/ddnet/pull/5245> made it worse xD ... but that was not my initial rework
17:45 <+bridge> [ddnet] <c0d3d3v> we should do unit tests xD to prevent physics changes
17:46 <+bridge> [ddnet] <c0d3d3v> but I do not know if tick related stuff is testable using unit tests :/ probably yes
17:46 <+bridge> [ddnet] <Learath2> Teehistorian based ones are possible if we ever get replay capabilities in the server
17:47 <+bridge> [ddnet] <c0d3d3v> that would also be an option, but I mean just normal unit tests, without running a complete server, only a dummy, that executes a view ticks with specific inital data
17:48 <+bridge> [ddnet] <Learath2> Even without replay we could probably hand parse th files, it’s easy to check stuff like position at a certain tick
17:48 <+bridge> [ddnet] <c0d3d3v> yes
17:48 <+bridge> [ddnet] <Learath2> The spaghetti we have isn’t really good for traditional mock tests
17:49 <+bridge> [ddnet] <c0d3d3v> build is ready
17:50 <+bridge> [ddnet] <c0d3d3v> Not easy but with some work, probably dooable
17:50 <+bridge> [ddnet] <c0d3d3v> Not easy but with some work, probably doable
17:56 <+bridge> [ddnet] <bencie> am i supposted to try this on a local server? on official servers its still the same
17:57 <+bridge> [ddnet] <c0d3d3v> with a local server and the map Fall into the Future
17:57 <+bridge> [ddnet] <bencie> ah yeah
17:57 <+bridge> [ddnet] <bencie> works
17:58 <+bridge> [ddnet] <Jupstar> bencie evolved from cat to anime girl
18:25 <+bridge> [ddnet] <ReiTW> @hopetez
18:45 <+bridge> [ddnet] <coldrun> where is the demo render code?
18:45 <+bridge> [ddnet] <Jupstar> video.cpp in client
18:45 <+bridge> [ddnet] <coldrun> ty
23:47 <+bridge> [ddnet] <Assa> I wonder why GitHub doesn't ping me, if a PR from vanilla teeworlds gets mentioned in ddnet 🤔
23:55 <+bridge> [ddnet] <Assa> I wonder why GitHub doesn't ping me, if a PR from me in vanilla teeworlds gets mentioned in ddnet 🤔