PART 4

One of the nifty and tricky things about lua tables is that the keys (the 'names' of things that hold values) are all just strings.

You traditionally (in computer languages in general) reference a value within a table by using square brackets [] after the name of the table variable, and put the 'key' inside the brackets, so that code knows which entry within the table to get.

When you first define a table, if you don't tell it what the keys are, it just assigns the values to a sequence of numbers.


That creates this table:

my_table[1] = 'first item'
my_table[2] = 'second item'
my_table[3] = 'third item'


However you don't need to use the default numbers. Our gear sets use the names of the equipment slots, where the 'key' for each entry is the slot name:


sets.aftercast['main'] = "Tamaxchi"
sets.aftercast['sub'] = "Genbu's Shield"
sets.aftercast['hands'] = "Serpentes Cuffs"

Note that we don't put a period between the terms if we use the brackets. If we did use the period, we wouldn't need the brackets and quotes around the key name. Instead, it would just be written as:

sets.aftercast.main = "Tamaxchi"
sets.aftercast.sub = "Genbu's Shield"
sets.aftercast.hands = "Serpentes Cuffs"


In other words, aftercast, main, sub and hands are all just strings that we can write in a couple different ways. The following are all exactly the same:

sets.aftercast.main = "Tamaxchi"
sets.aftercast['main'] = "Tamaxchi"
sets['aftercast'].main = "Tamaxchi"
sets['aftercast']['main'] = "Tamaxchi"


Another important aspect is that /all/ keys are valid, always, except for the special value of nil (nil represents "no value at all"). They may not have any value associated with them, but you can always look up any key.

The above set doesn't define anything for the ammo slot, but if I check sets.aftercast.ammo I'll still get something back (the special value called nil).


Why is this important? Because it means we can just use other string variables in place of the literal table values, while also not worrying about whether we have anything defined beforehand.


That code will equip the set under sets.precast that matches the name of the spell you just cast. If you cast Cure, it will try to equip sets.precast['Cure']. If you cast Cure II it will try to equip sets.precast['Cure II']. And so forth.

Of course you don't want to create one set for every single spell, so you might instead do things like equip(sets.precast[spell.skill]). Now when you cast any cure spell it will try to equip sets.precast['Healing Magic'].

Individual names are more useful for things like job abilities, where having an appropriate piece of gear equipped when you use the JA boosts it in some way. For example:


If you use Counterstance, it will equip the Melee Gaiters +2.

Of course, what happens when you try to use Berserk? There's no sets.precast.Berserk set defined, so it will generate an error.

What we can do, then, is check to see if the set exists first before trying to equip it, and that's very simple:


Remember that every key is valid to at least check for, so if sets.precast[spell.english] then is a valid conditional. When we use Counterstance we find that the sets.precast.Counterstance table exists, so we can try to equip it. If we use Berserk, there is no sets.precast.Berserk in the sets.precast table, so the check returns nil, and nil evaluates to false in a conditional. Since it returns false, we know the set doesn't exist and we don't try to equip anything.

---

Navigation
Part 1 - Basic Sets and Events
Part 2 - Conditionals and Testing
Part 3 - More on Conditionals
Part 4 - Tables
Part 5 - Abstractions
Part 6 - Asking the Right Questions
Part 7 - Library Tools