shirsig

That's not possible. The addon will technically always have to target to cast a spell, with the effects that brings like losing combo points. The issue must be some hook conflict or some other weird thing it does when casting with that macro. I'll look at it when I have time.

There's no such distinction. The timers appear as you cast a spell and stay no matter what you target. The text on the bar is the name of the target. You may have bars for many different targets. "let you cast spells on your focus target" what does this mean?

Well, what do you mean exactly by casting on your focus? If you target your focus and then cast it's not really anything special. If you mean a special function of the addon (which would have to do the same thing because there's no focus in the vanilla api) then the problem would likely be caused by conflicting hooks. Seduction and freezing trap don't use the player cast events (because they can't, neither being directly applied after a player cast). This makes them less accurate (e.g., no way to know the rank of the spell or if it's actually the player's or comes from anyone else in combat log range). I've added the additional restriction for them to only show on the current target to avoid being spammed with bars in a bg/open pvp raid.

Clearly, that's why I'm literally quoting the incoherent parts asking for clarifications ...

Shouldn't be. Except for seduce and freezing trap, which are special cases.

Why would you "post with them"? What does that even mean? 24g is what your bid has to be if you want to be at the top of that listing. Either that or you have to reduce your stack size. Obviously if you're posting a 6 stack you have to go very low to be above a 1-stack. (about a 6th) The point of the bid listing is not to "show what a reasonable price would be". That's what the percentages/buyout listing are for. The listing shows what your price needs to be to get a certain position in the listing.

If someone gives you a puppy do you complain it's not an accurate cat? that makes no sense. The values are all accurate, they're just defined differently.

I told you exactly what the bid value is: "the unit bid you would have to choose to get the same stack price as that auction with your currently selected stack size" Why on earth would that not change when you change the stack size? Let me explain by example: Let's say there's an auction stack size 10 10g. You're posting 20 units. If you post it at stack size 20 you need a unit price of 0.5g to match that auction's stack price. If you're posting at 10 then you need a unit price of 1g (same as that auction's). If you're posting at 1 you need a unit price of 10g.

You can already do that with double click. What?? You still haven't even told me what exact value you want to see and why.

with your currently selected stack size

It's not an inaccurate bid, it's accurately "the unit bid you would have to choose to get the same stack price as that auction with your currently selected stack size". (which is useful because it's close to the one you will get when undercutting)

What's an "accurate bid"? A unit bid? Stack bid? I look at the listing in your screenshot and I see exactly what I need to know. I see that all those 1-stacks will be listed above me (colored in red) and that I would have to go for a very low unit price (~5g/20% of historical value) to change that due to my own high stack size. Further I see that the 10 stack there would already be undercut at 46g unit price so I can just leave the bid at the 25.5g, same as the buyout, as it would make no difference.

I still don't understand why the prices in the old listing are useful at all. They're not "more accurate". They're just different values (and not useful for default ah positioning). You do realize that if you undercut the unit price in the old listing that doesn't mean you will be listed higher in the default ah? (because the default ah sorts by stack and not unit price)

I can only repeat what I just said: The low percentages are not asking you to post that low, they're warning you not to. The default ah sorting is by stack! price. If you post a stack of 6 you will have to go for a very low unit price to undercut the stack prices of all the 1-stack auctions to be listed above them. So either you should reduce your own stack size to 1 (which will show (6 times) higher values in the listing or accept that all the 1-stacks will be listed above yours and only undercut the first bid entry with a high percentage or none at all.

Ok but then you are talking about default ah positioning so why are you interested in the bid unit prices (which is what was shown before), I still don't understand. The current listing doesn't show "reduced" bid unit prices, it shows normalized stack prices. I think the old listing both showed and sorted by unit prices, making it pretty useless for this. Now, since it's sorted by stack price (normalized or not) the position in the listing corresponds exactly to the position in the default ah listing. If you undercut entry 1 in the listing, your auction will be at the top, if you undercut entry 2 it will be 2nd, etc. The color coding now works by this logic too. If you undercut your competitor in the buyout listing the corresponding bid will show up red if they do as you said. The low percentages are not asking you to post that low, they're warning you not to. If the percentages are too low you should either lower your stack size or accept to be low in the listing.

Yeah, no, sorry, there's no way to do that. The easiest way I can think of would be to use git and even then you might still have to manually merge when there are conflicts. Strings can be moved to different files, they can be dynamically generated, they can be changed (in meaning, formulation, ...), new ones may be added etc. There's no way to localize once and then automate it for further updates. Note though that if you ever want to do anything related to software engineering you'll have to learn how to use a VCS and git is extremely popular with no replacement in sight so it's one of the best investments you can make in that regard.

Well, that was the only reason I ever added the bid listing in the first place (someone requested it for that purpose). I don't know any other good reason to even look at the bids. There's no point in undercutting the bids in the same way as buyouts because they increase anyway as soon as people start bidding. Anyway, it seems most people don't even want that, which is why there's no bid listing at all now by default.

You're missing the point. The bid listing is for undercutting stack prices (so that you'll appear higher up in the default AH). The unit bid prices of the auctions are irrelevant. There's no point in even looking at them for reference. That's what you got the buyout listing for.

Discount? What would be preferable? The unit price is useless for undercutting the stack price. It would be all over the place. The stack price is naturally used for the sorting but it's not that useful for the listing because it doesn't show what unit price you'll get. That's why I normalize it by the stack size (that you have selected). Matches the stack price sorting and also shows what kind of deal you'd be making.

That's no mistake. Not sure what you expect from me, to copy paste a git tutorial? This sort of thing is exactly what a VCS like git is for. You can either learn how to use it or, the only alternative, like you've done so far, do everything by hand. Not sure what you mean. How doesn't it?

Yes, I just mean that after a certain point you would get lag spikes whenever the table is updated with a new page or when manually sorting. It stops listing any newly scanned ones after the limit. You can always use the clear button to make room for new ones. The default UI only ever shows you one page at a time. In any case, I don't really see any reason to ever use a filter that will make it reach the limit. Of course if you only scan for history it doesn't really matter but it never hurts to add for example a profit filter.

You can do multiple scans using semicolons. E.g., "peacebloom/exact;silverleaf/exact" It's the opposite, like it says, it won't be shown but it will be considered for the history. The only reason for the limit really is table sorting performance.

Sort of. What you can is filter by tooltip entries (post filter only). For example "scouting gloves/tooltip/of the monkey", or "scouting gloves/of the monkey" for short (unknown filters in positions other than the first are automatically treated as tooltip filters), or more specifically e.g. "scouting gloves/+4 agility/+4 stamina"

Well, I don't know which version you started from nor what changes you made so no way I could know. You'll have to learn to merge if you want to keep this up to date or you'll go insane anyhow.

Hey. I'd be happy to link to your localized version, thanks. The progress bar should be fixed. As for the tooltip issues, I cannot reproduce them. The darkening must be caused by another addon (or at least a conflict with one), the repair price seems to not exist in the default UI (except for the one on the "repair all" button) so the problem would be a "conflict" with whatever addon adds it. There is a version history (https://github.com/shirsig/aux-addon/commits/master) or else I'm not sure what you would mean. The proper way to get my changes would be to use https://git-scm.com/docs/git-merge. This does most of it automatically, inspecting and possibly adjusting only the few places where there are conflicts. Just commit your changes if you haven't deleted the git repo file (or get it again from the version you started with first). If you're new to git there are countless tutorials. Github hosts your repo for free for backup and distributing.