The current combat log messages are very inconsistent, not every spell casts have a message of 'cast'.
Parser events are direct translations of the combat log messages, if some spells do not have a 'cast' message, then you don't receive 'cast' parser event from that spell.
e.g. when a priest casts Psychic Scream, you might not see a 'Priest casts Psychic Scream.' message, instead you only see 'Target is afflicted by Psychic Scream.'.
AFAIK there is no online document about which spells show exactly what combat log messages, the only way to know is to test it yourself.
UNIT_SPELL* events were added in 2.0 and could allow Parser to show this. Parser only cares about CHAT_MSG_SPELL_FAILED_LOCALPLAYER so it can only show the players interrupts.
Itd be nice to have some of the UNIT_SPELL* events added to Parser.
ParserLib has nothing to do with UNIT_SPELL events.
This is the same with several Ace files, and somebody on IRC suggested it could be a problem with the core parser libs. I'm susprised nobody has noticed.
If i want to test this with older files, should i use older ace2 files or just older sct/parrot files?
The original combat log for "[You] ++Hamstring" is "You are afflicted by Hamstring.", which does not have a caster name in it, so you can't show the caster name.
I want to state clear that why do we need to write a wiki talking about the spirit.
It's not to prove that Ace3 is "better" than Rock, or Ace2, or Dongle or whatever. It is there to clearly define the 'spirit' of Ace3, and explains the differences of spirits in each frameworks.
If you read my the wiki, my explanation, and you love the idea of such spirit, then feel free to head to jira.wowace.com and contribute on making Ace3 success on what it is trying to achieve.
If you disagree with a minimal overhead embedding framework, then simply stay away from Ace3 and use something which suits your need.
The best thing is, both sides have agreed that the non-core libraries should be made as framework-agnostic as possible, so hopefully end user won't end up using duplicated libraries.
For duplicated framework cores, most likely yes, but unless ALL your addon use one framework (using all wowace-based addons != one framework), or even if you have only one addon which does not use any framework, most likely it'll duplicate code to some degree, and costing you may be 5 extra KB of memory. CPU resource is not wasted as long as the addon/frameworks is optimized enough. So does the few extra kilobytes of memory matter? The Ace3 team doesn't think so.
So, instead of making an universal standard framework which can saves your memory when ALL your addons use the framework, Ace3 try to have better scalability. That is, you don't lose any efficiency when you only use 1 Ace3 addon, and yet you earn efficiency when you have a somewhat Ace3-based compilation.
Since the core libraries are made to do only one task and to do the task optimally, even when you use only 1 Ace3 addon, that addon itself will gain the benefit of optimized backbone.
So what is the spirit of Ace3? Taken quite literally the above says that "if you use an Ace3-based compilation, then the overhead of the libraries will be large". I'm sure that is not what you mean. However, I am curious to know how you will avoid the classic problem of decomposition: code duplication. I expect that you will run into this problem over and over again during the design of Ace3 if you are religious about each and every library being fully independent of each other. Perhaps you will even come to realize that the "right answer" is somewhere in between.
The 'spirit' has already been mentioned, and I agree that it's impossible to have no dependency without any sort of code duplication. So, the 'how' and the 'where in between' are what the team have always been discussing at jira.wowace.com
[EDIT] And the good thing is that everyone is free to submit their ideas to jira for discussing, even if you don't know anything about coding. If the idea is agreed as an essential feature, I'm sure someone in the team will pick the task up and implement it.
Quote from Bam »
The vast majority of Ace2 is completely independent on these library-loading features. Wether it is a good or bad idea to include it in a framework, I don't know. I tend to agree that it probably does not belong there. On the other hand, including it may have been an important part of why Ace2 became so successful as it undeniably did. But this issue sure isn't important enough that an entirely different framework is needed.
It's just a (tiny) example to show the opposite of philosophy, not trying to say the decision is absolutely right or wrong. We're discussing about the spirit here and it makes no sense to argue the examples one by one unless all you seek is a meaningless flame war.
Quote from Bam »
What "standard" are you referring to? Having standards is usually a good thing. I'm pretty sure many Ace2 users enjoy the common look and feel of Ace2 addons.
Standards are good, and some kind of standards will still exist in Ace3, such as the traditional OnInitialize, OnEnable, OnDisable in AceAddon-2.0.
But the team try to give the authors more freedom to 'not follow the standard'. You're free use only one of the libraries, such as AceDB-3.0 for your profiling DB, without using AceAddon-3.0 or any kind of core at all, you don't even need to create an addon object in order use it.
Quote from Bam »
Oh please! Get rid of the "elitist" attitude and stop calling users dumb. Users are never dumb. They simply do not have the interest in the technicalities and want to install and use addons with as little effort as possible. It is the job of the developer to ensure that this is possible.
I agree that not users are interested in the technical details. But as mentioned in the wiki, the Ace3 team thinks that it's up to the author/updater's responsibility to make sure the addon package can be installed without knowing the technical details.
Again, as mentioned in the wiki, Ace3 is designed to be a embedded framework, and is capable of disembedding, but Ace3 will not try to help author/user to automate the process of disembedding, since that can completely be done when the author/updater distribute the addon package correctly.
Quote from Bam »
Pretty much the same as above. A good framework/library makes it completely transparent how it works internally and only requires that the developer knows how to interact with it by reading API docs or similar. If a library requires more than that, it is in fact the developer of the library that is "dumb" and not the user of it.
Ace3 requires the developer to read the Blizzard API, it will not try to abstract the Blizzard API completely that developers don't even know how it works.
Mainly because it requires much more overhead in the core to make a completely idiot-proof abstract layer, and such level of overhead is against the spirit of Ace3, i.e. minimal overhead of embedding.
It's hard to give a solid example right now, but imagine that you need 10 efforts to create a library with only contains the core, and you need 10 more to make it idiot-proof. For developers who know what they're doing, those extra 10 is the unnecessary overhead for embedding.
It's clearly a trade-off for providing idiot-proof API and avoiding unnecessary overhead. I guess that'll be one of the differences between Ace3 and Rock, in which Ace3 will pick the 'minimize overhead' extremely, while Rock will sit between the extremes, somewhere more towards minimal overhead.
Quote from Bam »
Well, exactly how simple? Make it too simple and the value of the using the framework is reduced substantially.
That's up to the developers to judge, Ace3 provides functionality with minimal overhead, you use it if you like it. There's nothing much to be discussed here.
Quote from Bam »
"All libraries limited to their original purpose, no extra payload you might not want/use"
It's a trade-off. It always is. I just hope you will not be so focused on avoiding this "extra payload" that you forget that the purpose of a framework is to help developers write better code, write it faster, with fewer bugs, and with more features. Reinventing the wheel is a bad thing - even if you think you can build a slightly better wheel.
The Ace3 team wishes to provide a framework which help developers write better code, write it faster, with fewer bugs and more features, and with minimal overhead of embedding.
Ace2 failed at that objective, Dongle was very success on it, but Dongle was designed to be one bundled framework which has all those essential features included. Ace3 aims to step even more forward from Dongle, making a framework with extreme tiny overhead.
I personally don't see how it is reinventing the wheel in that sense, since Ace2 completely failed to be a framework with minimal overhead.
(btw, I try hard to not create further drama, but if you think Ace3 is reinventing the wheel, then you probably also think that Rock, LibParser-4.0, LibSharedMedia-2.0, LibBabble-3.0 etc are reinventing the wheel?)
Not even close to being good enough. In particular, where are the overall design goals? I hope you haven't started developing without having these written down and agreed upon.
afaik the teams does have some clear overall design goals on what Ace3 should look like, just that they suck and are lazy to write any documentation.
I agree overall design goals should be documented clearly before pushing people to jira.wowace.com.
AFAIK the difference is that AutoRack uses bag slot buttons, where AutoBar uses itemID buttons.
Since moving items via WoW API works in combat, AutoRack puts the next ready-to-use item in the designated bag slot, say a healthstone. When I consume the healthstone, the next ready-to-use item, say the health potion, is moved to the designated bag slot. That way AutoRack enables the pre-TBC feature of AutoBar, i.e. use the same hotkey to eat healthstone, then health pot.
When raiding, it's possible that in a long boss fight that I'll eat rank 0/1/2 healthstone, pvp healing pot, super healing pot, tempest keep healing pot, all in 1 combat duration. Having the addon manages what to eat was really the purpose of AutoBar preTBC, and it's still possible postTBC by using the AutoRack approach.
Currently I have to use AutoRack for pots/bandages and AutoBar for food/drink/anything else.
The settings aren't really that complex.
SimpleCombatLog is only a reformat of the default combat log, so whenever you want to see something, check what the default combat log looks like first,
e.g If the original combat log is : "Your Frost Bolt is reflected.",
that means:
1. this message had a skill named 'Frost Bolt', which the caster source was 'player', and it is reflected. You don't get the information of 'whom reflected the spell', or 'what skill was used to reflect the spell'.
2. If you want to show this message, you know you want to enable 'source=player'.
3. The tricky question is 'which type of message does this belongs to?', since there are so many variation of possible combat log messages, the current ParserLib-1.1 (backbone library of SimpleCombatLog) isn't doing a very good job categorizing the messages clearly (and Parser-3.0 too, since it's a direct clone of 1.1 on categorization part). You can try to find out by checking ParserLib's source code, but that isn't very practical, so if you really have a hard time figuring out, ask me (I prefer to ask in SCL page in wowinterface since it has email notification) and I'll check it up for you. For this very case, reflect messages belong to 'miss' with 'missType' = 'reflect'.
st0nedpenguin:
For reflected message since it's 'target' hits 'target', enabling either 'source=target' OR 'victim=target' should show the message,
I was saying that you cannot show ONLY message which was reflected back, because SCL doesn't support a AND operation between source and victim filter.
Tsurani:
1. For how much dmg you take and give, enable 'hit' messages with source=player and victim=player
2. For how much heals you do, enable 'heal' messages with source=player
3. For what you dispelled, the original combat logs are really two message for a 'dispel' action (IIRC):
"You casts Dispel Magic on Someone"
"Someone's Buff is removed"
So you must show both 'cast' with source=player, and 'dispel' with target='victim'.
Sorry to hijack, but is there any way to set SCL to show reflected damage caused by the Warrior spell reflection ability?
So far all I've managed to do is get it to show all spell damage on the target which is fine in 1v1 but spammy in group PVP.
You mean you want a frame which only shows reflected damages?
Reflected damages have the same source and target, but currently SimpleCombatLog only supports a OR filter between source and target, not AND.
So I don't think you can set a window to show 'source=player AND target=player'
May be I should just rename the mod ComplexCombatLog and add all the possible config combinations...
From the code it looks like "You dispel someone" and "Someone's buff is removed" are two messages, not one. And that is the case for SimpleCombatLog too.
0
Parser events are direct translations of the combat log messages, if some spells do not have a 'cast' message, then you don't receive 'cast' parser event from that spell.
e.g. when a priest casts Psychic Scream, you might not see a 'Priest casts Psychic Scream.' message, instead you only see 'Target is afflicted by Psychic Scream.'.
AFAIK there is no online document about which spells show exactly what combat log messages, the only way to know is to test it yourself.
0
ParserLib has nothing to do with UNIT_SPELL events.
0
Check http://www.wowace.com/forums/index.php?topic=9705.0
0
So hopefully it's not a problem of the core parser libs, go bug the authors for pet interrupt support.
0
Can you try SimpleCombatLog and see if you can get interrupts to show? If so then it's not the library's problem.
0
0
0
SUF does not modify the default unitframes, only the text.
Shared Media... may be, I don't use Shared Media though.
0
It's not to prove that Ace3 is "better" than Rock, or Ace2, or Dongle or whatever. It is there to clearly define the 'spirit' of Ace3, and explains the differences of spirits in each frameworks.
If you read my the wiki, my explanation, and you love the idea of such spirit, then feel free to head to jira.wowace.com and contribute on making Ace3 success on what it is trying to achieve.
If you disagree with a minimal overhead embedding framework, then simply stay away from Ace3 and use something which suits your need.
The best thing is, both sides have agreed that the non-core libraries should be made as framework-agnostic as possible, so hopefully end user won't end up using duplicated libraries.
For duplicated framework cores, most likely yes, but unless ALL your addon use one framework (using all wowace-based addons != one framework), or even if you have only one addon which does not use any framework, most likely it'll duplicate code to some degree, and costing you may be 5 extra KB of memory. CPU resource is not wasted as long as the addon/frameworks is optimized enough. So does the few extra kilobytes of memory matter? The Ace3 team doesn't think so.
So, instead of making an universal standard framework which can saves your memory when ALL your addons use the framework, Ace3 try to have better scalability. That is, you don't lose any efficiency when you only use 1 Ace3 addon, and yet you earn efficiency when you have a somewhat Ace3-based compilation.
Since the core libraries are made to do only one task and to do the task optimally, even when you use only 1 Ace3 addon, that addon itself will gain the benefit of optimized backbone.
0
The 'spirit' has already been mentioned, and I agree that it's impossible to have no dependency without any sort of code duplication. So, the 'how' and the 'where in between' are what the team have always been discussing at jira.wowace.com
[EDIT] And the good thing is that everyone is free to submit their ideas to jira for discussing, even if you don't know anything about coding. If the idea is agreed as an essential feature, I'm sure someone in the team will pick the task up and implement it.
It's just a (tiny) example to show the opposite of philosophy, not trying to say the decision is absolutely right or wrong. We're discussing about the spirit here and it makes no sense to argue the examples one by one unless all you seek is a meaningless flame war.
Standards are good, and some kind of standards will still exist in Ace3, such as the traditional OnInitialize, OnEnable, OnDisable in AceAddon-2.0.
But the team try to give the authors more freedom to 'not follow the standard'. You're free use only one of the libraries, such as AceDB-3.0 for your profiling DB, without using AceAddon-3.0 or any kind of core at all, you don't even need to create an addon object in order use it.
I agree that not users are interested in the technical details. But as mentioned in the wiki, the Ace3 team thinks that it's up to the author/updater's responsibility to make sure the addon package can be installed without knowing the technical details.
Again, as mentioned in the wiki, Ace3 is designed to be a embedded framework, and is capable of disembedding, but Ace3 will not try to help author/user to automate the process of disembedding, since that can completely be done when the author/updater distribute the addon package correctly.
Ace3 requires the developer to read the Blizzard API, it will not try to abstract the Blizzard API completely that developers don't even know how it works.
Mainly because it requires much more overhead in the core to make a completely idiot-proof abstract layer, and such level of overhead is against the spirit of Ace3, i.e. minimal overhead of embedding.
It's hard to give a solid example right now, but imagine that you need 10 efforts to create a library with only contains the core, and you need 10 more to make it idiot-proof. For developers who know what they're doing, those extra 10 is the unnecessary overhead for embedding.
It's clearly a trade-off for providing idiot-proof API and avoiding unnecessary overhead. I guess that'll be one of the differences between Ace3 and Rock, in which Ace3 will pick the 'minimize overhead' extremely, while Rock will sit between the extremes, somewhere more towards minimal overhead.
That's up to the developers to judge, Ace3 provides functionality with minimal overhead, you use it if you like it. There's nothing much to be discussed here.
The Ace3 team wishes to provide a framework which help developers write better code, write it faster, with fewer bugs and more features, and with minimal overhead of embedding.
Ace2 failed at that objective, Dongle was very success on it, but Dongle was designed to be one bundled framework which has all those essential features included. Ace3 aims to step even more forward from Dongle, making a framework with extreme tiny overhead.
I personally don't see how it is reinventing the wheel in that sense, since Ace2 completely failed to be a framework with minimal overhead.
(btw, I try hard to not create further drama, but if you think Ace3 is reinventing the wheel, then you probably also think that Rock, LibParser-4.0, LibSharedMedia-2.0, LibBabble-3.0 etc are reinventing the wheel?)
0
afaik the teams does have some clear overall design goals on what Ace3 should look like, just that they suck and are lazy to write any documentation.
I agree overall design goals should be documented clearly before pushing people to jira.wowace.com.
0
AutoRack by Gello (author of ItemRack, TrinketMenu) : http://www.wowinterface.com/downloads/info6394-AutoRack.html
AFAIK the difference is that AutoRack uses bag slot buttons, where AutoBar uses itemID buttons.
Since moving items via WoW API works in combat, AutoRack puts the next ready-to-use item in the designated bag slot, say a healthstone. When I consume the healthstone, the next ready-to-use item, say the health potion, is moved to the designated bag slot. That way AutoRack enables the pre-TBC feature of AutoBar, i.e. use the same hotkey to eat healthstone, then health pot.
When raiding, it's possible that in a long boss fight that I'll eat rank 0/1/2 healthstone, pvp healing pot, super healing pot, tempest keep healing pot, all in 1 combat duration. Having the addon manages what to eat was really the purpose of AutoBar preTBC, and it's still possible postTBC by using the AutoRack approach.
Currently I have to use AutoRack for pots/bandages and AutoBar for food/drink/anything else.
0
SimpleCombatLog is only a reformat of the default combat log, so whenever you want to see something, check what the default combat log looks like first,
e.g If the original combat log is : "Your Frost Bolt is reflected.",
that means:
1. this message had a skill named 'Frost Bolt', which the caster source was 'player', and it is reflected. You don't get the information of 'whom reflected the spell', or 'what skill was used to reflect the spell'.
2. If you want to show this message, you know you want to enable 'source=player'.
3. The tricky question is 'which type of message does this belongs to?', since there are so many variation of possible combat log messages, the current ParserLib-1.1 (backbone library of SimpleCombatLog) isn't doing a very good job categorizing the messages clearly (and Parser-3.0 too, since it's a direct clone of 1.1 on categorization part). You can try to find out by checking ParserLib's source code, but that isn't very practical, so if you really have a hard time figuring out, ask me (I prefer to ask in SCL page in wowinterface since it has email notification) and I'll check it up for you. For this very case, reflect messages belong to 'miss' with 'missType' = 'reflect'.
st0nedpenguin:
For reflected message since it's 'target' hits 'target', enabling either 'source=target' OR 'victim=target' should show the message,
I was saying that you cannot show ONLY message which was reflected back, because SCL doesn't support a AND operation between source and victim filter.
Tsurani:
1. For how much dmg you take and give, enable 'hit' messages with source=player and victim=player
2. For how much heals you do, enable 'heal' messages with source=player
3. For what you dispelled, the original combat logs are really two message for a 'dispel' action (IIRC):
"You casts Dispel Magic on Someone"
"Someone's Buff is removed"
So you must show both 'cast' with source=player, and 'dispel' with target='victim'.
0
You mean you want a frame which only shows reflected damages?
Reflected damages have the same source and target, but currently SimpleCombatLog only supports a OR filter between source and target, not AND.
So I don't think you can set a window to show 'source=player AND target=player'
May be I should just rename the mod ComplexCombatLog and add all the possible config combinations...
0
iirc in SCL the default should look like this:
[You] Dispel Magic [Someone]
[Someone] -- Buff