prop_scalable
...
prop_scalable
is a point entity available in Half-Life 2: Episode Two. It creates a non-solid model that can be resized dynamically via inputs. It is used for the "superportal" effects at the beginning and end of the game. This entity is the successor of prop_coreball
from Half-Life 2: Episode One .
Bug:This entity is defined in later games' FGDs but is not implemented in the engine.
In code, it is represented by the
CPropScalable
class, defined in theprop_scalable.cpp
file.Keyvalues
Base:
- Parent
(parentname)
<targetname> - Maintain the same initial offset to this entity. An attachment point can also be used if separated by a comma at the end. (
parentname [targetname],[attachment]
)Tip:Entities transition to the next map with their parentsTip:phys_constraint
can be used as a workaround if parenting fails.
- Origin (X Y Z)
(origin)
<coordinates> - The position of this entity's center in the world. Rotating entities typically rotate around their origin.Note:Hammer does not move the entities accordingly only in the editor.
- Pitch Yaw Roll (X Y Z)
(angles)
<angle> - This entity's orientation in the world. Pitch is rotation around the Y axis, yaw is the rotation around the Z axis, roll is the rotation around the X axis.Note:This works on brush entities, although Hammer doesn't show the new angles.
- Classname
(classname)
<string> !FGD - Determines the characteristics of the entity before it spawns. Tip:Changing this on runtime still has use, like making matching an entry in S_PreserveEnts will persist the entity on new rounds!
Inputs
SetScaleX
<vector>
SetScaleY
<vector>
SetScaleZ
<vector>- Scales the model (local axes). Accepts either
newscale timespan
ornewscale
, where "newscale" is a float that sets the new scale of the prop, and "timespan" is an integer number of seconds over which the size change happens. If no timespan is specified, the changes apply immediately.
Note:Changing the size is not able via variables (e.g.,
math_counter
). You can set the different sizes in a logic_case
to get a near-blend between different sizes.Base:
AddContext
<string>- Adds to the entity's list of response contexts. See Context.
AddOutput
<string>- Assigns a new keyvalue/output on this entity. For keyvalues, some rely on extra necessary code to be ran and won't work if its simply just changed through this input. There is a strict format that must be followed:
// Format of changing KeyValues: "AddOutput [key] [value]"
//// Raw text:
"OnUser1" "!self,AddOutput,targetname new_name"
// Format of adding an Output: "AddOutput {targetname}:{inputname}:{parameter}:{delay}:{max times to fire, -1 means infinite}"
//// Raw text:
"OnUser1" "!self,AddOutput,OnUser1:SetParent:!activator:0.0:-1"
// Arguments can be left blank, but the empty blank should still be contained.
//// Raw text:
"OnUser1" "!self,AddOutput,OnUser1:ClearParent::0.0:-1"
|
ClearContext
- Removes all contexts from this entity's list.
ClearParent
- Removes this entity from the the movement hierarchy, leaving it free to move independently.
FireUser1
toFireUser4
- Fires the respective
OnUser
outputs; see User Inputs and Outputs.
Kill
- Removes this entity and any entities parented to it from the world.
KillHierarchy
- Functions the same as
Kill
, although this entity and any entities parented to it are killed on the same frame, being marginally faster thanKill
input.
RemoveContext
<string>- Remove a context from this entity's list. The name should match the key of an existing context.
SetParent
<string>- Move with this entity. See Entity Hierarchy (parenting).
SetParentAttachment
<string>- Change this entity to attach to a specific attachment point on its parent. The entity will teleport so that the position of its root bone matches that of the attachment. Entities must be parented before being sent this input.
SetParentAttachmentMaintainOffset
<string>- As above, but without teleporting. The entity retains its position relative to the attachment at the time of the input being received.
Outputs
Base:
OnUser1
toOnUser4
- These outputs each fire in response to the firing of the like-numbered
FireUser1
toFireUser4
Input; see User Inputs and Outputs.