CAreaPortal

From Valve Developer Community
Revision as of 03:12, 9 June 2008 by TomEdwards (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

The CAreaPortal class represents an areaportal. It's a very simple affair in game code, but also a very unusual entity.

Caveats

Areaportals do not exist in the world
Although portals are created as brushes in Hammer, at runtime they are something quite unique: while they do exist at a location, that location is not in the same dimension, as it were, as anything else. Any function with which you try to return a portal's position will only give (0,0,0).
So what can you do if you need that data? Your only option is to tie it to an entity that does have one. For instance, to determine how close the player is CFuncAreaPortalWindow steals its associated brush model before using CollisionProp()->CalcDistanceFromPoint().
Areaportals are closed and opened on the server
Since portal flow also helps decide which entities are transmitted to a client, a portal's state is decided by the server. This happens separately for each connected player. The resulting value is presumably networked to the client for rendering control somewhere outside the SDK's code.

UpdateVisibility()

This is the function called every tick by the server to decide whether or not the portal should be opened or closed.

As well as simply responding to a 'hard' value of closure (i.e. input, initial state, or linked door status) it calculates a 'soft' value by checking whether or not the plane facing towards the player's current area is also facing the player's origin (vOrigin). If it isn't, which is to say if the player is around a corner from it, the portal is closed.

Clients don't perform this backfacing test when controlling rendering for reasons explained in game\server\func_areaportalbase.h.

See also