Print

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

[Roses]

So I've been going through everything and realized that one of the reasons it's so complicated is because I was trying to make the scripts work both inside my framework and as standalone scripts. This made things needlessly complicated so I've decided to just make all my scripts work inside my framework since without it they really don't do anything more than already published scripts do.

[Roses]

As is probably not surprising, things have been moving much slower than I had hoped. As something to help show that I am still working on it and to help illustrate what I am working on, I have decided to do a set of Feature Notes (e.g. explaining the features of the various scripts, what they do, and how they can be used). So today will be the first of a series of notes.

Tracking

Description:
Tracking is used by nearly every script that makes a change to an item, unit, or building. It stores all changes made (i.e. changing a unit's strength with unit/attribute-change) in persistent tables that last between save/reload. This allows for a number of interesting uses.

Uses:

• The most basic use of tracking is to keep a consistent game state between save/reload (this is present in other peoples work, I know Putnam for sure, probably others as well). This is needed because the default DFHack callback isn't persistent.
• A more interesting use of tracking is the ability to terminate changes before their typical end duration. This allows changes to be "dispelled" through a variety of methods. The currently implemented methods for termination are, Syndrome Name, Syndrome Class, and Change Type. This is done by attaching a syndrome to each change (either a real in-game syndrome or a fake syndrome that is just used for tracking purposes).
• Another use is coupling one or more changes between units. This allows changes to be dependent on each other and can be used as another method for termination or as a

Examples:

• If you were to use the unit/attribute-change script and set a duration of 1000 ticks for the change exiting the game at any point in that 1000 ticks would cause the attribute change to become permanent, which was not intended. Tracking keeps this information in a persistent table which is checked every time the game is loaded so that the change can be correctly reverted.
• Let's give a unit five different attribute changes, 3 positive (+Strength, +Agility, +Toughness) and 2 negative (-Strength, -Endurance). Each syndrome has a different name, each of the positive changes has a syndrome class [BUFF], and each negative has a syndrome class [DEBUFF]. You could terminate the changes based on their individual syndrome names, by their syndrome class (get rid of just buffs or just debuffs), get rid of all attribute changes, or get rid of a specific attribute change (for example get rid of both strength changing effects).
• In the previous example the negative attribute changes would be linked with the unit that caused the negatives. This allows us to not just terminate the negative changes but also put them back on the source unit. You could also have the source unit gain bonuses for the negative syndromes on the target unit and those would disappear if the target unit got the negative syndromes removed

Summary:
Tracking allows for increased control over the behavior, effects, and duration of changes made with scripts. It offers things akin to "dispelling", "banishing", "purging", and other typical D&D like spell interactions.

[Roses]

I continue to make slow but steady progress. Have gone through all the base scripts and functions. Now I need to go through the systems. Updated the previous post to show progress.

Now it is time for another Feature post. This time we are talking about the wrapper feature. I know the Examples section for these feature things are pretty poor right now. I will be adding actual usable examples in the future.

Wrapper

Description:
The wrapper script is a unique script that allows for providing other scripts with more information, better targeting, and a whole host of other things. In essence it "wraps" around other scripts to improve on their uses without needing to modify the wrapped script.

Uses:

• Adds extra targeting options so that interactions and scripts can be tailor made for specific targets. Targeting can be done by creature, caste, civ, entity, location, syndromes, classes (creature and syndrome), age, sex, attributes, skills, traits, wounds, body parts, etc... Basically almost any information you could think of.
• Can use formulas to pass values to other scripts. This allows you to use a single interaction/script (say unit/attribute-change) but have the actual numbers used in the script depend on a number of factors including attributes and skill on both the source and target of the interactions.
• Can also modify are enhance a script in other ways. You can make single interactions target multiple units in a radius about the target. You can have interactions chain from one target to another. You can have interactions reflect back on the source. And more.

Examples:

• Suppose you want to make an interaction that is only usable in combat but only targets a friendly unit. You would create an offensive interaction, use modtools/interaction-trigger to cause the wrapper script to trigger, and then set the targeting options to a certain distance away from the source and require a member of the same civ as the source.
• If you want to create an interaction that increases a targets toughness but want to make the increase relative to the sources willpower you can use the wrapper script to create a formula that checks the sources willpower and calculates a number for the unit/attribute-change function to alter the targets toughness.
• If you want a script to target multiple units but don't want to modify the script itself you can change the max number of targetable units with the wrapper function. It will then randomly select up to that number (depending on the other targeting options used) and apply the script to each of them.

Summary:
By using the wrapper script with the modtools/interaction-trigger script (or any other trigger script) you can dramatically increase the options for both targeting and effects of scripts without having to modify the scripts themselves.

[Roses]

Continuing to make slow (very slow) but steady progress towards a complete code revamp. I have added a new pdf to github which details the persistent tables used by the various systems and scripts in case anyone is interested in how things work in the background, or how the information can be accessed for other purposes.

[Roses]

Alright, I've finally gotten through all of the scripts, functions, and systems. Scripts have been tested and are working, functions are 75% tested and working, and the systems will be tested this weekend. Assuming all goes to plan (which it never does, but hey, you've gotta start somewhere) everything should be up and running by next week. I've also included much more thorough help documentation for everything, as well as information about the systems (not currently on git, will push with the final tests). I will also need to stress test the systems, currently information is only read from persistent tables when it is needed, but in a big fort even that might be too often and have a negative impact on fps. If that's the case I will switch to using global non-persistent tables that are loaded from persistent tables at the start and are pushed back when saving.

As a reminder, I've changed the Enhanced and Civilization systems to read directly from the raws so there is no more need for multiple files and trying to link things. I've included an example for a building and an item. I didn't include an entity or creature example because those raws are big, but it works the same. Anything in the {} is read by the systems. For now any ON_ATTACK in an item will be applied to every attack from the item, in the future it will just be applied to the attack it is under.

Code: [Select]

[BUILDING_WORKSHOP:TEST_BUILDING_1]
  [NAME:Test Building 1]
  {DESCRIPTION:Testing various Enhanced Building triggers}
  [NAME_COLOR:7:0:1]
  [DIM:1:1]
  [WORK_LOCATION:1:1]
  [BUILD_LABOR:MECHANIC]
  [BLOCK:1:0]
  [TILE:0:1:207]
  [COLOR:0:1:0:7:0]
  [TILE:1:1:207]
  [COLOR:0:1:0:7:0]
  [BUILD_ITEM:1:NONE:NONE:NONE:NONE][BUILDMAT]
  {OUTSIDE_ONLY}
  {SCRIPT:devel/print-args [ BUILDING_ID BUILDING_TOKEN BUILDING_LOCATION ]:500}

Code: [Select]

[ITEM_WEAPON:ITEM_WEAPON_PICK]
  [NAME:Enhanced Pick]
  {DESCRIPTION:This is a test enhanced pick}
  [SIZE:500]
  [SKILL:MINING]
  [TWO_HANDED:47500]
  [MINIMUM_SIZE:42500]
  [MATERIAL_SIZE:4]
  [ATTACK:EDGE:100:4000:strike:strikes:NO_SUB:2000]
    [ATTACK_PREPARE_AND_RECOVER:3:3]
  {ON_EQUIP}
    {SKILL_CHANGE:MINING:15}
  {ON_ATTACK:25}
    {SCRIPT:devel/print-args [ SOURCE_ID TARGET_ID ITEM_ID ITEM_TOKEN ]:50}
Looking forward I would like to revisit the gui's I had been working on, specifically the detailed unit viewer and the journal. I never really finished these even though I put a bunch of work into figuring out custom view screens and how to get the information into them. There have also been several nice custom screens from other modders that I have seen on the forums lately and I think it would be cool to make it easy to tie various custom view screens together.

[Roses]

Alright! All scripts and systems (except for the Enhanced Materials) are updated and passing the tests! There are very basic examples in the raw/systems/Test/ folder. I will get better examples put together this week (things like a fountain that makes mist, reactions that take a long time, weapons that increase attributes, creatures with sizes/attributes outside the raw limitations, etc...).

As for the gui stuff, I am going to start with the detailed unit viewer (DUV) Looking through my old stuff I used a fairly complicated system in an effort to try and link things together. With the changes I just made to the various scripts and systems I should be able to simplify it greatly. So I am going to start from scratch (with a lot of copy and pasting probably) and use my previous work as a road map. Is there anything in particular people would like to see in a DUV?

[Roses]

So apparently multiple new versions of DF and DFHack were released since I last updated my download (man I've been slow lately). The scripts and systems are all working on version 44.05, there are a couple things that changed between then and the new version (e.g. unit_flags1.dead -> unit_flags1.inactive) so I will upload a new fix tonight with everything working for the the current (44.12) version.

The Detailed Unit Viewer is also almost done, it is all set up, there are just a couple bits of information that are just place holders for now that need to be updated, and the layout (widths/heights/colors/etc...) could probably use some fine tuning, but those are easy. I'll get some screen shots up of the new layout and information stuff tonight. I also made it easy to tie in other authors scripts so the DUV (and journal when I re-release that) can look for another script and add an extra button to call.

EDIT: I also have a set of examples for the various systems that I will upload tonight as well. And as a teaser here is an Enhanced Reaction which an entity that doesn't have diggers could use to create a "mine shaft" type job that takes an amount of time to complete based on the units skill.

Code: [Select]

[REACTION:BASIC_MINING]
  [NAME:shallow mining]
  {DESCRIPTION:dig up rocks from the mine shaft}
  [BUILDING:MINE_SHAFT:NONE]
  [SKILL:MINING]
  [PRODUCT:100:1:BOULDER:NONE:INORGANIC:NONE]
  {ON_START}
    {BASE_DURATION:1000} -- In-game ticks the reaction takes for someone with 0 skill
    {DURATION_REDUCTION:50:10} -- Lowers duration by 50 in-game ticks per skill level down to a minimum of 10

[Roses]

Alright, scripts/systems are updated to the correct version, and below are two screen shots for the detailed unit viewer. The main view and the detailed view, as mentioned above there's still some work to do, but it's coming along

Spoiler: Main View (click to show/hide)

Spoiler: Details View (click to show/hide)

[Roses]

So I've still got some more to do on the detailed unit viewer, but it is coming along, and with the inclusion of the work done by Patrik Lundell the thoughts, preferences, values, etc... should be a lot better than what they were previously. I still need to get my string splitting routine to properly respect words but it should be simple enough. So far I've built it to be very modular, with all of the screens being made of sets of panels that can easily be reordered or even moved to entirely new pages with only changing a few lines of code. Below are some screen shots of the current set up, items marked with [X] are just place holders.

Spoiler: Main View (click to show/hide)

Spoiler: Details View (click to show/hide)

Spoiler: Classes View (click to show/hide)

Spoiler: Personality View (text) (click to show/hide)

Spoiler: Personality View (numbers) (click to show/hide)

Thoughts?

[Bumber]

Why does Urist, Female Dwarf, have a male appearance? Is that the placeholder at work?

[Roses]

Why does Urist, Female Dwarf, have a male appearance? Is that the placeholder at work?

Yes it is!

[Roses]

So I've got the appearances working mostly. It gets all of the information and parses it correctly but there seems to be some extra processing done when displaying information on the unit description screen. Two units with the same amount of CURLY in their hair can have different descriptions (one that mentions the curliness and one that doesn't). So it looks like the descriptions generated for the detailed unit viewer will always be much more in depth than the default ones. I've decided to make a seperate tab to list the entire unit description and then just put the most important descriptors on the main view. That way you don't get overwhelmed by just looking at the main view, but you can still get a basic sense of the unit. So far it works well for all of the default creatures in the game, but I will need to try a custom creature with lots of different appearance and tissue modifiers and see if it still works.

Here's an example string for a units hair

Code: [Select]

Her hair is copper with a touch of gray. It is very long, wavy, quite dense, and is tied in a pony tail. compared to the default string

Code: [Select]

Her quite dense hair is wavy. Her very long hair is tied in a pony tail. Her hair is copper with a touch of gray.
Still not sure I like the way I'm piecing together the information, but that is easy enough to change once I get all the information in there (currently there are placeholder strings for a lot of the descriptions because I haven't seen them in game yet)

[Roses]

New update

Spoiler (click to show/hide)

[Putnam]

Kinda feel like that screen should have orientation on it.

[Roses]

Kinda feel like that screen should have orientation on it.

Good call