08:27 < bridge_> [teeworlds] <chillerdragon> https://github.com/teeworlds/teeworlds/issues/2645iirc some of his findings got CVEs
09:35 < asfgdsg> h
09:35 < asfgdsg> hi
09:35 < asfgdsg> hi
09:35 < asfgdsg> hi
09:35 < asfgdsg> hi
09:35 < asfgdsg> hi
09:35 < asfgdsg> h
09:35 < asfgdsg> hi
09:35 < asfgdsg> hi
09:35 < asfgdsg> hih
09:35 < asfgdsg> ih
09:35 < asfgdsg> ih
09:35 < asfgdsg> hi
09:36 < asfgdsg> hih
09:36 < asfgdsg> ih
09:36 < asfgdsg> ih
09:36 < asfgdsg> hi
09:36 < asfgdsg> hi
09:36 < asfgdsg> hihih
09:36 < asfgdsg> ih
09:36 < asfgdsg> ih
09:36 < asfgdsg> hi
09:36 < asfgdsg> i
09:36 < asfgdsg> helo
09:36 < asfgdsg> :(
09:36 < asfgdsg> whynobody have
09:36  * asfgdsg slaps ChillerDragon around a bit with a large fishbot
09:36 < fokkonaut> im fokko .sunglaseestststst
09:37 < fakeonaut> .a
09:37 < botnik> http://lol
09:37 < fakeonaut> .a
09:37 < botnik> http://lol
09:37 < fakeonaut> a.
09:37 < fakeonaut> s.d
09:37 < fakeonaut> as.
09:37 < fakeonaut> d.as.
09:37 < fakeonaut> h,
09:37 < fakeonaut> hi
09:37 < fakeonaut> hi
09:37 < fakeonaut> hi
09:37 < fakeonaut> hi
09:37 < fakeonaut> .a
09:37 < botnik> http://lol
09:37 < fakeonaut> .s
09:37 < fakeonaut> .d
09:37 < fakeonaut> .lol
09:37 < botnik> http://i.imgur.com/3M9fQ.jpg
12:16 < bridge_> [teeworlds] <fokkonaut> Can u guys stop faking me, thanks
13:23 < bridge_> [teeworlds] <chillerdragon> Fans
17:48 < bridge_> [teeworlds] <Assa> can somebody explain to me, why this works? https://github.com/teeworlds/teeworlds/blob/26d24ec061d44e6084b2d77a9b8a0a48e354eba6/src/game/gamecore.h#L42
17:48 < bridge_> [teeworlds] <Assa> this looks like C++ magic to me, trying to interprete this class as a bunch of ints
17:50 < bridge_> [teeworlds] <Assa> and shouldn't this be devided by sizeof(CTuneParam)?!
17:59 < bridge_> [teeworlds] <Dune> CTuningParams is an array of char*
18:00 < bridge_> [teeworlds] <Dune> So I guess this assumes sizeof int is sizeof char*
18:00 < bridge_> [teeworlds] <Dune> Nothing C++ in this
18:05 < bridge_> [teeworlds] <Assa> I am pretty sure it's an array of CTuneParams which happens to story just one integer value
18:06 < bridge_> [teeworlds] <Assa> store*
18:13 < bridge_> [teeworlds] <Assa> but thanks for the reply, it made it clearer for me ^^
18:54 < minus> yeah that code looks wrong
18:56 < minus> fails to account for s_apNames and any potential padding
18:56 < minus> it's an accident waiting to happen
19:06 < bridge_> [teeworlds] <Dune> @Essigautomat wanna open an issue?
19:07 < bridge_> [teeworlds] <Dune> ty for confirming minus
19:08 < bridge_> [teeworlds] <Assa> s_apNames is a static member, so I guess it's ignored? I can open an issue, but I am currently working on a better setup for tuning variables and Materials anyway
19:21 < bridge_> [teeworlds] <Dune> Don't change stuff if it doesn't bring concrete improvements
19:25 < bridge_> [teeworlds] <Stiopa> A new refactor PR? The backlog for oy grows :d
19:25 < bridge_> [teeworlds] <Assa> I wouldn't if it wouldn't ^^ Currently I need to add tuning variables for each material i am adding, while the new materials itself are just the same variables with different values
19:26 < bridge_> [teeworlds] <Stiopa> Will some of the tunes be map based?
19:26 < bridge_> [teeworlds] <Assa> materials are tune-based
19:27 < bridge_> [teeworlds] <Assa> ice is nothing else then default-ground with fancy tuning settings
19:28 < bridge_> [teeworlds] <Stiopa> I wanted to work on such system, where map could transfer some of the tunes in the map, with a few acceptable presets.
19:28 < bridge_> [teeworlds] <Stiopa> This would be done in order to allow to adapt the "water" to suit their map's theme and needs
19:28 < bridge_> [teeworlds] <Assa> there already is a tuning-layer in ddnet if you are interested
19:29 < bridge_> [teeworlds] <Stiopa> How does it work, exactly?
19:29 < bridge_> [teeworlds] <Assa> the tuning layer? you have 1 block with an ID like a telelayer and envlopes, that contain the new tuning settings
19:29 < minus> oh, you're right, Assa. still isn't nice tho
19:30 < bridge_> [teeworlds] <Stiopa> And data for that block ID can be changed in their editor?
19:31 < bridge_> [teeworlds] <Assa> yes
19:33 < bridge_> [teeworlds] <Stiopa> Here similarly I guess :) i was planning to add a tab where one could edit various tunes (mainly for water) or just pick a preset from vanilla. (Those accepted by vanilla gametypes)
19:34 < bridge_> [teeworlds] <Assa> What I am also modelling is material interactions, what if you are standing on Ice (left foot) and default ground (right foot) at the same time? I don't want to hardcode each interaction, so I genealize this
19:34 < bridge_> [teeworlds] <Stiopa> This would be done to let vanilla mappers do their own thing while keeping in with the vanilla 'purity' requirements
19:34 < bridge_> [teeworlds] <Stiopa> You want to make a smooth transition between materials?
19:34 < bridge_> [teeworlds] <Assa> Yes, and I have already done this
19:35 < bridge_> [teeworlds] <Assa> well, "smooth", for friction i get the minimum, for accerlation the maximum as example
19:36 < bridge_> [teeworlds] <Assa> but you could do it smooth, too
21:57 < rand> CTuneParam are class that contains only a int, so CTunningParams is a list of int members
22:01 < rand> oh, CTunningParams::Num() is only used for the debug HUD
22:06 < rand> iirc, the number of tune params is not part of the network layer (assumed to be the same for server and client, so 32)
22:10 < rand> if you want to start worrying, look into how each tunning param is retrieve for this HUD : *pValue = (float)((CTuneParam *)this)[Index]; (where this is CTunningParams)
22:19 < bridge> [teeworlds] <Assa> thank you ^^ I already understood the code, but it's still a bit hackish. Does Teeworlds have a map Type like std::map?
22:20 < bridge> [teeworlds] <Assa> This would solve all problems there
22:20 < bridge> [teeworlds] <Dune> no
22:23 < rand> how would that help here ?
22:25 < bridge> [teeworlds] <Assa> a map already implements methods like size(), and also we are searching in that static names field a lot
22:29 < rand> we are looking into a small array, the Num() function is likely to compute anything but return a constant known at build time
22:30 < rand> as long this data is not dynamic, this is good enough no?
22:32 < bridge> [teeworlds] <Assa> yes, as long as you don't introduce new stuff, like materials 🙈
22:34 < rand> if you add tuning stuff in tuning.h, macros should work to produce a correct CTunningParams class
22:36 < rand> (but, no client (except the one built with this setup) will like it)
22:41 < bridge> [teeworlds] <Assa> exactly! But we can already do a lot with the already existing tuning variables with different values
22:50 < rand> I missed the point then. anyway, the tuning could be dynamic, carefully look into the code where it's assumed fixed. The name lookup doesn't worth a std::map tho (with respect to teeworlds codebase)