//...The properly working proc
ShowStats()
src << "\n===Current Skills===: \n1: [ActiveSkills["skill1"]] \n2: \n3: \n4: \n5: \n6: \n7: \n8: \n9: \n===Passive Abilities===: \n10: \n11: \n12: \n13: \n14: \n15:\n===Cultural Abilities=== \n16: \n17: \n18:"
//note that the object, which is the skill name... we'll call it "Summon Giant Plush Ferret"...shows up as intended.
//However, another proc, using the same index "skill1" will return null. Calling ShowStats() will still show it is being there. Below is a code snippet from the "command" switch statement which handles text commands.
if ("cast")
//cast (slotnum) on (mobname) on a specific target
//cast (slotnum) will also work if attacking or if the spell targets self or room.
var/list/temp = Parse(list(" "),GetAttribute(command,t,scissors=" "),null,null,TRUE,null)
var/mob/target
if (temp.len == 3)
//We have 3 arguments, so find the mob.
target = CurrentRoom.Search(temp[3])
else if (temp.len == 1)
target = auto_attack_target
if (target)
//Now we try to grab our skill.
var/Skill/s
switch(temp[1])
if ("1","2","3","4","5","6","7","8","9","10")
//src << temp[1]
s = ActiveSkills["skill[temp[1]]"]
if ("c1","c2","c3")
temp[1] = copytext(temp[1],2,3)
s = ActiveSkills["cultural[temp[1]]"]
else
src << "Invalid slot!"
return
src << s
var foo = temp[1]
src << ActiveSkills["skill[temp[1]]"]
src << ActiveSkills["skill1"]
src << ActiveSkills.len
src << ActiveSkills["skill[foo]"]
src << ActiveSkills["skill1"]
src << temp[1]
src << "skill[temp[1]]"
src << ActiveSkills["melee attack"]
for (var/v in ActiveSkills)
src << "[v]: [ActiveSkills[v]]"
if (s)
if (s.CheckUsable(src,target))
//src << "1"
//src << s
spawn() s.Execute(src,target)
else
src << "There is no ability in that slot."
return
/*
Output:
>cast 1 on w
<--ActiveSkills["skill[temp[1]]"]
<--ActiveSkills["skill1"], tried to straight up access it without any concatenation
2 <--ActiveSkills.len, shows two skills in list as expected
<--ActiveSkills["skill[foo]"], tried switching with a non list concatenation in case it was that old bug where you couldn't access lists with indices being from other lists
<--ActiveSkills["skill1"], this time copied and pasted from the other proc because why not?
1 <--temp[1], to make sure we aren't having any stray characters
skill1 <--Double checking the concatenation
<--ActiveSkills["melee attack"], null. There is supposed to be a /Skill there.
---for loop---
melee attack: Melee Attack
skill1: Summon Giant Plush Ferret
The skills appear using the var/v in ActiveSkills for loop.
Conclusion: something dun broke
*/
Problem description:
Generally what's happening is that the typical way of accessing associative lists returns null for this one proc.
The expected result is to return the atom (which is normally the name of the atom) but this time it isn't returning it. However, it does return it in a proc that just lists your stats. After testing it to see if it's just me, it turns out I can verify that something is amiss.
The obvious workaround for this strange issue is to use a for loop, and return the skill from within the loop since it seems to access properly from there. Has anyone else encountered this issue?
Edit: I'll keep testing on my end to see if anything else is the problem (or I am missing something painfully obvious as can happen).
Edit2: Nevermind, the workaround does not work and instead returns null.
Edit 3: I have found the problem!
It appears that using the << operator alone in an associative list returns null when used with the << operator, but the data is just fine. Encapsulating it in quotes causes it to function as normal.
src << ActiveSkills["skill1"] //returns a null value/empty string? Will confused anyone trying to find problems
src << "[ActiveSkills[skill1]]" //returns Summon Giant Plush Ferrets, or, the actual value in list[index].
var/Skill/s = ActiveSkills["skill1"] //puts the expected atom there
This appears to be a bug with the latest update, was present in the last version as well.</<></<>
Then you should see that name instead of nothing, though I might be wrong on that.
From what I can see though, no bugs are happening here.