PvPLog's Future

Forum Dedicated to PvPLog, (The WoW PvP data collector addon), and PvPLog related topics

Moderator: bsmorgan

PvPLog's Future

Postby bsmorgan » Thu Jan 31, 2008 8:25 am

As some of you know, World of Warcraft version 2.4 is going to drastically change the format of the combat log. The heart of PvPLog is a language independent combat log parser that is no longer being maintained. While the Blizzard changes should lessen language dependencies, a replacement parser will still have to be found or written.

If you've been using PvPLog since before World of Warcraft 2.0, you will remember there was period of time when PvPLog didn't work on 2.0, and when it did work, its behavior was different because of the changes Blizzard made. While I did get on the test servers before the release, there wasn't enough time to have a working version when 2.0 was released.

Expect another period of time after the release of 2.4 before PvPLog works again. There's also a chance that the changes Blizzard has planned for the combat log will prevent PvPLog from ever working.

There are some problems in the current PvPLog data structures that will require a significant amount of work and I am reluctant to start this work until after 2.4 is available (as there may also be some data structure changes required by 2.4). I am, however, going to document the problems here just so they aren't forgotten.

When the PvPLog data structures were laid out, a name was unique on each realm, and there wasn't any way two different realms could ever be in combat with each other. Furthermore, there were two factions on each realm and characters on the same faction could only engage in combat with each other by dueling.

Blizzard added cross-realm battlegrounds and arenas and both of the above assumptions are no longer valid. The PvPLogData structure uses name as a key when it should use name and realm as a key. Furthermore, it uses guild as a key when it should use guild and realm as a key. It is also possible that two players on the same faction can both duel and oppose each other in an arena match (and I haven't figured out what this does to the keys).

While the occurance of name clashes is probably going to be rare, be aware that PvPLog will combine the records of two players with the same name from two different realms, and will it combine the guild totals as well. The duel and arena contests between the same players may inaccurately report a duel as an arena match or vice versa and it may combine or replace win loss records.

WowRoster should have enough information in the PurgeLogData records to prevent any of the above from happening.

Regards,

Brad
User avatar
bsmorgan
WoW Interface Developer
WoW Interface Developer
 
Posts: 160
Joined: Tue Nov 28, 2006 10:17 pm
Location: Colorado Springs, Colorado

PvPLog's Future

Postby cwpc » Wed Feb 06, 2008 10:53 pm

This was copied from www.mmo-champion.com, who copied it from the wow forums


Quote from: Vaneras (Source)The whole combat log also supports a new coloring model, based on context. While by default, entire lines are a single color, highlighting the most important details. The combat log also supports coloring just unit names, spells, actions and damage numbers. Spells and damage can also be colored by school. However, there are several features not exposed in the base UI that AddOns can use right away. These are event-specific coloring, unit coloring with greater granularity and the ability to customize the list of highlighted events.

There are several other formatting related features. You can enable timestamps which show the time that spell or attack happened. You can show or hide square braces, change formatting without refreshing the combat log and disable the display of raid icons. These features were too niche to go into the base UI, but can be easily exposed for power users. By now you’ve already thought of some features of your own and are ready to get to coding. So let’s jump straight to some examples.

Formatting & Coloring
One of the major combat log formats we considered while redoing the combat log was the Nurfed Combat Log format. This combat log format was very concise, made heavy use of color-coding and was one of the final candidates for the combat log. We eventually axed it on the basis of being too overwhelming for new users. However, we left in all of the options to convert the current combat log into the Nurfed combat log.

Here’s how:

Combat Log Settings -> Colors
Unit Colors:
Me -> Green
My Pet -> Dark Green
Friends -> Blue
Enemies -> Red
Neutral -> Yellow

Colorize:
Unit Names -> Checked
Spell Names -> Checked
Spell Color-by-School -> Checked
Damage Number -> Checked
Damage Color-by-School -> Checked
Damage School -> Checked
Entire Line -> Unchecked
All Highlighting Options-> Unchecked

Formatting:
Verbose -> Unchecked
Braces -> Checked
Timestamps -> Checked

However, some people may want it even more terse than that. For this, we present:

Hyper Condensed Mode
To get rid of the word “Fire” and “Frost” type:

/script TEXT_MODE_A_STRING_VALUE_SCHOOL = “”;

That will remove the Fire from “55 Fire”. However, let’s go even farther:

(Critical) (Crushing) (Blocked) (Resisted)

All of these are really long. Let’s compress them:

TEXT_MODE_A_STRING_RESULT_RESISTED = "R";
TEXT_MODE_A_STRING_RESULT_BLOCKED = "B";
TEXT_MODE_A_STRING_RESULT_ABSORBED = "A";
TEXT_MODE_A_STRING_RESULT_CRITICAL = "C";
TEXT_MODE_A_STRING_RESULT_GLANCING = "G";
TEXT_MODE_A_STRING_RESULT_CRUSHING = "Cr";

Now we get

[You] [Fireball] Hit [Spider] 64. (C) (5 R)
Image
Image
Image
User avatar
cwpc
WR.net Expert
WR.net Expert
 
Posts: 151
Joined: Wed Jun 13, 2007 9:07 pm
Location: The Edge of Insanity

PvPLog's Future

Postby zanix » Thu Feb 07, 2008 12:39 am

Very good information
Thanks cwpc
Read the Forum Rules, the WiKi, and Search before posting!
WoWRoster v2.1 - SigGen v0.3.3.523 - WoWRosterDF
User avatar
zanix
Admin
Admin
WoWRoster.net Dev Team
WoWRoster.net Dev Team
UA/UU Developer
UA/UU Developer
 
Posts: 5543
Joined: Mon Jul 03, 2006 8:29 am
Location: Idaho Falls, Idaho
Realm: Doomhammer (PvE) - US

PvPLog's Future

Postby cwpc » Thu Feb 07, 2008 1:04 am

More info

From Here

Combat Log Revamp!

In 2.4 the combat log is being completely reimplemented so that it sends events with arguments instead of text strings to the UI code.

It's still in development, so nothing is final, but here is a raw sneak preview:


-- Object type constants
-- Affiliation
COMBATLOG_OBJECT_AFFILIATION_MINE = 0x00000001;
COMBATLOG_OBJECT_AFFILIATION_PARTY = 0x00000002;
COMBATLOG_OBJECT_AFFILIATION_RAID = 0x00000004;
COMBATLOG_OBJECT_AFFILIATION_OUTSIDER = 0x00000008;
COMBATLOG_OBJECT_AFFILIATION_MASK = 0x0000000F;
-- Reaction
COMBATLOG_OBJECT_REACTION_FRIENDLY = 0x00000010;
COMBATLOG_OBJECT_REACTION_NEUTRAL = 0x00000020;
COMBATLOG_OBJECT_REACTION_HOSTILE = 0x00000040;
COMBATLOG_OBJECT_REACTION_MASK = 0x000000F0;
-- Ownership
COMBATLOG_OBJECT_CONTROL_PLAYER = 0x00000100;
COMBATLOG_OBJECT_CONTROL_NPC = 0x00000200;
COMBATLOG_OBJECT_CONTROL_MASK = 0x00000300;
-- Unit type
COMBATLOG_OBJECT_TYPE_PLAYER = 0x00000400;
COMBATLOG_OBJECT_TYPE_NPC = 0x00000800;
COMBATLOG_OBJECT_TYPE_PET = 0x00001000;
COMBATLOG_OBJECT_TYPE_GUARDIAN = 0x00002000;
COMBATLOG_OBJECT_TYPE_OBJECT = 0x00004000;
COMBATLOG_OBJECT_TYPE_MASK = 0x0000FC00;
-- Special cases (non-exclusive)
COMBATLOG_OBJECT_TARGET = 0x00010000;
COMBATLOG_OBJECT_FOCUS = 0x00020000;
COMBATLOG_OBJECT_MAINTANK = 0x00040000;
COMBATLOG_OBJECT_MAINASSIST = 0x00080000;
COMBATLOG_OBJECT_RAIDTARGET1 = 0x00100000;
COMBATLOG_OBJECT_RAIDTARGET2 = 0x00200000;
COMBATLOG_OBJECT_RAIDTARGET3 = 0x00400000;
COMBATLOG_OBJECT_RAIDTARGET4 = 0x00800000;
COMBATLOG_OBJECT_RAIDTARGET5 = 0x01000000;
COMBATLOG_OBJECT_RAIDTARGET6 = 0x02000000;
COMBATLOG_OBJECT_RAIDTARGET7 = 0x04000000;
COMBATLOG_OBJECT_RAIDTARGET8 = 0x08000000;
COMBATLOG_OBJECT_NONE = 0x80000000;
COMBATLOG_OBJECT_SPECIAL_MASK = 0xFFFF0000;

COMBATLOG = ChatFrame2;

Code: Select all
-- Process the event and add it to the combat log
function CombatLog_AddEvent(...)
   local info = ChatTypeInfo["COMBAT_MISC_INFO"];
   local timestamp, type, srcGUID, srcName, srcFlags, dstGUID, dstName, dstFlags = select(1, ...);
   local message = format("%s> %s, %s, %s, 0x%x, %s, %s, 0x%x",
                          date("%H:%M:%S", timestamp), type,
                          srcGUID, srcName or "nil", srcFlags,
                          dstGUID, dstName or "nil", dstFlags);
   for i = 9, select("#", ...) do
      message = message..", "..(select(i, ...) or "nil");
   end
   COMBATLOG:AddMessage(message, info.r, info.g, info.b);
end

-- Save the original event handler
local original_OnEvent = COMBATLOG:GetScript("OnEvent");
COMBATLOG:SetScript("OnEvent",
   function(self, event, ...)
      if ( event == "COMBAT_LOG_EVENT" ) then
         CombatLog_AddEvent(...);
         return;
      end
      original_OnEvent(self, event, ...);
   end
);
COMBATLOG:RegisterEvent("COMBAT_LOG_EVENT");



New API functions:
CombatLogResetFilter()
CombatLogAddFilter("events", "srcGUID" or srcMask, "dstGUID" or dstMask)
CombatLogSetRetentionTime(seconds)
seconds = CombatLogGetRetentionTime()
count = CombatLogGetNumEntries()
CombatLogSetCurrentEntry(index)
timestamp, type, srcGUID, srcName, srcFlags, dstGUID, dstName, dstFlags, ... = CombatLogGetCurrentEntry()
hasEntries = CombatLogAdvanceEntry(count)
CombatLogClearEntries()

Note that you can change filters on the fly and re-query previous combat log entries, which are retained for 5 minutes by default.


Oh, the combat log text file format changed as well, dumping the text format in favor of a comma separated event format for easy post-processing and analysis.


Since the combat log filter is global, there is a new event that AddOns can register for:
COMBAT_LOG_EVENT_UNFILTERED
If you register for this event, you will receive the event regardless of whether it matches the current filter.

There is also a new optional ignoreFilter parameter for the following functions:
CombatLogGetNumEntries()
CombatLogSetCurrentEntry()
CombatLogAdvanceEntry()
Passing true as the last parameter allows you to iterate over combat log entries ignoring the filter.


Interface Options Revamp

Along with Patch 2.4 we will be releasing a revamped in-game Interface Options screen. Most of the systems that interact with the current Interface Options screen have seen some code changes as a result. The new architecture for the system should allow AddOn authors to modify its contents without the taint issues presented by the current Interface Options system.

Additionally, this new system will contain an area for AddOn authors to present their own configuration options to players with a custom heading, subcategories, and frames. I'd like to encourage authors interested in utilizing these features to try the new system on the PTRs before Patch 2.4 is released. Basic details on how to use this system can be found in code comments in Blizzard_InterfaceUI.lua.

Please be aware that AddOns that interact with the Interface Options screen, modify it, or change the way that its options affect other systems within the game will need to be updated with the release of Patch 2.4.


MOD: bbcode fixed
Last edited by cwpc on Thu Feb 07, 2008 1:55 am, edited 1 time in total.
Image
Image
Image
User avatar
cwpc
WR.net Expert
WR.net Expert
 
Posts: 151
Joined: Wed Jun 13, 2007 9:07 pm
Location: The Edge of Insanity

PvPLog's Future

Postby cwpc » Thu Feb 07, 2008 1:05 am

Best post on this info so far


2.4.0 Guide to the New Combat Log

Hello Fellow UI Modders,

With the release of patch 2.4.0, we’ve made some enormous changes to the existing combat log. While this will result in some hard work now, it should be easier to maintain your AddOns in the future.

The feature we’re most proud of is the ability to filter your combat log. The combat log stores the last five minutes worth of raw combat events. Filters can be setup on multiple criteria, affiliation, ownership, etc. Any events that match the current filter are passed through the client via the COMBAT_LOG_EVENT message. The combat log filter is global. However, AddOns which want to parse all events the moment they happen can register for the COMBAT_LOG_EVENT_UNFILTERED message. This should allow all existing AddOns to still respond to combat events without a complicated middle-manager AddOn.
While the default combat log will only be setting 1-2 filters at a time, the WoW client supports many simultaneous filters. It’s possible to setup multiple filters to filter very specific source-target-event combinations. If a combat log event passes any of the filters, the COMBAT_LOG_EVENT event fires. This allows AddOns to define extremely specific settings we chose not expose in the base UI.

The new combat log will be coming with two text formats. One is the familiar, grammatically correct sentences with substitutions. The other is a terse format, containing the source, target, spell, action and result. There will be a number of ways to manipulate the formatting, from unit name coloring to coloring the damage numbers by their magic school. The settings used for these formats are stored in the Blizzard_CombatLog_Filters variable.

The result of the new terse format is that it’s very easy to write AddOns to modify or extend the format which ships with 2.4.0. In the formatting section, you can read up on a quick demonstration of how to convert the combat log to a “Nurfed” style combat log. While you can do a lot by just adjusting the settings within WoW, it’s also possible to provide an AddOn that changes the strings used to generate the Combat Log messages. This allows for more extensive formatting changes without re-writing the entire parsing engine. See the Formatting Section for an example.

The whole combat log also supports a new coloring model, based on context. While by default, entire lines are a single color, highlighting the most important details. The combat log also supports coloring just unit names, spells, actions and damage numbers. Spells and damage can also be colored by school. However, there are several features not exposed in the base UI that AddOns can use right away. These are event-specific coloring, unit coloring with greater granularity and the ability to customize the list of highlighted events.

There are several other formatting related features. You can enable timestamps which show the time that spell or attack happened. You can show or hide square braces, change formatting without refreshing the combat log and disable the display of raid icons. These features were too niche to go into the base UI, but can be easily exposed for power users. By now you’ve already thought of some features of your own and are ready to get to coding. So let’s jump straight to some examples.

Formatting & Coloring
One of the major combat log formats we considered while redoing the combat log was the Nurfed Combat Log format. This combat log format was very concise, made heavy use of color-coding and was one of the final candidates for the combat log. We eventually axed it on the basis of being too overwhelming for new users. However, we left in all of the options to convert the current combat log into the Nurfed combat log.

Here’s how:

Combat Log Settings -> Colors

Unit Colors:
Me -> Green
My Pet -> Dark Green
Friends -> Blue
Enemies -> Red
Neutral -> Yellow
Colorize:
Unit Names -> Checked
Spell Names -> Checked
Spell Color-by-School -> Checked
Damage Number -> Checked
Damage Color-by-School -> Checked
Damage School -> Checked
Entire Line -> Unchecked
All Highlighting Options-> Unchecked

Formatting:
Verbose -> Unchecked
Braces -> Checked
Timestamps -> Checked


However, some people may want it even more terse than that. For this, we present:

Hyper Condensed Mode

To get rid of the word “Fire” and “Frost” type:

/script TEXT_MODE_A_STRING_VALUE_SCHOOL = “”;

That will remove the Fire from “55 Fire”. However, let’s go even farther:

(Critical) (Crushing) (Blocked) (Resisted)

All of these are really long. Let’s compress them:

TEXT_MODE_A_STRING_RESULT_RESISTED = "R";
TEXT_MODE_A_STRING_RESULT_BLOCKED = "B";
TEXT_MODE_A_STRING_RESULT_ABSORBED = "A";
TEXT_MODE_A_STRING_RESULT_CRITICAL = "C";
TEXT_MODE_A_STRING_RESULT_GLANCING = "G";
TEXT_MODE_A_STRING_RESULT_CRUSHING = "Cr";

Now we get

[You] [Fireball] Hit [Spider] 64. (C) (5 R)


Filters
Filters consistent of 3 parts:



Source

Target

Events


Source & Target can be one of two types:



String

Number


If it is a string, then that string is assumed to be the GUID of the unit in question. If it’s a number, it is assumed to be a bitfield assembled from the following criteria:

Constants

-- Affiliation
COMBATLOG_OBJECT_AFFILIATION_MINE = 0x00000001;
COMBATLOG_OBJECT_AFFILIATION_PARTY = 0x00000002;
COMBATLOG_OBJECT_AFFILIATION_RAID = 0x00000004;
COMBATLOG_OBJECT_AFFILIATION_OUTSIDER = 0x00000008;
COMBATLOG_OBJECT_AFFILIATION_MASK = 0x0000000F;
-- Reaction
COMBATLOG_OBJECT_REACTION_FRIENDLY = 0x00000010;
COMBATLOG_OBJECT_REACTION_NEUTRAL = 0x00000020;
COMBATLOG_OBJECT_REACTION_HOSTILE = 0x00000040;
COMBATLOG_OBJECT_REACTION_MASK = 0x000000F0;
-- Ownership
COMBATLOG_OBJECT_CONTROL_PLAYER = 0x00000100;
COMBATLOG_OBJECT_CONTROL_NPC = 0x00000200;
COMBATLOG_OBJECT_CONTROL_MASK = 0x00000300;
-- Unit type
COMBATLOG_OBJECT_TYPE_PLAYER = 0x00000400;
COMBATLOG_OBJECT_TYPE_NPC = 0x00000800;
COMBATLOG_OBJECT_TYPE_PET = 0x00001000;
COMBATLOG_OBJECT_TYPE_GUARDIAN = 0x00002000;
COMBATLOG_OBJECT_TYPE_OBJECT = 0x00004000;
COMBATLOG_OBJECT_TYPE_MASK = 0x0000FC00;

-- Special cases (non-exclusive)
COMBATLOG_OBJECT_TARGET = 0x00010000;
COMBATLOG_OBJECT_FOCUS = 0x00020000;
COMBATLOG_OBJECT_MAINTANK = 0x00040000;
COMBATLOG_OBJECT_MAINASSIST = 0x00080000;
COMBATLOG_OBJECT_RAIDTARGET1 = 0x00100000;
COMBATLOG_OBJECT_RAIDTARGET2 = 0x00200000;
COMBATLOG_OBJECT_RAIDTARGET3 = 0x00400000;
COMBATLOG_OBJECT_RAIDTARGET4 = 0x00800000;
COMBATLOG_OBJECT_RAIDTARGET5 = 0x01000000;
COMBATLOG_OBJECT_RAIDTARGET6 = 0x02000000;
COMBATLOG_OBJECT_RAIDTARGET7 = 0x04000000;
COMBATLOG_OBJECT_RAIDTARGET8 = 0x08000000;
COMBATLOG_OBJECT_NONE = 0x80000000;
COMBATLOG_OBJECT_SPECIAL_MASK = 0xFFFF0000;

A unit can only be one of the following four categories:
1. Affiliation
2. Reaction
3. Ownership
4. Type

Here’s a quick explanation of how these flags are broken down:

Affiliation:
A unit’s affiliation is the unit’s relationship relative to YOU. Either it is owned by you, your party, your raid or someone else.

[[[Mine]Party]Raid] Outsiders

Reaction:
This is the unit’s faction reaction, relative to you. Anything that hates you is Hostile, anything that is friendly with you is Friendly, everything else is Neutral.

Ownership:
This is who owns this object. It can only be controlled by a player or the server.

Unit Type:
This is the way the unit is currently being controlled. Units directly controlled by their owner are players. Units controlled by the server are NPCs. Pets are controlled by another player or unit. Guardians are automatons that are not controlled, but automatically defend their master. Objects are everything else, such as Traps.

The result is that these bits can tell you what kind of unit that combat log object was.

Example:
A player who is dueling you is 0x0548.
(A hostile outsider who is both owned by a player and controlled as a player)
A player who was mind controlled that attacks you is 0x1148.
(A hostile outsiders who is owned by a player, but controlled as a pet)

Default Filters
The default filters are constructed by summing certain bit combinations together:

COMBATLOG_FILTER_MINE = bit.bor (
COMBATLOG_OBJECT_AFFILIATION_MINE,
COMBATLOG_OBJECT_REACTION_FRIENDLY,
COMBATLOG_OBJECT_CONTROL_PLAYER,
COMBATLOG_OBJECT_TYPE_PLAYER,
COMBATLOG_OBJECT_TYPE_OBJECT
);

This means that everything colored mine by default must be affiliated with me, friendly, controlled by a player and be a player.

Any unit that matches at least one bit in each of the four exclusive categories will pass the filter test. Filters can have more than one bit set in a category.

COMBATLOG_FILTER_FRIENDLY_UNITS = bit.bor(
COMBATLOG_OBJECT_AFFILIATION_PARTY,
COMBATLOG_OBJECT_AFFILIATION_RAID,
COMBATLOG_OBJECT_AFFILIATION_OUTSIDER,
COMBATLOG_OBJECT_REACTION_FRIENDLY,
COMBATLOG_OBJECT_CONTROL_PLAYER,
COMBATLOG_OBJECT_CONTROL_NPC,
COMBATLOG_OBJECT_TYPE_PLAYER,
COMBATLOG_OBJECT_TYPE_NPC,
COMBATLOG_OBJECT_TYPE_PET,
COMBATLOG_OBJECT_TYPE_GUARDIAN,
COMBATLOG_OBJECT_TYPE_OBJECT
);

This will allow messages relating to any unit who has a friendly reaction with you, the player. (Another way to do this is to use the “_MASK” suffixed globals, rather than specifying all bits, but I did it this way to make the point clear).


Setting up Filters
Each time you call the CombatLogAddFilter() function, you add a new filter. Any unit that passes that filter fires the COMBAT_LOG_EVENT event. For example, if you wanted to see anything that you did and anything hostile enemies did to you, you would call the following

CombatLogAddFilter(nil, COMBATLOG_FILTER_MINE, nil)
CombatLogAddFilter(nil, COMBATLOG_FILTER_HOSTILE_UNITS , COMBATLOG_FILTER_MINE nil)


Retrieving Combat Messages
Once you setup your filter, all of the entries which match that filter are organized into a linked list. By calling CombatLogSetCurrentEntry(1), you set the current pointer to the beginning of that list. If no message exists, CombatLogSetCurrentEntry(1) will fail. If you pass a negative number into CombatLogSetCurrentEntry(), it will select the Nth entry from the end of the list.

To move the pointer forward, call CombatLogAdvanceEntry(1) to move to the next entry in the list.

The CombatLogGetCurrentEntry() and COMBAT_LOG_EVENT events will return all of the arguments for that event. The exact argument order depends on the event, but here are the arguments that do not change:

timestamp, event, srcGUID, srcName, srcFlags, dstGUID, dstName, dstFlags = CombatLogGetCurrentEntry()

Events
There are honestly too many events to go into detail on all of them here, but here’s the basic organization.

Base Events:
SWING – These events relate to melee swings, commonly called “White Damage”.
RANGE – These events relate to hunters shooting their bow or a warlock shooting their wand.
SPELL – These events relate to spells and abilities.
SPELL_CAST – These events relate to spells starting and failing.
SPELL_AURA – These events relate to buffs and debuffs.
SPELL_PERIODIC – These events relate to HoT, DoTs and similar effects.
DAMAGE_SHIELD – These events relate to damage shields, such as Thorns
ENCHANT – These events relate to temporary and permanent item buffs.
ENVIRONMENTAL – This is any damage done by the world. Fires, Lava, Falling, etc.

Suffixes:
_DAMAGE – If the event resulted in damage, here it is.
_MISSED - If the event resulted in failure, such as missing, resisting or being blocked.
_HEAL – If the event resulted in a heal.
_ENERGIZE – If the event resulted in a power restoration.
_LEECH – If the event transferred health or power.
_DRAIN – If the event reduces power, but did not transfer it.

Special Events:
PARTY_KILL – Fired when you or a party member kills something.
UNIT_DIED – Fired when any nearby unit dies.



Q & A:
Q: The combat log only stores 5 minutes of events. Why 5? Why not 10?
A: We feel that 5 minutes is a good base number for most players . You can change this length, however with the CombatLogSetRetentionTime(seconds) function.

Q: Will the combat log be saved when I logout to my character list?
A: No. However, if you only reload the UI, the messages stay in the client.

Q: Why did you do it this way? Why didn’t you do it X way?
A: We tried to expose as much information as we could, without compromising gameplay and giving us the feature set we needed.

Q: Why didn’t you include information about who owns <Summoned Pet Name Here>?
A: This was one we considered for a while, but decided to leave out for the sake of simplicity. We’re going to be watching how the new combat log plays out before adding new features or making additional changes.

Q: Why did the CombatLog.txt file change?
A: Changing the CombatLog.txt format freed us to implement the combat log in this new event-driven way. We also felt that providing the combat log as raw data made parsing easier for sites such as WoW Web Stats, avoiding localization issues.

Q: Will the combat log format change again?
A: We’re always dedicated to improving our game, so we will very likely be making changes again in the future. However, we do realize the frustration that comes with AddOns breaking between patches. Hopefully, this new system will actually reduce how often you need to recode your AddOns, by decoupling AddOn authors from localization changes.

Q: Can we provide feedback on the new combat log?
A: Absolutely! We’ll be reading the Test Forums during the 2.4.0 PTR and gathering feedback. The more constructive, clear and concise the feedback is, the more responsive we can be.
Image
Image
Image
User avatar
cwpc
WR.net Expert
WR.net Expert
 
Posts: 151
Joined: Wed Jun 13, 2007 9:07 pm
Location: The Edge of Insanity

PvPLog's Future

Postby bsmorgan » Tue Feb 12, 2008 11:57 am

If you are interested in being a alpha tester for the PvPLog version that will be compatible with World of Warcraft 2.4, send me a private message with an email address than can receive .zip attachments and your character name(s) / faction on the "Test Server (US PVP)" realm.

You must be willing to collect debug data (as documented in the sticky topic) and send it to me when requested or when you find a bug.

I will begin testing with no more than 10 people. I may expand the list at a later stage. People (who can read and write in English) with a non-english client and/or a European server will be given preference if I do expand the list. If you fall in this category, please include your client locale and server name in the private message.

Regards,

Brad
Last edited by bsmorgan on Tue Feb 12, 2008 11:48 pm, edited 1 time in total.
User avatar
bsmorgan
WoW Interface Developer
WoW Interface Developer
 
Posts: 160
Joined: Tue Nov 28, 2006 10:17 pm
Location: Colorado Springs, Colorado

Re: PvPLog's Future

Postby bsmorgan » Wed Feb 13, 2008 12:32 am

bsmorgan wrote:... your character name(s) / faction on the "Test Server (US PVP)" realm.


Perhaps this wasn't clear but you have to download and install the Public Test Realm (PTR) client. This gives you a "second" copy of World of Warcraft running the test release of 2.4 which is available now. You access this version using the "Public Test" button on the WoW Launcher.

Character copies are currently disabled so you'll have to start a new character now or wait until you can copy one of your current characters. I have a level 5 Alliance warrior and a version of PvPLog which could be called PvELog (enabled by debug switches).

If none of the above makes sense to you, then you probably aren't a good candidate for this phase of testing. My goal is to have this alpha phase of testing completed and a beta phase started long before version 2.4 is released on the general servers.

Regards,

Brad
User avatar
bsmorgan
WoW Interface Developer
WoW Interface Developer
 
Posts: 160
Joined: Tue Nov 28, 2006 10:17 pm
Location: Colorado Springs, Colorado

PvPLog's Future

Postby cwpc » Wed Feb 13, 2008 1:11 am

I will be willing to test, but my toons arent copied over yet - ill let you know when they are
Image
Image
Image
User avatar
cwpc
WR.net Expert
WR.net Expert
 
Posts: 151
Joined: Wed Jun 13, 2007 9:07 pm
Location: The Edge of Insanity

PvPLog's Future

Postby cwpc » Fri Feb 15, 2008 10:25 pm

I have my toons ont he PVE server - you need testing done there also?
Image
Image
Image
User avatar
cwpc
WR.net Expert
WR.net Expert
 
Posts: 151
Joined: Wed Jun 13, 2007 9:07 pm
Location: The Edge of Insanity

PvPLog's Future

Postby bsmorgan » Sat Feb 16, 2008 12:36 am

At this point in time, I don't need independent testing, I need cooperative testing (i.e. all characters on the same realm, arranged duels, arranged fights, etc.)

It's pretty hard to get on the test server and ask people to duel, then ask them to wait while you fix a bug, and then ask them to duel again. Even harder is opposite faction fights... "Can you kill me now?", "Wait, I have to fix a bug", "Can I kill you now?", etc.

All of the above is possible when all the parties are working towards the same goal... making PvPLog work.

Regards,

Brad
User avatar
bsmorgan
WoW Interface Developer
WoW Interface Developer
 
Posts: 160
Joined: Tue Nov 28, 2006 10:17 pm
Location: Colorado Springs, Colorado


Return to PvPLog

Who is online

Users browsing this forum: No registered users and 0 guests

cron