11:58 < bridge> [teeworlds] `float SinceStart = (Client()->PrevGameTick(g_Config.m_ClDummy) - m_pClient->m_aClients[ClientID].m_EmoticonStart) / (float)SERVER_TICK_SPEED + Client()->GameTickTime(g_Config.m_ClDummy);` 11:59 < bridge> [teeworlds] didn't test. probably wrong. back to work lol 12:26 < bridge> [teeworlds] @TsFreddie that makes the animation way too slow 12:37 < Jupstar> ts didn't we already find out that the intratick just isnt a reliable source for such stuff, bcs on 2 tick per snapshot its still a value between [0, 1] 12:38 < Jupstar> the correct way would be to add a variable smth like IntraTickSincePrev, that is a value that isnt between 0 and 1 12:39 < Jupstar> but even then it would probably only look good in demos, not in realtime, that is bcs of the order of packets, emotestart just uses the gametick, but if the current gametick is old at the next snapshot we already skip quite alot of the animation 12:42 < bridge> [teeworlds] so we don't have a good smooth time that approximates gametime? 😦 12:43 < bridge> [teeworlds] I checked how damage indicators, weapons and map animations handle this kind of stuff 12:43 < bridge> [teeworlds] and it seems they are all doing it differently, and in ways that seem to conflict with the video recorder 12:43 < bridge> [teeworlds] seems very messy. I guess we need someone to give us a time that approximates gametime but is still relatively smooth 12:53 < bridge> [teeworlds] probably, i just copied the one used for weapon attacking animation. 12:54 < Jupstar> https://github.com/Jupeyy/ddnet/commit/d6cae724c89d55b829193d412669bc2b06cc6f42 12:54 < Jupstar> this would probs fix it for demos, but as said, bcs gametick is changed by a later snapshot it will still look like half of the anim is skipped 12:54 < Jupstar> on a server 12:54 < bridge> [teeworlds] seems like none of the character animation actually use intratick other than the aim angle 13:15 < bridge> [teeworlds] what have i started