• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

Stop the CASC madness

Status
Not open for further replies.
Level 7
Joined
May 30, 2013
Messages
210
Simple thread, as the title says.
Stop this asinine CASC madness that's coming with 1.30, please revert to the tried-and-true MPQ format and start using war3patch.mpq again (keep war3.mpq and war3x.mpq contents identical through the patches to not have the patcher redownload the entire client), don't make all the modders and their tools rely on old patches (even more).

Thank you.
 

Chaosy

Tutorial Reviewer
Level 40
Joined
Jun 9, 2011
Messages
13,182
Can't you bypass this by just putting the .mpq files in your 1.30 directory manually.
Textures are not updated anyway so you can just bring a copy over from 1.24 or something.
I still have a second warcraft 3 installation to access some JNGP features so for me this would not be a problem.

Same for others, probably.

Modders always find a way.
 
  • Like
Reactions: pyf

deepstrasz

Map Reviewer
Level 68
Joined
Jun 4, 2009
Messages
18,706
Can't you bypass this by just putting the .mpq files in your 1.30 directory manually.
Textures are not updated anyway so you can just bring a copy over from 1.24 or something.
I still have a second warcraft 3 installation to access some JNGP features so for me this would not be a problem.
I think the idea is to be able to mod the game on whichever patch version it is not be forced to keep older versions which over time might not be compatible with newer versions.
 
Where I see the issue is that new people wouldn't be able to join the modding community with this "don't you just have the old version?" idea.
For example, if a relative of mine who played the game in 2008 redownloads the game from his linked Battle.net CD key now, after 10 years, on a totally new computer, and then asks me for tips on how to make a model, I don't want to tell him, "Well, you can't, you didn't back up your game client in 2008 like I did"

Obviously I'm in a position like several others, where the modding software that I use and that I write will keep working on my computer one way or another. But it seems to me that there is a social benefit for it to be able to work on anybody's computer who has Warcraft III installed. Several have told me to port the CascView lib to Java for my Java model editor. Generally, they are right that this is the way to go forward. But during the time that I do so (I'm a hobbyist, so it might be slow) I foresee a "blip" in the set of available WC3 Model Viewer software for the average user.

Ghostwolf's online viewer is beautiful, and will keep working here on the Hive, but after someone downloads a model they might wish to view it again. And, many of the highest rated models use in-game textures. So, in my opinion, Blizzard would be doing us a big favor if they released a mini Model Viewer EXE with the game's own code for 3-6 months while the community catches up with CASC.
It could be that I'm too much of an old timer, and that the average users are only going to browse custom models on the Hive itself and in the Warcraft III world editor -- and both of those will keep working fine, for certain.

I messaged one of the recent Blizzard hires from the Hive about this idea, and his response was:

I think we have people like you that are still creating great tools
Why do we need Magos when we have your tool?

I love his optimism, but as the one working on my software, I'm painfully aware of the things that Magos has that it currently lacks (rendering particle emitters, animated textures, the ability to edit almost everything in the model in simple dialogues). To get work done faster, it might be time for me to do a better job actually embracing the power of open source and getting others to contribute to the "matrix eater" codebase.
 

Chaosy

Tutorial Reviewer
Level 40
Joined
Jun 9, 2011
Messages
13,182
More likely, a mod would put an up to date mpq in the magos' thread.
So it would be an extra download, an annoying one though.

Personally, I never 'look' at models through magos, the only reason I have it downloaded is to check which textures a model use.
Scenario: I download a model pack with custom texture, but I only want one of the models.
In which case I load up magos to check which textures it uses and the path they should be imported to

So to me, a mere viewer would not be enough, sadly
 
Hey, Frotty, you do stuff with Warcraft + Java, right? Do you feel a necessary for a Java CASC lib, too? What are you likely to do about that?
I know at one point I think I mentioned trying to work together or share code between some of the stuff you do and the Matrix Eater codebase that I've kept using for several years, and you didn't like the idea because you found the Matrix Eater's codebase to be unprofessional. I agree that portions are unprofessional, to an extent, but I never made the time to rework stuff that I wrote in high school.
Despite all that, should we be working on a Java CASC lib together somehow?
 
Level 23
Joined
Jan 1, 2009
Messages
1,608
Hey, Frotty, you do stuff with Warcraft + Java, right? Do you feel a necessary for a Java CASC lib, too? What are you likely to do about that?
I know at one point I think I mentioned trying to work together or share code between some of the stuff you do and the Matrix Eater codebase that I've kept using for several years, and you didn't like the idea because you found the Matrix Eater's codebase to be unprofessional. I agree that portions are unprofessional, to an extent, but I never made the time to rework stuff that I wrote in high school.
Despite all that, should we be working on a Java CASC lib together somehow?

Publicly misquoting me from a PM seems a bit odd - I never called it unprofessional (iirc), simply unusable as dependency in it's form at the time, due to not using a dependency manager, no unit tests, no CI etc.
I'm always eager to share code - but due to the state of your repositories this didn't seem easy. I would suggest collecting java wc3 filehandling in inwc3/wc3libs - I'm not sure about the coverage of topics with this your and JWc3libs, but if you have stuff to add, we can work on a PR together.

Regarding CASC, imo this should also be a separate library like mpq handling, and probably ported from ladislav-zezula/CascLib
Unless you feel like writing it from scratch - I don't really :D
If you want to port casclib or whip up something custom, I could help you out, especially regarding using it as a dependency :)
 
Level 23
Joined
Jan 1, 2009
Messages
1,608
I don't want to be forced to install further programs like Java to be able to run Warcraft III or something for it. I don't remember installing anything to be able to use Magus.
Sounds like a you problem.
The only reason *you* can run .exe files like magos without "installing anything" is, because windows ships the necessary libraries.
MacOS and most linux distributions ship with Java, thus you can run wurst and matrix eater out of the box, but can't run .exe files like Magos without installing extra libraries.
You really don't know this?
 
  • Like
Reactions: pyf
Level 26
Joined
Aug 18, 2009
Messages
4,097
Which is why despite many tests, there are still users getting errors when dealing with software. There are just too many variables and eventualities that derive from resources outside of the system. Much more so for developers. Things in Warcraft III are not really straightforward, more so with fluctuating versions. Next to writing tool XYZ, we have to educate people.
 
Level 12
Joined
Nov 3, 2013
Messages
989
Couldn't they just add one of those checkboxes to optionally install other software alongside the game?

Like it's not uncommon to have "recommended" "minimal" and "full" (as well as custom) installation options.
 

Dr Super Good

Spell Reviewer
Level 63
Joined
Jan 18, 2005
Messages
27,180
Stop this asinine CASC madness that's coming with 1.30, please revert to the tried-and-true MPQ format and start using
war3patch.[COLOR=color: #666666]mpq
[/COLOR]
again (keep
war3.[COLOR=color: #666666]mpq
[/COLOR]
and
war3x.[COLOR=color: #666666]mpq
[/COLOR]
contents identical through the patches to not have the patcher redownload the entire client), don't make all the modders and their tools rely on old patches (even more).
That does not solve the problem of file duplication between the standard MPQs and the patch MPQ. Additionally BattleNet Application probably does not support MPQ anymore seeing how Blizzard migrated all their games from it years ago.
Seconded. The drawbacks far outweigh the benefits.
What drawbacks?
Can't you bypass this by just putting the .mpq files in your 1.30 directory manually.
Probably... Most third party tools would probably not notice the difference. You could even dump all the files into a single MPQ with the others empty and they would work.
Where I see the issue is that new people wouldn't be able to join the modding community with this "don't you just have the old version?" idea.
For example, if a relative of mine who played the game in 2008 redownloads the game from his linked Battle.net CD key now, after 10 years, on a totally new computer, and then asks me for tips on how to make a model, I don't want to tell him, "Well, you can't, you didn't back up your game client in 2008 like I did"
I do not see why moving to CASC would prevent one from making models. CASC and MPQ have nothing to do with MDX, MDL and BLP.
Several have told me to port the CascView lib to Java for my Java model editor. Generally, they are right that this is the way to go forward. But during the time that I do so (I'm a hobbyist, so it might be slow) I foresee a "blip" in the set of available WC3 Model Viewer software for the average user.
From what I can tell it is nowhere near as hard as one thinks. Most of the CASCVIEW library is aimed at interfacing with BattleNet to query and pull archive information such as encryption keys and other files. To read data from an already built archive that is not encrypted I do not think a quarter of the amount of code is needed.

The main problem is that one literally has to port parts of the source code as all documentation on CASC is a load of gibberish.
Personally, I never 'look' at models through magos, the only reason I have it downloaded is to check which textures a model use.
Scenario: I download a model pack with custom texture, but I only want one of the models.
In which case I load up magos to check which textures it uses and the path they should be imported to
You can check texture paths using notepad... They are like the only plain text strings near the top of the file.
Hey, Frotty, you do stuff with Warcraft + Java, right? Do you feel a necessary for a Java CASC lib, too? What are you likely to do about that?
I know at one point I think I mentioned trying to work together or share code between some of the stuff you do and the Matrix Eater codebase that I've kept using for several years, and you didn't like the idea because you found the Matrix Eater's codebase to be unprofessional. I agree that portions are unprofessional, to an extent, but I never made the time to rework stuff that I wrote in high school.
Despite all that, should we be working on a Java CASC lib together somehow?
I plan to look into a Java CASC library some time in the future. Just currently I am trying to optimize something completely different and unrelated.
I don't want to be forced to install further programs like Java to be able to run Warcraft III or something for it. I don't remember installing anything to be able to use Magus.
WC3 will never need Java. Third party tools might but that is hardly a problem as Java really should be installed on every computer...
Couldn't they just add one of those checkboxes to optionally install other software alongside the game?
The game installs everything it needs... If it does not, report it as a bug to Blizzard with their installer.

Third party tools however might have different requirements and some do not have installers. For example Java for some tools.
 

deepstrasz

Map Reviewer
Level 68
Joined
Jun 4, 2009
Messages
18,706
Ugh, I hate java and deliberately uninstalled it.
tenor.gif
 
Level 11
Joined
Jun 2, 2004
Messages
849
The main reason to not have java on your computer is its long, long history of security vulnerabilities. To be fair though, vulnerabilities mostly come from java browser plugins, not standalone programs, but still.

Also it's an awful language.
 
Level 7
Joined
May 30, 2013
Messages
210
That does not solve the problem of file duplication between the standard MPQs and the patch MPQ. Additionally BattleNet Application probably does not support MPQ anymore seeing how Blizzard migrated all their games from it years ago.

[ .. ]
These few MiB will probably not kill anyone. They haven't killed anyone from 2002-2018 when people had much worse internet; unlikely these will kill anyone going from there.

Also, I literally cannot see any kind of causality nor correlation between the fact that the battle.net app not supporting mpqs to war3 having to migrate away from it. Why would it be necessary for the app to make sense of any of war3's game contents?
 

Dr Super Good

Spell Reviewer
Level 63
Joined
Jan 18, 2005
Messages
27,180
Why would it be necessary for the app to make sense of any of war3's game contents?
How else would it be able to programmatically update the patch archive? Also how would pre-downloading patches work?
The main reason to not have java on your computer is its long, long history of security vulnerabilities. To be fair though, vulnerabilities mostly come from java browser plugins, not standalone programs, but still.

Also it's an awful language.
Java is pretty quick at having vulnerabilities patched. Also it being an "awful" language is an opinion...
 
Publicly misquoting me from a PM seems a bit odd

That was definitely my bad for trying to remember what was said in a PM from half a year ago. No offense intended. Perhaps it was me that felt my codebase was unprofessional, and I was simply telling myself what I expected to hear as I read your words at that time.

Like they did it before, downloading a 50mbs patch and applying it on the game through the patch's .exe? Then there would be no need for Java and CASCO or whatever it's called.

@deepstrasz I am not sure you understand how Java is relevant to this discussion. I was the first one who mentioned it, and I only did so because I use it. Nothing in the game uses Java and nothing is going to.
But I have been working on a library of Warcraft 3 modding code for myself and others to use that is written entirely in Java, and only functions by loading game data. It uses several libraries written by Dr Super Good. Frotty, for example, is another Java developer who is a part of a team that made a similar library. They are more aware of how to work as a team, and use build systems that allow them to reference each other's projects across the internet, so they rewrote most of the Warcraft 3 libraries that I use with their own versions. That's just a matter of personal preference.
"CASC" is the name used for a storage system that is similar to MPQ. I always visualized MPQ files as something similar to ZIP files when I was first learning about them. "CASC" is somewhat similar. It is a storage system.

"Downloading a 50 mbs patch and applying it to the game" only ever worked because they gave you a program that downloaded new data -- stored in an MPQ storage system -- and saved that on your computer, replacing old data from older patches. The code for how to parse and understand the MPQ storage format was included inside of Warcraft III itself. But, it was binary, so fans weren't sure how to use it originally. It took them years to figure it out. Initially they discovered that the library called "Storm.dll" from the game was able to open this storage format. They hacked this library in many ways to obtain standard game models, like the Footman, etc, until Blizzard released patches so that it could no longer be hacked. However, at that point, the fans already had "Storm.dll" with a working MPQ library, and the storage format did not change. So, they continued to modify it and developed fan-made derivative works until they created "StormLib.dll" over the years. Eventually, even more years after that, people ported the StormLib to Java, and so for a while my code used "JStormLib". Then, eventually, Dr Super Good and others entirely replaced this with complete rewrites of MPQ storage system parsers.

The concern here is that Blizzard invented a new storage system. "CASC" is similar to ZIP, again, in that it is a way of storing data. However, the data is stored in many files instead of one file. This means that Blizzard can and will still give you a patch and apply it on the game through an exe. But the EXE will be invisible to you, inside of Battle.net code, because they want it to be easy for users. In addition, there's a new change to the system now. With CASC, instead of downloading a 26 MB "War3Patch.mpq" archive, as the game did many years ago, they can probably download 3 MB of "changes" into the CASC system and have it update itself, rather than replace itself with a whole new 26 MB download. This will greatly improve update bandwidth times for users as Blizzard continues to patch and improve Warcraft III.

The reason I am concerned is that any software developers, including Java developers like myself, need to relearn and rewrite all of our Warcraft III data parsing libraries if we want to load data out of the game itself.
Edit: And, actually, rewriting all of that is probably not that bad. If Frotty and the Wurst team get hit by a car tomorrow, all of their code is still around and is open source and somebody like Dr Super Good or me could fix it. If I get hit by a car tomorrow, somebody like Frotty's team could take up the Matrix Eater code and fix it if they really wanted to.

But Vexorian was already hit by a car. So, nobody is going to update his old map optimizer or his other systems. The guy who wrote the War3ModelEditor is gone, along with the ability to compile his source code. So nobody is going to update his old stuff.
Blizzard should not be held to the whimsical designs of people who are long gone, but I think that we should try not to let the modding community lose too much of what it can do. And that's why I think a standalone program that can view Warcraft 3 models using data stored in the CASC system should be released by Blizzard, so that guys like me can have several months to catch up with CASC.
 
Last edited:

deepstrasz

Map Reviewer
Level 68
Joined
Jun 4, 2009
Messages
18,706
I am not sure you understand how Java is relevant to this discussion.
I get it but it's just that modders have to find workarounds yet again. If that Java stuff works to bring back the soon-dead tools to life, then go ahead.
I always visualized MPQ files as something similar to ZIP files when I was first learning about them. "CASC" is somewhat similar. It is a storage system.
So, they're unpacking each time you're executing the game?
But Vexorian was already hit by a car. So, nobody is going to update his old map optimizer or his other systems. The guy who wrote the War3ModelEditor is gone, along with the ability to compile his source code. So nobody is going to update his old stuff.
Yeah, exactly. Would Java solve this? I'm not quite sure...
And that's why I think a standalone program that can view Warcraft 3 models using data stored in the CASC system should be released by Blizzard, so that guys like me can have several months to catch up with CASC.
Well, if they do it, at least, they should do it well to be on par with the oldies. It's them, who broke compatibility anyway.
 
Level 7
Joined
May 30, 2013
Messages
210
How else would it be able to programmatically update the patch archive? Also how would pre-downloading patches work?
[ .. ]
now if you would explain to me why you would want to do that when you can just rewrite 30 mib worth war3patch.mpq of instead and stop this asinine madness :thinking:
given that most of the updates nowadays will just be incremental changes to blizzard.j, common.j and the various slks it'd just be endlessly overwriting the exact same stuff in war3patch.mpq so it wouldn't even bloat! (in general you're all vastly exaggerating the bloat potential there; after even significant amounts of content update through the decades it and war3xlocal.mpq together weren't even remotedly getting close to 100 mib)
 

Dr Super Good

Spell Reviewer
Level 63
Joined
Jan 18, 2005
Messages
27,180
Like they did it before, downloading a 50mbs patch and applying it on the game through the patch's .exe?
With CASC the patches would likely be <<20MB.
Then there would be no need for Java and CASCO or whatever it's called.
Java has nothing to do with Warcraft III. It is the programming language used by some third party (NOT BLIZZARD) tools.

CASC is Blizzard's current archive system. All BattleNet application games use it from StarCraft to even non Blizzard games like Destiny.
So, they're unpacking each time you're executing the game?
Yes, the zlib compressed files are unpacked into memory every time the file is loaded. Been done this way since MPQ so nothing new with CASC.

Decompression is very efficient. It decreases the IO bandwidth needed to read files, which is often the largest loading time bottleneck, at the cost of some CPU time. Since many files have to be loaded at the same time the decompression CPU time can be efficiently masked by multi threading.
Yeah, exactly. Would Java solve this? I'm not quite sure...
A third party tool written in Java, such as the various ones that already exist, would.
It's them, who broke compatibility anyway.
That is not their problem... It is more on the stupid third party developers for not making their tools future proof by doing stupid things like always expecting the game data to come in MPQs.
now if you would explain to me why you would want to do that when you can just rewrite 30 mib worth
war3patch.[COLOR=color: #666666]mpq[/COLOR]
of instead and stop this asinine madness
:thinking:
In order for Warcraft III to be compatible with the BattleNet application? How many of the games in the BattleNet application still use MPQ for the main game data? 0?
given that most of the updates nowadays will just be incremental changes to
blizzard.[COLOR=color: #666666]j[/COLOR]
,
common.[COLOR=color: #666666]j[/COLOR]
and the various slks it'd just be endlessly overwriting the exact same stuff in
war3patch.[COLOR=color: #666666]mpq[/COLOR]
so it wouldn't even bloat! (in general you're all vastly exaggerating the bloat potential there; after even significant amounts of content update through the decades it and
war3xlocal.[COLOR=color: #666666]mpq[/COLOR]
together weren't even remotedly getting close to 100 mib)
So? We can just use CASC and it will work out the same from a user experience.

Honestly I did warn people this day was coming many years ago already. The fact no one has prepared is the surprising part.
 
Level 7
Joined
May 30, 2013
Messages
210
you're still missing the point, there is literally no gain from integrating war3 into the app like that, it doesnt use bnet2.0, nor will it (closed ecosystem will kill game just like sc2, besides the fact that it'd require an extensive rewrite of the engine), and it's not like war3's got a 30 gib download.

it's probably (much) smaller than a modern games patch
 
Level 28
Joined
Nov 12, 2007
Messages
2,340
that's why I think a standalone program that can view Warcraft 3 models using data stored in the CASC system should be released by Blizzard, so that guys like me can have several months to catch up with CASC.
This would be optimal, but perhaps there would be a drawback on Blizzard's side by doing this? I mean, I don't know how much are they willing the userbase to decrypt their CASC files, considering it is the same filetype used in other games that are not open to modding like Overwatch (and a game that's not even from Blizzard - Destiny). Still I'm hoping your suggestion will be taken in consideration, though deep down I'm skeptical.
 
I mean, I don't know how much are they willing the userbase to decrypt their CASC files, considering it is the same filetype used in other games that are not open to modding like Overwatch (and a game that's not even from Blizzard - Destiny).

This is exactly why I think Blizzard should release a standalone model viewer client. Maybe they don't want us to be able to load the game's internal files. If that's true, then they should write code to do it for us in the limited ways that Blizzard is OK with, without giving us some magic decrypter that can open any CASC system (which they probably don't want to give us).
 

Dr Super Good

Spell Reviewer
Level 63
Joined
Jan 18, 2005
Messages
27,180
you're still missing the point, there is literally no gain from
integrating
war3 into the app like that, it doesnt use bnet2.0, nor will it (closed ecosystem will kill game just like sc2, besides the fact that it'd require an extensive rewrite of the engine), and it's not like war3's got a 30 gib download.
You are still missing the point. There are huge gains from integrating Warcraft III into the app. Firstly it becomes a lot easier to buy as one can buy it from inside the app rather than some hidden pages of your BattleNet 2.0 account management. Secondly BattleNet 2.0 integration, which will occur around the same time, will mean that players can take advantage of the cross game communication and friend tracking of BattleNet 2.0, eg you could play Warcraft III and still chat to people playing StarCraft II. Thirdly it is unlikely to become a "closed ecosystem" whatever that means as chances are custom game hosting mechanics will remain unchanged.
I don't know how much are they willing the userbase to decrypt their CASC files
Most CASC files are not encrypted. Encryption is only used for pre release pre installs, to prevent game spoilers leaking out before a game is actually released. The CASC system can roll out encrypted files to clients but the clients cannot use them until the decryption keys are made public. Once the decryption keys are made public the CASC system can immediately allow the game to run by applying a decryption stage to the file stream.

From what I can tell this is mostly done targeting World of Warcraft and Destiny for expansion releases. Games like Heroes of the Storm do not use such encryption as there is nothing to spoil.

StarCraft II uses CASC and it has not been a problem. Like StarCraft II, map files will still remain as MPQs even after Warcraft III migrates to CASC.
 
  • Like
Reactions: pyf
Level 7
Joined
May 30, 2013
Messages
210
bnet app doesnt have to be able to read mpqs to do an integration like that tho, its like saying if you wanna post your game on steam the steam client must be able to make sense of all your games archives
??????
 

Dr Super Good

Spell Reviewer
Level 63
Joined
Jan 18, 2005
Messages
27,180
bnet app doesnt have to be able to read mpqs to do an integration like that tho, its like saying if you wanna post your game on steam the steam client must be able to make sense of all your games archives
??????
Except the steam client is able to make sense of all the game files, after all it is what installs them all...

Hence the BattleNet application also needs to make sense of all the game files, as it is what installs them. BattleNet is slightly more complex than steam in that it writes out most of the game files to an archive system rather than dumping them loosely in the file system.
 
Level 7
Joined
May 30, 2013
Messages
210
No?
The most Steam can do (for the vast majority of archive types anyways) is to verify their integrity through checksums
The very same would be sufficient for war3 (because lets face it no1 will rewrite it for more than the most basic of integrations), and im pretty sure you wouldnt have to be able to read a files contents to verify integrity
 
Level 26
Joined
Aug 18, 2009
Messages
4,097
That is not their problem... It is more on the stupid third party developers for not making their tools future proof by doing stupid things like always expecting the game data to come in MPQs.

It is a lot of work as it is. What can we assume? But that's why APIs and tools should be more differential and user awareness raised. I do not see a problem in switching to CASC if the tool developer is still there/source code available since you are to abstract that persistence format anyway. And otherwise really just convert the CASC data to MPQ ahead. If CASC is to be used for maps as well, you can convert the map to CASC afterwards. From a developer perspective, I do not like to deal with the package anyway, packaging is just for shipping/archiving. When working on it, I would rather have it unwrapped.
 

deepstrasz

Map Reviewer
Level 68
Joined
Jun 4, 2009
Messages
18,706
That is not their problem... It is more on the stupid third party developers for not making their tools future proof by doing stupid things like always expecting the game data to come in MPQs.
Wow, really!? I mean, expect what, a game to be so popular to last more than 20 years and get a rehash? Really now doc....
 

Dr Super Good

Spell Reviewer
Level 63
Joined
Jan 18, 2005
Messages
27,180
The most Steam can do (for the vast majority of archive types anyways) is to verify their integrity through checksums
Steam firstly deploys the files from their steam server. Steam can also verify the files to check for errors. Sound familiar? Of course it does because this is exactly what BattleNet application does!

Only difference is steam dumps all game files directly into the file system, discouraging game authors from using their own complex archive systems to reduce update sizes. BattleNet application on the other hand dumps all game files into CASC file systems with exception of some specifically loose files such as the game executables. From the developer point of view they are the same, both only accepting loose game files.

From a deployment point of view it is a lot easier. They can just update the loose game files and not care about having to run horribly dated and unmaintained MPQ builders.
If CASC is to be used for maps as well, you can convert the map to CASC afterwards.
MPQ will remain in use for maps, as with StarCraft II. CASC is only for the main game data.
When working on it, I would rather have it unwrapped.
Exactly why they moved to CASC. From their perspective that is how they deploy Warcraft III. The files are then bundled local CASC storage on a client by the BattleNet application.
Wow, really!? I mean, expect what, a game to be so popular to last more than 20 years and get a rehash? Really now doc....
There are so many ways they could have made their tools more future proof but did not due to their own stupidity or arrogance...
 
Status
Not open for further replies.
Top