Print

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

[Meph]

These sound fantastic for adventure mode.

[Roses]

These sound fantastic for adventure mode.

I hope it all works in adventure mode. I really need to set up a test script for trying them all out. I've got them all running in Fort mode, any they just use things like modtools/item-trigger, which I am pretty sure work just fine in adventure mode.

I also, got the Enhanced Buildings working. So now you can have working multi-story buildings (it's kind of a cludgy work around, but seems to work fine). You can also require a certain size in the z direction be available in order to build a building. As an example a multi-story cathedral can be designated like this.

Code: [Select]

[BUILDING:MULTI_STORY_CATHEDRAL]
 [OUTSIDE_ONLY]
 [WALLS:BUILDING_MAT:STONE]
 [ROOF:BUILDING_MAT:STONE]
 [FLOORS:BUILDING_MAT:STONE]
 [LEVELS:5]
 [PILLAR:1:1]
 [LEVEL:1:MULTI_STORY_CATHEDRAL]
 [LEVEL:2:CATHEDRAL_LEVEL_2]
 [LEVEL:3:CATHEDRAL_LEVEL_3]
 [LEVEL:4:CATHEDRAL_LEVEL_4]
 [LEVEL:5:CATHEDRAL_TOP_LEVEL]When you start construction of the MULTI_STORY_CATHEDRAL building it will check to make sure there is enough room for all five levels and that it is outside. It will then construct floors, a roof, and walls out of whatever stone material is being used in the base construction of the building (if the building material being used isn't stone it will default to a local stone material). Walls and roof are optional, the PILLAR argument states which position you want to act as a pillar that holds the whole thing up. If you are using walls it is not necessary. Each level needs to have it's own BUILDING_WORKSHOP raw entry, as it is basically just constructing buildings on buildings. I'm hoping to tie the construction of different levels to the build stages of the base building, but right now it just completes all of them at once. I haven't tested out building destroyers and multistory buildings yet, but I'm guessing it will fail miserably, as I barely have deconstruction working.

In addition to multi-story buildings, it is now easy to set up buildings with continuous effects. For example a building that continually produces mist every 10 ticks

Code: [Select]

[BUILDING:MIST_GENERATOR_BASE]
 [SPAWN_FLOW:MIST:100:10]Which is really just a shortcut for a building that runs a script

Code: [Select]

[BUILDING:MIST_GENERATOR_SCRIPT]
 [SCRIPT:flow/random-pos -location BUILDING_LOC -flow MIST -density 100:10]
To go along with Enhanced Buildings, Enhanced Reactions is coming along nicely. These reactions will basically allow you to specify a much wider range of reagents and products for a reaction. I will also be adding the ability to change reaction times, so you can make a reaction take as long as you want. The idea behind this addition was to be able to create things like quarries, where you assign a unit to perform the reaction with a certain amount of food and drink, then the unit goes to the quarry disappears for a couple days and then finishes the reaction with a certain amount of stone produced based on the units skill and what local stones are available. You will also be able to create stage like workshops where you can have a unit or group of units "perform" for a certain amount of time in order to give nearby units buffs and such.

Two notes;
1. I haven't played with the new version at all, so I don't know if anything that I am doing now will conflict with that. From what I can tell, no, but we shall see.
2. Like most of the scripting I do, these are all just tools for modders and players to use to add features to their game. Eventually there will be a mod of my own that uses all of these features, but for now the scripts come with just very basic examples. So if you want to know more about what they can do just ask!

Hope everyone is having a good holidays and happy new year (tomorrow). I should be pushing a big update on the 3rd or 4th of January when I get back to non dial-up internet.

EDIT: So something I did with the building triggers is now causing an intermittent crash. I'm trying to work it out before I push all the new stuff. If I can't figure it out in the next couple of days I'll probably just disable the Enhanced Buildings and Enhanced Reactions.

[Roses]

So a small update on progress. I meant to get changes pushed through by now but as usual I am fairly delayed. But fear not! Progress does continue, so here we go, green is done, yellow is in the testing stage, and red is in the planning stage;

1. modtools/action-trigger: A new script has been written to handle the "magical" items mentioned from a previous post. The reason I created this new script is because, while it was working fine before, it was limited to only work with my entire framework. This new script, which I will be submitting for inclusion in dfhack, does not rely on anything from my other scripts and systems. Of course my Enhanced Items and Enhanced Materials systems will add more functionality to the script and automate the components, any modder should now be able to set up action triggers in the same vein as item-trigger and interaction-trigger.

2. modtools/building-trigger: Following the same reasoning as above, this script essentially takes the current modtools/outside-only script and adds additional checks. For now you can check for a certain amount of height available, water and magma being available within 1 square of the buildings perimeter, other buildings already being built (as both a requirement and forbidden), and the outside/inside checks from the modtools/outside-only script. My Enhanced Buildings system will allow for much more (as outlined in the previous post), but splitting this script off into it's own thing allows other modders to benefit without the need for everything else.

3. modtools/reaction-trigger: This is more of a rewrite/rework of the existing modtools/reaction-trigger and modtools/reaction-product-trigger. This script combines the two together and allows for some more advanced options. It will probably need a new name because I'm not entirely sure it should replace the existing modtools/reaction-trigger, but for now I'll keep it what it is. The main reason for the creation of this script is to tie it into my Enhanced Reaction system, which needs more control than the current scripts have. Whether or not this should be included in default dfhack will be a decision for another time.

4. Civilization System - Diplomacy SubSystem: With mifki creating a script that can reliably force a siege, and the new DF features of sending out parties and such I figured it was time to actually make the Diplomacy SubSystem useful. Your standing with other civilizations will influence many different factors including, but not limited to, sieges, merchants, prices, immigration, and sending units to help you against other sieges.

5. Civilization System - Soldiers SubSystem: In conjunction with the Diplomacy SubSystem changes I am adding more configurable options for specifying a civilizations armies. Currently the Civilization System allows you to specify what materials and items are available to them (and Classes if using the Class System), but this leads to relatively random equipment of their units. The Soldiers SubSystem will allow you to set uniforms and other features. For instance, if you want to have a civilization that only ever sends its best soldiers you could set the Soldiers SubSystem to give all (or a percentage of all) units in a siege steel plate armor with steel weapons and enhanced skills and attributes, then when units from the civilization enter your map their inventories, skills, and attributes (and Classes if using the Class System) will be changed, Or another civilization might send lots and lots of poorly armed weak units and just a handful of extremely strong units, this will change the necessary things to achieve the preset stats of the armies. You will also be able to specify "Hero" units with a chance to show up on occasion.

6. Expedition System: This has been on my back burner for a long time now, with a lot of uncertainty about how I would even do it, but with the newest DF version and the ability to send out units I feel like now is a great time to take what is there and build on it. Originally this system was planned out to allow users to send units to raid, explore, quest, trade, steal, hunt, and more. I still need to figure out what features this system will have with respect to the new DF version and also which of those features are even remotely possible.

Once the reaction-trigger and Enhanced Reaction system is fully tested I will push a new release for the previous DF version. Once that is done I will migrate all of my scripts to the new DF version (shouldn't be too bad, especially since I spent an inordinate amount of time creating testing scripts), and then continue the work on expanding the Civilization System.

EDIT: reaction-trigger is coming along nicely. I just figured out how to increase the length of reactions to an arbitrary length so I am pretty pumped about that, it was the last major change I wanted to make to the script so after a little more testing it should be ready to go.

[Roses]

Warning: Long Post Incoming!

Good news everyone! I just (last night) pushed an update through! This update mainly focuses on minor bug fixes and fine tuning but there are a couple changes I would like to highlight.

First is the inclusion of three new scripts trigger/action, trigger/building, and trigger/reaction. These scripts (discussed in detail below) are stand alone scripts. What that means is that you can take them from my repository and use them as is. You can move and rename them anyway you want (I would suggest renaming them and putting them in modtools/action-trigger etc... since I will, hopefully, be getting them included in the main DFHack repo). Now what do they do? There is a brief description of them in the post above, but I'll go into more detail here. As with all trigger type scripts these commands need to be placed into the onLoad.init file.

1. trigger/action - This script is an extension of modtools/item-trigger. It allows you to trigger scripts when a unit does certain actions based on specific criteria. The exact options are;

Code: (trigger/action -help) [Select]

[[trigger/action.lua usage
arguments:
    -help
        print this help message
    -clear
        clear all registered triggers
    -actionType
        trigger the command when this action takes place
        valid values:
            Attack              -- This triggers whenever a unit makes an attack, whether or not the attack hits or misses
            Block               -- This triggers whenever a unit blocks an attack
            Dodge               -- DOES NOT CURRENTLY WORK, DODGES AREN'T ACTIONS
            Equip               -- Stolen from modtools/item-trigger, triggers when a unit equips an item
            Move                -- This triggers whenever a unit moves
            Parry               -- This triggers whenever a unit parries an attack
            Unequip             -- Stolen from modtools/item-trigger, triggers when a unit unequips an item
            Wound               -- Stolen from modtools/item-trigger, triggers when a unit wounds another unit
    ANNOUNCEMENT_TYPE   -- NOT CURRENTLY IMPLEMENTED
    -item type
        trigger the command for items of this type
        examples:
            ITEM_WEAPON_PICK
    -material mat
        trigger the commmand on items with the given material
        examples
            INORGANIC:IRON
            CREATURE:DWARF:BRAIN
            PLANT:MUSHROOM_HELMET_PLUMP:DRINK
    -contaminant mat
        trigger the command on items with a given material contaminant
        examples
            INORGANIC:IRON
            CREATURE:DWARF:BRAIN
            PLANT:MUSHROOM_HELMET_PLUMP:DRINK
    -creature creature
        trigger the command on creature performing the action
        examples:
            DWARF:ALL
            ELF:FEMALE
    -attack type
        trigger the command when a certain attack is performed
        obviously only works for the attack actionType
    -command [ commandStrs ]
        specify the command to be executed
        commandStrs
            UNIT_ID
            ATTACKER_ID
            BLOCKER_ID
            PARRIER_ID
            DEFENDER_ID
            BLOCKED_UNIT_ID
            PARRIED_UNIT_ID
            ITEM_MATERIAL
            ITEM_TOKEN
            ITEM_ID
            CONTAMINANT_MATERIAL
            anything -> anything
]])Unlike item-trigger this script checks that all three requirements are met before triggering a script. This means you could make an action trigger which only works if a male elf attacks with a mithril short sword coated in dwarf brain

Code: (All requirements Example) [Select]

trigger/action -actionType Attack -creature ELF:MALE -item ITEM_WEAPON_SWORD_SHORT -material INORGANIC:MITHRIL -contaminant CREATURE:DWARF:BRAIN -command [ blah ]You can also trigger a script any time a specific unit moves

Code: (-actionType Move Example) [Select]

trigger/action -actionType Move -creature DRAGON:ALL -command [ shake the ground or something ]Note that -actionType Dodge doesn't currently work because the game doesn't actually register the dodge as an action even though there is a dodge action type. The work around for this is allowing triggers off of combat reports as well. This will open up many new action types (list below), right now this is disabled but I do have a prototype version working, just need to find a full proof way to get the required information from the reports

Code: (Combat Report Types) [Select]

        <enum-item name='COMBAT_TWIST_WEAPON'/>
        <enum-item name='COMBAT_LET_ITEM_DROP'/>
        <enum-item name='COMBAT_START_CHARGE'/>
        <enum-item name='COMBAT_SURPRISE_CHARGE'/>
        <enum-item name='COMBAT_JUMP_DODGE_PROJ'/>
        <enum-item name='COMBAT_JUMP_DODGE_STRIKE'/>
        <enum-item name='COMBAT_DODGE'/>
        <enum-item name='COMBAT_COUNTERSTRIKE'/>
        <enum-item name='COMBAT_BLOCK'/>
        <enum-item name='COMBAT_PARRY'/>
        <enum-item name='COMBAT_CHARGE_COLLISION'/>
        <enum-item name='COMBAT_CHARGE_DEFENDER_TUMBLES'/>
        <enum-item name='COMBAT_CHARGE_DEFENDER_KNOCKED_OVER'/>
        <enum-item name='COMBAT_CHARGE_ATTACKER_TUMBLES'/>
        <enum-item name='COMBAT_CHARGE_ATTACKER_BOUNCE_BACK'/>
        <enum-item name='COMBAT_CHARGE_TANGLE_TOGETHER'/>
        <enum-item name='COMBAT_CHARGE_TANGLE_TUMBLE'/>
        <enum-item name='COMBAT_CHARGE_RUSH_BY'/>
        <enum-item name='COMBAT_CHARGE_MANAGE_STOP'/>
        <enum-item name='COMBAT_CHARGE_OBSTACLE_SLAM'/>
        <enum-item name='COMBAT_WRESTLE_LOCK'/>
        <enum-item name='COMBAT_WRESTLE_CHOKEHOLD'/>
        <enum-item name='COMBAT_WRESTLE_TAKEDOWN'/>
        <enum-item name='COMBAT_WRESTLE_THROW'/>
        <enum-item name='COMBAT_WRESTLE_RELEASE_LOCK'/>
        <enum-item name='COMBAT_WRESTLE_RELEASE_CHOKE'/>
        <enum-item name='COMBAT_WRESTLE_RELEASE_GRIP'/>
        <enum-item name='COMBAT_WRESTLE_STRUGGLE'/>
        <enum-item name='COMBAT_WRESTLE_RELEASE_LATCH'/>
        <enum-item name='COMBAT_WRESTLE_STRANGLE_KO'/>
        <enum-item name='COMBAT_WRESTLE_ADJUST_GRIP'/>
        <enum-item name='COMBAT_GRAB_TEAR'/>
        <enum-item name='COMBAT_STRIKE_DETAILS'/>
        <enum-item name='COMBAT_STRIKE_DETAILS_2'/>
        <enum-item name='COMBAT_EVENT_ENRAGED'/>
        <enum-item name='COMBAT_EVENT_STUCKIN'/>
        <enum-item name='COMBAT_EVENT_LATCH_BP'/>
        <enum-item name='COMBAT_EVENT_LATCH_GENERAL'/>
        <enum-item name='COMBAT_EVENT_PROPELLED_AWAY'/>
        <enum-item name='COMBAT_EVENT_KNOCKED_OUT'/>
        <enum-item name='COMBAT_EVENT_STUNNED'/>
        <enum-item name='COMBAT_EVENT_WINDED'/>


2. trigger/building - This is an extension of modtools/outside-only, basically it takes that script and adds extra checks to it. The exact options are;

Code: [Select]

Arguments::
    -clear
        clears the list of registered buildings
    -building BUILDING_TOKEN
        specify the id of the building
    -location OUTSIDE or INSIDE
        state whether the building needs to be built outside or inside
    -zLevels #
        the number of z levels needed for the building
    -requiredBuilding [ ID:# ]
        the id and number of a building(s) that needs to already be built to continue
    -forbiddenBuilding [ ID:# ]
        the id and number of a building(s) that cannot be already built to continue
    -maxNumber #
        the maximum number of this type of building
    -requiredWater #
        the amount of water next to the building that is required to build
        it will check every tile between x1-1->x2+1, y1-1->y2+1, and z-1->z
    -requiredMagma #
        the amount of water next to the building that is required to build
        it will check every tile between x1-1->x2+1, y1-1->y2+1, and z-1->z
    -command [ commandStrs ]
        specify the command to be executed if the building passes the checks
        commandStrs
            BUILDING_ID
            BUILDING_TOKEN
            BUILDING_LOCATION
            anything -> anythingThis script is fairly self explanatory, be careful with using the zLevel check as it is very specific, there must be that much open space above the building, if even a small tree branch is there it will abort the building.


3. trigger/reaction - This script is a combination of modtools/reaction-trigger and modtools/reaction-product-trigger with some new added features. The exact options are;

Code: [Select]

Arguments::
    -clear
        unregister all reaction hooks
    -reactionName name
        specify the name of the reaction
    -trigger Trigger Type
        specify when to trigger the script
        Valid Values:
            onStart
            onFinish
            onProduct
    -delay #
        how long to make the reaction take
        only works on -trigger onStart
    -requiredWater #
        amount of water the reaction needs, will cancel reaction if the water isn't present
        removes this amount of water from the surrounding tiles
    -requiredMagma #
        same as -requiredWater except for with magma
    -syndrome name
        specify the name of the syndrome to be applied to the targets
    -allowNonworkerTargets
        allow other units in the same building to be targetted by
        either the script or the syndrome
    -allowMultipleTargets
        allow multiple targets to the script or syndrome
        if absent:
            if running a script, only one target will be used
            if applying a syndrome, then only one target will be infected
    -resetPolicy policy
        the policy in the case that the syndrome is already present
        policy
            NewInstance (default)
            DoNothing
            ResetDuration
            AddDuration
    -command [ commandStrs ]
        specify the command to be run on the target(s)
        special args
            WORKER_ID
            TARGET_ID
            BUILDING_ID
            LOCATION
            REACTION_NAME
            JOB_ID
            INPUT_ITEMS
            OUTPUT_ITEMS
            anything -> anythingWith the inclusion of the -trigger option this script mimics the behavior of the combined scripts. Use -trigger onFinish to replicate modtools/reaction-trigger and use -trigger onProduct to replicate modtools/reaction-product-trigger. The major additions from this script is the onStart trigger and delay and requiredWater/Magma. A couple examples for illustration. First, a reaction that takes a full day, regardless of skill, to complete. Note that the timer for this starts as soon as the unit begins the work so it includes the amount of time spent fetching items needed for the reaction, at a later time I will make it only start the timer once the unit stops fetching and starts working.

Code: (-delay Example) [Select]

trigger/reaction -reaction SOME_REACTION_YOU_WANT_TO_TAKE_A_WHOLE_DAY -delay 3200 -command [ you don't need a command if you don't want one ]Next up is a reaction that requires 1 water and 1 magma to run and makes steam. Note the water and magma will be removed from the surrounding tiles.

Code: (-requiredWater/Magma Example) [Select]

trigger/reaction -reaction MAKE_STEAM -requiredWater 1 -requiredMagma 1 -command [ flow/random-pos -flow STEAM -location LOCATION ]Other than the above examples the script should work the same as the two modtools equivalents.


Alright! Now that I have covered the new scripts, let's talk about how they interact with my other scripts and systems! As with all my systems they use an external "raw" file written by the user. Examples will be provided below for each of the subsystems. These scripts were basically written to be the power horse of the Enhanced System. So let's discuss that.

1. Enhanced System - Buildings SubSystem (Note that for the time being I have disabled the construction of multi story buildings as the deconstruction of them can cause crashes)
    This subsystem is designed to; a) streamline the trigger/building script and b) add additional utility. The structure of the subsystem raws are;

Code: [Select]

[BUILDING:TEST_BUILDING_1]
    [NAME:Test Building]    < Name and Description are only for the journal-gui scripts
    [DESCRIPTION:Testing all the things]
    [INSIDE_ONLY]
    [MAX_AMOUNT:4]
    [REQUIRED_WATER:7]
    [REQUIRED_MAGMA:3]
    [REQUIRED_BUILDING:TEST_BUILDING_2:1]
    [FORBIDDEN_BUILDING:TEST_BUILDING_3:2]
    [MULTI_STORY:4]
    [SCRIPT:devel/print-args [ BUILDING_ID BUILDING_TOKEN BUILDING_LOCATION ]:500]    < This script will be run every 500 ticks for as long as the building remains constructedYou will see that most of the the options correspond directly to what is in the trigger/building script. This allows you to write out what each building is supposed to do/require and not have to worry about placing script calls in onLoad.init

2. Enhanced System - Creatures SubSystem
    This subsystem is designed to allow automatic manipulation of creatures. This gets around the current raw cap on things like attributes as well as making the acquisition of interactions more random. It can also be tied into the Class System to assign classes. The structure of the subsystem raws are;

Code: [Select]

[CREATURE:ELF:MALE]
  [NAME:Test Enhanced Creature (ELF:MALE)]
  [DESCRIPTION:This is a test enhanced creature, checks that all tokens are processed correctly]
  [BODY_SIZE:1000:10000:100000:200000:1000]                 < Will change the size of the creature based on age, BABY:CHILD:ADULT:MAX:VARIANCE
  [ATTRIBUTE:AGILITY:5000:5500:6000:6500:7000:7500:8000]    < Will set agility to between 5000 and 8000 using the same weighting as the standard raws
  [NATURAL_SKILL:AXE:2:5]                                   < Will set units natural axe skill to between 2 and 5
  [STAT:SPELL_CASTING:50:75]                                < Stats and resistances are used in my other scripts, they work just like skills and attributes
  [RESISTANCE:MAGICAL:25:50]
  [CLASS:TEST_CLASS_1:2:50]                                 < Will assign TEST_CLASS_1 at level 2 with 50% of it's spells chosen randomly, note that multiple CLASS tokens will be chosen from randomly
  [INTERACTION:TEST_SPELL_2:50]                             < 50% chance the unit will learn TEST_SPELL_2
  [INTERACTION:TEST_SPELL_3:50]                             < 50% chance the unit will learn TEST_SPELL_3This entry will update any male elf on the map every 100 ticks. Once they are "enhanced" they won't be enhanced again so you don't have to worry about multiple enhancements for the same unit (note MALE could be replaced with ALL to handle all elf units).

3. Enhanced System - Items SubSystem and Materials SubSystem
    Both of these subsystems serve the same purpose but are triggered on different things (items and material respectively). They both heavily use trigger/action. The structure of the subsystem raws are;

Code: [Select]

[ITEM:ITEM_WEAPON_SWORD_SHORT]
  [NAME:Test Enhanced Item (ITEM_WEAPON_SWORD_SHORT)]
  [DESCRIPTION:This is a test enhanced item, checks that all tokens are processed correctly]
  [ON_EQUIP]    < This means the following effects occur when the item is equipped (and are reveresed when unequipped)
    [ATTRIBUTE_CHANGE:STRENGTH:-250]    < Subtracts 250 strength from the unit
    [SKILL_CHANGE:SWORD:10]    < Adds 10 levels to the units sword skill
    [TRAIT_CHANGE:ANGER:50]    < Adds 50 to the units anger trait
    [STAT_CHANGE:PHYSICAL_HIT_CHANCE:-10]    < Stats and resistances are used in other scripts, they work the same as skills and attributes
    [RESISTANCE_CHANGE:FIRE:-25]
    [INTERACTION_ADD:TEST_SPELL_2]    < Adds the TEST_SPELL_2 interaction to the unit
    [SYNDROME_ADD:TEST_SYNDROME_1]    < Adds the syndrome TEST_SYNDROME_1
  [ON_ATTACK:25]    < This means the following effects occur on an attack with the item 25% of the time. Effects are the same as ON_EQUIP but are prefaced by ATTACKER_ or DEFENDER_
    [ATTACKER_ATTRIBUTE_CHANGE:STRENGTH:25]
    [ATTACKER_SKILL_CHANGE:SWORD:-1]
    [ATTACKER_TRAIT_CHANGE:ANGER:-5]
    [ATTACKER_STAT_CHANGE:PHYSICAL_HIT_CHANCE:1]
    [ATTACKER_RESISTANCE_CHANGE:FIRE:5]
    [ATTACKER_INTERACTION_ADD:TEST_SPELL_3]
    [ATTACKER_SYNDROME_ADD:TEST_SYNDROME_2]
    [ATTACKER_CHANGE_DUR:100]    < The length of time for the changes to last. Note that in this particular case multple stacks of these changes can and will be applied to the attacker
  [ON_BLOCK:5]    < This means the following effects occur on a block with the item 5% of the time. Effects are the same as ON_EQUIP but are prefaced by ATTACKER_ or DEFENDER_
    [DEFENDER_ATTRIBUTE_CHANGE:AGILITY:25]
    [DEFENDER_SKILL_CHANGE:DODGE:-1]
    [DEFENDER_TRAIT_CHANGE:ANGER:5]
    [DEFENDER_STAT_CHANGE:PHYSICAL_CRIT_CHANCE:5]
    [DEFENDER_RESISTANCE_CHANGE:WATER:-5]
    [DEFENDER_INTERACTION_ADD:TEST_SPELL_1]
    [DEFENDER_SYNDROME_ADD:TEST_SYNDROME_3]
    [DEFENDER_CHANGE_DUR:100]
    [SCRIPT:devel/print-args [ SOURCE_ID TARGET_ID ITEM_ID ITEM_TOKEN ]:50]    < This script will be run 50% of the time the ON_BLOCK is triggered (so 50% of 5% of the blocks)
  [ON_PARRY:100]    < This means the following effects occur on a parry with the item 100% of the time. Effects are the same as ON_EQUIP but are prefaced by ATTACKER_ or DEFENDER_
    [ATTACKER_ATTRIBUTE_CHANGE:STRENGTH:-25]
    [ATTACKER_SKILL_CHANGE:SWORD:1]
    [ATTACKER_TRAIT_CHANGE:ANGER:5]
    [ATTACKER_STAT_CHANGE:PHYSICAL_HIT_CHANCE:-1]
    [ATTACKER_RESISTANCE_CHANGE:FIRE:-5]
    [ATTACKER_INTERACTION_ADD:TEST_SPELL_3]
    [ATTACKER_SYNDROME_ADD:TEST_SYNDROME_2]
    [ATTACKER_CHANGE_DUR:100]The Materials SubSystem has the exact same format exept [ITEM:ITEM_WEAPON_SWORD_SHORT] gets changed to [MATERIAL:INORGANIC:STEEL], [MATERIAL:CREATURE:DRAGON:BONE], or [MATERIAL:PLANT:SINGLE-GRAIN_WHEAT:DRINK] etc...

4. Enhanced System - Reactions SubSystem
    This subsytem takes advantage of the trigger/reaction script, and allows for some extra goodies. The structure of the subsystem raws are;

Code: [Select]

[REACTION:TEST_REACTION_1]
    [NAME:Test Reaction 1]
    [DESCRIPTION:Testing various Enhanced Reaction triggers]
    [ON_START]
[SKILL:MINING]                < Skill associated with this reaction
[BASE_DURATION:1000]          < Base duration (or delay in the trigger/reaction script) for the reaction to last
[DURATION_REDUCTION:50:10]    < Reduction in the base duration based on skill. This means for each 1 level of MINING the duration of the reaction decreases by 50 ticks down to a minimum of 10 ticks
        [SCRIPT:devel/print-args [ UNIT_ID TARGET_ID BUILDING_ID LOCATION INPUT_ITEMS OUTPUT_ITEMS REACTION_NAME ]]    < This script will be run on the start of the reaction, note that INPUT_ITEMS and OUTPUT_ITEMS will not be populated since they aren't available to onStart reaction triggers
    [ON_PRODUCT]
        [SCRIPT:devel/print-args [ UNIT_ID TARGET_ID BUILDING_ID LOCATION INPUT_ITEMS OUTPUT_ITEMS REACTION_NAME ]]
    [ON_FINISH]
        [SCRIPT:devel/print-args [ UNIT_ID TARGET_ID BUILDING_ID LOCATION INPUT_ITEMS OUTPUT_ITEMS REACTION_NAME ]]Currently there aren't as many fun features for this subsystem as there with the others. But that will change with time.

NOTE: For all of the above Enhanced System examples you DO NOT need to place anything in the onLoad.init (like you do if using the trigger scripts by themselves). The Enhanced System will take care of all of that for you!

I will be testing all scripts and systems on DF 44.05 this afternoon and if there are no issues I will update the master branch of my GitHub to 44.X compliant and create a 43.X branch for those still using the old DF. All future development will be done in the current DF version however.

[Roses]

More good news. All tests came back as passing for the new DF/DFHack version (44.05). No changes needed! So feel free to download and use to your hearts content. Hopefully the inclusion of my tests means there will be less errors going forward, but with over 10000 lines of combined code there is always going to be something wrong somewhere.

One request, if anyone decided to use the Enhanced System (or any of the Systems actually) would you please post your files here so that others can see, take inspiration from, and possibly even use them?

[Roses]

I've made a small upgrade to the Enhanced Item system, now in addition to ON_EQUIP, ON_ATTACK, ON_WOUND, ON_BLOCK, ON_PARRY, and ON_MOVE triggers there is now ON_FIRED, ON_PROJECTILE_MOVE, and ON_PROJECTILE_HIT. Both the moving and the hit were already possible with an eventful trigger, this is just a different method for calling them without having to mess with the onload.init. The ON_FIRED allows you to trigger a script when a projectile is fired. Some neat examples are a "cannon shot" that knocks the firer backwards and a "semi auto shot" which every time you shoot a projectile it fires an extra 4 shots. I will add some extra examples soon

[Roses]

At a conference this week so I won't have time to add examples and updates for the new Enhanced Item and Enhanced Material projectile triggering, but here is a sneak peak that I tested before I left. This will change any ITEM_AMMO_ARROW_SPLITSHOT ammo fired from 1 into 3 projectiles. I still need to add options for branching shots and other unique features, but it works pretty well so far. You can also add the ability to a bow so that any ammo shot from the bow will split into 3 shots (or whatever else you want)

Code: [Select]

[ITEM:ITEM_AMMO_ARROW_SPLITSHOT]
 [NAME:Split Shot Arrow]
 [Description:An arrow that splits into multiple when fired]
 [ON_PROJECTILE_FIRED]
  [SCRIPT:item/projectile -unitSource UNIT_ID -unitTarget TARGET_ID -item ITEM_TOKEN -material MATERIAL_TOKEN -number 2 -velocity PROJECTILE_VELOCITY -hitchance PROJECTILE_HITCHANCE]


[Roses]

Question for possible users. For the systems, is it better to have separate files or to include the information directly into the DF raws. For example;

2 Files

Code: (objects/item_ammo.txt) [Select]

[ITEM_AMMO:ITEM_AMMO_ARROWS_SPLITSHOT]
[NAME:split shot arrow:split shot arrows]
[CLASS:ARROW]
[SIZE:150]
[ATTACK:EDGE:5:1000:stab:stabs:NO_SUB:1000]
        [ATTACK_PREPARE_AND_RECOVER:3:3]

Code: (system/Eitems.txt) [Select]

[ITEM:ITEM_AMMO_ARROWS_SPLITSHOT]
 [NAME:Split Shot Arrow]
 [Description:An arrow that splits into multiple when fired]
 [ON_PROJECTILE_FIRED]
  [SCRIPT:item/projectile -unitSource UNIT_ID -unitTarget TARGET_ID -item ITEM_TOKEN -material MATERIAL_TOKEN -number 2 -velocity PROJECTILE_VELOCITY -hitchance PROJECTILE_HITCHANCE]

Or 1 single file with the normal raws with [] and the enhanced item raws with {}

Code: (objects/item_ammo.txt) [Select]

[ITEM_AMMO:ITEM_AMMO_ARROWS_SPLITSHOT]
[NAME:split shot arrow:split shot arrows]
{Description:An arrow that splits into multiple when fired}
[CLASS:ARROW]
[SIZE:150]
[ATTACK:EDGE:5:1000:stab:stabs:NO_SUB:1000]
        [ATTACK_PREPARE_AND_RECOVER:3:3]
{ON_PROJECTILE_FIRED}
        {SCRIPT:item/projectile -unitSource UNIT_ID -unitTarget TARGET_ID -item ITEM_TOKEN -material MATERIAL_TOKEN -number 2 -velocity PROJECTILE_VELOCITY -hitchance PROJECTILE_HITCHANCE}

The reason they are currently separate is because the classes and civilization systems that I started with didn't have corresponding DF raws. But items, buildings, reactions, and materials all do. Just not sure which is easier

[Atomic Chicken]

Not much of a modder myself, but having everything integrated into a single raw file sounds much more convenient from the user friendliness perspective.

[zilpin]

Ditto.
I vote 1 file with the default language (english).
Separate files for content should only be considered when you have verbose text, complex markup, or multimedia.
If wanted, a languages folder could later be used, the way software typically is done.

@Roses, are you fully parsing all raw files and validating them, or are you just scanning through them looking for your extensions and replacing them with the appropriate RAW text?

[Roses]

Currently the scripts will read all correctly named files in the raw/systems/ folder. Since this is outside of the normal raw/objects structure the files can be made to match the default raws, namely using [ ] to specify a raw token. For example, for testing the Enhanced Item system I use this file

Code: (Eitems_test.txt) [Select]

Eitems_test

[OBJECT:ENHANCED_ITEM]

[ITEM:ITEM_WEAPON_PICK]
  [NAME:Test Enhanced Item 1 (ITEM_WEAPON_PICK)]
  [DESCRIPTION:This is a test enhanced item, check ON_EQUIP SKILL_CHANGE]
  [ON_EQUIP]
    [SKILL_CHANGE:AXE:15]
  [ON_ATTACK:25]
    [SCRIPT:devel/print-args [ SOURCE_ID TARGET_ID ITEM_ID ITEM_TOKEN ]:50]
   
[ITEM:ITEM_WEAPON_AXE_BATTLE]
  [NAME:Test Enhanced Item 2 (ITEM_WEAPON_AXE_BATTLE)]
  [DESCRIPTION:This is a test enhanced item, checks ON_EQUIP INTERACTION_ADD]
  [ON_EQUIP]
    [INTERACTION_ADD:TEST_SPELL_1]
    Now the first group of lines is only included to match with default raws, the lua parser doesn't start reading until it finds [ITEM: on line 5. By using the same names as the default raws (namely ITEM_WEAPON_PICK and ITEM_WEAPON_AXE_BATTLE) the system knows to link create a link between the two.

If I were to add it all to the default raws I would no longer be able to use the [ ] convention (DF would spit out a lot of errors of unrecognized tokens) so I would have to switch to something like { }, and then I would need to parse all files in the raw/objects folder. Luckily this only needs to be done at the first setup so it wouldn't cause a slow down during gameplay. I wouldn't validate any raws with [ ], but instead just validate { } raws. I suppose I could leave it set up to try both methods as well

[Roses]

Sorry for my recent lack of updates. I have been doing some DF stuff, but mostly RL has invaded my time. As for updates, heres a small list

1. As per recent discussions I have combined my Systems Raws with the game raws, this flows a lot better I think, and it means all the information is stored in one place. For an example I have included a building and an item. Note the Enhanced System information is placed in { } as opposed to [ ]

The building can only be built outside, requires at least 4 water within 1 tile of it, and creates a source of mist (this uses my flow/source script, but you could also spawn a specific amount of mist each X ticks with the spawn-flow script)

Code: [Select]

[BUILDING_WORKSHOP:FOUNTAIN]
        [NAME:Fountain]
        [NAME_COLOR:7:0:1]
        [DIM:1:1]
        [WORK_LOCATION:1:1]
        [BUILD_LABOR:MECHANIC]
        [BUILD_KEY:CUSTOM_P]
        [BLOCK:1:0]
        [TILE:0:1:207]
        [COLOR:0:1:0:7:0]
        [TILE:1:1:207]
        [COLOR:1:1:MAT]
        {OUTSIDE_ONLY}
        {REQUIRED_WATER:4}
        {SCRIPT:flow/source -location BUILDING_LOCATION -source 200 -flow MIST -check 10:0}
        [BUILD_ITEM:2:TRAPPARTS:NONE:NONE:NONE][CAN_USE_ARTIFACT]
The item is a standard spear with some extra information that is used in my scripts and systems. You could also add ON_EQUIP or ON_ATTACK or any of the other Enhanced Items options

Code: [Select]

[ITEM_WEAPON:ITEM_WEAPON_SPEAR]
        [NAME:spear:spears]
        {DESCRIPTION:A standard spear}
        [SIZE:400]
        [SKILL:SPEAR]
        [TWO_HANDED:47500]
        [MINIMUM_SIZE:5000]
        [MATERIAL_SIZE:3]
        {CRIT_CHANCE:10}
        {CRIT_BONUS:150}
        {DAMAGE_TYPE:PIERCING}
        {WEAPON_CLASS:SPEAR}
        [ATTACK:EDGE:20:10000:stab:stabs:NO_SUB:1000]
                [ATTACK_PREPARE_AND_RECOVER:3:3]
        [ATTACK:BLUNT:10000:6000:bash:bashes:shaft:1250]
                [ATTACK_PREPARE_AND_RECOVER:3:3]

2. Multi Story buildings continue to cause issues with deconstructing them and building destroyers. I'm not sure if they will end up being useful at all, but I'm still trying.

3. With the recent DF additions the Civilization System needs to be reworked a bit. Particularly the Diplomacy Sub-System which handles civilizations interactions with each other.

That's pretty much it for now, I'm still working on creating my mod, but it is slow going as it is essentially a total conversion and I am trying to translate D&D like rules into DF which hasn't been as easy as I thought it would!

[Roses]

Wow, 2 months since the last post. Time sure does fly.... I'm trying to get back into DF modding and coding since I miss doing it, but I've been going through everything that's already there and I've realized it is kind of a mess! Reading through it all it seems like I was trying to do to many things at once and never finished a task before leaping onto the next one.

So over the next couple of weeks I am going to be going through all my stuff. And essentially "starting from scratch" (but it will actually be mostly just copying and pasting) and going through a list of tasks. Only adding needed code, and making the code as simple and straight forward as possible. I think one of the big problems is that I added features on to already completed scripts in kind of crappy ways instead of rewritting the scripts to account for the new features. This resulted in some functions and scripts needing way to many variable inputs and the persistent data tables being a complete mess. Looking at everything as a whole should make it all much more streamlined and hopefully more usable by others.

Work plan

• Review Scripts and Functions: Review all functions and make a list of what they do, the scripts that call them, and other functions they call
• Persistent Tables: Restructure persistent tables (unit, item, building, etc...) and methods for accessing information from them
• Unit Scripts and Functions: Remove unneeded functions, improve unit tracking, and integrate new and old unit scripts
• Item Scripts: Improve item tracking and integrate new and old item scripts
• Building Scripts: Improve building tracking and integrate new and old building scripts
• Map Scripts and Functions: Make getting specific locations more streamlined and integrate new and old tile/flow scripts
• Special Scripts: Integrate attack, entity, and misc scripts with the previous changes
• Review Systems: The "systems" (currently Class, Civilization, Event, and Enhanced) have gotten too unwieldy as things kept getting tacked on. Sketch out a specific plan for each system its necessary components (scripts, functions, sub-systems), and review against current implementation
• Class System: Simplify the entry level system, basic users don't need to be overwhelmed by all the bells and whistles
• Enhanced System: Integrate the enhanced system directly into the raws, most of this system is already fairly concise and straight forward
• Event System: Simplify the creation of events and their triggering mechanisms
• Civilization System: With the inclusion of the expeditions and other recent changes, this system needs to be completely redesigned
• Testing: Each step will be self tested, but recreate the testing scripts necessary to do a full test to check for any breaks between versions

I should be able to reasonably get through the scripts and functions in the next two weeks. I am going to try and be more aggressive and get through the Class and Enhanced systems as well, but those are both very large codes that it may take a while to fully sketch out and implement.

[Meph]

Roses! Glad to see you around. :-)

[Roses]

Thanks! Now I just hope that I can keep a good balance between RL and DF. I really want to get back in to modding, script writing, and eventually playing.

Updated previous post with progress, working on scripts now.