Annotating your map entities

The basics

Now you have a map overview image ready to go. The other major ingredient you need to generate the overview page is a description of the entities in your map; most likely you will just use your .map file for this. So it would be possible to just go ahead and generate the overview page at this point.

However, first you may want to work with your entities a little bit to adjust the position of the icons that will represent them, or to add labels to clarify certain situations. You do this by adding special key/value pairs, which we'll call annotations, to the entities. If you're experienced with using this system you'll likely think of some obvious annotations you want to add even before the first time you use Entifier on your map. If you don't, though, that's perfectly fine; skip this step and move on to generate the overview page, and Entifier will suggest some possible annotations you may want to do (although it will not be able to catch every situation in which you might want to add a label -- it doesn't look for overlapping icons). You can then come back to this step, make some changes, and then run Entifier again.

Setup

As mentioned above, annotations are just entity key/value pairs. So if you're generating an overview for your own map, presumably you have access to the .map source file, and you can add annotations either using the entity dialog in the map editor, or else by editing the .map file directly with a text editor if you're comfortable with that. So no problems there.

However, if you happen to be generating an overview for someone else's map and you don't have the .map file available, then you can use a utility called q3wumpas to extract an entity list from the .bsp file. Once you have this entity list, you can basically treat it as a .map file that only contains entities (no brushes) -- which is fine, since it's the entities we're concerned with, but the lack of brushwork can make it difficult to find the precise entity that you want to fiddle with, especially for brush entities like teleport triggers. You can deal with this problem to some extent by using bspc to convert the .bsp file into a .map file that has both entities and brushes (but no texturing). The bottom line is that it's a tricky process and I won't go into any more details about it here. I assume most people will be interested in working with their own maps anyway, which means you'll have access to the real .map source file and this whole paragraph is a moot issue.

The essentials

The simpler annotations deal with icons.

So it's time for a short spiel on icon placement. Entifier will place an icon by taking the center of the bottom of an entity's bounding box and perspective-projecting that position onto the map overview. This results in very accurate icon placement, which is good, but that means that minor errors in entity position will be visible -- and that includes vertical positioning problems, since it is a perspective projection. Some of those problems can and should be fixed by correcting the position of the entity itself, but maybe in some cases you'd rather just tweak the icon position. And there are other reasons you might need to fiddle with the icon as well. These are the available keys for doing so:

Caveat: if you use these keys to "match origins" between two entities, you're not necessarily forcing the icons for those entities to be shown in exactly the same spot (assuming both entities are displaying icons). This is because, as mentioned above, the icon position isn't at the entity origin, but rather down at the bottom of the entity. So if two origin-matched entities have bounding boxes that extend down to different levels, their icons may not be placed at quite the same spot. Usually this is not a problem because almost all entities have exactly the same bounding box, with the origin dead center. However if it becomes a problem, keep in mind that you can match origins with any entity. For example you can use "iconloc_target" and "iconloc_targetname" to link an entity to an info_null entity that you have created explicitly for this very purpose, and then put that info_null entity wherever you please.

OK, now for labels. Labels are a little more complicated.

A label (the value of a "label_comment" key) normally appears to the right of its entity's icon, and it appears in only the selected game types and icon type for which the icon itself appears. However, it's possible to change all of that by using additional annotations.

It's also possible to have more than one label associated with an entity, by adding the same suffix to all of that entity's label-related key names that should "go together". For example: you could have two different labels for one entity by giving it a "label_comment_1" key and a "label_comment_omega" key; and you could change the docking behavior of the first label with a "label_docking_1" key, the gametypes for the second label with a "label_gamelist_omega" key, etc.

The label keys listed below are shown without suffixes. You don't have to give them any suffix if you are only putting one label on an entity (which is the usual case).

The distribution includes as examples, in the "entity_lists" folder, the original entity list from every Threewave and idctf map, and the modified (annotated) entity list that I used to generate the overviews. These examples can hopefully be used in conjunction with the overviews themselves to get a feel for how to handle annotations. Note that I was working with completed maps for which I did not have the .map source file, so in a few cases I solved problems differently than I would have if I had been working on my own map. But still these files should be an occasionally useful reference.

At this point it seems like it's time for me to say that using these entity keys is more an art than a science, but really that's not quite true; I actually had a fairly specific set of rules that I followed. I'll lay those out below, best as I can remember. It's quite a data dump on first viewing, but after working with the system a little it should make a lot more sense.

Good practices: entity placement

As you have probably gathered, it is best to place your entities where you want them to be in-game. Don't place the entity way up in the air and rely on the fact that Quake 3 will "drop the entity to the ground"; instead, place it on the ground, and its icon will then show up in the correct spot. For teamed entities you can slack on this, of course, as long as the team master is in the right spot (you can use "iconloc_trackmaster" for the other items in the team).

Good practices: teleporters

Teleporters (trigger_teleport entities) are annoying because they are brush entities, and brush entities don't have a handy "origin" key that shows where they are. This means that an icon for a teleporter cannot be placed on the overview unless you intervene with annotations to tell Entifier where it is.

One way to do this, of course, is to manually add an "origin" key to the trigger_teleport. If you go this route it's good to pick a point on the bottom of the trigger brush, either on the leading edge (for teleporters against a wall) or in the center (for midair teleporters). This will work fine. However, if you ever move that trigger_teleport, the origin you specified will not be automatically adjusted, and the icon will then be in the wrong place on the overview. (Obviously this is not a concern though if you are working with a finished map.)

If your teleporter has a misc_model sitting in the same spot, then there's an easier solution. Just use "iconloc_target" and "iconloc_targetname" to link the trigger_teleport's location to that of the misc_model. If you don't have a misc_model there, perhaps consider putting an info_null at a good origin spot and iconloc-linking the trigger_teleport to that... then it's easy to select that info_null along with the teleporter if you ever need to move the teleporter.

Now, about labelling teleporters. If the teleporter entrance and exit are very close to each other, and far away from any other teleporter entrance/exits, then there's no confusion about what is going on, and no need to label them (as in q3wcp2). If labelling is needed, however, then the Threewave practice is to use letters like so: a teleporter entrance is labelled "A", and its exit is "A out"; another teleporter entrance is "B", and its exit is "B out"; etc. The map overview page for q3wcp6 has an example of some simple teleporter labelling like this. Since teleporters (and their labels) are always shown, you really want to avoid overlapping their labels with any other icon if at all possible.

If a teleporter entrance and exit are right on top of each other, use iconloc keys to make sure that the icons are exactly on top of each other, and only label one of the icons. q3w7 shows some simple bidirectional teleporters. q3wc7 displays the most complicated teleporter setup among the Threewave maps. See also the floating label in the TA oneflag and harvester gametypes for q3wcp1, for a complete cop-out.

Good practices: label positioning

Choose a docking behavior for a label so that it does not significantly overlap with other icons of the same type as the one it is attached to, or with an "always displayed" icon (type "m" or "f"), which in the default entity configuration are flag/generator/teleporter/teledest icons. If you can't avoid such overlapping, consider using "label_x" and "label_y" to make it a floating label positioned in the upper left corner of the overview.

If it turns out that you can avoid that kind of overlap with either style of docking, another consideration is to try to avoid overlapping other types of icons. If you can't avoid that, though, that's OK.

Good practices: floating labels

The most common uses of floating labels in the Threewave overviews are notification of nonstandard item respawn times and notification of players getting stuff when they spawn, but there are several other uses. In q3wcp3, when weapons are selected in TA oneflag or harvester, the floating label tells about some teamed weapons, rather than putting the label next to the weapons themselves (too crowded). q3wc7 also shows an example of dealing with teamed items, this time teamed quads; since the quads are important and widely separated, the label indicates which one spawns first (the team master). The armors in CTF mode in q3wcp15 are described by a floating label as well, but their initial spawn is randomized so there's no need to indicate the team master. q3wcp2 has a floating label to describe the idiosyncratic behavior of the TA powerups.

Floating labels should of course only be displayed when they are appropriate to the game and icon types currently selected. Usually this is easy to do; just put those label keys on the entity that the label is talking about. An example of where this is not sufficient: if the label is talking about weapon respawn times, those don't matter in Classic CTF, so it should have a "label_gamelist" that omits cctf (unless the entity is a TA-only entity, which naturally avoids the CCTF gametype). And q3wc3, q3wcp3, and q3wcp9 have other examples of labels that, for maximum clarity, need to say different things for different gametypes, accomplished by using suffixes to attach multiple labels to an entity.

All the floating labels in the Threewave overviews use an x coordinate of 100. The y coordinates start at 50 and increment in steps of 25 if there is more than one floating label for the map. And in that case, the labels are ordered so that they will appear from top to bottom if a user is enabling the icon type buttons from left to right. q3wc3 is an example of this.

Good practices: overlapping icons

If one entity is above another entity in the map, on the overview their icons will be at about the same position. If these icons are of the same type, or if one of them is an "always displayed" icon, then the overview user will not be able to get a clear look at the individual icons just by disabling the viewing of various icon types. Therefore the icons should be labelled to identify them more clearly. (Unless they're both the same icon, in which case there's not much confusion.)

Usually one label docked to the right of the "high" item, and one label docked below the "low" item, is the best way to go, as with the GL and RL in q3wcp3. (You can of course dock either label to either entity if necessary to make things look better.) If you can't place both labels without breaking the label positioning guidelines, then try placing just one label to describe the situation, like in the weapons for the TA gametypes on q3wcp9. If you can't even do that without breaking the label positioning guidelines, then use a floating label or just ignore the problem.

Rarely, multiple items may really exist in the same place at the same time, which is another cause of overlapping icons. The quad and the center flag in TA oneflag mode on q3wc2 is an example of this. If the icons are of the same type, or if one of them is an "always displayed" icon, it's good to add a label to clear things up, if you have the room.

Good practices: teamed items

Teamed items should always have a label showing that the items are teamed, and listing the items in the team. There are many examples of this throughout the Threewave overviews. The rules for a team label are 1) it should only be displayed for a particular gametype if there are actually multiple different item types on the team that will spawn in that gametype, and 2) it should always list all items in the team, even if some of them have icon types that are not currently selected.

For most teams this is dead easy. Usually a team consists of powerups, of which only quad will show up in Classic CTF. So if there are other types of powerups in the team, attach the label to one of those other powerups, and the label will only appear in non-CCTF gametypes. See q3wcp1 for one example among many.

The most complex teaming in the Threewave overviews is the center team (or teams) on q3wcp7. It mixes different icon types and changes across gametypes and throws in icon overlapping issues for good measure. The weapons in TA gametypes on q3wcp8 are a close runner-up. If you understand all of what is happening with the labels in both those maps, you have achieved team labelling zen mastery. Fortunately you don't really have to figure the team labelling out ahead of time, as Entifier will tell you what team items need to be labelled and how. This is described later in the manual.

Good practices: label format

For clarity's sake, when writing the text of a label, try to use the same wording, punctuation, and item abbreviations as used in the Threewave overviews for a label of the same purpose. To recap: although there are many different types of labels in the Threewave overviews, most of them could be categorized as being for one of six purposes, shown below with some example texts.

< Generating the map imageCreating a Web page >