Interpreting the messages

The basics

When you run Entifier, it is probably going to generate some messages. Maybe a lot of them. Not every message will require action on your part; but you should examine each message in turn and decide whether or not you need to do something about it. You may want to fix some entities, or add or change some annotations. Then run Entifier again. Repeat this cycle until the only messages generated are ones that you have already taken care of or decided not to worry about. Note that the warning messages can change if you change the arguments to Entifier (specifically --nowrite, --nocctf, and --nota).

Setup

There's not really any setup per se for the things discussed on this page, but if you want to save the messages for later viewing, and/or you expect to generate more messages than will fit in the scroll history of the window where you are running Entifier, then make sure you redirect the output to a text file. All of Entifier's non-fatal messages are printed to the standard output stream to make this super-easy. In all the shells I can think of right now, the format for redirecting the output to a file would be the same; just add "> entifier_output.txt" to the end of the command line that invokes Entifier, and you're all set. (Naturally, you don't use those quote marks, and you can name the text file whatever you want.)

Checking the arguments

The first thing Entifier prints out is all the settings it will be using. The first time you run Entifier on a particular map, or if you have changed some arguments since the previous run, you should eyeball this section and make sure it looks OK.

Warning messages

Next up, possibly, is a sequence of warning messages. These are numbered just for reference; the numbering doesn't have any meaning. Below is a table of commentary on some of the warning messages. Most warnings are self-explanatory and need no comment. I would recommend just using this table as reference when dealing with specific warning messages, as it won't make much sense when read by itself.

00The contents of the "message" key of the worldspawn entity is used as the title of the map for the Web page; therefore it's a problem if this key does not exist.
03An entity targetted by a target_give is probably something that players get when they respawn; that's worth noting in a floating label. Since the entity has been removed, don't put the label on the entity; what I do is put it on the target_give, with an x/y position and appropriate icon type specified (see q3wxs2). As for the other part of this warning message: an entity "targetted by nothing" is probably a map error (its "targetname" value was not found in the "target" of any other entity). Yes, I should have separated this into two different warning messages.
04The chain referred to in this warning is a sequence where one entity's "iconloc_target" points to another entity's "iconloc_targetname", and that entity itself has an "iconloc_target" that points to some other entity's "iconloc_targetname", etc. This is legal (as long as you don't create loops) but of course eventually it should end pointing to an "iconloc_targetname" value that does indeed exist on some entity.
05Ditto the above, with the added stipulation that the target entity must have an "origin" value, since after all the point of using "iconloc_target" is to copy that origin.
06As discussed previously, a trigger_teleport entity must be annotated in some way to specify its location, or Entifier cannot place an icon for it.
08Teleporters don't always need to be labelled, as discussed previously, but often they should be to avoid confusion.
09You'll only get this warning if you are using something other than a misc_teleporter_dest as a teleporter destination. (Bad! Bad!) This warning is just a heads-up to make sure that the teleporter dest is properly labelled if a label would be needed. (This item might already be labelled, but Entifier has no way of knowing if that label applies to its capacity as a teleporter dest).
10Teleporter dests don't always need to be labelled, as discussed previously, but often they should be to avoid confusion.
11If you have an item that is triggered by something other than target_give, Entifier will go ahead and place an icon for it on the map, but if there is some odd entity spawning behavior going on there you may want to use a label to explain it.
12You have multiple labels showing up at the same time for a set of teamed items. This may or may not be what you want to do (probably not, though). See the discussion at the end of this section about teamed items.
13You have a situation where teamed items are being displayed without a label (as far as Entifier can tell by checking the labels attached to those items). See the discussion at the end of this section about teamed items.
14You have a situation where a label attached to an item in a team is being displayed when the teamed items are not being displayed. See the discussion at the end of this section about teamed items.
18The usual red/blue flag gametypes for TA are "ctf oneflag", so the flag shows up in the same spot for both ctf and oneflag, and doesn't show up in any other gametypes. So that's the gametype key value that Entifier checks for. It's possible that you would want to put a flag in one position for the ctf gametype, and another flag of the same type in some different position for the oneflag gametype, but unlikely.
21Similar to the above comment, for red/blue obelisks.
24Similar to the above comment, for the neutral obelisk.
26It's a common misconception that you need an info_player_start in your map. If you have the other entities set up properly, you don't. It's custom, though, so Entifier warns if it is missing.
55This warning usually indicates that you should have a floating label about unusual item respawn times. (When setting the label gamelist, remember that weapon respawn times are ignored for the Classic CTF gametype.)
56Similar to the above comment; in this case, the unusual factor is not the base respawn value, but rather that it has a random component. The floating label should note the range of possible respawn times (base-random to base+random), as with the q3wc3 megahealths.
57Whoops; you specified the "--notta" argument, but your map contains at least one entity that only shows up in TA play.
58As above, but for "--notcctf"
59You specified both "--notta" and "--notcctf", but your map contains at least one entity that only shows up in either TA play or CCTF play.

One thing to keep in mind is that sometimes Entifier is specifically reporting the fact that an entity does not have a label (or does not have a label with the correct gamelist/typelist), and at other times it is just reporting that an item is odd in some way, and that you may want to make sure that you have a label that describes it. In the former case, adding the requisite label makes the warning message go away. In the latter case, adding a label somewhere to describe the odd item does not make the warning message go away, because of course Entifier can't actually read and understand the contents of your label texts to see what they are talking about.

The item teams analysis

The last portion of Entifier output begins with the line "*** item teams analysis ***". If there is nothing after this line, then there are no teamed items in your map, and you don't need to worry about this part.

However if you do have teamed items in your map, then you'll see some more information describing them, and possibly some of the warning messages. There is a separate block for each team; it starts with the team name, and then lists each item (starting with the team master), its origin, its icon type, and its gamelist. That is followed by any warnings related to labelling this team. It's important to keep in mind that Entifier bases its team labelling warnings on the assumptions that any labels on team items are for the purpose of describing the team, and that no labels elsewhere are describing the team. If this isn't true then you should take the warnings with a grain of salt.

Here's a simple example of an item teams analysis. This is from processing an unannotated version of q3wcp1's entities:

*** item teams analysis ***

Team name: red-power
   item_quad at <-1748 -1564 48> -- (p) ctf cctf ta_ctf ta_oneflag ta_overload ta_harvester
   item_regen at <-1748 -1564 32> -- (p) ctf ta_ctf ta_oneflag ta_overload ta_harvester

WARNING 13: Unlabelled team items
entities: item_quad item_regen
for:
(p) ctf ta_ctf ta_oneflag ta_overload ta_harvester


Team name: blue-power
   item_quad at <1752 1604 48> -- (p) ctf cctf ta_ctf ta_oneflag ta_overload ta_harvester
   item_regen at <1752 1604 32> -- (p) ctf ta_ctf ta_oneflag ta_overload ta_harvester

WARNING 13: Unlabelled team items
entities: item_quad item_regen
for:
(p) ctf ta_ctf ta_oneflag ta_overload ta_harvester

So, there are two teams of items in the map. The indented lines under each "Team name" header tell us that each team consists of a quad and a regen, each of which uses icon type "p"; the quad shows up in all gametypes, and the regen shows up in all gametypes except for Classic CTF.

The warning messages are to let us know that these teams are unlabelled. The warnings say that there are quad/regen teams that are unlabelled for certain icon types and gametypes. Note that in the list of gametypes shown by the warning messages, cctf is not included. This is because in cctf, the regen doesn't appear, therefore there is no "item team" in cctf, just a quad, and a label about an item team should not be shown in cctf.

Basically what you need to do is add one label for each warning message. Attach the label to an item on the team that it is labelling, and choose a good docking behavior for it. The mechanical approach to making this label display correctly is to specify a "label_typelist" key with the type(s) indicated by the warning message, and a "label_gamelist" key with the gametype(s) indicated by the warning message. So to satisfy one of the warning messages from the above example, we could attach a "label_comment" describing the team to either the quad or the regen in a team, add a "label_typelist" of "p", and a "label_gamelist" of "ctf ta_ctf ta_oneflag ta_overload ta_harvester".

However this degree of specification is almost always not necessary. Remember that labels inherit their icon type and gamelist from the entity that they are attached to. Now look at the icon type and gamelist in the warning messages above; hey, they're exactly the same as the icon type and gamelist for those regens, which makes sense, because the regens appear if and only if there is an actual item team active in a gametype. So in this case, that means all you need to do is attach an appropriate "label_comment" to each regen, and you're done. Look in the example entity list for q3wcp1 and you'll see that's exactly what I did. Below is the regen entity from the first team, after adding the label (and also adding "iconloc_trackmaster" to keep it lined up with the icon for the quad from that team).

{
"origin" "-1748 -1564 32"
"classname" "item_regen"
"team" "red-power"
"wait" "120"
"iconloc_trackmaster" "1"
"label_comment" "Q/R"
}

I mentioned before that q3wcp7 had probably the hairiest item teaming situation in the Threewave maps; so, as an "advanced example", here's what the item teams analysis looked like for the unannotated version of that map:

*** item teams analysis ***

Team name: 1
   holdable_kamikaze at <512 -1320 928> -- (p) ta_oneflag ta_harvester
   item_armor_body at <511 -1320 928> -- (a) ta_ctf ta_oneflag ta_overload ta_harvester
   holdable_invulnerability at <512 -1320 928> -- (p) ta_ctf ta_oneflag ta_overload ta_harvester

WARNING 13: Unlabelled team items
entities: holdable_kamikaze item_armor_body holdable_invulnerability
for:
(a) ta_oneflag ta_harvester
(p) ta_oneflag ta_harvester

WARNING 13: Unlabelled team items
entities: item_armor_body holdable_invulnerability
for:
(a) ta_ctf ta_overload
(p) ta_ctf ta_overload


Team name: 2
   holdable_kamikaze at <512 -1320 480> -- (p) ta_ctf ta_overload
   item_health_mega at <512 -1320 480> -- (p) ctf cctf ta_ctf ta_overload

WARNING 13: Unlabelled team items
entities: holdable_kamikaze item_health_mega
for:
(p) ta_ctf ta_overload


Team name: 3
   item_quad at <511 -1320 1004> -- (p) ctf cctf
   item_armor_body at <511 -1320 1000> -- (a) ctf cctf

WARNING 13: Unlabelled team items
entities: item_quad item_armor_body
for:
(a) ctf cctf
(p) ctf cctf

You can check the example entity list for this map to see how I annotated those teams. Below is the kamikaze entity with the label I added to take care of the first warning message. The kamikaze already had the correct gamelist for the label, so I didn't need to specify this. However the warning message said that the label was both for icon type "a" and also for type "p" (since both armor and powerups were in the team); the kamikaze is only type "p", so I had to specify a "label_typelist". The "high" at the end of the label text, by the way, is there because this label is doing double duty -- both as a teamed items label, and also as a label dealing with overlapping icons caused by items at different heights (this item team is above the neutralflag or skull generator).

{
"notq3a" "1"
"origin" "512 -1320 928"
"gametype" "oneflag harvester"
"team" "1"
"classname" "holdable_kamikaze"
"label_comment" "KAM/RA/INV high"
"label_typelist" "a p"
}

(Anyone who actually checks this entity in the q3wcp7 entity list will note that it doesn't look quite the same as above. To avoid confusion, when transcribing the entity above I corrected some errors in the other entity keys, which weren't relevant to the discussion of the label.)

The bottom line, really, is that even with the weirdest teamed items setup, the warning messages should tell you exactly how to label the item teams. You can explicitly specify the typelist and gamelist for each label using the values shown, and the results will be correct. Most of the time though you don't have to do that, as you can be crafty and make sure you stick the label on the team item that will cause it to inherit the correct values for those keys.

If you mess up the labelling, warning messages will tell you -- warning 12 for redundant labels, and warning 14 for labels that are showing up at just plain the wrong time. Remember though that you're the final authority on what is right and wrong. Case in point: for my final annotated version of q3wcp7's entities, I still get a warning 14, because I have a label on that item_health_mega that shows up in the ctf and cctf gametypes. You'll note that since the kamikaze doesn't appear in those gametypes, the mega isn't really part of an item team in ctf and cctf; therefore Entifier nags that it shouldn't be showing a label. Fact is, though, that particular label doesn't have anything to do with describing an item team; instead I'm using it to describe overlapping icons. So it's fine the way it is.

< Creating a Web pagePackaging for upload >