Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[expwnent]

https://github.com/DFHack/dfhack/pull/667

https://github.com/DFHack/dfhack/pull/679

I'm just posting this here to get input from modders / users who don't have github accounts. The main issue is whether backwards compatibility is more important to users in general than including scripts in the main repo. I realize that not all scripts already in the main repo follow the conventions but that is a goal for the future and I think it would be a bad idea to make negative progress on that by allowing new scripts which don't follow them. At a minimum new scripts should follow the utils.processArgs method of processing arguments unless they have a good reason not to. Ideally they should export their functionality using the new script_environment system but that can be fixed without breaking backwards compatibility so that's not as big an issue.

I feel that standardization is more important, because once things are standardized backwards compatibility will follow and it will be easier for both players and modders to learn (and remember) how to use scripts. After the initial pain of converting to the new system, we'll have both backwards compatibility and standardization.

[milo christiansen]

I am all for standardization in the main package, I don't follow the DFHack standards with my scripts, but I'm not trying to get them included with DFHack either...

[Nopenope]

I extensively use scripts and mods. Whenever I want to do a fresh DF install somewhere, here's the places I pull scripts from (on top of DFHack):
https://github.com/Raidau/public_scripts
http://dwarffortresswiki.org/index.php/User:Vjek
https://github.com/maxthyme/dfstuff
https://github.com/expwnent/DFHeritage
https://github.com/lethosor/dfhack-scripts
https://gist.github.com/Putnam3145
https://gist.github.com/IndigoFenix
http://www.bay12forums.com/smf/index.php?topic=135506.0
https://gist.github.com/warmist

And I probably forgot a few more (like the df-ai or milo's stuff). Not to mention some of them are broken as of 40.24, so I have to manually test the ones I want.

Sorry if this sounds rude, but this is getting a teensy little bit silly.

[lethosor]

In my opinion, the current processArgs() makes script invocations too verbose - it's useful for scripts that require a lot of arguments (e.g. modtools/*) or accept a lot of optional arguments, but less useful for simple scripts as it requires arguments to be explicitly named. For example, there's probably no doubt about what the first/only argument to a "rename-selected-unit" script should be, so I'd currently prefer to process arguments in that script manually instead of using processArgs(). Also, there's a case to be made for scripts recognizing a single "help" argument, as well as "enable"/"disable" in some cases (although that won't be necessary in r4 for Lua scripts). I'd support something similar to argparse or getopt, though.

Sorry if this sounds rude, but this is getting a teensy little bit silly.

If you're referring to having to install those scripts manually, the reason for this thread is that we're looking at including more of them in DFHack (although most likely not *all* of them). It's discussed more in-depth at the links expwnent posted, although the first post could be clearer.
Anyway, I'm working on support for extra script search paths, which would allow you to install those scripts in a separate directory and point DFHack to it.

[Meph]

I'm all for standardization and merging more custom scripts into dfhack releases.

It's always difficult of syntax changes, and there are so many nice, useful scripts flying around that people barely find, because they are hidden away inside some threads. Only way people find out about them is the Starterpack or (the currently inactive) MasterworkDF.

[mifki]

Or it's time to make a repository of scripts and a plugin that would let search and install.

[Warmist]

Or it's time to make a repository of scripts and a plugin that would let search and install.

I'm a bit torn between these two views.
One one hand it's obvious that script repo would be best. Especially if you have docs inside scripts (or linked somehow).
One other hand it's way more work and i'm not sure if it's used that much. I think there is "Lazy newb pack" and there is like 20 other people that use it... So not sure if it's worth the trouble.
It would be fun to figure this out and make a nice flexible architecture. I'm thinking somehow use github as our repository. That way it would be free and quite flexible. Not sure if it's legal though.

[expwnent]

As I said in issue #667:

I don't think it's a good idea to have widely open write access. Most scripts are one-offs highly specific to a certain problem. Those certainly don't belong in the main repo. Scripts in the main repo should be reusable and have clear, accurate, and literal names. All widely inclusive threads for organizing user scripts that I've seen end up having so many scripts that it's hard to find the one you're looking for, and most of the scripts they contain will not be useful to most users. I don't want to clutter the main repo with so many scripts that it's hard for users to find the one they need.

I somewhat like the idea of a "supplemental" script library which has a wider range, but who would organize it, and more importantly, maintain it? A lot of the time people will write one script and then more or less forget about it, and if a new major DF version comes along and breaks it they'll be nowhere to be found, and the number of users of highly-specific scripts is small so it's unlikely to get reported to someone who can fix it and it makes it unclear to users whether the script is broken or whether they're just using it incorrectly. Heck, even I've abandoned scripts before and exactly that happened. Point is, there are a lot more people with enough time to write a script than there are people who have enough time to write it and maintain it for future versions.

I agree processArgs is verbose, but the advantage is that the standard can comfortably fit any script in a way that's easy to remember, even if it passes arguments to other scripts and needs escape sequences. You don't have to remember the order of the arguments, and if the arguments are well-named it should be easy to remember the names. I guess it'd be ok to make an exception for scripts that only take one argument, but anything more complicated should be written such that it's easy to learn and remember how to use a new script.

[Dirst]

It might help to a have a snippet of code that checks the first argument for a leading dash, and send it off to ProcessArgs if it finds one, otherwise process the argument (there should only be ONE) positionally.  The advantage is that "command -help" would still work.

By code snippet, I don't mean writing a new feature into ProcessArgs.  Just five or so lines of code that the author can use if they want to be a bit unorthodox.

For comparison, here is a snippet of code to see if a "standard" helper script is available and fall back to a mod-specific one if it's not found.  In this particular case, it's looking for a spawn-unit script new enough to handle an age parameter.  I don't see how to do this more easily without imposing version numbers on scripts, perhaps in a first-line comment.

Code: [Select]

argCustom = (string.match(dfhack.run_command_silent("spawn-unit -help"),"-age ")~="-age ")

if args.custom or argCustom==true then
spawn_cmd = "tesb-spawn-unit"
else
spawn_cmd = "spawn-unit"
end

I agree with restricting write access to the main repository, whatever form it takes, but how does one ask to have their script included?

[expwnent]

That sounds reasonable.

As for getting scripts included, just ask in the main thread I guess.

[PeridexisErrant]

How does one ask to have their script included?

I just make a pull request, often with someone else's script, and that seems to work pretty well.