Claire Foster

> first triggers are resolved, then first level of results happens, next loop second level of results propagate This is basically what I do in Gamoji. Sometimes it requires fiddling...

> produce Δ components, which are aggregated Yes that could work in the context of a particular game and systems. I don't think any mechanism is really general because game...

I have had trouble with ordering in the past but I can't remember the exact detail. The game previously triggered updates only when keyboard events occurred so in that case...

This is interesting, but tricky I think. One thing I found in using Overseer is that sometimes you want to use some state which is stashed outside of the components...

> I don't think getting `e.time` to work is actually possible since there's no guarantee that `LifetimeComp` doesn't have a field `time` as well... Yeah this was also one of...

> Okay, I've managed to implement the getproperty based on Tim's nice implementation. Seems that there's not much, if any, impact on performance. Nice! > Okay I've slightly changed the...

> Isn't that similar to how it is now with e[ComponentTypeName].xyz? Oh I see, yes I think that makes a lot of sense.

IIUC, the answer is that yes, creating an unlimited number of functions at runtime will eventually cause your system to run out of memory. Primarily I expect because all the...

I spent an hour looking into this and reading the C code for method specializations in the runtime. I wasn't able to find anything obvious yet. One interesting thing I...

I think this is probably feasible. `f(x,z=3)` is normally lowered to a *pair* of methods and dispatch figures out which one to call. For RGFs we only really have one...