4.1 COMBAT_LOG_EVENT_UNFILTER changed

- Technical Support
90 Human Warrior
18100
there is a new boolean arg at 5 which pushed everything else over. this will require a lot of mod updates for 4.1.

1 table
2 combat log event unfilt
3 12........ number
4 unit_died string
5 true boolean
6 0x00000....... string
7 nil nil
8 -2147483648 number
9 0xF string
10 small frog string
11 2600 number

the event is called "hideCaster" for the boolean

if ( sourceString == "" and not hideCaster ) then sourceString = UNKNOWN; end
Reply Quote
85 Human Death Knight
ONE
4725
Bump, this is probably what's causing all this crazyness over on the PTR :[
Reply Quote
85 Worgen Hunter
5730
<3
Edited by Dandraffbal on 4/26/2011 1:24 PM PDT
Reply Quote
85 Goblin Shaman
12230
As per wowinterface:
4.0.6
COMBAT_LOG_EVENT_UNFILTERED(timestamp, event, sourceGUID, sourceName, sourceFlags, destGUID, destName, destFlags, ...)

4.1
COMBAT_LOG_EVENT_UNFILTERED(timestamp, event, hideCaster, sourceGUID, sourceName, sourceFlags, destGUID, destName, destFlags, ...)


What exactly is the hideCaster flag? What can it be used for?
Reply Quote
Looked for a post on this change for days.

Thanks for finding the info.
Reply Quote
85 Blood Elf Priest
7120
4.1 is out! Bumping this because this is important information that not too many people knew about. (What I should say is, this is part of the reason you need to update a lot of your addons this patch).
Reply Quote
74 Worgen Warrior
500
Wowza! Talk about Blizz dropping the ball on this one. System design 101: add new stuff to the END of a parameter list.

No0b programmer mistake? Or part of an evil scheme to purge the land of Add-Ons?

/don TinFoilHat
Reply Quote
85 Blood Elf Priest
7120
Warning: Speculation Below
I think they did it this way to clean up some of the addons where the developers moved on.
Reply Quote
90 Draenei Shaman
13455
Wowza! Talk about Blizz dropping the ball on this one. System design 101: add new stuff to the END of a parameter list.

No0b programmer mistake? Or part of an evil scheme to purge the land of Add-Ons?

/don TinFoilHat


Blizzard has done this sort of thing before. They code the UI for their convenience, not ours.
Edited by Unkle on 4/26/2011 3:50 PM PDT
Reply Quote
90 Draenei Shaman
9660
Wowza! Talk about Blizz dropping the ball on this one. System design 101: add new stuff to the END of a parameter list.

No0b programmer mistake? Or part of an evil scheme to purge the land of Add-Ons?

/don TinFoilHat


The "COMBAT_LOG_EVENT_UNFILTERED" event has 2 sets of parameters. One that is passed for every event (frame handle, timestamp, combat log event name, hide caster flag) and one that changes depending on the type of combat log event. Had Blizzard added the flag after both parameter sets, it's offset would not be consistent and finding the flag would incur significant performance penalties.

Lifetime of sub-optimal performance vs. +1% nerd rage on forums for 2 days.

I'm partial to the latter.
Edited by Naidi on 4/26/2011 2:38 PM PDT
Reply Quote
85 Blood Elf Priest
7120
Lifetime of sub-optimal performance vs. +1% nerd rage on forums for 2 days.

I'm partial to the latter.


This is actually true. If Blizzard was to add it to the end, you would have events that get called like this:

event(self, eventName, sourceguid, sourcename , nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, hidecaster)

As you can see, this is less optimal. You could say its a short coming of Lua, but I love how it deals with parameters.
Reply Quote
90 Blood Elf Rogue
15085
This is actually true. If Blizzard was to add it to the end, you would have events that get called like this:


What are you talking about? The API, which had 8 parameters, was this:

timestamp, event, sourceGUID, sourceName, sourceFlags, destGUID, destName, destFlags

in 4.1 they SHOULD have added hideCaster at the end to this

timestamp, event, sourceGUID, sourceName, sourceFlags, destGUID, destName, destFlags, hideCaster

And as it has been said, it's one of the early things you learn is software design, always add the end, especially in an environment where parameters are not all required. If parameters were passed by name, then the order wouldn't matter.
Reply Quote
86 Tauren Warrior
9510
What are you talking about? The API, which had 8 parameters, was this:

timestamp, event, sourceGUID, sourceName, sourceFlags, destGUID, destName, destFlags
'


event (the 2nd param) was the event that triggered the CLEU, and depending on the event had differe params after the 8th one... so even adding hideCaster to the 9th slot (after destFlags) then pretty much all CLEUs would have to be changed anyways, so might as well put it where they want

edit::

your addon might require only the source vs the dest info, but 90% of all other CLEU using addons need some information off the event, thus no matter where they put the new param within the first set of 8 (now 9), those addons will have to change accordingly
Edited by Xubera on 4/26/2011 3:59 PM PDT
Reply Quote
Community Manager
Gonna sticky this thread for a bit so authors are aware.

Wowza! Talk about Blizz dropping the ball on this one. System design 101: add new stuff to the END of a parameter list.

No0b programmer mistake? Or part of an evil scheme to purge the land of Add-Ons?

/don TinFoilHat


The "COMBAT_LOG_EVENT_UNFILTERED" event has 2 sets of parameters. One that is passed for every event (frame handle, timestamp, combat log event name, hide caster flag) and one that changes depending on the type of combat log event. Had Blizzard added the flag after both parameter sets, it's offset would not be consistent and finding the flag would incur significant performance penalties.

Lifetime of sub-optimal performance vs. +1% nerd rage on forums for 2 days.

I'm partial to the latter.
Reply Quote
85 Blood Elf Priest
7120
04/26/2011 03:49 PMPosted by Kilryte
it has been said, it's one of the early things you learn is software design, always add the end, especially in an environment where parameters are not all required. If parameters were passed by name, then the order wouldn't matter.



Not in Lua.

Plus there are more arguments then that depending on the event :P!


Edit: Thanks Bash! Nice to see a Blue 'round these parts :D lol
Edited by Dandruff on 4/26/2011 4:04 PM PDT
Reply Quote
85 Blood Elf Paladin
7710
Lifetime of sub-optimal performance vs. +1% nerd rage on forums for 2 days.

I'm partial to the latter.


This is actually true. If Blizzard was to add it to the end, you would have events that get called like this:

event(self, eventName, sourceguid, sourcename , nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, hidecaster)

As you can see, this is less optimal. You could say its a short coming of Lua, but I love how it deals with parameters.


I program in other languages, so my curiosity has gotten the better of me.

I'm not that familiar with LUA, but I'm going to assume the reason is that LUA is setup so you can create a function with optional parameters? And hideCaster isn't an optional parameter?
Reply Quote
90 Draenei Shaman
9660
I program in other languages, so my curiosity has gotten the better of me.

I'm not that familiar with LUA, but I'm going to assume the reason is that LUA is setup so you can create a function with optional parameters? And hideCaster isn't an optional parameter?


It's not that parameters are optional but that parameters are passed by index.

function Foo(arg1, arg2, arg3, etc)
end


Think of a function call as putting items in a stack or a crate. The first item that goes in the stack will be the last item that comes out and the last item in will be the first item out. It's a standard FILO (First In, Last Out) stack. It's similar to how function calls work in other languages. The major differences are no type sanity is performed at parse/compile time; if you pass 15 parameters to a function expecting 3, the last 12 parameters just wont be used and you wont be told that they are unused; and the name of a variable or parameter in the function declaration makes no difference in how the parameters are moved off the stack. Only the order of parameters in the call and in the declaration matter for Lua function calls.

Since hideCaster was stuck at index 3, the indices of everything else was shifted by 1.
Reply Quote
85 Troll Mage
12470
02/26/2011 01:51 PMPosted by Omegal
there is a new boolean arg at 5 which pushed everything else over. this will require a lot of mod updates for 4.1.

It was actually very easy to make mods forward-compatible between 4.0.6 and 4.1. Mine were a month ago.

The real cause for so many mods breaking on patch day is a bug in Character Copy to PTR. Any account in Cataclysm Beta can't copy characters, not real characters or premades: nothing. And most addon authors were in Cataclysm Beta! So almost no author can get a high-level character on the PTR, which greatly discouraged testing. I created a level 1 and did it anyway, but not everyone did. This will continue to be a problem in 4.2, and the foreseeable future, as long as addon authors suffer this roadblock to testing. (I'm not complaining; I assume it's difficult to fix. But everyone should be aware of the consequences.)
Reply Quote

Please report any Code of Conduct violations, including:

Threats of violence. We take these seriously and will alert the proper authorities.

Posts containing personal information about other players. This includes physical addresses, e-mail addresses, phone numbers, and inappropriate photos and/or videos.

Harassing or discriminatory language. This will not be tolerated.

Forums Code of Conduct

Report Post # written by

Reason
Explain (256 characters max)
Submit Cancel

Reported!

[Close]