Please address the "reference clients" validity

From the very beginning, the goal was about bringing a classic experience that is as close to the reference client as possible but also fixing minor things that WERE exploits, bugs, etc. from vanilla.

There was several changes back in the beta that were #somechanges because it was borderline exploit or an actual exploit. Other things that match the reference client but didn’t make any sense were slightly adjusted or fixed. Classic as a whole has undergone a MASSIVE amount of changes that all haven’t necessarily been #referenceclient. They ultimately decide what stays and what goes. I don’t see this being any different. You can come up with some fallacies of why you think the reference client isn’t real, but you know deep down that it is. If you don’t, then you’ve just not paid attention to some of the mechanics of the game that has been discovered over the course of the last year.

Bottom line, if it’s a bug from vanilla the dev team decides whether it is important enough to fix it or not. Runeblade and this were important enough. That’s just 2 examples. There was an entire changelog from the beta that covered a massive amount of changes that the players documented, not to mention all of the changes undocumented as well.

Their is no reason they need to lie about the changes. They shouldn’t say that the reference client has it one way and then retcon the statement later. Blizzard likes to retcon. We all knew this going in. We just didn’t think they would retcon their own honesty.

As he said, they used the reference client as a cloak for the change rather than coming right out and saying that for the health of the game they were changing them.

1 Like

This would be interesting to dive into.

What does this mean? What is “it?” in this context?


This is an incredibly interesting statement.

What do you think “The Classic meta” means… ???

And thank you for making me smile :smiley:

Thanks for your constructive input. For those that have been derailed:

Blizzard said that enchantments from items such as arcanums were staying as helpful buffs and not being moved to the passive category. In this way they still occupy part of the buff limit. Which is how the reference client classified them. Now with the ZG enchants being released we have just learned from blizzard that the reference client classified them as passive buffs so that they don’t count toward the buff limit.

The OP is asking for a clarification for the inconsistency in the use of justification through reference client authority.

This is minus the fluff that some people ^^ just can’t help using to try and remove the legitimacy of the OP asking this question so that it won’t be answered.


This seems like a blatant contradiction!

Do we have references to the points made?


a.) Blizzard said that enchantments from items such as arcanums were staying as helpful buffs and not being moved to the passive category.

b.) Now with the ZG enchants being released we have just learned from blizzard that the reference client classified them as passive buffs so that they don’t count toward the buff limit.

If we could show that both a.) and b.) are accurate, then we could verify that this contradiction is indeed a contradiction.

(at least, I think that makes sense - do we have something we can point to to support this information?)

The OP has the quoted threads in the OP.

1 Like

Would you be so kind as to point to precisely what you are responding to?

i.e. are you suggesting that:

Is answered? (then answer it - by simply quoting the OP)

What seems to be the issue is similar things work completely differently. Which is certainly possible but the coding must be terrible is that’s the case (which may be true for vanilla era coding all things considered). Normally similar effects work the same for consistency.

Look at Runeblade vs Diamond Flask. If one doesn’t benefit from snapshotting hps, neither should. Yet we have a statement that the “reference client” shows Diamond Flask does while Runeblade does not and this is intended behavior. Sounds suspicious yet plausible but casts doubt on the validity of the client due to how absurd it seems.

1 Like

except blizzard doing 'what activision thinks is best" gave us retail…

Let’s not mince words here until relatively recently this was not nearly as bad a thing as everyone whined about.

Read the original post. Or are you instigating with off the wall questions on purpose? Blizzard posted that in the reference client the enchants WERE counted as buff slots. Then they later posted that in the reference client the same enchants WERE NOT counted as buff slots, contradicting themselves on what the true behavior should be.

1 Like

I dont think the ref client cares about classic meta?

Well one reason is that it does not run right on some PC’s
Does not work on mine, neither does 1.1 out of the retail box.
Cant identify the video card and crashes.

The ref client by the way, is a version of WoW we had for like 2 months
I dont suppose it is impossible that an issue could have been induced in said version.
No source exists though to build a ref client from an earlier version, say 1.5 or 1.9 to compare against.

So if they run into something that makes no sense in it’s functionality or conflicts with similar logic in the original source, i guess they have to make a judgement call?

The meta comment was about Blizzard, not the reference client. Originally, Blizzard had told the entire community that in the reference client these buffs were part of the buff cap only to now claim the reference client doesn’t count them towards the buff cap.

The assumption here is that Blizz, per their post, understands that the meta is very much different than Vanilla and enjoys the buff stacking of enchants and wbuffs.

Thus, Blizzard potentially removed the buff cap of the Arcanums in light of this meta shift from what they had originally thought Classic would be, i.e. they didn’t understand the private server meta before they launched and still didn’t understand it when they had originally addressed the issue.

It seems rather obvious to me at least that the “reference client” is not a reliable source. I suppose they can try and weasel themselves out of it saying that they were misinformed from the Developer Team, but it still doesn’t explain other misses such as Runeblade, Guardians, etc.

1 Like

Arcanums dont really make logical sense to apply to a buffcap.

They are a portable enchant (kind of like buying a vellum in later WoW)
The have no duration, do not expire, they are a perm modification, just like a chanter putting +55 heal on a weapon or +5 stats on a chest piece.
It becomes innate.

It kind of makes no logical sense for them to even appear as a “buff”
or technically be visible at all really.

Now other things do, things that expire and have durations.
Eating food, sharpening weapons, things we consume for a temp boost.
Those at least make sense as they never become an innate thing.

I can not actually remember how they were working that far back
my memory of that only goes back to after the fact.

The comparison of diamond flask and runeblade doesn’t really hold up as Lifestone has the exact same effect too and it never scaled. The real issue is that blizzard either changed the runeblade with the TBC pre-patch or it always scaled. The most likely option is that it always scaled, especially because lifestone wasn’t changed either.

1 Like

Yea, we knew it continued to scale even into WoTLK:

The life regen upon equiping seems to be 30hp5 increased by ~100% of your spellpower
On my ret pala it’s ticking well over 1.5k hp every 5 seconds, which makes it awesome for passive healing, should you ever need that

Either the reference client itself is bugged or Blizzard is straight up falsifying their reports. I mean. They have used TBC values for other items such as Skull of Impending Doom in Classic as well. So we know they’re fudging around with the data they’re sharing.

I’d love for a response on clarifying their contradictions. It’s troubling that they continue to use the “reference client” as a shield when we’ve caught them red handed on a few occasions. I’m not even asking for them to admit that they’re dropping the ball, but that’d be big of them if they did so.

1 Like

That’s not really what they said.

They first said they weren’t removing the hidden buff auras from the arcanums. They mentioned it was like this in 1.12.

Months later they say that they missed some previous enchantments that could (keyword is could) be flagged to avoid consuming buff slots.

This doesn’t mean that it’s still not like that in the reference client. It means they’ve loosened up their “No-changes” stance on the buff cap a bit because players are getting really ticked off at how stupid it is.

Blizzard is awful at communicating and I don’t know if they’ll clarify this.

Yep, that’s why I mentioned above that they should have designed Classic with their own vision in mind. Not restricting themselves to some vague and broken version of the game that has inherent issues in itself to validate whether something did or didn’t work as it did back in Vanilla. I.e. A “fun” server much akin to Nostalrius and Kronos.

There are reasons those servers were a blast to play on versus Classic…

1 Like

I’m not sure I understand your point. They stated a long time ago Arcanums were counting as buffs, and while they didn’t specifically say they would fix it, they did fix other enchantments along those lines. So they never contradicted themselves, they even mentioned it in the fix that it WAS counting as buffs in the reference client. This was considered a bug, and therefore fixed along with the ZG ones.

Probably looked at it and said, umm anyone know why we did it that way? it kind of defies logic, did we flub it up then?

When is an enchant not an enchant? When it is a buff…
…except it’s an enchant, except now it’s a buff, ANYONE GOT EXCEDRIN?

Probably what happens when you ask a CM to go ask a thing and then translate what a coder or scripter said.

Go ask an engineer for an answer, without a technical writer handy, that’s always fun to be on the receiving end.

1 Like