philmasterplus
Active member
Currently, the Script Menu mirrors the layout of files and directories under
Recent events have shown that these solutions have flaws. (A) is not true in JavaScript.† (B) has caused issues and has been effectively disabled. The traditional solution no longer works.
†
To remedy this, I suggest making the Script Menu more flexible. Some ideas:
Edit: @taltamir suggested something similar to Idea #1:
@gausie and @xKiv offered other suggestions, such as adding
scripts/
. This poses a problem as we build large projects like autoscend that install many files and clutter the Script Menu. Users "solved" the problem by moving files into subdirectories. KoLmafia enabled this by (A) allowing scripts to be imported from anywhere and (B) intelligently updating files during svn update
.Recent events have shown that these solutions have flaws. (A) is not true in JavaScript.† (B) has caused issues and has been effectively disabled. The traditional solution no longer works.
†
require("foo.js")
does not recursively search all subdirectories of scripts/
for foo.js
.To remedy this, I suggest making the Script Menu more flexible. Some ideas:
- Allow users to hide files from the Script Menu. KoLmafia could keep a "exclude list" in a settings file.
- Allow the Script Menu to be fully customizable and data-driven, decoupling them from the filesystem. The new Menu would be similar to bookmarks in web browsers, or icons in the Windows Start Menu/the macOS Dock.
Edit: @taltamir suggested something similar to Idea #1:
I think it wold be great if there was a way to instruct mafia itself that a specific file should be excluded from the scripts dropdown menu?
like starting the first line with
#exclude_dropdown
and some way for include to handle it. (either only use it to exclude from dropdown if it is the first line. or have the include command skip that specific line)
or maybe
exclude_dropdown("scripts/autoscend/util.ash");
@gausie and @xKiv offered other suggestions, such as adding
svn/*/scripts/
to the "search path", and allowing projects to declare endpoints/entrypoints. These are good ideas and should be investigated as well, but I feel they are orthogonal to my suggestions.
Last edited: