Custom Meta Data SLKs

[Barade]

As you might know much of the data in Warcraft III is build up on SLK files which define values for fields of objects.

For some of this data there are meta data SLK files such as "Units/AbilityMetaData.slk". Those files describe the fields with a four letter ID such as "unam" and define the data type etc.
This meta data is used by the object editor to display the GUI properly and to show editing dialogs.

Since I am creating my own Object Editor for my project wc3lib: http://www.hiveworkshop.com/forums/tools-560/wc3lib-275380/

I had the idea to provide more meta data files. At the moment I have initial versions of WeatherMetaData.slk and WaterMetaData.slk. Therefore I have two more tabs in the Object Editor for weather effects and water.
Of course the object data cannot be saved in .w3o files. It can only be exported as SLK data itself and merged with the existing (Widgetizer) but since my Object Editor should provide this functionality as well there is no problem here.

My question is: What do you think about this and do you have any suggestions for more meta data?

Probably editing some of this stuff by just adding setting values without a graphical editor might not be that useful.

Some more suggestions:
- Unique field IDs (at the moment I am using field IDs like "texf and "mred", Warcraft III uses always a fixed first letter depending on the object type, therefore I would have to define a fixed unused letter for every object type as well)
- Tileset Editor/Cliff Types Editor
- Preview Window (knowledge is required what the single fields actually mean and how for example the water/tileset stuff is displayd properly)

 

[WaterKnight]

lightnings, ubersplats, splats, terrain, cliffs, ...

The native types are no problems but the meta slks in their uniformity may also be enough for user types, which I would like to have in my object editor. lep, on the other hand, wants to textually script objects solely similar to how wurst does it without GUI. I think both can be done.

- Unique field IDs (at the moment I am using field IDs like "texf and "mred", Warcraft III uses always a fixed first letter depending on the object type, therefore I would have to define a fixed unused letter for every object type as well)

That's not entirely true. You probably refer to custom objects and even there units use multiple ones depending on the type/hero state and there are special abilities that use "S" besides "A". Also a lot of the alphabet letters are used already by various, spread original objects, yet I do not think that a unit for example evokes problems by colliding with terrain ids.

 

[Ezekiel12]

I think additional meta data files should not be added.

- Effort required for the different files could be spent on doing useful things
- The new meta .slks would only have one .slk they are corresponding to
- also they have less fields(columns), which have quite recognizable names, no need for more aliases. For a real explanation a name field is not enough, so a help file or hover over is needed anyway
- and less entries(rows), which makes it fitting for

giving just direct editing access to those .slks. Basically an enhanced MPQ editor in the WE. While I'm at it, opening more than one MPQ for easy drag and drop of files would be even cooler. Ofc all with the ability to preview textures/models/etc..

 

[WaterKnight]

There is not much effort other than you maybe learn what the individual fields actually do. If you only have an slk editor, you can enter anything and therefore have no sanity checks and can aid less because e.g. you do not know that this field hosts a model -> no automatic model selection/preview. It's used for sorting as well or verbose identifiers like you requested a help function. The extra meta alias does not matter, you can just show the real name in the object editor.

 

[Dr Super Good]

It is worth noting that many of those files, eg water, provide data for all Warcraft III and not just a single map. As such in theory only 1 entry in the SLK file is needed, the entry for the tileset the map uses. Saving any other entries, or retaining data for the other entries if they are required to exist is a waste of space.

As such the UI for those types of data within a map could be simplified to a single entry, which always corresponds to the tileset currently in use. The exception is a campaign editor where if the SLK files can be inherited it then shows all entries for all tilesets.

 

[Barade]

And it is possible to replace the terrain data slk with a single map? But would it reduce the loading time? Is the file or the war3x.mpq for terrain data loaded everytime I start a map?

I think it is generally a good idea even if it takes some time because it prevents users from adding wrong entries to the slks and shows some previews. The hard part is to understand what the fields actually mean. It would be cool if there was some specification for all SLKs.

 

[Dr Super Good]

And it is possible to replace the terrain data slk with a single map? But would it reduce the loading time? Is the file or the war3x.mpq for terrain data loaded everytime I start a map?

It is loaded when the map loads, at least the first time. Cutting it would mostly save a kilobyte or so of file space rather than load times.