Most of Roses' scripts should go in modtools

[PeridexisErrant]

Rather than in new top-level scripts folders, as they're currently set up to do.

[lethosor]

Several other subdirectories should probably also be changed (base, classes, events, etc.), although the obvious issue here is that these scripts depend on each other.

cc @Pheosics

[PeridexisErrant]

Honestly I'm not sure that they should be in the standard DFHack package anyway:

• very specific use-case
• tied very closely to raws, which can be generated with tools DFHack isn't proposing to include
• substantial interdependence on other scripts
• modders can distribute them in /raw/scripts
• anyone worried about versioning issues will do this anyway

Don't get me wrong, I think the collection is amazing, but it's not a great fit with the rest of standard DFHack and I don't think including it actually adds any value over eg a blurb singing it's praises at the top of the modtools docs.

[PeridexisErrant]

Also it keeps jumping to a new repo: most recently here, which does move everything to /raw/scripts/

[lethosor]

Do all of Roses' scripts depend on this organization?
In theory, we could set up another script folder containing Roses' scripts, but that runs the risk of name conflicts with standard scripts that use the same name (and there isn't a great way to configure extra script paths at the moment, outside of running lua in dfhack.init). It would at least prevent them from cluttering ls and possibly command completions, though.
Alternatively, we could try to rework them to be more DFHack-friendly (including moving some utilities to library/lua), or remove them and point users to the repo/thread.

cc @expwnent

[Pheosics]

Not sure if replying directly from my email will work, but here it goes.

Honestly I'm not too concerned with adding my scripts to the standard
package. I really only write them because I want to use them, and then I
release them for others to use (because if there written they may as well
be used). I'm not against it at all, but it sounds like there would need to
be some serious revisions to the scripts and even then they may not mesh
well. Whatever you higher ups decide I will go with, but that is just my
two cents.

On Sun, Nov 1, 2015 at 11:22 AM, Lethosor notifications@github.com wrote:

Do all of Roses' scripts depend on this organization?
In theory, we could set up another script folder containing Roses'
scripts, but that runs the risk of name conflicts with standard scripts
that use the same name (and there isn't a great way to configure extra
script paths at the moment, outside of running lua in dfhack.init). It
would at least prevent them from cluttering ls and possibly command
completions, though.
Alternatively, we could try to rework them to be more DFHack-friendly
(including moving some utilities to library/lua), or remove them and point
users to the repo/thread.

cc @expwnent https://github.com/expwnent

—
Reply to this email directly or view it on GitHub
#712 (comment).

[lethosor]

I'm not sure if we want to include them in r4 (which should be soon) in their current state, although some of your scripts and utilities are useful. I'll disable them for now, but keep this open as a reminder.

[PeridexisErrant]

Yep, it works.

DFHack/roses-scripts#2 is probably relevant; I've basically scraped and formatted the forum posts on the topic. This also clarifies my suggestion a little (you can read the lot here):

• Merge and standardise the 'useful scripts', placing each wherever they'd fit best (modtools, fix, etc)
• Leave out the 'systems' as too complex and versioned for most users

For example gui/unit-info-viewer.lua is identical to the DFhack version aside from some trailing whitespace, while modtools/building-trigger.lua would be a useful thing to add. teleport.lua is much more capable in Roses' version.

There's a bunch of other stuff, but overall I'm starting to think we need a bigger change in the way script development is done. I'll open an issue for that once I've sorted out my thinking.

[PeridexisErrant]

I think the best way to address this and related issues is to let them shake out in #723.

The immediate issue, of adding a large number of scripts and locations which will not have long-term support, has been solved by removing the scripts until we work out what's going on.