CAreaPortal

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 piggyback on an entity that does have it. For instance, to determine how close the player is CFuncAreaPortalWindow steals its associated brush model before using CollisionProp()->CalcDistanceFromPoint().

(Mappers will need to create the linked entity in roughly the same place as the portal of course!)

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()

The portal is closed.

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) that is the same for every client, 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 has doubled back around a corner from it, the portal is closed for them.

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

See also

• Areaportal
• func_areaportal
• CFuncAreaPortalWindow / func_areaportalwindow
• CAreaPortalOneWay (source code for new entity)