Variable Problem

Posted by Orogan on Sun 09 Nov 2008 03:21 PM — 12 posts, 34,938 views.

#0
if I got a variable a wich could have the value "glow"
I want to do something like:

SetVariable ((a), "1")

to set the variable glow to 1

Tryed using every thing I could think of but it just won't work.
How would I go about this?
USA #1
Is "glow" meant to be a MUSHclient-space variable, or a Lua-space variable?

Also, it is helpful if you describe in more detail why it's not working; error messages are always useful, symptoms are useful, etc.
#2
Lua space variable.

And as far as error go I think I had them all ranging from
parcing errors over 'doing nothing at all' to 'ambiguous syntax (function call x new statement)' depending on the stuff I try.
USA #3
Ah... well, SetVariable is a function to set MUSHclient-space variables. There are many ways to do this, that are more or less complicated depending on how complicated you want it to be, but here's one way:

loadstring(a .. " = 1")()

This loads up the string "glow = 1" as a function, and then executes it to make the assignment.

You could also try:

_G[a] = 1

which talks directly to the table of Lua global variables.
#4
The first solution worked.:)

To make more clear what i wanted to do:

list = "glow, hum, res"

for f in string.gmatch (list, "%a+") do
loadstring(f.."=1")()
end

Just to be sure this is the correct way to go about it?

Thanks again for the help.
USA #5
That looks reasonable to me, although I might make it an explicit list, something like:

list = {"a", "b", "c"}

for _, varname in ipairs(list) do
  loadstring(varname .. " = 1")()
end


If you know the list ahead of time, it's easier to skip the splitting phase and just represent it as a list.
#6
I grab the list in that format from the mudoutput so to make it into a table would be unnecessary I would think. Unless there's a good reason for it that I'm newbie unaware of?
USA #7
Ah -- I didn't realize that you only get the list as a string. (I wasn't sure if it was a known list of things to check, or something from the MUD.) In that case, what you did with string.gmatch makes perfect sense.
Australia Forum Administrator #8
Personally I don't like the loadstring approach, as that is invoking the Lua compiler to do something which is really a runtime operation.

At the very least, do this:



for f in string.gmatch (list, "%a+") do
   _G [f] = 1
end



That at least doesn't need a compile phase, which is slower. Better again, use a boolean:


for f in string.gmatch (list, "%a+") do
   _G [f] = true
end


However all this looks messy. What happens if the flag from the MUD happens to be called "print"? Then you have clobbered your global print function with the number 1. Or if a flag is called "string" then your script stops working because string.gmatch won't work any more as string has changed from a function to 1.

Far, far better to make a table of flags, like this:


flags = {}

for f in string.gmatch (list, "%a+") do
   flags [f] = true
end


Now you can just test flags, eg.


if flags.hum then
  -- do something
end -- if


Also you can now iterate through all the flags, eg.


print "flags set = "
for k, v in pairs (flags) do
  print (k)
end -- for


Amended on Sun 09 Nov 2008 09:58 PM by Nick Gammon
#9
If used what you said Nick.
Works,exept I use 1 and 0 instead of boolean.
The reason is I'm using the values in this:


assert (con:execute(string.format([[INSERT INTO lore
   	 VALUES ('%s', '%d')]],(p.Type),(flags.hum))))


(shorter version)
To pass the values to a database.

Couldn't find the specifier for the boolean so I used %d wich worked.
I can't see a difference between using 0 and 1 over boolean.
So if there is a diff. please explain. :)
USA #10
In Lua, this code will print "hello":

if 0 then print("hello") end


The only things that are "false" in Lua are nil and, well, "false". Everything else evaluates to "true".
Australia Forum Administrator #11
When David asked you before, you said it was a Lua variable, nothing was mentioned about a database.

You may well need to convert from true/false to 1/0 for a database, however as David says, once you retrieve the information later, you will need to test for equal to 1 to be true, and not equal to 1 to be false. It might be better to have a helper function that converts true to 1 and false to zero, like this:


function db_bool (val)
  if val then
    return "1"
  end -- if

  return "0"
end -- function


You could make a similar function to convert back, when reading from the database. The point of this is that then you can subsequently test:


if <variable> then ...


rather than:


if <variable> == "1" then ...