Hi there. I really love that in ClassicHD/Classic the skins that don’t have custom visuals are still applying the campaign characters’ names (and voice lines where appropriate), but I’ve noticed that this application is not consistent across all skins. For example, Kel’thuzad, Cenarius, Tyrande and Maiev all fail to apply the correct name and voice lines, while Cairne Bloodhoof, Muradin, Rokhan and Anub’arak all successfully change their names, and have their unique voices where applicable. Can this be improved, or is this a technical limitation?
There is absolutely no way that this is a technical limitation. If you want to change that, you can hack the skins file yourself on the local computer and then it will load the voices when you play. I know that this is true without even testing it, because that is how technology works.
I am less certain whether applying the special name on the local computer might cause a desync bug or not, since other players in that game would most likely not see the special name. But because of language files needing to avoid checking for desyncs on different language translations of names, I think that most likely you could fix the names on your local computer as well and that would probably also not introduce a desync in that case.
“I didn’t ever actually do this but I know everything so trust me”
You’re not entirely wrong, but you basically described the first step and the last step and left out the important part in the middle. And even considering that, every implementation of features in a game is different, especially across different game engines (and especially entirely custom ones like that used in war3). Giving this kind of advice without the actual know-how and just a blanket “this is how tech works” statement could lead people to try to do something they don’t really know how to do and potentially mess up their game.
You’ve taken a position I won’t deny I’ve been guilty of before, saying things without actually doing the research or having all the knowledge. and I can tell you from experience that can easily go awry.
To his credit, he does have a verifiable amount of experience with this stuff, given his Warsmash project.
That’s fair, but it’s way too easy for people to just say “oh this is how things work” without actually knowing how they work. People do it all the time, especially here. Even I admitted above to sometimes stating something before verifying it. But this happens on almost every game forum, someone says “why cant the game be like this? It would be so easy to do” but they don’t even know anything about how the game is designed or how these kinds of things are accomplished.
Reforged took the existing unit data system that I was playing with in World Editor for 20ish years, and they added a new file called Units\UnitSkin.txt in the year 2020. I’d reckon Brad Chan used the same system when he added the new ones.
In a manner likewise to how World Editor worked for 20 years, the skins described in this file are essentially key/value pairs for a property map that defines each unit. Where that becomes more complicated is that Reforged changed the game code so that every unit has 2 type IDs, instead of the old system where a unit had 1 type ID that defined what it is. So on a technical level, since long ago the Archmage was a 4 letter key Hamg that contained the key/value pairs for Archmage. However, Reforged introduces the idea that the Archmage in the game world might have a different model on my computer than on your computer during play. For example, you might buy Reforged graphics and turn it on, and I might not. That’s one use of the “skin” system – it means that a unit with type Hamg and also skin type Hamg will only use Hamg for the purpose of checking for network desyncs. I guess that’s probably pretty important, but we don’t think about it much as World Editor users since we like to pretend everything is always going to work properly and not desync (Ha).
But because every unit has 2 types now since the 2020 craziness, it means you can spawn a Hamg type unit into the game world but who visually uses the Jaina visuals. I’m on a Linux computer with a really old version of Reforged on it because I don’t like to deal with Microsoft every day, but even when I look at my old 2021 copy of Reforged dissected I can see something like this in the Units\UnitSkin.txt file:
// Daughter of the Sea Jaina
[Hjas]
Art:hd=ReplaceableTextures\CommandButtons\BTNJainaSea.blp
skinType=unit
skinnableID=Hamg
file:hd=units\human\JainaSea\JainaSea
unitSound:hd=DaughterOfTheSeaJaina
ScoreScreenIcon:hd=WebUI\ScoreScreen\HeroIcons\scorescreen-hero-jainasea.png
So, obviously in this case, we introduce a skin type Hjas for the Jaina Sea character. Of course this is not Hjai from the 2002 campaign missions – it is instead the Reforged version of Jaina on a horse.
When the new Reforged code loads the split ID for a unit, we can have a unit with Hamg as the behavior and Hjas as the visual. Apart from that change, the system is very nearly the same as the old 2003 system. As such, in the example above, unitSound is used here to look up a unit soundset definition. These definitions are in UI\SoundInfo and generally define for a given name what sounds play when we click that unit, or give it a command. The organization of the stuff in UI\SoundInfo changed a bunch in 2020 and I haven’t studied the new organization as much as the one I used prior to that for 17 years, partly because I think the new one is stupid. They were dedicated to hacking FaceFX technology into the game instead of using the “looping flapping mouth” animation technique, and to be honest in a cartoon world for me the “looping flapping mouth” idea was fine (these were animations called Portrait Talk in the code).
So, obviously the Excel spreadsheets that link the name DaughterOfTheSeaJaina from the value for the unitSound key are slightly different in format in 2025 than in my youth, but the idea is 100% the same that which sounds we play is given by a table. It’s just that now it’s an overcomplicated, gummed up table with some bad-attempt-at-lip-sync-using-expensive-proprietary-code nonsense.
So, if you follow where I’m going with this, if it’s true that Muradin in the Brad Chan patch doesn’t use the "Yer kinda slow for a human, aren't yet?" sound files, I am extremely confident that this could be fixed by modifying the game installation. Nobody likes to bring attention to how we modify the game installation, because Reforged devs tried really hard to make this harder and harder and to be anti-modding, but there are mods that exist (and want to exist!) for custom ways of playing, so even though enabling modding is as simple as just editing 1 registry key, and I know the name of that key and where it is, I’ll leave it as an exercise for the reader to go and find it.
Once you find that key, if we suppose that you’re playing some newer version of Reforged than the one I have in front of me, and that this newer version is loading a unit with type Hmkg (Mountain King) but with the “skin” (visuals) from the Muradin type ID, then you’re going to see one of two ways that Brad Chan coded this:
- Maybe he used the pre-existing Campaign hero key from Muradin, which was
Hmbras the one loaded by the new skins menu - Maybe he added his own skin ID for “muradin but as a skin on melee games” which would be a different and new 4 letter ID
When I look at the data in Units\UnitSkin.txt for Hmbr, we can see it looks like this:
[Hmbr]
Art=ReplaceableTextures\CommandButtons\BTNHeroMountainKing.blp
Art:hd=ReplaceableTextures\CommandButtons\BTNMuradinBronzeBeard.blp
skinType=unit
heroAbilSkinList=AHtc,AHtb,AHbh,AHav
abilSkinList=AInv
modelScale:hd=1.0
skinnableID=Hmbr
sortUI=z1
file=units\human\Muradin\Muradin
fileVerFlags=0
unitSound=Muradin
tilesetSpecific=0
special=0
campaign=1
inEditor=1
hiddenInEditor=0
dropItems=1
useClickHelper=0
hideHeroBar=0
Above, we see unitSound=Muradin and this is why he says, "Yer kinda slow for a human, aren't ye?" when we click him, instead of the generic Mountain King guy who says stuff like "Wait 'til ye see me in action!"
So, either the code of Brad Chan is very busted and a unit with type='Hmkg', skin='Hmbr' fails to load its unitSound=Muradin property (unlikely) or else what probably happened is that second case listed above, where Brad Chan and his friends didn’t use Hmbr and instead added their own ID for this. Then, on that ID, they probably didn’t add unitSound=Muradin as one of its properties.
As such, in your modified game client, to change this you just edit the Units\UnitSkin.txt file (it’s literally an INI text file, pretty standard) and you would find the new Brad Chan 4 letter ID that was added for Muradin as a skin, and append the line of text unitSound=Muradin to give it that property.
And that’s why I believe… that fixing this… isn’t hard.
Edit:
Upon review, I skimmed the OP’s comment a bit and was incorrect in my interpretation. Muradin is one of the GOOD and WORKING ones. And you know why? Because of exactly what I predicted. Here’s a deep dive: my theory was correct, and Brad Chan and the new guys added Muradin skin with a different ID than Hmbr for some reason. I guess he figured he couldn’t trust Hmbr so he needed to increase the complexity of the game code. So, they added Hmmb:
// Muradin Bronzebeard skin
[Hmmb]
skinType=unit
skinnableID=Hmkg
Art:hd=ReplaceableTextures\CommandButtons\BTNMuradinBronzeBeard.blp
modelScale:hd=1
file=units\human\Muradin\Muradin
unitSound=Muradin
portrait:hd=units\human\Muradin\Muradin_portrait
portrait:sd=units\human\Muradin\Muradin_portrait
It’s just like we expect – it does include unitSound=Muradin property. And that’s why it works (contrary to my misinterpretation of OP’s comment.
What makes less sense to me is the following:
// Tyrande skin
[Emot]
Art:hd=ReplaceableTextures\CommandButtons\BTNTyrande.blp
skinType=unit
skinnableID=Emoo
file:hd=Units\NightElf\Tyrande\Tyrande
unitSound=Tyrande
walk:hd=320
run:hd=320
portrait:hd=Units\NightElf\Tyrande\Tyrande_portrait
It seems that Tyrande has Emot added for Tyrande skin (again, a limited repeat of the Etyr campaign character and IMO it’s probably pointless and a sign of bad code design that we can’t just apply Etyr as the skin of a hero in versus mode, but whatever. The weird thing is that Emot has unitSound=Tyrande in the data. So, I don’t understand why that wouldn’t work, actually. That makes it seem a bit more like Brad Chan or his predecessors might have just mucked up the code. Then again, the entire premise of not simply spawning Emot as its own unit type into the world is probably stupid, so ever since the moment the 2020 guy decided we would have type='Emoo', skin='Emot' on a single unit, I’m pretty sure the simplicity and elegance of Warcraft III as a system was already going downhill due to being stewarded by lesser minds. But, whatever, from their own internal perspective, it makes sense, there’s no reason to keep Warcraft III running if you can modify it to become a new profit source with a new system internal that better reflects profitable eSports, I guess.
The name of Tyrande should be in war3.w3mod\_locales\enus.w3mod\units\unitskinstrings.txt I should think, so we can look at that too. And of course, I’m only looking at English when I say this, but let’s have a look:
In this case, the reason that Tyrande name doesn’t load for the OP is extremely stupid and obvious when we look in these data files. The developers flagged Tyrande’s name as an HD graphics mode only setting, whereas a name like Muradin is applied in all modes. See here:
[Hmmb]
Name=Mountain King
Propernames=Muradin Bronzebeard
[Emot]
Name=Priestess of the Moon
Propernames:hd=Tyrande
So, these are just stupid problems, and fixing them just requires a human to do it and delete the :hd from Tyrande. From looking at the code I have no idea why Tyrande’s soundset wouldn’t work, but the user also complained about Cenarius soundset and from what I can recall there never was a Cenarius specific soundset – he just use the one from the Keeper – so I’m going to go out on a limb and say that I was probably correct all along in thinking that the problems OP is having are these dumb data issues that any kiddo could fix in a custom mod and not a complex C++ programming problem with the game itself.
Do you hear that, Brad Chan? Wasn’t it you who said that throughout your life, when something is broken, you fix it? Oof.