The ACF Loader uses the given Addon Name as the Addon Path, which is not good for a number of reasons:
People can name the addon directory whatever they want
On Linux, addons with capital letters cannot be loaded - this means when you tell the Loader to look for addons/ACF-3, it will always fail
There's another issue, too: If you're using a branch that has a slashed-prefix (e.g. feature/whatever-thing), the Branch finder will fail because Git internally stores the branch names in sub-directories instead of flat files.
For example, if our branch name was feature/example-feature, ACF looks in the heads/ directory for a file named feature/example-feature. Instead, it should look in the heads/feature/ directory for a file named example-feature. (This is a bit of an oversimplification but it should get the point across)
Example of the error trace:
ACF has finished loading.
[acf-3] addons/acf-3/lua/acf/core/version/version_sh.lua:79: attempt to concatenate local 'Code' (a nil value)
1. CheckLocalVersion - addons/acf-3/lua/acf/core/version/version_sh.lua:79
2. AddRepository - addons/acf-3/lua/acf/core/version/version_sh.lua:142
3. v - addons/acf-3-missiles/lua/acf/core/acfm_globals.lua:23
4. Run - lua/includes/modules/hook.lua:96
5. LoadAddon - addons/acf-3/lua/autorun/acf_loader.lua:187
6. unknown - addons/acf-3/lua/autorun/acf_loader.lua:194
Impact ☄️
Okay, so before, this hasn't been that big of an issue, but recently, ACF-3-Missiles added their AddRepository call to the _OnAddonLoaded hook, which, among other things, loads the ACF Engine Performance data.
It's a weird whirldwind of an issue, but, this means if an addon uses _OnAddonLoaded to call AddRepository, it will break the _OnAddonLoaded hook chain and prevent Engine Data (and other things) from loading.
Which lines up with what we're seeing. ACF Engines just poop out when they spawn, erroring in UpdateOverlay because engine.PowerMax is nil.
The Fix 🛠️
This PR changes two important parts of the ACF Loader:
The ACF Loader no longer tries to search for the addon that calls it. It uses the current stack to determine which addon called the function. This means it'll work regardless of the operating system, and regardless of the directory name
The code that retrieves the branch information can now properly handle branch names with slashes in them
Description 📜
The ACF Loader uses the given Addon Name as the Addon Path, which is not good for a number of reasons:
addons/ACF-3, it will always failThere's another issue, too: If you're using a branch that has a slashed-prefix (e.g.
feature/whatever-thing), the Branch finder will fail because Git internally stores the branch names in sub-directories instead of flat files.For example, if our branch name was
feature/example-feature, ACF looks in theheads/directory for a file namedfeature/example-feature. Instead, it should look in theheads/feature/directory for a file namedexample-feature. (This is a bit of an oversimplification but it should get the point across)Example of the error trace:
Impact ☄️
Okay, so before, this hasn't been that big of an issue, but recently, ACF-3-Missiles added their
AddRepositorycall to the_OnAddonLoadedhook, which, among other things, loads the ACF Engine Performance data.It's a weird whirldwind of an issue, but, this means if an addon uses
_OnAddonLoadedto callAddRepository, it will break the_OnAddonLoadedhook chain and prevent Engine Data (and other things) from loading.Which lines up with what we're seeing. ACF Engines just poop out when they spawn, erroring in
UpdateOverlaybecauseengine.PowerMaxisnil.The Fix 🛠️
This PR changes two important parts of the ACF Loader: