1. Hey Guest! If you're more than just a WildStar fan and want to keep up on the latest MMO news, reviews and opinion pieces then I'd like to suggest you visit our sister site MMO Central

Let's talk about Combat Logs!

Discussion in 'WildStar General' started by Kihra, May 6, 2013.

  1. Kihra

    Kihra Cupcake

    Joined:
    Mar 29, 2013
    Likes Received:
    35
    Trophy Points:
    18
    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.
     
    KTap, Kallor, Shimitsu and 16 others like this.
  2. Draahl

    Draahl Cupcake-About-Town

    Joined:
    Apr 15, 2013
    Likes Received:
    45
    Trophy Points:
    28
    Location:
    Sweden
    Good job :) this is something that is vital for us who wants to min/max everything. Keep up the good work :)
     
  3. Convicted

    Convicted Super Cupcake

    Joined:
    Apr 28, 2013
    Likes Received:
    755
    Trophy Points:
    113
    My number one request is a "good" death log. Recount was an example of a good death log, very detailed, on the flip side Skada was an example of a bad death log.
     
    Neepz likes this.
  4. Neepz

    Neepz New Cupcake

    Joined:
    May 4, 2013
    Likes Received:
    7
    Trophy Points:
    3
    Awesome work. :up:
    As a healer, I'm glad you remembered about (5).
     
  5. Sol

    Sol Cupcake-About-Town

    Joined:
    Apr 23, 2013
    Likes Received:
    28
    Trophy Points:
    28
    I would personally like to also see interrupts tracked as well as CC's that are broken.
     
  6. Dwel

    Dwel Cupcake

    Joined:
    Apr 11, 2013
    Likes Received:
    32
    Trophy Points:
    18
    Location:
    Europe
    In a nutshell, give us as much information as possible, log-wise. What gets parsed by default in the in-game combat log can get complimented by addon creators.
     
    kur1 likes this.
  7. Bainik

    Bainik Cupcake-About-Town

    Joined:
    Apr 11, 2013
    Likes Received:
    103
    Trophy Points:
    43
    I would also think information on cast interrupts would be important. Just seeing the skill was used doesn't tell you who kicked what which is really important at times.
     
  8. UNDERZZZZZ

    UNDERZZZZZ Cupcake-About-Town

    Joined:
    May 5, 2013
    Likes Received:
    160
    Trophy Points:
    43
    Logs are certainly necessary for the best plays to use as an analysis tool. The pets being attributed to owners is good, although much of it I don't understand. Would you be planning a ranking system? That for me was a brilliant part of the enjoyment of my raiding, especially as content got older.
     
  9. Calsic

    Calsic Cupcake-About-Town

    Joined:
    Feb 19, 2013
    Likes Received:
    185
    Trophy Points:
    43
    Location:
    Vancouver, Canada
    Sometime during Burning Crusade, one of the addons (Recount?) was causing quite a few people (lower end pc's I think) to disconnect during raids. Hope 40 man raiding doesn't bring that problem back. It was annoying.

    Can't wait to see what awesome addons the community comes up with though.

    @OP, I always like to see who prevented damage through interrupts, dispels, etc. Also, time and cause of death. Oh, and overheals too please.
     
  10. Cocochinese

    Cocochinese New Cupcake

    Joined:
    May 6, 2013
    Likes Received:
    0
    Trophy Points:
    1
    I think this pretty much sums it all up for me. Having every little detail available to analyze is something I really enjoy doing during raids and mainly when I am not raiding. Have that much information to dissect is huge boon for any facet of the game.
     
  11. Convicted

    Convicted Super Cupcake

    Joined:
    Apr 28, 2013
    Likes Received:
    755
    Trophy Points:
    113
    I'm pretty sure the d/c bug for recount was fixed a while ago, people will need to select how many things they want to track based on their pc performance, most of the raid shouldn't really need to track enough things that would bog their system down.
     
  12. Jeremy Gaffney

    Jeremy Gaffney Former Carbine Alumni

    Joined:
    Mar 18, 2013
    Likes Received:
    1,135
    Trophy Points:
    93
    Location:
    Aliso Viejo, CA
    Well thought out, Kihra. I don't have enough WS modding experience myself to answer your questions, but given Jon's philosophies as he works on the UI system (basically anything available to our dev UIs is available to player-made UIs, to oversummarize) it's likely much of this is supported out of the box - but we'll ask the folks involved.

    On the external logs, not sure if we support them yet or not (we have the dev ability to do such but not sure if that's enabled for players or not).

    I pinged the community folks to see if someone technically qualified is nearby to post a response (everyone's super busy with beta but you had good feedback/questions here IMO).

    -jg
     
    SiegaPlays, Haoli and Cocochinese like this.
  13. Kihra

    Kihra Cupcake

    Joined:
    Mar 29, 2013
    Likes Received:
    35
    Trophy Points:
    18
    My system caches events prior to a death so that you'll know at a glance the last five damaging events that hit you. You can then drill into the raw events to see a more detailed death overview if those five events aren't sufficient to tell what happened.

    One thing that has always annoyed me about detailed death logs is that they typically show extraneous events and/or they go back too far. Really you only need to rewind to the point where you were last at full health, since anything before that is irrelevant.
    Yes, interrupts, dispels and purges are all important. I made the baseline assumption that the game will at least have events for all of the basic actions you can take, so I didn't bother to enumerate them, but you are right that they are probably worth calling out as being important.

    In general, these are the events that I would hope to be present:
    (1) Events for the application, removal and refresh of buffs and debuffs.
    (2) Events for when you begin activating or "casting" an ability.
    (3) Event for when the ability completes casting (and possibly if it fails for add-ons that wish to do replacement cast bars, etc.).
    (4) Events for damage, both for a straight-up hit and for periodic damage (like from a DoT). Damage should include the amount absorbed or blocked, as well as info about parrying, dodging, missing, crits, mechanics like that.
    (5) Healing events, both for a direct heal and tick heals. Healing should include both effective healing and overhealing (also indicate absorb information if it's an absorb and not a heal).
    (6) Events for summon/dismissal of pets.
    (7) Events for interrupts that also indicate what ability was interrupted.
    (8) Events for dispels and purges that directly connect the dispel/purge to the buffs/debuffs being removed. (Don't make us guess!)
    (9) Death events for all units.
    Yes, rankings will be implemented, although I will probably wait until I have much more information about the raids before tackling that. Especially if the raids vary significantly from week to week, overall rankings may be devalued as a result, e.g., maybe one week has an encounter that lets you do much more DPS.
    One of the issues when you listen for all combat events in an add-on is that you need to get in and get out fast. You can't take your time processing each event. Usually the issue with damage meter add-ons is that they take too much time handling each event.

    I think one possible way to handle these concerns is to restrict event processing to the window type you actually have displayed in your UI. For example if you only have a damage meter and not a healing meter, you could consider having an option to just ignore healing events and not waste time processing them. (By default, WoW add-ons like Skada process everything, so they get bogged down by healing on Ultraxion for example, even if all you cared about was damage.)
    This is why I think external logging is important. In-game add-ons are incredibly useful, but at best they can really only provide an overview. For really comprehensive analysis (especially query-based raw event filtering), you've just got to be able to access all of the combat events and get them up to a Web site for processing.
    Thanks Jeremy!
     
    Sonntam likes this.
  14. SiegaPlays

    SiegaPlays "That" Cupcake

    Joined:
    Sep 14, 2011
    Likes Received:
    454
    Trophy Points:
    83
    Location:
    Denmark
    I use world of logs for wow and I really like the streaming client there, because if I dc, what has been streamed is still reported on site, while combatlogs itself have a tendency to not save on dc - well, that is just my observation, I have lost a couple of combatlogs to dc.

    I would prefer to upload the combatlog after, but to ensure that the report is not lost, I stream it.
     
  15. Kihra

    Kihra Cupcake

    Joined:
    Mar 29, 2013
    Likes Received:
    35
    Trophy Points:
    18
    I agree that live logging is important. A complete logging picture looks something like this:

    Game Requirements:
    - Support for unfiltered combat events.
    - Ability to write combat log to disk via a command, e.g., "/combatlog"
    - Log gets flushed to disk often enough that live logging is possible (when combat ends would be sufficient).

    Add-Ons:
    - "Recount/Skada" Damage Meters to allow for some simple information to be available to players immediately.
    - "Loggerhead" Add-on to automatically enable combat logging in certain zones (handles turning on /combatlog when you zone into a raid instance for example).

    External Logging:
    - Native client that can scan the log file as it is being generated, pack it, and transmit individual fights as they happen to a Web site. (Don't worry. I'm not going to write it in Java.)
    - The ability to upload a complete file later (e.g., for people who hate live logging or have a d/c, etc.). Can be done through the same client or just by uploading directly to the Web site.
    - Web site that can process and store the raw event information and provide detailed analysis capabilities.

    With 40-man raids, these combat log files are going to be *huge*, so live logging will be very beneficial as far as keeping the upload size down. For comparison, a 4-5 hour raid in WoW for 25-mans generates a 500 MB file. For 40 players that result will be even larger, although as I mentioned in a previous post, WoW's combat log file is not designed with size in mind.

    At any rate, I'll be thrilled if WildStar has external logging at all, since I can work with pretty much any file format they give me. If it's inefficient, I'll pack it before uploading, so no big deal either way.
     
  16. SiegaPlays

    SiegaPlays "That" Cupcake

    Joined:
    Sep 14, 2011
    Likes Received:
    454
    Trophy Points:
    83
    Location:
    Denmark
    ok, I put this on my watch list, I am definitly interested in testing it out, when we get closer to a time where it can be done :)
     
  17. pseudo

    pseudo Podcaster

    Joined:
    Aug 22, 2012
    Likes Received:
    250
    Trophy Points:
    63
    This is so cool! Thank you for letting us know about this project! :)

    Can't wait to see more
     
  18. Bitwise

    Bitwise Former Carbine Alumni

    Joined:
    May 8, 2012
    Likes Received:
    35
    Trophy Points:
    13
    More tasks for the tasklist!

    Hey, why is this list still growing....
     
  19. AcidBaron

    AcidBaron "That" Cupcake

    Joined:
    May 4, 2013
    Likes Received:
    623
    Trophy Points:
    93
    Location:
    Belgium
    Simply want to add that i'm glad the general consensus is there that combat logs are a useful addition to the game and not a hindrance and something that should be there by default to help you improve.

    For combat log specific, i believe most have already been mentioned such as personal buff uptime, damage done and taken so forth..


    But for me more importantly as a raid leader. And i haven't seen this yet a death log.
    This basically constructs the last minute of the person, seeing to up to a tenth of a second what happened to the person to diagnose to actual cause of death.
    Often the combat log alone would tell me that i died by this big melee swing, but if you dig deeper you actually notice it was by a late response of a dispell that actually caused you to take a large DoT tick before hand, that actually killed you.

    A good example for this is what i use in WoW, deathnote, it's a quick tool that tells me everything i need to know to see the actual cause of dead and steer corrections in the right direction and is a nice time saving tool.

    I didn't see this mention, yet ad find something when on the subject of logs a real interesting tool to have that tells you more than damage taken when looking at cause of death, the correct cause of death that is.
     
  20. Kihra

    Kihra Cupcake

    Joined:
    Mar 29, 2013
    Likes Received:
    35
    Trophy Points:
    18
    A couple of things I forgot to mention:

    - Stacking buffs/debuffs. Make sure that your buff/debuff events can communicate stacking clearly (either with additional events, or with the stack being communicated as part of application/removal events).

    - Overkill. When a damaging event kills you, the overkill should be communicated. This is kind of analogous to overhealing (it's even in the same parameter position on WoW damage events as overheal is for a heal event).
     

Share This Page