- Registered User
Member for 15 years
Last active Wed, Dec, 10 2014 17:40:30
- 0 Followers
- 1,639 Total Posts
- 0 Thanks
Mar 3, 2011of course, if this is for bg's you know every enemy name to start with, so you could theoretically have a table of all enemies onscreen and then identify which ones are healers and which ones are more threatening than others based on damage done or killing blows or even how many times they've killed you today or whatever....Posted in: Addon Ideas
Mar 2, 2011it's too bad there's no means to generate a texture on the fly with the blizz api. if you could define a frame as being a texture, then have all the draw commands issued end up outputting to the texture, then you could draw that texture with an alpha. that's really the way to do what you're looking for.Posted in: AddOn HELP!
Mar 1, 2011so i tried something simple today.Posted in: Lua Code Discussion
right after creating my parent window frame, i use SetFrameLevel to set the frame level to 129 since this seems to be the point of failure in all my bug reports.
sure enough, all the children are created at the wrong frame level. they seem to hit the 128 frame level boundry and are "behind" their parent frame. granted, this isn't exactly the error i'm running into, but it does illustrate that there's an internal issue with how blizz is handling their frame level code.
Feb 12, 2011i'm guessing that "buttons" hasn't been defined by the time the OnShow event fires for the parent frame. you should check the blizz template code lua files to see when/where/how the buttons field is created.Posted in: Lua Code Discussion
Feb 7, 2011so i've had another report of the problem and this is coming from a different user. the "buggy" frame stack straddles the 128 frame boundry again. the parent frame is at level 129, all its children are okay except for what should be the top level frame which has been reordered down to level 128.Posted in: Lua Code Discussion
it can't be a coincidence, imo.
i need to come up with a good way to test this. i'm wondering if the problem could be caused by some other frame trying to move around by great a distance (128 levels) and confusing the level tracking system....
Feb 6, 2011i checked and i'm no longer using the "SetUserPlaced" system, so i'm thinking that isn't factoring in.Posted in: Lua Code Discussion
i ran some test to see if i could debug things further.
i created a simple macro to adjust the frame level of my main frame. all children update appropriately. if i increase the level of my main frame by 10, all children update by 10 as well. what's interesting is that these numbers get reshuffled when other windows come and go. they don't always go back to the same point, either. they adjust downwards in what seems like a rough stab at collapsing unneeded gaps in the frame level list... or something. it's pretty inexact.
Feb 6, 2011Posted in: Lua Code DiscussionQuote from FarmbuyerNot that I know of.
This may be helpful or may just be cool-story-bro verbosity: the only times I've come across abnormally high frame levels are when an addon author has tried to handle movable windows in a sane way and store their positions in a SavedVariables file, but screws it up and leaves it in a state where size&position get written to layout-local.txt also.
At load time, the author thinks that the various "restore position" bits of code he's written are doing the work, when really it's the game engine overriding everything with layout-local.txt data. Visually, there's no difference, so it's hard to explain the nature of the bug to the author (who, very reasonably, asks for some kind of demonstrative proof of error).
One of the annoying side effects in this scenario is that the frame level of layout-local.txt is restored as well as the size and position. Unless the frame handling code is careful, child frames of the restored frame will start in the (say) 50's and go up from there, and there's no obvious reason why until you look in layout-local.
interesting. i'll look into this. not sure it would explain the frame level creep since i don't ever see it on my end, but perhaps in other usages it could enter into it.
any idea about why it would suddenly rearrange things? i know there's a quirk in frame levels where you can't set a frame level beyond 128 unless you do it in multiple steps. i'm curious if the underlying cause of that is related to some kind of automatic reshuffling being triggered as opposed to some arbitrary rule blizzard came up with... i posted on the ui forums, so maybe somebody there has some insight.
Feb 6, 2011does the blizzard api trigger a frame level re-organization under certain circumstances? like perhaps when frame levels get too high or too sparse or something?Posted in: Lua Code Discussion
gnomeworks is having an issue where the frame levels get f'd up for some people. the framstack is showing frame levels in the 64 and 128 level range for the screenshots i've gotten so far when this is happening. the frame that should be on top is on the bottom and has a sub-64/128 level while the frames that should be below it straddle the 64/128 level (some are above, some are under).
these are frames that are generated and work fine until something triggers them to suddenly rearrange and fail.
Feb 5, 2011Posted in: Lua Code DiscussionQuote from egingell"Soulbound" may be part of the item link (possibly in the UniqueID portion? -- in which case, there would be no way to accurately determine its bound state), but it is not used by the client or the server when it's passed to :SetHyperlink(). Mostly because there's no reason to.
am i understanding that right? when you call SetHyperlink() it doesn't send the uniqueID portion of the link?
Feb 4, 2011Posted in: Lua Code DiscussionQuote from AdirelleAFAIK, sometimes the tooltip:SetXXXItem are asynchronous if the item isn't in the cache client or so, e.g. the tooltip takes some time to be filled and its content won't be available when you'll test it. In that case the function would likely return false.
Moreover, scanning several items like this causes several requests to be send to the server and on the server side, there is a throttling mechanism that causes the client to disconnect if you send too many requests in a short period of times.
Disclaimer: both of these behaviors may have changed with the Cataclysm client but I'm not aware of such changes (and there is little information about this).
the problem with too many requests really only relates to invalid items (ie, those the server either hasn't seen since restart or are simply bogus). if the id's are valid and the server has the items in cache, i don't think you have to worry about too many queries in too short a time (unless you trigger a generic traffic flood throttle). if you're scanning your own items on your toon, then the server should have them in cache and throttling shouldn't be a concern in terms of dc. you still will have to set up some kind of OnUpdate check to determine if data is available locally.
Feb 4, 2011Posted in: Lua Code DiscussionQuote from LombraFor the record, the reason SetHyperlink didn't work was it needs to be passed something like "item:itemIDGoesHere". But yeah, even then it would never show up as soulbound.
should SetHyperlink work on an itemlink? the "item" he was passing the function was a link.
so does this mean that itemlinks DON'T contain soulbound status via the uniqueID data?
Feb 3, 2011i think (but i could be wrong) the soulbound status is in the uniqueID field of an item string. so if you get the itemlink, you should be able to use a tooltip to parse it for the "soulbound" keyword.Posted in: Lua Code Discussion
- To post a comment, please login or register a new account.