Hey all, DogTags can be difficult at times, this I know.
I am planning out LibDogTag-3.0 and would like some user feedback on DogTag and tags in general.
If anyone's willing to provide some good feedback about what they think is bad in DogTag now or knows what could be improved or added or taken away, I'm willing to hear it.
Note that LibDogTag-3.0 does not need to be backwards compatible, so don't try to stay inside that confining box.
I'm looking for more general syntax suggestions rather than necessarily specific tags people want.
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.
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.
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.
This is more confusing to me.
Replacing ?,!,| with and, else, or would make it 100x easier for the average joe user.
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.
That does make it more "english", but I see a few drawbacks: One, the "and/else" combination doesn't make sense from that perspective - [Alpha and Bravo or Charlie] would at least be consistent grammar-wise, but still isn't intuitive as an "if-then-else" construct for most users who aren't programmers. A second issue is that of tag length - with people creating more and more complex custom tags, they are becoming somewhat cumbersome to work with already; adding length by turning a single "?" or "|" character into an entire english word makes that problem worse. A third, more subtle issue is that visual differentiation between tags and syntax operators becomes slightly blurred, potentially making it trickier to work on tags (since syntax highlighting is not available).
Now that I think of it, the second issue could be somewhat alleviated if you allowed multi-line editboxes for DogTag. That does mean you'd have to come up with a preferred whitespace style for multi-line tag editing, though... :)
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.
Lua code in it self isn't to hard to read, if you stick to the basics:
[hp]
[if not atmaxhp then hp end]
[if atmaxhp then name else maxhp - hp end]
[if not combat and elite then text("Tread carefully!") end]
as for implementation, you can parse the string every time it has been changed, and have a local variable scope ready when it's time for update, and just eval the tag :)
Even if you haven't done any programing, you are able to understand is expected to do.
Ellipsis: Syntax highlighting is more the individual implementation, it's not impossible, quite the opposite :) Perhaps someone could make a DogTag editor, with drag and drop boxes, like lego programing ;)
Ellipsis: Syntax highlighting is more the individual implementation, it's not impossible, quite the opposite :) Perhaps someone could make a DogTag editor, with drag and drop boxes, like lego programing ;)
I didn't mean that it's *impossible*, just that it shouldn't be absolutely required to edit tags - with various addons using DogTag, each using their own configuration methods, you can't guarantee it will be available. Additionally, it's not exactly trivial to implement syntax coloring in WoW's editboxes, and if you're not careful you can crash the game - so it would be a significant amount of work to add, even just to RockConfig.
Slightly off-topic: your drag-n-drop suggestion instantly brought to mind traumatic memories of using the Lego Mindstorms IDE...
1. Make it possible to do things like [IsPlayer ? Level Class ! Classification CreatureType].
Currently this must be done in one of two ways:
- with duplicate sequences like [IsPlayer ? Level ! Classification] [IsPlayer ? Class ! CreatureType, which becomes quite messy if you don't want equal numbers of tags for each condition.
- or with Append modifiers like [IsPlayer ? Level:Append( [Class]) ! Classification:Append( [CreatureType])], which is easier to read in simple sequences (i.e. in this example you can easily see what will be shown for players, since Level and Class are together) but gets very ugly with tons of Appends for inequal numbers of tags per condition. Additionally I've actually managed to break the current version of DogTag with especially complex sequences using Append, and find that duplicate [A ? ... ! ...] and [~A ? ...] work better. While this is technically a bug, it really illustrates the limitation of the current version when it comes to complex sequences.
Something like what I suggested for this would be shorter, easier to read, and better able to handle complex sequences. Inner brackets would only be required for nested things like [IsPlayer ? [IsFriend ? Level:Green ! Level:Red] Class ! Classification CreatureType]. Spaces inside sequences would be ignored, and literal spaces would be inserted with Text(" ") or a Space alias.
2. Quotes around literal text = win. Currently things like [Classification = Text(Non-combat Pet)] require fighting with the code beautifier to get right, because it keeps trying to change it to Text(Non - combat Pet) because it can't tell the difference between literal text and math operations.
3. I'd argue against turning ? ! | characters into "and" "else" "or" words. Like someone already pointed out, the English words wouldn't necessarily be more intuitive to a non-programmer, would be harder to pick out from actual tags when editing a sequence, and would greatly increase the length of already-unwieldy complex sequences.
4. I don't think CurHP and MaxHP need to be more verbose. If anything, I'd vote for shortening longer tags. Complex sequences are already long enough, and pretty much everyone who's gotten past about level 2 knows that HP means Health.
5. I think Text("Some text here") is fine, and would look cleaner in a sequence like the one I posted above than just "Some text here", especially if you wanted to apply modifiers to the text string.
6. I agree with the tag naming consistency thing. Tags that return only true/false should be IsSomething or HasSomething, whereas tags that return a number or string should just be Something.
I've had trouble with DogTags from time to time, and I just want to say that the number one thing that would make them easier to use for me would be MORE EXAMPLES. There aren't nearly enough in the wiki entries, and I find the logical operators very counter-intuitive; I wouldn't know how to use them if not for having looked at other people's tags.
The wiki says this:
* The ? as used by DogTag serves as a boolean AND.
* The : as used by DogTag serves as a boolean OR.
* The ! as used by DogTag serves as an else.
So why does [IsPlayer?Name:ClassColor] translate to "If it is a player, print its name in the class colour"? I do not understand how an AND can follow a condition, or why an OR links a modifier to a tag.
When fiddle around with DogTags it is mostly the edit-UI for the tags which is hindering fast and effective tweaking. Most of the times it is more useful to create or modify the tags outside of the game in a more or less good editor. Although this is not something that the DogTag Lib will fix it is what is making the handling of DogTags frustrating from time to time for me.
I've had trouble with DogTags from time to time, and I just want to say that the number one thing that would make them easier to use for me would be MORE EXAMPLES. There aren't nearly enough in the wiki entries, and I find the logical operators very counter-intuitive; I wouldn't know how to use them if not for having looked at other people's tags.
Umm...ever looked at the in-game documentation (/dog)? Is there anything that you think could be improved there?
PS@Phanx: great points/suggestions all around. My babies, will you have them?
I think the most complicated thing about DogTag is to manage all those brackets :) Because the 'Text()' is needed to display more complex things my DogTags are wrapped in LOTS of them.
* The ? as used by DogTag serves as a boolean AND.
* The : as used by DogTag serves as a boolean OR.
* The ! as used by DogTag serves as an else.
So why does [IsPlayer?Name:ClassColor] translate to "If it is a player, print its name in the class colour"? I do not understand how an AND can follow a condition, or why an OR links a modifier to a tag.
If it helps I've pretty much ignored the Wiki's description of the operators. I stick to how I read the tags, like you did above. IF player then print name in class color etc... The : character is confusing in it's own at times since it's considered a boolean OR and it's to signify a modifier to an existing tag, like ClassColor is to Name.
If Phanx's suggestion number 1 holds up and I sure hope it does you should be able to have your code like this depending on how modifiers and strings work out:
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)
I think concatenation would go the other way on the scale of easy to understand - hard to understand... But maybe that's just me. I look at that and think "huh?"
Slightly off-topic: your drag-n-drop suggestion instantly brought to mind traumatic memories of using the Lego Mindstorms IDE...
Ugh... same here. I had a project last year where everyday for a month or two three other lads and I where we had to make a lego robot follow a line and go around an obstacle. Seems easy? Try using the lego programming...
We could have figured it out in a week or two if we learned basic programming. The blocks just confused the thing more and we ended up with a failure of a robot in the competition XD.
Anyway that was *very* off-topic. Basically what I am trying to say is stay away from that type of programming altogether.
I find DogTag's syntax to be awkward at best. Trying to decipher any complicated DogTag string gives me a headache. I'll throw my two cents in and suggest that you adopt a more regular syntax.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI am planning out LibDogTag-3.0 and would like some user feedback on DogTag and tags in general.
If anyone's willing to provide some good feedback about what they think is bad in DogTag now or knows what could be improved or added or taken away, I'm willing to hear it.
Note that LibDogTag-3.0 does not need to be backwards compatible, so don't try to stay inside that confining box.
I'm looking for more general syntax suggestions rather than necessarily specific tags people want.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumCurrently, 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.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium[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.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThis is more confusing to me.
Replacing ?,!,| with and, else, or would make it 100x easier for the average joe user.
-
View User Profile
-
View Posts
-
Send Message
Curse Premiume.g.
[Leader] => "Leader"
[MasterLooter] => "True"
I think it'd be nicer if everything worked with each other instead of having inconsistencies.
That does make it more "english", but I see a few drawbacks: One, the "and/else" combination doesn't make sense from that perspective - [Alpha and Bravo or Charlie] would at least be consistent grammar-wise, but still isn't intuitive as an "if-then-else" construct for most users who aren't programmers. A second issue is that of tag length - with people creating more and more complex custom tags, they are becoming somewhat cumbersome to work with already; adding length by turning a single "?" or "|" character into an entire english word makes that problem worse. A third, more subtle issue is that visual differentiation between tags and syntax operators becomes slightly blurred, potentially making it trickier to work on tags (since syntax highlighting is not available).
Now that I think of it, the second issue could be somewhat alleviated if you allowed multi-line editboxes for DogTag. That does mean you'd have to come up with a preferred whitespace style for multi-line tag editing, though... :)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI 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.
[hp] [if not atmaxhp then hp end] [if atmaxhp then name else maxhp - hp end] [if not combat and elite then text("Tread carefully!") end]as for implementation, you can parse the string every time it has been changed, and have a local variable scope ready when it's time for update, and just eval the tag :)
Even if you haven't done any programing, you are able to understand is expected to do.
Ellipsis: Syntax highlighting is more the individual implementation, it's not impossible, quite the opposite :) Perhaps someone could make a DogTag editor, with drag and drop boxes, like lego programing ;)
I didn't mean that it's *impossible*, just that it shouldn't be absolutely required to edit tags - with various addons using DogTag, each using their own configuration methods, you can't guarantee it will be available. Additionally, it's not exactly trivial to implement syntax coloring in WoW's editboxes, and if you're not careful you can crash the game - so it would be a significant amount of work to add, even just to RockConfig.
Slightly off-topic: your drag-n-drop suggestion instantly brought to mind traumatic memories of using the Lego Mindstorms IDE...
Currently this must be done in one of two ways:
- with duplicate sequences like [IsPlayer ? Level ! Classification] [IsPlayer ? Class ! CreatureType, which becomes quite messy if you don't want equal numbers of tags for each condition.
- or with Append modifiers like [IsPlayer ? Level:Append( [Class]) ! Classification:Append( [CreatureType])], which is easier to read in simple sequences (i.e. in this example you can easily see what will be shown for players, since Level and Class are together) but gets very ugly with tons of Appends for inequal numbers of tags per condition. Additionally I've actually managed to break the current version of DogTag with especially complex sequences using Append, and find that duplicate [A ? ... ! ...] and [~A ? ...] work better. While this is technically a bug, it really illustrates the limitation of the current version when it comes to complex sequences.
Something like what I suggested for this would be shorter, easier to read, and better able to handle complex sequences. Inner brackets would only be required for nested things like [IsPlayer ? [IsFriend ? Level:Green ! Level:Red] Class ! Classification CreatureType]. Spaces inside sequences would be ignored, and literal spaces would be inserted with Text(" ") or a Space alias.
2. Quotes around literal text = win. Currently things like [Classification = Text(Non-combat Pet)] require fighting with the code beautifier to get right, because it keeps trying to change it to Text(Non - combat Pet) because it can't tell the difference between literal text and math operations.
3. I'd argue against turning ? ! | characters into "and" "else" "or" words. Like someone already pointed out, the English words wouldn't necessarily be more intuitive to a non-programmer, would be harder to pick out from actual tags when editing a sequence, and would greatly increase the length of already-unwieldy complex sequences.
4. I don't think CurHP and MaxHP need to be more verbose. If anything, I'd vote for shortening longer tags. Complex sequences are already long enough, and pretty much everyone who's gotten past about level 2 knows that HP means Health.
5. I think Text("Some text here") is fine, and would look cleaner in a sequence like the one I posted above than just "Some text here", especially if you wanted to apply modifiers to the text string.
6. I agree with the tag naming consistency thing. Tags that return only true/false should be IsSomething or HasSomething, whereas tags that return a number or string should just be Something.
The wiki says this:
* The ? as used by DogTag serves as a boolean AND.
* The : as used by DogTag serves as a boolean OR.
* The ! as used by DogTag serves as an else.
So why does [IsPlayer?Name:ClassColor] translate to "If it is a player, print its name in the class colour"? I do not understand how an AND can follow a condition, or why an OR links a modifier to a tag.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNot sure how grammatically correct this would be, but as a programmer I would read this as
IsPlayer
? acting as an if
Name (text to be modified) modified by ( : ) ClassColor
Not sure how much that helps, or just confuses you more, shrug, hehe.
Edit: to be clearer
Basically you start with the tag, what you want it to say:
Name
then ask yourself, do I want to change how this looks? (add :Classcolor)
Then Do I only want this to show up if something? add IfPlayer?
Sorry for offtopic :)
Umm...ever looked at the in-game documentation (/dog)? Is there anything that you think could be improved there?
PS@Phanx: great points/suggestions all around. My babies, will you have them?
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumthank you for the open survey!
I would like to get rid of something which is - in my opinion - redundant.
I try to explain it with an example
at the moment:
i would love to have it working this way:
I think the most complicated thing about DogTag is to manage all those brackets :) Because the 'Text()' is needed to display more complex things my DogTags are wrapped in LOTS of them.
Would that be possible?
Best regards
X-buZZ
If it helps I've pretty much ignored the Wiki's description of the operators. I stick to how I read the tags, like you did above. IF player then print name in class color etc... The : character is confusing in it's own at times since it's considered a boolean OR and it's to signify a modifier to an existing tag, like ClassColor is to Name.
If Phanx's suggestion number 1 holds up and I sure hope it does you should be able to have your code like this depending on how modifiers and strings work out:
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumInstead 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)
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumUgh... same here. I had a project last year where everyday for a month or two three other lads and I where we had to make a lego robot follow a line and go around an obstacle. Seems easy? Try using the lego programming...
We could have figured it out in a week or two if we learned basic programming. The blocks just confused the thing more and we ended up with a failure of a robot in the competition XD.
Anyway that was *very* off-topic. Basically what I am trying to say is stay away from that type of programming altogether.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWith a LISPy syntax would become: (with '[' ']' as the top level parens to make it easier to parse out each code chunk)
Or if you allow newlines:
[if (not (HasNoMP)) (concat (Short (CurMP)) (PowerColor "/") (Short (MaxMP))))]