16:11 <+bridge> [ddnet] <Learath2> Ryozuki: here?
16:13 <+bridge> [ddnet] <Learath2> hmm, in that case @jao do you happen to know what bug https://github.com/ddnet/ddnet/commit/c074fdd30f8e6777bcb9e51bf9b38e3cdceec65f fixed?
16:14 <+bridge> [ddnet] <Learath2> Line 62 of entity.cpp looks very much like undefined behaviour
16:18 <+bridge> [ddnet] <ChillerDragon> is the enevelopes synchronization feature removed?
16:32 <+bridge> [ddnet] <Learath2> I don't think so
16:33 <+bridge> [ddnet] <ChillerDragon> do i have to activate a config or something?
16:34 <+bridge> [ddnet] <ChillerDragon> because during my tests i could not get the synced enevelopes reset they were happily continuing in their animation state no matter what my timer did
16:36 <+bridge> [ddnet] <Learath2> idk how envelopes work at all
16:37 <+bridge> [ddnet] <ChillerDragon> there is this checkbox if the envelope is synced or not and usually synced envelopes are bound to the game timer. So you could use the startline to reset animations. I actually used that in a map. But now it doesnt seem to have a effect
16:38 <+bridge> [ddnet] <Learath2> well given i don't remember any change, you can either find someone who does, or bisect to find at which version this happened
16:38 <+bridge> [ddnet] <ChillerDragon> yea
17:39 <+bridge> [ddnet] <jao> @Learath2 why closed?
17:42 <+bridge> [ddnet] <Learath2> iirc the issues raised in there were fixed
17:43 <+bridge> [ddnet] <jao> i dont think so
17:43 <+bridge> [ddnet] <Learath2> Is binary still unplayable?
17:44 <+bridge> [ddnet] <jao> no but lunar base is
17:44 <+bridge> [ddnet] <jao> unless there was a fix that i missed
17:44 <+bridge> [ddnet] <Learath2> what's the issue? did you add the mapbug command to enable double explosions?
17:44 <+bridge> [ddnet] <jao> yes, didnt help
17:50 <+bridge> [ddnet] <Learath2> I don't see how it can not help 😛
17:51 <+bridge> [ddnet] <Learath2> @jao you added `mapbug grenade-doublexplosion@ddnet.tw` to the config?
17:52 <+bridge> [ddnet] <jao> yes
17:52 <+bridge> [ddnet] <jao> its not emulating the old behavior correctly
17:53 <+bridge> [ddnet] <Learath2> But it works for binary?
17:54 <+bridge> [ddnet] <Learath2> there is no way it's not emulating the behaviour correctly, it explodes twice, it's not a very complex behaviour 😛
17:54 <+bridge> [ddnet] <jao> it doesnt work as it used to on binary either
17:55 <+bridge> [ddnet] <Learath2> Oh I think I see the issue there
17:56 <+bridge> [ddnet] <Learath2> @jao can you test a fix? I can't land a double explosion to begin with 😛
17:58 <+bridge> [ddnet] <jao> im not good enough either xd
17:58 <+bridge> [ddnet] <jao> i can try tho
18:04 <+bridge> [ddnet] <jao> @Im 'corneum
18:16 <+bridge> [ddnet] <Im 'corneum> yes
18:37 <+bridge> [ddnet] <jao> ^
18:55 <+bridge> [ddnet] <Learath2> Oh we are so relying on undefined behaviour with those demo headers, there is no guarantee that you can read a struct from one implementation on another
23:11 <+bridge> [ddnet] <deen> because of padding or endianness?
23:11 <+bridge> [ddnet] <deen> if it's just padding, add a static_assure
23:16 <+bridge> [ddnet] <Learath2> padding and endianness both I guess
23:50 <+bridge> [ddnet] <redix> most structs that are written to files consist of chars only. integers are packed into the chars so endianess shouldn't be a problem. and padding should not be an issue either when you only have chars
23:50 <+bridge> [ddnet] <redix> but yeah... proper serialization would be better