Print

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

[Roses]

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.

Yeah, sorry, force of habit. My work insists on using tabs. Will switch to spaces.

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

Good call, I noticed this functionality after I was about half way through re-making the scripts, missed it in lots of cases though. I will go back through many of the scripts with defaults and get rid of the 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.

There is the option to specify on the command-line what to upgrade/downgrade to, I'm not really sure what the -upgrade and -downgrade options are there for, but I know I had an idea about them at one point.

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.

That will be nice. Right now its kind of just hacked together, but at least it works.

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.

That's a good idea to group them, I'll see what I can do.

EDIT: Updated my scripts with your suggestions, and added the help section to them.

EDIT2: Had a little bit of time today, so I figured I would just start at the basics of the wrapper.lua script. Uploaded a test version of the wrapper.lua script. It is a direct port from the current version to the new system, so is a bit ugly. We will call this version 0.1. (Not even going to try with a help section for this one until I finalize it).

[Roses]

For those of you wanting a concrete example of how this new method changes things here is an exact conversion:

The old method

Code: [Select]

[INTERACTION:SPELL_ELEMENTAL_FIRE_BURN]
[I_SOURCE:CREATURE_ACTION]
[I_TARGET:C:CREATURE]
[IT_LOCATION:CONTEXT_CREATURE]
[IT_MANUAL_INPUT:target]
[I_EFFECT:ADD_SYNDROME]
[IE_TARGET:C]
[IE_IMMEDIATE]
[SYNDROME]
[SYN_CLASS:\COMMAND]
[SYN_CLASS:spells/selected]
[SYN_CLASS:script@spells/addsyndrome]
[SYN_CLASS:args@SYNDROME_ELEMENTAL_FIRE_BURN;UNIT]
[SYN_CLASS:iclass@FIRE1;FIRE2;FIRE3;FIRE4;MAGIC_IMMUNE;MAGIC_RESIST]
[SYN_CLASS:isyndrome@MAGIC_IMMUNITY;RESIST_MAGIC;FIREWARD]
[SYN_CLASS:relfect@REFLECT_FIRE;REFLECT_ELEMENTAL;REFLECT_ALL]
[SYN_CLASS:silence@SILENCE_FIRE;SILENCE_ELEMENTAL:SILENCE_ALL]
[CE_SPEED_CHANGE:SPEED_PERC:100:START:0:END:1]
The new method

Code: [Select]

modtools/interaction-trigger -onAttackStr "casts burng" -command [wrapper -unitSource \\ATTACKER_ID -unitTarget \\DEFENDER_ID -iclass [FIRE1 FIRE2 FIRE3 FIRE4 MAGIC_IMMUNE MAGIC_RESIST] -isyndrome [MAGIC_IMMUNITY RESIST_MAGIC FIREWARD] -reflect [REFLECT_FIRE REFLECT_ELEMENTAL REFLECT_ALL] -silence [SILENCE_FIRE SILENCE_ELEMENTAL SILENCE_ALL] -script [add-syndrome -target !TARGET -syndrome burn] ]

[expwnent]

A quibble: because of the way processArgs works, you actually need [ and ] to have spaces around them to work properly.

[Roses]

Good to know, that would have caused me no end of frustration trying to figure out why it wasn't working.

[Roses]

So working on a new system that relies on kills, the way I have it working now is that it uses the eventuful onUnitDeath() and then checks for last attacker. I would prefer it to be automatic, like eventful, but I could work around making it triggered via reaction or syndrome. (ideally an unitUnitKill() would be the ultimate). Is there a better way to track kills? Is there an array that is stored in the unit that tracks the creature/caste that they have killed?

[expwnent]

I forget the details but I think that the unit attack event includes death strikes, but not when you hit someone and they bleed to death two seconds later.

[Roses]

Hmm, maybe I will have to play around with that and the onUnitDeath() last attacker and see what I can come up with. I wonder if the kill list that the game displays keeps track of fatal wounds (like dying from blood loss), or only handles actual death stikes. Maybe it even uses my system where it just has the attackers last ID and sets that as the killer.

For now last attacker will have to do.

A couple questions:
1. Since interaction-trigger triggers based on the VERB or TARGET_VERB is it possible to just have one blank interaction that is the basis for all interaction triggers and then just specify in the unit different VERBs for different effects? (i.e. eliminate all interactions that just run scripts)
2. add-syndrome now uses the name of the syndrome correct? Does that mean that for all of our syndromes added through scripts we can just put them all in a single inorganic and use different names?
3. What happens if you have two syndromes with the same name? Does it just take whichever syndrome it comes to first/last as the one to use?

And heres a suggestion, something I would like to see.
1. I know that right now with the way things are we can use multi-cmd and such to print announcements when we run scripts, but it would be much more friendly and clean if the *-trigger scripts had an extra argument for -announcement, that way we wouldn't have to worry about multi-cmd for something as simple as generating an announcement. I am planning on adding that functionality to all my scripts but thought that the trigger scripts would benefit most from the addition.

EDIT: I never know whether to post in this thread or the DFHack Unstable Beta thread. Which do you prefer me to post in?

[expwnent]

I'll think about the announcement thing.

Either thread is fine I guess.

I'm not sure what you mean about interaction-trigger.

Yes, the name of the syndrome. It picks the first one it finds if there's a duplicate. You can define the syndrome anywhere you want. Only the name is important.

[expwnent]

For the announcement thing I recommend that you make your own *-trigger2.lua scripts that do announcements and forward the rest of the arguments to the existing *-trigger.lua script. When it's possible to do as separate commands, it makes sense to logically separate them so that only one place has to be updated if it needs to be fixed. If you use one action frequently with a command, then writing a forwarder script shouldn't be too hard.

I'm not 100% sure if this is possible, but I had an idea for simplifying your wrapper script. You have a lot of different conditions for selecting a target, require this, require not that, etc. I'm pretty sure Lua scripts can "return" a value to whatever called the script, so if you do it just right then you should be able to separate out all the conditions into separate script files once dfhack.run_script is modified to return the return value of the script it runs. Basically, for each candidate, run all the condition scripts passing along the caster and target (and the spell if necessary), if the condition script returns definitelyYes then accept, definitelyNo then reject, maybe then keep running the other condition scripts (or however you want it to work). There would be a slight overhead, but Lua isn't fast in the first place and it could make your code a lot easier to maintain and extend. If you name your helper scripts based on the arguments the user actually passes that would make it even easier to call the helper scripts as external subroutines.

Basically you could have one small central file and many helper scripts in a subfolder instead of one monolithic script. It's almost always a bad idea to do it this way, but in your case I think it's worth it. Most of the time you should use Lua modules, but then you'd have to import many modules or have one monolithic module and that would defeat the purpose.

[Roses]

I like that idea for the wrapper script. It would certainly make it easier to update, maintain, and navigate. I quick search looks like the command require() can return an argument. So something like

Code: [Select]

if args.aclass then
 script = require('aclass')
 selected = script.checkClass(unit,args.aclass)Where aclass.lua has the function checkClass. It also might be possible to just pass the variable args directly as a global so that all you need is

Code: [Select]

if args.aclass then
 selected = require('aclass')I can see what is possible.

As for the interaction thing, I was thinking you could have one interaction like

Code: [Select]

[INTERACTION:SCRIPT_USE]
[I_SOURCE:CREATURE_ACTION]
[I_TARGET:C:CREATURE]
[IT_LOCATION:CONTEXT_CREATURE]
[IT_MANUAL_INPUT:target]
[I_EFFECT:ADD_SYNDROME]
[IE_TARGET:C]
[IE_IMMEDIATE]
[SYNDROME]
[CE_SPEED_CHANGE:SPEED_PERC:100:START:0:END:1]Then your creatures could have

Code: [Select]

[CAN_DO_INTERACTION:SCRIPT_USE]
[CDI:ADV_NAME:Burn]
[CDI:USAGE_HINT:ATTACK]
[CDI:TARGET:C:LINE_OF_SIGHT]
[CDI:TARGET_RANGE:C:15]
[CDI:MAX_TARGET_NUMBER:C:1]
[CDI:VERB:casts burn:casted burn:burnt]
[CDI:WAIT_PERIOD:50]

Code: [Select]

[CAN_DO_INTERACTION:SCRIPT_USE]
[CDI:ADV_NAME:Freeze]
[CDI:USAGE_HINT:ATTACK]
[CDI:TARGET:C:LINE_OF_SIGHT]
[CDI:TARGET_RANGE:C:15]
[CDI:MAX_TARGET_NUMBER:C:1]
[CDI:VERB:casts freeze:casted freeze:frozen]
[CDI:WAIT_PERIOD:50]Something like that. So you only need one interaction

EDIT: Another question I had is how the *-trigger scripts handle duplicates?

For instance if I had

Code: [Select]

modtools/reaction-trigger -reactionName TURN_INTO_CHICKEN -command shape-change -target \WORKER_ID -creature CREATURE_CHICKEN
modtools/reaction-trigger -reactionName TURN_INTO_CHICKEN -command substituteThenRunLua "df.unit.find(<unitId>).flags1.dead = 1" unitId \UNIT_IDWould it run both if I ran the reaction TURN_INTO_CHICKEN?

What about

Code: [Select]

modtools/item-trigger -itemType ITEM_WEAPON_SPEAR -onEquip -command [ devel/printArgs "spear equipped" ]
modtools/item-trigger -material INORGANIC:GOLD -command [ devel/printArgs "gold item equipped!" ] -onEquipWould it print out both if I equipped a gold spear?

[expwnent]

It only looks at the attack/defend verbs, so that should work fine.

Duplicates are triggered in the order that they are registered, but don't rely on the specific order. If there's a dependency, just register one and make it forward the trigger to the others in the proper order. Ignoring a few issues with backslashes and [ ] those examples should work the way you expect.

Moving the stuff to a module would certainly help. If you do it just right you'll only have to update the main script in one place to deal with new conditions. Probably. Except for documentation.

Be careful with backslashes. The first backslash is to escape backslashes, [, ], and -. "\\" is passed as "\" to the script. In those examples, those should all be double backslashes. Single backslashes are for things like "-health \-1" -> args.health = '-1'.

[Roses]

Duplicates are triggered in the order that they are registered, but don't rely on the specific order. If there's a dependency, just register one and make it forward the trigger to the others in the proper order. Ignoring a few issues with backslashes and [ ] those examples should work the way you expect.

I was more thinking as a way to run two commands, that aren't linked, instead of using multi-cmd (for readability). I doubt I will use multiple lines like that, but was just wondering if it is possible.

Moving the stuff to a module would certainly help. If you do it just right you'll only have to update the main script in one place to deal with new conditions. Probably. Except for documentation.

Yeah, I have started moving it over to modules, but got side tracked by the class system I am working on. So far it is looking much nicer.

Be careful with backslashes. The first backslash is to escape backslashes, [, ], and -. "\\" is passed as "\" to the script. In those examples, those should all be double backslashes. Single backslashes are for things like "-health \-1" -> args.health = '-1'.

Those were all just copied from earlier in the thread before the syntax was finalized, but I will make sure to keep an eye out for that in my stuff.

[milo christiansen]

Reading through it is hard to tell if the old eventful "LUA_HOOK" reactions will still work.
Please say yes, Rubble uses them for almost all DFHack related workshop addons and it would be cumbersome to try to move all the functionality to commands.

[Roses]

As far as I am aware LUA_HOOK will still be a thing, but we, as modders and scripters should move over the new system wherever possible. I am planning on migrating most of my LUA_HOOK scripts to the new system since it will allow more features and eliminates the need for special inorganics. There are a couple that don't require and inorganics or have no need for new features that I will, for now, be keeping under LUA_HOOK, but eventually I will probably abandon it completely since it works on a poor system that doesn't run if there are no products, and runs multiple times for each product created.

[milo christiansen]

LUA_HOOK is IMHO MUCH better than needing a command for everything, using commands is far more work for no gain in cases where you need heavy duty Lua logic for only one reaction.

I suppose they compliment each other, at least the new way is better than autoSyndrome