Maybe I'm not the right person to say it, but what the heck: To anyone who read this latest devlog and thought, "oh noes, Josh is re-architecting LT again
," nope. Or at least, not really -- not in the sense of a year-long replacement of a core tech such as a language. This is not that.
As I understood it, this was a combination of two insights:
1. Instead of "broadcasting" events to lots of code, some of which doesn't need to run after every event, add a layer of abstraction that lets code only run when it receives a message that says it needs to run, and redesign events to fire messages instead of calling code directly. For the cost of this additional layer of abstraction to an event/trigger model, you can get a significant performance improvement by no longer making some unnecessary function calls.
2. Distinguish more clearly between "what to do" and "how to do it." Just as your brain supports both conscious thinking and the control of autonomic processes (heartbeat, respiration), it sounds like Josh is distinguishing between invariant functions, which can go in the core for performance (the "how") and control functions, which can be in Lua for modding (the "what"). By better balancing core functions and control functions, the performance vs. flexibility tradeoff can be directly managed.
If I've got these about right, it sounds like an early test of combining these two concepts for how the LT code talks to itself has already yielded a major improvement in performance. That is very cool! It sounds like some of that weight may be lifting.
It's maybe worth noting that the value of these changes (again, assuming I've understood them) goes beyond raw performance. By being consistent in applying the event/trigger communication model where appropriate, the code actually gets easier to write and modify because it tends to decouple functionality -- each module becomes a little more independent, just doing its thing when triggered. Similarly, a clearer distinction between what is core code and what's OK to do in Lua will also help with understandability.
And one other point on moving some functions into the core: computers are only going to get faster. Even if Josh feels he needs to move some functionality into the core for LT 1.0, it may not have to stay there forever. As general CPU/GPU speeds improve, it might be possible to migrate certain features out of the core, opening them up to modding. So just because some things are off-limits (so to speak) when the initial version of Limit Theory launches doesn't necessarily mean they'll stay out of reach of modders forever.
Naturally, if Josh thinks I've gotten any of the above factually wrong, I appreciate correction.
Anyway, the overall point to this is that while there's some recoding to be done, I think the main change Josh was talking about here is conceptual... but these are really good concepts, which should allow delivery of the performance potential that LT must
have. These breakthroughs were necessary now. I believe Josh is on exactly the right track here, and I believe the asteroid performance stats bear that out.
So be of good cheer! I'm certainly excited.