Print

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

[Meph]

That does fix the errormessage. But the workshop does not revert back into its former state after the ticks I added. I upgrade is with "here" "building_id" "ticks".

Code: [Select]

[INORGANIC:UPGRADE_BUILDING_WORKSHOP_HUMAN_TIME]
[USE_MATERIAL_TEMPLATE:STONE_VAPOR_TEMPLATE]
[SPECIAL][MATERIAL_VALUE:0]
[SYNDROME]
[SYN_CLASS:here][SYN_CLASS:WORKSHOP_HUMAN][SYN_CLASS:500]
Does it only work with the upgrade/downgrade options, and not specific IDs? For example it would not work with BUILDING:HUMAN to BUILDING:ORC, but it would work with BUILDING:HUMAN_1 to BUILDING:HUMAN_2, which reverts back to BUILDING:HUMAN_1 after a while?

That would mean that time-limited upgrades can only work on workshops that have a single type of upgrade (level 1-2-3-4-5 and so on), but not on workshops that have multiple options (race warlock, race orc, race goblin, and so on).

What I wanted to do is this:
 - Buy item from caravan.
 - Rent workshop to race. Costs that items, gives coins, active for 6-12 months.
 - You can "prolong the contract", costs another of these items, gives more coins.
 - Or you can "kick out the merchant", reverts the building back to the base/empty workshop.

[Roses]

I did only test it with the upgrade option, but I added the same code to the other options as well so it should work with them. Let me see what I can figure out.

[Meph]

Sure thing, and thanks for the quick response.

[Roses]

Found the issue, it is a quick fix, but it also changes the way I thought lua and DFHack worked, which I am amazed hasn't caused an issue in any of my other scripts yet, or it has and they just haven't been found  I am going to ask in the DFHack thread for clarification, but, like I said, it is an easy fix, for testing purposes if you change line 120;

Code: [Select]

if #args == 3 then dur = tonumber(args[2]) end
to

Code: [Select]

if #args == 2 then dur = tonumber(args[2]) end
it should work.

[Meph]

I tried that change, and while it doesnt create any errors, it also doesnt fix the issue. The workshop upgrade is still permanent.

[Roses]

Interesting, it works fine for me now, for all three types.

Here is my full code that I just tested,

Code: [Select]

--base_upgradebuilding.lua v1.0
--MUST BE LOADED IN DFHACK.INIT
--[[
upgradebuilding - used to upgrade buildings from one to another, or to change them from one to another
Requires a reaction an inorganic and corresponding buildings

REACTION OPTIONS:
All reagents with [PRESERVE_REAGENT] will be added to the building materials of the upgraded building and can be reclaimed by destroying the upgraded building
Reagents without the [PRESERVE_REAGENT] tag will be consumed and will not be able to be reclaimed
The first product must be the inorganic with the syndrome attached to it
Subsequent products will be created as normal

EXAMPLE REACTION:
[REACTION:LUA_HOOK_UPGRADE_BUILDING_EXAMPLE_1] <- LUA_HOOK_UPGRADE_BUILDING is required
[NAME:upgrade building]
[BUILDING:TEST_BUILDING_1:NONE]
[REAGENT:A:1:BOULDER:NONE:INORGANIC:NONE][PRESERVE_REAGENT]
[REAGENT:B:1:BOULDER:NONE:INORGANIC:NONE][PRESERVE_REAGENT]
[REAGENT:C:1500:COIN:NONE:INORGANIC:SILVER]
[PRODUCT:100:0:BOULDER:NONE:INORGANIC:UPGRADE_BUILDING]

INORGANIC OPTIONS:
Inorganics must have a syndrome with at least two [SYN_CLASS:] tags
Valid arguments for the first SYN_CLASS;
here - this will change this particular building
BUILDING_TOKEN - this will change a randomly selected building of the given token (e.g. TEST_BUILDING_1)
Valid arguments for the second SYN_CLASS;
upgrade - this will upgrade the building from the name to one higher (i.e. TEST_BUILDING_1 -> TEST_BUILDING_2)
downgrade - this will downgrade the building from the name to one lower (i.e. TEST_BUILDING_2 -> TEST_BUILDING_1)
BUILDING_TOKEN - this will change the building to a completely new token (i.e. TEST_BUILDING_1 -> RESEARCH_BUILDING)
(OPTIONAL) A third SYN_CLASS can be added to specify duration of the change. Defaults to permanent. Duration is in in-game ticks

EXAMPLE INORGANIC:
[INORGANIC:UPGRADE_BUILDING]
[USE_MATERIAL_TEMPLATE:STONE_VAPOR_TEMPLATE]
[SPECIAL]
[SYNDROME]
[SYN_CLASS:here]
[SYN_CLASS:upgrade]
[MATERIAL_VALUE:0]

BUILDING OPTIONS:
Nothing special is required from buildings except when using the upgrade/downgrade option
then the buildings you wish to change need to be named in the convention BLAH_BLAH_BLAH_1, BLAH_BLAH_BLAH_2, etc...

EXAMPLE BUILDINGS:
[BUILDING_WORKSHOP:TEST_BUILDING_1]
[NAME:Soul Forge]
[NAME_COLOR:7:0:1]
[DIM:3:3]
[WORK_LOCATION:1:1]
[BLOCK:1:0]
[TILE:0:1:207]
[COLOR:0:1:0:7:0]
[TILE:1:1:207]
[COLOR:1:1:MAT]
[BUILD_ITEM:1:NONE:NONE:NONE:NONE]
[BUILDMAT]
[WORTHLESS_STONE_ONLY]

[BUILDING_WORKSHOP:TEST_BUILDING_2]
[NAME:Upgraded Soul Forge]
[NAME_COLOR:7:0:1]
[DIM:3:3]
[WORK_LOCATION:1:1]
[BLOCK:1:0]
[TILE:0:1:207]
[COLOR:0:1:0:7:0]
[TILE:1:1:207]
[COLOR:1:1:MAT]

RESTRICTIONS!
Only upgrade between buildings of the same type (i.e. WORKSHOP->WORKSHOP)
Only upgrade to buildings of the same size (i.e. 3x3 -> 3x3)
Only upgrade to buildings with the same center and work spot (I don't know if this is strictly necessary, haven't done much testing)
Be careful about forbiden tiles in a building, the effect of changing these tiles without redefining the building is unknown
--]]

function split(str, pat)
   local t = {}  -- NOTE: use {n = 0} in Lua-5.0
   local fpat = "(.-)" .. pat
   local last_end = 1
   local s, e, cap = str:find(fpat, 1)
   while s do
      if s ~= 1 or cap ~= "" then
table.insert(t,cap)
      end
      last_end = e+1
      s, e, cap = str:find(fpat, last_end)
   end
   if last_end <= #str then
      cap = str:sub(last_end)
      table.insert(t, cap)
   end
   return t
end

function createcallback(x,sid)
return function(resetbuilding)
x.custom_type = sid
end
end

function upgradebuilding(reaction,unit,input_items,input_reagents,output_items,call_native)
local sitems = {}
for i,x in ipairs(input_reagents) do
if x.flags.PRESERVE_REAGENT then sitems[i] = input_items[i] end
end
local pos = unit.pos

local ptype = reaction.products[0].mat_type
local pindx = reaction.products[0].mat_index
local product = dfhack.matinfo.decode(ptype,pindx)
local args = {}
for i,x in ipairs(product.material.syndrome[0].syn_class) do
args[i] = x.value
end

local dur = 0
if #args == 2 then dur = tonumber(args[2]) end

local bldg
if args[0] == 'here' then
-- Upgrade only the building that runs the reaction
bldg = dfhack.buildings.findAtTile(pos)
elseif args[0] == 'all' then
-- Upgrade all buildings of this type (doesn't currently work)
else
-- Upgrade random building of specific type
local bldga = {}
local i = 0
for _,x in ipairs(df.global.world.buildings.all) do
if df.building_furnacest:is_instance(x) or df.building_workshopst:is_instance(x) then
local ctype = x.custom_type
if ctype >= 0 then
if df.global.world.raws.buildings.all[ctype].code == args[0] then
bldga[i] = x
i = i+1
end
end
end
end
local rando = dfhack.random.new()
bldg = bldga[rando:random(#bldga)]
end

if args[1] == 'upgrade' then
-- Increase buildings number by one
local name = df.global.world.raws.buildings.all[bldg.custom_type].code
if dur > 0 then sid = bldg.custom_type end
local namea = split(name,'_')
local num = tonumber(namea[#namea])
num = num + 1
namea[#namea] = tostring(num)
name = table.concat(namea,'_')
local ctype = nil
for _,x in ipairs(df.global.world.raws.buildings.all) do
if x.code == name then ctype = x.id end
end
if ctype == nil then
print('Cant find upgrade building, possibly upgraded to max')
return
end

bldg.custom_type=ctype

for _,x in pairs(bldg.contained_items) do
for _,y in pairs(sitems) do
if x.item == y then
x.use_mode = 2
x.item.flags.in_building = true
end
end
end
if dur > 0 then dfhack.timeout(dur,'ticks',createcallback(bldg,sid)) end
elseif args[1] == 'downgrade' then
-- Decrease buildings number by one
local name = df.global.world.raws.buildings.all[bldg.custom_type].code
if dur > 0 then sid = bldg.custom_type end
local namea = split(name,'_')
local num = tonumber(namea[#namea])
num = num - 1
if num > 0 then namea[#namea] = tostring(num) end
name = table.concat(namea,'_')
local ctype = nil
for _,x in ipairs(df.global.world.raws.buildings.all) do
if x.code == name then ctype = x.id end
end
if ctype == nil then
print('Cant find upgrade building, possibly upgraded to max')
return
end

bldg.custom_type=ctype

for _,x in pairs(bldg.contained_items) do
for _,y in pairs(sitems) do
if x.item == y then
x.use_mode = 2
x.item.flags.in_building = true
end
end
end
if dur > 0 then dfhack.timeout(dur,'ticks',createcallback(bldg,sid)) end
else
-- Change building to new building
if dur > 0 then sid = bldg.custom_type end
local name = args[1]
local ctype = nil
for _,x in ipairs(df.global.world.raws.buildings.all) do
if x.code == name then ctype = x.id end
end
if ctype == nil then
print('Cant find upgrade building, possibly upgraded to max')
return
end

bldg.custom_type=ctype

for _,x in pairs(bldg.contained_items) do
for _,y in pairs(sitems) do
if x.item == y then
x.use_mode = 2
x.item.flags.in_building = true
end
end
end
if dur > 0 then dfhack.timeout(dur,'ticks',createcallback(bldg,sid)) end
end
end

-- START Taken from hire-guard.lua
local eventful = require 'plugins.eventful'
local utils = require 'utils'

function string.starts(String,Start)
   return string.sub(String,1,string.len(Start))==Start
end

dfhack.onStateChange.loadUpgradeBuilding = function(code)
local registered_reactions
if code==SC_MAP_LOADED then
--registered_reactions = {}
for i,reaction in ipairs(df.global.world.raws.reactions) do
-- register each applicable reaction (to avoid doing string check
-- for every lua hook reaction (not just ours), this way uses identity check
if string.starts(reaction.code,'LUA_HOOK_UPGRADE_BUILDING') then
-- register reaction.code
eventful.registerReaction(reaction.code,upgradebuilding)
-- save reaction.code
--table.insert(registered_reactions,reaction.code)
registered_reactions = true
end
end
--if #registered_reactions > 0 then print('HireGuard: Loaded') end
if registered_reactions then print('Upgradable Buildings: Loaded') end
elseif code==SC_MAP_UNLOADED then
--[[ doesn't seem to be working, and probably not needed
registered_reactions = registered_reactions or {}
if #registered_reactions > 0 then print('HireGuard: Unloaded') end
for i,reaction in ipairs(registered_reactions) do
-- un register each registered reaction (to prevent persistance between
-- differing worlds (probably irrelavant, but doesn't hurt)
-- un register reaction.code
eventful.registerReaction(reaction.code,nil)
end
registered_reactions = nil -- clear registered_reactions
--]]
end
end

-- if dfhack.init has already been run, force it to think SC_WORLD_LOADED to that reactions get refreshed
if dfhack.isMapLoaded() then dfhack.onStateChange.loadUpgradeBuilding(SC_MAP_LOADED) end
-- END Taken from hire-guard.lua


[Meph]

I copied that code, tried again. Doesnt work on my end.

Here my raws:

Base building

Code: [Select]

[BUILDING_WORKSHOP:WORKSHOP_BASE]
[NAME:Workshop (empty)]
[NAME_COLOR:7:0:1]
[BUILD_LABOR:ARCHITECT]
[BUILD_KEY:CUSTOM_NONE]
[DIM:5:5]
[WORK_LOCATION:3:3]
[BLOCK:1:0:0:0:0:0]
[BLOCK:2:0:0:0:0:0]
[BLOCK:3:0:0:0:0:0]
[BLOCK:4:0:0:0:0:0]
[BLOCK:5:0:0:0:0:0]
[TILE:0:1:32:32:223:32:32]
[TILE:0:2:221:32:32:32:219]
[TILE:0:3:32:32:32:32:32]
[TILE:0:4:221:32:32:32:222]
[TILE:0:5:32:32:219:32:32]
[COLOR:0:1:0:0:0:0:0:0:7:0:1:0:0:0:0:0:0]
[COLOR:0:2:7:0:1:0:0:0:0:0:0:0:0:0:7:0:1]
[COLOR:0:3:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0]
[COLOR:0:4:7:0:1:0:0:0:0:0:0:0:0:0:7:0:1]
[COLOR:0:5:0:0:0:0:0:0:7:0:1:0:0:0:0:0:0]
[TILE:1:1:219:223:32:32:32]
[TILE:1:2:221:32:32:223:222]
[TILE:1:3:32:32:32:32:219]
[TILE:1:4:221:32:32:32:222]
[TILE:1:5:32:219:32:32:32]
[COLOR:1:1:7:0:1:7:0:1:0:0:0:0:0:0:0:0:0]
[COLOR:1:2:7:0:1:0:0:0:0:0:0:7:0:1:7:0:1]
[COLOR:1:3:0:0:0:0:0:0:0:0:0:0:0:0:7:0:1]
[COLOR:1:4:7:0:1:0:0:0:0:0:0:0:0:0:7:0:1]
[COLOR:1:5:0:0:0:7:0:1:0:0:0:0:0:0:0:0:0]
[TILE:2:1:219:32:223:223:219]
[TILE:2:2:221:43:43:32:222]
[TILE:2:3:32:32:32:32:32]
[TILE:2:4:221:32:43:32:222]
[TILE:2:5:219:32:32:32:219]
[COLOR:2:1:7:0:1:0:0:0:7:0:1:7:0:1:7:0:1]
[COLOR:2:2:7:0:1:7:0:1:7:0:1:0:0:0:7:0:1]
[COLOR:2:3:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0]
[COLOR:2:4:7:0:1:0:0:0:7:0:1:0:0:0:7:0:1]
[COLOR:2:5:7:0:1:0:0:0:0:0:0:0:0:0:7:0:1]
[TILE:3:1:219:223:43:223:219]
[TILE:3:2:221:43:43:43:222]
[TILE:3:3:43:43:63:43:43]
[TILE:3:4:221:43:43:43:222]
[TILE:3:5:219:220:43:220:219]
[COLOR:3:1:7:0:1:7:0:1:7:7:1:7:0:1:7:0:1]
[COLOR:3:2:7:0:1:7:0:1:7:0:1:7:0:1:7:0:1]
[COLOR:3:3:7:7:1:7:0:1:7:0:1:7:0:1:7:7:1]
[COLOR:3:4:7:0:1:7:0:1:7:0:1:7:0:1:7:0:1]
[COLOR:3:5:7:0:1:7:0:1:7:7:1:7:0:1:7:0:1]
upgraded building

Code: [Select]

[BUILDING_WORKSHOP:WORKSHOP_HUMAN]
[NAME:Human Gunsmith]
[NAME_COLOR:7:0:1]
[BUILD_LABOR:ARCHITECT]
[BUILD_KEY:CUSTOM_NONE]
[DIM:5:5]
[WORK_LOCATION:3:3]
[BLOCK:1:0:0:0:0:0]
[BLOCK:2:0:0:0:0:0]
[BLOCK:3:0:0:0:0:0]
[BLOCK:4:0:0:0:0:0]
[BLOCK:5:0:0:0:0:0]
[TILE:0:1:32:32:223:32:32]
[TILE:0:2:221:32:32:32:219]
[TILE:0:3:32:32:32:32:32]
[TILE:0:4:221:32:32:32:222]
[TILE:0:5:32:32:219:32:32]
[COLOR:0:1:0:0:0:0:0:0:7:0:1:0:0:0:0:0:0]
[COLOR:0:2:7:0:1:0:0:0:0:0:0:0:0:0:7:0:1]
[COLOR:0:3:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0]
[COLOR:0:4:7:0:1:0:0:0:0:0:0:0:0:0:7:0:1]
[COLOR:0:5:0:0:0:0:0:0:7:0:1:0:0:0:0:0:0]
[TILE:1:1:219:223:32:32:32]
[TILE:1:2:221:32:32:223:222]
[TILE:1:3:32:32:32:32:219]
[TILE:1:4:221:32:32:32:222]
[TILE:1:5:32:219:32:32:32]
[COLOR:1:1:7:0:1:7:0:1:0:0:0:0:0:0:0:0:0]
[COLOR:1:2:7:0:1:0:0:0:0:0:0:7:0:1:7:0:1]
[COLOR:1:3:0:0:0:0:0:0:0:0:0:0:0:0:7:0:1]
[COLOR:1:4:7:0:1:0:0:0:0:0:0:0:0:0:7:0:1]
[COLOR:1:5:0:0:0:7:0:1:0:0:0:0:0:0:0:0:0]
[TILE:2:1:219:32:223:223:219]
[TILE:2:2:221:43:43:32:222]
[TILE:2:3:32:32:32:32:32]
[TILE:2:4:221:32:43:32:222]
[TILE:2:5:219:32:32:32:219]
[COLOR:2:1:7:0:1:0:0:0:7:0:1:7:0:1:7:0:1]
[COLOR:2:2:7:0:1:7:0:1:7:0:1:0:0:0:7:0:1]
[COLOR:2:3:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0]
[COLOR:2:4:7:0:1:0:0:0:7:0:1:0:0:0:7:0:1]
[COLOR:2:5:7:0:1:0:0:0:0:0:0:0:0:0:7:0:1]
[TILE:3:1:219:223:43:223:219]
[TILE:3:2:221:11:162:47:222]
[TILE:3:3:43:37:64:47:43]
[TILE:3:4:221:37:128:47:222]
[TILE:3:5:219:220:43:220:219]
[COLOR:3:1:7:0:1:7:0:1:7:7:1:7:0:1:7:0:1]
[COLOR:3:2:7:0:1:7:0:1:7:0:1:7:0:1:7:0:1]
[COLOR:3:3:7:7:1:7:0:1:7:0:1:7:0:1:7:7:1]
[COLOR:3:4:7:0:1:7:7:1:7:0:1:7:0:1:7:0:1]
[COLOR:3:5:7:0:1:7:0:1:7:7:1:7:0:1:7:0:1]
reaction

Code: [Select]

[REACTION:LUA_HOOK_UPGRADE_BUILDING_HUMAN_WORKSHOP_HUMAN_TIME]
[NAME:*TIME TEST*]
[BUILDING:WORKSHOP_BASE:NONE]
[PRODUCT:100:0:BOULDER:NONE:INORGANIC:UPGRADE_BUILDING_WORKSHOP_HUMAN_TIME]
[PRODUCT:100:500:COIN:NONE:INORGANIC:GOLD]
inorganic

Code: [Select]


[INORGANIC:UPGRADE_BUILDING_WORKSHOP_HUMAN_TIME]
[USE_MATERIAL_TEMPLATE:STONE_VAPOR_TEMPLATE][SPECIAL][MATERIAL_VALUE:0]
[SYNDROME]
[SYN_CLASS:here]
[SYN_CLASS:WORKSHOP_HUMAN]
[SYN_CLASS:50]

[Roses]

Interestingly enough it is because of the extra product. Just tried my exact raws with adding the extra coin product and it did change it, but did not change it back. I have no idea why the extra product would be causing it to behave like this. I will see what I can do.

EDIT: Actually, I believe it is because it runs a seperate instance of the script for *each* product. Which means it is actually changing, changing back, then changing back again. I will have to think of a fix for this, although I am unsure of a good way to do it.

EDIT2: Yeah, for now if you can figure out a way to accomplish what you wanted to accomplish without the second product, that would be good.

[Meph]

Yes, easily.

Reaction 1 takes RaceSpecificItem1, makes 500 gold and RaceSpecificItem2. RaceSpecificItem2 is used on automatic reaction to upgrade building. Essentially this:

 - Buy "Goblin Merchant licence" from Goblins.
 - Go to "empty merchant stall".
 - Run reaction "rent out shop", get 500 gold.
 - Create item "Goblin Merchant"
 - Run reaction "*Merchant is setting up shop*" - Automatic
 - Reaction upgrades workshop to "Goblin Merchant Stall" - for 3/6/9/12 months.

Its just one automatic workstep more.

[Meph]

ROSES, YOU CRAZY PERSON!

Because I updated to 1.1, the syntax changed for teleporters and liquid spawning. Fixed both, read through the teleport script. ... Interaction based teleportation to a random room. 

I say three things:
1. Mass Recall (Starcraft-style, teleport all units back home.)
2. Panic Button (When fleeing, trigger teleport home. Linked to itemsyndrome item.)
3. Teleporting invaders. (I can think of so many fun ideas with that.)

Thats awesome. In case its not clear, calling you a crazy person was meant as a compliment.

EDIT: While testing the teleporter I noticed one thing: Teleporting units with syn_class:unit does take the worker, and nearby pets, but not nearby citizens. Is that intended?

EDIT2: Reading through the entire readme atm. A couple of questions:

1. Wrapper. It can add any token from the token.txt to a target? Even those not supported by CE_ADD_TAG ? Lets say you want to add TRAINABLE_WAR to any creature on a workshop/nearby, how would that look? I dont completely understand the example with @ in it. An example inorganic for workshop use would be great.

Code: [Select]

[INORGANIC:TRAINABLE_WAR]
    [USE_MATERIAL_TEMPLATE:STONE_VAPOR_TEMPLATE]
    [SYNDROME]
        [SYN_CLASS:\AUTO_SYNDROME]
        [SYN_CLASS:\COMMAND]
 [SYN_CLASS:???]
I ask, because the token adding and the delay@1000 can be used to alter the duration of a reaction. Unit goes in, turns immobile, waits with delay, then does an interaction that triggers createitem, and voila, you can set a timer on when a reaction is supposed to finish. All without that transformation/full-heal/drop-all-gear nonsense.

2. What exactly is a "Silence Effect"? At silence@SILENCE_NATURE...

The entire wrapper script seems to allow all kinds of things, from a very complicated combat system, to a very complicated guild system. Enough to completely swamp one person, thats more something of a community project I guess... fully implementing guilds.

3. Changetile. If I assume correctly, it could be used to freeze water or cause frostbite. Could you please post an example of the syntax to affect tiles one z level ABOVE the worker/unit? I am thinking about a "refrigaration unit" workshop that can freeze water above it if active.

SYN_CLASS:changetile
SYN_CLASS:plan
SYN_CLASS:\WORKER_ID
SYN_CLASS:freeze_large(.txt)
SYN_CLASS:temperature
SYN_CLASS:7600
SYN_CLASS:500

But I dont know how to set up the freeze_large.txt to cover the z level above, instead of freezing/killing the worker.

4. Changetile again. Can it be used to "mine" an area? Artificially replace the inorganic tiles around it with open space, with/without dropping boulders/ores/gems?

5. imbueitem. Not sure if you already had the thought, but it can also be used to curse enemy weapons, or let them rust.

6. can projectile be used for very rare "meteor showers" ? weather that drops boulders on the surface?

7. projectile again. I saw how to make a unit the source of a projectile, but the direction is hardcoded? I cant make another unit on the map the target? (for example using interactions and line of sight) ? But this looks like some seriously cool new siege engines, even with hardcoded direction.

8. Lol, your example for upgradeitem seems to upgrade the suit of leather armor from MDF into a plated hide from kobolds, which is not remotely an upgrade. ^^

Thats all. I only looked at upgradebuilding and upgradeitem previously, but now that I read through everything... Wow, thats pretty awesome.

[Roses]

No it should take nearby citizens too, in fact it should take any units nearby, friend or foe. I will look into it.

1. No, unfortunately it can't add the tags as those are part of the creatures raws (although they may be editable, I haven't tried. It's possible that they will stay changed until another load from the raws, which I think only happens at the start of the game. Maybe I should try making a changeraws script, with the caveat that they won't be permanent changes). What it does do is allow you to check for those tags in the interaction, so that you could, for example, only target flying units, or trainable units.

2. The silence is a way to check the syndrome classes of the unit using the interaction. If they have a listed syndrome class, the script will not run. So if I have an interaction with silence@SILENCE_NATURE, if the unit gets the SILENCE_NATURE syndrome class from another interaction, they will be unable to use the one with the silence on it.

I was in the middle of writing a bunch of example interactions, but then I got discouraged because I wanted to wait for the new release and see how many changes there were, but yes the wrapper script offers A LOT of customization, probably more than is reasonable in fact, but DF is anything but reasonable so I think it works out 

3. Ah, good suggestion, right now it isn't possible, as it only effects the current z-level. I will make a few adjustments and add it as an option. I should do the same for the eruption script too.

One thing to note is that changing temperatures is wacky. Sometimes the change lasts for the full desired length, sometimes it changes back rather quickly. I have tried fiddling with different variables but to no avail (was hoping turning update temperature to false would allow it to stay one temperature, but it appears to get set back to true after some time. Maybe if I have the script periodically turn the temperature back over the course of the change it will work better?). I mainly only used it to give creatures frostbite and as a "ray of frost" type spell, but it should freeze water, for at least a little bit.

4. It is possible to do such a thing, but when I tried it caused a lot of pathing issues and such. It may be that there are different variables and such that I have to change as well, I can look into it.

5. Yep I have a couple "rust" type spells

6. The short answer is, yes it can. The long answer is, it isn't currently set up to optimally do this. It is actually something I want to add (I was thinking just a small area of effect for things like a "Blizzard" spell, but I will add a map wide option as well).

7. You can make another unit the target, the trick with having both the origin unit and target unit is that you need the wrapper script (and that it still suffers from the issue of not always getting the correct unit). And you need your CDI to have a CDI:VERB (see previous discussions in this thread for why you have to have that). Below is an example that should work.

Code: [Select]

[SYN_CLASS:wrapper]
[SYN_CLASS:script@projectile]
[SYN_CLASS:args@unit;!UNIT;AMMO/ITEM_AMMO_BOLTS;STEEL;shoot;1/20/50/10/1;!SELF]
8 I just copied two armors, didn't look at what they were.

Thanks for the compliment, over all I would say I am pretty happy with how some of the scripts have turned out, some of them not so much, but I will keep working on them. The major thing, and really the biggest obstacle to me writing new scripts now is the "Can't always get the casting units ID in a [USAGE_HINT:ATTACK] interaction"

[Meph]

3. Ah, good suggestion, right now it isn't possible, as it only effects the current z-level. I will make a few adjustments and add it as an option. I should do the same for the eruption script too.

While at this: Eruption is quite dangerous as well, obviously it kills the worker if he is not magmaproof. I was thinking of a workshop like a screw pump, with the worktile on the left, a solid tile in the center and a "spawn tile" on the right. The eruption would be 1 7/7 tile, but a few tiles away from the worker. Maybe with a duration as well?

It should really just simulate a screw pump. Create 10 times 1 7/7 of magma, with a certain wait-time in between, so you run the reaction once, and the worker survives, and a few tiles away the game will spawn magma for a few tiles, like an aquifer. If done in a 5x5 workshop, the distance could be x-3, 3+3, y-3 or y+3, and I could name the reactions "Spawn magma (North)", east, south, west...

Then you just build the workshop next to a channel and have a way better control about how to use the liquids. You could also use it to dump magma over edges on your walls.

Oh, and with the timed buildingupgrade it can even get better. Anyway, I could write this myself, by simply copying the script 4 times and adding "+x" to the positions in it. If you want I just do it that way, but I thought you find a more elegant solution. SYN_CLASS:0/0, with the numbers being X/Y to determine the distance of the spawn tile.

[Roses]

Yes, for now you can do it by just copying if you want, but I think I want to add an option for all of my location based scripts to change the source. I know right now I can already have it affect a radius or in lines and all of that, but it all suffers from being on top of a unit. I will think of a nice way to add offsets in all three directions. (Raining magma?)

[Meph]

One cool thing would be generating walls. You know how classical RPGs and dungeon crawlers have stuff like "wall of fire"?

Imagine a dwarf wizard that spawns a 10x1 wall of obsidian (water+magma 1 tick later). Suddenly some enemies are encased in obsidian, the rest has to path around the wall, and it protects from archers.

Or an ice wizard that, when heavily injured and fleeing, casts a 3x3 block of ice, with a hollow space in the center for himself. So the 8 tiles around him turn to ice (spawn water, set temp to very low), and he is safe for a while, till the ice melts... which you could set yourself.

Edit: I just got a report, and since your scripts are the only change for dfhack in the last update, I wanted to ask here:

Was something intensive added to "eventful.onBuildingCreatedDestroyed"?

Queuing up a lot of buildings almost causes the game to crash in the newest version, and that seems the most likely culprit.

[Boltgun]

Hey, I am trying to do something similar to improve item but since you have most of what I need, would you mind if I add a case to raise the quality depending of the worker's skill?