Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 21 22 [23] 24 25 ... 42

Author Topic: [DFHack] Roses' Script Collection Updated 5/4/15  (Read 125437 times)

Roses

  • Bay Watcher
    • View Profile
Re: DFHack Spells (updated 9/1/14)
« Reply #330 on: September 22, 2014, 03:32:04 pm »

Question for those that might be interested in using the "Civilization" scripts.

It is currently possible to add metals to entities (they will show up to trade bars of said metal), but the flags for what metals they can make armor/weapons out of are seperate from just having access to the metal. Presumably this means you could have a civ that only ever trades steel weapons, but can't trade steel bars, or vice-versa.

The question is, should I keep these separate, or should I make it that if you give a civ access to steel, it not only gives them access to the bars, but also weapons and armor made of steel?

What this means functionally is the difference between
Code: [Select]
[LEVEL_ADD:INORGANIC:METAL:STEEL]vs
Code: [Select]
[LEVEL_ADD:INORGANIC:METAL:STEEL]
[LEVEL_ADD:ITEM_METAL:WEAPON:STEEL]
[LEVEL_ADD:ITEM_METAL:ARMOR:STEEL]
[LEVEL_ADD:ITEM_METAL:AMMO:STEEL]
[LEVEL_ADD:ITEM_METAL:PICK:STEEL]
[LEVEL_ADD:ITEM_METAL:RANGED:STEEL]
[LEVEL_ADD:ITEM_METAL:ANVIL:STEEL]

Thoughts?

As for an update, I am thinking by October 1st I will have a working civilization system and preliminary events, if things go really well I will have a preliminary journal system as well.
Logged

TheDorf

  • Bay Watcher
    • View Profile
Re: DFHack Spells (updated 9/1/14)
« Reply #331 on: September 23, 2014, 10:25:12 am »

Question for those that might be interested in using the "Civilization" scripts.

It is currently possible to add metals to entities (they will show up to trade bars of said metal), but the flags for what metals they can make armor/weapons out of are seperate from just having access to the metal. Presumably this means you could have a civ that only ever trades steel weapons, but can't trade steel bars, or vice-versa.

The question is, should I keep these separate, or should I make it that if you give a civ access to steel, it not only gives them access to the bars, but also weapons and armor made of steel?

What this means functionally is the difference between
Code: [Select]
[LEVEL_ADD:INORGANIC:METAL:STEEL]vs
Code: [Select]
[LEVEL_ADD:INORGANIC:METAL:STEEL]
[LEVEL_ADD:ITEM_METAL:WEAPON:STEEL]
[LEVEL_ADD:ITEM_METAL:ARMOR:STEEL]
[LEVEL_ADD:ITEM_METAL:AMMO:STEEL]
[LEVEL_ADD:ITEM_METAL:PICK:STEEL]
[LEVEL_ADD:ITEM_METAL:RANGED:STEEL]
[LEVEL_ADD:ITEM_METAL:ANVIL:STEEL]

Thoughts?

As for an update, I am thinking by October 1st I will have a working civilization system and preliminary events, if things go really well I will have a preliminary journal system as well.

While I personally haven't used any DFHack scripts in mods yet, I believe having more options is generally better. Now, I'm pretty clueless here, but wouldn't it be possible to make yet another token that essentially works like all of them, but still keeping the possibility to just give them access to parts of it?




On an unrelated note: How would I go about using your scripts in interactions? The ones that are for reactions come with examples, so I think I understand how I would go about using them, but I'm clueless about the createitem script. If anyone could come with an example of an interaction that uses the script, that'd be awesome. :D
Logged
I love this community. Somebody asks "hay guise how do i tame shark", and then everybody is like "why don't we fling sharks at things with complex mechanical devices?".

Roses

  • Bay Watcher
    • View Profile
Re: DFHack Spells (updated 9/1/14)
« Reply #332 on: September 23, 2014, 10:47:37 am »

I agree, I think more options are better, I suppose I could include a tag that would add all of them, I don't think it would be that much more work.

Unfortunately my old help readme is out of date. The new system uses the onLoad.init, so what you need to do is put these in your onLoad.init in the raws folder.

for reactions
Code: [Select]
modtools/reaction-trigger -reactionName NAME_OF_REACTION -command [ insert command information here ]
for interactions
Code: [Select]
modtools/interaction-trigger -onAttackStr CDI:VERB_GOES_HERE -command [ insert command information here ]
So for the create item script
Code: [Select]
modtools/interaction-trigger -onAttackStr "summons a steel sword" -command [ item/create -unit \\ATTACKER_ID -item WEAPON:ITEM_WEAPON_SWORD -mat STEEL -inventory ]
Would go with an interaction that has the [CDI:VERB:summons a steel sword:whatever you want:whatever you want]

EDIT: I do plan on creating another readme with up to date information, but alas it is still low on my to-do list.
« Last Edit: September 23, 2014, 10:54:03 am by Roses »
Logged

TheDorf

  • Bay Watcher
    • View Profile
Re: DFHack Spells (updated 9/1/14)
« Reply #333 on: September 23, 2014, 06:33:43 pm »

I agree, I think more options are better, I suppose I could include a tag that would add all of them, I don't think it would be that much more work.

Unfortunately my old help readme is out of date. The new system uses the onLoad.init, so what you need to do is put these in your onLoad.init in the raws folder.

for reactions
Code: [Select]
modtools/reaction-trigger -reactionName NAME_OF_REACTION -command [ insert command information here ]
for interactions
Code: [Select]
modtools/interaction-trigger -onAttackStr CDI:VERB_GOES_HERE -command [ insert command information here ]
So for the create item script
Code: [Select]
modtools/interaction-trigger -onAttackStr "summons a steel sword" -command [ item/create -unit \\ATTACKER_ID -item WEAPON:ITEM_WEAPON_SWORD -mat STEEL -inventory ]
Would go with an interaction that has the [CDI:VERB:summons a steel sword:whatever you want:whatever you want]

EDIT: I do plan on creating another readme with up to date information, but alas it is still low on my to-do list.
Yeah, if you have the opportunity to add functionality that might be requested at a later date without tons of extra work, I think it will be worth it. :)


Thank you! I think the spells I've set up should work now. :)

I realize that you're most probably a busy person, but if you have the time, it'd be greatly appreciated if you could lend a hand understanding how to use the wrapper script with the new init files. Obviously not all of it, seeing as it all seems quite complicated, but if you could post an example that uses the wrapper to launch 2 scripts at the same time, that would be awesome. Just so that I can see what the syntax is like, pretty much. :)


At any rate, I really want to say "Thank you". These scripts seem really amazing, and I'm really looking forward to learning how to use them all! :)

Edit: How come it's item/create when the script is called createitem.lua? Stuff like this confuses me O_o
« Last Edit: September 23, 2014, 06:45:07 pm by TheDorf »
Logged
I love this community. Somebody asks "hay guise how do i tame shark", and then everybody is like "why don't we fling sharks at things with complex mechanical devices?".

Roses

  • Bay Watcher
    • View Profile
Re: DFHack Spells (updated 9/1/14)
« Reply #334 on: September 23, 2014, 07:24:39 pm »

If you have createitem.lua you are using an older version of the scripts.
Logged

TheDorf

  • Bay Watcher
    • View Profile
Re: DFHack Spells (updated 9/1/14)
« Reply #335 on: September 23, 2014, 07:41:59 pm »

If you have createitem.lua you are using an older version of the scripts.

Silly me :x Downloaded the new version of the scripts now. So any dashes in file names are replaced by slashes?

Does the wrapper.lua script call the others as required? Or was the wrapping made more complex with the new scripts?

Anyway, I've experimented a little bit with the wrapper but can't seem to be able to get it to work. I've put the following in dfhack.init:
Code: [Select]
modtools/interaction-trigger -onAttackStr "are surrounded by a barrage of ice" -command [wrapper -script@special/falling -args@unit\\DEFENDER_ID;item BOULDER;mat STEEL;number 1; height 15 -plan@9x9_O -center@false -delay@10 -chain@7 -maxtargets@3]
But it says I'm passing invalid arguments. At the moment, DFHack is whining about the first argument, "script@special/falling". :s

...\hack\lua\utils.lua:595: error: invalid arg: 5: script@special/falling

Edit: I've also tried
Code: [Select]
modtools/interaction-trigger -onAttackStr "are surrounded by a barrage of ice" -command [wrapper -script special/falling -args [-unit \\DEFENDER_ID -item BOULDER -mat STEEL -number 1 -height 15] -plan 9x9_O -center false -delay 10 -chain 7 -maxtargets 3]
Which seems sensible to me after reading a bit in the utils.lua script. This doesn't work either, though, and gives me the same error.

...\hack\lua\utils.lua:595: error: invalid arg: 5: script
« Last Edit: September 23, 2014, 08:01:47 pm by TheDorf »
Logged
I love this community. Somebody asks "hay guise how do i tame shark", and then everybody is like "why don't we fling sharks at things with complex mechanical devices?".

Roses

  • Bay Watcher
    • View Profile
Re: DFHack Spells (updated 9/1/14)
« Reply #336 on: September 23, 2014, 08:40:43 pm »

You need spaces before and after all [

Code: [Select]
modtools/interaction-trigger -onAttackStr "are surrounded by a barrage of ice" -command [ wrapper -script [ special/falling -unit \\DEFENDER_ID -item BOULDER -mat STEEL -number 1 -height 15 ] -plan 9x9_O -center false -delay 10 -chain 7 -maxtargets 3 ] *should* work
Logged

TheDorf

  • Bay Watcher
    • View Profile
Re: DFHack Spells (updated 9/1/14)
« Reply #337 on: September 23, 2014, 09:38:05 pm »

You need spaces before and after all [

Code: [Select]
modtools/interaction-trigger -onAttackStr "are surrounded by a barrage of ice" -command [ wrapper -script [ special/falling -unit \\DEFENDER_ID -item BOULDER -mat STEEL -number 1 -height 15 ] -plan 9x9_O -center false -delay 10 -chain 7 -maxtargets 3 ] *should* work


Thank you, I really appreciate it! Thank you for the awesome scripts - now I'm off to create a few awesome spells :D



Edit: Ran into some more trouble while trying to create my awesome spells :c I put it all in a spoiler not to steal too much space, but if anyone has time to help, it'd be greatly appreciated. c:
Spoiler (click to show/hide)
« Last Edit: September 24, 2014, 08:42:23 am by TheDorf »
Logged
I love this community. Somebody asks "hay guise how do i tame shark", and then everybody is like "why don't we fling sharks at things with complex mechanical devices?".

Roses

  • Bay Watcher
    • View Profile
Re: DFHack Spells (updated 9/1/14)
« Reply #338 on: September 24, 2014, 11:54:45 pm »

Hmm, don't have time to look into it now, but I assume since you didn't mention it, DFHack isn't spitting out any errors? If that is the case it is most likely something wrong on my end, I will look at it soon.
Logged

TheDorf

  • Bay Watcher
    • View Profile
Re: DFHack Spells (updated 9/1/14)
« Reply #339 on: September 25, 2014, 05:27:40 am »

Hmm, don't have time to look into it now, but I assume since you didn't mention it, DFHack isn't spitting out any errors? If that is the case it is most likely something wrong on my end, I will look at it soon.

Once every time I run DF, it seems to throw an error saying "Too few actors". I really just can't get it to work, I've tried everything that seems reasonable to me.
Logged
I love this community. Somebody asks "hay guise how do i tame shark", and then everybody is like "why don't we fling sharks at things with complex mechanical devices?".

Putnam

  • Bay Watcher
  • DAT WIZARD
    • View Profile
Re: DFHack Spells (updated 9/1/14)
« Reply #340 on: September 25, 2014, 05:29:47 am »

That error doesn't actually break anything, it's just a notification.

expwnent

  • Bay Watcher
    • View Profile
Re: DFHack Spells (updated 9/1/14)
« Reply #341 on: September 25, 2014, 11:51:17 am »

It indicates that it failed to detect an attacker and a defender for an interaction.
Logged

Roses

  • Bay Watcher
    • View Profile
Re: DFHack Spells (updated 9/1/14)
« Reply #342 on: September 25, 2014, 12:21:12 pm »

@expwnent: Does interaction-trigger work in the arena?

There are definitely some errors on my part, but even after fixing them and trying to test these interactions the scripts just aren't triggering. Does onLoad.init not work in the arena? I'm stumped. I tested things with the command line, not the triggers so I am new to all this.

EDIT: Yeah, I'm not sure what is going on, simply replacing \\ATTACKER_ID and \\DEFENDER_ID with the actual unit id numbers and running via command line shows that the scripts are working (i.e. I can make a unit fling a spear, or conjure a dagger), but when placed in interaction-trigger they don't seem to be working.

EDIT2: @TheDorf: This is an embarrassment on my end. I seem to have uploaded a half-way version to my github, everything is the same except the "special" scripts (I really need to think of a better word) are not like the others (i.e. they are still special- and not special/ ) but even with the non-half-way version they still aren't working. (See above) For now you can just replace the special/falling and special/projectile with special-falling and special projectile. Or you can download the new version from GitHub or DFFD. Sorry!
« Last Edit: September 25, 2014, 12:59:27 pm by Roses »
Logged

TheDorf

  • Bay Watcher
    • View Profile
Re: DFHack Spells (updated 9/1/14)
« Reply #343 on: September 26, 2014, 06:31:27 am »

@expwnent: Does interaction-trigger work in the arena?

There are definitely some errors on my part, but even after fixing them and trying to test these interactions the scripts just aren't triggering. Does onLoad.init not work in the arena? I'm stumped. I tested things with the command line, not the triggers so I am new to all this.

EDIT: Yeah, I'm not sure what is going on, simply replacing \\ATTACKER_ID and \\DEFENDER_ID with the actual unit id numbers and running via command line shows that the scripts are working (i.e. I can make a unit fling a spear, or conjure a dagger), but when placed in interaction-trigger they don't seem to be working.

EDIT2: @TheDorf: This is an embarrassment on my end. I seem to have uploaded a half-way version to my github, everything is the same except the "special" scripts (I really need to think of a better word) are not like the others (i.e. they are still special- and not special/ ) but even with the non-half-way version they still aren't working. (See above) For now you can just replace the special/falling and special/projectile with special-falling and special projectile. Or you can download the new version from GitHub or DFFD. Sorry!

No worries, just happy to help with noticing bugs etc. :) Thank you for looking into it - now I don't have to feel like a complete idiot who doesn't even manage to launch scripts with the help of the author xD

Logged
I love this community. Somebody asks "hay guise how do i tame shark", and then everybody is like "why don't we fling sharks at things with complex mechanical devices?".

Roses

  • Bay Watcher
    • View Profile
Re: DFHack Spells (updated 9/1/14)
« Reply #344 on: September 29, 2014, 10:45:25 am »

Figured I would put up a little "guide" to the wrapper script, and how to use it.

The main function of wrapper.lua is to be able to select targets for interactions with more options than provided by the in-game system. The basic structure of the command to use the script is
Code: [Select]
wrapper -userSource UNIT_ID -userTarget UNIT_ID -script [ script information goes in here, see examples below ] These are the only required inputs, where -userSource is the unit doing the interaction and -unitTarget is the target unit that is first receiving the interaction (i.e. the target that the game first picks out when running an interaction).

For an example, lets look at a simple projectile script.
Code: [Select]
modtools/interaction-trigger -onAttackStr "shoots a bolt of steel" -command [ special/projectile -unit_source \\ATTACKER_ID -unit_target \\DEFENDER_ID -item AMMO:ITEM_AMMO_BOLTS -mat STEEL -number 1 ]This will cause the unit performing the interaction to "shoot" a steel bolt at the target. For the exact same results using the wrapper script we would use.
Code: [Select]
modtools/interaction-trigger -onAttackStr "shoots a bolt of steel" -command [ wrapper -unitSource \\ATTACKER_ID -unitTarget \\DEFENDER_ID -script [ special/projectile -unit_source !SOURCE -unit_target !TARGET -item AMMO:ITEM_AMMO_BOLTS -mat STEEL -number 1 ] ]Notice that the -unit_source and -unit_target have changed now that they are inside the wrapper's -script. This is an important change, because it allows for some of the more interesting options that I will mention later.

So far we haven't gained anything from using the wrapper script. Both of the above examples will preform exactly the same. So now let's talk about what makes the wrapper script so useful. Options! The following is a list of currently available options;
Code: [Select]
-chain
-maxtargets
-delay
-value
-radius
-target
-aclass
-acreature
-asyndrome
-atoken
-iclass
-icreature
-isyndrome
-itoken
-physical
-mental
-skills
-traits
-age
-speed
-noble
-profession
-entity
-reflect
-silence
-counters
-plan
-center

You can basically split all of these options into four categories, Number Based, Token Based, Target Manipulation, and Script Manipulation

1. Number Based
The number based options are
Code: [Select]
-age
-speed
-physical
-mental
-skills
-traits
Each of these options has the requirements min, max, greater, less. Min and max are straight forward, they tell the script that for a target to be acceptable they must have a minimum or maximum amount of a certain type.
Greater and less perform slightly differently. They take the ratio unitSource/unitTarget and compare it to a given value. Examples to follow

These can further be broken down into two separate groups

i. No sub-types
These are -age and -speed. They don't have any sub-types associated with them and so have the format
Code: [Select]
-age min:10This means that the script will only accept the target if it is older than 10. Multiple requirements for the same option can be included for more configuration. For example
Code: [Select]
-age [ min:10 max:20 ]This will only accept the target if they are older than 10 but less than 20 years old.
ii. Sub-Types
The rest of the number based options all require an additional input of a sub-type. This takes the form
Code: [Select]
-physical STRENGTH:min:2000Which should be fairly straightforward. So, for instance, if you would like an interaction to affect the target only if the user is twice as strong as the target you would use
Code: [Select]
-physical STRENGTH:less:0.5Or only if the user is at least as strong as the target, and the target isn't super tough
Code: [Select]
-physical [ STRENGTH:less:1 TOUGHNESS:max:2000 ]The possibilities are endless (ok not actually endless, but there are a LOT of possibilities). A full list of sub-types for each option is available on my github

Token Based
The token based options are
Code: [Select]
-aclass
-acreature
-asyndrome
-atoken
-iclass
-icreature
-isyndrome
-itoken
-noble
-profession
-entity
These can further be broken up into two groups

i
-noble, -profession, and -entity all require an additional input, namely 'required' or 'immune'. So to make an interaction that can only target your leader you would use
Code: [Select]
-noble required:MONARCHNothing particularly fancy about these. Just like the number based options, multiple specifications can be placed, so if you would only like an interaction to target carpenters or masons
Code: [Select]
-profession [ required:CARPENTER required:MASON ]
ii
The rest do not need the 'required' or 'immune' designation, as it is already built into their function (this was done for several reasons that I would be happy to discuss with people, but for now it is just how it is). As you can probably guess all of the i* options are the immune versions, and the a* options are the required (or allowed as the a stands for in this case) versions.

-aclass and -iclass check the units [CREATURE_CLASS:] tokens and subsequently allow or deny a creature to be targeted. They can be invoked by using
Code: [Select]
-aclass GENERAL_POISON
-acreature and -icreature check the actual creature and caste to see if the unit can be targeted. They are used with
Code: [Select]
-icreature [ DRAGON:MALE DRAGON:FEMALE ]
-asyndrome and -isyndrome check for any actives syndromes [SYN_CLASS]. Used just the same as -aclass and -iclass.

-atoken and -itoken, these are probably one of the more interesting options, they check the unit for a myriad of a number of tokens ranging from FLIER to MEGABEAST to AMPHIBIAN, basically anything that is specified as a single token in the creatures raws. A full list of supported tokens can be found on my github.

Note that none of these options are required in any way, and the logic behind using them is the same as the in-game logic behind the ALLOWED and IMMUNE options in interactions.

** There is another token based option that just needs a little bit more work/testing before it is implemented, and that is body checking. Basically it will be possible to check if a creature has a tail, or horns, or whatever you want, and will allow a spell to only target them/not target them based on these parts. (For instance you could have an interaction that a creature with a shell is immune to, or one that requires the target to have a stinger, and if the stinger is cut off, the creature is no longer targetable)

Target Manipulation
Now we get into the more advanced options. These options are
Code: [Select]
-radius
-plan
-maxtargets
-target
-reflect
-silence
Each one is fairly different, so lets take them one at a time.

-radius allows for selecting multiple targets in a given area around the -unitTarget. This means that you could have all units within 10 tiles, all units in a single square, or all units in a line be effected. The default value for this is -1,-1,-1 which means just the -unitTarget is effected. Change this by using
Code: [Select]
-radius 10,10,0Which, as you might guess, is the radius around which a unit can be affected (in the typical x,y,z coordinates).

-plan functions similarly to -radius but allows for more interesting shapes. It requires an external text file, located in the hack/scripts folder, for instance my example allows units within an X pattern of the -unitTarget to be affected. 0's mean not allowed, 1's are allowed, and the 'X' is the location of the -unitTarget. Note that this currently only supports the current z-level of the -unitTarget
Code: (5x5_X.txt) [Select]
1,0,0,0,1,
0,1,0,1,0,
0,0,X,0,0,
0,1,0,1,0,
1,0,0,0,1
This option is invoked by using
Code: [Select]
-plan 5x5_X
-maxtargets is useable with -radius and -plan to limit the number of targets that can be selected. If no -maxtargets option is selected, all the targets found will be targeted, otherwise a random sample, the size of -maxtargets will be selected from the list of available targets. This option is used by specifying
Code: [Select]
-maxtargets 10
-target is a rather difficult to use option, I have altered the logic behind this option more times than I can count, and am still not entirely happy with it. The gist of the option is to allow configurable targeting based on the relationship between the -unitSource and -unitTarget. The valid options for -target are
Code: [Select]
invasion
civ
population
race
sex
caste
enemy
Which, if you know how DFHack structures are enumerated you will see that there are id numbers associated with each creature for each of these options (except for enemy, which is basically just the inverse of civ).
Code: [Select]
-target civThis would mean that only creatures that have the same civ_id as the -unitSource are eligible for targeting. More work needs to be done on this option, but for now these are the only options available.

-reflect and -silence both take [CREATURE_CLASS] and [SYN_CLASS] tokens as their arguments, but check differently.

-reflect checks the -unitTarget's creature classes and any active syndrome classes, and if any are found to match the given token the -unitTarget will be changed to be the -unitSource, and as long as the -unitSource passes the other options, the script will treat the -unitSource as the -unitTarget and the -unitTarget as the -unitSource (for functions where both are needed to be different, like special/projectile). An example would be;
Code: [Select]
-reflect [ REFLECT_FIRE REFLECT_ELEMENTAL REFLECT_ALL ]
-silence checks the -unitSource's creature classes and any active syndrome classes, and if any are found to match the given token the interaction simple won't be cast, effectively "silencing" the unit (or disabling if you prefer not to think of the classic magic system).
Code: [Select]
-silence SILENCE_ALL
Script Manipulation
The final group of options are, possibly, the most unique.
Code: [Select]
-chain
-center
-delay
-value

-chain allows for "chaining" of spells. By default spells do not chain (i.e. -chain 0), but say you want the steel bolt from the above examples to hit the first target and then hit another target (from the acceptable target list) you would use
Code: [Select]
-chain 1Note that this means you MUST HAVE a -radius or -plan option specified, otherwise it will just continually hit the same target (as there is no one else to chain to). Also note that by default this example
Code: [Select]
-radius 5,5,5 -chain 1Will hit all units within a block of 5x5x5 around the target AND then each one of those will chain to another target (thus if there are 5 illegible units it will target all 5, then each of those 5 will chain to a new set of units within 5x5x5 of them). To change this behavior so that it still checks the targets in range, but only actually hits the -unitTarget, you must use the -center option, so that
Code: [Select]
-radius 5,5,5 -chain 1 -centerWould only hit the -unitTarget and then select a random unit from those otherwise illegible to hit next.

-center forces the script to ignore any previous options and only target the -unitTarget (note that it still keeps a list of otherwise illegible targets for use in other options, like -chain).

-delay simply delays the effect of the script by a specified amount of in-game ticks.
Code: [Select]
-delay 100This would tell the wrapper script to calculate all of the illegible targets now, but wait to apply the actual affect for 100 ticks.

-value, this is personally my favorite option, and probably the most complex. It effectively allows you to pass different arguments to scripts based on the units targeted and unit using the interaction. My go-to example is if you want your warrior to have a "battle shout" type ability that gives their willpower to all nearby friendly units you can do it with this option.

To break it down, this option required four different specifications

TYPE:SUB_TYPE:VALUE:OFFSET

There are 4 valid types stacking, destacking, self, and target. Stacking and destacking form one group of types and self and target form another.

Valid sub types for stacking and destacking are; total, allowed, and immune
Valid sub types for self and target are; strength, agility, endurance, toughness, resistance, recuperation, analytical, focus, willpower, creativity, intuition, patience, memory, linguistic, spatial, musicality, kinesthetic, empathy, social, web, stun, winded, unconscious, pain, nausea, dizziness, paralysis, numbness, fever, exhaustion, hunger, thirst, sleep, infection, and blood

Stacking and destacking work by checking the targets list and manipulating the value based on the number of targets. It starts with the given value and increases it by the offset. So, for example, if you wanted to give a value of 100 + 10 for each creature targeted you would use
Code: [Select]
-value stacking:allowed:100:10destacking works the same way, except it decreases the value by the offset instead of increases.

Self and target work by taking the -unitSource or -unitTarget's value for a given sub type, taking a percentage of that value and then increasing or decreasing it by a given offset. Thus, to give the unit the same willpower as the -unitSource you would do
Code: [Select]
-value self:willpower:100:0Or to take the targets strength
Code: [Select]
-value target:strength:100:0
Then anywhere you put !VALUE in the command line, it would be replaced by these calculations.

Those are all the "basic" options (I list them as "basic" only because they are all fairly straight forward). There is also the "special" option; -counters, this allows for scripts to be triggered only once certain conditions are met. And is to be used in conjunction with the special/counters script. See the -help documentation for that script to understand the use of the -counters option.

EXAMPLES:
Ok, now that was a lot of information. So how about some examples! Let's take our original example
Code: [Select]
modtools/interaction-trigger -onAttackStr "shoots a bolt of steel" -command [ wrapper -unitSource \\ATTACKER_ID -unitTarget \\DEFENDER_ID -script [ special/projectile -unit_source !SOURCE -unit_target !TARGET -item AMMO:ITEM_AMMO_BOLTS -mat STEEL -number 1 ] ]And add some options to it

Code: [Select]
modtools/interaction-trigger -onAttackStr "shoots a bolt of steel" -command [ wrapper -unitSource \\ATTACKER_ID -unitTarget \\DEFENDER_ID -script [ special/projectile -unit_source !SOURCE -unit_target !TARGET -item AMMO:ITEM_AMMO_BOLTS -mat STEEL -number 1 ] -radius 3,3,0 -maxtargets 5 ]Now it will shoot a steel bolt at up to 5 targets within a 3x3x0 block around the target. But this includes friendly units too! Well I don't want that so I use
Code: [Select]
modtools/interaction-trigger -onAttackStr "shoots a bolt of steel" -command [ wrapper -unitSource \\ATTACKER_ID -unitTarget \\DEFENDER_ID -script [ special/projectile -unit_source !SOURCE -unit_target !TARGET -item AMMO:ITEM_AMMO_BOLTS -mat STEEL -number 1 ] -radius 3,3,0 -maxtargets 5 -target enemy ]Now, instead, I want to just shoot one bolt, but have it chain to one of the 5 targets
Code: [Select]
modtools/interaction-trigger -onAttackStr "shoots a bolt of steel" -command [ wrapper -unitSource \\ATTACKER_ID -unitTarget \\DEFENDER_ID -script [ special/projectile -unit_source !CENTER -unit_target !TARGET -item AMMO:ITEM_AMMO_BOLTS -mat STEEL -number 1 ] -radius 3,3,0 -maxtargets 5 -target enemy -chain 1 -center ]Notice that I added -center, but I also changed !SOURCE to !CENTER. This means that the script knows the bolt should go from the source to the target, then from the target to the new, chained, target. If I had left !CENTER as !SOURCE it would have, instead, shot a bolt from the source to the target and then another from the source to the new target.

Now, what if I want to shoot a number of arrows, and a single target, based on the number of allies around the unit?
Code: [Select]
modtools/interaction-trigger -onAttackStr "shoots a bolt of steel" -command [ wrapper -unitSource \\ATTACKER_ID -unitTarget \\DEFENDER_ID -script [ special/projectile -unit_source !SOURCE -unit_target !TARGET -item AMMO:ITEM_AMMO_BOLTS -mat STEEL -number !VALUE ] -radius 3,3,0 -maxtargets 5 -center -target civ -value stacking:allowed:0:1 ]
Ok, so there are some offensive examples, but what about defensive examples? How about my above mentioned example of giving willpower to all nearby friendly units.
Code: [Select]
modtools/interaction-trigger -onAttackStr "shouts a rallying battle cry" -command [ wrapper -unitSource \\ATTACKER_ID -unitTARGET \\ATTACKER_ID -script [ unit/attribute-change -unit !TARGET -set !VALUE -mental WILLPOWER -dur 1200 ] -radius 5x5x0 -value self:willpower:100:0 -target civ ]Simple really!

I think that is enough information for now. Hopefully this is useful for people attempting to use the wrapper script, I know it can seem very daunting, but please feel free to ask, and please, post any of your uses here so people have more examples to look at.
Logged
Pages: 1 ... 21 22 [23] 24 25 ... 42