Is there a way to programmatically determine if a client is running retail, classic, or tbc?
Needed for my many macros project (which is coming along pretty well).
/run print(WOW_PROJECT_ID == WOW_PROJECT_MAINLINE and "Retail" or WOW_PROJECT_ID == WOW_PROJECT_BURNING_CRUSADE_CLASSIC and "TBC" or WOW_PROJECT_ID == WOW_PROJECT_CLASSIC and "Vanilla" or "I don't know")
Very nice.
I was looking at maybe having to parse the first field from GetBuildInfo() but that’s much better.
Where on EARTH did you find those?
Followup question.
Where the file path has _retail_, what do Classic and TBC have?
People smarter then me unpacked the project id info when it was introduced.
Vanilla = _classic_era_
TBC = _classic_
Nice. I’d never have guessed that.
I guess “classic” and “tbc” was too complicated for them, right?
What happens to TBC when it’s not longer _classic_?
At least you can have more than one .toc for the different versions in the same addon.
I know, right?
I would have thought “classic” then “tbc” then whatever next one they do.
Blizzard’s motto: Inconsistency is better than no consistency at all.
1 Like
They should have named it classic_new. Then the next one could be classic_new_new.
This is a running joke at my job…
Hahahah.
I’ve actually had to maintain code in mainframe systems that did something very similar.
The shortsightedness of some people…
1 Like
I’ve written my share of COBOL.
I was writing BASIC in the mid 80s as a kid, but I am old enough to have made a bunch of the Y2K changes. If I never read another line of RPG, it will be too soon. We’re talking pre-ILE, so reusing indicators a dozen time was commonplace. These guys using a GUI to “code” have no idea… 
Yup.
I think when I was first using it, there were something like 8 verbs.
ADD, SUBTRACT, MULTIPLY, DIVIDE, MOVE, OPEN, CLOSE, TRANSFORM, maybe one or two others (we’re talking IBM Cobol 1.0).
We ran the world on that.
It’s hard to get across to the younger generations that coding is not the skill.
Design is, and not web design. Data structure, data relationships, converting business rules to algorithms. That’s the hard stuff.
Being good at that was why I billed out at $450 an hour at my peak as a consultant.
The FOTM language out there?
Pffft.
My boss that taught me at the time used to say “Syntax is easy. The business is hard”
BTW - I lead a team of Data Architects now. I am constantly trying to explain to people why it is not a good idea to create one flat table with 600 fields in it. I don’t care how easy that makes your SQL.
OMG.
Yeah.
Normalize the data.
Build views for business rules.
1 Like