comp_piston_platform

comp_piston_platform

This logic entity manages a set of brush entities to control a set of pistons, like in Portal 1 or 2. The entity can produce only regular logic for use in P1 or other games, but for full functionality VScript is required. comp_piston_platform measures the start/end position of all pistons, allowing detecting the starting configuration, and for each which direction Open/Close correspond to. In VScript mode the pistons can start in any configuration, and be told to move to any position. In basic logic mode, the pistons can only be fully extended or retracted.

Setup

The entity expects a certain setup of either func_door or func_movelinear brushes for the pistons.

• The pistons should be placed in their starting position, then set to move up/down the appropriate distance for their segment.
• Parent each to the previous (in the direction of the anchor).
• Each should be solid (so they stop if blocked), and the topmost one can include the platform surface.
• Models should be parented to their brush as normal.
• Don't set movement sounds - this is triggered externally to prevent start/stop sounds triggering after each individual segment.
• If the piston never fully retracts, those should probably be prop_static and func_detail. In this case you can leave the first few piston keys blank to allow the MoveToX inputs to correspond better to the target length.
• Any extra segments at the top that don't actually extend should be merged into the top piston, for efficiency.
• More than 5 segments will work, but you'll need to turn off "SmartEdit", then add the piston keys yourself.

Hurt Triggers

When retracting, it is often possible to obstruct the platform with objects or the player (especially if it fully retracts into grating). To deal with this, a pair of triggers are used, one for players and one for objects. These are thin and placed just under the platform. The logic expects 3 different triggers - a trigger_hurt for players, and either a trigger_multiple or trigger_portal_cleanser for objects. trigger_multiple is preferred, since this can have different outputs added to explode turrets, fizzle cubes, and break other props. But a fizzler works fine as well.

By default comp_piston_platform has trigger autoconfiguring enabled, meaning it will set all the keyvalues to appropriate options, and if only one trigger is supplied automatically copy it to produce the other. If disabled it's up to you to set appropriate outputs. If VScript is enabled, "lienient hurt" can be enabled. In this mode, the triggers are only enabled if the platform is blocked and stops moving for a second or so. This gives objects a chance to be pushed away. Without VScript, the triggers are always active while it moves down.

Enable Motion Trigger

If reflection cubes are powered, they are motion disabled to prevent accidentally knocking them out of alignment. But this needs to be disabled if platforms moved. To handle this, add a trigger_multiple on top of the platform. If autoconfiguring is enabled, a prop_weighted_cube filter is added automatically. If the piston is attached to the wall/ceiling or no reflection cubes are used, this can be safely omitted.