• 0

    posted a message on Reported (v0.3) Update 5-27-06 -- New, Simple non-Ace Addon
    :) How did you test this without annoying the GMs with useless spam?

    Steve
    Posted in: General Chat
  • 0

    posted a message on any way to see more than 20 topics per page?
    I've noticed a bit of a bug in the "show unread posts" page. If you have more than one page of posts you can miss some of them because it refreshes the list of unread posts when you go to the second page.

    For example, if you have 25 topics with unread posts and view 3 of them and then select page 2 you will only see 2 topics on the second page, not 5 as you would expect. This is because the other three are now on page 1 to replace the three topics you have read and so removed from the list of unread topics.

    This problem would be reduced if you increased the number of topics per page.

    Steve


    Posted in: General Chat
  • 0

    posted a message on oxygen theme ftw!


    You can also use this: http://www.wowace.com/forums/index.php?action=unread;all read what you like and click on the "mark as read" button at the top to mark the rest as read.

    Steve
    Posted in: General Chat
  • 0

    posted a message on oxygen theme ftw!
    Quote from speak »

    thanks for puttin in more themes :)


    Who's Smiley and why's he putting themes on our board? 8^)

    Steve

    P.S. That's the best smiley that I could come up with that wasn't replaced by a word
    Posted in: General Chat
  • 0

    posted a message on UI Changes - Patch 1.10
    Toggling autocast for pet actions requires input to work, like commanding your pet does.


    Well, that's just brought my Ace mods:non-Ace mods ratio up a bit in favour of Ace. I'm pretty sure that Smart Pet toggles the auto-cast flag to activate a growl / claw when it needs to.

    Steve
    Posted in: General Chat
  • 0

    posted a message on Ace'ing an assisting addon!
    Quote from "Jayblah" »
    In my opinion, the absolute best assist-helper addon is [b]Multi-Assist[/b]. [url]http://ui.worldofwar.net/ui.php?id=1057[/url]

    Unfortunately, this addon has a few problems:
    [list]Takes up a lot of memory.
    It is abandoned by its original author.[/list:u]

    Ace users have been clamoring for an assisting addon thats as useful as Multi-Assist. Please, one of you efficient codemasters, consider creating an addon similar to Multi-Assist, or Ace'ing Multi-Assist outright!


    I'm at work so I can't look at the description of Multi-Assist on worldofwar.net but have you tried [url=http://wowace.com/forums/viewtopic.php?t=235&highlight=quickassist]QuickAssist[/url]? It's what I use and it does everything I need.

    Steve
    List tags are malformed.
    Posted in: Addon Ideas
  • 0

    posted a message on Memory thing
    Quote from "Tuplad" »
    Hey boys & girls,

    A while ago, I had my memory set to 64, worked well, the memory thing, like, 5kb/s, was very low.
    Then I downloaded few other addons, and had to raise my memory, I raised it to 72, then my memory/s went to 150kb/s :\

    What should I do ?


    Disable the latest add-ons until your memory use goes back to the acceptable values and then re-enable them one at once until you find the culprit. Then you need to decide which is more important: the add-on or the memory.

    Steve
    Posted in: General Chat
  • 0

    posted a message on What Addons do YOU use?
    I use (excluding libraries):

    AceCount
    AcePlayerGrid
    ArcHUD

    BCUI - Tracking Menu
    BossPanel
    BP - Ammunition
    BP - Bags
    BP - Clock
    BP - Durability
    BP - Experience
    BP - Money
    BP - Performance
    BP - Spacing
    BP - Transparency
    Chat Scroll

    Custom
    FlexBar
    Friend Notes
    Golden Run
    Jeff's Pet Feeder
    Quick Assist
    Quick Target

    Smart Pet
    Target Tracker
    Visor


    Blue ones are Ace.

    Custom is a small addon which, at the moment, just handles the upper and lower textures. I'm planning on expanding it to provide assistance to get rid of FlexBar - the only thing I need it for is a range check on Auto Shot for my Hunter. Visor can do everything else I need already.

    AcePlayerGrid has been modified to have Player, Party 1, Party 2, Party 3, Party 4, Target and Target's Target along the top and the pets on the second row. The pet windows have been made smaller and transparent.

    Screenshot

    Steve
    Posted in: General Chat
  • 0

    posted a message on Request (or whereabouts): Chat to the RIGHT of chat screen.
    Quote from "Maahe" »
    Well, one more try before this gets lost for presumably all eternity.

    I asked this to author of the updated HitsMode (I hear there's an Ace version, too...damn, I will never be done with my UI will I :)), and his or her reply was;
    "Seems that it's currently not possible to align (or justify) text within chatwindows. You can still move your windows to either side of your action buttons though. Don't think I can find a workaround for the alignment stuff, but if I happen to trip over one I'll post it up."

    Taken from this thread. Seems I have found my new Holy Grail. Regardless, seemingly not possible one-two-three. I'd like to ask here though, does anyone know of said 'workaround'? Puh-lease let me know. :)


    A workaround would be to write a mod that monitors the chat and puts it to a list box rather than the chat window. You could make the listbox look like a chat window with right aligned text.

    Steve
    Posted in: Addon Ideas
  • 0

    posted a message on What Addons do YOU use?
    Quote from "Orione" »
    Meh, I tried. It doesn't work... I would ahve thought it was doable. For some reason you can hide the WorldFrame. I wouldn't reccomend doing that though. :P


    I've done that loads when playing with Visor and using the following line:
    /vz set gf=TRUE h=TRUE

    I usually call it from my chat history accidentally when I mean to get something else. For some reason
    /vz set h=FALSE
    doesn't fix it. :( I usually resort to resetting Visor and setting it all up again. A pain until I stopped just using the command line to set it up.

    Quote from "Sariash" »
    Top and Right have to be negative, not sure why... I guess some kind of blizzard bug... aeh logic


    top has to be negative because Blizzard decided that zero was at the top and negative numbers moved down. An odd decision IMO. I guess that right has to be negative because the BOTTOMRIGHT corner of WorldFrame is probably anchored to the BOTTOMRIGHT corner of UIParent and you want it to be X pixels to the left of it.

    Steve
    Posted in: General Chat
  • 0

    posted a message on Experimental: AceOptions
    Quote from "Kaelten" »
    Well it looks like we might be able to get something working here.

    We could possibly have the regular chat method get called with a true appended to the argument list.

    So to some that up we could have it work as follows for say checkboxes

    If option.set then option.set() else option.method(true) end

    Just an idea. Having the true appended there may potentially cause a bug on a chat option that is poorly setup.


    That's not what I was suggesting - I was suggesting that we look for the set function and if it is there then call that. If there is no set function call the method function and just have any output it would generate display as normal. Authors that do not like the chat output implement set and the rest do not. The silent flag I was suggesting was to be implemented in a function that both "method" and "set" call - "set" would call it with true for silent and method would call it with false to display the output - all internal to the addon and nothing to do with AceOptions.

    A bit like this:

    {
        option = "setcut",
        set = function (param) return self:doSetCut(param, true) end,
        method="SetCut"
    }
    
    function TestAddon:SetCut(param)
        self:doSetCut(param, false)
    end
    
    function TestAddon:doSetCut(param, silent)
        local rtrn = self:SetOpt({"options"}, "cut", param)
    
        if silent == false then
            ace:print("Scale changed")
        end
    
        return rtrn
    end
    


    Quote from "Kaelten" »
    Other things need to be taken into consideration as well. Nested options and arguments and handlers come to mind. It is a fairly undocumented feature I think but you can set handler = <class> inside of your chat definition and all options that are lower than that in the tree will call the methods using handler:method(). One thing that we should probably do is pass the handler into the get methods so they can use 'self' inside of them.


    I already pass the addon to the set and get functions in my prototype so that they can use 'self'. I'll have to look into the handler thing.

    Quote from "Kaelten" »
    The nested options I bring up because some addons can go several layers. For example KC_Items has an option "/kci broker autofillmode mixed" there is also "/kci broker autofillmode smart" and a few others.

    One way we might want to handle this is to have an ACEC_CATEGORY global to let the addon know to treat that command as just a header type. In my example above broker would be a category with several commands listed under it.

    Categories could be listed in the main box there slightly indented under the main addon to allow people to quickly select that particular section. However, we need to keep in mind that in theory you can have an infinite amount of sub categories, as there is no hard coded limit built into the ace chat system.


    I see what you are saying here but are autofillmode mixed and smart mutually exclusive? If they were then, visually, I think that it would be better to have one autofillmode setting which has a drop down list to select the desired one.

    I think we just remove this complexity completely by flattening all the options into one layer. Perhaps have two layers to allow for categories and items within the categories. To try to allow for an infinite amount of sub categories is not really workable due to limited screen space.

    Quote from "Kaelten" »
    As far as the name goes, my suggest is if a long name appears use it, if not use the option name the addon uses.


    Yeah, I'll do that then - a good solution.

    Quote from "Kaelten" »
    Now for addons that do not support this new architecture I would suggest that those get referred back to an ace commander type approach so that when you select on that addon's name in the listbox then you could still use it even if its not been updated.


    That should be easy to do by lifting the code from AceCommander.

    Quote from "Kaelten" »
    I'm not sure, if just checking for a set method would be good enough, or if we should actually put in an indicator in the chat definition saying that it has been setup for the new system.


    I think that it would work to just rely on the presence of the set method but it may be quicker to process if we have a quick to access variable to check. I'm thinking of visor which is very complex and has a lot of options that we would have to trawl through just to find out that it doesn't support AceOptions. If we get a lot of complex addons that don't support AceOptions it could cause problems.

    Quote from "Kaelten" »
    In addition, did you make the prototype using AceGUI?


    Yes I did. I liked the look and feel of AceCommander and it used AceGUI so I did too.

    Steve
    Posted in: Addon Ideas
  • 0

    posted a message on Experimental: AceOptions
    Quote from "Rowne" »
    There's something I don't understand about this approach so consider this an idea. Why are we actually making a get-set call at all? The coder will already have handled all this so it seems like it's becoming a double-standard (don't count me out as a naysayer just yet, I'm going somewhere with this).


    We need a "get" call so that the GUI can display the current options. We don't need a "set" call as we can just use the chat command method. I just think that it would be better to have a seperate "set" method for the reasons mentioned in my previous post.

    Quote from "Rowne" »
    option: This would be the option as shown in the GUI as Steve mentioned. Basically it would str-upper the first letter and leave it at that.


    I would prefer a seperate value for this as the "option" field is generally designed to be an easy to remember and type value and is often only useful as a reminder as to what the option does. Also, it is often two words joined together. For example, TargetTracker has the "showguild" option. If we capitalise the first letter we would get "Showguild" which doesn't look as good as "Show guild tag".

    Quote from "Rowne" »
    desc: This would be the tooltip description you'd get when you moused-over the option, thus keeping congruency with the slash-command system.


    I agree with this - we should use the current "desc" value from the chat command system.

    Quote from "Rowne" »
    method: Here's where it starts to get a little complicated, this is what the final value is passed to once the GUI has handled the command, much as if the player had typed it.

    gmethod: This is the GUI method that will be used, basically it takes the value the player gives from the GUI and feeds that value through to method.


    I don't get the difference between "method" and "gmethod". In your example above you specify "Slider" as the "gmethod" - does this mean that this is an instruction to the GUI to use a slider instead of, say, an edit box?

    Quote from "Rowne" »
    value: This would be the basic resources the gmethod would need to work with, what it is is min, max and step. So basically the GUI now has everything it needs to render the option and process the result through to method.

    Value could also be a function if you want it to be alterable on the fly. As for gmethod, this would be like AceGUI, it would call a global menu function which would handle the rendering.


    This sounds like a control specific thing. Your example gives the info required to setup a slider
    Quote from "Rowne" »
    --- A little more on my ideas ... ---

    Okay, I've been thinking about how this would build and it's really quite simple, basically it would dynamically build a list of 'pages' much like AceCommander works by parsing the command tree, it wouldn't even need to be in the Ace core for that reason alone, it could be its own Addon.

    What happens is that once the AceOptions UI is called for, it'll parse the tree of every Addon and first grab the name and the desc of the Addon itself, the name it will use for the title of a page, the desc it will use for a little text at the top for decoration, thus mimicking the way the chat-command works.


    This is almost what the experimental version does now. It parses the list of addons and adds their category to a drop down list. When you choose a category it adds the list of addons in the category to another list. When you select an addon it parses the settings array (to be changed to be the chat options array later) and adds the options to the settings group as seen above. It doesn't do anything with the addon's description but I think that it's a good idea so I'll add that in too.

    Quote from "Rowne" »
    Perhaps the idea of having a function build in the current value is a bit too complicated and you'll want a second value for that, say something like ...

    value = "1-10-0.5",
    status = self:Get("scale")


    I do prefer to have the current value be seperate from the range stuff because not all controls require a range.

    Steve
    Posted in: Addon Ideas
  • 0

    posted a message on Experimental: AceOptions
    Quote from "Kaelten" »
    I'm not sure i see the issue with the chat output by calling the default method. At least that gives you a confirmation that things really did change.


    The GUI would give the feedback that things really did change. The way that I have it above is that the set function returns the new value and the GUI displays that value. If you're not going to believe the GUI then why would you beleive the chat window. The real test as to if things changed would be to try the new setting.

    Quote from "Kaelten" »
    Plus on things like setcut I have error checking code and formating code. I'd rather not have that code in two places.


    You don't need it in two places - you can have it all in the "set" function that AceOptions would use and your normal chat command could call the "set" function and then report the result to the chat window. If the reporting is integral to the setting then you have a bit more of a problem but that could be solved by having a function that has a "silent" parameter which is called with "silent" as FALSE for the chat command and "silent" as TRUE for the "set" function.

    I know it seems like I'm really pressing for this feature but I wouldn't be too bothered if we did decide to use the chat command method - I just think that it would be better to not have the chat command spam when the GUI is already displaying the change made.

    Maybe we could have the "set" function be optional and if it doesn't exist call the chat command method instead?

    Steve
    Posted in: Addon Ideas
  • 0

    posted a message on Experimental: AceOptions
    Quote from "Kaelten" »
    If you want to try to make this part of the Ace community projects I'm willing to work with you to setup a standard that will work with all ace addons.


    I really would like to do this as I don't think the project will work without this standard. I think that it would end up only being supported by a small number of addons and would then fizzle out.

    Quote from "Kaelten" »
    However I don't see the point of creating a second array when we could just integrate it into the chat command array.


    That was me just experimenting with the idea rather than actually coming up with a good implementation. It should be integrated with the normal chat command array as some of the data would be duplicated otherwise. I'll probably play around with this idea tomorrow night.

    I don't think that we should use the option to double as the option text because they are usually shortened forms of what they mean. I would prefer the option text to be a short sentence and the tooltip to be more descriptive. For example on my screen shot above the options are: mouseover, keeppositions, showguild, showhealth etc. I think it would look much more professional if we had slightly longer names that could include spaces etc to make it easier on the eye.

    I would also prefer a seperate set method than the normal command method because the command method usually reports its output to the chat window resulting in unnecessary spam which is just reporting what you see on the screen. The only difference would be that it would change the relevant option silently - it could be called by the main method which would then do the reporting for the chat command.

    So taking your example:
    { 
       option = "setcut", 
       desc   = "Sets cut percentage used to adjust smart mode's value", 
       method = "SetCut" 
    }, 


    would become
    { 
       option = "setcut",
       desc   = "Sets cut percentage used to adjust smart mode's value", 
       method = "SetCut",
       name   = "Cut percentage",
       get    = function () return KC_Items.broker:GetOpt({"options"}, "cut") end,
       set    = function () return KC_Items.broker:SetOpt({"options"}, "cut") end,
       type   = ACE_PERCENTAGE,
    }, 


    Steve
    Posted in: Addon Ideas
  • 0

    posted a message on Experimental: AceOptions
    Quote from "Kaelten" »
    One thing you might want to consider is to try to do this using the same array as the chat options.


    The chat options array cannot be used without modification because there is no way to tell the difference between a command to execute (e.g. /lb eat) and a setting to change. I agree that it would be better if we could add some new variables to the chat options array to flag certain items as settings and provide the functions to change them.

    Steve
    Posted in: Addon Ideas
  • To post a comment, please or register a new account.