#include <global.h>
#include <math.h>

Include dependency graph for los.c:

Data Structures
struct	blstr

Macros
#define	SPACE_BLOCK 0.5

Typedefs
typedef struct blstr	blocks

Functions
static void	blinded_sight (object *op)

static void	check_wall (object *op, int x, int y)

void	clear_los (object *op)

static void	expand_lighted_sight (object *op)

static void	expand_sight (object *op)

int	has_carried_lights (const object *op)

void	init_block (void)

void	make_sure_not_seen (const object *op)

void	make_sure_seen (const object *op)

void	print_los (object *op)

static void	set_block (int x, int y, int bx, int by)

static void	set_wall (object *op, int x, int y)

void	update_all_los (const mapstruct *map, int x, int y)

void	update_all_map_los (mapstruct *map)

void	update_los (object *op)

Variables
static blocks	block [MAP_CLIENT_X][MAP_CLIENT_Y]

Detailed Description

This handles the "line of sight" for players and monsters.

Definition in file los.c.

Macro Definition Documentation

#define SPACE_BLOCK 0.5

Distance must be less than this for the object to be blocked. An object is 1.0 wide, so if set to 0.5, it means the object that blocks half the view (0.0 is complete block) will block view in our tables. .4 or less lets you see through walls. .5 is about right.

Definition at line 46 of file los.c.

Referenced by init_block().

Typedef Documentation

typedef struct blstr blocks

Function Documentation

static void blinded_sight ( object * op )

static

Sets all veiwable squares to blocked except for the one the central one that the player occupies. A little odd that you can see yourself (and what your standing on), but really need for any reasonable game play.

Parameters

op	player's object for which to reset los. Must have a valid contr.

Definition at line 450 of file los.c.

References pl::blocked_los, obj::contr, socket_struct::mapx, socket_struct::mapy, and pl::socket.

Referenced by update_los().

Here is the caller graph for this function:

static void check_wall	(	object *	op,
		int	x,
		int	y
	)

static

Used to initialise the array used by the LOS routines.

Parameters

op	player's object
x
y	Values based on MAP_CLIENT_X and Y that index the blocked[][] arrays.

Todo:: use player *instead of object *to show it must be a player?

Definition at line 220 of file los.c.

References pl::blocked_los, obj::contr, get_map_flags(), obj::map, MAP_CLIENT_X, MAP_CLIENT_Y, socket_struct::mapx, socket_struct::mapy, P_BLOCKSVIEW, P_OUT_OF_MAP, set_wall(), pl::socket, obj::x, and obj::y.

Referenced by update_los().

Here is the call graph for this function:

Here is the caller graph for this function:

void clear_los ( object * op )

Clears/initialises the los-array associated to the player controlling the object.

Parameters

op	player's object.

Todo:: use player *instead of object *to show it must be a player?

Definition at line 258 of file los.c.

References pl::blocked_los, obj::contr, MAP_CLIENT_X, and MAP_CLIENT_Y.

Referenced by do_wizard_dm(), get_player(), and update_los().

Here is the caller graph for this function:

static void expand_lighted_sight ( object * op )

static

Propagate the light information.

Parameters

op	player's object for which to compute the light values.

Definition at line 336 of file los.c.

References pl::blocked_los, obj::contr, FLAG_SEE_IN_DARK, get_map_flags(), GET_MAP_LIGHT, isqrt(), llevError, LOG(), obj::map, MAP_DARKNESS, socket_struct::mapx, socket_struct::mapy, MAX, MAX_DARKNESS, MAX_LIGHT_RADII, MIN, obj::name, mapdef::outdoor, P_OUT_OF_MAP, mapdef::path, QUERY_FLAG, pl::socket, obj::x, and obj::y.

Referenced by expand_sight().

Here is the call graph for this function:

Here is the caller graph for this function:

static void expand_sight ( object * op )

static

Goes through the array of what the given player is able to see, and expands the visible area a bit, so the player will, to a certain degree, be able to see into corners. This is somewhat suboptimal, would be better to improve the formula.

Parameters

op	player's object to process.

Todo:: use player *instead of object *to show it must be a player?

Definition at line 278 of file los.c.

References pl::blocked_los, obj::contr, expand_lighted_sight(), freearr_x, freearr_y, get_map_flags(), obj::map, MAP_DARKNESS, socket_struct::mapx, socket_struct::mapy, P_BLOCKSVIEW, P_OUT_OF_MAP, pl::socket, obj::x, and obj::y.

Referenced by update_los().

Here is the call graph for this function:

Here is the caller graph for this function:

int has_carried_lights ( const object * op )

Checks if op has a light source.

Parameters

op	object being checked.

Returns: true if op carries one or more lights

Note: This is a trivial function now days, but it used to be a bit longer. Probably better for callers to just check the op->glow_radius instead of calling this.

Definition at line 322 of file los.c.

References obj::glow_radius.

Referenced by can_see_enemy(), and hideability().

Here is the caller graph for this function:

void init_block ( void )

initialises the array used by the LOS routines.

Since we are only doing the upper left quadrant, only these spaces could possibly get blocked, since these are the only ones further out that are still possibly in the sightline.

Definition at line 102 of file los.c.

References FABS, blstr::index, MAP_CLIENT_X, MAP_CLIENT_Y, set_block(), and SPACE_BLOCK.

Referenced by cctk_init_std_archetypes(), and init_library().

Here is the call graph for this function:

Here is the caller graph for this function:

void make_sure_not_seen ( const object * op )

The object which is supposed to be visible through walls has just been removed from the map, so update the los of any players within its range

Parameters

op	object that disappears.

Todo:: what about tiled maps?

Definition at line 667 of file los.c.

References pl::do_los, first_player, obj::map, socket_struct::mapx, socket_struct::mapy, pl::next, pl::ob, pl::socket, obj::x, and obj::y.

Referenced by process_object().

Here is the caller graph for this function:

void make_sure_seen ( const object * op )

The object is supposed to be visible through walls, thus check if any players are nearby, and edit their LOS array.

Parameters

op	object that should be visible.

Todo:: what about tiled maps?

Definition at line 644 of file los.c.

References pl::blocked_los, first_player, obj::map, socket_struct::mapx, socket_struct::mapy, pl::next, pl::ob, pl::socket, obj::x, and obj::y.

Referenced by process_object().

Here is the caller graph for this function:

void print_los ( object * op )

Debug-routine which dumps the array which specifies the visible area of a player. Triggered by the DM command printlos.

Parameters

op	DM asking for information.

Todo:: change the command to view another player's LOS?

Definition at line 614 of file los.c.

References pl::blocked_los, obj::contr, draw_ext_info(), MAP_CLIENT_X, socket_struct::mapx, socket_struct::mapy, MSG_TYPE_COMMAND, MSG_TYPE_COMMAND_DEBUG, NDI_UNIQUE, snprintf(), and pl::socket.

Referenced by command_printlos().

Here is the call graph for this function:

Here is the caller graph for this function:

static void set_block	(	int	x,
		int	y,
		int	bx,
		int	by
	)

static

What this sets is that x,y blocks the view of bx,by This then sets up a relation - for example, something at 5,4 blocks view at 5,3 which blocks view at 5,2 etc. So when we check 5,4 and find it blocks, we have the data to know that 5,3 and 5,2 and 5,1 should also be blocked. Used to initialise the array used by the LOS routines.

Parameters

x
y	coordinates that block.
bx
by	coordinates that get blocked.

Todo:: check index for overflow?

Definition at line 75 of file los.c.

References blstr::index, llevDebug, LOG(), blstr::x, and blstr::y.

Referenced by init_block().

Here is the call graph for this function:

Here is the caller graph for this function:

static void set_wall	(	object *	op,
		int	x,
		int	y
	)

static

This recursively sets the blocked line of sight view. From the blocked[][] array, we know for example that if some particular space is blocked, it blocks the view of the spaces 'behind' it, and those blocked spaces behind it may block other spaces, etc. In this way, the chain of visibility is set. Used to initialise the array used by the LOS routines.

Parameters

op	player for which we're computing.
x
y	indexes into the blocked[][] array.

Definition at line 185 of file los.c.

References pl::blocked_los, obj::contr, blstr::index, MAP_CLIENT_X, MAP_CLIENT_Y, socket_struct::mapx, socket_struct::mapy, pl::socket, blstr::x, and blstr::y.

Referenced by check_wall().

Here is the caller graph for this function:

void update_all_los	(	const mapstruct *	map,
		int	x,
		int	y
	)

This function makes sure that update_los() will be called for all players on the given map within the next frame. It is triggered by removal or inserting of objects which blocks the sight in the map. Modified by MSW 2001-07-12 to take a coordinate of the changed position, and to also take map tiling into account. This change means that just being on the same map is not sufficient - the space that changes must be withing your viewable area.

Parameters

map	map that changed.
x
y	coordinates of the change.

Todo:: check if this couldn't be simplified, especially tiling (isn't there a function somewhere that could help?)

Definition at line 544 of file los.c.

References pl::do_los, first_player, obj::map, MAP_HEIGHT, MAP_WIDTH, socket_struct::mapx, socket_struct::mapy, pl::next, pl::ob, pl::socket, mapdef::tile_map, obj::x, and obj::y.

Referenced by cfapi_object_set_property(), do_turn(), gate_type_process(), insert_ob_in_map(), insert_ob_in_ob(), kill_object(), magic_wall(), remove_ob(), and tear_down_wall().

Here is the caller graph for this function:

void update_all_map_los ( mapstruct * map )

update all_map_los is like update_all_los() below, but updates everyone on the map, no matter where they are. This generally should not be used, as a per specific map change doesn't make much sense when tiling is considered (lowering darkness would certainly be a strange effect if done on a tile map, as it makes the distinction between maps much more obvious to the players, which is should not be. Currently, this function is called from the change_map_light function

Parameters