|
Originally Posted by Gello
I believe Tem was working on a project like this. Maybe she'll have some input. But it was months ago so maybe it's been set aside for a bit. It really is a huge project.
The documentation would be invaluable to a lot of people so that in itself is worth doing, even if the library isn't created.
The library would be useful but I think less as a common parsing point than you may expect:
1. Most mods that watch the combat log only register for a handful of events. Only a few register for almost all of them.
2. string.find is fast. While filing down through a bunch of filters takes time, it's an easy trap to believe that if two mods do the same string.find then it's a monumental waste. When one mod only registers for a few events, it's not, really. Performance is in no way related to perception. The CPU doesn't ask how a user feels when it processes a command. Different things take different amounts of time to process and some things are fast enough to be considered instant. Test and compare always.
3. It would depend on mods adopting the library. There is a natural hesitation to use dependencies. I suggest an embedded library. But even as an embedded library it would be unlikely to be used by established mods that parse combat. Some mods don't even use combat logs but use UNIT_COMBAT instead.
|
Yes I have thought about all of these. I'm not that good at creating good codes, but I will mostly likely "learn" from good codes such as yours and addons like Ace, FuBar libraries etc.
1. Addons register to lib for specific events they want to listen, and lib only register an event when someone actually wants to listen.
2. If there is a common library, when we "optimize" something in the parsing code, all client addons benefit from it. If there are many addons using it, I personally think there should make some actual differences on performance. And by (1) since lib only register an event if there is at least one event interested in it, performance should only be better, not worse IMO?
3. Yeah, most likely I'll just learn from existing libraries such as BabbleLib, CompostLib.
Its greater use would be lowering the barrier of entry for new mods. These are all likely things you've thought of, but I would keep in mind:
1. Mods often care when damage happened as much as what happened.
2. There will be huge demand for sync'ing the data.
3. You'll need to decide where the data lives. Do you store every conceivable effect, resist and combatant in the library's tables? Or do you let the separate mods handle that?
|
1. Yes, damage part is the core, and it's why I wanted to do this. The lib can already parses all attacks, hits and misses. But if I have to made a common library, I should I should add all event messages which requires parsing, such as.... spell started casting, making items, gaining rep, raising to another level of rep against some factions etc. If I have the knowledge to make an addon which knows ALL patterns, then at the same time I should be able to complete the documentation.
2. What kind of sync'ing do you mean?
3. For now the approach is to pass a table recording parsed information to the client functions. I know creating a table for every event is wasteful so this is gonna get changed, my thought is stay on passing tables, but use CompostLib to recycle them. So that's an embedded library in an embedded library. Client addons are expected to record down required information immedately when they receive the table, since the table is gonna get recycled.
I think a sane approach to a parsing library would be to let the other mods handle the data themselves.
MyMod registers with the library, telling it to send stuff to MyMod.CombatEvent()
Bob's Smite hits Joe for 100 Holy damage (10 resisted).
library calls MyMod.CombatEvent("damage","Bob","Joe","Smite","Holy",100)
The MyMod.CombatEvent can work from generic to specific for its particular needs, ignoring stuff it doesn't care about and stowing away the info it does.
Actually now that I think about it, I think this is the only possible type of library implementation. Otherwise if you reset the data in one mod you reset them all, unless you plan to keep a massive--MASSIVE--amount of information.
|
Yes, these are very close to my thoughts, although I create a table storing "damage", "Bob", "Joe" etc and pass it to the client function on each event, I know this is not a good behaviour.
On localization, I speak from months of experience and ulcers: I will never again attempt to do localized combat log parsing. The german possessives, the ambiguous french heals, etc make me nauesous thinking back to it.
Good luck with it. It's an ambitious project.
|
Localization is what taking me the most time, I learned most of the codes from your Recap, it's really a good addon, much better than what I can make. But when I try to learn from your language converting part, I have found quite many problems on each language.
Since then I have always been trying to solve this problem, so I think if there're someone doing the same thing, I can share my results.
The basic approaches are explained on the previous posts, but in addition I have made a "testing function" to simulate all patterns, and warning on wrong info being parsed. Then I just copy the whole globalstring.lua into the addon (you can't replace globalstring.lua now).
It's not a trivial project, that's why I hope someone are already working on them, so that I don't have to do all these on my own. But anyway I have already made something for both documentation and addon.
For the documentation, basically I created a simple addon which stores ALL possible patterns, and registers all pattern-related events. Then I just play the game normally and let it records what event will produces what patterns. Then I just need to refer to the stored variables to create the documentation.
For the addon I have just made the bare bones: clients register to it, it registers the events if there are clients interested on, if there are events then it parses for the inforation and then pass to client function as a table. The clients will check the "category" variable, and refer to the addon documentation to know what variables will be passed to each category. Currently I believe the patterns related to damage part should be complete ( those which Recap, DamageMeters and CombatStats would interested on ).