Rick van Dam

> There appears to be a CompilerGenerated attribute on both the properties and fields, which we could potentially use to filter out candidates for any matching. Oh also on the...

> > Thirdly because of how the serializer api works atm it always creates a new instance. This makes it impossible to put change events on the settings class itself...

> > We could also use composition: > > Could you give an example what the advantage of this design would be? Because it seems more complex / harder to...

For usability reasons I do think we should stick with `.xml` extensions though. Editors know what to do with `.xml` while with `.dat` you don't get any highlighting making it...

Extensions are currently changed to xml in #860 actually. Didn't changed them all in #856 due to conflicts. The PR is still WIP though. Will probably split it up since...

> Worked on the API a bit while looking into #868 and I think we should keep in mind a slight design trap we might fall into: > > *...

Also not sure if the current arithmetric implementation is the most optimal one. There is quite a big difference in the IL being generated. Take for example the vector3 +...

Basically its this: The current version (vector is the vector you get through the parameters) ``` vector.X = someCalculatedValue1; vector.Y = someCalculatedValue2; etc.. return vector; ``` vs this: ``` return...

Might be better memory locality since it doesnt have to go back to that vector between the calculations? Idk really I just noticed this when I looked at the IL...

I have added the assembly to the source and IL post. Here is the benchmark code: ``` class Program { static void Main(string[] args) { BenchmarkRunner.Run(); Console.ReadKey(); } } public...