easiest fix give DK if they kill anyone lower.
This is the nonsense that has me defending spy all day long. These are the kinds of changes that will have dramatic impact upon other addons that have nothing to do with spy.
I have not looked into the API to see for myself but I am certain this falls into the “why we went with the modern infrastructure” department.
The API is not vanilla. The Client (combat log) is not vanilla.
Yes… a change is being suggested. The amount of time it has remained unchanged is irrelevant to discussion about how hard it would be to implement.
So… what’s your point with this statement?
No new variables would be added. Some data simply wouldn’t be presented in the combat log.
You can sigh all you want, but neither of the options I mentioned require overhauling the API or breaking all addons.
Look, you can say that Blizzard SHOULDN’T break spy addons, but pretending they CAN’T break spy addons is silly. There are plenty of ways they could approach it… if they want to.
You could pull all the same data. It was just all individually bundled into CHAT_EVENT_Variable_Variable. The Combat Log still existed, but it was more of a big messy chat box, but the same underlying information was present and it absolutely was part of Vanilla.
Not to mention they specifically limited the events available to us for Classic, which is why we can’t access the Threat API, or SpellID, etc.
1 Like
People are asking them to further limit the events.
I’m not arguing they should, but they definitely could do that with minimal disruption to other addons.
The combat log was built to be an open dump of information, with Blizzard’s support and blessing for addon creators to go buck wild. It has been built up and supported in this fashion for 15 years. If you think that has zero bearing on how difficult it would be to redesign the combat log to perform contrary to its initial and present-day design purpose… I don’t know what else to say.
That’s just silly.
The state of being “in combat” doesn’t keep track of whether someone is in combat with you, a mob, another player, etc. The game isn’t tracking independent groups of people connected by combat, it simply knows whether an entity is in or out of combat, that’s it.
/heavy-sigh
Then you’re asking for the addons to be broken because the API call that would need protecting would be the one and only call any of these addons uses.
Not sure you followed what I am saying.
The API in Classic and the combat log in Classic are reworked 8.x versions. They are not 1.x versions.
And you’re not understanding what I’m saying.
The old CHAT_EVENT calls pulled the same information for entities as we are getting now with COMBAT_LOG_EVENT_UNFILTERED, minus parameters that didn’t exist in Vanilla like SpellID.
Y’all are quibbling over the difference between a Ford and a Chevy when the actual meat of the situation is that both have a working engine, four tires, and the ability to be driven on the road.
This is the part that is making things hard to follow.
I read your post (where this quote came from) as you saying the API predates this 2.4 overhaul
You pointed out earlier that it’s already limited for classic.
If they can limit the events that addons see, then it doesn’t require a redesign in the first place.
I never suggested determining if a player is in combat with you… HOWEVER…
If you’re saying it isn’t possible to determine if a player is in combat with you, you’re being deliberately obtuse. It doesn’t take much imagination to come up with schemes that allow the game to determine this.
OR instead of determining if the players are in combat with each other you could use a simpler check. For example: If one or more of the players are out of combat and the players are on opposing factions, don’t show the event.
You can sigh all you want, but neither of the options I mentioned require overhauling the API or breaking all addons.
You don’t need to change the API call. You only need to limit what’s being returned.
People are asking for Blizz to limit what events are being returned.
The fact that they’re already doing that indicates that they can do so without overhauling the entire combat log or API.
Yes. They made big updates to the Combat Log to make it all cleaner and even more accessible, but we were already accessing all of these things in Vanilla and TBC. That’s how Recount works.
That’s also how the very first iteration of Spy, something called SentryGizmo or similar, worked, and that was early Vanilla, like super early. Same thing with the first iteration of Spell Alert.
The only difference between today and then is we can call a single API instead of dozens to get the same info.
Yes. Events associated with vehicles, facing directions, map functions, etc, that are associated with later baseline updates to the game have been culled. Some because they’d just clutter things up and would do nothing if called. Others because despite not being full supported in a Vanilla world would still give players access to info they never had 15 years ago.
The event in question is this:
COMBAT_LOG_EVENT_UNFILTERED
If this is hidden, hundreds of addons break overnight with no work around.
The 3rd Parameter of the above API call is a TRUE/FALSE check called “hideCaster”. This only applies if other events set this to be true, and the list of those events can be seen here:
https://wow.gamepedia.com/COMBAT_LOG_EVENT_UNFILTERED
That is why when a Rogue enters Stealth, the event of applying that aura shows up, but renders all subsequent events hidden provided the aura remains.
So as the Combat Log is currently built, to make it faction specific, each faction member would have some sort of race/faction specific aura, hidden from the default Combat Log, but itself visible when it applies or doesn’t apply, and dropping off once a combat related action is initiated, triggering the log just like auras fading do right now. Since the aura would be persistent otherwise, we could just change Spy to track for it specifically existing and ping results of nearby enemy.
Hiding parameters are done in a totality fashion, not an if-then fashion. SpellID isn’t checked for to see if you have permission to see it, the parameter is simply protected outright.
Gotcha, following.
Now the next question would how do we know that Blizzard does not delineate faction on their end. Do we know that the API isn’t setup to do this but hasn’t been exposed for the API.
Would make sense that Blizzard already parses the data by faction.
Don’t think I would be willing to say it would take an over haul when it could be a slight tuning.
Not that I am saying they should do anything at all.
Calls to opposing faction events could fairly trivially be restricted. I keep seeing people make this statement about how difficult it would be, but I highly doubt it. Also, transparency/automation is great up until it ruins the game.
It is tied up with your unitID, unitFlag, and your GUID. That’s how the information can be filtered on your end, by setting these sub-categories to hide or show based upon whether the target is hostile, or alive, or w/e. There are actually a LOT of bits of info related to this that most wouldn’t find a use for normally, but addon users can have a field day using them.
https://wow.gamepedia.com/UnitFlag
If you can look at a unit, you can see all of this.
Event parameters are separate from source and destination and a host of others. That’s how you can get odd things like seeing a spell go out, but only get Unknown or nil as the “caster”
As it turns out, I can save you some time. See, neither of these things are “problems” that Blizzard needs to “solve.”
So, there you go. Hopefully that helps you understand things from a different perspective.
Huh, interesting. Doesn’t that mean that any event source with an enemy player source could be restricted to unknown? It wouldn’t break Spy per se, but it would definitely make it a whole lot less “broken”. You’d only know that there was a player, maybe, if it wasn’t failing to receive a mob source, etc.
Culled or filtered. AFAIK, we’re not sure if they’re still being sent (from the server) at all.
Nobody is suggesting hiding ALL of the events. They’re essentially suggesting that COMBAT_LOG_EVENT_UNFILTERED not trigger for certain events.
I don’t understand what is so hard to understand about this.
Yea and I’m saying you don’t even send that event in the first place.
I’m not suggesting that parameters be hidden, though. I’m suggesting that events be hidden.
I think he’s saying that the source of the event and the event itself are untethered to preserve responsiveness.