The info_rotate isn’t really a Quoth entity at all, it doesn’t do anything in the mod. For a tutorial-style guide to what it’s for, read CZG’s guide to creating rotators or the rotate_object entry. What follow is technical info on how they work.
One of the surprising things about brush entities in quake is where their origin is in the map. For normal entities like monsters, weapons and players, their origin is roughly at their centre of mass – and certainly falls inside their bounding box.
Brush entities are entirely different. Regardless of their placement in the map, the origin of a brush entity starts at ‘0 0 0’, lined up with the world origin. When a door moves 128 up, its origin updates accordingly to ‘0 0 128’. It’s easiest to think of brush entity origins as being in “relative coordinates”, the displacement of the entity from her starting point. If you need a centre of mass coordinate for rocket damage or similar, you have to calculate it manually, using the bounding box coordinates.
Rotation is the one time that you need to worry about the absolute origin of a brush entity. If you rotate a model in Quake by 20°, the centre of rotation is always the origin of that model. For a brush entity several thousand units from the origin, this rotation moves it a very long way! Trying to translate to compensate for this would be difficult and probably noticeably inaccurate.
However, if we imagine a door which by coincidence is centred on the origin of the map, this entity would rotate in a sensible way that meets our expectations. Even if we then displace the door by hundreds of units it will still rotate around the centre of the brush, because the door’s origin will have moved by the same amount as the door. However, we don’t like the idea of having to build all of our rotating entities at the centre of the map, and then specifying the offset to their starting point manually.
This is where the compiler helps us out if we set up our entities carefully. If we give the brush entity a classname of rotate_object and make it target a point entity of classname info_rotate, the compiler will make a brush model which has its origin in line with the info_rotate, but starts in the position of the original rotate_object. It does this by selecting all the brushes and the info_rotate, then translating them until the info_rotate is positioned over the origin. Once the brushes are compiled, the entity is given an “origin” key set equal to the info_rotate’s origin.
The origin key makes sure that the brushes appear in the right location in the map, but this behaviour has other side effects. Most important is that the textures are not locked while the move takes place, so they might end up compiled strangely. The lighting tools also have to work around this strange entity which appears to have moved by magic.
To close, I’ll just mention a few little extra tips about exactly which entities aguirRe’s compiler will give this special treatment to:
- His compiler will consider any entity whose classname begins with rotate_ for displacement. At the moment this doesn’t matter for Quoth, where rotate_object is the only accepted classname.
- It will also accept any class of point entity to mark where the origin should be – not just info_rotate. It only needs to be targeted by the rotate_ classed entity.
- Other compilers may not be as flexible, I am sure that at one point info_rotate was the only classname you could use.