so i seems i can do a skill[n].header.expanded = false which is reflected thru all skill[#].header tables which share the same header. that implies that the header field is a reference to the same table and not a copy of that table. right?
ok, here, having filled out some context, the table header is being attached to the skill[n].header key. so you can do skill[n1].header[n2].expanded
yeah, kinda. tho the [n2] index isn't required because i'm actually referencing the header record, not the whole header table. i guess my initial pseudocode wasn't clear about that. what i'm doing is essentially:
so each header record is created as i come across it in the skill list. the headers are stuffed into the same list as professions and then an extra header table is being created. it made more sense when i was coding it. :) i wanted to avoid additional indices, so stuffing the header table right into the profession skill list seemed simple enough. and keeping the header labels in the profession list also made for easy display.
what you prolly wnat to do is something like this dir structure..
for i,v in ipars(header) do
for k, v in pairs (skills[v.name])
--DoStuff()
end
end
not sure of how your accessing these tables but you prolly want a table structure that is going to work with that.
yeah, that makes a ton of sense organizationally, but i'm a little leary about how that would interact with other aspects of my code. i'm trying to keep to the idea of a single index being enough to identify a skill and a "flat" trade skill list facilitates that. also pushing the headers into the skill list also keeps my indices sync'd with the api indices, which is a plus.
it's the save/load stuff that mucks it up on me. i think i'll ditch the header table and just add an expanded flag to the trade skill table, then use an index back into the profession list as the header identifier.
i suppose i could add (yet another) layer of abstraction to enable grouping like you suggest. in that case, groupedSkills[profession][group][index] would just be a single index into the flat list.
Stick to the PIL. The best you're going to get here is some sparse information, which you can never guarantee is accurate, from the few people who want to take the time to recite sections of the book you should be reading instead. (Edit: I'm not suggesting OrionShock's information is inaccurate. He knows what he's talking about.)
It may seem like a lot to read, and it is all for one session. But read a little at a time, front to back, and you won't have to ask these questions--instead you'll be the one smart enough to answer them.
for example:
header[n] = {}
header[n].name = headerName
header[n].expaned = true
... maybe 5 or 6 different headers where n is a non-sequential integer
then:
skill[n] = {}
skill[n].name = skillName
skill[n].header = header[x]
... maybe a few hundred of these
so i seems i can do a skill[n].header.expanded = false which is reflected thru all skill[#].header tables which share the same header. that implies that the header field is a reference to the same table and not a copy of that table. right?
skill[n].header = header Will set skill[n]["header"] to the table header. skill[n].header.expanded will set header["expanded"] to false.
okay, so then i could do something like:
myaddon.currentDataSet = myaddon.db.server.professionData[selectedPlayer][selectedProfession]
and then read/write to myaddon.currentDataSet to alter the database i'm using, right?
how is lua smart about recreating tables?
like, if i do:
a = {}
a.name = "fred"
a.number = 100
then
b = {}
b.name = "fred"
b.number = 100
will "a" and "b" point to the same table internally? i suspect not, but lua continues to surprise me.
My guess is that both a and b will be two different tables.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumheaderName = "bob" skillName = "BoB's Craft" header[n] = {} header[n].name = headerName header[n].expaned = true skill[n] = {} skill[n].name = skillName skill[n].header = [i]header[/i]ok, here, having filled out some context, the table header is being attached to the skill[n].header key. so you can do skill[n1].header[n2].expanded
what you prolly wnat to do is something like this dir structure..
header info = { 1 = { name, expanded}, 2 = { name, expanded}, ...or.. [//headerName//] = true/false } skills = { [//headerName//] = { [//skillName//] = {..}, [//skillName//] = {..}, }, }you could then traverse it all with
for i,v in ipars(header) do
for k, v in pairs (skills[v.name])
--DoStuff()
end
end
not sure of how your accessing these tables but you prolly want a table structure that is going to work with that.
:(
yeah, kinda. tho the [n2] index isn't required because i'm actually referencing the header record, not the whole header table. i guess my initial pseudocode wasn't clear about that. what i'm doing is essentially:
if skillType == "header" then header[i] = {} header[i].name = skillName header[i].expaned = true lastHeader = header[i] profession[i].name = skillName ...more profession stuff else profession[i].name = skillName profession[i].header = lastHeader ...more profession stuff endso each header record is created as i come across it in the skill list. the headers are stuffed into the same list as professions and then an extra header table is being created. it made more sense when i was coding it. :) i wanted to avoid additional indices, so stuffing the header table right into the profession skill list seemed simple enough. and keeping the header labels in the profession list also made for easy display.
yeah, that makes a ton of sense organizationally, but i'm a little leary about how that would interact with other aspects of my code. i'm trying to keep to the idea of a single index being enough to identify a skill and a "flat" trade skill list facilitates that. also pushing the headers into the skill list also keeps my indices sync'd with the api indices, which is a plus.
it's the save/load stuff that mucks it up on me. i think i'll ditch the header table and just add an expanded flag to the trade skill table, then use an index back into the profession list as the header identifier.
i suppose i could add (yet another) layer of abstraction to enable grouping like you suggest. in that case, groupedSkills[profession][group][index] would just be a single index into the flat list.
That wouldn't be smart at all.
http://www.lua.org/pil/2.5.html
http://www.lua.org/pil/11.html
Stick to the PIL. The best you're going to get here is some sparse information, which you can never guarantee is accurate, from the few people who want to take the time to recite sections of the book you should be reading instead. (Edit: I'm not suggesting OrionShock's information is inaccurate. He knows what he's talking about.)
It may seem like a lot to read, and it is all for one session. But read a little at a time, front to back, and you won't have to ask these questions--instead you'll be the one smart enough to answer them.
a = {} a.name = "fred" a.number = 100 b = {} b.name = "fred" b.number = 100a and b are the same table.
a = {} a.name = "fred" a.number = 100 b = a -- $b =& $a (from a PHP standpoint)Tables in Lua are always passed by reference.