• 0

    posted a message on Aloft - Customized Nameplates - Official Thread
    Quote from Thortok2000 »

    Keep in mind, I'm still willing to pay $10 for a fix to the HealthBarColor tag bug.


    very close to being done with all the threat chrome i can think of, and will be moving into bugfixes next.

    i won't need $10, i will fix it for the fun of it. just a matter of reaching that part of my TODO list :-).
    Posted in: General AddOns
  • 0

    posted a message on Outdated addons but no replacement
    Quote from tripeX »

    I have sever outdated addons running with my WoW install but I never found a real replacement for them, which fits my needs/flavour.


    FYI, i am hoping to take over Aloft (which i believe might fall in this category)... actively coding, just trying to figure out where to host the codebase, ongoing into the future. this would (i hope) take Aloft out of this "outdated and irreplaceable" category.
    Posted in: AddOn HELP!
  • 0

    posted a message on Aloft - Customized Nameplates - Official Thread
    my threat-2.0 tweaks are stabilizing. i am waiting to see if WoWAce will grant me SVN access in a "timely" fashion (i.e. within the next 10 days or so).

    if not, looks like the WoWInterface SVN is up and running, so that is where i will head next.

    in the meantime, i will keep working on features and defects. every time i dive into something, to figure it out, i learn more about the Aloft code overall...
    Posted in: General AddOns
  • 0

    posted a message on SVN access?
    awesome... looks like TortoiseSVN has a comman-line capability.

    soon as i have SVN access i will give that a try.
    Posted in: AddOn HELP!
  • 0

    posted a message on SVN access?
    i am in the process of taking over an addon (Aloft, hosted at WoWAce; its author does not appear to be maintaining it any more).

    if continuing to host the codebase at WoWAce is not in the cards, and the codebase needs to be taken elsewhere for ongoing maintenance/enhancement, i would like to do that in as smooth a fashion as possible, without forking the codebase such that it is receiving maintenance in multiple locations. on the other hand, if it can be maintained here at WoWAce, then i would like to be able to do that.

    anyway, i have read and signed the SVN rules... edit: DOH! didn't read them carefully enough... i will now contact the Ace Admins, per the instructions. sorry about that. still interested in the changelog extraction, as discussed below.

    as well, i would like to be able to extract the full changelog (just once, preferably in some useful and semi-human-readable form; text, XML, a giant HTML document, whatever), so that i can bundle it with the addon as a legacy artifact when it moves to another hosted repository. i have rummaged around in the FishEye interface and its documentation, and i don't see a way to pull this down, and i am completely ignorant of RSS and its capabilities. will the changelog be hosted by WoWAce in perpetuity, in some form? if so, maybe i can just incorporate the link to the "new" WoWAce (when it emerges) as the "legacy artifact". if not, getting some advice on the most efficient way to extract the changelog would be helpful.

    anyway, thanks for any information you can supply.
    Posted in: AddOn HELP!
  • 0

    posted a message on Aloft - Customized Nameplates - Official Thread
    Quote from Anatoll »

    This is from the beta forum:


    well, that doesn't look too bad :-). i will add that to my TODO list for WotLK.

    thanks for the pointer.
    Posted in: General AddOns
  • 0

    posted a message on Aloft - Customized Nameplates - Official Thread
    on deficits:

    i can supply relevant deficit text tags for everything (many are already implemented in the original Aloft), and while it is likely i could jump through some frame overlay hoops to animate mana deficits on a bar (along the lines of the Aloft legacy threatbar implementation, or any number of status/cooldown/unit bar addons)...

    the healthbar Aloft uses appears to be the underlying blizzard nameplate graphic (apparently mined out of the children of the WoW client's root frame). Aloft tweaks the shape/texture of this frame, but i doubt there is a way for an addon to control (easily) how it is animated. there is no simple "SetGrowDirection()" API method i can call to tweak things (if there were, i expect it would save addon developers a lot of grief).

    since health deficits are acually the useful deficit metric, and since it looks infeasible at the moment to do something like this with the health bar (or at least rather complicated in terms of inserting texture overlays into the healthbar frame heirarchy and debugging the whole mess), i think i will set this concept aside for now.

    once i am no longer so much a LUA/WoW-API newbie (or if other folks see this and offer some ideas), maybe something will become feasible later.
    Posted in: General AddOns
  • 0

    posted a message on Aloft - Customized Nameplates - Official Thread
    Quote from Anatoll »

    PS: Thanks for taking a look at this addon. I really miss the threat bar.


    happy to do it!

    thanks very much to Anatoll for the WotLK report, and to Thortok for the explanation of what constitutes an "Ace mod" (at least i now understand the rationale :-)).

    "turning everything on" in Aloft might uncover other issues, but at least the basic functionality is there. i will look into how Aloft expects use those hooked API methods... sounds like they don't exist or the functionality has been relocated/renamed in WotLK.

    i have a threat bar implementation "working", complete with threat text, based on r80814 (the changes to 80814 were minor, as people have stated, and in any event did not relate to anything i was fiddling with).

    i will be working on some code cleanup, simplification, and etc, with an eye towards a) efficiency with regard to changes in threat and b) isolating interaction with Threat-2.0 such that migration to the WoW 3.x native threat API (where appropriate) will be as quick and as easy as possible.

    i have no ETA, nor am i necessarily comfortable right now trying to move Aloft to a place like WoWInterface if people are still committing changes to the WoWAce SVN (would be troublesome to fork something the size of Aloft, and end up with multiple bugfix repositories, etc, especially when i don't have any current influence over the Aloft codebase lifecycle at WoWAce; it doesn't appear to be quiescent, which was one of my basic operating assumptions in all of this). i could use the WoWAce SVN myself, i suppose, but have not looked into gaining commit access to it, or anything of that sort (at some point i guess i can just try it, and see what happens?). i will keep thinking about this. in the meantime, maybe Kaelten will get closer to refactoring the site and the problem will get solved for me. at that point, i could just post my version as a "fan update"/"beta" and try to coordinate with anyone else who tried to do the same thing.

    in the coming days, i intend to dig into this HealthBarColor bug (i would expect a similar problem to exist with ManaBarColor, if such a tag even exists), and i will play with a deficit display option for healthbars, manabars, and threatbars (assuming showing threat that way even makes any sense :-)). adding these options would probably not be a big deal, once i know what i want to do and how to do it (for instance, anchoring frame growth on the left or right... i don't know the API well enough to know if that is even possible). i also want to play around with the Frame:SetHeight() API, this seems to be causing the mouse access problems i mentioned in an earlier post (apparently moving a nameplate's visible healthbar frame out of intersection with its anchor point via Frame:SetHeight() seems to make the whole nameplate dead to the mouse; dunno if there is a workaround).

    if anyone spots anything more in WotLK, or wants a feature, or whatever, just shout out here.
    Posted in: General AddOns
  • 0

    posted a message on Frame:SetHeight() side-effects?
    Quote from rodrick »

    I seem to remember that the orig. nameplate locaiton/size is what is clickable no matter what you do with the nameplace loc/size in aloft. Have you tried clicking where the orig. nameplate should be if you didn't change it height?


    thanks for the feedback.

    that was the first thing i tried. the whole nameplate area, where the graphics appear after Frame:SetHeight() is called, *and* where they should appear if that had not been done, seem to be dead to the mouse. i have tried mousing and clicking everywhere in the vicinity, to see if the frame responds. no joy.

    i do remember something else i tried: if i make the frame large enough on the screen (via changing the frame's dimensions; specifically in this case by making it tall enough), it does come alive to the mouse. perhaps what is required is for the dimensions of the frame to intersect its (original) anchor point? this happened when clicking over the visible parts of the frame, not by clicking anywhere near what would be the original anchor point.

    would i be able to "insert" some sort of little dummy frame into the nameplate frame heirarchy somehow, as a parent/attachment point for nameplates, and then use SetPoint() somehow to affect the visible graphic components of the nameplate frame)? it would be the visible components that would have the EnableMouse() API methods invoked on them, not this manufactured (and presumably invisible dummy) frame. i suppose if the anchor point theory above is correct, this would probably not help. but... assuming for the sake of discussion that it would work, would there be any material difference in runtime efficiency (that anyone can think of) between SetPoint() and SetHeight() (i.e. on a large number of frames)?

    just thrashing around wildly, as a direct consequence of ignorance...
    Posted in: Lua Code Discussion
  • 0

    posted a message on Aloft - Customized Nameplates - Official Thread
    first of all, i am still looking for a clear testimonial as to whether Aloft even works under WoW 3.x (WotLK beta). at this point, knowing which version(s) of aloft are in use would be helpful too.

    Quote from Scyqe »

    instead of having bars under a nameplate, would it be easier just to integrate in a "threat text" feature into the nameplate, just like health text and mana text and such? or is it just as difficult?


    text would be roughly as difficult, from the monitoring perspective (monitoring events, gathering the data, etc).

    text alone would perhaps be simpler than a graphical element like a bar... but in this case the bar part already exists in Aloft, and seems to work fine (though by default it is commented out, along with the gathering part, which has historically been obsolete, since the release of Threat-2.0), and there has historically been no associated threat text capability (nothing that i can find, anyway).

    so, in my own test version locally, i have the event-driven threat-gathering stuff working in conjunction with Threat-2.0 (though this will need benchmarking and refinement, for the sake of efficiency), and the threat bar code is re-enabled and feeding off of this alright (at least so it appears). i am working on the threat text component now, there will be a variety of threat-related tags for aloft text labels, comparable to what is already available for mana.

    i can look into adding a "text only" option for threat, that would disable the threat bar but allow embedding of threat-related text tags into other text strings (like the one for health, etc). should not be hard.

    i can also look into a deficit-oriented display of health and mana. i expect that would involve just checking the relevant configuration option and changing the way the bars grow/shrink (in the form of a quick little piece of arithmetic). relevant deficit text tags appear to exist already.

    i will also look at the HealthBarColor tag. i don't use it myself, so i have no idea how it should work, or actually does work, or etc.

    woops, looks like Aloft just received an update, after all these months... and the changelog truncated. now at r80814 (up from 69497), with none of the intervening changelog entries (so i have no idea right now what changed). i will have to bring that version in locally and poke around, see what might be different, and/or see if i can get browser access to the Ace SVN and see if that can tell me anything.

    p.s. i guess i assumed MobHealth was an "Ace mod" since i have always picked it up from there. i suppose i don't know the details, or why something hosted and distributed via the Ace repostiory (at least as one of its locations, detailed bug-fix changelog and all) would not be an "Ace mod"... if this is important in some way, perhaps someone could explain the rationale behind which is what is which?
    Posted in: General AddOns
  • 0

    posted a message on Frame:SetHeight() side-effects?
    i have been working with nameplate code recently (specifically, integrating the old Ace standby, Aloft, with Threat-2.0), and i have noticed something.

    if the height of a nameplate, as it appears above a unit's head on-screen, is adjusted with Frame:SetHeight() by a large enough value, the nameplate frame quits recognizing the mouse (i mean completely; mouseover and clicks do nothing anymore, even when they should). if one reverses this, restoring the height to something approximating the original value, then the mouse is again recognized.

    i thought it was a "bug" in something Aloft was doing, but Aloft basically just resolves to a Frame:SetHeight() call on the nameplate frame (though granted Aloft does replace this frame's texture, add things to its text region(s), move those text region(s), glue other frames on, and etc, though fundamentally it appears to originate as, and remain, the underlying blizzard nameplate frame).

    i rummaged the web, these forums, the WoWWiki, and etc, for information relevant to Frame:SetHeight(), and pretty much just got code snippets from SVN repositories. no mention of "bugs" that i could find.

    has anyone else noticed this? assuming so, is there any sort of workaround anyone can suggest?

    i am new to LUA and the WoW API environment, but neither the varoious bits of the blizzard native mouse API, nor the remaining bits of the Frame API, appear to be relevant (nothing to do with increasing the area of mouse sensitivity, etc).

    thanks.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Aloft - Customized Nameplates - Official Thread
    Quote from Kerecha »

    Is there any way to get Aloft to pull its mob HP info from MobInfo2 instead of mobhealth?


    i can add this to my list of things to look into. seems like it could be an option, but of course the core Ace functionality for this (and Aloft is an Ace addon) is MobHealth, so this might need to be a line that stays drawn. MobInfo (and i use both) has always seems more like a self-updating database for feeding tooltips than a means of affecting live data display during combat, but i could be mistaken. i would have no idea of their relative merits for this purpose.

    has anyone had a chance to try Aloft in the WotLK beta? is basic functionality even there?

    update:

    starting to get a decent handle on how to integrate LibThreat-2.0 into Aloft, and restore some threat indicator capabilities to the current version of Aloft. this is proving to be a good little project for getting familiar with the structure/flow of Aloft's codebase and runtime behavior, etc.

    right now, seems to me the right approach is to model basic Aloft threat bar semantics on Aloft mana bar semantics (i.e. show only on the current target, make it as narrowly event-driven as feasible, for efficiency), and drive threat indicator updates via the same events Omen uses (Threat-2.0 callbacks, PLAYER_TARGET_CHANGED, and etc). progress has been slow (completely new tools and APIs for me, not historically a LUA developer), but there is progress :-).

    the WoW 3.x threat API looks like it will have some threat-specific events that (at the moment) appear to be appropriate for this, which will be even better for 1v1 unitid-based threat tracking than the approach currently emplyed. how well the new WoW-native threat API and event model will suit group-oriented threat display and AOE-derived threat (i.e. showing everyone's threat at once relative to each other, and tracking AOE damage, stuff that current threat meters do by comprehensively sniffing the combat log) is not clear to me, but as far as "player" versus "target" is concerned, it looks "easier" to do with the new API.
    Posted in: General AddOns
  • 0

    posted a message on Aloft - Customized Nameplates - Official Thread
    Aloft does not have unitids to work with, so cannot use DogTag


    ahh yes. i suppose i had been thinking in terms of incrementally collecting unit GUIDs, as targets were moused over, selected, and etc (and their GUIDs could be constructed)... Aloft does a fair bit of this anyway, caching a variety of different data in its map of nameplates, so i was just going to piggyback. but most of what DogTag can offer really isn't all that relevant to what nameplates are supposed to do anyway, and GUID sniffing would be unwieldy at best (and most likely just impossible).

    for something like a threat bar on the name plate, its going to be your threat versus your current target, and unit ids are trivially available for that relationship.

    thanks for spotting that earlier post. good sanity check. saved me a bunch of time fiddling around with a stupid dead end :-)
    Posted in: General AddOns
  • 0

    posted a message on Aloft - Customized Nameplates - Official Thread
    Quote from Arthenik »

    I tried searching for a TagCompiler FAQ regarding the syntax and I have been unable to find anything.


    there is a TagCompiler RTF document, at least summarizing the syntax, distributed as part of Aloft. i have rummaged the Aloft code for various purposes over the past year or so, and have seen tags implemented that don't appear to be documented in this RTF document (like PetOwnersName), but the RTF does supply some examples and a summary of pretty much all the tags.

    hope that helps.
    Posted in: General AddOns
  • 0

    posted a message on Aloft - Customized Nameplates - Official Thread
    I would actually strongly prefer that Aloft did not use DogTag.


    good point. i may deprioritize this, or code it in such a way that the choice of tag system can be selected somehow. i was not aware DogTag was... a dog? i use it several places (or the authors of the mods i use use it several places; IceHUD, CowTip, etc), and i have been accustomed to doing things with it. it just seemed natural to bring Aloft into the fold. anyway, setting it up so that either could be used could permit some benchmarking, and that would probably be the only way for me to really clarify this to myself.

    threat values will now be exposed through the WoW API and will not require Threat-x.0 to estimate them.


    i will try to dig into the new WoW-organic threat API (and maybe i can compare current and beta versions of Omen, Diamond, KLH, and etc, assuming they exist). again, perhaps, it will be easy to do it one way for the next month or two and then swap over when WotLK actually arrives. i am still looking at how Aloft collects and maintains unit data for use in nameplates, there is an elaborate lifecycle there, of which threat is just a part...

    What do you mean? Mouse interaction works fine for me.


    for reasons unknown to me, while native WoW nameplates permit mouse left/right-click on them for selection and interaction... Aloft nameplate frames have gone dead for me, as far as the mouse is concerned. this is under all circumstances, without regard for whether i am in combat or whatever. it could be something i have configured somehow (though actually enabling mouse interaction in Aloft, as a specific option, has no effect on this behavior). it could be synergy with another mod. i just don't know at this point. i have been looking at how Aloft believes it controls nameplate frame mouse interaction, and i expect i will need to trace it diagnostically (print out messages as the state of mouse interaction is controlled), and understand what user interface behavior i obtain relative to what Aloft believes it is doing. that will hopefully help me visualize how this is going wonky for me.

    I'm already using WoWInterface as my primary addon host, and now that they've got SVN repos, I'm using them for my development as well.


    i figured that is what i would be doing, assuming i got that far. i have not tried to use any of the sites as a mod author, but i have read forum posts from authors describing general difficulty of use at curse, and lack of response getting projects approved at WoWAce, and the relative ease of use and comparatively responsive support at WoWInterface. i also use the WoWInterface automatic updater, and find it a nice feature. WoWInterface will probably be what i try first.

    first i want to get deep enough into this that i can have some degree of confidence i will be adding value, before i try to set up a bunch of infrastructure.

    thanks for the comments, everything like this is very helpful.
    Posted in: General AddOns
  • To post a comment, please or register a new account.