Object Editor

Hello there,
it has been some time (again) since the last article but don’t expect me to stop development of wc3lib. There has been some great changes recently which made it possible to write and improve
World Editor modules such as the famous Object Editor.

If you do not want to read all this, just scroll down to the screenshots.

Warcraft III’s object data as well as other data such as weather effects, sounds, ubersplats, skins, terrain types etc. etc.  is stored in separate .slk files.
The SYLK (Symbolic Link) format is a spreadsheet format by Microsoft which is supported by LibreOffice and other programs as well. It simply allows you to store “Excel tables” with columns and rows where cells store the actual data.
As the format is important for all the meta data which you would need to create weather effects, sound data or units and items etc. wc3lib should be capable of handling it. Therefore I’ve started writing a parser as well as a generator at once. The new class map::Slk supports reading and writing SLK files in a generic way. It does only depend on some Boost libraries.
For parsing and generating the files I use Boost Spirit a C++ inline parser framework which supports defining grammars by C++ code.
The cells are stored in a multidimensional array created by boost::multi_array where the first dimension is the column and the second dimension is the row. All cell values are stored as strings but could be converted into any type. This rather generic class is important to provide an Object Editor emulation, for instance since all data shown in the object editor heavily depends on SLK files.

Another type of files provided for the meta data are .txt files. Those files simply have key value pairs and groups/sections:
[MySection]
MyName=Peter123
Path=dir/file.txt

There’s already a parser for those files provided by the class map::Txt. It also uses Boost Spirit to parse the files. Performance could still be improved by providing a lexer and adding expectation points to the grammars
Unlike a compiler which should produce as many valid syntax errors as possible those parsers must stop on the first error since they always expect valid files. Therefore no complex error recovery support is required.

 

Having those two formats supported by the wc3lib and a working MPQ extraction, I’ve finally been able to start working on an Object Editor recreation which should work on Unix platforms as well as Windows.
Like the Trigger Editor, the Object Editor is based on KDE4 libraries. It expects the default meta data files and creates all tree and table widgets. Unfortunately, it is based on data from SLK files as well as TXT files.
That is why I had to write another wrapper class for the “editor” module called “MetaData” (probably it will be renamed to “ObjectData”) which unifies the interface for SLK and TXT files and provides fast hashing functions.

In the SLK files for the Object Editor there is an initially row and an initially column. The column contains raw data ids such as “hfoo” for the Footman. The row contains column names such as “ID” for the raw data ids or “race” for a unit’s race. Basically, you always want to identify a cell value by its column and row key.
For TXT files it is nearly the same except that you have sections surrounded by brackets ([MySection]) and key-value pairs (MyKey=MyValue). For the Object Editor data the sections contain the raw data ids (“hfoo”) and the keys contain the column names (“ID” or “race”).
Now you can see that there is two file formats but one single concept behind. After having written the class “MetaData” I could access most values in an acceptable time. Only searching for the key in a section is done with linear complexity at the moment which might be improved later.

 

The messy part comes with the actual GUI. The class “ObjectEditor” is the module but it needs sub modules for the separate tabs/editors such as the Unit Editor or the Item Editor. For this reason, I’ve added the class “ObjectEditorTab” which unifies all functionality all the separate editors do share with each other.

At the left edge there is a tree widget which lists all standard and all custom objects whereas at the right edge a table widget with two columns lists value descriptions and the actual values of the currently activated object (which must be selected in the tree widget).

Starting with the Unit Editor I had to load the file “Units/UnitMetaData.slk” which contains all possible value fields for a unit. Using the “field” column you get the key name which is used in SLK and TXT files for the actual data of the standard units. Note that the key name is the column key.

The “slk” column says in which file you can find the actual data which is quite useful for keeping the performance high. “Profile” means that it is found in one of the TXT files depending on the unit’s race. The other possible values are simply the names of the corresponding SLK files.

The “displayName” column contains the string reference which should be displayed as value description in the table widget which I’ve mentioned already. You can resolve the string reference by searching for the value in “UI/[WorldEditStrings.txt” (section “[WorldEditStrings]”) for the corresponding key which is named after the string reference.

For translation stuff I’ve introduced a class called “WarcraftIIISharedData”. It allows you to access World Editor strings, trigger data, trigger strings and shared textures (such as team colours) in a unified way.

 

Besides I had to allow editing values in the right table widget. As “Units/UnitMetaData.slk” has a “type” column we know the type of each field. For Reign of Chaos the file “UI/UnitEditorData.txt” provides possible entries for types like “attackType” or “regenType” as well as their translations.

For other types like “string” I had to choose manually how the value has to be treated but that’s not that much code and it is shared by all object editor tabs.

Finally, all modifications must be stored in a hash for fast access and serialization when exporting them. After that was done I could modify most values in a proper value and get modified units highlighted. Also resetting values was a minor part since I had to load the default values anyway to load the standard units.

 

When testing the new Unit Editor I extracted the archive “war3.mpq” from the Warcraft III directory to another directory which I used as source path. The class “MpqPriorityList” can handle multiple sources (directories, MPQ archives etc.) to allow accessing files following the priority of the sources.

For example if the archive “War3Patch.mpq” is added to the priority list with a higher priority than “war3.mpq” it will first look into “War3Patch.mpq” for the file “UI/WorldEditStrings.txt” when requested and afterwards into “war3.mpq”.

This allows you a very simple access to files which come from multiple archives/directories and made debugging really easy.

Now let’s look at some screenshots (the translations are in German and directly loaded from Blizzard’s own provided files):

Unit Editor

Creeps in Unit Editor

Import Units From War Chasers

Unit Editor War Chasers

Unit Editor Missiles

Future

When it is done, the object editor should provide more features than the original from the World Editor. It should provide a better search function with more filtering options, easier import/export functions, merging functions, exporting as SLK support and allow the user to modify SLKs for weather effects and other types as well.

But the main reasons why it could be useful to have this one as well is simply to have a standalone Object Editor which allows running multiple instances in an Unix environment (as well as Windows) and to have the ability of writing extensions which might help handling huge amounts of object data.

I think these points will really help developing Warcraft III maps in the end. For basic usage the normal Object Editor is just fine but I myself had often problems with its limited functionality (even if just a function like “Insert Color” is missing in the tooltip editor).

Note that I am a bit late with my version since this one is out for quite some time but it still requires Windows or .NET.

 

Btw. I’ve improved the MPQ support as well which made it possible to test all SLK and TXT files easily. Besides I’ve written a simple MPQ Editor module which I hopefully will write about in the next article.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: