[Note: this is a thread split. The quotes are from the Omen thread; since the unique identifiers Marroc refers to won't be usable in threatmeters, it seems like a bad idea to keep the topic in that thread. Also I'd be interested to hear any other reports from the panel, so. But tell me if I'm screwing up, oh mighty mods.]

That got my attention too. Apparently it's only for reporting, however. See this thread.

Any other reports from the panel? The news sites seem to have all decided to go to the Starcraft II panel instead, understandably.

From what I remember:

Unique identifiers for all mobs(even with the same name), pets and players.

"threatmeter" integration of some sort, likely a very toned down version of what is currently out, they mentioned a "green, yellow, red" type of integration.

Boss Mod integration - some sort of bar system that's similar to what's currently in place via the boss mods(vendetta/bigwigs)

Outfitter like mod - but with their ability to "we have the advantage since we have the power to give you some place to put the gear" - or something like that

No more character slots.

Guild Banking - nothing new

[edit]

I knew that I had forgotten a bit, here's one more.

Guild event/calendars were hinted at as something to assist with raid formation.[/edit]

A bit of it was over my head, and I can't quite remember at the moment. The initial discussion was a "how-to" on making a mod, the afterward Q&A was where a lot of information was covered. I'm sure that there are a few other people that picked up on more of the information then I did, and hopefully someone will post it up since I was being bombarded with too much information at that point in the day.

Just to clarify: They WILL be usable in threat meters. They can be gotten for any mob in the game, they just can't be returned to targeting functions later on. That means ALL reporting addons (damage meters, threat meters, etc.) can take advantage of them for tracking data, you just can't turn around later and go "target mob 183342".

Absolutely correct, the GUIDs are coming along with the combat log revamp in 2.4, and its intentional that you can use them for reporting and data calculations.

... yeah, I'm a numbskull. That makes sense and is super-awesome.

Tell me more of this combat log revamp in 2.4?

Meh, I wouldn't say most of the information was there, and there were plenty of us who were there and can answer any questions that get asked :P

Was referring to the video I linked, which is the only one I know of for the UI Panel. It cuts out the later part of the discussion and the QA panel, which is where most of the information was (the video just covers the addon example, and a few other things).

Understood, I was there and can answer anything else people want :P

The only problem is we can't really ask questions without knowing what was said =P

On that note, what were some of the "highlights" of the Q&A?

UI Highlights:

* There will be a spell casting revamp that allows you to start casting a spell on the client, and it will be validated on the server side of things. Right now, when you are casting a spell, a message is sent to the server and the client "locks" the spellcasting. Until the server comes back and says "okay, spellcast successful" it won't let you start casting the next spell. This is why the /stopcasting macros that speed up your casting work. This will no longer be necessary due to these changes.

* Scheduled for 2.4, we'll have a new combat log revamp which brings a number of important things to us, including GUIDS for every single combat actor in the game. This includes pets, NPCs and every single player character acting in combat.

* Along with this comes a change to the visual style of the combat log, looking much like Simple Combat Log, with the [You] hit [Doomwalker] for 15 (Fire) type messages. These messages will be filterable (i.e. only show me the messages involving this actor.) including combat history.

* Instead of sending each combat log message as a CHAT_MSG event, they are sent as their own distinct combat events, with arguments. This means no parsing is necessary, whatsoever. This makes damage and stat meters very nice and easy to make.

The Q&A didn't have much "information" given out, and if you ask any questions about the R&D panel (i.e. the DBM or KTM part) then I'll do my best to answer them. Beladona has posted a good wrapup with screenshots here: WoWInterface - View Single Post - Blizzcon 2007 Wrapup.

Nope, it's basically a "request" from the encounter team, that hasn't had any work done in the UI side of things. If I had to guess, I'd say they'll likely give us a timer for something like Gruul's Grow, or other consistently timed events that are 100% obvious after the first run of an encounter. The end implementation may end up looking quite different-- but that's the impression I got.

I can also see those in-built timers being used for abilities that are inappropriate to give in-game yells for, which nevertheless can make or break your ability to do the encounter without some kind of timer. I'm looking at you Chromaggus.

Yep.

Think about it from this perspective.. the designers want an encounter to still be difficult, but if there are certain things that every single raid guild requires in order to make something work. It then makes the execution of the strategy the hard part.. not the downloading or getting a mod to run the encounter.

Didn't Blizzard specifically say that they would not implement a threat meter?

They said they won't give direct access to exact threat values, and i'm certain they won't give that.

Indeed. It's really the only thing holding down threat meters from being almost perfect now. That and the inability to tell when certain things happen. Luckily for us, that's fixed from the combat log changes in 2.4 from what i've been hearing (combat log becoming a filtered list of events rather than just a local chat box).

This is somewhat off-topic, but how accurate are KTM and Omen (or i suppose Threat) at this moment? Would it really be that big of an increase in accuracy for us to get the actual values?

Their relative threat values are pretty damn accurate, so no, getting the raw values wouldn't be that much more useful.

For a reason why we won't get the raw values (in my opinion), consider the first time a raid does an encounter that has an aggro reducing ability. If you can poll the threat values, the first run through a fight will completely reveal any aggro reducing abilities-- completely trivializing that portion of the encounter. I doubt they'll want to implement support for something in the API which completely trivializes something that currently needs to be experienced and adapted to.

Or a construction kit. An method to define triggers (based on combat log events) and timers shouldn't be too complex, and wouldn't trivialize anything. This is not speculation, just noting that there are a few ways to fulfill the rather loose spec.

The accuracy will come from the unique IDs of the mobs - Omen will now be able to accurately display AoE threat among other things.

The hilarity of it is that KTM will need to be completely rewritten, where ThreatLib and Omen change like 2 functions ^_^ Ah well thought out code, it's a beautiful thing.