This ProtocolZero query is much like rf, except that it is designed for large-scale image acquisition. Normal rf returns only one sample per command, and thus a user attempting to get a large number of samples by sending many queries to it at a variety of angles suffers poor performance and risks overflowing the Quagent's command queue. rb improves upon rf by allowing the user to specify a region of samples with only a single command. High-resolution data can take some time to write: the game will appear to hang while it does. On machine "e33" in the lab, this command can acquire about 250,000 samples per second (so, for example, it takes 2 seconds to get a 720 by 720 area).

It is useful to think of rb as returning a raster of duples. (An image interpretation of such a raster is shown below.)

(In the above image, the striped area represents another entity (in this case, a player) in the environment, while the walls are greyscale. White areas are further from the bot, while black areas are close. The uppermost row of the image corresponds to a pitch of 45 degrees up, and the bottom row is 44.5 degrees down. The left side is at -90 yaw from the bot, and the right side at +90.)

However, this should not be thought of as returning a picture from the point of view of the bot for the following reasons.

• rb returns a number of samples generated by accumulating sample_deltas. Increasing YAW makes the bot turn left, so for positive sample_delta_yaw, subsequent samples are more to the left. This is not the standard image coordinate system where increasing samples in the X direction are to the right. In other words, the "image" would be flipped horizontally from what the bot would actually "see".
• rb generates the image by a process that is suggestive of a fisheye lens, not a linear projection. For example, it is possible to have a raster that contains the results of rays looking directly ahead and behind, an impossible perspective for linear projections. Wall seams will appear curved, etc. Turning 90 degrees left in the game and rerunning the command returns a translated version of the image, not a different image.

Parameters:

• 1: integer type, selecting the type of rangefinder to use. A "solid" as used below means a wall, floor, ceiling, etc.
  • 0 = an infinitely narrow beam that is only stopped by permanent surfaces that will stop the player (usually just walls, floors, ceilings, and moving platforms, never other quagents or rockets or powerups).
  • 1 = an infinitely narrow beam that is blocked by anything that would block player movement (like mode-0, but plus other things like quagents).
  • 2 = an infinitely narrow beam that is blocked by anything that would block a shot (often equivalent to mode 1, but on some levels (like suspended), there are walls/floors that can be shot through but not walked through).
  • 3 = an infinitely narrow beam that is blocked by anything in the environment (like mode-1, but plus powerups or other things that can be walked through).
  • 4 = a wide beam the size of a quagent that is blocked if any part of it is blocked by something that would block a mode-0 rangefinder.
  • 5 = a wide beam the size of a quagent that is blocked if any part of it is blocked by something that would block a mode-1 rangefinder.
  • 6 = a wide beam the size of a quagent that is blocked if any part of it is blocked by something that would block a mode-2 rangefinder.
  • 7 = a wide beam the size of a quagent that is blocked if any part of it is blocked by something that would block a mode-3 rangefinder.
• 2: integer distance, the maximum distance of the rangefinder. There is no particular penalty to supplying very large distances that we can find - the maximum distance we've seen this call used with in Quake is 8120, the range of the rail gun.
• 3: float theta, the number of degrees left of facing to start shooting the rangefinder at.
• 4: float phi, the number of degrees down from facing to start shooting the rangefinder at.
• 5: int width, the width of the returned raster (how many YAW-variant samples to take).
• 6: int height, the height of the returned raster (how many PITCH-variant samples to take).
• 7: float sample_delta_yaw: how far apart (in degrees) two samples differing only in YAW should be.
• 8: float sample_delta_pitch: how far apart (in degrees) two samples differing only in PITCH should be.

Responds:

• n X1 E1 X2 E2 X3 E3... Xn En where n is the number of samples (width*height) in the raster. Each Xi is the range at which the rangefinder stopped, and each corresponding Ei is the entityid of the entity that stopped it (or -1 or -2, see rf).

Reports:

• done when the task completes.
• replaced if another task with replacement scheduling replaces it.
• popped if popped by po.
• forgotten if deleted by fa or fm.
• replaced if replaced by a command scheduled with 'r'.

Example:

• User sends: "n rb 512 1 6000 -90 0 5 1 45 0"
• Bot replies "rs rb 512 5 65.2 -2 70.4 -2 200.2 2 100.33 -2 55.3 -2"
• Bot replies "cp rb 512 done"

The following illustrates the difference between rangefinder modes. Please note that none of the pictures have the exact same scale in terms of white to black. Both pictures, however, are of the exact same scene, and were gotten by "n rb 0 [MODE] 20000 -180 -90 360 180 1 1".

Mode 0	Mode 1
Mode 2	Mode 3
Mode 4	Mode 5
Mode 6	Mode 7

While the first image has more detail, the second image is more useful for navigation - objects appear wider because the Quagent is considering how far it can move before it collides with them. In the second image, a single pixel of room around an obstacle indicates that it can be moved through, whereas the first image does not take into account the bounding box size of the Quagent. (By the way, the scale on the images is independent: there are pixels on the second that are brighter than their counterparts on the first (even though the rangefinder returned a close value) because the way I drew these was to just put white at maximum distance and black at minimum, and the second image has a narrower range of values.)