Print

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

[expwnent]

PS: I don't see the new event stuff on github.

[Roses]

The UNIT_ATTACK thing was really minor, and is already handled with in game mechanics + interaction trigger (i.e. specifying an interaction to use a specific body part).

The vector of items created by a reaction and or used in a reaction would be a huge help. Right now some of my scripts still rely on the old LUA_HOOK system because they need the items. It would also be nice to specify items be removed if a reaction was successful or conversely, saved if a reaction was unsuccessful (for instance, I try to change my dwarf to another class, but they don't meet the requirements so the reagents for the change aren't used), which should be doable if the items are known.

I don't think there is anything else off the top of my head. There are some scripts I want, but they are ones that I can do myself and will get around to doing sometime relatively soon.

And yeah, the Event System hasn't been uploaded yet, there were a couple problems that crept up that I need to figure out, I don't think anyone would encounter them in typical usage, but they are there so they should be handled.

[expwnent]

If you have a nice clean version of the unit spawning script and/or any extensions of it that would be nice. It's about time that went in the main repo.

The vector of items should be possible, it's just a pain and requires breaking one of the fundamental assumptions I had when writing EventManager so technically I should rewrite a lot of it to avoid that assumption but I could just do one ad-hoc thing and make it work. The annoying bit is making sure it only fires once.

It is possible to fully parse out the attack string into useful bits, including the attacking part and the unit attack used, but it would break any time combat log text changes and it would require understanding exactly the right format.

I have a slight optimization to some of your code that also make it look nicer. The following is perfectly fine:

Code: [Select]

local persistent = require 'persist-table'
local roseTable = persistent.GlobalTable.roses
local unitTable = roseTable.UnitTable
local classTable = roseTable.ClassTable

--instead of
--local bob = classTable[something]['asdf']
local bob = classTable[something].asdf

The only problem comes if the game unloads between when you get a persistent table and when you do something with it. If you're inside some Lua function and you're just doing local stuff that can't happen. If you say table.foo.bar.blah = 2, table.foo.bar.blah2 = 3, etc, it has to actually traverse the internal tables every time.

Also you should really try avoiding things like

Code: [Select]

if split(x,blah)[1] == 'string1' then
elseif split(x,blah)[1] == 'string2' then
elseif split(x,blah)[1] == 'string3' then
endif

--instead try this
local splits = split(x,blah)
if splits[1] == 'string1' then
elseif splits[1] == 'string2' then
elseif splits[1] == 'string3' then
endif

That way you cache the old result. The code in question only runs occasionally so it won't affect framerate but it's still a bit of a bad habit.

edit: I think maybe a good way of doing it would be to have a "new item" event and a "reaction product" event and have them be completely separate. Does that sound good? You could still keep track of items that come from invaders or merchants that way.

[Putnam]

(and string equality checking in lua is O(1), so don't worry about that in particular)

[expwnent]

(and string equality checking in lua is O(1), so don't worry about that in particular)

That's excellent. I do worry about that sometimes but I shall worry no more!

[Roses]

If you have a nice clean version of the unit spawning script and/or any extensions of it that would be nice. It's about time that went in the main repo.

I do not, I have a version that I have been tinkering with, but its pretty much in shambles. It's one of the things I need to get up and running.

The vector of items should be possible, it's just a pain and requires breaking one of the fundamental assumptions I had when writing EventManager so technically I should rewrite a lot of it to avoid that assumption but I could just do one ad-hoc thing and make it work. The annoying bit is making sure it only fires once.

edit: I think maybe a good way of doing it would be to have a "new item" event and a "reaction product" event and have them be completely separate. Does that sound good? You could still keep track of items that come from invaders or merchants that way.

The tracking of items, in any form, would be much appreciated. If it is easiest to do through a new-item trigger and a reaction product event separately than that is just fine.

It is possible to fully parse out the attack string into useful bits, including the attacking part and the unit attack used, but it would break any time combat log text changes and it would require understanding exactly the right format.

Yeah, I personally don't think the UNIT_ATTACK thing is worth the time investment, but if you are interested in doing it I'm not going to stop you

I have a slight optimization to some of your code that also make it look nicer. The following is perfectly fine:

Code: [Select]

local persistent = require 'persist-table'
local roseTable = persistent.GlobalTable.roses
local unitTable = roseTable.UnitTable
local classTable = roseTable.ClassTable

--instead of
--local bob = classTable[something]['asdf']
local bob = classTable[something].asdf

The only problem comes if the game unloads between when you get a persistent table and when you do something with it. If you're inside some Lua function and you're just doing local stuff that can't happen. If you say table.foo.bar.blah = 2, table.foo.bar.blah2 = 3, etc, it has to actually traverse the internal tables every time.

I have actually redone a little of the persistent stuff since my last upload, so that instead of needing to put base/classes for the class system and base/civilization for the civilization system in onLoad.init, all you have to do is roses-init and then give the modules you want to load (i.e. roses-init -classes -civilizations -events -upgradeableBuildings etc... or just roses-init -all). Part of that change has been to clean up some of what I have already done in other scripts. So that change you suggest is a good idea. I will make sure to implement that.

Also you should really try avoiding things like

Code: [Select]

if split(x,blah)[1] == 'string1' then
elseif split(x,blah)[1] == 'string2' then
elseif split(x,blah)[1] == 'string3' then
endif

--instead try this
local splits = split(x,blah)
if splits[1] == 'string1' then
elseif splits[1] == 'string2' then
elseif splits[1] == 'string3' then
endif

That way you cache the old result. The code in question only runs occasionally so it won't affect framerate but it's still a bit of a bad habit.

Bad habit? It's terrible. I mean, I doubt you will see any speed improvement since the strings aren't very long and the split function is very efficient, but still, I should know better than calling a function repeatedly when it only needs to be called once.

[Roses]

Just a small update, I have finally finished writing a system that allows dfhack.timeout() calls to persist between save/load. It is amazingly simple, with only two parts

Code: (lua/persist-delay.lua) [Select]

local persistTable = require 'persist-table'

function persistantDelay(ticks,script)
 local currentTick = 1200*28*3*4*df.global.cur_year + df.global.cur_year_tick
 local runTick = currentTick + ticks
 local persistDelay = persistTable.GlobalTable.roses.PersistTable
 local number = #persistDelay._children
 persistDelay[tostring(number+1)] = {}
 persistDelay[tostring(number+1)].Tick = tostring(runTick)
 persistDelay[tostring(number+1)].Script = script
 dfhack.timeout(ticks,'ticks',function () dfhack.run_script(script) end)
end

return persistantDelay

Code: (scripts/persist-delay.lua) [Select]

local split = require('split')
local utils = require 'utils'
local persistTable = require 'persist-table'
persistTable.GlobalTable.roses.PersistTable = persistTable.GlobalTable.roses.PersistTable or {}

local persistDelay = require 'persist-delay'
local delayTable = persistTable.GlobalTable.roses.PersistTable
for _,i in pairs(delayTable._children) do
 local delay = delayTable[i]
 local currentTick = 1200*28*3*4*df.global.cur_year + df.global.cur_year_tick
 if currentTick >= tonumber(delay.Tick) then
  delay = nil
 else
  local ticks = delay.Tick-currentTick
  dfhack.timeout(ticks,'ticks',function () dfhack.run_script(delay.Script) end)
 end
end
Then all you need to do to run it in your own script is to use

Code: [Select]

delay = require 'persist-delay'
delay(ticks,script)Where ticks is the number of ticks you want the game to wait, and script is the command line script you want to run.

And to make sure they are correctly queued up on load, just put persist-delay in onLoad.init

Note that this isn't quite the same as dfhack.timeout since it currently only supports in game tick delays, and will only run scripts through dfhack.run_script(), not arbitrary functions.

@expwnent, I think something like this would be helpful to put in the main repository, I'm sure some changes could be made to make it more useful and pretty.

[expwnent]

That's definitely something that would be useful.

My first thought is that it would be nice if there were some automatic way of ensuring that scripts/persist-delay.lua is run if there was at least one persistent delay in the save. When possible it's better to not make people remember unnecessary things because sooner or later people will forget and then their events won't fire. We'd get a lot of new modders confused because they didn't put the right line in onLoad.init when DFHack should be able to do it automatically.

If you use world.frame_counter instead of doing arithmetic with cur_year and cur_year_tick then it will also work in arena mode. frame_counter is confusingly named. It's actually the tick counter since the game was loaded (or maybe since ever, I forget).

Executing arbitrary functions is possible with some very heavy machinery on the C++ side but the cheating way is to just convert the function to a string and use devel/anonymous-script so it should work fine as is. It's rare someone would want it anyway.

[Roses]

That would be nice to not need to place it in the onLoad.init. Since I was just making it for my mods I didn't even think about it, and am not even sure how to make that happen without making it a part of the C++ library.

I did not know about world.frame_counter, I was looking for that information, good to know! But if it is only sense the game was loaded then every time you load it would be reset to zero, which wouldn't particularly help.

EDIT: @expwnent
Do you know why

Code: [Select]

dfhack.run_script('unit/body-change -unit 3399 -temperature fire -all')Is giving me an error? Just putting the string directly in the command line works fine

[Putnam]

You need to separate the arguments out as arguments in the function.

[Roses]

expwnent answered in the other thread (I know, bad form to ask in two places). It works if I change run_script to run_command

[expwnent]

Roses: any thoughts on this? I think if it's properly implemented it could simplify and accelerate a lot of your stuff.

[Putnam]

I personally would benefit greatly from that; as of right now, the class system requires a few files in the hack/lua folder, which prevents me from making Fortbent as mergeable through the DF starter pack as I want it to be (I.E fully).

Well, that and friendship.o not usually being distributed with DFHack despite being required for friendship, but that's going to be a moot point as soon as 0.41.01 is released.

[expwnent]

That's a good point. It would also help toward the goal of being able to transfer saves between installations of DFHack that don't have the same mods installed.

DFusion is old enough there's likely other ways of doing the things it did by now. Are you sure you need it?

[Putnam]

I cannot find anything that does what friendship does (allow multi-race forts). Next DF version does, so I'll probably only upgrade if an upgrade exists (otherwise I'll just wait for the upgrade instead of bothering with making a new version, since it'll be obsolete soon after).