Entities are the "active" objects of Anachronox. Things like monsters, weapons, powerups, triggers, etc. are all entities. Each entity in Anachronox has a specific task that is hard coded, either in the regular Anachronox engine or as a separate add-on modification. Additionally, there are two different types of entities: point entities and solid entities.
A point entity is an entity that has a model preassigned to it. For example, a monster. The monster does not require the user to create the physical representation of the monster or its movement. This has already been done by the entity creator. When you place a monster entity in your editor, Anachronox automatically puts the monster in its proper place. Typically, this also means that if you use a box and make it a monster, you don't need to worry about the size of the box, since it will be replaced by the appropriate model when Anachronox runs. Some examples of point entities: monsters, lights, health, player starts and powerups.
A solid entity is an entity where the level designer does have to give a solid geometry in order for the entity to work. An example of this is a door. You have to make a door the size and shape you want. The advantage of having to define the solid for the entity is to allow a greater design range for which to create those entities. For example, you may want a double door rather than a single door, so being able to define this gives you that option. Examples of solid entities are: doors, triggers, buttons, trains, and platforms.
A common thing about all entities is that certain things need to be defined for each entity in the level to modify the behavior of that entity. For example a trigger isn't much good if you can't tell what is to be done by that trigger. So, each entity has properties that can be defined by the user. These properties are known as KEYs.
Not all entities listed here have been tested. Some of the information partaining to an entity could be incorrect. Others may not work at all. I have been trying to test each entity and update the list as I go.
NOTE: Too COLOR, or too _COLOR? That is the question.
A KEY prefixed with an underscore means that the KEY will be ignored if the default is not applicable. This is why "color" works here as well as "_color". It's good practice to always include the underscore, even if it works without it.