I wanted to start a discussion about combat logging and what features I hope to see implemented in order for log analysis tools for WildStar to be really great. I should start by introducing myself. I'm Kihra, and I'm working on developing a log analysis site for WildStar. This site will end up at http://wildstarlogs.com/, but if you are interested in checking out the in-development version you can go to http://dev.wildstarlogs.com/. At the moment I'm mostly concentrating on the non-log aspects of the site (e.g., user accounts, guilds, the calendar, etc.), but I've also implemented a lot of the GUI for the logs themselves (charts, graphs, and so on). Let me just begin by listing off the features I'd like to see in order to make a great tool for the game, and I'm hoping others will help me fill in the blanks if there's anything I've left out. So let's talk about in-game add-ons first: (1) Add-on support for responding to an unfiltered combat event. What I mean by unfiltered is that it should be possible for a client to see an event even if they have nothing to do with the event. For example, if a bunch of people are attacking an enemy, let's say Metal Maw, I want to be able to see all the damage done to Metal Maw, even damage that comes from outside my party. In other words, I would like a "damage meter" add-on to be able to see all the events on one client so that it can function by itself without the need for every player in a group to have the add-on installed. (2) Make sure to communicate unique type IDs and unique instance-of IDs for enemies. Ideally an enemy will have both a unique type identifier representing what he is, e.g., "Warlord Scary", but then also have an instance-of identifer that represents which version of "Warlord Scary" you're fighting. This is important for being able to tell different copies of the same mob apart. (3) Make sure pets can be attributed to their owners. For any pets that are summoned by players (or by enemies), it's important that there is an easy way to discern who the pet belongs to. This can either be done with a SUMMON event that communicates that a player summoned a pet with a given GUID (and instance GUID, see (2) above), or the player's GUID could continue to be communicated in all events involving the pet. (4) Communicate Effective Healing. It's important for healing that we don't just see raw heal amounts. We need to know the amount of effective healing done as well as the raw healing. This allows analysis sites to compute overhealing as well if they have both numbers. (5) Attribute Absorbs to their owners. I don't know if you have absorb mechanics or not, but assuming you do, make sure to communicate the amount absorbed in damage events, but ideally also find a way to attribute the absorbs back to their original owners so that it can be counted as part of their total healing. If any healers or tanks are based around absorb mechanics, it's important to be able to analyze how much damage is being mitigated (in the tank case) and to properly attribute the absorb as healing to its originator. (6) Don't hide damage mitigation like Blocking. Assuming tanks have some kind of "block" or "shield" mechanics, and especially if the amount they block can fluctuate, e.g., if there is a "Block Value" stat, it's important to communicate the amount blocked in damage events. In general if damage is being mitigated in such a way that the value is not readily discernible (e.g., it's based off a stat or can be altered by procs), then it's important to communicate the amount that was mitigated. (7) Communicate hostility clearly. It's not enough to know whether or not a mob is an enemy or a player. You also need to know their disposition towards you. If that disposition is the result of a temporary affliction, e.g., Mind Control, it's important that damage be counted as "Friendly Fire" rather than "Damage Done." (8) Don't hide enemy-only events. In some cases enemies may gain buffs that increase their damage, or maybe one enemy heals another. It's important that these events be communicated even though they involve no players. (9) Make sure the range of the combat log is large With 40-man raids, I imagine you're going to have some pretty big rooms. Ideally the range of the combat logging will be large enough to capture everything happening in a raid. (10) Support logging to an external file In order for third party Web sites to be built around WildStar, we'll need to support logging to an external file. Although add-ons can certainly provide basic analysis (on the level of Recount or Skada), they simply can't hold all of the raw events in memory, nor can they write that volume of data to disk. External logging is going to be necessary to allow for really robust analysis of the data such as raw event browsing and expression-based queries. As for my wish list for the external file format: (a) Pack it as much as you can. The WoW combat log for example is far more verbose than it needs to be, and this results in sites like World of Logs having to pack the file client-side before even transmitting it to their Web site. For example, if you have 50 unique events, don't write them out in the log as SPELL_PERIODIC_DAMAGE every time like WoW does. Just use a number. (b) The date of the combat log should be clear. You can do this by using different files for each log session (like Star Wars), or you could put the date into the combat log file for each event (like WoW does). (c) Make sure that information is obtainable from the file without the need for additional APIs. For example, it should be possible to tell if a mob is a player, a pet, mind controlled, a vehicle, hostile, etc. (d) Make sure to flush it to disk often enough that live logging works. In order for people to be able to check the previous attempt on the Web site to find out what happened, live logging needs to work. In order for live logging to work, though, the combat log needs to flush to disk regularly, especially once combat has ended. I'm sure there are many more things I'm not thinking of, but this should be more than enough to kick-start a discussion.