kk Ill try this at home today. If its AH - then I suppose that AceHealSquishy code need to be rewriten if it prevents from clicktargeting
AceHeal will competely take over your clicking functions for the frames it modifys. Just assign either "Select" or "TargetUnit" to your Left Click.
Working as intended™ :P
I kind of have to agree...if I had my left click for aceheal bound to a heal or some other function and suddenly it was overwritten by acehealsquishy to be a targetunit I'd be a bit upset!
However, maybe there could be some function that says something like "hey if nothing is bound make it targetunit, but if something is bound leave it well enough alone". I've got to think there must be something like that for other interfaces between whatever unitframes uaxli was using and aceheal now or they'd have had this problem before?
I could try to play around with that and see, but then its one of those "if its not broke don't fix it" things. I'd just be adding more code to possibly break / cause bugs.
It's not that hard to just assign "Select" to your left click now is it? :)
Sorry I haven't had a chance to look into anything. Real life intervened a bit. Changed application frameworks on the "real" project I'm supposed to be working on, and had to spend a lot of time getting back up to speed. Anyhow, I hope to have commited a few bug fixes to SVN by the end of this weekend. :)
General question to anyone who uses TortoiseSVN.. I tried using it to update this, locals files and credits won't update (red arrow) but it updated the others ones.. anyone know what I'm doing wrong =x
Rulan, regarding Tortoise: I've never used it myself as I'm running OSX and therefor svnX instead. But I guess that if you have problems updating your version you could simply rename the existing folder on your harddrive (mainly as backup) and then do a completely new checkout of /root/trunk/Squishy - it should redownload all files.
I'm waiting for a few things to happen (tekkub might write a range-check library I'd embed in Squishy, codayus planned to fix some bugs), and once we have a stable version (hopefully in a week or so) I'll upload a .zip to somewhere for the people who don't have access to the SVN. I'm still hoping Cladhaire will find a solution to provide automatically generated tarballs soon again though.
Currently trying to track down some odd and very intermitent bug to do with priority sorting that may not even exist. Driving me nuts. Okay...more nuts. :)
FYI: I've tracked down the reason why not all frames are properly updated with new units. I've completely rewritten that code in a "simulated raid behaviour" (aka I copied the code to an empty addon, simulated the existance of a roster with health changes on random basis etc).
Current problem: the code has about 100 lines. And I'm very sure I've chosen a complicated way and there is lots of room for optimization. Which is why I'll spend some more hours with the code (now I finally found a working solution) and will try to reduce it as much as possible. Once that's done I'll update the real world code and release a new version of Squishy.
uploaded a new version to the SVN. The code responsible for displaying units in the emergency frame was completely revamped. I've tested it in a AV pug for the last hour, and finally seems to work.
Maia, been meaning to tell you, I see a ~3KiB garbage churn when Squishy is shown. I don't know what portion is causing it, but you might wanna look into that.
I hope to get the rage library done shortly.... ugh, I hate employment...
Tekkub, as for the garbage churn, I guess it's that I'm frequently overwriting arrays and should replace a hello = {} by a: for k,v in pairs(hello) do hello[k] = nil table.setn(hello, 0) end - or use CompostLib instead. Doing that is on my to do list, but as I failed implementing compost lib some weeks ago it's not done yet. Or is there anything else that's commonly responsible for garbage churns?
As for the range check library: I'm desperately waiting for it and planning to include it as soon as you upload the first version to the svn.
Tekkub, I've taken a first glance at ProximityLib and might be able to add it later today (or tomorrow). The only thing I'm somewhat unsure about is that no range info is available for 0.5sec whenever the roster is updated, as this can cause some problems - not only for Squishy which will then have to resort the units in the emergency frame, but mainly for situations like: raid leader switching to master loot in the middle of a boss fight, tanks/shaman groups get swapped during the vael fight,...
Is there no possibility to store the old range data when updating the roster?
Also I'm curious how you're dealing with incomplete roster information. The reason why I'm having tons of roster checks in Squishy is because from my observation the roster data isn't always complete after roster-related events, and GetNumRaidMembers() can return wrong values as well.
PS: do you know of any other addons that will either use the entire library or the unit iterator code so far? What about PerfectRaid, X-Raid, MiniGroup2, the oRa-MT module,...?
considering I put it up last night, I doubt anything does :P
Are roster changes happening mid-battle? I can force a full update after a roster check, but it won't catch stuff outside the 30yd range until a combat log event fires. I guess the real question is how MUCH does the roster change on an event? I'm just kindof assuming it's totally different, wiping it, and restarting. I guess I could reverse the logic and store by unit name instead of unitID, and reverse the lookup as well (it would still take a unitid for lookup, but would pull from the table based on name. Give it a test run and I'll look into changing that stuff. Don't worry, I won't remove or break anything in the API, only add to it.
yea, but how much does it really CHANGE? I mean, I know the event fires a lot, but do unitids rearrange a bunch when it doe? Guess it doesn't matter, the more I think about it, the more indexing by name makes more sense.
AceHeal will competely take over your clicking functions for the frames it modifys. Just assign either "Select" or "TargetUnit" to your Left Click.
Working as intended :P
I kind of have to agree...if I had my left click for aceheal bound to a heal or some other function and suddenly it was overwritten by acehealsquishy to be a targetunit I'd be a bit upset!
However, maybe there could be some function that says something like "hey if nothing is bound make it targetunit, but if something is bound leave it well enough alone". I've got to think there must be something like that for other interfaces between whatever unitframes uaxli was using and aceheal now or they'd have had this problem before?
It's not that hard to just assign "Select" to your left click now is it? :)
I'm waiting for a few things to happen (tekkub might write a range-check library I'd embed in Squishy, codayus planned to fix some bugs), and once we have a stable version (hopefully in a week or so) I'll upload a .zip to somewhere for the people who don't have access to the SVN. I'm still hoping Cladhaire will find a solution to provide automatically generated tarballs soon again though.
Currently trying to track down some odd and very intermitent bug to do with priority sorting that may not even exist. Driving me nuts. Okay...more nuts. :)
Coming shortly: Optional pet support.
Current problem: the code has about 100 lines. And I'm very sure I've chosen a complicated way and there is lots of room for optimization. Which is why I'll spend some more hours with the code (now I finally found a working solution) and will try to reduce it as much as possible. Once that's done I'll update the real world code and release a new version of Squishy.
I hope to get the rage library done shortly.... ugh, I hate employment...
As for the range check library: I'm desperately waiting for it and planning to include it as soon as you upload the first version to the svn.
ProximityLib got SVN'd last night, give it a looksie (there's no useful comments/documentation yet tho)
Is there no possibility to store the old range data when updating the roster?
Also I'm curious how you're dealing with incomplete roster information. The reason why I'm having tons of roster checks in Squishy is because from my observation the roster data isn't always complete after roster-related events, and GetNumRaidMembers() can return wrong values as well.
PS: do you know of any other addons that will either use the entire library or the unit iterator code so far? What about PerfectRaid, X-Raid, MiniGroup2, the oRa-MT module,...?
Are roster changes happening mid-battle? I can force a full update after a roster check, but it won't catch stuff outside the 30yd range until a combat log event fires. I guess the real question is how MUCH does the roster change on an event? I'm just kindof assuming it's totally different, wiping it, and restarting. I guess I could reverse the logic and store by unit name instead of unitID, and reverse the lookup as well (it would still take a unitid for lookup, but would pull from the table based on name. Give it a test run and I'll look into changing that stuff. Don't worry, I won't remove or break anything in the API, only add to it.
Because the priority for an healer is to stay alive :)