• 0

    posted a message on Pitbull Background Alpha
    This is being worked on. I added code to allow addons that use FakeStatusBar (which is like Blizzard's, only without a significant amount of suckage) to set alpha colors.
    Posted in: Unit Frames
  • 0

    posted a message on Are DogTags too difficult? Help me make it better
    Pasta, that's not what I mean, I mean I don't want to have lists be a vital part of DogTag, like cons are with LISP.
    Posted in: Unit Frames
  • 0

    posted a message on Are DogTags too difficult? Help me make it better
    Pusikas, it could easily be done with
    [if Class:In("Priest", "Mage", "Warlock") then "Squishy"]

    I don't really want to add comprehensive list manipulation to DogTag.

    Dragon, DogTags are compiled into separate lua functions, interpreted only once, not multiple times. Also, those lua functions are compiled to lua bytecode, which is the best we can do.
    Posted in: Unit Frames
  • 0

    posted a message on Are DogTags too difficult? Help me make it better
    Quote from Pastamancer »

    The lua/icon-style if then else is reasonably sane except that you'll need an 'end' of some sort. I still think you're making things more complicated than they need to be by not treating dogtag like a functional language.


    Actually, seeing as DogTag doesn't have more than one statement per bracketed sequence, end is never required, even in complex if-then systems.
    Posted in: Unit Frames
  • 0

    posted a message on Are DogTags too difficult? Help me make it better
    My current thought process has led me to believe that the following idea is the sanest of what I've heard (note, I'm fully willing to be proved otherwise):

    If syntax:
    [if Condition then Result]

    If-else syntax:
    [if Condition then Result else Other]

    Separate and from if
    [Alpha and Bravo], [if Alpha and Bravo then Charlie else Delta]

    I think that separation will clear up a lot of issues, since instead of [Alpha ? Bravo ? Charlie ! Delta], you get the more understandable syntax above.

    There would also be or as well as and, along with all your favorite comparators such as =, <, >, etc.

    I'm also going over in my mind to have lower levels of bracketing use different shapes, e.g.

    [if Alpha and (Bravo or {Charlie and [Delta or Echo]}) then Something else "Howdy"]
    or perhaps only [] on the outside and () on the inside:
    [if Alpha and (Bravo or (Charlie and (Delta or Echo))) then Something else "Howdy"]
    or perhaps [] everywhere
    [if Alpha and [Bravo or [Charlie and [Delta or Echo]]] then Something else "Howdy"]
    or some other symbols, i.e. we don't need to keep [].

    Separately, with regards to modifiers being postfix (as it is now) or prefix (as pastamancer has suggested), frankly I don't see any reason why it couldn't function as both. [Green("Hello")] could be just as supported as ["Hello":Green], and up to the user as to what will make more sense for them.
    Posted in: Unit Frames
  • 0

    posted a message on Are DogTags too difficult? Help me make it better
    Hoern, that actually already exists with [PercentHP < 10 ? Text(Die Scum) ! Text(Just a flesh wound)]. Uses ! instead of : since : is used for piping.

    The main issue that I see is that simple if-then and if-then-else statements are necessary, and currently handled by the [Alpha ? Bravo] and [Alpha ? Bravo ! Charlie] syntax, but that is complex and unintuitive for some people. I just don't know how to make it better and turning it into Lisp doesn't seem like the best solution to make things easier for users.

    I could have something like [If(Alpha, Bravo)] or [If(Alpha, Bravo, Charlie)], but I don't think that that necessarily provides a better landscape.
    Posted in: Unit Frames
  • 0

    posted a message on Are DogTags too difficult? Help me make it better
    Going back to pastamancer's post about Lisp, I think that DogTag really only has two large syntactical ideas behind it.

    First is piping, as some may know from bash. echo 'alpha'|sed 's/p/s/' will pipe the results of echo 'alpha' into sed 's/p/s/'.
    Much in the same way [CurHP:Green] pipes the results of CurHP into Green.

    Second is basic logic statements, if something then do something else do another end, which DogTag has done with [Alpha ? Bravo ! Charlie]

    There's not really anything beyond this, there's no list manipulation, no iteration.
    Posted in: Unit Frames
  • 0

    posted a message on Are DogTags too difficult? Help me make it better
    I am definitely thinking about having juxtaposition imply concatenation, e.g. [CurHP "/" MaxHP] => "7433/10200"

    CSS has concatenation by juxtaposition, and it seems like it could simplify things for users quite a bit.
    Posted in: Unit Frames
  • 0

    posted a message on Are DogTags too difficult? Help me make it better
    Quote from Phanx »

    1. Make it possible to do things like [IsPlayer ? Level Class ! Classification CreatureType].


    Instead of [IsPlayer ? Level Class ! Classification CreatureType], my thought was for it to be something like [IsPlayer ? Level .. " " .. Class ! Classification .. " " .. CreatureType] (Note: the concatenation operator could change)
    Posted in: Unit Frames
  • 0

    posted a message on Chinchilla - Minimap addon of awesomeness.
    make feature requests at http://jira.wowace.com/browse/CHIN otherwise they might not happen.
    Posted in: Map/Minimap AddOns
  • 0

    posted a message on Chinchilla - Minimap addon of awesomeness.
    Chinchilla:AddTrackingDotStyle("My Blip", L["My Blip"], [[Interface\AddOns\HunterZBlip\MyBlip]])


    Just put that in a lua file, make a toc file, and make the texture.
    Posted in: Map/Minimap AddOns
  • 0

    posted a message on Are DogTags too difficult? Help me make it better
    Another thing I was thinking about, possibly making tags more verbose, e.g. instead of [CurHP], it might be [CurrentHealth] or even [Current Health] or just [Health], with others being [MaximumHealth] or something like that.

    I also think there should be a consistency to the naming of tags, as some are [HasSomething] or [IsSomething] where others are just [Something], e.g. [Resting] instead of [IsResting], but there's [HasSoulstone] and the like, so that should be made consistent.

    Again, I'm just throwing ideas out there and I want people to disagree with me so that the best solution can be achieved.
    Posted in: Unit Frames
  • 0

    posted a message on Are DogTags too difficult? Help me make it better
    One thing I also want to do, more on the tag-oriented side of it, is to make the tags and modifiers more standardized.

    e.g.
    [Leader] => "Leader"
    [MasterLooter] => "True"

    I think it'd be nicer if everything worked with each other instead of having inconsistencies.
    Posted in: Unit Frames
  • 0

    posted a message on Are DogTags too difficult? Help me make it better
    I'm also thinking it could be better to make the ternary syntax more "english" instead of being a bunch of symbols.

    [Alpha ? Bravo] could become [Alpha and Bravo]
    [Alpha ? Bravo ! Charlie] could become [Alpha and Bravo else Charlie]
    [Alpha | Bravo] could become [Alpha or Bravo]

    I'm not sure whether this is an improvement or not.
    Posted in: Unit Frames
  • 0

    posted a message on Are DogTags too difficult? Help me make it better
    My ideas thus far have been as such:

    Currently, arguments of tags are seen as literal, but internal expressions can be done by using brackets with the syntax [Alpha([Bravo])].

    I kind of want to remove the internal bracket and instead have [Alpha(Bravo)]. To do a literal string in that case, you would do [Alpha("Charlie")] or [Alpha('Charlie')].

    I could also eliminate the Text tag, as currently you use [Text(Hello)], but that could become [Text("Hello")] or just as easily, ["Hello"]

    With this new system, I could also add support for multiple arguments, e.g. [Alpha(Bravo, Charlie)] or [Alpha("Bravo", "Charlie")] or something along those lines.
    Posted in: Unit Frames
  • To post a comment, please or register a new account.