Print

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

[Roses]

This is all looking wonderful.

Unfortunately I am going to be working quite intently over the next couple weeks on my actual job, but I hope to start to transition my scripts to the new system at the same time.

For those wondering (and I know this is a separate thread and I will let people know in my own thread) the changes that expwnent has made will involve several changes to start, but will mean a much more robust and helpful system in the future. I will do everything I can to test the various scripts and such before I release the new scripts, to limit the involvement of others, but as always I am sure there will be some issues that I have not foreseen.

The interaction-trigger will almost completely replace the syndromeTrigger script, and it will allow for a much better system of scripts. For those of you following this thread and my Dwarf Spells thread, I will be updating all of my scripts as I have the chance, and hopefully you individual modders won't have much work to do to switch over.

One thing I would like to say is that this system, as far as I can tell, is going to be a great benefit to DF and DFHack in general. I know several of you may be resistant to the changes mentioned in this thread, but truly it is something that needs to take place, and it is better now than later. I am also sure that expwnent and myself (along with other scripters and modders) would be happy to help converting old system scripts into the new system, so that everyone can benefit from all of the new wonders.

[Meph]

It it possible to use the reaction id instead of the syndrome name to trigger it? And what happens to ProbabilityTrigger?

AutoSyndrome and the new Registration system seems to trigger 100% of the time, McTeellox system allows more balancing, with percentages and "else/if". But it relies on AutoSyndrome boulders, so it will break. Do you think the features can be included in the new registration system?

[expwnent]

Syndromes have integer ids, but there's no way to find them until you actually run the game. The only reliable way to identify them is with names. Sometimes they're attached to a boulder, but not always. If you want to make a gila monster bite reaction, you can do that with the system as it is.

I'll add a probability script.

[expwnent]

Probability script is added in the r5e1 thread.

[Roses]

Starting to work on moving over my scripts. Picked an easy one to start with, wanted to get your opinion before I continue

Code: [Select]

--change-values.lua v1.0
--[[TODO
--]]

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(etype,unitTarget,ctype,strength,save)
return function(reseteffect)
effect(etype,unitTarget,ctype,strength,save,-1)
end
end

function effect(e,unitTarget,ctype,strength,save,dir)
local value = 0
local t = 0
local int16 = 30000
local int32 = 200000000
if (e == 'webbed' or e == 'stunned' or e == 'winded' or e == 'unconscious' or e == 'pain'
or e == 'nausea' or e == 'dizziness') then t = 1 end
if (e == 'paralysis' or e == 'numbness' or e == 'fever' or e == 'exhaustion'
or e == 'hunger' or e == 'thirst' or e == 'sleepiness') then t = 2 end
if e == 'blood' then t = 3 end
if e == 'infection' then t = 4 end
if (e == 'hunger' or e == 'thirst' or e == 'sleepiness') then e = e .. '_timer' end

if t == 1 then
value = unitTarget.counters[e]
if dir == 1 then save = value end
if ctype == 'fixed' then
value = value + strength
elseif ctype == 'percent' then
local percent = (100+strength)/100
value = math.floor(value*percent)
elseif ctype == 'set' then
value = strength
end
if value > int16 then value = int16 end
if value < 0 then value = 0 end
if dir == -1 then value = save end
unitTarget.counters[e] = value
elseif t == 2 then
value = unitTarget.counters2[e]
if dir == 1 then save = value end
if ctype == 'fixed' then
value = value + strength
elseif ctype == 'percent' then
local percent = (100+strength)/100
value = math.floor(value*percent)
elseif ctype == 'set' then
value = strength
end
if value > int16 then value = int16 end
if value < 0 then value = 0 end
if dir == -1 then value = save end
unitTarget.counters2[e] = value
elseif t == 3 then
if dir == 1 then save = value end
if ctype == 'fixed' then
value = value + strength
elseif ctype == 'percent' then
local percent = (100+strength)/100
value = math.floor(value*percent)
elseif ctype == 'set' then
value = strength
end
if value > unitTarget.body.blood_max then value = unitTarget.body.blood_max end
if value < 0 then value = 0 end
unitTarget.body.blood_count = value
elseif t == 4 then
value = unitTarget.body.infection_level
if dir == 1 then save = value end
if ctype == 'fixed' then
value = value + strength
elseif ctype == 'percent' then
local percent = (100+strength)/100
value = math.floor(value*percent)
elseif ctype == 'set' then
value = strength
end
if value > int16 then value = int16 end
if value < 0 then value = 0 end
unitTarget.body.infection_level = value
end
end

validArgs = validArgs or utils.invert({
 'help',
 'token',
 'mode',
 'value',
 'dur',
 'unit',
})

mode = mode or utils.invert({
 'fixed',
 'percent',
 'set',
})

local args = utils.processArgs({...}, validArgs)

if args.help then
 print("TODO - Help Section")
 return
end

args.unit = df.unit.find(tonumber(args.unit))
args.mode = mode[args.mode or 'set']
args.token = split(args.token,'+')
args.value = split(args.value,'+')

if args.dur and tonumber(args.dur) then
dur = tonumber(args.dur)
else
dur = 0
end

for i,etype in ipairs(args.token) do
save = effect(etype,args.unit,args.mode,tonumber(args.value[i]),0,1)
if dur > 0 then
dfhack.timeout(dur,'ticks',createcallback(etype,args.unit,args.mode,tonumber(args.value[i]),save))
end
end


My experience with Lua is limited to only what I have done with DFHack so I am sure there are several things that could be better, but I tried to follow your example scripts (with reference to the processArgs and such. Thoughts? Comments? Suggestions? Angry Ranting?

[papent]

one question I have is how much functionality is taken from the RAW modders i.e. the people who don't write scripts/plugins and do little mods and piggyback of of the plugins usings the SYN_CLASSes?

because looking at the initial example this is pretty much locking out all the entry-level modders for using some of dfhack neater plugins with this rewrite.

[expwnent]

Roses: I'll take a look in a bit.

papent: This doesn't remove any functionality, and it's actually easier to use than SYN_CLASS stuff. You just add lines to onLoad.init in your raw folder. The advanced features are mostly for scripters. No change has been made in how hard it is to write scripts. Both the old stuff and the new stuff are just ways of making scripts run when certain things happen. Once your scripts are made, you can call them from item-trigger or whatever and it will function the same as it did with itemsyndrome, and reaction-trigger will achieve the same outcomes as autoSyndrome.

[Roses]

Thanks.

Quick question, does the new item-trigger allow for triggering when invading units (or merchants) enter the map? Or is it still only on the act of equipping?

[expwnent]

Yes, I fixed that.

[Roses]

Awesome.

Have you had a chance to look over the script I posted?

[expwnent]

I was busy for a few days, then I forgot all about it. I'll take a look at it tonight.

[Roses]

No worries, I have been pretty busy as well and won't have any time until next week to start working on this again.

[expwnent]

First thing that jumps out at me is that in the effect function, you should be using if/elseif instead of many unrelated ifs, and unless t gets used in some subtle way, you should have one big if/elseif/else/end block instead of two. When possible it's best to avoid variables that only exist for control flow.

Looking at original here. I don't like special syntax for commands. I only glanced at the script but stuff like var1;var2;var3#var5^3;g is hard to read unless you know exactly what's going on. It looks like a lot of that could be replaced by just running the script multiple times or using multicmd in a trigger. No need for every script to have syntax to run itself multiple times when we have multicmd. Maybe something like

Code: [Select]

change-values blah blah -mode [add/set] -percentOrAmount [percent/amount]
 as args. Something less awkward than percentOrAmount would be better of course. If you insist on using lists, then I'd recommend the syntax

Code: [Select]

change-values -skills [ skill1 skill2 skill3 ] -amount [ 3 10 -5 ]
In that case, args.skills will be a list of skills, and args.amount will be the corresponding list of amounts.

[expwnent]

Also, in regards to the split function, if you're using the same function in many scripts, you should move it to a module. Make a file in hack/lua/blah.lua and follow the examples there. That way you only have to code it once and if you need to change it you only need to change it once. In your existing repo I get that you wanted each script to be standalone, but it's a better design this way when possible. Theoretically, you should never have to write the same code twice.

[Roses]

Yeah, as I was re-doing that script I found that having the special syntax was kind of awkward. I left it in just because I was doing a direct change, but I think you are right and I should just eliminate all the special syntax (although I do like your list idea a lot more than the special syntax, maybe I will add the option lists? not sure, I will have to think about it.)

Other than your comments on changes (I will change the if block, and get rid of the special syntax), does it look alright? Does it follow your conventions? Any other tips before I start working on my other scripts?