• 0

    posted a message on Version history (old files)
    To clarify before-hand, I'm talking about the packaged files that wowace makes when I update my add-on's repository - i.e. when I tag it.

    I just wanted to be sure, should I be deleting the old packaged files from my add-ons. Especially the ones that are out-dated in terms of UI version. Or do they eventually expire on their own? Or should I just leave them there for some archival purpose?

    So far I've only deleted versions that were broken (I didn't upload them right, or there was a huge bug that I didn't find in time).
    Posted in: General Chat
  • 0

    posted a message on Localization and Buff Names...
    I know to be careful with assumptions, that's why I put the "beta" tag on this version, haha. Not that that's an excuse for "carelessness," but I'm pretty confident it'll work.

    It is true that the plural is different than the singular. However, the itemSubType return value from GetItemInfo is always the plural form. And One-Handed, etc.., would not be included in this, as that is a different return value of GetItemInfo - itemEquipLoc.

    What is displayed on the item's tool-tip to the user is different from what is returned by GetItemInfo. The info on the tool-tips is usually in singular form, and I don't know where to grab those strings from. However, the return of GetItemInfo, for subItemType, is the plural form and that's what I'm actually going for. I'm using the plural string just to check, for example: if the player's current weapon a fishing pole (subItemType "Fishing Poles"), then do magic. The end user doesn't actually see or interact with the localized string.

    The only exception to that itemSubType is always plural "rule" was "Fishing Pole," but they did actually change that to "Fishing Poles" in 2.3.

    Edit:
    And in terms of fist weapons being unarmed, that was a good point and I double checked. There still is a separate proficiency spell for being able to equip weapons of subItemType Fist Weapons, http://www.wowhead.com/?spell=15590. Even though the crit and hit chance is still determined by your unarmed skill.

    Edit 2:
    I've been up all day coding, and going to classes, and am wayy to tired. Not that that's an excuse, but I see what egingell is saying now. On your list of four equations, the left side is the itemSubType, and the right side is the Skill related to hit and crit chance. However, the proficiency spells that I'm talking about that I'm using for the localized name is the spell that allows the character to equip each type of weapon. So there actually is a different spell for "One-Handed Swords," and "Two-Handed Swords." All your right hand values are of the TradeSkill type, I don't check against those, and I don't know where the localized version of them can be found in the game.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Localization and Buff Names...
    But it's the Skill to be able to use that weapon proficiency. Therefore I assume it will be the same.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Localization and Buff Names...
    Thank you all for the useful info.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Localization and Buff Names...
    Awesome thanks, I also found itemsubtypes are also spells:
    http://www.wowhead.com/?spell=7738 - Fishing Poles for example.

    Now if only I could find a way to get itemtype "Weapon" without relying on item cache. Currently I force a Fishing Pole item to be cached via GameToolTip for both "Weapon" itemtype, and "Fishing Poles" itemsubtype.

    Edit:
    Looking at GlobalStrings.lua I may be able to use ENCHSLOT_WEAPON for itemtype = "Weapon". Even though it's technically a different string, it should be the same.

    I always try to make any functional part of my add-ons independant of localization. This way I just leave what the User interacts with to the translators.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Localization and Buff Names...
    Part of my add-on needs to check against certain debuff-names, and it enumerates the player's debuffs with UnitDebuff.

    I noticed there were no "Buff IDs" like there are Spell IDs.

    However, in the english version, for every debuff I check, the spell that inflicts that debuff also has the same exact name. For example: Blind, Cheap Shot, and Sap.

    This makes sense of course, and I'm thinking I could get the name from the Spell ID instead of depending on translators. However, before I do that, I'm wondering if it's safe to assume the Spell and Buff name will be the same across all languages?

    Edit:
    Additionally does the GetSpellInfo() API function need the spell to be "cached" (like GetItemInfo()) on the player's client for it to work?
    Posted in: Lua Code Discussion
  • 0

    posted a message on math.random question on efficiency and distribution
    Sorry for my slow response time, I'm currently on vacation and don't have ready accesss to a computer. I do appreciate all of your input. I can see the arguments for the current Lua implementation of its Random function. I think instead of trying to work around the issues I have with their implementation, I'm just going to implement the Mersenne Twister code in Lua. It'll probably be painfully slow if it had to be called often, but luckily I only need to generate a random number about once weekly - however, it needs to be a very fair random generation (that's why I was concerned about 0's double probability).

    Haha, your reference for the "getRandomNumber" function would be much faster. And since the number only needs to be generated weekly, I wonder how weeks it'd take for people to realize it was constant. Although, given that they don't actually see the random number, but a result modified by that number, which also has other dynamic input - they probably wouldn't be able to tell. Why reinvent the wheel, when you can get away with pole vaulting? It wouldn't be a smooth ride, but it'd eventually get you where you're going.
    Posted in: Lua Code Discussion
  • 0

    posted a message on math.random question on efficiency and distribution
    Oooo, thanks, that's exactly the info I needed!!! I didn't know the source code was available like that. I see the reason they exclude 1.0, unfortunately they make 0.0 twice as likely to happen than any other number. But I guess the over all range is high enough that it won't significantly impact the randomness. If I really wanted to, I could do math.random, and if it returned 0.0, do math.random again to determine if I want to count that 0.0 as 0.0 or as 1.0. It should technically fix the actual distribution. But again, probably not necessary.

    Edit:
    From what I could tell the difference is rand() generates values between [0, 0x7fff] on most systems, but on some SunOS systems it generates [0, 0x7fffffff]. And Lua decided to take the rand() and mod it by 0x7fff. In my opinion they should just AND it with 0x7fff. This would make no difference for most systems, and only a small difference (only count the least significant 15-bits) on SunOS systems. It doesn't make sense to me that because SunOS systems generate random numbers differently that ALL systems should be impacted.

    Of course in the actual code, this would be (rand() & RAND_MAX), as typing (rand() & 0x7fff) would not be good practice.
    Posted in: Lua Code Discussion
  • 0

    posted a message on math.random question on efficiency and distribution
    I am familiar with the C version rand() that generates an integer value between [0, RAND_MAX]. Where RAND_MAX is a compiler defined constant.

    I see Lua's math.random normally generates floats between [0,1)
    Or with paramaters, it will generate within a given inclusive integer range.

    I am also familiar with how modulus division skews the distribution of the C rand() function. And the best way I know is to use a scalar method, where you do RANGE*(rand()/RAND_MAX) where RANGE is the range of numbers you want to generate.

    I was wondering if anyone knows if the call to Lua's random function with parameters for an integer range uses the modulus or the scalar method?

    If it does use the modulus method, then it would be better for me to use the float generating (no paramater) call. However, I am interested in how it generates the float. AFAIK random floats are generated as shown in the scalar method - from integers using floating point division. Which makes the smallest difference possible from two unique (non-equal) generated results to be 1/RAND_MAX. This makes ranges greater than RAND_MAX a little more complicated.

    Does anyone know the details, or where I can find the details, on how Lua's random function generates its floats (or integers for that matter)? And is RAND_MAX (or similar) defined in Lua or in WoW at least?
    Posted in: Lua Code Discussion
  • 0

    posted a message on Localization and WoW API
    Oh ok, I'll set the tooltip first thanks. Does GameTooltip:SetHyperlink("item:6256") not return until the information is available? Or may it return before it actually caches the info?
    Posted in: Lua Code Discussion
  • 0

    posted a message on Localization and WoW API
    Pardon me for bumping my own post, but I came up with a great idea for the problem with the GetItemInfo returns and localization! This will hopefully no longer need a translator to get the API right. I will explain how I did it, and I hope someone can confirm if it's done correctly (as I'm not 100% familiar with AceLocale-3.0).

    Firstly, the two return values I needed translated (in order to do a string compare) was itemType(6th return) "Weapon" and itemSubType(7th return) "Fishing Poles" from the GetItemInfo API.

    Unfortunately this requires translators to get the translation EXACTLY correct to what Blizzard uses for that localization of WoW.

    So I took the L["Weapon"] = "Translation"; and L["Fishing Poles"] = "Translation"; out of each Locale file. And instead added a line just after local L = LibStub("AceLocale-3.0") line in the main Lua.
    _, _, _, _, _, L["Weapon"], L["Fishing Poles"] = GetItemInfo(6256);

    6256 is the item id for "Fishing Pole" (the very basic item). I use this item id for my case, because it has both the item type, Weapon, and item sub type, Fishing Poles, that I'm looking for.
    Posted in: Lua Code Discussion
  • 0

    posted a message on AceConfig-3.0 + AceLocale-3.0 Localizing Options Table
    Ok, thanks. For anyone else who reads this thread, it does work with accented characters.

    I renamed a option normally Check, to Chìck (just to test). That's a small Latin i with a grave accent. Putting \195\172 in the string for the name did show up correctly in-game. And using alt+0236 on a US-Keyboard for ì successfully accessed the option.
    Posted in: Ace3
  • 0

    posted a message on AceConfig-3.0 + AceLocale-3.0 Localizing Options Table
    Ok thanks. I was missing the second set of brackets around LocalilzedName the first time I did it.

    Does the set of Printable Characters include accented characters not available on US keyboards? I've seen the definition of Printable Characters usually refers to 7-bit Ascii. However, the definition of Non-Printable Characters seems limited to special escape sequences such as NULL, form-feed, etc... Not sure on the grey area in between.
    Posted in: Ace3
  • 0

    posted a message on AceConfig-3.0 + AceLocale-3.0 Localizing Options Table
    I believe I tried to localize the options in my options table completely wrong.

    Quick Segment With Omissions (for naming purposes):
    local Options = {
        --...
        args = {
            OptionName = {
                name = L["LocalizedName"];
    


    Basically from that segment, you can see I assumed "OptionName" was just an internal name, and "LocalizedName" was the name of the option actually used. Continuing this assumption /myaddon LocalizedName would have been registered.

    However, I unfortunately found out that /myaddon OptionName was registered. Which makes Localizing it somewhat difficult.

    Am I missing something, or doing something wrong? Or should I move the whole Options table to each Locale Lua? I don't want German users (if it ever gets German translation that is) to have to remember English commands.
    Posted in: Ace3
  • 0

    posted a message on Localization and WoW API
    Ok, I got it. Thank you so much for your help.
    Posted in: Lua Code Discussion
  • To post a comment, please or register a new account.