Bay 12 Games Forum

Please login or register.

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

Author Topic: Future of MDF  (Read 9838 times)

Protonicus

  • Bay Watcher
    • View Profile
Re: Future of MDF
« Reply #15 on: July 13, 2018, 02:42:53 am »

I am playing the dwarf mode mostly and now after some pause I am waiting to start with proper release.
Making empire and settle (colonize/conquer) world is quite sweet to me in between dwarf town raising.
Starting new site with dwarves I already prepeared in-game what is I am waiting from it release.
And it also seems as good alternative from abandoning site from fps death.

So crossed the fingers and waiting for the combination of last DF and Masterwork to use old good masterwork features and maybe improving newest features if possible.
Logged

KittyTac

  • Bay Watcher
  • Impending Catsplosion. [PREFSTRING:aloofness]
    • View Profile
Re: Future of MDF
« Reply #16 on: July 13, 2018, 02:55:01 am »

Keep improving and updating the other races. I'm not interested in dorfs.
« Last Edit: July 13, 2018, 02:57:10 am by KittyTac »
Logged
Don't trust this toaster that much, it could be a villain in disguise.
Mostly phone-posting, sorry for any typos or autocorrect hijinks.

Wyzack

  • Bay Watcher
    • View Profile
Re: Future of MDF
« Reply #17 on: July 13, 2018, 09:25:00 am »

I just figured that they will pretty quickly fall out maintenance or else see more and more features atrophy as the scripting becomes outdated, like how we lost the ability to convert people to guardsmen or squires, the ability to teach your humans magic if you could score a Warlock permit, or the diplomats guild of old where you could spam "Make War With X" and get massive sieges. (pretty sure that last one went the way of the dodo because armies actually travel on the world map now rather than springing to life at the edge of your map once your pop/worth is high enough)

If you are planning on porting them as is to the newest versions of Dwarf Fortress that is actually fucking fantastic news and I cant wait!
Logged

Meph

  • Bay Watcher
    • View Profile
    • worldbicyclist
Re: Future of MDF
« Reply #18 on: July 13, 2018, 10:31:55 am »

I just figured that they will pretty quickly fall out maintenance or else see more and more features atrophy as the scripting becomes outdated, like how we lost the ability to convert people to guardsmen or squires, the ability to teach your humans magic if you could score a Warlock permit, or the diplomats guild of old where you could spam "Make War With X" and get massive sieges. (pretty sure that last one went the way of the dodo because armies actually travel on the world map now rather than springing to life at the edge of your map once your pop/worth is high enough)

If you are planning on porting them as is to the newest versions of Dwarf Fortress that is actually fucking fantastic news and I cant wait!
That is sadly all true. Especially about the old scripts that don't work anymore.

I wish I could resurrect Warlocks... but Toady even changed how the AI uses interactions, and they wont use about 80% of their features because of that.
Logged
::: ☼Meph Tileset☼☼Map Tileset☼- 32x graphic sets with TWBT :::
::: ☼MASTERWORK DF☼ - A comprehensive mod pack now on Patreon - 250.000+ downloads and counting :::
::: WorldBicyclist.com - Follow my bike tours around the world - 148 countries visited :::

friendo

  • Bay Watcher
    • View Profile
Re: Future of MDF
« Reply #19 on: July 14, 2018, 09:55:44 am »

Exciting, would love to continue playing MW Humans in newer versions of DF.  Guess i'm going for the "vicarious" experience of playing as humans in a living fantasy world.  I understand, however, that i'm in a minority on that one.
Logged

Metall

  • Bay Watcher
    • View Profile
Re: Future of MDF
« Reply #20 on: July 15, 2018, 11:50:38 am »

I just figured that they will pretty quickly fall out maintenance or else see more and more features atrophy as the scripting becomes outdated, like how we lost the ability to convert people to guardsmen or squires, the ability to teach your humans magic if you could score a Warlock permit, or the diplomats guild of old where you could spam "Make War With X" and get massive sieges. (pretty sure that last one went the way of the dodo because armies actually travel on the world map now rather than springing to life at the edge of your map once your pop/worth is high enough)

If you are planning on porting them as is to the newest versions of Dwarf Fortress that is actually fucking fantastic news and I cant wait!
That is sadly all true. Especially about the old scripts that don't work anymore.

I wish I could resurrect Warlocks... but Toady even changed how the AI uses interactions, and they wont use about 80% of their features because of that.


Oh crap, that puts a damper on Succubi as well. Dang that sucks... Oh well, can't wait to see how they put magic systems into the game, then we can really start cooking with gas.
Logged

KittyTac

  • Bay Watcher
  • Impending Catsplosion. [PREFSTRING:aloofness]
    • View Profile
Re: Future of MDF
« Reply #21 on: July 15, 2018, 11:59:22 am »

Procgen magic will be great.
Logged
Don't trust this toaster that much, it could be a villain in disguise.
Mostly phone-posting, sorry for any typos or autocorrect hijinks.

Meph

  • Bay Watcher
    • View Profile
    • worldbicyclist
Re: Future of MDF
« Reply #22 on: July 15, 2018, 12:53:53 pm »

Considering that Succubi are done by boltgun (and orcs by smakemupagus), I'd say neither of them are at any risk. Both are developed for vanilla DF too.
Logged
::: ☼Meph Tileset☼☼Map Tileset☼- 32x graphic sets with TWBT :::
::: ☼MASTERWORK DF☼ - A comprehensive mod pack now on Patreon - 250.000+ downloads and counting :::
::: WorldBicyclist.com - Follow my bike tours around the world - 148 countries visited :::

KittyTac

  • Bay Watcher
  • Impending Catsplosion. [PREFSTRING:aloofness]
    • View Profile
Re: Future of MDF
« Reply #23 on: July 15, 2018, 11:17:34 pm »

Maybe someone needs to take up kobolds? There are a lot of kobold fans around here.
Logged
Don't trust this toaster that much, it could be a villain in disguise.
Mostly phone-posting, sorry for any typos or autocorrect hijinks.

Wyzack

  • Bay Watcher
    • View Profile
Re: Future of MDF
« Reply #24 on: July 17, 2018, 12:41:54 pm »

Good old Warlocks. Nothing else played like them, it was such a blast to have a core of powerful pseudo immortal spellcasters accumulating magical knowledge and assembling greater and greater numbers of skeletal warriors and workers. The whole scalp binding for books mechanic was a great timegate too because it meant that you couldnt not rush the more powerful magical spells without getting into conflict with some sapients like elves and dwarves. I was pretty disappointed to hear that they were dropped in favor of a new necromancers plan, even if it didnt end up panning out, but i totally understand. Even in the game version that supported it the stuff was still buggy as hell, especially ghoul conversion of hostile entities, and some construction recipes like building a bone golem, as they would only be half loyal to your civ.

Maybe one day if the base game ever gets to a point where DFHACK is stable for a year or two we might have someone re-discover the ability to make all those reactions and have glorious evil wizard race fortress once again
Logged

Putnam

  • Bay Watcher
  • DAT WIZARD
    • View Profile
Re: Future of MDF
« Reply #25 on: July 19, 2018, 01:07:22 am »

All the DFHack features that allowed for warlocks are still stable and usable AFAIK. All the scripts in DFHack get updated with DFHack unless there's massive under-the-hood changes (siege forcing in 0.40.01).

Meph

  • Bay Watcher
    • View Profile
    • worldbicyclist
Re: Future of MDF
« Reply #26 on: July 20, 2018, 08:31:28 am »

If you can tell me how to target creatures inside of/next to workshops with a script, which is triggered by a different unit that runs a reaction in said workshop..
Logged
::: ☼Meph Tileset☼☼Map Tileset☼- 32x graphic sets with TWBT :::
::: ☼MASTERWORK DF☼ - A comprehensive mod pack now on Patreon - 250.000+ downloads and counting :::
::: WorldBicyclist.com - Follow my bike tours around the world - 148 countries visited :::

Putnam

  • Bay Watcher
  • DAT WIZARD
    • View Profile
Re: Future of MDF
« Reply #27 on: July 22, 2018, 02:23:23 pm »

If you can tell me how to target creatures inside of/next to workshops with a script, which is triggered by a different unit that runs a reaction in said workshop..

this is not a working script, but it has everything that that needs to work

Code: [Select]
local validArgs = utils.invert({
 'command',
 'distance',
 'unit',
 'miscargs'
})

if moduleMode then
 return
end
local args = utils.processArgs({...}, validArgs)

local function distance2D(pos1,pos2)
    return math.sqrt((pos1.x-pos2.x)^2+(pos1.y-pos2.y)^2)
end

local unit1=df.unit.find(args.unit)

for k,unit2 in ipairs(df.global.world.units.active) do
    if unit1.pos.z==unit2.pos.z and distance2D(unit1.pos,unit2.pos)<tonumber(args.distance) then
        dfhack.run_command(args.command,'-unit',unit2.id,table.unpack(args.miscargs))
    end
end

this isn't particularly likely to work in any reasonable regard, but it's a stepping point

thefriendlyhacker

  • Bay Watcher
    • View Profile
Re: Future of MDF
« Reply #28 on: July 23, 2018, 05:08:22 am »

If you can tell me how to target creatures inside of/next to workshops with a script, which is triggered by a different unit that runs a reaction in said workshop..
I modified the reaction-trigger script a while back to do exactly that so I could use it for giving cybernetics/drugs to other units, rehabilitating slaves etc in FoE.  Here:
Code: [Select]
-- trigger commands when custom reactions complete
-- author expwnent, tweaks by thefriendlyhacker
-- replaces autoSyndrome
--@ module = true
local usage = [====[

foe/reaction-trigger
=========================
Triggers dfhack commands when custom reactions complete, regardless of whether
it produced anything, once per completion.  Arguments::

    -clear
        unregister all reaction hooks
    -reactionName name
        specify the name of the reaction
    -syndrome name
        specify the name of the syndrome to be applied to the targets
    -allowNonworkerTargets
        allow other units to be targeted if the worker is immune or ignored. Only one is affected by a syndrome
        commands must be paired with syndromes, or the command will execute on some/all creatures within range.
        overridden by -allowMultipleTargets
    -allowMultipleTargets
        allow all targets within range to be affected by the command or syndrome
        if absent:
            if running a script, only one target will be used
            if applying a syndrome, then only one target will be infected
    -ignoreWorker
        does not target the worker.  Only makes sense with -allowMultipleTargets or -allowNonworkerTargets.
    -range [ x y z ]
        controls how far elligible creatures can be from the workshop.  Defaults to [ 0 0 0 ] (within the workshop). 
        Negative x/y numbers can be used to ignore outer squares of the workshop.  The worker is always within range. 
        Line of sight is not respected.
    -resetPolicy policy
        the policy in the case that the syndrome is already present
        policy
            NewInstance (default)
            DoNothing
            ResetDuration
            AddDuration
    -command [ commandStrs ]
        specify the command to be run on the target(s).
        if a syndrome is also provided, the command will not execute on targets that are invalid for the syndrome.
        special args
            \\WORKER_ID
            \\TARGET_ID
            \\BUILDING_ID
            \\LOCATION
            \\REACTION_NAME
            \\anything -> \anything
            anything -> anything

]====]
local eventful = require 'plugins.eventful'
local syndromeUtil = require 'syndrome-util'
local utils = require 'utils'

reactionHooks = reactionHooks or {}

eventful.enableEvent(eventful.eventType.UNLOAD,1)
eventful.onUnload.reactionTrigger = function()
 reactionHooks = {}
end

function getWorkerAndBuilding(job)
 local workerId = -1
 local buildingId = -1
 for _,generalRef in ipairs(job.general_refs) do
  if generalRef:getType() == df.general_ref_type.UNIT_WORKER then
   if workerId ~= -1 then
    print(job)
    printall(job)
    error('reaction-trigger: two workers on same job: ' .. workerId .. ', ' .. generalRef.unit_id)
   else
    workerId = generalRef.unit_id
    if workerId == -1 then
     print(job)
     printall(job)
     error('reaction-trigger: invalid worker')
    end
   end
  elseif generalRef:getType() == df.general_ref_type.BUILDING_HOLDER then
   if buildingId ~= -1 then
    print(job)
    printall(job)
    error('reaction-trigger: two buildings same job: ' .. buildingId .. ', ' .. generalRef.building_id)
   else
    buildingId = generalRef.building_id
    if buildingId == -1 then
     print(job)
     printall(job)
     error('reaction-trigger: invalid building')
    end
   end
  end
 end
 return workerId,buildingId
end

local function processCommand(job, worker, target, building, command)
 local result = {}
 for _,arg in ipairs(command) do
  if arg == '\\WORKER_ID' then
   table.insert(result,''..worker.id)
  elseif arg == '\\TARGET_ID' then
   table.insert(result,''..target.id)
  elseif arg == '\\BUILDING_ID' then
   table.insert(result,''..building.id)
  elseif arg == '\\LOCATION' then
   table.insert(result,''..job.pos.x)
   table.insert(result,''..job.pos.y)
   table.insert(result,''..job.pos.z)
  elseif arg == '\\REACTION_NAME' then
   table.insert(result,''..job.reaction_name)
  elseif string.sub(arg,1,1) == '\\' then
   table.insert(result,string.sub(arg,2))
  else
   table.insert(result,arg)
  end
 end
 return result
end

eventful.onJobCompleted.reactionTrigger = function(job)
 if job.completion_timer > 0 then
  return
 end

-- if job.job_type ~= df.job_type.CustomReaction then
--  --TODO: support builtin reaction triggers if someone asks
--  return
-- end

 if not job.reaction_name or job.reaction_name == '' then
  return
 end
-- print('reaction name: ' .. job.reaction_name)
 if not job.reaction_name or not reactionHooks[job.reaction_name] then
  return
 end

 local worker,building = getWorkerAndBuilding(job)
 worker = df.unit.find(worker)
 building = df.building.find(building)
 if not worker or not building then
  --this probably means that it finished before EventManager could get a copy of the job while the job was running
  --TODO: consider printing a warning once
  return
 end

 local function doAction(action)
  local didSomething
  local xRange, yRange, zRange
  if action.range then
    xRange,yRange,zRange = tonumber(action.range[1]), tonumber(action.range[2]), tonumber(action.range[3])
  else
    xRange,yRange,zRange = 0, 0, 0
  end
  if action.syndrome and not action.ignoreWorker then
   didSomething = syndromeUtil.infectWithSyndromeIfValidTarget(worker, action.syndrome, action.resetPolicy) or didSomething
  end
  if action.command and not action.ignoreWorker and ( not action.syndrome or didSomething ) then
   local processed = processCommand(job, worker, worker, building, action.command)
   dfhack.run_command(table.unpack(processed))
  end
  if didSomething and not action.allowMultipleTargets then
   return
  end
  if not action.allowNonworkerTargets and not action.allowMultipleTargets then
   return
  end
  local function foreach(unit)
   if unit == worker then
    return false
   elseif   unit.pos.z < building.z - zRange or unit.pos.z > building.z + zRange then
    return false
   elseif unit.pos.x < building.x1 - xRange or unit.pos.x > building.x2 + xRange then
    return false
   elseif unit.pos.y < building.y1 - yRange or unit.pos.y > building.y2 + yRange then
    return false
   else
    if action.syndrome then
     didSomething = syndromeUtil.infectWithSyndromeIfValidTarget(unit,action.syndrome,action.resetPolicy) or didSomething
    end   
    if action.command and ( not action.syndrome or didSomething ) then
     local processed=processCommand(job, worker, unit, building, action.command)
     dfhack.run_command(table.unpack(processed))
    end
    if didSomething and not action.allowMultipleTargets then
     return true
    end
    return false
   end
  end
  for _,unit in ipairs(df.global.world.units.all) do
   if foreach(unit) then
    break
   end
  end
 end
 for _,action in ipairs(reactionHooks[job.reaction_name]) do
  doAction(action)
 end
end
eventful.enableEvent(eventful.eventType.JOB_COMPLETED,0) --0 is necessary to catch cancelled jobs and not trigger them

validArgs = validArgs or utils.invert({
 'help',
 'clear',
 'reactionName',
 'syndrome',
 'command',
 'allowNonworkerTargets',
 'allowMultipleTargets',
 'range',
 'ignoreWorker',
 'resetPolicy'
})

if moduleMode then
 return
end
local args = utils.processArgs({...}, validArgs)

if args.help then
 print(usage)
 return
end

if args.clear then
 reactionHooks = {}
end

if not args.reactionName then
 return
end

if not reactionHooks[args.reactionName] then
 reactionHooks[args.reactionName] = {}
end

if args.syndrome then
 local foundIt
 for _,syndrome in ipairs(df.global.world.raws.syndromes.all) do
  if syndrome.syn_name == args.syndrome then
   args.syndrome = syndrome
   foundIt = true
   break
  end
 end
 if not foundIt then
  error('Could not find syndrome ' .. args.syndrome)
 end
end

table.insert(reactionHooks[args.reactionName], args)

For reference, here is a script call I have lying around that will probably look similar to what you want:

foe/reaction-trigger -reactionName REHABILITATE_SLAVE -allowNonworkerTargets -range [ 5 5 0 ] -syndrome "rehabilitated (em)" -command [ foe/fix-unit-history -unit \\TARGET_ID -clearTamed ]

Of course, the above script call assumes you stick the script in a file called reaction-trigger.lua in the new folder hack/scripts/foe.

If you are running a command and you want it to only apply to certain kinds of units, you need to include a dummy syndrome that can only be applied to those units.  The script will apply the dummy syndrome (which does nothing) and then run the command on that unit.

If you need something which is sensitive to what syndromes a creature has already, I will leave this syndrome swapping monster of a script here, which can be used to swap out a dummy syndrome applied by the above with the syndrome you want if the target has/doesn't have the correct syndromes (good luck):
Code: [Select]
-- this script swaps syndromes with other syndromes, only on certain conditions
--written by thefriendlyhacker
local usage = [====[

foe/swap-syndrome
=====================
This script applies syndromes with other syndromes on certain conditions.  It can also be used to apply syndromes to all creatures (again, on certain conditions).

Arguments::

    -disable name
        removes a syndrome replacement registration.
    -help
        prints help and ends
    -noRepeat
        only executes once, does not repeat on subsequent ticks
    -name string
        names the syndrome replacement registration. Required unless -noRepeat
    -tickRate nbr
        defines how often the syndrome(s) is replaced. Defaults to 100 ticks
    -dontDisperseCalls
        by default, the first repeat is randomly offset so that all swap-syndrome calls don't end up on the same tick (potentially creating lag spikes).  This disables that behavior.

    -oldSyn syndrome or oldSyn [ syndromes ]
        defines which syndromes are to be replaced.  If both oldSyn and oldSynClass are undefined, then the new syndrome is applied
    -oldSynClass synClass or -oldSynClass [ synClasses ]
        defines which syndrome classes are to be replaced
    -newSyn syndrome or -newSyn [ syndromes ]
        defines which syndrome(s) is to be applied
    -resetPolicy policy
        specify a policy of what to do if the unit already has an instance of the syndrome.
            NewInstance (default)
            DoNothing
            ResetDuration
            AddDuration

    -reqSyn syndrome or reqSyn [ syndromes ]
        only apply the syndrome if one of the syndrome(s) is present
    -reqSynClass synClass or reqSynClass [ synClasses ]
        only apply the syndrome if one of the syndrome class(es) is present.  If both reqSyn and reqSynClass are args, only one need match to apply the syndrome.
    -notSyn syndrome or -notSyn [ syndromes ]
        only apply the syndrome if the syndrome(s) is not present
    -notSynClass synClass or -notSynClass [ synClasses ]
        only apply the syndrome if the syndrome class(es) is not present
]====]
local eventful = require 'plugins.eventful'
local utils = require 'utils'
local repeatUtil = require 'repeat-util'
local syndromeUtil = require 'syndrome-util'

defaultTickRate=100 -- on low tickrates this may hurt fps severely
defaultResetPolicy=syndromeUtil.ResetPolicy["ResetDuration"]

function applySyndrome(unit,syndrome,resetPolicy)
  syndromeUtil.infectWithSyndromeIfValidTarget(unit,find_syndrome(syndrome),resetPolicy)
end
--func must take unit only, not nil
function checkSynConds(unit,reqSyns,reqNotSyns,reqSynClasses,reqNotSynClasses)
  local hasReqSyn=false
  if not next(reqSynClasses) and not next(reqSyns) then
    hasReqSyn=true
  end
  if hasReqSyn and not (next(reqNotSyns) or next(reqNotSynClasses)) then
    return true -- when there are no conditions
  end
  for _,active_syn in pairs(unit.syndromes.active) do
    local syn= df.syndrome.find(active_syn.type)
    for _,reqSyn in ipairs(reqSyns) do
      if syn==reqSyn then
        hasReqSyn=true
      end
    end
    for _,reqNotSyn in ipairs(reqNotSyns) do     
      if syn==reqNotSyn then
        return false
      end
    end
    for _,class in ipairs(syn.syn_class) do
      for _,reqSynClass in reqSynClasses do
        if class.value==reqSynClass then
          hasReqSyn=true
        end
      end
      for _,invalidSynClass in reqNotSynClasses do
        if class.value == invalidSynClass then
          return false
        end
      end
    end
  end
  if hasReqSyn then return true end
  return false
end

function find_syndrome(syn_name)
  local syndrome
  for _,syn in ipairs(df.global.world.raws.syndromes.all) do
    if syn.syn_name == syn_name then
      syndrome = syn
      break
    end
  end
  if not syndrome then
    error ('error - cannot find: ' .. syn_name)
  end
  return syndrome
end

function stripSyndrome(unit,synName)
  syndromeUtil.eraseSyndromes(unit,find_syndrome(synName).id)
end

function stripSyndromeByClass(unit,synClass)
  for _,syn in unit.syndromes.active do
    for _,unitSynClass in syn.syn_class do
      if synClass==unitSynClass then
        stripSyndrome(unit,syn.id)
      end
    end
  end
end

function registerScript(name,func,tickRate,dontDisperse)
  assert(name,'error - no name defined')
  if not tickRate then tickRate=defaultTickRate end
  repeatUtil.scheduleEvery(name,tickRate,'ticks',func)
  if not dontDisperse then
  --yeah, I am using impl details, it is the nicest way to do this
    local callback=dfhack.timeout_active(repeatUtil.repeating[name],nil)
    dfhack.timeout(tickRate-math.random(0,tickRate-1),'ticks',callback)
  end
end

function searchUnitForSyndromes(unit,syns,synClasses)
  for _,unitSyn in ipairs(unit.syndromes.active) do
    local synType=df.syndrome.find(unitSyn.type)
    for _,unitSynClass in ipairs(synType.syn_class) do
      for _,synClass in ipairs(synClasses) do
        if synClass==unitSynClass then return true end
      end
    end
    for _,syn in ipairs(syns) do
      if synType.syn_name==syn then return true end
    end
  end
  return false
end

function swapSyns(unit,oldSyns,oldSynCs,newSyns,resetPolicy)
  for _,syn in ipairs(oldSyns) do
    stripSyndrome(unit,syn)
  end
  for _,synC in ipairs(oldSynCs) do
    stripSyndromeByClass(unit,synC)
  end
  for _,newSyn in ipairs(newSyns) do
    applySyndrome(unit,newSyn,resetPolicy)
  end
end


--this is a desperate attempt to reduce runtime costs by writing code such that everything done in the callback proper is a local variable lookup.
function getCallbackInner(oldSyns,oldSynCs,newSyns,reqSyns,reqSynCs,notSyns,notSynCs, resetP)
  return function()
    for _,unit in ipairs(df.global.world.units.all) do
      if searchUnitForSyndromes(unit,oldSyns,oldSynCs) then
        if checkSynConds(unit,reqSyns,reqSynCs,notSyns,notSynCs) then
          swapSyns(unit,oldSyns,oldSynCs,newSyns,resetP)
        end
      end
    end
  end
end

function getCallback(args)
  return getCallbackInner(args.oldSyn,args.oldSynClass,args.newSyn,args.reqSyn,args.reqSynClass,args.notSyn,args.notSynClass,args.resetPolicy)
end


--note - repeatCall is for internal use only
validArgs = validArgs or utils.invert({
 'disable',
 'help',
 'noRepeat',
 'name',
 'tickRate',
 'dontDisperseCalls',
 'oldSyn',
 'oldSynClass',
 'newSyn',
 'resetPolicy',
 'reqSyn',
 'reqSynClass',
 'notSyn',
 'notSynClass'
})
local args = utils.processArgs({...}, validArgs)

if args.help then
  print(usage)
  return
end
if args.disable then
  repeatUtil.cancel(args.name)
  return
end


if not args.tickRate then
  args.tickRate=defaultTickRate
end


if type(args.oldSyn)=="string" then
  args.oldSyn= {args.oldSyn}
end
if not args.oldSyn then
  args.oldSyn={}
end


if type(args.oldSynClass)=="string" then
  args.oldSynClass= {args.oldSynClass}
end
if not args.oldSynClass then
  args.oldSynClass= {}
end

if type(args.newSyn)=="string" then
  args.newSyn= {args.newSyn}
end
if not args.newSyn then
  args.newSyn={}
end


if type(args.reqSyn)=="string" then
  args.reqSyn={args.reqSyn}
end
if not args.reqSyn then
  args.reqSyn={}
end


if type(args.reqSynClass)=="string" then
  args.reqSynClass={args.reqSynClass}
end
if not args.reqSynClass then
  args.reqSynClass={}
end

if type(args.notSyn)=="string" then
  args.notSyn= {args.notSyn}
end
if not args.notSyn then
  args.notSyn= {}
end

if type(args.notSynClass)=="string" then
  args.notSynClass= {args.notSynClass}
end
if not args.notSynClass then
  args.notSynClass= {}
end

if not args.resetPolicy then args.resetPolicy=defaultResetPolicy
else
  assert( syndromeUtil.ResetPolicy[args.resetPolicy],"error - resetPolicy must be: DoNothing, ResetDuration, AddDuration or NewInstance")
  args.resetPolicy=syndromeUtil.ResetPolicy[args.resetPolicy]
end


callback=getCallback(args)
if not args.noRepeat then
  registerScript(args.name,callback,args.tickRate,args.dontDisperseCalls)
end
callback()
This one isn't as thoroughly tested as I would like, so tell me if anything breaks.  Here is an example call from Fallout Equestra.

foe/swap-syndrome -name "Time Stutter" -tickRate 2000 -oldSyn "Time Stutter School Tag" -newSyn "Time Stutter Apprentice School Knowledge" -notSynClass [ "CONJURATION_APPRENTICE_SCHOOL" "DESTRUCTION_APPRENTICE_SCHOOL" "ILLUSION_APPRENTICE_SCHOOL" "RESTORATION_APPRENTICE_SCHOOL" ] -resetPolicy DoNothing
Logged
Fallout Equestria Redux - that's right, it's back

coolphoton

  • Bay Watcher
    • View Profile
Re: Future of MDF
« Reply #29 on: August 16, 2018, 09:09:02 am »

My favorite races were and are warlocks>orks>kobolds>gnomes. I am happy to see that MW will be continuing, even if I'm loosing my favorite race.
Logged
Pages: 1 [2] 3