Print

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

[expwnent]

Yeah it mostly looked fine except for that. The main purpose of the conventions is to make it so that people only have to learn one set of syntax rules to use all of the helper scripts (and eventually, all scripts in the main repo), and to make it so that it's as easy as possible to determine what a command means even if you've never seen the syntax before. The rest is just flavor. Documentation is important too, of course, but you already put a todo so yeah. Honestly my own documentation should be a little more thorough. I give examples of arguments but not of entire useful commands.

For examples in the documentation, try to pick them from the default raws as much as possible so that it's easy for new modders to figure out.

[Roses]

Sounds good, I will begin porting all my scripts next week. The only one I foresee trouble with is the wrapper script (since it has to much functionality), I may need your help in deciding what to do with that beast.

[milo christiansen]

Is there a syntax for use in init.lua? I already have a bunch of script code for generating that file from Rubble, and adding reaction command support would just be a simple extension of that.

Ideally something like:

Code: [Select]

hook = require("whatever")
hook.register("REACTION_NAME", "command and args")


[expwnent]

You would want onLoad.init, not init.lua. It's command-line registration, not Lua registration. The syntax is the same as dfhack.init, and the syntax for each command is basically

Code: [Select]

commandName -argName argval -argNameThatIsAList [ listThing1 listThing2 ] -argWithNoValue -anotherArg anotherArgValueHere
Order doesn't matter for argument/value pairs. Type

Code: [Select]

commandName -help for documentation on what arguments do what.

[expwnent]

Link if you want to try it out.

[Roses]

Question:

What should I do about scripts like base_upgradebuilding which currently relies on the LUA_HOOK system and is currently loaded in dfhack.init?

[expwnent]

First, split it into multiple parts. Separable functionality should be separated when possible.

1. Do the actual upgrade from one building type to another

Code: [Select]

building-change-type -building id -newType blah
2. Add components to the new building

Code: [Select]

building-add-component -building id -component itemId
For convenience

Code: [Select]

building-create-then-add-component -building id -item itemStr -material matStr -creator unitId
#delegate to create-item
After those are done, I would make it work like this:

Code: [Select]

building-upgrade-register -reactionName UPGRADE_FACTORY -newType FACTORY_SUPER -items [ WEAPON:ITEM_WEAPON_PICK INORGANIC:IRON WEAPON:ITEM_WEAPON_SWORD CREATURE_MAT:DWARF:BRAIN ]
#which basically just does
#reaction-trigger -reactionName UPGRADE_FACTORY -command [ building-change-type -building \\BUILDING_ID -newType FACTORY_SUPER ]
#reaction-trigger -reactionName UPGRADE_FACTORY -command [ building-create-then-add-component -building \\BUILDING_ID -item WEAPON:ITEM_WEAPON_PICK -material INORGANIC:IRON ]
#reaction-trigger -reactionName UPGRADE_FACTORY -command [ building-create-then-add-component -building \\BUILDING_ID -item WEAPON:ITEM_WEAPON_SWORD -material CREATURE_MAT:DWARF:BRAIN ]

As a native english speaker I am intimately aware of the horrible monstrosity that the language is. One of its many flaws is that modifiers (adjectives/adverbs/etc) go before the thing they modify. When coding, it's sometimes convenient to ignore this so that stuff is sorted/organized by what type of thing it is rather than sorting it little endian, so to speak. I prefer that as a convention, but that's a very mild suggestion. Name your scripts whatever you want.

[Roses]

Question, if I have an argument declared in validArgs but it isn't called in the command line, what does it default to? Is there a way to change what it defaults to?

EDIT: Also, how is your processArgs command going to handle negative numbers? (e.g. change-values -percent -100 -token blood, this should change the amount of blood the creature has by -100%)

EDIT2: How will the dfhack.run_script() function work with the new method for inputting arguments?

[expwnent]

It will be nil. There is currently no way to set a default except local asdf = args.blah or "default value".

It should work if the user uses a backslash before the "-". "-percent \-100" will work. "-percent -100" will not.

run_script should work the way you expect. You just pass the arguments you want as strings.

[Roses]

run_script should work the way you expect. You just pass the arguments you want as strings.

Not sure I quite understand, will one argument be "-percent 100"?

[expwnent]

dfhack.run_script('scriptName', '-arg', 'argValue')

[Roses]

Alright, thanks for all your help. I am almost done with updating all my scripts. Just need to write a help section for each, update my ReadMe, and finish a couple more updates (need to update all the base_* scripts still). Unfortunately I am going to need your help once more though, and that is for updating my wrapper.lua script.

Basically this script gives a whole bunch of different ways to further limit (or allow) how units are targeted. Several of the components can be dropped because of the new version, but most are still useful in determining if a unit is immune or susceptible.

My very simplistic idea is to just make each check a different variable (e.g. -nobleImmune MONARCH), but this would require a lot of different variables to be declared. Do you have any thoughts or ideas about a better way to handle this script?

[expwnent]

That's a much harder question. I'm not sure. Do you have any specific use cases in mind? I often fall into the habit of "overabstracting" and having lots of fancy interfaces that I never end up using.

[Roses]

Well it lets you do things like only triggering when your strength (or some other attribute, trait, skill, token) is higher/lower than the targets. Or allowing you to limit the effect to allowed syndrome classes (in vanilla there is only IT_CANNOT_HAVE_SYNDROME_CLASS). It also allows targeting based on more tokens than just what is available in vanilla (so you can target all creatures with FLIER or MEGABEAST or any tag you want).

In addition to allowing more customizable targeting, it also allows for more control over value inputs into scripts. So you can have an interaction that gives all local allies your strength (or any other) value, or gives all local allies a buff which is dependent on how many allies/enemies are around. You can even have an interaction that only nobles can do that increase the stats of nearby dwarves based on how skilled the noble is at LEADERSHIP or some other skill.

I currently use all of these in my own spell system, and it allows for a myriad of extra options that I am hoping to find a way to keep.

EDIT: I have finished updating my old scripts, minus the wrapper.lua and help sections. I will be adding those before I do an official release in my thread, but if you have time and feel like reading through someone elses code (I know how much fun that can be) you can find the scripts here. I still need to thoroughly test them all, but if you do find the time to look at them (no rush or even necessary really) and you have any suggestions let me know. I haven't quite settled on a naming convention, but basically you can tell exactly what the script affects from the name, and they are grouped by liked effects.

[expwnent]

One quick thing: please don't use tabs. Tabs are kind of evil and different text processors make them different widths so it's messy.

In custom-weather you can do things like "stype = args.flow or 'mist'" to avoid lots of if blocks.

For item-upgrade, if you specify on the command-line what to upgrade/downgrade to, then you could save yourself a lot of text processing and it would let raw modders name items however they want. Same for building-upgrade later once you do that.

For custom counters: this won't make it in the next version, but for the version after that I'll do a persistent binary data storage that will allow storing even fancy datatypes persistently to the save file without awkward histfig stuff. That should make this a lot easier: just register a map from unitIds to the value of the counter and it'll all just work.

---

Re: wrapper: Hm.

Maybe split it into sections.

Code: [Select]

blah -targets [ -caster -inRange 5 ] -targetsRequire [ -notNoble MONARCH -ageMin 2 -ageMax 8 ] -maxTargets 5
Then you'd do something like

Code: [Select]

local args = utils.processArgs({...}, validArgs)
args.targetsRequire = (args.targetsRequire and utils.processArgs(args.targetsRequire, validTargetRequireArgs)) or {}

This still doesn't allow for conditions that depend on the caster, like "must be same sex as the caster" or "must be within 3 years of caster's age". I guess you could fake it a bit with -sex \\CASTER_SEX but that wouldn't let you do the "within 3 years of age" thing. How important is that? Couldn't you just pass the caster's id to the script the does the effect and have it do the condition itself? I guess that wouldn't properly keep track of the number of affected targets for maxTargets though. Hmm...

I'll think about it some more. This should be enough to get you started.