Please reconsider your stance on retail/classic reward linking

Ok, we’re dealing with multiple intersecting issues here. But yes, you are correct in that jumping from a 1.12 dataset to a 8.x dataset you are going to encounter problems. Problems which have largely been addressed by the Classic WoW Devs already.

You also are correct in regards to the datafiles and some other assorted code for Classic is very likely to be unique to Classic as it doesn’t need to worry about being compatible with 8.x gameplay. This isn’t news, we’re aware of that. You’re ignoring what we were telling you because you seem to be failing to make some important connections and associations.

Retail has the code from the image cache database for the pre-1.12 (wearable) items because they remain wearable in game. THAT portion of the DB specifically needs very little attention all things considered. That 1.12 code is NOT “a mess” because it looks exactly like the code for 8.1.X items in the 8.1.x DB when you look at it from the code side. (Not to be confused with what the end user sees) Besides which, even if the above wasn’t valid, the work being done by the Classic WoW Team would ensure that a 8.x Compatible version is available to work from.

As the image database formats changed between versions of WoW, their formatting changed in the item cache along with everything else. Although you would be correct to point out some items do not have the same textures now as they did in 1.12.x, that’s fine, Retail can keep the new textures.

You only get a problem if you try to jump from 1.12 data straight into 7.x (Which the presentation talked about), or 8.x which is the current “Modern Client.” (Good odds that the Classic project is, or soon will be, on the 8.1.x code base. As I’m sure they worked out how to handle keeping the client/engine code synced between the two projects, they even seem to have (vaguely) alluded to that in the presentation. Do NOT confuse the engine with the gameplay data.)

But that only covers wearables, there also are consumables and their assorted Icons, THAT could be a lot more of a grey area, particularly after the “recipe streamlining” they did recently for the older Expansions. That just potentially made things a lot more difficult in terms of integration with Retail than it was previously.

Alternately, they just made it easier. If they completely modularlized every Expansion Tier and their professions with each Expansion being its own module. Now they just need to plug the Classic Data back in as its own “Module” for Retail and off they go on starting to implement Retro-Vanilla-in-Retail.

So short form: “Wearables” from 1.12 still exist in 8.1.x and their status is “just fine” in the item DB, making them re-obtainable isn’t going to cause any problems for Retail at all from that quarter.

Vanilla “Consumables”/crafting mats are potentially a different matter entirely, as Blizzard did forcefully removed some of those from their (player usable) DB as of 8.x and no longer exist in the player-side of the game.

Yes, but again, you’re not fully processing what you were told in the presentation, or what we’ve been saying here. The Terrain Engine had changed how it operated between 1.12 and 7.x (There probably were major formatting changes in Wrath to accomodate Phasing, and again after the Cataclysm) which meant the 7.x engine didn’t understand what the 1.12 data was telling it. So “Weird things happened.”

Weird things which the Classic Dev team has been systematically going through, identifying, and correcting. That Classic WoW Terrain Data, once it is “ready to launch,” would also be “ready to roll” on Retail as well, albeit with a few additional tweaks to certain data pointers. Mostly in regards to which “world tab”/“world server” they belong on, as Classic WoW is running them as the “Prime” locations, while Retail would be using them as a different/alternate location option–they don’t want it to over-write all their work from Cataclysm or in BfA. That particular change should be positively trivial to make, with a time to implement measured in minutes. Although Blizzard QC will make it take weeks. :wink:

The difficult part is determing how players get there. What rulesets apply to them while there. How the Game Engine is to handle players in those areas, and on and on. It is the Game Engine aspect that makes things get complicated quick.

As our preference would be that they turn up in the Retro-Vanilla-in-Retail Content as a level 1, and that they basically have to contend with the 1.X patch level talent trees, abilities, and everything else. In other words, that “Paralell use of different Mechanics” things I mentioned way up this thread.

I guess in some repects, given Classic should be its own thing. Allowing non-Vanila Race/Class combos to wander around “could be allowed,” although the Space Goats, Blood Elves, Goblins, Worgen, and Pandas(as well as the 6 newcomers) would all need “a race-change” while in that content. (Yes, that likely means Alliance Shaman and Horde Paladins for that version if they went that route)

Not sure how they’d address the Monks, Demon Hunters and Death Knights on the retail side though, other than possibly locking them out because of the cascade of changes that letting them in triggers, above and beyond anything the Shaman <-> Paladin faction crossover would trigger.

Except you’re forgetting something here: Classic WoW already moved the 1.12 data from the old 1.12 data format over to the 8.1 format. Once Classic “is done,” that work also is done. At that point they’re moving from 8.1 to 8.1. They’re not having to re-invent that particular wheel, Classic alreay did the work.

What they’re having to “re-invent” at that point is finding a way to incorporate the Classic (8.x) data into the (8.x) Retail Client (as that “Retro-Vanilla-in-Retail” concept), in a way that satisfies both Blizzard and the community at large. And that is where the zombie bears come out and start eating people while Inquistors from Spain go about conducting Inquisitions.

But as I think more about changes that seem to have happened in BfA, I think they’re already laying groundwork to possibly do something like the above. They just haven’t had a team decide to try to actually do it. I expect the next developer Team to come up “at lose ends” soon is the one working on Classic itself right now. Although I think their sights are on Classic TBC, not the monster that integrating with Live would be.

2 Likes

On further thought, should clarify on this:

If Blizzard wanted to be very lazy, they could likely intergrate “Retro-Vanilla” into Retail very quickly and with minimal effort on their part after Classic launches.

All they’d have to do is copy/clone the relevant data for Eastern Kingdoms and Kalimdor from Classic. Spawn two new entries on the world tab, give players a way to get there, and let it run with 8.x Talents/Specs/Abilities, and not care that there are level 120 players running around the place. … Or that there have been multiple Stat/Item squishes since 1.12 went live, so the gear that would be dropping there would be “inappropriate for retail” without adjustment, or the matter that the Mobs themselves would likely be absolutely lethal for “an appropriately leveled” character trying to take them on.

Edit: Yes, I did just quote myself, but that’s because I’m writing this 30+ minutes after the initial post.

[quote=“Katerina-mannoroth, post:1335, topic:22030, full:true”]

What they’re having to “re-invent” at that point is finding a way to incorporate the Classic (8.x) data into the (8.x) Retail Client (as that “Retro-Vanilla-in-Retail” concept), in a way that satisfies both Blizzard and the community at large. And that is where the zombie bears come out and start eating people while Inquistors from Spain go about conducting Inquisitions.

[/quote].

Except… They’re NOT using the “8.1, vanilla data”

They have literally said they have peeled back the code to bring us the un-edited 1.12. Which will not just be randomly compatible. Also your “retro-vanilla” idea would be a disaster. VERY VERY VERY specifically in the opening announcement they said they COULDNT do that because of how re-writing cataclsym changed the entire world data and was written over to produce cataclysm and beyond.

Also. If you took 8.1 data and tried to load it into 1.12 cache you’d probably freeze the game immediately.

Just because its USING the Legion and onwards graphics engine doesnt mean that its magically “8.1.X but vanilla”

Writing my own code for machinery, and other macro’s and the like over the years, And de-bugging and updating and re-writing those codes from scratch… even simple ones… And then bringing the concept to something as large and the depth that wow has? Yeah. Leave it for the Devs to say waht they can and cant do VS your “BuT it wIlL b So EaSy To DO!”

its really really really not.

Not only is every data value different. Its different MULTIPLE times over. Now, just randomly go over, and take un-edited bits of data from 2006 and then slap it and data from 2018 together and see how well your scripts run.

old bits don’t mix with new bits

CAN WE GET THIS LOUDER FOR THE PEOPLE IN THE BACK.

Ya know… I didnt know “code” and “data” were different things. Ya know. Code makes up data right?

I mean… But if you did know that then your entire post is absolutely meaningless.

Why speak on technical matters that you dont understand?

1 Like

They are going to be 2 separate games, lets not mix them together. And anyway its not about the longevity of classic wow its about a authentic experience for those who want it. Blizzard have already said they will keep the servers active whether there are millions playing it or only thousands

3 Likes

Code and data are not the same.

For example, Johnny’s accounting program is written in code, but when he tells it to calculate and print paychecks, it uses data (not code) to accomplish those functions.

1 Like

That’s different Fesz.

It would be an isomorphic program pulling from the two separate area’s and thus definable as a very strict Code utilizes data to produce X effect.

Where as in something that isnt isomorphic (I.E. Wow, differing between patches 1.12, and 8.1, where the data will be drastically different and not the same parallel in form or function to the 8.1 data) cannot correspond a direct Code -> data -> effect where the code for 8.1 will try to pull different data from 1.12 than exists in 8.1 and 1.12 wont know where to pull ANY data from 8.1

Now. Code and data can be written to be interchangeable with each other and extrapolate between themselves to produce more data that wasnt originally part of the data/code set it was originally given to be able to produce something as complex and in depth as wow. Your code, uses the data, to plug into new code, to run into becoming data with those values to loop back into code to continue producing the AI and interactive world of video games.

Now, to get 1.12 and 8.1 to link, you basically have to re-write 1.12 to become isomorphic to 8.1 so that they can correspond off their similar functions and produce the proper data from the code pulling from previous to current… Which… They are not doing.

I think you misunderstand me.

I am not saying that it would be as easy as some would have us believe to “recreate” vanilla within retail.

I do not think it would be at all easy to do, and I would not expect Blizzard to even try. In fact, I hope they do not.

I do, however, think that IF Blizzard decided to make unobtainable items obtainable again, that they should find a way to make them obtainable again in RETAIL and NOT use Classic as a means to do so.

1 Like

That last tidbit is all that needs to be said.

1 Like

That’s what I have been advocating this whole time :smiley:
Taking the cache data from 1.12 and directly linking to to 8.1 is terrible because of how it was updated so it cant directly be done. HOWEVER inside 8.1 is still the items data to be able to be loaded (EDITED DATA, NOT JUST RAW VANILLA DATA FOR THE ITEMS)

So literally all that needs to be done is inside 8.1 take the new data and then link it to BMAH or something and decrease the spawn length and then it will be part of the game. The problem is, is these people thinking that we can just magically take code from 12, 14 years ago and have it magically plug into something that’s 7 expansions and 13 years out of date? To just add things from TWO separate programs (it will NOT be the same thing, not even freaking close) and then hope that Program A takes from program B that isnt compatible with Program A and cross your fingers that the static data from program B isnt going to crash program A or give it a corrupted file because it couldnt read?
That will either blow the WoW servers up or make them take another 2-3 years to give us classic.

1 Like

So go ask for that on general discussion where it belongs. Not here. Less confusion that way.

1 Like

I have been on your side fighting against the “JUST GIVE IT TO ME ON LIVE CUZ I GOT IT ON CLASSIC” crowd Matc :smiley:

Never once have I said “please let me do this”

I’ve been very very outspoken about linking classic and Livetime

1 Like

I know. I’m just saying in general. Not you. Those who want the old school stuff in retail? Go ask for it in retail forums.

3 Likes

Agreed.

This whole thread got beyond ridiculous many days ago.
The CE pets are one thing. Ys said he would look into that, so fair enough. The rest of it, though? The answer was a firm “no” for obtaining it in Classic, so the next step for you guys is to ask for ways over in GD to get your stuff in the modern game.
Make noise there.

2 Likes

Yeah other than the CE pets being looked into, everything else is a firm “no”.

1 Like

Ok, going back to the BlizzCon panel on building Classic.

  1. They have a 1.12 “Reference Client” built from the 1.12 code repo.
  2. They have the 1.12 data and art assets.
  3. They have been working on making the 1.12 data and art assets function “in the Modern Client” in such a manner as to provide an experience consistent with the 1.12 Reference Client.

Yes “the data is sacred” but it isn’t untouchable. Obviously so, or they’d need to have changed the engine to accept 1.12 data, rather that change the 1.12 data to be accepted by the current Engine.

If the reference client and the Engine come up with conflicting results, the first place they go for resolving the issue is the data. This was demonstrated with the Purple Lights(where purple is the modern engine’s error indication), while in Vanilla the error indication gave a white light. Their solution? Change the data so the light from that lamp was white, as the cause for the error was caused by no color having been specified in the original code.

Practically every single example they cited involved data manipulation, not changes to code on the engine. And as to where changes to code on the Engine are concerned. If they’re being smart, they turned the impacted sections into “plug and play modules”(functions) between the two versions of the game, as it makes the code easier to manage for all involved.

Which would be where the “throw-away comment” during the one panel about their having the ability to work on multiple projects with the same codebase in paralell didn’t exist until recently comes into play.

If if has already been modularized, a LOT of the work for allowing “paralell rule sets” has been done already, they “just”(and I know how deceptive that can be in programming parlance. Seemingly easy tasks are very hard, while seemingly hard tasks turn out to be mind-bendingly simple), need to insert some additional code to allow for “module swapping” from within the client/server interactions, rather than have the swap be something which happens at compile. That’s a rather significant change, even if all of the needed hooks exist already.

Eastern Kingdoms and Kalimdor exist entirely as data, data which WoW Classic is bringing up to Modern Engine Spec. Ergo, that data is usable by the Modern Engine, which means “retail” can use that Data.

Now that Data DOES hook into a legion of scripts and other “high level” code(which the engine interprets) as opposed to the low level code. But again, this runs us back to the Classic WoW Devs are having to go through and make sure the 1.12 data/scripts are altered so that they can be understood by the Modern Engine. In other words: “The work is being done already.”

If Blizzard’s code for WoW isn’t a giant Spaghetti Monster, re-adding the two Vanilla Continents(as new entities), should be about as involved as loading a (well made) custom map mod into Quake 3. They’re not manipulating the engine, they’re manipulating the data.

That isn’t to say everything is flowers from there, as that is only part of the battle for the WoW Devs, as those continents are a LOT more involved than a Quake 3 Mod/custom map. Content “tuned for Classic” that is simply dropped into Retail with no additional work done would be a train wreck for numerous reasons. Up to and including scripts and numerous other things breaking because while the Classic Data can be understood by the Modern Engine. That doesn’t mean that everything in Classic would be understood by the Modern Engine when lensed through the Modern Client’s data. (“What do you mean this NPC is casting ‘Heal Rank 2’?”)

Which is why QA would likely be spending weeks/months going over everything, and that’s just letting 120’s roam across the place under Retail’s rules. Going even further in “tailoring” those Retro-zones for Retail adds even more time to the equation.

Uh, except they are? The 1.12 data is being changed so it is understood by the Modern Client, and so it presents itself in the “authentic” manner it would have presented in 1.12.

Once the Classic Devs are done, there will be no “1.12 data” there will be “Modern Data” which represents the 1.12 data in as authentic a manner as is reasonably possible in the Modern Client.

Now yes, there are a number of technical differences which will still stand between Classic and Retail, but mostly the differences lie in what gets turned off or on with regards to the modern engine, and which specific set of data gets used in terms of spells, abilities, and art assets.

As it stands, there is no need or reason for Retail to hold the old art assets, or for it to hold the data about the old talent trees and abilities. But there is a difference between “no reason” and “no ability” to do so, and Classic is addressing part of the “no ability” aspect of it, in that it is bringing 1.12 up to the standards of the Modern Client.

The last piece in the puzzle is working out how it would either be merged into one another, or otherwise allowed to exist as their own things side by side.

2 Likes

I can’t help but notice you have a helmet on now. You didn’t always, did you?