Add extract_overlay.py and dependency files submodule

[ProjectOblivion]

No description provided.

[sozud]

What's the rationale behind tools/extract_overlay.py being in this repo vs. the other one?

[ProjectOblivion]

Really just pathing. Seems unnecessary to have it be in a subfolder when it's really just a simple entry point that isn't going to be used anywhere else. Realistically makes very little difference either way.

[ProjectOblivion]

Having the script in the sotn-decomp repo also establishes a place to address sotn-decomp specific code in an external repo, I just haven't split it up yet.

[JoshSchreuder]

@Xeeynamo I think we should consider removing make-config.py in favour of this

I have used it for CAT and ARE now and I think it improves upon a lot of the new config adding experience.
Probably this would close #2703 and #2942

[ProjectOblivion]

Beyond what was there for cat and are, it now also automatically imports and merges e_init.c (EntityUpdates and EInits) and header.c (it has generated <ovl>.h for a while now).
It uses the dynamic syms process and does not use the previous git checkout method for handling symbols, though it does still use git add when complete, to prevent the new config/ files from being wiped by make clean, and uses git clean to clean the asm directory. There is no longer a chance for accidental losses that would happen in the past.

[Xeeynamo]

I’m a bit surprised to see a project-specific utility recreated and relicensed in a separate repository, then proposed as an external dependency rather than contributing improvements upstream. Any changes to make_config.py or closely related tools should also be coordinated with the existing contributors (CC @hohle).

From a practical perspective, I’m not sure what the advantage is of pulling sotn_utils in as a submodule, given that it can already be cloned and used independently. A quick look at the repository also shows several pieces of hard-coded logic that are tightly coupled to our decomp (https://github.com/ProjectOblivion/sotn_utils/blob/main/sotn_config.py, https://github.com/ProjectOblivion/sotn_utils/blob/main/sotn_overlay.py, https://github.com/ProjectOblivion/sotn_utils/blob/main/symbols.py). Ideally, these should be driven by a configuration file rather than embedded directly in the code.

I want to avoid the inevitable situations where updating our project's configuration or symbol definitions require opening PRs in a separate repository, waiting for review, and then syncing the changes back. Such friction will only slow us down and make maintenance more complicated.

[ProjectOblivion]

waiting for review, and then syncing the changes back. Such friction will only slow us down and make maintenance more complicated

This is the primary reason it is in a separate repository, so this doesn't happen to me. I'm updating it incredibly frequently, on the order of daily at times. I do not want everything that is currently in the repo to remain in the repo, though, I want some things to be in sotn-decomp and I am in the process of splitting it up, but that takes time.

Ideally, these should be driven by a configuration file rather than embedded directly in the code.
This is my ultimate intent, but it isn't there yet. I wanted to get it available and worry about things like that next.

I tried having it just be cloned and used independently, but I first created this tool months ago and the only one who used it aside from myself was @JoshSchreuder .

should also be coordinated with the existing contributors

I've brought the tool up twice on discord and have gotten little in the way of overall response there. @JoshSchreuder has been fantastic with feedback and @hohle gave me some good points to adjust (of which I believe I've adjusted all of his concerns). I don't appreciate being told to coordinate when I've done my absolute best to do just that long before submitting the PR.

[Xeeynamo]

I've brought the tool up twice on discord and have gotten little in the way of overall response there. @JoshSchreuder has been fantastic with feedback and @hohle gave me some good points to adjust (of which I believe I've adjusted all of his concerns). I don't appreciate being told to coordinate when I've done my absolute best to do just that long before submitting the PR.

I wasn't aware you coordinated with the other contributors. A mention of in the pull request description would have helped me. I am simply sharing my feedback based on my data points, which I have none as your pull request description is blank.