A function to check physical capability.

[Alexander Divine]

I'm working on my auto-basher right now. I've done auto-bashers a trillion times over, especially back in zMud, so the concept isn't a huge deal, but now that I'm getting a better grounding in Lua, I can't help feel that my current approach is way too clumsy.

My current implementation is as follows: On my prompt, it checks to see if autoBashing == 1. If this is true, it basically runs a function called "canAct." canAct currently looks like this:

Code: [show] | [select all] lua

-- canAct acts as a physical audit to check every possible circumstance
-- (afflictions, prone, etc.) that would keep one from being able to act on
-- either the given balance or both balances. If no balance is given, it
-- checks for both.

function canAct(balance)
-- As we don't currently have any affliction variables created, for
-- now this will just check to make sure they're not 1.
-- Also I obviously need more afflictions.
--
-- NOTE TO SELF: Add functionality for checking an action that only needs one balance!

  if BAL == 1 and EQ == 1 and prone == 0 and pacifism ~= 1 and peace ~= 1 then
    return true
  else
    return false
  end
end

Now, this works pretty damn well, but as I mentioned, it feels pretty clumsy. I hate "if/then" statements and wish I could somehow do without them, but I feel there could be a better way of going about this than just checking several different variables.

Any ideas?

(And yes, I actually write my comments like that)

[tsuujin]

well, a bit unrelated, but I highly suggest coming up with a manager for your afflictions, rather than individual variables.

[syntax=lua]
-- General management of afflictions.

if not affs then
affs = {
current = {},
}
end

-- add, drop, and check afflictions
function affs:add(a,diag)
a = a:lower()
-- only add an affliction once
if self.current[a] then return end
-- in case we want to state something specific about an affliction
-- take an optional val
self.current[a] = true
end

function affs:del(a)
a = a:lower()
-- don't try to drop an affliction you don't have
if not self.current[a] then return end
-- remove the element.
self.current[a] = nil
-- run a scan for new afflictions every time this is done
end

function affs:has(a,flag)
flag = flag or "or"
if type(a) == "table" then
local cont = true
if flag == "or" then
for _,k in pairs(a) do if self.current[k:lower()] then return true end end
return false
elseif flag == "and" then
for _,k in pairs(a) do
cont = self.current[k:lower()]
if not cont then
Note("don't have "..k:lower())
return false
end
end
return true
end
end

if flag == "reg" then
for k,v in pairs(self.current) do
if k:match(a) then return v end
end
else
a = a:lower()
if self.current[a] then return self.current[a] end
end
return false
end

function affs:reset()
self.current = {}
display:message("Afflictions Reset")
end
[/syntax]

This is my affliction manager (based off of ideas from another system which helped me learn lua). There are a few obsolete notes and so forth because it's currently in transition, but you get the idea.

[tsuujin]

As for the check, what you have looks fine.

Although, because I'm always a fan of saving a few keystrokes, you can change how you return the function a bit by excluding the else statement. Return automatically exits out of the function, so you can use the if statement to return true if everything's ok and simply return false at the end of the statement (or visa versa)


[syntax=lua]
-- canAct acts as a physical audit to check every possible circumstance
-- (afflictions, prone, etc.) that would keep one from being able to act on
-- either the given balance or both balances. If no balance is given, it
-- checks for both.

function canAct(balance)
-- As we don't currently have any affliction variables created, for
-- now this will just check to make sure they're not 1.
-- Also I obviously need more afflictions.
--
-- NOTE TO SELF: Add functionality for checking an action that only needs one balance!

if BAL == 1 and EQ == 1 and prone == 0 and pacifism ~= 1 and peace ~= 1 then
return true
end

return false
end
[/syntax]

Yeah, picky, but I'm used to coding things where a few keystrokes here and there make up thousands of keystrokes in the end.

[Alexander Divine]

Mmk, I guess I'll keep it the way it is for now. We'll see! Thanks for the input.

As an aside, why do you recommend saving the afflictions as items in a table? I don't disagree that this method is sloppy as all hell, but would there be any advantages? I love advantages!

[tsuujin]

You don't have to code in a list of afflictions, and bother updating it as things change, for one. Once you've got the manager working properly you just feed it names and check for them.

Mostly, though, it works wonders for encapsulation. You never have to worry about conflicting variables, because each system has essentially been given it's own namespace.