Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1] 2

Author Topic: DFHack Unstable Beta 0.34.11-r5e1  (Read 7648 times)

expwnent

  • Bay Watcher
    • View Profile
DFHack Unstable Beta 0.34.11-r5e1
« on: July 03, 2014, 07:57:55 pm »

Even though the most recent release was only a few weeks ago, I've done a lot since then, and I've broken backwards compatibility in many ways. Therefore I'm releasing an unstable beta version for testing purposes. Changelog

Do not download this unless you know what you are doing and you have your saves backed up.

If anyone can beta test this version I would greatly appreciate it. All the blah-trigger scripts especially need testing, but the new events could use some too. The item-trigger and interaction-trigger scripts are particularly useful.

Download Link (Windows)

Strike the scripts!

---

Also try this script: https://github.com/expwnent/dfhack/blob/scriptOrganization/scripts/modtools/random-trigger.lua
« Last Edit: July 06, 2014, 04:34:18 am by expwnent »
Logged

Roses

  • Bay Watcher
    • View Profile
Re: DFHack Unstable Beta 0.34.11-r5e1
« Reply #1 on: July 05, 2014, 12:17:18 am »

Unfortunately I have a lot of personal work that needs to get done over the next couple weeks, but I am hoping to have all of my scripts (and all of my example "spells") switched over to this new system by the end of the month.

I would just like to say that all of the DFHack scripters and raw modders should attempt to follow these new syntaxes and systems. Even though I know it is rather annoying to switch over to a new system. I truly believe that it will be best for the DF community.

EDIT: expwnent has already provided many scripts as examples, if you wish to wait a little longer, I will be re-releasing all of my scripts from the DFHack Spells thread in the new system so that you will have more examples.
Logged

expwnent

  • Bay Watcher
    • View Profile
Re: DFHack Unstable Beta 0.34.11-r5e1
« Reply #2 on: July 06, 2014, 04:34:30 am »

modtools/random-trigger script added.
Logged

expwnent

  • Bay Watcher
    • View Profile
Re: DFHack Unstable Beta 0.34.11-r5e1
« Reply #3 on: July 09, 2014, 04:38:45 am »

In the next release, scripts will be runnable from the raw/scripts folder. This means that modders can have scripts that have the same name as scripts in the main repo and they won't have to worry about them being overwritten. DFHack checks this folder first for scripts so that they take priority. The other reason for this change is that it makes it possible to send someone a savegame folder and have everything it needs come with it so that the recipient won't have to worry about installing scripts in the right place in order to play with it: they will only need to have the same version of DFHack.
Logged

Roses

  • Bay Watcher
    • View Profile
Re: DFHack Unstable Beta 0.34.11-r5e1
« Reply #4 on: July 22, 2014, 01:59:39 pm »

Looking through the various scripts in the modtools folder I noticed in the create-item.lua there is a command dfhack.items.createitem(). I haven't seen that command before, does it have any enhanced functionality, or is it simply a short cut for creating items? Does it place the items anywhere or just make them exist?

EDIT: Another question, how do syndrome-trigger and reaction-trigger pass the \LOCATION argument?

EDIT2: Another question, if an argument has no value (i.e. just -attrNoValue1 -attrNoValue2) how are the handled? Are they just set to true or to some other value?
« Last Edit: July 22, 2014, 06:05:38 pm by Roses »
Logged

expwnent

  • Bay Watcher
    • View Profile
Re: DFHack Unstable Beta 0.34.11-r5e1
« Reply #5 on: July 22, 2014, 09:16:25 pm »

Looking through the various scripts in the modtools folder I noticed in the create-item.lua there is a command dfhack.items.createitem(). I haven't seen that command before, does it have any enhanced functionality, or is it simply a short cut for creating items? Does it place the items anywhere or just make them exist?

EDIT: Another question, how do syndrome-trigger and reaction-trigger pass the \LOCATION argument?

EDIT2: Another question, if an argument has no value (i.e. just -attrNoValue1 -attrNoValue2) how are the handled? Are they just set to true or to some other value?

modtools/create-item works basically the same way as the plugin, but it uses the new dfhack.items.createitem interface, so that plugins can use the same tool as scripts.

The location argument gets expanded to three arguments for the x, y, z coordinates in that order.

If an argument has no value, it's set to the empty string, not to be confused with nil.
Logged

Roses

  • Bay Watcher
    • View Profile
Re: DFHack Unstable Beta 0.34.11-r5e1
« Reply #6 on: July 23, 2014, 12:14:41 am »

The location argument gets expanded to three arguments for the x, y, z coordinates in that order.

Does that mean if I have;

Code: [Select]
modtools/reaction-trigger -reactionName TURN_INTO_CHICKEN -command shape-change -location \LOCATION -creature CREATURE_CHICKEN
That args.location will be a table with three elements? Or something else?
Logged

expwnent

  • Bay Watcher
    • View Profile
Re: DFHack Unstable Beta 0.34.11-r5e1
« Reply #7 on: July 23, 2014, 12:33:50 am »

No, that will fail parseArgs. You should say

Code: [Select]
modtools/reactionTrigger -reactionName TURN_INTO_CHICKEN -command [ modtools/shape-change -location [ \\LOCATION ] -creature CREATURE_CHICKEN ]
then it will have 2 elements in the table: reactionName and command. After shape-change parses its args, it will have two arg-value pairs: location and creature.
Logged

Roses

  • Bay Watcher
    • View Profile
Re: DFHack Unstable Beta 0.34.11-r5e1
« Reply #8 on: July 23, 2014, 12:38:51 pm »

Awesome, thanks.

Another question (sorry for the barrage). Is LUA_HOOK still going to be possible in the new version? I know for some of my scripts I can just easily get rid of it and add the functionality to the new system, but for some of my scripts, like this one;

Code: [Select]
--base_copyitem.lua v1.0
--[[
base_copyitem - used to make an exact copy of the item
Requires a reaction

REACTION OPTIONS:
All item reagents with [PRESERVE_REAGENT] will be flagged for copying
Reagents without the [PRESERVE_REAGENT] tag will be consumed
The reagent with the 'mat' ID will be the material the copied item is made from
If no reagent with 'mat' is found, it will use the material of the item being copied
Products will be created as normal

EXAMPLE REACTION:
[REACTION:LUA_HOOK_COPY_ITEM_EXAMPLE_1] <- LUA_HOOK_COPY_ITEM is required
[NAME:copy giant's armor]
[BUILDING:FORGARY_SMITH:NONE]
[REAGENT:A:1:ARMOR:ITEM_ARMOR_GIANTS_SPECIAL:INORGANIC:NONE][PRESERVE_REAGENT]
[REAGENT:mat:150:BAR:NONE:INORGANIC:NONE] <- will read the reagent with 'mat' for its definer as the base for the new item
[REAGENT:C:1500:COIN:NONE:INORGANIC:SILVER]
[PRODUCT:100:1:BOULDER:NONE:INORGANIC:FORGER_EXPERIANCE] <- for experiance gains, not actually needed
--]]

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 itemSubtypes(item) -- Taken from Putnam's itemSyndrome
   local subtypedItemTypes =
    {
    ARMOR = df.item_armorst,
    WEAPON = df.item_weaponst,
    HELM = df.item_helmst,
    SHOES = df.item_shoesst,
    SHIELD = df.item_shieldst,
    GLOVES = df.item_glovest,
    PANTS = df.item_pantsst,
    TOOL = df.item_toolst,
    SIEGEAMMO = df.item_siegeammost,
    AMMO = df.item_ammost,
    TRAPCOMP = df.item_trapcompst,
    INSTRUMENT = df.item_instrumentst,
    TOY = df.item_toyst}
    for x,v in pairs(subtypedItemTypes) do
        if v:is_instance(item) then
return x
end
    end
    return false
end

function copyitem(reaction,unit,input_items,input_reagents,output_items,call_native)
local itemmat = nil
for i,x in ipairs(input_reagents) do
if x.flags.PRESERVE_REAGENT then sitems[i] = input_items[i] end
if x.code == 'mat' then itemmat = input_items[i] end
end

for i,x in ipairs(sitems) do
t = itemSubtypes[x]
if t == 'WEAPON' then v = 'item_weaponst' end
if t == 'ARMOR' then v = 'item_armorst' end
if t == 'HELM' then v = 'item_helmst' end
if t == 'SHOES' then v = 'item_shoesst' end
if t == 'SHIELD' then v = 'item_shieldst' end
if t == 'GLOVE' then v = 'item_glovest' end
if t == 'PANTS' then v = 'item_pantsst' end
if t == 'AMMO' then v = 'item_ammost' end

local item=df[v]:new() --incredible
item.id=df.global.item_next_id
df.global.world.items.all:insert('#',item)
df.global.item_next_id=df.global.item_next_id+1
item:setSubtype(x.subtype.subtype)
if itemmat == nil then
item:setMaterial(x.mat_type)
item:setMaterialIndex(x.mat_index)
else
item:setMaterial(itemmat.mat_type)
item:setMaterialIndex(itemmat.mat_index)
end
item:categorize(true)
item.flags.removed=true
if t == 'WEAPON' then item:setSharpness(1,0) end
item:setQuality(input_items[i].quality)
dfhack.items.moveToGround(item,{x=unit.pos.x,y=unit.pos.y,z=unit.pos.z})
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.loadCopyItem = 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_COPY_ITEM') then
-- register reaction.code
eventful.registerReaction(reaction.code,copyitem)
-- 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('Copyable Items: 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.loadCopyItem(SC_MAP_LOADED) end
-- END Taken from hire-guard.lua

It would be easiest to just leave this as a LUA_HOOK script, since its only one declaration in the dfhack.init and it handles all reactions necessary (no special inorganics or anything is needed)
Logged

expwnent

  • Bay Watcher
    • View Profile
Re: DFHack Unstable Beta 0.34.11-r5e1
« Reply #9 on: July 24, 2014, 07:46:11 am »

As I understand it, the information you need from the raws (besides which reactions to look at) is which product to duplicate, and with what material. If I rejigger reaction-trigger I should be able to get it to pass along a list of the job item ids. In that case, you'd have to temporarily PRESERVE_REAGENT on the boulder so that it isn't deleted before reaction-trigger does the callback, then look up the boulder, grab its material, delete the boulder by setting its flags, then call create-item. How does that sound?

Something like

Code: [Select]
register-copy-item -reactionName COPY_ITEM_EXAMPLE_1
#equivalent to
#modtools/reaction-trigger -reactionName COPY_ITEM_EXAMPLE_1 -command [ copy-item-helper -items [ \\JOB_ITEM_LIST ] -worker \\WORKER_ID ]
Logged

Roses

  • Bay Watcher
    • View Profile
Re: DFHack Unstable Beta 0.34.11-r5e1
« Reply #10 on: July 24, 2014, 10:31:09 am »

Well the boulder itself is unnecessary. All the script looks for is items with [PRESERVE_REAGENT] and a reagent with the ID 'mat'. All items with [PRESERVE_REAGENT] are duplicated (TYPE:SUBTYPE) and are made of the material specified in the reagent with the ID 'mat'. If there is no reagent with that ID it just used the material of the item with [PRESERVE_REAGENT]. This means that the reaction is completely self contained and no products are necessary.
Logged

expwnent

  • Bay Watcher
    • View Profile
Re: DFHack Unstable Beta 0.34.11-r5e1
« Reply #11 on: July 24, 2014, 10:53:26 pm »

I guess it's ok. If there's no clear way to translate it into the new system, then the old system is ok, but when possible the new system should be used.
Logged

Roses

  • Bay Watcher
    • View Profile
Re: DFHack Unstable Beta 0.34.11-r5e1
« Reply #12 on: July 28, 2014, 06:16:47 pm »

A small request. Currently add-syndrome uses the syndromes name. Would it be possible to allow it to use the SYN_CLASS of the syndrome as well? This wouldn't be particularly useful for adding syndromes, but the -erase and -eraseall functionality would be greatly improved if it could remove syndromes based on their SYN_CLASS.

EDIT:
\If I rejigger reaction-trigger I should be able to get it to pass along a list of the job item ids.

Something like

Code: [Select]
register-copy-item -reactionName COPY_ITEM_EXAMPLE_1
#equivalent to
#modtools/reaction-trigger -reactionName COPY_ITEM_EXAMPLE_1 -command [ copy-item-helper -items [ \\JOB_ITEM_LIST ] -worker \\WORKER_ID ]

It would be nice if reaction-trigger could pass along the job items.
« Last Edit: July 28, 2014, 08:17:46 pm by Roses »
Logged

expwnent

  • Bay Watcher
    • View Profile
Re: DFHack Unstable Beta 0.34.11-r5e1
« Reply #13 on: July 29, 2014, 04:51:38 am »

The syndrome thing should be pretty straightforward. I'll put it on the list of things to do.

Do you need a copy of what the items were before they were destroyed? That's harder than just a list of item ids.
Logged

Roses

  • Bay Watcher
    • View Profile
Re: DFHack Unstable Beta 0.34.11-r5e1
« Reply #14 on: July 29, 2014, 09:23:20 am »

Well my actual use was just the items with PRESERVE_REAGENT on them, so that if certain conditions are met I can destroy the items (or manipulate them in some way). I know the old eventful onReactionComplete passed a list of the input items.

EDIT: So up until recently I have been testing all of my scripts on the command line just to make sure they work, but now I am trying some more complex tests and have started using the onLoad.init and reaction-trigger and I got this error
Code: [Select]
...ss\DF_r5_test\hack\scripts/modtools/reaction-trigger.lua:6: module 'syndromeU
til' not found:
        no field package.preload['syndromeUtil']
        no file 'C:\Users\Miles\Desktop\Dwarf Fortress\DF_r5_test\hack\lua\syndr
omeUtil.lua'
        no file 'C:\Users\Miles\Desktop\Dwarf Fortress\DF_r5_test\hack\lua\syndr
omeUtil\init.lua'
        no file '.\syndromeUtil.lua'
        no file 'C:\Users\Miles\Desktop\Dwarf Fortress\DF_r5_test\syndromeUtil.d
ll'
        no file '.\syndromeUtil.dll'
stack traceback:
        [C]: in function 'require'
        ...ss\DF_r5_test\hack\scripts/modtools/reaction-trigger.lua:6: in main c
hunk
        (...tail calls...)
I assume it is just because in the download you provided it is named syndrome-util. I fixed it by changing the name to syndromeUtil and then the corresponding line in the file, but this also caused problems with add-syndrome since it actually wanted syndrome-util not syndromeUtil.

Also, where are the locations onLoad.init can go?
« Last Edit: July 29, 2014, 09:17:05 pm by Roses »
Logged
Pages: [1] 2