EPT[G] Custom Maps and Custom Hotkeys
Update: Part two now here
The purpose of this guide is to demonstrate how to make your maps and mods accessible to those of us who customise our hotkeys. Having beaten every test Blizzard could throw at me helping with TheCore I wrote half of this guide and then stopped, possibly out of exhaustion. With renewed interest in Starbow (and Jakatak asking nicely) I have dusted this guide off.
It is my hope that by the end mapmakers will have the tools to update their maps to be playable with any hotkey setup, preferably with minimal fuss for everyone. In a perfect world every key would be accessible through the front end (and the icon movable), but while we wait for that to happen there are still ways to make life easier for players of your map.
These are
- Plan ahead so conflicts don’t occur in the first place
- Set keys to inherit wherever possible
- Provide a text version of new keys
Presumably planning is something that mapmakers do anyway. Setting keys to inherit is 5-10 seconds more work per ability.
If both of these were done then in the worst case there would be a few lines for players to paste into their hotkey file. This is what I mean by minimal fuss for everyone. However these aren’t being done (not even by Blizzard) so the maximum amount of work is being pushed to individuals (who probably just switch to grid) or maintainers of hotkey setups (who are overwhelmed so their players probably just switch to grid).
Plan Ahead
There are a number of ways to make life difficult for players but only a couple to make life easy. Copy the Medivac, change the ID to MyMedivacBringsAllTheBoysToTheYard, check that no info appears in the front end, lock the map and voilà: hotkey this, bitch.
Further complications arise when the ID is kept the same but the unit changes to a new command card, more still if you swap units. In some of these cases, even if the hotkey could be written manually into the file, a whole new file would need to be created for the custom game.
How Hotkeys Work
In the .SC2HotKeys file the hotkeys are in the following format
buttonID/unitID=hotkey,alternate
Scroll through your file and you will see
Baneling/Zergling=
Open up the Editor and you’ll see the unit “Zergling” has the ID Zergling. Attached to the Zergling is the button “Morph to Baneling” which has the ID Baneling. Abilities, Actors, Behaviours and Buttons all have IDs, but only one combination allows players to change the key.
I point this out as part of planning ahead because either this is news to a lot of you, or old information and some of you are real pricks. MyMedivacBringsAllTheBoysToTheYard barely exaggerates some of the stuff I’ve seen and in most cases the unit was indistinguishable from the original. But if someone moves buildings between the Basic and Advanced Structures cards you can bet the one thing they won’t change is the UnitID.
IDs and Planning
If you remove the Siege Tank and replace it with the Battle Tank then by all means have the UnitID=SiegeTank. Same if you swap out Siege Mode for Battle Mode and leave the ID the same. The hotkeys will stay the same and with one for one swaps no conflict can occur.
If you keep the Siege Tank as is and shift it to the Planetary Fortress then change the ID to SiegeTankFromPF. Then write the following line where people can get to it: in the map’s How To Play, on a TL post, on a Mapster post… or wherever you think is easiest
SiegeTankFromPF/PlanetaryFortress=
Without this players can’t find conflicts without triggering them by opening the map. And in this example you think the SCV is the problem, what if rally point was set to ‘S’? There’s no telling which key will be unbound, but when it is it will revert to its hardcoded value, so in the case of Rally Point now shifting back to ‘Y’ on every building (and most Protoss units) a chain reaction of unbinds will be unleashed as yet more keys are sent to look for a new home.
Set Keys to Inherit
I stumbled across this when writing up a blog post for TheCore so all the background is there and I’ll just repeat the key point. The SC2 Map Editor can tell keys to inherit.
Remember all the “campaign keys don’t work” posts like this and this and this? Remember how they were fixed at the end of July 2013? Well the solution was in the editor all along, every unit has a simple setting and Blizzard have been doing it for years.
Here is the step by step exactly as I wrote it: Setting Inheritance. You won’t be able to follow those steps because if you now open that map and scroll to that button the change is already there. Three months after I found the fix that Blizzard already knew about they got around to doing it themselves.
Go have a look at Kerrigan K5: and look at the Leaping Strike button. See how it has that same Hotkey Alias set to Kinetic Blast?
Apocalypse has its Hotkey Alias set to Spawn Leviathan.
Psionic Shift has its Hotkey Alias set to Crushing Grip.
Go the Engineering Bay: Upgrade Infantry Armor Levels 2 and 3 both alias Level 1, as they have for years. Open up a WoL campaign map and see that Vanadium Plating has its Hotkey Alias set to VanadiITSSTILLNOTFIXEDFFS. But if you change all the Vanadium Platings to alias Level 1 (while you’re practising do the same for all campaign upgrades in the Engineering Bay and Armory) and test the map then you’ll see inheritance in action.
Inheritance and Planning
So now we can go further than just swapping units and avoiding conflicts. The new button can be set to inherit the original’s hotkey, which players will already have in their file.
Starbow has removed Calldown MULE and Calldown Supply Depot, replacing them with Calldown SCV and Overcharge. That seems like a good place to good start.
So set the Alias for Calldown SCV to Calldown MULE, and set the Alias for Overcharge to Calldown Extra Supplies (not Calldown Supply Depot which is a campaign ability which should have its own alias set to Build Supply Depot) and test the map.
Switch from Standard to your customised keys and whatever keys you’re used to in multiplayer should now be in Starbow.
Moving on, the Ghost’s Shock is an AoE and EMP has been removed. Set the Alias for Shock to EMP Shockwave and test the map.
Provide a Text Version of New Keys
Before you go too much further I will point out that there are a few cases that won’t work. This can be due to dependencies, or disabling buttons. It can also come from they way a button is designed. I will explain these later and how to design buttons so even this number is reduced.
But let’s say I get struck by lightning before I can update this post. Even if these cases were never fixed, with UnitIDs changed where a clash might occur, and with inheritance set where possible, most maps would be left with a handful of entries for players to paste into their hotkey file.
Their single hotkey file which would work for everything.
The above section functions as an overview. This update now moves into the nitty gritty. If I’d finished the whole thing at once rather than staggered episodes I would have structured it differently.
Mechanics of Buttons
This section explains the various settings and how they affect hotkeys. Using these too often or not enough can have the same result for players: make a new SC2HotKeys file for your game. So no pressure!
These settings are
- (Basic) UI: Hotkey Alias
- (Basic) UI: Universal
- (Basic) UI: Hotkey Set
Hotkey Alias
This tells the button to use an assumed name. It’s limited as it only works for buttons on the same unit but this still covers a lot of ground since most buttons are swaps for others.
Buttons to build various units from larva are a good example. They all have the same unitID, so everything will be
buttonID/larva=
The Swarmling and Hunterling can alias the Zergling so the buttonID=zergling for all three. So one entry in the file covers three units
zergling/larva=
This solves the problem of players having to make their own bindings for the 12 units you added which were pretty similar to the one they replaced. They already have an entry in their file so your units using aliases will access those keys too. But bear in mind this alias cannot be overridden even with a manual entry to the file. Any different ideas that players have about binding will now require a new hotkey file.
If you take Blink, make it alias Storm and change the hotkey in game then SC2Hotkeys will record PsiStorm/Stalker=. So it is aliasing but it’s highly unlikely to inherit any key in the file. Lacking the option to tell buttons to also retrieve a unitID there is not an easy way to create new units and abilities and have them use hotkeys that players already have.
Actual units also have a Hotkey Alias, it’s mostly used on buildings and does even less. It moves the card to another unit on the hotkey GUI. The three Tech Labs that appear on the front are separate buildings with separate IDs which alias one Tech Lab. There would be no affect on the SC2Hotkey file if this was turned off, the buttons would just be harder to see all at once through the front.
Universal
So how do Ghost and Banshee share cloak then? How do Gateway units come from Warpgates?
Attack, Archon Merge, Build SCV, and Cloak all have Universal enabled and all appear in the format
buttonID=
This is almost always used in combination with the Hotkey Alias, and almost always where one button is shared by many units. When keys are updated through the front it forces an update of everything sharing that key.
Note the difference here: Hotkey Alias is used where one unit has many buttons, which you might not want or need on the front as no conflict can occur; Universal is used where one button is on many units, probably all of which are on the front and changing one might well conflict somewhere else.
The Load buttons for Overlord, Warp Prism, Nydus, and Medivac are all universal and all have the alias Load Bunker (which is also universal but has no alias). Same for all the unloads.
If you change the load key on any unit the alias setting decides which line to write to the SC2Hotkeys file (the bunker’s), the universal decides only the buttonID will be written (BunkerLoad= or BunkerUnloadAll=) and then tells all the other buttons on the GUI to update.
Edit a HotS map and turn off Universal on Load and Unload on all these units. Test the map and change only the Bunker’s Load and Unload. First you will notice no other unit’s button changed in the GUI, now change some of the rest and check the format in the file
BunkerLoad/Bunker=
BunkerLoad/Medivac=
BunkerLoad/NydusCanal=
BunkerLoad/NydusNetwork=
BunkerLoad/Overlord=
BunkerLoad/WarpPrism=
BunkerUnloadAll/Bunker=
BunkerUnloadAll/Medivac=
BunkerUnloadAll/NydusCanal=
BunkerUnloadAll/NydusNetwork=
BunkerUnloadAll/Overlord=
BunkerUnloadAll/WarpPrism=
You can see the alias is still working and you can see how units having separate hotkeys was bypassed: just remove the unitID.
Every Protoss Gateway unit is universal. If you make the Sentry come from the Robotics Facility there’s no Sentry/RoboticsFacility= for players to use to bypass whatever clash arises in their file. Those that make the mistake of changing it will just get another clash playing ladder.
Making Sentry2 non-universal will get past that, so what key will be the default for Sentry2/RoboticsFacility? What about the 14 buttons now in the format
buttonID/Sentry2=Will you write them all somewhere easy to find? Because players might get conflicts if you don’t.
There’s more fun to be had moving units onto the gateways, they have to be universal. Or you can leave everything separate and players can just bind everything four times. Pussies.
Immortal=
Immortal/Gateway=
Immortal/RoboticsFacility=
Immortal/WarpGate=
Actual lines from TheCore
Hotkey Set
This tells keys to ignore a conflict with other members of the set. Fun things to do with this are
- Fix the Spectre’s Hold Fire and Weapons Free. actually why bother?
- Add everything on a command card to the same set.
I guess the chain reactions would be stopped.
Examples from Maps and Mods
Let’s start this off as ‘your own personal reflection journal’. I’ll describe the creation or editing of some buttons and you decide how you would design it. The goal of the design is for players to use your map without conflicts. Assume a player has no conflicts between WoL & HotS campaigns and ladder and they are reading about your map in the Arcade.
- In Brood War
- The Queen was built by larva. She also had 3 abilities.
- The Defiler had 3 abilities
- The Science Facility was built by the SCV
- The Dragoon was built by the Gateway.
- Build every Terran ship at the Starport
- When the Greater Spire is upgraded it unlocks flyer upgrades 4
- When upgraded again it unlocks a choice between Devourers and Guardians.
- It’s your choice how Devourers and Guardians spawn.
External Consistency
Internal consistency would get every key working in your map, which would be an achievement in itself. External consistency would allow players to switch to any map without conflicts, which might be impossible but let’s take a shot.
Starbow removed the Colossus and added the Reaver, so one might set the Reaver’s Hotkey Alias to the Colossus. However this will presumably create a conflict when LotV has both. LotV might have the unitID’s EagerForTheReaver and OhCollyMyColly but
- It will be bad enough coping with the conflicts Blizzard make never mind your custom thingy.
- Some other custom game might already have both.
Each map has different ideas on which units belong on the Factory command card, but the pool of units is the same. Starbow removes the Hellion for the Vulture but the alias wouldn’t be set because these units need different keys for the campaign. Comparing OneGoal, SC2BW, Starbow and the current campaign mods shows, for the most part, agreement on the pool of units on each building.
I think external consistency is possible, and I’m sure it’s worth a shot. But I’ll revisit this later since it is less of a priority.
