Wow. Thank you again, Josh, for taking the time to write what, as mcsven said, combined detail with clarity.
On collision detection, it seems like what I was missing was the knowledge that it's doing a lot more than just "ship hit station?"; this is a system that covers many kinds of physical interactions. As such, it's more fundamental than I thought.
This Court finds for the defense. Next case, please!
On modding, of course I understand that it can only be made so easy. I would even argue for caution in making any special effort to simplify it beyond what you're already doing through the basic design of the scripting interface. There should, I think, be a balance of responsibility there.
I mostly followed the examples, I think. And I'm glad to hear they helped a little with your own planning; that's really all I hoped for. The note that debugging/profiling tools will work is especially welcome, though, as well as the by-design split between ECS-modifying and generally-modifying functions/data. I'm hopeful that between these, we (I) won't shoot ourselves (myself) in the foot too often.
At the risk of getting beaten up by forumers who'd rather you were coding, though
, what I keyed on most was your distinction between extending
scripts/data and replacing
them. I understand that you've taken steps to make extending easy -- I can see that in your example code. It's modifying (or even suppressing) functionality that I'm wondering about.
What if there's a feature that is altered by several mods? How will hierarchy be enforced? With a BethSoft "loading order" paradigm or something else (and where would that control live)? Also, if there's a whole feature set that needs to be disabled (perhaps for a really big functionality change of some kind), will there be a simple way to do that, and will modders and mod-users be alerted that any code with a dependency on the disabled functions may break?
The judge must retire to his chambers for the nonce... at most, two nonces.