Print

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

[IndigoFenix]

Turns out that the propel script can, in fact, propel creatures upward.  The mistake I was making was in not realizing that they can collide with the top z-level.  So it looked like they were exploding against the ground, while in fact they were exploding against the nearby sky.

[Roses]

Turns out that the propel script can, in fact, propel creatures upward.  The mistake I was making was in not realizing that they can collide with the top z-level.  So it looked like they were exploding against the ground, while in fact they were exploding against the nearby sky.

Interesting, so you can't give a unit a positive z velocity with an x or y velocity and have them move across the map?

On a different note, I am going to add the ability to check for professions and positions in my various scripts (I am also going to make an external script that will have all of the various checks in it that can be referenced by others if they wish). A question though, so far I check for creatures classes, caste classes, specific creature/caste, syndrome classes, tokens, and now professions and positions. Are there any other checks people would like to see? Some basic thoughts, I could add a gender check, an age check, a training level check, a body part check, a size check, a temperature check, a skill level check, an attribute level check, and probably several more. Any that sound like something people would want? (I was thinking you could add an entangle like spell that had an agility check or something, if a creature has enough agility it avoids the webs or something)

[Meph]

Age sounds nice, because you can simulate old age. If age is 50% of creature maxage, do this, if age is 80% of maxage add shortsightedness and lower physical attributes, if age is 90% of maxage, more nerfs... this way younger dwarves are stronger and better suited for heavy labor and fighting.

Skill level: Could add new abilities to workers, for example legendary miners are immune to black lung/coal dust. Many possibilities here.

Can you do noble position? If unit is noble X, unit gets ability X. This would allow to make special nobles in total conversions a lot more interesting, like my four riders of the apocalypse in Warlock mode.

[Putnam]

1. You can even make it time to death-by-old-age as opposed to maxage in general.

2. Yep.

3. Yep.

[Roses]

Yeah, like Putnam said, all of that is possible. Maybe I will just add a whole bunch of different things, then if people want different things they can request them. It is fairly simple to add these checks anyway, and with my new external check I only have to modify one file instead of altering every script.

[Roses]

The new selections script is now more robust then ever, it checks for

• Distance from a unit (in x, y, and z)
• Relation to a unit (civ and population ids)
• Creature Class (both required and immune)
• Creature and Caste (both required and immune)
• Syndrome Class (both required and immune)
• Creature Tokens, not just the ones from the IT_REQUIRES, but all tokens specified in the raws (both required and immune)
• Age (both min and max)
• Movement Speed (both min and max)
• Physical Attributes (both min and max)
• Mental Attributes (both min and max)
• Traits, like Anxiety (both min and max)
• Skill Levels (both min and max)
• Noble Positions (both required and immune)
• Professions, this can also affect babies and children, anything found here (both required and immune)

The format for using these checks is [SYN_CLASS:physical@min;STRENGTH;2000,max;STRENGTH;3000,min;AGILITY;4000], the "@" symbol is used to determine which type of check, the "," is used to distinguish multiple checks of the same type, and the ";" is used to separate the internal designations.

I will be updating all of my previous scripts to handle these new checks, and also providing examples of how each works. Are there any other checks that people would like to see?

[Meph]

Roses: I dont even...

Thats pretty much the biggest addition since interactions to DF, because with this many checks you can write about anything. I usually try to write a feature using the newest scripts to show other people how its done and add more content to MDF (sometimes even causing bloat that I have to reduce later), but with this I wouldnt even know where to start. I could spend a month just using this to write an entire guild system based on nobles, professions, skill level and attributes...

[Roses]

Glad you like it, now if only I could get the self targeting attack interactions to work I could finally finish my magic/ability system. I am still testing each check individually and in groups to make sure the logic is working correctly. I will post the script, and a detailed description of the allowed values, tomorrow.

[Roses]

selected.lua -

The function expects 3 inputs. isSelected(unit,unitTarget,args).

unit is a reference unit (not the ID but the actual unit table), only important for checking radius and target affects.
unitTarget is the unit you wish to make the various checks on, can be the same as unit
args is a list of arguments, can be taken directly from the autoSyndrome or syndromeTrigger inputs

Note, the above is only important if you wish to use this selection criteria in your own scripts. The scripts included in this thread already have the necessary modifications included.

Now for the fun stuff!

All checks take the form type@logic;value;subvalue (not all have all three). Below is a detailed list of all accepted inputs. Multiple checks can be included in the same type by separating with commas (e.g. type@logic;value;subvalue,logic;value;subvalue,logic;value;subvalue)

• radius - Used to test if unitTarget is within certain distance of unit
  • circle - treats the radius as circular, x^2+y^2+z^2
  • square - treats the radius as absolute, covers all squares
  • outside - treats the radius as exclusive, covers all squares not in specified radius
    • x,y,z value - integers 0+, will change large values to preserve map size
    • EXAMPLE: radius@circle;10,10,0
• target - Used to test unitTarget's relationship to unit
  • foreign - checks that civ ID is different
  • civ - checks that civ ID is the same
    • N/A
    • EXAMPLE: target@civ
• aclass - Checks creature classes specified in raws (see below for information on logic check)
  • ANY SELF DECLARED CREATURE CLASS
    • N/A
    • EXAMPLE: aclass@GENERAL_POISON
• acreature - Checks if specific creature;caste (see below for information on logic check)
  • ANY CREATURE;CASTE COMBINATION
    • N/A
    • EXAMPLE: acreature@DWARF;FEMALE
• asyndrome - Checks syndrome classes specified in individual creature (see below for information on logic check)
  • ANY SELF DECLARED SYNDROME CLASS
    • N/A
    • EXAMPLE: asyndrome@SPEED_CHANGE
• atoken - Checks creature tokens specified in raws (see below for information on logic check)
  • ANY OF THE TOKENS FOUND HERE
    • N/A
    • EXAMPLE: atoken@AMPHIBOUS,AQUATIC
• iclass - Checks creature classes specified in raws (see below for information on logic check)
  • ANY SELF DECLARED CREATURE CLASS
    • N/A
    • EXAMPLE: iclass@GENERAL_POISON
• icreature - Checks if specific creature;caste (see below for information on logic check)
  • ANY CREATURE;CASTE COMBINATION
    • N/A
    • EXAMPLE: icreature@DWARF;FEMALE
• isyndrome - Checks syndrome classes specified in individual creature (see below for information on logic check)
  • ANY SELF DECLARED SYNDROME CLASS
    • N/A
    • EXAMPLE: isyndrome@SPEED_CHANGE
• itoken - Checks creature tokens specified in raws (see below for information on logic check)
  • ANY OF THE TOKENS FOUND HERE
    • N/A
    • EXAMPLE: itoken@AMPHIBOUS,AQUATIC
• physical - Checks the physical attributes of the unitTarget
  • max
  • min
    • STRENGTH
    • AGILITY
    • TOUGHNESS
    • ENDURANCE
    • RECUPERATION
    • DISEASE_RESISTANCE
      • attribute value
      • EXAMPLE: physical@min;STRENGTH;2500,min;AGILITY;2500
• mental - Checks the mental attributes of the unitTarget
  • max
  • min
    • ANALYTICAL_ABILITY
    • FOCUS
    • WILLPOWER
    • CREATIVITY
    • INTUITION
    • PATIENCE
    • MEMORY
    • LINGUISTIC_ABILITY
    • SPATIAL_SENSE
    • MUSICALITY
    • KINESTHETIC_SENSE
    • EMPATHY
    • SOCIAL_AWARENESS
      • attribute value
      • EXAMPLE: mental@min;MEMORY;3000
• skills - Checks the skills of the unitTarget
  • max
  • min
    • any of the skills found here
      • skill level (0-20)
      • EXAMPLE: skills@min;ALCHEMY;15
• traits - Checks the personality traits of the unitTarget
  • max
  • min
    • any of the personality traits found here
      • trait level (0-100)
      • EXAMPLE: traits@max;ANGER;50
• age - Checks the age of the unitTarget as determined by dfhack.units.getAge(unit), "Returns the age of the unit in years as a floating-point value."
  • max
  • min
    • age value (0+)
    • EXAMPLE: age@min;80
• speed - Checks the movement speed of the unitTarget as determined by dfhack.units.computeMovementSpeed(unit), "Computes number of frames * 100 it takes the unit to move in its current state of mind and body."
  • max
  • min
    • movement speed value (0+)
    • EXAMPLE: speed@min;1000
• noble - Checks the noble positions of the unitTarget
  • required
  • immune
    • ANY NOBLE POSITION TOKEN
    • EXAMPLE: noble@required;MONARCH
• profession - Checks the profession of the unitTarget
  • required
  • immune
    • any profession token found here
    • EXAMPLE: profession@immune;BABY,immune;CHILD

Remark on the logic used:
The logic used to determine if a unitTarget passes or fails these checks is similar to the current logic in syndromes and interactions. It starts by checking the radius and target values if they are present. After those are passed it goes on to check the age, speed, physical, mental, skills, traits, noble, and position checks (again only if they are present). After it has passed all of these checks it begins to look through the iclass, icreature, isyndrome, and itoken checks. If the unitTarget has any of these classes or tokens it will fail (as would be expected). If it has passed all of the above checks it then looks at the aclass, acreature, and asyndrome checks. These checks are treated slightly differently than the others. If none of them are present, the unitTarget will pass and the script will return true. However, if any one of these checks is present the creature will fail UNLESS the creature has the required class or token (e.g. if you have acreature@DWARF;FEMALE than only the FEMALE caste of the DWARF creature will be targeted). Finally the atoken is checked. This check requires that the creature has ALL of the listed tokens, not just one of them.

I believe this logic is fairly intuitive, and am pretty sure is what is used in the games interactions logic. If you have any questions about the logic, please feel free to ask.

Lastly, these are the currently accepted values (as you can see, there is A LOT that can be done with these checks). While typing this up I thought of some additional checks for all of those that are looking for a min/max value.

• less and greater! This would check the unitTarget against the unit and determine if it has a lesser value or a greater value (e.g. check if the target is faster than the reference unit, if it is the interaction doesn't work)
• ratio! Check the ratio of ages (Meph mentioned this below), and the ratio of different values

EDIT: Another thing that might be interesting is entity specific interactions, I will look into figuring out the entity of the unitTarget using DFHack.

[Raidau]

Fantastic!

One thing I have to notice. I used multicmd command with syndomeTrigger, and it uses ";" for separating commands, just wondering if it will conflict with syntax of your script

[Roses]

It only checks the ";" and other separators for the specific commands mentioned in my other post so it should work just fine with multicmd, although I'm not entirely sure since I haven't used multicmd before.

[Roses]

I have found a semi-reasonable way to check interactions for the person using them. Using tests of 10 units fighting each other I was able to consistently identify the correct unit. However, because my method depends on announcements and reports it has three major draw backs.

1. Your interactions need to have a CDI:VERB and can not have a CDI:TARGET_VERB. (I am currently working on reworking my method so that you can have both, I think it should be possible, but you will still be required to at least have the CDI:VERB)
2. Large groups of combatants (20+, i.e. a siege) of stacked teams with lots of interactions could cause in correct identifications. I do not know if this can be fixed, or even how large of a problem it will be. More testing is required.
3. It can only be used with scripts, and will not apply syndromes or do other interaction type things (unless using my, or others, applySyndrome script).

For those of you interested, my method is;

1. Unit A targets Unit B with an interaction
2. Announcement stating "Unit A CDI:VERB" is generated and attached to Unit B (the game does this automatically)
3. The script reads the three most recent announcements stored in Unit B's data structure.
4. It identifies the announcement with the right structure (I am thinking it might be possible to pass the CDI:VERB to the script so that it always finds the correct announcement) and it pulls Unit A's name.
5. It then also pulls position data out of the announcement (the square that Unit A was in when the interaction was used) and first checks that square for Unit A by cross referencing the name.
6. If it can't find Unit A on that square it begins searching adjacent squares.
7. Once Unit A is found, the script returns Unit A's ID.

This means that the script has access to both the unit ID of the target and the unit ID of the person using the interaction. This allows things like reflections (reflect that fireball), stat comparisons (check your willpower against an enemies), and silence effects (interaction fails if Unit A is silenced) to be used.

I am currently working on incorporating this usage in my select.lua script, but am unsure if the above mentioned drawbacks will limit its actual use or not.

NOTE: For those wondering, I have tried many different methods for gathering both ID's in a single script (i.e. getting Unit A's ID while using an ATTACK interaction). The only other method that seemed to work was checking the units attacker_id flag. This worked flawlessly for one on one fights, but immediately failed for larger fights. If anyone has a better method to use I am all ears.

NOTE 2: You can use pong type interactions (Unit A gives Unit B an interaction that it can use on Unit A to give an interaction that Unit A can use on itself), but there are inherent flaws in that type of interaction. I also don't like having many redundant interactions, when one should really be enough.

EDIT: Forgot to mention the whole original purpose, this will allow adding syndromes and such to your own units via ATTACK interactions. This should limit the amount of spam, and make sure your mage only uses that stoneskin spell in combat.

[Roses]

Just found a major bug (really just a problem with the logic used) so don't use the currently uploaded version. I almost have a new working version that should have all the correct logic in. I will edit this post when the correct version is updated.

EDIT: Almost done with the fixes, just wanted to share the full functionality of this new script. It now works as a wrapper for other scripts. Any script that takes a \UNIT_ID (or \WORKER_ID for autoSyndrome) or \LOCATION can be used with this script (it also has its own built in multicmd function). Here is how it works.

[SYN_CLASS:selected] <= The name of the selection script
[SYN_CLASS:\UNIT_ID] <= Self explanatory
[SYN_CLASS:script@script1,script2,script3] <= Names of the scripts you wish to run
[SYN_CLASS:args@arg11;arg12;arg13,arg21;arg22,arg31;arg32;arg33;arg34] <= arguments for each of the scripts, for \UNIT_ID and \LOCATION, simply enter unit and location respectively and the selected script will fill them in as needed.
[SYN_CLASS:...] <= Any of the selection criteria mentioned above. Note that if using for \LOCATION it will check the location of various targeted creatures and will check their selection criteria.

Example, an exhaustion causing, blood draining circle around a unit. High willpower makes the creature immune.
[SYN_CLASS:selected]
[SYN_CLASS:\UNIT_ID]
[SYN_CLASS:script@changefixed,changepercent]
[SYN_CLASS:args@exhaustion;unit;10000,blood;unit;-25]
[SYN_CLASS:radius@circle;5,5,2]
[SYN_CLASS:aclass@GENERAL_POISON]
[SYN_CLASS:mental@max;WILLPOWER;2000]

[Deon]

Thank you. You sir are a scholar, a noble and a gentleman.

Finally I have something to occupy myself with while I am waiting for the next version.

Regarding Meph's question "where's Deon", I was so hyped about the next release that I decided to postpone modding for a while until it hits (I hoped it would be February-March). Now it looks like it will take more time, so this is a perfect opportunity to return.

I cannot thank you for the wonders which this brings .

[Roses]

I will be uploading updated scripts shortly, the functioning is all the same as before, but the inputs are a little different. The updated syntax for all scripts will be based on the new selected.lua script. They will function by themselves as normally but will be much more powerful and configurable when paired (similarly all peoples scripts should be able to be paired with selected.lua to benefit from its options).

I will also be releasing several example interactions from my mod along with the scripts so people can get a wide range of examples.

EDIT: Decided to add a couple more functions before I released things;
1. A "chain" command that will run the script on repeat a specified number of times, only chaining to creatures that were hit by the script the first time. This means if you have a script that just hits an individual unit it will hit that unit X number of times. If you have a script, however, with a radius that hits multiple units, one of those units will be selected at random to start the script again. This could chain across the entire map if X is high enough and your radius is large enough. Use by setting [SYN_CLASS:chain@X] where X is the number of chains. Defaults to 0
2. A line of sight boolean. Useful for when you are triggering a radius effect but you only want the units that are within line of sight of your originating unit. Use by setting [SYN_CLASS:los@true]