Print

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

[Urist McTeellox]

Quicklink: Download here

Have you wished to run an AutoSyndrome command a certain percentage of the time, only to discover that AutoSyndrome completely ignores reaction product probabilities? I know that I do, and so I've written probability-syndrome. This is a ruby script for DFHack, and an accompanying inorganic file that supports it. To use probability-syndromes, we just use the special INORGANIC:PROBABILITY_TABLE stone as a reaction product:

Code: [Select]

    [PRODUCT:100:1:BOULDER:NONE:INORGANIC:PROBABILITY_TABLE]

Now let's say that we want there to be a 20% chance each of an an elf siege:

Code: [Select]

    [PRODUCT:100:1:BOULDER:NONE:INORGANIC:PROBABILITY_TABLE]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:SIEGE_ELF]

Pretty nifty, right? It gets better; we could have a 20% chance a siege from the four great races, and a 20% chance of nothing. Only *one* of these events will trigger, so you'll never end up being double-sieged:

Code: [Select]

    [PRODUCT:100:1:BOULDER:NONE:INORGANIC:PROBABILITY_TABLE]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:SIEGE_ELF]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:SIEGE_HUMAN]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:SIEGE_DWARF]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:SIEGE_DROW]

This means we can now do things like have a reaction with a 90% chance of doing something nice, and a 10% chance of doing something nasty:

Code: [Select]

    [PRODUCT:100:1:BOULDER:NONE:INORGANIC:PROBABILITY_TABLE]
    [PRODUCT:90:1:BOULDER:NONE:INORGANIC:SOMETHING_NICE]
    [PRODUCT:10:1:BOULDER:NONE:INORGANIC:SOMETHING_NASTY]

So, I know what you're thinking... What do those inorganics actually look like?

Code: [Select]

[INORGANIC:SIEGE_ELF]
    [USE_MATERIAL_TEMPLATE:STONE_VAPOR_TEMPLATE]
    [SYNDROME]
        [SYN_CLASS:\AUTO_SYNDROME]
        [SYN_CLASS:\COMMAND]
        [SYN_CLASS:probability-syndrome][SYN_CLASS:cmd]
            [SYN_CLASS:force]
            [SYN_CLASS:siege]
            [SYN_CLASS:FOREST]

In other words, they're the DFHack command you want to run (along with arguments), but with '[SYN_CLASS:\AUTO_SYNDROME] [SYN_CLASS:\COMMAND] [SYN_CLASS:probability-syndrome] [SYN_CLASS:cmd]', at the front. This sequence of tags fires off AutoSyndrome (which we need because it cleans up the rocks for us), but delegates the command itself to probability-syndrome. The PROBABILITY_TABLE inorganic actually does the heavy lifting, as it's what inspects the reaction products and decides what to actually fire.

As of 4th January 2014, probability-syndrome now supports \REACTION_INDEX, \WORKER_ID, and \LOCATION meta-arguments in commands.

Probability-syndrome has only been tested under DFHack r4; I don't believe that r3 has the necessary df.dfhack_run() method available.

Probability-syndrome is already part of the Masterwork Dwarf Fortress: Studded With Patches master branch, but you can also download a stand-alone zipfile containing both the script and the supporting inorganic file.

Enjoy!

~ T

[Meph]

What about caravans? Traders have items in their inventory. Will the mithril items that you trade suddenly turn into wood?

[Roses]

I didn't know autosyndrome was a 100% always thing. This probability-syndrome is great.

[Meph]

Autosyndrome even fires, if the probability of the product is 0. PRODUCT:0:1:BOULDER will trigger it. Nice if you dont want to add extra XP to the worker.

[Urist McTeellox]

I didn't know autosyndrome was a 100% always thing. This probability-syndrome is great.

Neither did I, until I tried to add a 10% probability that each of four races would siege my fort after a reaction, and I discovered myself in serious amounts of !FUN!.

Autosyndrome even fires, if the probability of the product is 0. PRODUCT:0:1:BOULDER will trigger it. Nice if you dont want to add extra XP to the worker.

Oh gosh, I didn't even think about worker XP. Is that calculated on how many reaction products were actually created?

It might be possible for me to improve the script to not require the PROBABILITY_TABLE stone, by having the command stones check to see if they're the first probability-syndrome commands listed, and run the init logic if they are. That would mean that probability-syndrome stones could be listed just like any other product, without the need for a header. That would transform this script from a clever hack into a beautifully designed feature.

~ T

[Meph]

Is that calculated on how many reaction products were actually created?

Yes. With 100% skill learn rate its 30XP per item. The old libraries and legendary reaction literally created thousands of items in one go, to boost skills.

Its not so much that it has a large effect, but I noticed it because I have announcements everywhere. There are all on 0:1:BOULDER, to stop XP gain.

I did not understand your last sentence, but does it mean that I should wait before I rewrite dwarf expeditions and kobold theft?

[Urist McTeellox]

Yes. With 100% skill learn rate its 30XP per item. The old libraries and legendary reaction literally created thousands of items in one go, to boost skills.

That's good to know. I don't think I'll be doing any XP adjustment changes anytime soon, but deducting 30 XP times the probability of an option being selected means we could make a reaction product stochastically neutral if desired.

I did not understand your last sentence, but does it mean that I should wait before I rewrite dwarf expeditions and kobold theft?

Nope! It means you should definitely continue as planned, since all changes (if I make them) will be backwards compatible with the existing version.

~ T

[Meph]

I have a questions:

Auto-Syndrome never triggers when the reaction is set to repeat. 'R'. Does this change with Probability-Syndrome? Can I have a reaction thats 10% and just 'R' it?

[Urist McTeellox]

Auto-Syndrome never triggers when the reaction is set to repeat. 'R'. Does this change with Probability-Syndrome? Can I have a reaction thats 10% and just 'R' it?

Alas no, because we chain off AutoSyndrome. If it doesn't fire, then neither do we.

Also, I didn't realise AutoSyndrome never triggers on a repeat job. I wonder if that's a technical limitation? (I haven't actually checked how AutoSyndrome gets triggered from within DFHack at all.)

~ T

[Meph]

It gets better: If you have a job that will use autosyndrome, its 'A' active (which means a dwarf is one the way to the workshop), and you cancel it, autosyndrome triggers.

This means: Start collecting 25 souls for the Guardian of Armok. Wait for the 'A'. Cancel, before the first soul even reaches the workshop. Get free Guardian of Armok. Rinse, repeat.

[Quietust]

In other words, it's triggering when the job is removed, not when the job is completed. If these jobs are always custom reactions, then it would probably be more reliable to write a C++ plugin which interposes reaction_product_itemst::produce(...) and checks for the appropriate name, then goes back through the unit to get the job and the rest of the info for the reaction being performed.

[Roses]

What if I wanted to do something like

Code: [Select]

    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:GRANITE]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:OBSIDIAN]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:MARBLE]
    [PRODUCT:100:1:BOULDER:NONE:INORGANIC:PROBABILITY_TABLE]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:SIEGE_ELF]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:SIEGE_HUMAN]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:SIEGE_DWARF]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:SIEGE_DROW]
Where the first three products are treated just like normal products (i.e. there is a 20% chance of getting each one) and then all the products after PROBABILITY_TABLE are AutoSyndrome products? Will that work?

[Warmist]

In other words, it's triggering when the job is removed, not when the job is completed. If these jobs are always custom reactions, then it would probably be more reliable to write a C++ plugin which interposes reaction_product_itemst::produce(...) and checks for the appropriate name, then goes back through the unit to get the job and the rest of the info for the reaction being performed.

There is also a lua interface in eventful, but afaik raw-commands are more popular

[Meph]

What if I wanted to do something like

Code: [Select]

    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:GRANITE]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:OBSIDIAN]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:MARBLE]
    [PRODUCT:100:1:BOULDER:NONE:INORGANIC:PROBABILITY_TABLE]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:SIEGE_ELF]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:SIEGE_HUMAN]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:SIEGE_DWARF]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:SIEGE_DROW]
Where the first three products are treated just like normal products (i.e. there is a 20% chance of getting each one) and then all the products after PROBABILITY_TABLE are AutoSyndrome products? Will that work?

This as how it should work, yes. Everything below the probability is included in it, the top products should be fine.

I have a question as well:

Currently, you can only use probability-syndrome to run commands

Does this mean I cant add syndromes this way?

Example:
    [PRODUCT:100:1:BOULDER:NONE:INORGANIC:PROBABILITY_TABLE]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:SICKNESS]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:RAINBOW_PUKING]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:ELEPHANT_TRANSFORM]

This should either add a syndrome with a disease, a syndrome with an interaction, or a syndrome with a transformation to a creature. Thats not possible yet, is it?

Or: "Roll a dice"
    [PRODUCT:100:1:BOULDER:NONE:INORGANIC:PROBABILITY_TABLE]
    [PRODUCT:17:1:BOULDER:NONE:INORGANIC:ROLL_A_1]
    [PRODUCT:16:1:BOULDER:NONE:INORGANIC:ROLL_A_2]
    [PRODUCT:16:1:BOULDER:NONE:INORGANIC:ROLL_A_3]
    [PRODUCT:16:1:BOULDER:NONE:INORGANIC:ROLL_A_4]
    [PRODUCT:16:1:BOULDER:NONE:INORGANIC:ROLL_A_5]
    [PRODUCT:16:1:BOULDER:NONE:INORGANIC:ROLL_A_6]

And each one affects the creature differently, but only one affect comes into play.

[Urist McTeellox]

Oh my! It looks like I missed a whole bunch of questions on this thread, so let me do some catch-up.

First of all, as of about five minutes ago, you can now use \LOCATION, \REACTION_INDEX, and \WORKER_ID in probability syndrome commands.

And now, on to the questions:

What if I wanted to do something like

Spoiler (click to show/hide)

Code: [Select]

    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:GRANITE]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:OBSIDIAN]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:MARBLE]
    [PRODUCT:100:1:BOULDER:NONE:INORGANIC:PROBABILITY_TABLE]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:SIEGE_ELF]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:SIEGE_HUMAN]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:SIEGE_DWARF]
    [PRODUCT:20:1:BOULDER:NONE:INORGANIC:SIEGE_DROW]

Where the first three products are treated just like normal products (i.e. there is a 20% chance of getting each one) and then all the products after PROBABILITY_TABLE are AutoSyndrome products? Will that work?

Yes, provided you're not expecting probability-syndrome to interact with the other reaction products. So you'll have a 20% chance of getting obsidian, an (independent) 20% chance of getting marble, and then ONE OF a elf, human, dwarf, drow invasion (20%), or no effect (20%).  So you might get both marble, obsidian, and an invasion, but you won't ever get *two* invasions.

The intent is that one can write a reaction which may have side-effects, so you can have a dangerous reaction that produces a valuable product 100% of the time, but has a 10% chance of causing minor burns, and a 2% chance of causing major ones.

Unfortunately, I don't know of any good way to see what (non-probability-syndrome) products were created by the reaction, so I can't have something generate an item 20% of the time, and a command the other 80%.  (Unless you're using a create-item script, which is a potential work-around, although some items created from scripts (notably quivers) seem to be buggy.)

There is also a lua interface in eventful, but afaik raw-commands are more popular

I'm still a DFHack noob. Do you have docs you can point me out?

And now that I've noticed Meph beat me to Roses' question...

    Currently, you can only use probability-syndrome to run commands

Does this mean I cant add syndromes this way?

Alas no, unless you can trigger that syndrome from a command. I'm not familiar with how to place syndromes on units from within code (which is what would be needed for this), but I'm totally open to contributions from more experienced DFHack developers. (Although given we can now use \WORKER_ID, the most reusable solution may be a DFHack command which assigns a syndrome to a given unit, and then we can just call that.)

~ T