Question in regards to string.lower

Sharlikran · 04/15/14, 01:42 AM

Code:

function Harvest.IsValidBottle(name)
    for k, v in pairs(Harvest.bottle) do
		d("v name :" .. v)
		d("name :" .. name)
        if v == name then
            return true
        end
    end

    return false
end

I though the above function was working perfectly yesterday. However, I reverted changes to stick with the original authors syntax.
The entire function:

Warning: Spoiler

Code:

_, _, _, itemId = ZO_LinkHandler_ParseLink( objectName ) --name, color, type, id, +19 other attributes

He uses that to do something and I don't quite get. The function is on the wiki but no explanation as to what it does. Whatever it's doing it's preventing the routine from comparing the names. So I changed the Boolean routine to this thinking it would be enough.

Code:

function Harvest.IsValidBottle(name)
    for k, v in pairs(Harvest.bottle) do
		d("v name :" .. v)
		d("name :" .. string.lower(name))
        if v == string.lower(name) then
            return true
        end
    end

    return false
end

When I do that then the debug routine returns this.

Code:

:hFFFFFF:item:1187:1:13:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:hclear waterh

I fixed it by making a global variable. However, for my sanity does anyone know why that's happening?

Garkin · 04/15/14, 06:33 AM

Originally Posted by Sharlikran

When I do that then the debug routine returns this.

Code:

:hFFFFFF:item:1187:1:13:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:hclear waterh

This is broken item link. If you use string.lower() on item link, function ZO_LinkHandler_ParseLink does not work.

Warning: Spoiler

Sharlikran · 04/15/14, 09:03 AM

I received a nice PM from ins as well. Thanks ins. He suggested the same thing that that it may have changed since beta. I have a question though. The above code snipit suggests using text, color, zo_strsplit(':', data) The original routine has "_, _, _, itemId = ZO_LinkHandler_ParseLink( objectName )"

To me, not understanding lua all that much, means that ZO_LinkHandler_ParseLink (onjectname) is assigining 4 variables. The first three are "_, _, _," and the fourth is itemID. I have seen some routines that say things like, 'for _, node in pairs( nodes ) do'. What does '_' that mean? Nil?

Stormknight · 04/15/14, 09:31 AM

http://mirven.github.io/underscore.lua/

Kinda mentions it. I'd be interested to know why it should be used though.

It *seems* like it's a local throwaway variable?

Kinda like each function automatically has "local _" declared at the start?

Garkin · 04/15/14, 10:31 AM

Originally Posted by Sharlikran

What does '_' that mean? Nil?

"_" is dummy variable - http://www.lua.org/pil/5.2.html

Iyanga · 04/15/14, 01:55 PM

Originally Posted by Sharlikran

Code:

function Harvest.IsValidBottle(name)
    for k, v in pairs(Harvest.bottle) do
		d("v name :" .. v)
		d("name :" .. string.lower(name))
        if v == string.lower(name) then
            return true
        end
    end

    return false
end

When I do that then the debug routine returns this.

Code:

:hFFFFFF:item:1187:1:13:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:hclear waterh

I fixed it by making a global variable. However, for my sanity does anyone know why that's happening?

Because the item link contains more than the name and if you turn the H into an h, it no longer is a correct item link, as a H is expected to start the color code, not a h.

And no, there is no workaround, because even if you manage to not convert the Hs, in the end your strlower will wreck havoc upon the item name once you have UTF-8 characters in it.

**Seerah** · 04/15/14, 04:14 PM

_ is just as valid a variable name as x, or myVar, or THIS_AWESOME_VARIABLE_NAME.

It is used conventionally as a throwaway variable by many authors, assigning it to values we don't care about. Since we don't care about them, it doesn't matter if they get overwritten. It is good practice to declare this _ variable as local.

Sharlikran · 04/15/14, 05:14 PM

Originally Posted by Iyanga

Because the item link contains more than the name and if you turn the H into an h, it no longer is a correct item link, as a H is expected to start the color code, not a h.

And no, there is no workaround, because even if you manage to not convert the Hs, in the end your strlower will wreck havoc upon the item name once you have UTF-8 characters in it.

Yeah but since I am learning how all this works I am printing out every little piece of information. When the name of the item is displayed, it's lower case, yet it's mixed case in other places. So It's messing up comparing the string. At least that's what I think is happening, I'm still testing that. I didn't know that OnLootUpdate was passing the whole Item link until I started reading the responses.

I made "ZO_LinkHandler_ParseLink( objectName )" assign all 22 variables and it's still assigning the same information.

1: The item name
2: The color. Which is 3 bytes in Hex like ffffff or 2DC50E
3: The type: so far a string 'item' for what I have tested with.
4: The ItemId
5: Unknown, but it's 13 for most of what I have seen.

Then +18 other attributes which are usually 0.

Request, I need a routine to break #5 into flags. Can anyone help me with that?

Such that it displays:

{0x0001} 'Unknown1'
{0x0002} 'Unknown2'
{0x0004} 'Unknown3'
{0x0008} 'Unknown4'
{0x0010} 'Unknown5'
{0x0020} 'Unknown6'
{0x0040} 'Unknown7'
{0x0080} 'Unknown8'

I don't need the number in brackets, that's for clarification.

Xrystal · 04/15/14, 05:50 PM

During my testing of my gatherer addon I have noticed a pattern to the case differences.

Nodes ( Iron Ore, Jute, Maple ) etc. Are harvestable fixed objects in the game. Items ( iron ore, raw jute, maple) are the items you receive by harvesting from them.

So far, it has consistently been, objects = mix case, items = lower case. This means that they can be stored in the same table, with apparently the same key values and me treated differently.

EG.

Harvests[zone][node] = Nodes that were harvested. ( Harvests["Auridon"]["Iron Ore"] )
Harvests[zone][item] = Items harvested from nodes. ( Harvests["Auridon"]["iron ore"] )

That bit of information aside ...

If the item link is anything remotely like the ones in wow you will probably find that they will be markers such as quality, type, filterType, enchants, traits etc.

To figure them out look at multiple items with identical stats, and then ones with 1 or 2 different but the same in themselves. Ultimately you will see a bigger picture there.

Sharlikran · 04/15/14, 06:25 PM

Thanks for sharing that. I mean this wholeheartedly, in that proper variable naming is important. I think I see a lot of things with variables like 'item', rather then 'NodeName', 'NodeNumber', 'ItemName', 'ItemNumber' and so on. I'll have to review that and the API Functions to make sure I'm really evaluating things correctly.

I'll have to look at the API functions a little closer, because I want the None Numbers and the Node Names, not Item Numbers and Item Names.

Xrystal · 04/15/14, 08:19 PM

There are no node numbers. The node information you get from the interaction functions. But interactions are only tracked via an Update routine. There are no events currently at least that track interactions. A sample of my update routine that checks for interaction follows. But please note that I have noticed some flaws in the interaction results resulting in several checks before processing the information as valid.

Lua Code:

local playerInteracting = IsPlayerInteractingWithObject()
 
local interactMode = GetInteractionType()
if interactMode ~= INTERACTION_HARVEST then processingHarvest = false return end
processingHarvest = true
 
local action, name, blocked, extra, context = GetGameCameraInteractableActionInfo()

For say a mine (Iron Ore) the action would be "Mine" and the name would be "Iron Ore".
For a tree limb ( Maple ) the action would be "Cut" and the name would be "Maple".
For most others it is "Collect" or "Gather".

Occasionally however, I have had the "Use" of a crafting station show up as INTERACTION_HARVEST instead of a more appropriate interaction.